Semantic Model Router — בחירת מודל לפי משמעות הבקשה

מאת צוות מדיה דיל · 12.08.2026 · Model Economics · 6 דק׳

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

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

למה כללים סטטיים נכשלים בניתוב

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

איך בונים ניתוב לפי משמעות בפועל

הגישה המעשית מבוססת על ייצוג וקטורי (embedding) של כוונת הבקשה, לא של הטקסט הגולמי שלה. שלושה מרכיבים עיקריים:

• מיפוי כוונות מראש — אוסף דוגמאות מייצגות לכל רמת מורכבות (משימה פשוטה, בינונית, מורכבת), שממנו נגזר embedding ייחוס לכל קטגוריה.
• השוואת דמיון סמנטי בזמן ריצה — כל בקשה נכנסת מומרת ל-embedding ומושווית מול קטגוריות הייחוס באמצעות cosine similarity, לא מול מילות מפתח נוקשות.
• סיגנלים משלימים — היסטוריית הלקוח (האם יש לו הזמנה פעילה, מנוי premium), הקשר השיחה (האם זו פנייה ראשונה או המשך של שיחה שכבר הסלימה), ומצב המערכת (האם יש תקלה ידועה שמשפיעה על נושא הפנייה).

שילוב הסיגנלים האלה נותן ניתוב שמבוסס על תוכן אמיתי במקום קירוב גס. חשוב לזכור שגם embedding-based routing לא חף מטעויות — הוא צריך רף confidence, ומתחת לרף הזה עדיף לנתב שמרנית למודל חזק יותר, בדיוק כמו שמתואר בגישת ה-fallback שמוזכרת ב-Small Models as Gatekeepers.

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

עדכון מתמשך של מפת הכוונות

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

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

כדי לתת סדר גודל: ארגון עם 200,000 בקשות בחודש ומאגר דוגמאות ייחוס של כמה מאות בלבד יכול להגיע לרמת דיוק ניתוב סבירה, אבל שדרוג ל-2,000-3,000 דוגמאות מתויגות בקטגוריות הגבוליות בדרך כלל משפר את שיעור הניתוב הנכון בכמה נקודות אחוז נוספות — וכל נקודת אחוז כזו, בהיקף של מאות אלפי בקשות, שווה בפועל אלפי דולרים בחודש בין ניתוב יתר למודל יקר מדי לבין ניתוב חסר שגורם לתשובות באיכות נמוכה. ההשקעה בהרחבת מאגר הדוגמאות היא לרוב אחת הפעולות בעלות ה-ROI הגבוה ביותר בכל הפרויקט.

מתי ניתוב סמנטי לא שווה את המורכבות

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

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

תגיות: Semantic Router · Model Routing · Embeddings · Intent Classification · Model Economics

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