ניתוב מודלי AI: המרוץ עובר ממודל גדול לחיסכון תפעולי

התשובה הקצרה: המודל הטוב ביותר הוא לא תמיד הבחירה הנכונה

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

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

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

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

כלכלת ה-AI נמדדת ברמת התהליך, לא במחיר הטוקן

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

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

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

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

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

איך נראית ארכיטקטורת ניתוב ארגונית

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

תהליך טיפוסי יכול לפעול כך:

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

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

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

שכבת הערכה: מאגר תרחישים עסקיים אמיתיים שבודק איכות, עקביות, בטיחות ועלות. Benchmark כללי אינו תחליף ל-evals המבוססים על עבודת הארגון.

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

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

ללא שלוש השכבות האלה, multi-model הוא בעיקר שם מרשים לריבוי ספקים. הוא אינו מערכת שניתן לנהל בביטחון.

מודלים פתוחים משנים את מאזן הכוחות, אך אינם פתרון קסם

מודלי open-weight משתפרים ומאפשרים להריץ חלק מהעבודה קרוב לנתונים הארגוניים. לפעמים הם גם מהירים ומדויקים יותר ממודל כללי גדול, במיוחד לאחר התאמה למשימה מוגדרת.

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

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

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

Anthropic, OpenAI ו-Microsoft הן רכיבים, לא אסטרטגיה

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

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

Microsoft Copilot הוא כלי תשתיתי סביר מאוד לארגונים שכבר פועלים עמוק בתוך סביבת Microsoft. קצב החידושים שלו היה לעיתים איטי יחסית לשחקנים ממוקדים יותר, אף שבתקופה האחרונה ניכר שיפור. Copilot Studio מתאים לפיתוח סוכנים בסביבת Microsoft, ולצדו נכנסים לארגונים כלים גמישים כמו n8n, שבעבר נתפסו כפחות מתאימים לחברות גדולות.

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

אדם בלולאה צריך להיות מנגנון הסלמה, לא צוואר בקבוק

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

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

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

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

הטכנולוגיה לבדה לא תייצר ניתוב נכון

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

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

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

שני נתיבי אימוץ שחייבים להתקדם יחד

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

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

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

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

תוכנית פעולה למנהלים

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

1. לבחור שלושה עד חמישה תהליכים בעלי נפח גבוה ועלות מדידה.
2. למפות בכל תהליך את רמת הסיכון, סוגי המידע ונקודות שיקול הדעת.
3. לבנות סט הערכה המבוסס על מקרים אמיתיים ותוצאות רצויות.
4. להשוות לפחות מודל קטן, מודל מתקדם ומודל open-weight מתאים.
5. להגדיר כללי ניתוב, fallback והסלמה אנושית.
6. למדוד עלות לתוצאה תקינה ולא רק צריכת טוקנים.
7. להקים ממשל גרסאות והרשאות לפני הרחבת השימוש.
8. לפתח יכולת פנימית שתוכל להחליף ספקים ולעדכן מדיניות.

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