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

רוב הצוותים מבצעים אופטימיזציה עבור ה-"happy path". הם בודקים את רמת הדיוק על מערכי נתונים נקיים, משפרים פרומפטים מול קלטים אידיאליים, ופורסים (deploy) בביטחון. ואז מגיעה תעבורת הפרודקשן. המודל מתחיל לסבול מ-timeouts בשעות השיא, מחזיר JSON לא תקין בערבי שישי, או פתאום עולה פי שלושה לאחר עדכון תמחור. פיצ'ר ה-AI שתכננתם בקפידה הופך לנטל, כי אף אחד לא תכנן למקרה שהמודל יקרוס.

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

התחילו עם אותות כשל ברורים

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

עקבו אחר timeouts של ה-API כאשר ה-endpoint של הספק נתקע. עקבו אחר שגיאות מגבלת קצב (rate limit) — בדרך כלל HTTP 429 — שמופעלות כשמגיעה תנועת תעבורה חריגה או כשמגיעים למכסות חודשיות. עקבו אחר פלט JSON לא תקין שגורם לקריסת צינור העיבוד (parser pipeline) שלכם. עקבו אחר תגובות ריקות או חלקיות שנראות כמו הצלחות בשכבת ה-HTTP אך אינן מכילות תוכן שמיש. עקבו אחר שיהוי (latency) גבוה שפוגע בחוויית הצ'אט לפני שמתרחש timeout קשיח. עקבו אחר חריגה מאורך ההקשר (context length overflow) כאשר קלט המשתמש גדל מעבר לחלון ההקשר של המודל. ועקבו אחר נסיגה באיכות, הכשל העדין מכולם: המודל מגיב, אך התשובות שלו סוטות מהנושא, הופכות לעמומות, או מתעלמות מהוראות הפורמט לאחר עדכון בצד הספק.

כל אחד מהאותות הללו אמור להפעיל תגובה שונה. timeout מצדיק ניסיון חוזר (retry). JSON לא תקין מצדיק מעבר למודל אחר. מגבלת קצב (rate limit) עשויה להצביע על כך שעליכם לפנות לספק אחר לגמרי.

התאימו את ה-fallback לזרימת העבודה (Workflow)

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

צ'אטבוטים זקוקים למהירות ולמומנטום שיחתי. משתמשים יסלחו על תשובה מעט גנרית, אך הם לא יסלחו על השהיה של חמש שניות. אם המודל הראשי שלכם מאט, עברו לגיבוי מהיר — לעיתים קרובות גרסה קטנה יותר מאותה משפחת מודלים, או הצעה בדרגת מהירות (speed-tier) של ספק אחר. שמרו על רצף הדיאלוג.

מערכות RAG זקוקות לדיוק. כבר שילמתם את מחיר השליפה (retrieval) — חיפוש וקטורי, reranking, ואולי סריקת רשת (web crawling). אם הגנרטור נכשל בכיבוד ההקשר שסופק, כל העבודה הזו הולכת לאיבוד. עברו למודל הידוע במעקב מדויק אחר הוראות ובהבנת הקשר ארוך (long-context comprehension), גם אם הוא איטי יותר.

כלי קוד זקוקים ללוגיקה. מפתחים רוצים תחביר נכון וקריאות API תקינות על פני הסברים רהוטים. אם המודל הראשי מתחיל להזות (hallucinating) פונקציות או לדלג על מקרי קצה, עברו למודל שעבר fine-tuning על קוד. קבלו latency גבוה יותר בתמורה לפלט מוכן לקומפילציה.

חילוץ JSON זקוק למבנה. יצירה מובנית היא שבירה. סוגריים חסרים או גרשיים שלא עברו escaping כהלכה יהרסו את כתיבת הנתונים למסד הנתונים בהמשך הדרך. אם המודל הראשי שלכם סוטה מהעמידה בסכימה (schema adherence), נסו פעם אחת נוספת, ואז עברו למודל עם אמינות פורמט גבוהה. באופן מוזר, מודלים קטנים יותר המכווננים לצייתנות (obedience) לרוב מציגים ביצועים טובים יותר ממודלים יצירתיים ענקיים במשימה ספציפית זו.

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

הכירו את המגבלות שלכם לפני שאתם מחליפים

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

לפני שאתם מעלים מודל כלשהו לסטטוס fallback, בצעו לו אודיט (audit) מול שישה גורמים.

  • יכולת המודל: האם הוא באמת מסוגל להתמודד עם סוג הפרומפט, או שהוא ייכשל בצורה אחרת?
  • תמיכה בשפות: הגיבוי שלכם אולי יצטיין באנגלית, אך עלול להזות (hallucinate) בהינדי, ספרדית או יפנית.
  • גודל חלון ההקשר (Context window): אם הקלט שלכם הוא 50,000 טוקנים, fallback עם מגבלה של 16,000 טוקנים יקצץ את הטקסט וישמיד את המשמעות בשקט.
  • שיהוי (Latency): ספקים מסוימים מהירים יותר מאחרים באופן עקבי עבור האזור שלכם.
  • עלות לבקשה: קבעו תקרה קשיחה. דעו מה עלות ה-fallback בעומס שיא.
  • אמינות הפלט: האם הוא יעקוב אחר פורמט הפלט בכל פעם, או רק בימי שלישי?

ארבעה דפוסי fallback שעובדים

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

Retry fallback (ניסיון חוזר). עבור שגיאות רשת חולפות והשבתות קצרות של ספקים, נסו שוב את אותו המודל עם exponential backoff. אל תנסו שוב במקרה של פלט לא תקין או חריגה מגודל ההקשר — שליחת אותו פרומפט גרוע פעמיים כמעט אף פעם לא עוזרת.

Equivalent fallback (מודל מקביל). כאשר הספק העיקרי שלכם למטה או חווה הגבלת קצב (throttled), עברו למודל דומה מספק אחר. מעבר ממודל frontier אחד למודל אחר מאותה קטגוריה בערך דורש בדרך כלל כתיבה מחדש מינימלית של הפרומפט ושומר על איכות הפלט.

Cheaper fallback (מודל זול יותר). שמרו מודל בעלות נמוכה למשימות לא קריטיות. אם האופציה הזולה מתקשה, הפחיתו את רמת השירות (degrade) בצורה הדרגתית במקום לבזבז טוקנים יקרים על עבודה בעלת ערך נמוך.

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

הטמיעו את הלוגיקה בארכיטקטורה שלכם

אל תפזרו את לוגיקת ה-fallback על פני עשרות בלוקים של try-catch בקוד האפליקציה. התייחסו לניתוב (routing) כאל תשתית. בנו שכבת middleware שממפה סוגי משימות לרשימות מסודרות של מודלים, כאשר לכל אחד סף timeout, מדיניות ניסיון חוזר (retry policy) ו-circuit breaker משלו.

עקבו אחר אירועי fallback כשיטות מדידה (metrics) מרכזיות. שיעורי שגיאות אומרים לכם מתי מודל למטה; שיעורי fallback אומרים לכם מתי מודל אינו מתאים למשימה. אם המערכת שלכם עוברת ל-fallback ב-30 או 40 אחוז מהזמן, המודל העיקרי שלכם אינו מותאם היטב לעומס העבודה. זהו סימן להערכה מחדש של בחירת המודל, ולא רק של הטיפול בשגיאות.

קבעו תקציבים מפורשים. fallback לעולם לא צריך להיות "צ'ק פתוח". אם אתם מעלים את הבקשה למודל פרימיום תחת עומס, הגבילו את מספר הבקשות המועלות לדקה. הגנו על הארנק שלכם באותה הקפדה שבה אתם מגנים על זמן הפעילות (uptime) שלכם.

המבחן האמיתי

אתם לא בונים עבור הדמו. אתם בונים עבור יום שלישי בשעה 15:00, כשה-API איטי, המשתמש ממתין, וצוות הכספים בדיוק שאל למה החשבון של ה-AI הוכפל. אסטרטגיית fallback בשלה שומרת על המוצר יציב, שומרת על חווית משתמש עקבית ושומרת על עלויות צפויות.

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

Source: How to Design AI Model Fallback Rules for Multi-Model Apps

Community: GyaanSetu AI בטלגרם