Intelligent Model Routing — בחירת מודל AI אוטומטית לפי מורכבות המשימה

מאת צוות מדיה דיל · 09.08.2026 · AI · 10 דק׳

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

צוות פיתוח טיפוסי מתחיל עם מודל אחד - בדרך כלל הכי חזק שיש - ומריץ עליו הכל: תשובה לשאלת "מה שעות הפעילות שלכם", וגם ניתוח משפטי מורכב של חוזה בן 40 עמודים. זה עובד, אבל זה יקר בצורה לא הגיונית: קריאה פשוטה שיכולה להיפתר במודל קטן ומהיר עולה פי כמה - ולוקחת פי כמה זמן - ממה שהיא צריכה. הבעיה מחריפה כשנפח הבקשות גדל: אלפי קריאות ביום, כשרובן פשוטות יחסית, אבל כולן "משלמות" את המחיר של המקרה הקשה ביותר. Intelligent Model Routing הוא הפתרון הארכיטקטוני לבעיה הזו: שכבת ביניים שמנתחת כל בקשה נכנסת ומחליטה - באופן דינמי, לא בקוד קשיח - לאיזה מודל לשלוח אותה.

מה זו בעצם בעיית הניתוב

ברגע שיש לכם יותר ממודל אחד זמין - למשל מודל "flash" מהיר וזול, מודל "בינוני" מאוזן, ומודל "פרו" חזק ויקר - נוצרת שאלה שלא הייתה קיימת קודם: איזה מודל מתאים לכל בקשה ספציפית? Routing נאיבי מדלג על השאלה הזו ופשוט קובע חוק סטטי: "כל הבקשות מהקטגוריה X הולכות למודל Y". זה עובד לזמן קצר, אבל לא מגיב לשונות בפועל בתוך אותה קטגוריה - שתי בקשות "תמיכה טכנית" יכולות להיות אחת טריוויאלית ואחת שדורשת הבנה עמוקה של מערכת מורכבת, ושתיהן "ילכו" לאותו מודל.

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

אסטרטגיות ניתוב נפוצות

יש כמה גישות מבוססות לבניית שכבת ניתוב, וכל אחת מתאימה לסוג אחר של מערכת:

• Classifier-based routing - מודל קטן וזול (או אפילו מודל קלאסי non-LLM) מסווג את הבקשה לרמת מורכבות (פשוט/בינוני/מורכב) לפני שהיא בכלל מגיעה למודל שמייצר תשובה. היתרון: מהיר וזול. החיסרון: דורש אימון או Prompt engineering נפרד לקלאסיפייר עצמו, ויש טעות סיווג לא מבוטלת בגבולות.
• Cascading (הסלמה מדורגת) - שולחים תמיד למודל הזול קודם, ובודקים את התשובה שלו לפי קריטריון ודאות (confidence) - ציון עצמי, אורך תשובה, נוכחות ביטויי היסוס. אם התשובה לא עוברת את הרף, מסלימים למודל החזק יותר. הגישה הזו טובה כשרוב הבקשות באמת פשוטות, כי אז רובן נפתרות בשלב הראשון בעלות מינימלית.
• Heuristic routing - חוקים מבוססי מטא-דאטה: אורך הפרומפט, מספר כלים (tools) שצריך להפעיל, נוכחות קוד או נתונים מבניים, זיהוי שפה. פשוט ליישום, אבל פחות מדויק ממודל סיווג אמיתי.
• Learned routing (Router model) - מודל ניתוב שאומן (Fine-tuned) במיוחד על היסטוריית בקשות ותוצאות, ולומד לחזות איזה מודל ייתן את התוצאה הטובה ביותר ביחס לעלות. זו הגישה המדויקת ביותר אך גם היקרה ביותר לבנייה ולתחזוקה.

דוגמה למבנה החלטה

{
  "request": { "tokens_in": 180, "has_code": false, "tool_calls_expected": 0 },
  "classifier_score": { "complexity": "low", "confidence": 0.91 },
  "routing_decision": {
    "model": "model-flash",
    "fallback_model": "model-pro",
    "escalation_trigger": "confidence < 0.6 OR user_flagged_unsatisfied"
  }
}

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

שכבת ניתוב בלי מדידה שוטפת היא ניחוש שקיבל שם מכובד. כדי לדעת אם הניתוב באמת עושה את עבודתו, צריך לעקוב אחרי כמה מדדים במקביל, לא רק אחרי "כמה חסכנו". שיעור הסלמה (Escalation rate) - כמה אחוז מהבקשות שהתחילו במודל הזול הגיעו בסוף למודל היקר - הוא אינדיקטור מרכזי: שיעור נמוך מדי עלול להעיד שסף ההסלמה גבוה מדי ומחמיץ מקרים שבאמת דורשים מודל חזק; שיעור גבוה מדי מעיד שהסיווג הראשוני לא באמת עוזר, וכל מה שהוא עושה הוא להוסיף שלב מיותר בדרך למודל שהיה נבחר ממילא. עלות ממוצעת לבקשה לאורך זמן, בפילוח לפי סוג בקשה, מראה אם החיסכון בפועל תואם את הציפייה התיאורטית. ושביעות רצון משתמשים בפילוח לפי המודל שטיפל בבקשה - אם בקשות שטופלו על ידי המודל הזול מקבלות דירוג נמוך משמעותית, זה סימן שהסיווג לא מדויק, לא בהכרח שהמודל הזול "גרוע".

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

מעבר לעלות: ניתוב לפי Latency ולפי יכולת

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

יש גם ניתוב לפי יכולת: לא כל מודל תומך באותו Context Window, לא כל מודל טוב באותה מידה ב-Function Calling מורכב, ולא כל מודל תומך בקלט מולטימודלי. שכבת ניתוב בוגרת בודקת גם את הדרישות הפונקציונליות של הבקשה - "יש כאן תמונה מצורפת" או "צריך לקרוא ל-6 כלים ברצף" - ומסננת החוצה מודלים שלא מתאימים, לפני שהיא בכלל שוקלת עלות.

ניתוב סטטי מול ניתוב לומד - מתי לעבור בין הגישות

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

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

איפה ממקמים את שכבת הניתוב בארכיטקטורה

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

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

טעויות נפוצות בבניית Router

• סיווג בינארי גס מדי - "קל / קשה" בלבד מפספס טווח רחב של מקרים. מומלץ לפחות 3-4 רמות, עם אפשרות אמיתית להסלמה.
• אין Fallback אמיתי - אם המודל הזול נכשל (Timeout, שגיאת API, תשובה ריקה), חובה שיהיה נתיב הסלמה אוטומטי למודל חזק יותר, לא רק ניסיון חוזר לאותו מודל.
• מדידה חד-פעמית - התנהגות משתמשים ותפלגות הבקשות משתנה עם הזמן. Router שלא עובר ריענון תקופתי (בין אם ידני ובין אם אוטומטי דרך Evals) יתיישן ויתחיל לקבל החלטות גרועות.
• התעלמות מ-Consistency - כשאותו משתמש מנהל שיחה רב-תורית, מעבר בין מודלים שונים באמצע יכול ליצור חוסר עקביות בסגנון ובזיכרון ההקשר. לעיתים עדיף "לנעול" מודל לכל אורך שיחה בודדת.

דוגמה מהשטח: מערכת תמיכה עם שלוש רמות מודל

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

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

ניתוב ופרטיות: מתי לא רק עלות קובעת

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

שאלות נפוצות

האם Model Routing מתאים גם למערכות קטנות בהיקפן?

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

האם ניתוב פוגע באיכות התשובות?

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

איך בודקים שהניתוב עובד כמו שצריך?

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

מה ההבדל בין Routing ל-Load Balancing רגיל?

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

האם צריך לבנות את זה בעצמנו או להשתמש בפתרון קיים?

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

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

תגיות: Model Routing · LLM Routing · AI Gateway · עלויות AI · Latency · Multi-model · Cascading

← חזרה לבלוג · צור קשר