מהו AI Engineering

העבודה: לבנות מערכת אמינה מרכיב שאינו אמין

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

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

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

מה זה לא: אימון מודלים

הבלבול הזה עולה כסף למי שמתכנן הסבה. Data Science ולמידת מכונה עוסקים באימון מודל — נתונים, פיצ׳רים, מדדי דיוק, רקע סטטיסטי. AI Engineering לוקח מודל שכבר קיים ובונה סביבו מערכת.

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

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

חמשת החלקים שכל מערכת מגיעה אליהם

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

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

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

רוב האיכות נקבעת בשליפה, לא במודל

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

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

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

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

כמה להביא, וכמה להעביר הלאה

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

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

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

ההקשר הוא תקציב, לא מיכל

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

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

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

הגבול בין המודל לקוד

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

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

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

{
  "amount_ils":   {"type": ["number", "null"]},
  "amount_found": {"type": "boolean"},
  "source_quote": {"type": ["string", "null"],
                   "description": "הקטע המדויק מהמקור"}
}

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

מתי ניסיון חוזר עוזר ומתי הוא בזבוז

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

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

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

כשהמערכת פועלת ולא רק עונה

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

• הגדרת כלי היא פרומפט, לא תיעוד API. המודל רואה רק את השם, התיאור ותיאורי הפרמטרים. תיאור שנכתב למפתח — "שולח בקשת POST ל-endpoint" — לא עוזר לו להחליט מתי לקרוא.
• כל כלי שמשנה מצב חייב להיות בטוח לקריאה כפולה. סוכנים מנסים שוב: אחרי timeout, אחרי תשובה שלא הגיעה, וכשהמודל פשוט לא בטוח. מפתח ייחודיות שנוצר בקוד שלכם ולא על ידי המודל הוא מה שמונע חיוב כפול.
• שגיאה היא תשובה, לא קריסה. חריגה שלא נתפסה עוצרת את הסוכן באמצע עם צעדים שכבר בוצעו. ההודעה עצמה היא גם פרומפט: "Error 400" גורם לניסיון חוזר זהה, ו"התאריך אינו תקין, נדרש YYYY-MM-DD, קיבלתי 9/3/26" גורם לתיקון.

הרחבה מלאה: Tool Use וסוכני AI.

מה שהופך שינוי מניחוש למדידה

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

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

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

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

כשמשהו נשבר בייצור

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

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

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

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

איך בוחרים מודל למשימה

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

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

הדרך הנכונה להחליט אינה טבלת בנצ׳מרקים אלא מערך ההערכה שלכם: להריץ את אותם עשרים מקרים על שני מודלים ולראות אם ההפרש מצדיק את הפער במחיר. לעתים קרובות מתברר שלא — ובשלב אחד או שניים מתוך חמישה אפשר לרדת מודל בלי לשלם באיכות.

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

עלות והשהיה הן אילוצי תכנון

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

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

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

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

הגבולות שחייבים להיות בקוד

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

הרשאות נקבעות בקוד, לא בהנחיה. "אל תמחק לקוחות" בהנחיית המערכת היא בקשה, ואפשר לשכנע מודל לעקוף בקשה. אם פעולה מסוכנת זמינה למערכת — היא ניתנת להפעלה. המימוש הוא שחייב לבדוק הרשאה לפי זהות המשתמש, לפני הפעולה.

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

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

מה משתנה כשהמערכת בעברית

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

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

מה מהתחום הזה לא יתיישן

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

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

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

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

סדר למידה שעובד

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

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

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

מה השוק בישראל מחפש

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

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

טעויות שחוזרות

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