בניית AI מהימן במהירות של 160 קמ"ש

1. סקירה כללית

בינה מלאכותית היא חלק ממערכות תוכנה רבות, אבל בניית אפליקציית AI שונה מבניית אפליקציה שהמשתמשים יכולים לסמוך עליה. בהרבה סביבות בעולם האמיתי, האתגר הוא לא רק ליצור תשובה. האתגר הוא ליצור תגובה שהיא עדכנית, מבוססת, ניתנת ליישום ותואמת למומחיות אנושית.

ב-Codelab הזה תבנו סימולטור של מאמן מרוצים שמדגים את הרעיונות האלה בצורה מוחשית ומושכת. האפליקציה משתמשת בנתוני טלמטריה ממכונית מרוץ וירטואלית כדי ליצור אנימציה של תנועה במסלול ולספק הדרכה. התרחיש הוא מירוץ, אבל אותם רעיונות ארכיטקטוניים רלוונטיים גם לתחום הבריאות, הייצור, הלוגיסטיקה ולתחומים אחרים שבהם האמון חשוב.

תעבדו עם זרם מהיר של נתוני טלמטריה, תמירו אותם לפורמט שימושי ויעיל לניתוח על ידי AI, ותשלבו פלט מבוסס-LLM עם הנחיות אנושיות מוצפנות כדי להפיק תשובות מהימנות יותר.

מה תפַתחו

בשיעור ה-Codelab הזה תיצרו אב טיפוס של AI מהימן ש:

• הזרמת טלמטריה ממכונית מרוץ וירטואלית שפועלת ב-Google Cloud
• הדמיה של מכונית שנוסעת במסלול מרוצים באמצעות Chrome
• הופך נתוני טלמטריה גולמיים לקלט שמוכן לשימוש ב-AI
• החלת שכבת אסטרטגיה שמבוססת על Google Gemini
• שילוב של פלט המודל עם הנחיות אנושיות מקודדות וכללי בטיחות
• מספק משוב על אימון באמצעות ממשק שפונה למשתמש

מה תלמדו

בסיום ה-Codelab הזה, תוכלו:

• הסבר על הגורמים שמשפיעים על רמת המהימנות של מערכת AI
• הסבר על המטרה של ארכיטקטורת AI מודולרית
• יצירת פייפליין פשוט של טלמטריה מדומה
• הכנת נתונים מובְנים ושימושיים לשימוש עם LLM
• החלת שכבות הגנה וכללים בהנחיית אדם כדי לשפר את האמינות
• הערכה של האופן שבו אפשר להחיל את הארכיטקטורה הזו על דומיינים אחרים

2. מה צריך

לפני שמתחילים, חשוב לוודא שיש לכם את החשבונות, הכלים והשירותים הנדרשים.

דרישות מוקדמות

צריכים להיות לכם:

• חשבון Google אישי עם כתובת Gmail
• גישה ל-Google Cloud והבנה בסיסית של CLI
• חשבון לחיוב פעיל או קרדיטים ל-Cloud
• הבנה כללית של Google Cloud ו-AI גנרטיבי באמצעות Gemini

‫Gemini הוא מודל ה-AI של Google שמבוסס על חשיבה רציונלית מתקדמת, והוא יכול להפוך כל רעיון למציאות. זהו מודל מצוין להבנה מולטי-מודאלית, לתכנות סוכנים ולתכנות בשיטת Vibe coding.

קבלת קרדיטים לשימוש ב-Google Cloud

כדי לממש את הקרדיטים, צריך להיכנס לקישור הזה ולהתחבר באמצעות כתובת אימייל ב-Gmail (דומיין gmail.com). לאחר מכן, מאשרים את הקרדיטים בחשבון לחיוב ב-Google Cloud Platform ‏ (GCP), והם יתווספו לחשבון.

3. למה חשוב להשתמש ב-AI מהימן

מערכות AI רבות יכולות ליצור תשובות שוטפות ומשכנעות, אבל שוטפות לא אומרת אמינות. במערכות בעולם האמיתי, משתמשים צריכים לעיתים קרובות תשובות מבוססות בזמן, שמוגבלות על ידי כללי בטיחות ומעוצבות על ידי מומחיות בתחום.

זה חשוב במיוחד כשמערכת פועלת על נתונים שמשתנים במהירות. תשובה שמגיעה מאוחר מדי עלולה להיות חסרת תועלת. תשובה שנשמעת בטוחה אבל מתעלמת מהקשר חשוב עלולה להטעות. יכול להיות שיהיה קשה לסמוך על תשובה שלא מבוססת על ידע אנושי, גם אם היא נשמעת מנוסחת היטב.

בתרחיש של מכונית המרוץ שמשמש במעבדת הקוד הזו, הבעיה היא לא אם AI יכול להגיד משהו מעניין. הבעיה היא אם המערכת יכולה לספק עצות שימושיות, בטוחות, בזמן המתאים ובהתאם למצב.

בואו נסתכל על דוגמה קטנה של טלמטריה ונשווה בין שתי תוצאות אפשריות:

Racing Car Telemetry Data
{
   "speedMph": 118,
   "throttle": 91,
   "frontGrip": "nominal",
   "rearGrip": "low",
   "trackPosition": "Turn 1 Entry"
}

תשובה נאיבית של AI

"Stay aggressive on the throttle and carry your speed into Turn 1"

תשובה שמודעת למהימנות

"Rear grip is low at Turn 1 entry. Reduce your throttle slightly and prioritize a stable corner entry"

שמתם לב להבדל?

מה יקרה אם נסתמך רק על התשובה של ה-AI הנאיבי?

התשובה הראשונה נשמעת בטוחה, אבל היא מתעלמת מהסיכון. התשובה השנייה שימושית יותר כי היא משקפת את ההקשר וההגבלה.

במקום להתייחס ל-LLM כמערכת שלמה, צריך להתייחס אליו כאל חלק אחד בארכיטקטורה רחבה יותר כדי להגביר את רמת המהימנות. בנוסף, בהרבה אפליקציות נדרש שההמלצות יתקבלו מספיק מהר כדי שאפשר יהיה לפעול לפיהן, כמו במכונית מרוץ, בהליך רפואי, בתעופה, ברשת חשמל, במערכת מסחר, בניווט ימי וכו'.

עכשיו נסביר איך יוצרים ארכיטקטורה כזו.

4. הסבר על AI מהיר ועל ארכיטקטורה מודולרית מהימנה

חלק ממערכות ה-AI צריכות להתנהג בצורה שונה מאוד. הם צריכים להגיב במהירות לשינויים בתנאים, וגם לתמוך בהסקה איטית ומחושבת יותר.

בארכיטקטורה מודולרית, האחריות הזו מחולקת לנתיבים נפרדים. נתיב אחד יכול להיות רפלקסיבי, ולטפל בפרשנות מיידית של אותות נכנסים שרגישים לזמן. מסלול אחר יכול להתמקד באסטרטגיה, לתמוך בחשיבה רציונלית ברמה גבוהה יותר ובקבלת החלטות שמודעות יותר להקשר. נתיבים אחרים מטרגטים סוגים אחרים של פונקציונליות.

חלק מההחלטות צריכות להתקבל בזמן אמת. יש החלטות שכדאי להקדיש להן יותר זמן למחשבה.

כדי להשתמש ב-AI בצורה מהימנה, לרוב צריך את שניהם.

ההפרדה הארכיטקטונית הזו עוזרת למערכת להמשיך להגיב, ועדיין לתמוך בהנחיות מבוססות-AI עשירות יותר. בנוסף, הוא יוצר מקום ברור להצגת אילוצים מונחים על ידי בני אדם וידע בתחום.

בתוכנית הקטנה הזו, יש נתיב רפלקס ונתיב אסטרטגיה שמוטמעים כפונקציות Python.

const telemetry = {
  speed: 147,
  grip: 0.68,
  corner_type: "sharp",
  lap_trend: "entering_corners_too_fast",
};

function reflexPath(event: typeof telemetry): string {
  if (event.grip < 0.70) {
    return "REFLEX: Reduce throttle now";
  }
  return "REFLEX: No urgent issue";
}

function strategyPath(event: typeof telemetry): string {
  if (event.lap_trend === "entering_corners_too_fast") {
    return "STRATEGY: Brake earlier and prioritize corner exit";
  }
  return "STRATEGY: Driving pattern looks stable";
}

console.log(reflexPath(telemetry));
console.log(strategyPath(telemetry));

שתי הפונקציות מתנהגות באופן שונה כשמזינים להן את אותם נתוני טלמטריה. פונקציית הרפלקס היא אזהרה מיידית. הפונקציה 'אסטרטגיה' מספקת לנו עצות אימון שמבוססות על כללים.

למה לדעתך כדאי להפריד את הלוגיקה הזו?

עכשיו ניצור אפליקציה כיפית מרובת חלקים ונראה איך הארכיטקטורה הזו הופכת תגובות מהירות וחשיבה רציונלית מעמיקה למערכת AI מהימנה שתוכלו להתנסות בה בפועל.

5. בניית שרת להזרמת טלמטריה

אחרי שהבנתם את המטרה הארכיטקטונית, הגיע הזמן לבנות את צינור הנתונים שמפעיל את האפליקציה.

בקטע הזה, תיצרו זרם טלמטריה פשוט למכונית מרוץ וירטואלית. הנתונים יגיעו ממקור CSV שמכיל נתוני GPS או נתוני מיקום מסלול, והאפליקציה שלכם תמיר אותם לשידור חי ששכבת ממשק המשתמש ושכבת ה-AI יוכלו לעבד.

בקטע הזה תלמדו:

• יצירת פרויקט חדש ב-Google Cloud לשרת ולאפליקציה של הסטרימינג
• יצירת שרת קטן להעברת נתוני טלמטריה
• הזרמת האירועים לממשק משתמש בדפדפן או למסוף

1. פתיחת Cloud Shell

א. עוברים אל מסוף Google Cloud.
ב. יוצרים פרויקט חדש בשביל ה-codelab הזה. לוחצים על התפריט הנפתח של הפרויקט בחלק העליון.

כשיוצרים פרויקט, כדאי לקשר אותו לחשבון לחיוב:

לחלופין, אם כבר יצרתם פרויקט, אתם יכולים לפתוח את החלונית הימנית, ללחוץ על Billing ולבדוק אם החשבון לחיוב מקושר לחשבון GCP הזה.

ג. קבלת מפתח Gemini API

אחרי שמפעילים את הקרדיטים ל-Google Cloud, צריך מפתח Gemini API כדי לגשת ל-Gemini ב-Google Cloud.

כדי ליצור מפתח Gemini API, צריך להשתמש ב-Google Vertex AI Studio כדי ליצור מפתחות.

ב-Vertex AI Studio, לוחצים על 'קבלת מפתח API' בפינה הימנית התחתונה מעל 'תיעוד'. יוצרים מפתח API ל-Gemini (נראה כמו מחרוזת ארוכה של תווים שנראים אקראיים). שומרים את המפתח הזה במקום מאובטח. נשתמש במפתח ה-API הזה בשלב 6, 'יצירת סימולטור מכונית מרוץ', כדי לאמת את הגישה שלנו ל-Gemini ב-Google Cloud.

חשוב שמפתחות ה-API לא יהיו בקוד המקור, ואסור להוסיף אותם למאגרי Git. מומלץ לאחסן אותם במשתני סביבה או במנהל סודות מאובטח. חשוב להתייחס למפתחות API כמו לסיסמאות: אסור לשתף אותם בצ'אטים, באימייל, בצילומי מסך או ביומנים. להחליף אותם באופן קבוע. במערכות ייצור, מומלץ להוסיף התראות על מעקב ושימוש כדי לזהות במהירות כל שימוש לרעה ולבטל באופן מיידי מפתחות שנפרצו.

ד. לוחצים על סמל Cloud Shell בסרגל העליון (סמל הטרמינל) כדי לפתוח טרמינל מבוסס-דפדפן.

ה. מחכים שהסשן בטרמינל יתחיל.

2. קבל את הקוד

משכפלים את מאגר הראשי.

git clone https://github.com/ocupop/trustable-ai-codelab.git
cd trustable-ai-codelab

שימו לב שיש שני תיקיות במאגר הזה: koru-application (אפליקציית אינטרנט) ו-streaming-telemetry-server (טלמטריה סימולטיבית של מכונית מרוץ בזמן אמת). בשלב הזה מתואר ה-streaming-telemetry-server. נשתמש ב-koru-application בשלב הבא.

3. הפעלת ממשקי ה-API הנדרשים

מריצים את הפקודה פעם אחת לכל פרויקט:

# Set Project ID
gcloud config set project YOUR_PROJECT_ID
# Enable APIs
gcloud services enable \
  run.googleapis.com \
  cloudbuild.googleapis.com \
  artifactregistry.googleapis.com

מחליפים את YOUR_PROJECT_ID במזהה הפרויקט בפועל (או מדלגים על השורה הראשונה אם הפרויקט כבר מוגדר).

אפשר למצוא את YOUR_PROJECT_ID ברשימת הפרויקטים

4. פריסת ה-Backend ב-Cloud Run

מתיקיית השורש של המאגר (כלומר, מוודאים שאתם נמצאים בתיקייה trustable-ai-codelab):

gcloud run deploy streaming-telemetry-server \
  --source streaming-telemetry-server \
  --platform managed \
  --region us-central1 \
  --allow-unauthenticated

הערה: יכול להיות שתצטרכו להקיש על Y כשתוצג בקשה.

• יכול להיות שבמהלך ההרצה הראשונה תתבקשו להפעיל ממשקי API או ליצור מאגר Artifact Registry. צריך לאשר את הפעולות האלה לפי הצורך.
• אם אתם משתמשים באזור אחר מus-central1, אתם צריכים לציין את האזור הזה באמצעות --region
• בסיום הפריסה, gcloud מדפיס את service-URL. כדי להשתמש בכתובת ה-URL הזו כנקודת הקצה המלאה של שרת הטלמטריה, צריך רק להוסיף את המחרוזת events.

5. שימוש בכתובת ה-URL של השידור

שרת הטלמטריה פולט עכשיו נתוני טלמטריה מסימולציה באמצעות Server-Sent-Events ‏ (SSE) בנקודת קצה מהצורה :

service-URL/events		// service-URL - the last line displayed by "deploy"

הפורמט של נקודת הקצה של הסטרימינג הוא: https://streaming-telemetry-server-${PROJECT_NUMBER}.${REGION}.run.app/events כאשר $PROJECT_NUMBER ו-$REGION מוגדרים לערכים שלהם עבור השרת הספציפי שלכם.

בדיקה בדפדפן: נכנסים לכתובת ה-URL של נקודת הקצה של הסטרימינג באמצעות Chrome. בדפדפן אמורים להופיע נתונים מוזרמים נכנסים, שמדמים נתונים שנפלטים מחיישנים במכונית מרוץ.

כדי לסיים את החיבור, אפשר לסגור את הכרטיסייה בדפדפן.

בדיקה באמצעות curl:

עכשיו נבדוק משורת הפקודה של Shell.

curl -N service-URL/events		# Replace service-URL with actual deployment endpoint

בחלון של Cloud Shell אמורים להופיע נתונים מוזרמים נכנסים.

נשתמש בנתוני הטלמטריה האלה כדי לדמות את הנתונים שמשודרים מחיישנים במכונית מרוץ. נשתמש בנתונים האלה בהמשך ה-codelab. אפשר להפסיק את התוכנית curl על ידי הקשת CTRL-C בחלון הטרמינל.

מה כדאי לשים לב

במהלך מילוי הקטע הזה, חשוב לשים לב לאופי הנתונים הנכנסים. נתוני טלמטריה גולמיים הם לרוב נתונים בכמות גדולה, שרגישים לזמן ולא מתאימים באופן מיידי לניתוח על ידי AI. אחרי שנפתח את אפליקציית הקצה, נצטרך לסנן את הנתונים הגולמיים לפורמט יעיל ש-LLM יכול לעבד במהירות.

אבל קודם נבנה את ממשק האינטרנט כדי להציג את הנתונים.

6. הרכבת סימולטור מכונית מרוץ

בקטע הזה תלמדו:

• יצירת סימולציה של מכונית מרוץ
• חיבור שרת הטלמטריה לאפליקציית האינטרנט של מכונית המירוץ
• צפייה במירוצים מדומימים

בשלב הזה, יש לנו סימולציה פעילה של נתוני הטלמטריה ממכונית מרוץ שפועלת בענן. עכשיו ניצור את האפליקציה שפועלת במכונה המקומית, מתחברת ל-Google Cloud ומציגה את הנתונים בצורה ויזואלית.

אפליקציית ה-AI המהימנה שלנו משתמשת גם בעוצמה ובגמישות של שירותי Google Cloud וגם בנתונים מקומיים שפועלים ב-Chrome.

שירות הטלמטריה של הסטרימינג פועל ב-Google Cloud, אבל אפליקציית מכונית המירוץ פועלת במחשב המקומי שלכם. כלומר, תצטרכו לשכפל שוב את המאגר, הפעם למחשב הנייד או למחשב שלכם.

כדי לפשט את הדברים, אותו מאגר מכיל את הקוד של שרת הסטרימינג ושל אפליקציית מכונית המירוץ.

משכפלים את אפליקציית ה-front-end מ-GitHub:

git clone https://github.com/ocupop/trustable-ai-codelab.git
cd trustable-ai-codelab

אחרי שהמאגר משוכפל במחשב הנייד או במחשב השולחני, מריצים את האפליקציה.

cd koru-application		# racing car simulation app
npm install
npm run dev

‫"koru" הוא סמל מתרבות המאורי בניו זילנד. הוא מסמל התחלה חדשה.

ב-Chrome, פותחים את היציאה במחשב המקומי (http://localhost:5173 כמו בדוגמה שלמעלה). יוצג דף הנחיתה של האפליקציה 'AI Motorsport Coaching'.

לוחצים על הלחצן 'פתיחת לוח הבקרה ->'. ממשק המשתמש של האפליקציה יופעל.

בשלב הזה, יש לכם שרת טלמטריה שמפיק טלמטריה מסימולציה של מכונית מירוץ ב-Google Cloud, ואפליקציית אינטרנט מקומית שיכולה להציג את הנתונים האלה באופן חזותי ולהתחבר למודל שפה גדול (LLM). בואו נחבר אותם, וגם נתחבר לשירותי Gemini LLM.

בפינה השמאלית העליונה של האפליקציה, לוחצים על סמל גלגל השיניים (הגדרות).

מזינים את מפתח Gemini API משלב 2. כך מקבלים גישה לשירותי Gemini ב-Google Cloud.

לוחצים על 'שמירה' כדי שהאפליקציה תזכור את מפתח ה-API.

עכשיו נחבר את האפליקציה לשרת הטלמטריה. בלוח הבקרה של האפליקציה, לוחצים על 'סשן פעיל'.

מזינים את כתובת ה-URL הספציפית של שרת הטלמטריה מבוסס-הענן (שלב 5) בשדה הטקסט SSE URL or .txt file path. כתובת ה-URL של ה-SSE שלנו הייתה בפורמט:

https://streaming-telemetry-server-${PROJECT_NUMBER}.${REGION}.run.app/events

אחרי שמזינים את כתובת ה-URL של נקודת הקצה של שרת הטלמטריה, לוחצים על 'התחברות' (משמאל לשדה הטקסט). אל תשכחו להוסיף את המילה events בסוף כתובת ה-URL.

עכשיו אמור להופיע ייצוג ויזואלי של הנתונים המדומים באפליקציה.

אם עוצמת הקול של הרמקול מוגברת, תוכלו לשמוע את העצות לגבי מירוץ המכוניות מסוגים שונים של מאמנים. לכל מאמן יש אישיות שונה. נסו לבחור מאמנים שונים כדי לשמוע את עצות המירוץ המגוונות שלהם ואת סגנונות הקול השונים שלהם. אם צריך, אפשר להשבית את האודיו בלחיצה על סמל הרמקול.

עכשיו, כשיש לנו אפליקציה שעובדת, נסביר איך הכנו את הנתונים לעיבוד יעיל על ידי ה-LLM ואיך אפשר להוסיף תכונות נוספות כדי לשפר את מהימנות המערכת הכוללת.

7. הכנת נתוני טלמטריה לניתוח באמצעות AI

טלמטריה גולמית שימושית לסימולציה, אבל בדרך כלל היא מפורטת מדי ומתרחשת בתדירות גבוהה מדי כדי לשלוח אותה ישירות ל-LLM. אם תשלחו את כל נתוני הטלמטריה ללא שינוי, יכול להיות שזמן האחזור יתארך, שיופיעו הפרעות ושהאיכות של ההנחיות שיתקבלו תהיה נמוכה יותר.

בקטע הזה, תעצבו מחדש את נתוני הטלמטריה כדי שיהיו שימושיים יותר.

בקטע הזה תלמדו:

• בדיקת ה-JSON הגולמי של נתוני הטלמטריה
• זיהוי השדות שהכי רלוונטיים לנימוק
• סינון או סיכום הנתונים
• הפחתת פרטים מיותרים
• הכנת ייצוג ידידותי ל-AI של מצב הנהיגה

זהו שלב חשוב בבניית AI שאפשר לסמוך עליו. איכות התשובה תלויה לא רק במודל, אלא גם במבנה וברלוונטיות של הנתונים שהוא מקבל.

עכשיו נבדוק את הנתונים הספציפיים לגבי מכוניות מירוץ. אפשר לערוך ניסויים על ידי שינוי ערכים ספציפיים באפליקציה, טעינה מחדש של האפליקציה ובדיקת התוצאה.

../src/services/telemetryStreamService.ts near line 180

// Clamp G-forces
gLat = Math.max(-3, Math.min(3, gLat));		// sideways G-force
gLong = Math.max(-3, Math.min(3, gLong));	// front/back G-force

כוחות ה-G במכונית הם מדד להאצה או להאטה. במכונית מרוץ, הבנת כוחות ה-G עוזרת לשליטה במכונית ולביצועים הכוללים שלה. אם המידע הזה לא מופיע באפליקציה שלנו, קשה לספק לנהג עצות. מוסיפים הערה לשתי השורות האלה, מגדירים את הערכים של gLat ושל gLong ל-0.0 ומריצים מחדש את האפליקציה.

שימו לב שלא ניתן ייעוץ כשהמכונית מתקרבת לפינה. זה לא מאוד שימושי לנהג מרוצים!

לאחר מכן מבטלים את השינוי ומריצים מחדש את האפליקציה. שמתם לב להמלצות האודיו המועילות כשהמכונית מגיעה לפינה? נקודות הנתונים של כוח ה-G חיוניות למתן עצות לנהג.

עכשיו נגביל באופן מלאכותי את מהירות הנסיעה של המכונית לקצב נינוח של 30 מייל לשעה. לא ננצח במרוצים במהירות הזו, אבל זה בהחלט ידגים את סוג האימון שאנחנו מקבלים.

באותו קובץ (telemetryStreamService.ts) ליד שורה 158, נמצאת הפונקציה processPoint(). בפונקציה הזו, נגביל את המהירות.

שנה את:

private processPoint(point: GpsSSEPoint) {
...
 const speedKmh = point.speed > 200 ? point.speed : point.speed * 3.6;
...

אל:

private processPoint(point: GpsSSEPoint) {
...
 let speedKmh = point.speed > 200 ? point.speed : point.speed * 3.6;
 speedKmh = Math.min(speedKmh, 48);   // 48 kmh is approx 30 mph
...

מריצים מחדש את האפליקציה. איזה סוג של ייעוץ אימון אנחנו מקבלים עכשיו? לא צריך הרבה אם נוסעים בנחת!

עכשיו צריך לבטל את השינויים האלה ולהפעיל מחדש את האפליקציה.

ברור שמהירות המכונית היא נקודה על הגרף חשובה. חשוב מאוד להבין אילו נתונים ספציפיים נחוצים כדי לספק המלצות מועילות. חשוב באותה מידה להעריך אילו נתונים לא רלוונטיים.

כדאי גם להתחיל לחשוב על בטיחות ואמינות. גם אם הקלט מוכן היטב, לא מובטח שתתקבל תשובה מהימנה. אנחנו עדיין צריכים להציג כללים מפורשים ומגבלות ברורות בהנחיית בני אדם.

הכנת הנתונים היא לא רק שלב של עיבוד מוקדם. זהו חלק קריטי באסטרטגיית האמון. קלט נקי יותר מוביל לרוב לפלט ממוקד ואמין יותר.

8. הוספת אמצעי הגנה ומומחיות אנושית מוצפנת

מערכת AI מהימנה לא צריכה להסתמך רק על הפלט של המודל. במקרים רבים, המערכות הכי אמינות משלבות בין נימוקים של מודל שפה גדול (LLM) לבין כללים מפורשים, ידע בתחום ואילוצים בהנחיית אדם.

בקטע הזה מוסיפים את השכבה.

אפשר לחשוב על השכבה הזו כעל ידע אימון מקודד. ההנחיות האלה עשויות לכלול דפוסי תשובה מועדפים, כללי אימות, בדיקות בטיחות או הנחיות מובנות שעוזרות למערכת להישאר מבוססת עובדות ומועילה.

בקטע הזה תלמדו:

• הצגת כללי תגובה שמעצבים את התנהגות המודל
• איך משתמשים בבדיקות בטיחות כדי לצמצם את הסיכון לקבלת עצות מטעות
• שילוב מומחיות אנושית מוצפנת בצינור עיבוד הנתונים
• השוואה בין התשובות לפני ואחרי ההוספות האלה

נבדוק איך מומחיות בתחום מסוים מתווספת לאפליקציה שלנו.

בדרך כלל, מודל LLM לא מאומן במירוצים או בפיזיקה של ביצועי מכוניות מירוץ. אם האפליקציה שלנו הייתה כוללת את המומחיות הזו בתחום, המשתמשים היו יכולים לסמוך יותר על ההנחיות שלה. ההנחיות האלה מבוססות על כללים שנוצרו על סמך מומחיות אנושית, כלומר שכבת מומחיות בתחום.

../src/utils/coachingKnowledge.ts near line 115

...
export const RACING_PHYSICS_KNOWLEDGE = `
CORE PRINCIPLES:
1. **The Friction Circle:** A tire has 100% grip. If you use 100% for braking, you have 0% for turning.
  - *Error:* Turning while 100% braking = Understeer (Plowing).
  - *Fix:* "Trail braking" (releasing brake pressure as steering angle increases).

2. **Weight Transfer:**
  - Braking shifts weight forward (Front grip UP, Rear grip DOWN).
  - Accelerating shifts weight backward (Front grip DOWN, Rear grip UP).
  - *Error:* Lifting off throttle mid-corner shifts weight forward abruptly -> Oversteer (Spin risk).

3. **The racing line:**
...

העקרונות האלה של מכוניות מרוץ הם מרכיב מרכזי ביצירת תוצאות שאפשר לסמוך עליהן. מה יקרה אם לא יהיה לנו את הידע הזה? בואו נגלה.

אני רוצה להסיר את RACING_PHYSICS_KNOWLEDGE ולבדוק את העצות שלך לגבי מירוצים.

export const RACING_PHYSICS_KNOWLEDGE = ``;

מריצים מחדש את האפליקציה. איזה סוג של ייעוץ אימון אנחנו מקבלים עכשיו?

שימו לב לעצה הכללית.

אנחנו כבר לא מקבלים מידע מפורט על חיכוך, העברת משקל, מהירות יציאה וכו'. המהימנות שלנו נמוכה יותר בלי המידע הזה. משחזרים את המומחיות הזו במירוצים ומריצים מחדש את האפליקציה.

השלב הזה הוא היבט קריטי במערכת AI שאפשר לסמוך עליה. הנחיה טובה יותר לא יוצרת אמון באופן אוטומטי. האמון נובע מתכנון המערכת ומחשיבה ביקורתית.

מודל ה-LLM הוא חלק מהפתרון, אבל הוא לא הפתרון כולו. האמון משתפר כשהפלט של ה-AI מבוסס על ידע אנושי מפורש.

9. עיצוב של פרסונות האימון וחוויית המשתמש

אחרי שמקימים את צינור הנימוקים, השאלה הבאה היא איך המערכת צריכה לתקשר עם המשתמש.

בקטע הזה תגדירו איך שכבת האסטרטגיה מתקשרת עם הנהג, כדי לעצב את חוויית האימון. תשפרו את ההנחיה למערכת עבור אחת מהדמויות של המאמן, ותחשבו איך להעביר את ההנחיות שלה בצורה ברורה, בזמן הנכון והכי חשוב – בצורה שתאפשר לכם לפעול.

בקטע הזה תלמדו:

• יצירה או שיפור של הנחיה למערכת עבור דמות של מאמן
• התנסות בסגנונות אימון שונים
• איך שינויים בהנחיות משפיעים על התשובות
• הגדרת דרישות ממשק משתמש למשוב מהימן
• הסבר על התמיכה בהמרת טקסט לדיבור (TTS) בהודעות דחופות ולא דחופות

האפליקציה שלנו כוללת כמה דמויות של מאמנים. כל אחד מהם מספק סוגים שונים של עצות אימון.

PERSONA	מאפיינים
Tony	מעורר השראה, מבוסס על תחושות
רחל	טכני, עם דגש על פיזיקה
AJ	פקודות ישירות ובוטות
Garmin	אופטימיזציה מבוססת-נתונים, דלתא
Super AJ	מתגים שניתנים להתאמה לכל סוג שגיאה

הפרסונות האלה מוגדרות בקובץ ../src/utils/coachingKnowledge.ts.

בקובץ הזה תראו מפת אובייקטים (COACHES) שמקשרת בין מפתחות מחרוזת לבין CoachPersonas. רכיב CoachPersona מכיל מאפיינים של כל סוג של מאמן. מאפיין חשוב אחד הוא systemPrompt. לכל פרסונה יש systemPrompt משלה שמנחה את מודל ה-LLM לגבי אופן התגובה.

בואו נשנה את אחד מהם system prompts ונראה איך מודל ה-LLM מגיב.

ליד שורה 31, תראו את systemPrompt של AJ, שמספק עצות בצורה מאוד ישירה ובוטה. נשנה את ההגדרה systemPrompt כדי ש-AJ יהיה מנומס מדי.

systemPrompt: `You are AJ, a race engineer that is excessively polite. 
	Use telemtry terminology.  Be actionable
	Examples: 	"Lat G settling. please throttle", 
				"Brake when its convenient."
	Keep responses under 12 words. Never explain — just command.`

מריצים מחדש את האפליקציה, בוחרים את AJ כמאמן ובודקים אילו סוגי תשובות נוצרות.

עכשיו משחזרים את systemPrompt המקורי ומריצים מחדש את האפליקציה. שימו לב שההנחיה למערכת היא קריטית להנחיית ה-LLM לספק תגובה שתתאים לדמות.

אמינות היא לא רק עניין של נכונות. הוא עוסק גם באספקה. גם אם העצה מדויקת מבחינה טכנית, היא עדיין יכולה להיות לא יעילה אם היא לא ברורה, אם היא ניתנת בזמן לא מתאים או אם היא מסיחה את הדעת.

מערכת שאפשר לסמוך עליה צריכה לתקשר בצורה טובה. חוויית המשתמש היא חלק מארכיטקטורת האמון.

בסביבת ייצור, בדרך כלל מקצים לכל מאמן קולות שונים, ולא קול אחד שמשנה את הגובה וההטעמה שלו. עם זאת, השימוש בשירותי המרת טקסט לדיבור דורש הגדלה משמעותית של מספר הטוקנים שמועברים ברשת. אם אתם משתמשים בחשבון ענן לייצור, תוכלו לשמוע סוגים שונים של קולות של מאמנים.

10. סקירת הארכיטקטורה מקצה לקצה

בשלב הזה, בנינו את החלקים העיקריים של המערכת. עכשיו הגיע הזמן לעצור לרגע ולבדוק איך הם פועלים יחד.

הבקשה שלך כוללת עכשיו את הרכיבים הבאים:

• זרם טלמטריה
• שכבת הוויזואליזציה
• שלב שינוי הנתונים שמוכן לשימוש ב-AI
• רכיבי שיטה שמבוססים על LLM של נימוקים
• אמצעי הגנה והנחיות אנושיות מוצפנות
• חוויית אימון שפונה למשתמשים

דרך פשוטה ושימושית להבין את הזרימה הכוללת של הרכיבים האלה היא להוסיף רישום ביומן לאפליקציה.

נוסיף רישום ביומן כדי לראות את נתוני הטלמטריה כשהם עוברים בנתיבים.

קודם כל, נציג את נתוני הטלמטריה. ב-telemetryStreamService.ts, סביב שורה 212 (לפני this.emit(frame)), מוסיפים שורה שמציגה את המהירות, את כוח ה-G הצדדי (התאוצה הצידית) ואת עוצמת הלחיצה של הנהג על דוושת הבלם.

console.log('FRAME', { 
    speed: frame.speed.toFixed(1), 
    gLat: frame.gLat.toFixed(2),
    brake: frame.brake.toFixed(0) }
);

טוענים מחדש את האפליקציה. לפני שמריצים את האפליקציה, כדאי לפתוח את המסוף בכלי הפיתוח של Chrome כדי לראות את מידע על תוצאות ניפוי הבאגים.

באפליקציה, מזינים את נקודת הקצה של הטלמטריה ולוחצים על 'התחברות'. עכשיו אפשר לראות את נתוני הטלמטריה הנכנסים.

עכשיו נוסיף רישום ביומן לנתיב הרפלקס ולנתיב האסטרטגיה.

בשורה 71 בערך, לפני this.emit(), מוסיפים שורת רישום ביומן עבור הנתיב reflex:../src/services/coachingService.ts

console.log('Reflex', { 
	action: rule.action, 
	text, 
	coach: this.coachId }
);

באותו קובץ, בערך בשורה 287, לפני this.emit(), מוסיפים שורת רישום דומה לנתיב strategy (נוסיף את התשובה של האימון text שמוחזרת על ידי Gemini API):

console.log('Strategy', { 
	coach: coach.id, 
	chars: text.length, 
	preview: text.slice(0, 60) }
);

מריצים מחדש את האפליקציה. במסוף אפשר לראות איך נתוני הטלמטריה זורמים מהמקור דרך הנתיבים האלה. הזרם הנכנס מסונן, נשלח ל-LLM, מאומת באמצעות מומחיות אנושית מהימנה ומוצג למשתמש באמצעות ממשק משתמש מתאים.

שימו לב שחיברנו בין הרכיבים הטכניים השונים כדי להשיג את המטרה הגדולה יותר של AI מהימן. הערך של הארכיטקטורה לא נמצא באף רכיב בנפרד. הערך נובע מהאופן שבו החלקים מחזקים זה את זה.

AI מהימן הוא תוצאה של ארכיטקטורה, ולא תכונה יחידה.

הסרה (מחיקת השירות)

חשוב לזכור להסיר את השירות כשכבר לא צריך אותו. אחרי שמסיימים לבדוק את שרת הטלמטריה ואת האפליקציה, צריך למחוק את שירות Cloud Run ולהפסיק את החיוב עליו:

gcloud run services delete streaming-telemetry-server \
  --region us-central1 \
  --platform managed

אם צריך, מחליפים את us-central1 באזור שבו השתמשתם כשפרסתם את הפונקציה. מאשרים כשמוצגת בקשה.

אופציונלי: קובצי האימג' לקונטיינרים, החבילות ופריטי מידע קשורים מאוחסנים ב-Artifact Registry. כדי להימנע מחיובים על אחסון נתונים ישנים שלא נמצאים בשימוש, כדאי להסיר אותם כדי למנוע חיובים מיותרים. כדי להסיר נתונים מ-Artifact Registry, משתמשים ב-Cloud Console: Artifact Registry, בוחרים את המאגר שנוצר על ידי הפריסה ואז מוחקים את קובץ האימג' או את המאגר.

11. אתגרים

עכשיו, אחרי שהאפליקציה הבסיסית פועלת והבנתם את הרכיבים השונים, נסו להרחיב את העיצוב.

הצעות לאתגרים

• העברת חלק גדול יותר מהלוגיקה של האימון אל המכשיר
• שינוי הסימולציה כדי לתמוך בגשם או באחיזה מופחתת
• כדאי לבדוק איך כוונון מודלים או כוונון עדין יכול לשפר את הביצועים
• להתאים את הארכיטקטורה לדומיין אחר, כמו רפואה, ייצור או לוגיסטיקה

לדוגמה, כדאי לשקול את השאלות הבאות כשמיישמים את הלקחים שנלמדו ב-Lab הזה בדומיין אחר:

• מה המקבילה לטלמטריה של מירוצים, כלומר נתונים רציפים, בתחום אחר?
• אילו החלטות צריך לקבל באופן מיידי ואילו החלטות הן יותר אסטרטגיות?
• איזה סוג של מומחיות אנושית צריך לקודד?
• מה המשתמשים צריכים לראות כדי להאמין שאפשר לסמוך על המערכת?

האתגרים האלה מעודדים אתכם לחשוב מעבר לדוגמה של המירוץ ולזהות את תבנית העיצוב הרחבה יותר של מהימנות שמוצגת ב-Codelab הזה.

12. סיכום והשלבים הבאים

ב-codelab הזה יצרתם יותר מהדגמה של משחק מירוצים. יצרתם דוגמה קונקרטית לאופן שבו אפשר לתכנן מערכות AI שאפשר לסמוך עליהן.

התחלתם עם טלמטריה גולמית, המרתם אותה לפורמט שימושי עבור LLM, הפעלתם חשיבה רציונלית מבוססת-AI וחיזקתם את הפלט באמצעות הנחיות אנושיות מקודדות ומגבלות על התשובה. במהלך הקורס ראיתם שהמהימנות נובעת מהארכיטקטורה, ולא רק מהפלט של המודל.

מערכת AI מהימנה משלבת בדרך כלל:

• נתונים מובְנים בזמן אמת
• חשיבה רציונלית מבוססת-מודל
• מומחיות מוצפנת בתחום
• שכבות הגנה מפורשות
• עיצוב חוויית משתמש מחושבת

תרחיש המירוץ עזר להפוך את הרעיונות האלה לממשיים, אבל אפשר להשתמש באותה גישה בכל מקום שבו ההמלצות של ה-AI צריכות להיות עדכניות, מעשיות ומהימנות.