לבנות או לקנות היא לא שאלה בינארית. יש חמישה מסלולים: API של מודל חזית, מודל בעל משקלים פתוחים על נקודת קצה מנוהלת, מודל פתוח שעבר כוונון, מודל שנבנה מאפס, והאפשרות שרוב הצוותים שוכחים — לא לפתור את זה עם LLM בכלל. הבחירה נקבעת בשלוש עדשות בלבד: עלות בנפח הצפוי, תקרת היכולת הנדרשת, וחשיפה רגולטורית. ההמלצה המעשית לרוב הארגונים היא להתחיל בקנייה, לבנות שכבת הפשטה מהיום הראשון, ולשקול בנייה רק אחרי שיש נתוני שימוש אמיתיים.
חמישה מסלולים, לא שניים
המסגור הרגיל של הדיון, בנייה מול קנייה, מייצר החלטות גרועות כי הוא מסתיר שלוש אפשרויות ביניים שבהן נמצא רוב הערך.
| מסלול | מה זה בפועל | מתי זה נכון |
|---|---|---|
| API של מודל חזית | קריאה לספק מסחרי, בלי תשתית משלכם | משימה רחבה, נפח בינוני, צוות בלי עומק ML |
| מודל פתוח מנוהל | משקלים פתוחים על נקודת קצה של ספק תשתית | צורך בשליטה על גרסאות ובעלות צפויה |
| מודל פתוח מכוונן | אימון נוסף על הדאטה שלכם למשימה צרה | משימה צרה וחוזרת, מעל עשרת אלפים דוגמאות מתויגות |
| מודל מאפס | אימון מלא, צוות מחקר ייעודי | כמעט אף פעם. רק אם המודל הוא המוצר עצמו |
| בלי LLM | חוקים, חיפוש, מודל סטטיסטי קלאסי | כשהמשימה דטרמיניסטית וניתנת להגדרה מלאה |
שלוש העדשות שקובעות
עלות בנפח הצפוי. לא בנפח היום, אלא בנפח שאתם מתכננים בעוד שנה. חישוב מהיר: כמה יחידות עבודה בחודש, כפול עלות ליחידה במסלול הקנייה, מול עלות ההנדסה והתשתית הקבועה של מסלול הבנייה. פירטנו את שיטת החישוב במאמר על עלות הבעלות של פיצ׳ר LLM.
תקרת יכולת. אם המשימה דורשת הסקה מרובת שלבים, שפה נדירה או ידע רחב, מודל קטן מכוונן לא יגיע לשם ולא משנה כמה תאמנו אותו. אם המשימה היא סיווג לשבע קטגוריות, מודל חזית הוא בזבוז.
חשיפה רגולטורית. כשהדאטה חייבת להישאר בגבולות מדינה או ברשת סגורה, מסלולי הקנייה מצטמצמים מיד. זו העדשה היחידה שיכולה לפסול מסלול מראש, ולכן כדאי לבדוק אותה ראשונה ולא אחרונה. הקשר בין סוגי מידע להרשאות מפורט במאמר על סיווג מידע ארגוני לפני הכנסתו ל-LLM.
מתי כוונון מודל באמת משתלם
כוונון הוא המסלול שהכי הרבה צוותים בוחרים מוקדם מדי. הוא הופך משתלם כשמתקיימים כל התנאים הבאים יחד, לא חלקם:
- המשימה צרה, חוזרת על עצמה ומוגדרת היטב, ולא משתנה כל רבעון.
- יש בידיכם אלפים רבים של דוגמאות מתויגות באיכות טובה, מהפרודקשן שלכם ולא ממאגר גנרי.
- עלות ה-API או ההשהיה הפכו לאילוץ הכובל בפועל, ולא לחשש תיאורטי.
- יש בצוות מי שיתחזק את המודל, ימדוד סחיפה ויאמן מחדש כשההתפלגות תשתנה.
אם אחד מהתנאים חסר, כוונון יוסיף עלות תחזוקה קבועה בלי להחזיר אותה. המסלול הנפוץ שמצליח הוא הפוך: להישאר על API, לאסוף דאטה מהפרודקשן באופן שיטתי, ולחזור לשאלה אחרי כתשעים יום של שימוש אמיתי, כשיש מספרים במקום הערכות.
שכבת ההפשטה: ההחלטה היחידה שכדאי לקבל מיד
אין צורך להחליט על המסלול ביום הראשון, אבל כן צריך להחליט לא להתחייב. שכבת הפשטה דקה בין הקוד לספק המודל היא הביטוח הזול ביותר בפרויקט:
| מה השכבה מכילה | למה זה חשוב |
|---|---|
| ממשק אחיד לקריאה למודל | החלפת ספק היא שינוי בקובץ אחד, לא בכל בסיס הקוד |
| ניתוב לפי סוג משימה | מאפשר לשלוח משימות זולות למודל זול בלי לשכתב לוגיקה |
| לוגים אחידים של קלט, פלט ועלות | בלי זה אין נתונים להחליט לפיהם בעוד שלושה חודשים |
| שכבת ולידציה על הפלט | מאפשרת להחליף מודל בלי לשנות את חוזה הפלט |
העלות שלא נמצאת בגיליון
השוואת בנייה מול קנייה שנעשית בגיליון אלקטרוני נוטה להשוות מחיר רישוי מול עלות מחשוב, ולהחמיץ שלוש עלויות שמכריעות בפועל: זמן ההגעה לשוק, עלות ההחמצה בזמן שהצוות בונה במקום למכור, ועלות התחזוקה לאורך שנים. פרסומים מ-2026 מדווחים שארגונים שבנו יכולת AI מותאמת בלי לתקף אותה מראש מול פתרון מדף איבדו לוח זמנים ממושך לפני שהבינו שהכיוון שגוי.
מהצד השני, קנייה שנמשכת לנצח יוצרת תלות בספק אחד ומסירה מהארגון את היכולת לשפר את מה שמייחד אותו. האיזון המעשי הוא כמעט תמיד היברידי: לקנות את הבסיס, לבנות מעליו את השכבה שבה נמצא היתרון התחרותי — הדאטה, האחזור, חוקי העסק והממשק — ולא את המודל עצמו.
סדר הפעולות המומלץ
- הגדירו את יחידת העבודה ואת קריטריון ההצלחה לפני שבוחרים טכנולוגיה.
- בדקו את העדשה הרגולטורית. אם היא פוסלת מסלולים, כל השאר מתייתר.
- הריצו הוכחת היתכנות על פתרון מדף, גם אם אתם משוכנעים שתבנו. היא זולה ומייצרת בסיס השוואה.
- בנו שכבת הפשטה ולוגים מהיום הראשון.
- חזרו להחלטה אחרי תשעים יום, עם עלות ליחידה, שיעור הצלחה והתפלגות משימות אמיתית.
הליווי הזה, מהגדרת יחידת העבודה ועד בחירת המסלול, הוא בדיוק מה שאנחנו עושים בשירות הטמעת בינה מלאכותית.
שאלות נפוצות
מה ההבדל המעשי בין כוונון מודל לבין אחזור מבסיס ידע?
אחזור מוסיף מידע עדכני לתוך הפרומפט בזמן הריצה, וכוונון משנה את התנהגות המודל עצמו. לצורך של ידע ארגוני שמשתנה, אחזור כמעט תמיד נכון יותר. כוונון מתאים לשינוי סגנון, פורמט או משימה צרה, לא להזרקת עובדות.
כמה דוגמאות מתויגות באמת צריך לכוונון?
סדר הגודל המקובל הוא אלפים רבים של דוגמאות איכותיות למשימה צרה. הקובע הוא לא הכמות אלא האיכות והייצוגיות: אלף דוגמאות נקיות מהפרודקשן שלכם שוות יותר מעשרות אלפים סינתטיות.
האם שכבת הפשטה לא מוסיפה מורכבות מיותרת?
שכבה דקה, שרק מאחדת את הקריאה, הלוגים והוולידציה, עולה ימים ספורים של פיתוח. העלות של היעדרה מתגלה ביום שבו צריך להחליף ספק, לנתב משימות זולות למודל זול, או להסביר מאיפה הגיעה חשבונית.
מתי בכלל נכון לאמן מודל מאפס?
כמעט אף פעם, אלא אם המודל עצמו הוא המוצר שאתם מוכרים, או שיש לכם דאטה ייחודי בהיקף עצום בתחום שמודלים כלליים לא מכסים. עבור רוב הארגונים זו החלטה שעלותה עולה בסדרי גודל על התועלת.
איך יודעים שהגיע הזמן לעבור מקנייה לבנייה?
כששלושה תנאים מתקיימים יחד: העלות החודשית של הקנייה חצתה את עלות ההנדסה והתחזוקה השנתית של החלופה, המשימה התייצבה ולא משתנה, ויש נתוני פרודקשן שמאפשרים לאמן ולמדוד. שניים מתוך שלושה אינם מספיקים.
