הפסיקו להנדס יתר על המידה: הגישה האמפירית ל-AI

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

נקודות מרכזיות

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

מדוע הנדסת יתר הורגת פרויקטי AI

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

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

המעבר מתכנון מראש ללמידה מבוססת ביצועים

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

בסרטון Boris Cherny: We Cut 80% of Claude Code’s Prompt, ניתן לראות איך פישוט המערכת והתמקדות במה שבאמת עובד מובילים לתוצאות טובות יותר. בוריס צ'רני, מוביל הנדסי ב⁨אנתרופיק (Anthropic)⁩, מדגים שהסרת הוראות הופכת את המודל לאמין יותר כי יש לו פחות 'חוקים' להתנגש בהם. הכלל פשוט: אל תנחשו מה המודל צריך. תנו לו לעבוד, תראו איפה הוא טועה, ותנו לו את הכלי המדויק שימנע את הטעות הבאה.

חשיבותם של כלי אימות במערכות אוטונומיות

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

ביצוע תיקונים ממוקדים

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

מקורות

• Boris Cherny: We Cut 80% of Claude Code’s Prompt (youtu.be)

שאלות נפוצות

למה כדאי לתת למודל משימה שהוא עלול להיכשל בה?

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

מהם כלי אימות ואיך הם עוזרים?

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

איך נמנעים מהנדסת יתר בפרויקטים של AI?

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

דברים שחשוב לזכור

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

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