בניית 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.

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 של השידור

שרת הטלמטריה פולט עכשיו נתוני טלמטריה מסימולציה באמצעות אירועים שנשלחים מהשרת (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 לספק תגובה שמתאימה לדמות.

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

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

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

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 צריכות להיות עדכניות, מעשיות ומהימנות.