מעבר למודל חדש

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

סקירה כללית על תהליך ההעברה

העברה מלאה של מודל כוללת ארבעה שלבים:

1. בידוד השינויים: יוצרים גרסה שלא ניתנת לשינוי של אפליקציית הנציג בסביבת הייצור, או מייצאים ומייבאים את האפליקציה לסביבת בדיקה נפרדת.
2. עדכון הגדרות המודל: שינוי המודל הגלובלי, בדיקת שינויים במודל של סוכני המשנה והכלים, ואימות הגדרות הניסיון החוזר והחלופות באמצעות המסוף, קובצי התצורה שיוצאו או ה-API בארכיטקטורת REST.
3. הערכה ושיפור של הביצועים: בודקים את השיחות בסימולטור, מריצים הערכות באמצעות Find issues with AI ומשתמשים ב-AI Co-Builder: Arc כדי לשפר את ההוראות עד שמדדי האיכות מגיעים לסף היעד.
4. פריסה בשלבים: שומרים את ההגדרות המאומתות כגרסה ומשתמשים בפיצול תנועה בערוץ הפריסה כדי להעביר את התנועה בזמן אמת בהדרגה, תוך כדי מעקב אחרי התוצאות.

שלב 1: מבודדים את השינויים

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

שימוש בגרסאות באותה אפליקציית נציג

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

כדי לשמור תמונת מצב בסיסית של ההגדרות הנוכחיות:

1. פותחים את מסוף CX Agent Studio ובוחרים את אפליקציית הנציג.
2. פותחים את החלונית Versions בכלי ליצירת סוכנים.
3. לוחצים על + יצירת גרסה.
4. מזינים שם תיאורי, כמו pre-model-migration-baseline, ותיאור אופציונלי, ולוחצים על Create.
5. פותחים את הכרטיסייה Deploy ומוודאים שערוצי הפריסה הפעילים מפנים לגרסה שלא ניתנת לשינוי (מסומנת בתג Live בחלונית Versions) ולא לטיוטה שניתנת לשינוי.

ייצוא וייבוא לסביבת ארגז חול (sandbox)

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

1. פותחים את מסוף CX Agent Studio ובוחרים את הפרויקט.
2. ברשימת האפליקציות של הנציג, פותחים את התפריט של האפליקציה ולוחצים על Export.
3. אם סביבת ה-Sandbox משתמשת ביחסי תלות חיצוניים שונים, כמו מאגרי נתונים או נקודות קצה של שירותים, מחלצים את הארכיון שהורדתם, מעדכנים את הקובץ environment.json ודוחסים את הספרייה לארכיון ZIP. למידע נוסף, ראו קובץ סביבה.
4. בפרויקט בארגז החול או באפליקציית הבדיקה, פותחים את תפריט האפליקציה, בוחרים באפשרות ייבוא ומעלים את הארכיון.
5. אופציונלי: מייצאים את מקרי הבדיקה להערכה מאפליקציית המקור ומייבאים אותם לאפליקציית Sandbox כדי להריץ בדיקות רגרסיה.

שלב 2: עדכון הגדרות המודל

עיינו ברשימת המודלים הנתמכים כדי לבחור מודל Gemini שמתאים למודל של הנציג (טקסט או קול). אפשר לעדכן את הגדרות המודל באמצעות המסוף, קובצי תצורה שיוצאו או ה-API בארכיטקטורת REST.

עדכון מודלים באמצעות המסוף

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

1. שינוי המודל הגלובלי:
   1. בכלי לפיתוח סוכנים, פותחים את Settings כדי לראות את הגדרות האפליקציה של הסוכן.
   2. בקטע Basic > Interactions, בוחרים את מודל היעד בשדה Global model. המודל הזה משמש כברירת המחדל לכל הנציגים באפליקציה שלא מציינים ביטול.
2. בודקים את ההגדרות של המודלים של הסוכן הראשי וסוכני המשנה:
   1. בכלי לפיתוח נציגים, פותחים את התפריט בסרגל הכותרת של נציג הבסיס ולוחצים על Edit config כדי לראות את הגדרות הנציג.
   2. בודקים את השדה Model. אם הסוכן משנה את המודל הגלובלי, בוחרים את מודל היעד או מבטלים את השינוי כדי שהסוכן יקבל את המודל הגלובלי.
   3. חוזרים על הבדיקה הזו לכל סוכן משנה בהיררכיית הסוכנים.
3. בודקים את המודלים של הכלים במאגר הנתונים:
   1. אם האפליקציה משתמשת בכלים של מאגרי נתונים, פותחים את החלונית Tools ובוחרים כל כלי של מאגר נתונים.
   2. מרחיבים את הקטע Advanced > Modalities ומוודאים שהאפשרויות Rewriter model ו-Summarization model נבחרו גם להגדרות של Text וגם להגדרות של Voice.
4. בדיקת ההגדרות של ניסיונות חוזרים ושל חלופות:
   1. פותחים את ההגדרות של אפליקציית הנציג ועוברים אל Basic > Behavior > Fallback behavior.
   2. מוודאים שההגדרות של Retries,‏ Agent response ו-Fallback מתאימות לטיפול בשגיאות במהלך יצירת המודל.

הערה: אם אתם מעבירים סוכן קולי מ-gemini-composite-v1 ל-gemini-composite-v2, כדאי גם לבדוק את ההנחיה של סגנון הדיבור ולהמיר תגים מוטבעים בסוגריים מרובעים לסוגריים זוויתיים. מידע נוסף זמין במאמר מעבר מ-Composite V1.

עדכון מודלים באמצעות קובצי תצורה שיוצאו

אם אתם מנהלים את אפליקציית הנציג באמצעות ניהול גרסאות או צינורות עיבוד נתונים של CI/CD, אתם יכולים לעדכן את הגדרות המודל בארכיון שייצאתם ולייבא מחדש את החבילה:

1. מחלצים את ארכיון ה-ZIP של אפליקציית הנציג שייצאתם.

2. בכל ספריית סוכן ב-agents/<var>AGENT_NAME</var>/, פותחים את הקובץ agents/<var>AGENT_NAME</var>/<var>AGENT_NAME</var>.yaml ומעדכנים את השדה modelSettings.model למזהה מודל היעד:

   displayName: "AGENT_NAME"
   modelSettings:
     model: "MODEL_ID"
   instruction: "agents/AGENT_NAME/instruction.txt"
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫<var>AGENT_NAME</var>: השם המוצג של הנציג.
   • ‫<var>MODEL_ID</var>: המזהה של מודל היעד, למשל gemini-3.5-flash או gemini-composite-v2.

3. דוחסים את תיקיית השורש לארכיון ZIP ומייבאים את הארכיון המעודכן ל-CX Agent Studio.

עדכון מודלים באמצעות ה-API בארכיטקטורת REST

אתם יכולים לעדכן באופן פרוגרמטי את ModelSettings באפליקציית הסוכן ובסוכנים ספציפיים באמצעות ה-API בארכיטקטורת REST של CX Agent Studio.

לפני ששולחים קריאה ל-API, צריך לאסוף את הערכים הבאים:

• ‫<var>PROJECT_ID</var>: מזהה הפרויקט ב- Google Cloud .
• ‫<var>LOCATION_ID</var>: האזור של אפליקציית הנציג, למשל us או eu.
• ‫<var>APP_ID</var>: מזהה המשאב של אפליקציית הנציג.
• ‫<var>AGENT_ID</var>: מזהה המשאב של סוכן ברמה הבסיסית או סוכן משנה ספציפי.
• ‫<var>MODEL_ID</var>: מזהה מודל היעד, למשל gemini-3.5-flash.

כדי לעדכן את המודל הגלובלי שמוגדר כברירת מחדל לאפליקציית הנציג, שולחים בקשת PATCH ל-method‏ projects.locations.apps.patch עם updateMask=modelSettings:

curl -X PATCH \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json" \
  "https://ces.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION_ID/apps/APP_ID?updateMask=modelSettings" \
  -d '{
    "modelSettings": {
      "model": "MODEL_ID"
    }
  }'

כדי לעדכן את שינוי המודל בסוכן ראשי או בסוכן משנה ספציפי, שולחים בקשת PATCH ל-method‏ projects.locations.apps.agents.patch עם updateMask=modelSettings:

curl -X PATCH \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json" \
  "https://ces.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION_ID/apps/APP_ID/agents/AGENT_ID?updateMask=modelSettings" \
  -d '{
    "modelSettings": {
      "model": "MODEL_ID"
    }
  }'

שלב 3: הערכה ושיפור של ביצועי הנציג

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

בדיקה אינטראקטיבית בסימולטור

מריצים בדיקות תקינות ראשוניות בסימולטור Preview agent:

1. פותחים את הסימולטור בכלי לפיתוח סוכנים ולוחצים על התחלת שיחה חדשה.
2. בודקים אינטראקציות מייצגות של טקסט או אודיו ומוודאים שהסוכן פועל לפי ההוראות, מפעיל כלים עם ארגומנטים תקינים ועובר בין סוכני משנה כצפוי.
3. מרחיבים את פרטי המעקב של כל שלב כדי לבדוק את זמן האחזור של השלב, את הקלט והפלט של הכלי ואת התגובות הגולמיות בפורמט JSON.
4. אופציונלי: כדי להוסיף שיחה לחבילת הרגרסיה, פותחים את תפריט הסימולטור ובוחרים באפשרות Save as golden.

הרצת הערכות ואבחון בעיות באמצעות AI

אתם יכולים להשתמש בהערכות כדי למדוד את הביצועים במקרי הבדיקה של גרסת הזהב, התרחיש והסימולציה, ולהשוות את התוצאות לגרסת הבסיס:

1. בחלק העליון של הכלי לפיתוח סוכנים, לוחצים על הערכה.
2. בוחרים את מקרי הבדיקה שכוללים את חוויות השימוש ההכרחיות ואת גרסאות הנציג, ולוחצים על Run selected.
3. בתיבת הדו-שיח של ההרצה, בוחרים באפשרות איתור בעיות באמצעות AI, מגדירים את מספר ההרצות ל-3 או יותר כדי לקבל ניתוח אופטימלי של ה-AI, ואז מתחילים את ההרצה. מידע נוסף זמין במאמר שימוש ב-AI לשיפור מקרי הבדיקה.
4. כשההרצה מסתיימת, בודקים את מדדי ההערכה – כולל נכוֹנוּת הכלי, התאמה סמנטית, שביעות הרצון של המשתמש מהיעד, השלמת מטרות עסקיות, הזיות והשלמת המשימה – ובודקים אם יש פניות שנכשלו או יעדים שלא הושלמו.
5. בדף התוצאות, לוחצים על Ask Gemini כדי לבדוק את ה-loss_report שנוצר, לסכם את שורש הבעיה בכל ההרצות שנכשלו ולראות הצעות לתיקון ההוראות או ההגדרות.

הוראות לטיפוס על גבעה עם AI Co-Builder: קשת

אם תוצאות ההערכה מראות רגרסיות או שינויים בהתנהגות במודל היעד, השתמשו ב-AI Co-Builder: Arc ובעוזר ההערכה כדי לשפר את ההנחיות באופן איטרטיבי:

1. לוחצים על Arc בחלק העליון של הכלי ליצירת סוכנים כדי לפתוח את AI Co-Builder.
2. לוחצים על בחירת הקשר ובוחרים את הנציגים או ההוראות הספציפיים שצריך לשנות, או מצרפים תמלילים של שיחות שנכשלו ודוחות על הפסדים.
3. מנחים את Arc לעדכן את ההוראות או את תיאורי הכלים כדי לטפל בכשלים שנצפו, תוך שמירה על ההתנהגות במקרי בדיקה אחרים. אתם יכולים גם להשתמש בתכונה ארגון מחדש של ההוראות כדי לארגן את ההוראות בפורמט מובנה.
4. מריצים מחדש את חבילת ההערכה אחרי שמיישמים את התיקונים, וחוזרים על הפעולה עד שכל מקרי הבדיקה עומדים בקריטריונים למעבר. הנחיות נוספות מפורטות במאמר שיטות מומלצות להערכות ולטיפוס על גבעות.

שלב 4: פריסה בשלבים עם חלוקת תנועה

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

יצירת גרסה לסוכן שהועבר

שומרים תמונת מצב שלא ניתנת לשינוי של ההגדרות המאומתות:

1. אם בדקתם את השינויים באפליקציה נפרדת בארגז חול, ייצאו את חבילת האפליקציה המאומתת וייבאו אותה לאפליקציה בסביבת הייצור.
2. באפליקציה בסביבת הייצור, פותחים את החלונית Versions ולוחצים על ‎+ Create version.
3. מזינים שם ותיאור שמזהים את מודל היעד, למשל v2-gemini-3-5-flash, ולוחצים על Create.

העברה הדרגתית של תנועה בזמן אמת

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

1. לוחצים על הכרטיסייה Deploy בחלק העליון של הכלי לפיתוח סוכנים ובוחרים את ערוץ הפריסה.
2. בקטע Agent version, לוחצים על Add version ומוסיפים גם את גרסת הייצור הבסיסית וגם את הגרסה המועמדת להעברה.
3. מקצים אחוז תנועה קטן לגרסה המועמדת (לדוגמה, ‎90% ‎ לגרסת הבסיס ו-‎10% ‎ לגרסה המועמדת, סה"כ 100%), ואז שומרים את הגדרות הערוץ. אפשר גם להגדיר את experimentConfig.versionRelease.trafficAllocations באופן פרוגרמטי באמצעות ה-API בארכיטקטורת REST.
4. מעקב אחרי הביצועים בזמן אמת בגרסאות השונות:
   • בודקים את נפח הסשנים, זמן האחזור ושיעורי ההעברה לטיפול ברמה גבוהה יותר בלוח הבקרה למעקב.
   • בודקים את התמלילים בזמן אמת בהיסטוריית השיחות.
   • מריצים שאילתות על יומני האינטראקציות שיוצאו לפי app_version_id ב-BigQuery כדי להשוות בין שיעורי ההפעלה והתוצאות של הכלים בגרסאות השונות. במאמר ניתוח ביצועי הגרסאות ב-BigQuery מופיעות דוגמאות לשאילתות SQL.
5. כשהיציבות והאיכות של הגרסה שהועברה יאושרו, אפשר להגדיל את אחוז התנועה שמועברת אליה בשלבים, עד שהיא תטפל ב-100% מהתנועה בזמן אמת. אם אתם מזהים בעיות לא צפויות במהלך ההשקה, אתם יכולים להפנות 100% מהתנועה בחזרה לגרסת הבסיס או לשחזר את הגרסה הקודמת בחלונית Versions.