GPT-4 נכשל ב-99.4% מהמקרים — אז הפסקנו לתת לו לקבל החלטות

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

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

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

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

בנינו סוכן AI להזמנת נסיעות — מהסוג שמדבר עם מערכות הפצה גלובליות (Global Distribution Systems) כמו Amadeus ו-Sabre, אותם שרתי עורף עתיקים מעידן המיינפריים שמניעים כל הזמנת טיסה בעולם. ועשינו את מה שכולם עשו ב-2023: עטפנו את GPT-4 בשכבת תזמור דקה, נתנו לו כלים, והתפללנו.

התפילה לא עבדה.

המספר ששינה הכול

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

שיעור ההצלחה הכולל של GPT-4: 0.6%.

לא 60%. לא 6%. אפס נקודה שש אחוזים.

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

כשביקשו מ-GPT-4 לתכנן טיולים עם אילוצים מהעולם האמיתי, הוא הצליח ב-0.6% מהמקרים. סוכן נוירו-סימבולי שפתר את אותה בעיה השיג 97%.

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

המדד הזה לא רק אישש את התסכול שלנו. הוא נתן לנו תוכנית פעולה.

למה סוכן ה-AI שלך ממשיך להיכשל?

הנה הדבר שאף אחד בבהלת הזהב של "סוכני AI" לא רוצה לדבר עליו: LLMs לא מסיקים. הם חוזים.

כש-GPT-4 "מחליט" לקרוא ל-API של חיפוש, הוא לא מריץ לוגיקה. הוא חוזה את הטוקן הבא הסביר ביותר סטטיסטית על סמך דפוסים בנתוני האימון שלו. בשיחה, החיזוי הזה בדרך כלל טוב מספיק. בתהליך עבודה בן עשרה שלבים של API שבו כל שלב תלוי בפלט המדויק של הקודם? זו קטסטרופה.

התחלתי לקרוא לזה בעיית שרשרת ההסתברות. נניח שה-LLM שלך צודק בכל שלב ב-90% מהמקרים — הערכה נדיבה לשימוש מורכב בכלים. הנה החשבון:

• שלב 1: 90% הצלחה
• 5 שלבים: ~59% הצלחה
• 10 שלבים: ~34% הצלחה

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

ו-34% הוא התקרה. הביצועים בעולם האמיתי גרועים יותר בגלל שתי תופעות שנתקלנו בהן שוב ושוב בסביבת הייצור.

מפל ההזיות

הראשונה היא מה שאני מכנה מפל ההזיות. בארכיטקטורה משורשרת, הפלט של שלב 2 הופך לקלט של שלב 3. אם ה-LLM עושה טעות עדינה מוקדם — קורא בטעות זמן נחיתת טיסה כ-2:00 אחר הצהריים במקום 2:00 לפנות בוקר — הטעות הזו לא נתפסת. היא מתפשטת. הסוכן מזמין צ'ק-אין למלון ביום הלא נכון על סמך הזמן ההזוי. ה-API של ה-GDS לא יודע את הכוונה של הסוכן, אלא רק את הקלט שלו, ולכן הוא מעבד את הבקשה בהצלחה. הסוכן רואה תגובת 200 OK ומחזק את הטעות של עצמו.

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

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

ראיתי את זה קורה בשידור חי במהלך הדגמה לשותף פוטנציאלי. הסוכן מצא מלון בתוך התקציב בשלב 3. עד שלב 8, כשבחר מסעדה, הוא איבד לחלוטין את המעקב אחר התקציב שנותר. הוא המליץ על מקום שהיה חורג ממגבלת ההוצאות של המשתמש ב-40%. השותף פנה אליי ואמר, "אז הוא פשוט... שוכח?"

כן. הוא פשוט שוכח.

מה קורה כשה-AI פוגש מיינפריים?

כדי להבין באמת למה נזקקנו לגישה שונה, צריך להבין איך זה לעבוד עם מערכות הפצה גלובליות (Global Distribution Systems).

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

אתה מבצע אימות ומקבל אסימון סשן. את האסימון הזה חובה להעביר בכל כותרת עוקבת — אם ה-LLM "שוכח" אותו או ממציא בהזיה חדש, כל הקשר של העסקה אובד. אחר כך אתה מחפש טיסות, וה-GDS מחזיר מטעני JSON מקוננים ענקיים — לעיתים 50KB+ — המכילים קודי בסיס תעריף, מודלי כבודה, הפניות מקטע. ה-LLM צריך לחלץ offerId ספציפי מהמטען הזה כדי להמשיך. אבל LLMs הם דוחסים מאבדי מידע. הם מסכמים. הם קוטעים. הם "בעזרה" מנרמלים פורמטי נתונים שה-GDS דורש שיהיו מדויקים, עד רמת הבייט.

לילה אחד, בילינו ארבע שעות באיתור באגים של כשל בהזמנה. ה-LLM "תיקן" קוד בסיס תעריף — שינה אות קטנה לאות גדולה, כי זה נראה יותר "נכון" למודל שאומן על טקסט באנגלית. ה-GDS דחה אותו עם שגיאה סתומה: ERR 1209 - SEQUENCE ERROR. ללא הסבר. ללא הצעה. רק קיר.

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

וכשה-GDS מחזיר שגיאה כמו UC (Unable to Confirm), ל-LLM אין מושג מה לעשות. הוא מאומן להיות מועיל, ולכן הוא מפרש את השגיאה כתקלה חולפת ומנסה שוב את אותה בקשה בדיוק. שוב. ושוב. צפינו בסוכנים שורפים אלפי טוקנים ומגיעים למגבלות קצב של ה-API, תקועים במה שהתחלנו לכנות "לולאת המוות" — חובטים שוב ושוב בקיר שלא הצליחו להבין.

הלילה שבו הפכנו את הארכיטקטורה

נקודת המפנה הגיעה במהלך ויכוח.

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

פתחתי את הלוגים שלנו. בשבוע הקודם היו לנו 47 ניסיונות הזמנה כושלים בסביבת הבדיקות שלנו. אחד-עשר היו לולאת המוות. תשעה היו קודי שדה תעופה הזויים. שישה היו ה-LLM שמנסה לבצע commit ל-PNR לפני הוספת השדה "Received From" החובה — שגיאת רצף ששום כמות של פרומפטים לא נראה שמתקנת, כי למודל לא היה מושג מובנה של סידור זמני מעבר למה שספג מנתוני האימון.

"אנחנו לא קרובים," אמרתי. "אנחנו בתקרה. הארכיטקטורה היא הבעיה."

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

במקום זאת, בנינו גרף.

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

איך AI נוירו-סימבולי באמת עובד?

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

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

פיצלנו את המערכת שלנו לשתי שכבות:

ה-LLM הפך לשכבת הממשק — המתרגם. הוא מנתח את השפה הטבעית של המשתמש ("אני רוצה טיסת בוקר לדהרדון, לא יקרה מדי") לנתונים מובנים: {origin: "DEL", destination: "DED", date: "2024-03-15", time_preference: "morning", budget: "economy"}. זה מה ש-LLMs באמת מצטיינים בו: הבנת כוונה אנושית מבולגנת.

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

השתמשנו ב-LangGraph כדי לבנות את זה, כי הוא נותן לך את היסודות שאתה צריך: סכמת מצב משותפת (מגובה במסד נתונים, לא בהיסטוריית צ'אט), צמתים שהם פשוט פונקציות Python, וקשתות מותנות שמנתבות על סמך ערכי משתנים אמיתיים.

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

בארכיטקטורה שלנו, ה-LLM ממש לא יכול לדלג על שלבים. פיזית בלתי אפשרי שהמערכת תנסה לבצע הזמנה לפני שהמשתנה selected_offer_id מאוכלס במצב. לא כי אמרנו ל-LLM "אל תעשה את זה" בפרומפט, אלא כי קשת הגרף לא תופעל. זה כמו לנסות לנהוג דרך קיר — הקוד פשוט לא מאפשר את זה.

איך המערכת בפועל נראית?

הרשו לי להוליך אתכם דרך מה שקורה כשמישהו אומר "הזמן לי טיסה ממומבאי ללונדון ביום שלישי הבא."

ראשית, צומת Collector — המונע על ידי LLM — מנתח את המשפט הזה לשדות מובנים. הוא משתמש בגנרציה מודרכת (JSON Mode) כדי להפיק סכמה ספציפית. מאמת Python בודק אם קודי שדות התעופה אמיתיים. "לונדון" עמומה — הית'רו או גטוויק? — ולכן הגרף מנתב לצומת פירוק עמימות. ה-LLM לא מנחש. הוא שואל.

לאחר שיש לנו קריטריוני חיפוש מאומתים, צומת Retriever קורא ל-API של Amadeus. זה קוד טהור. ללא מעורבות LLM. התגובה חוזרת, נשמרת במטמון במצב, ורק אז צומת Summarizer — LLM — ממיר את חמש התוצאות המובילות להודעה קריאה לבני אדם. אבל הוא מוגבל בקפדנות: הוא יכול להציג רק נתונים שקיימים ב-JSON השמור במטמון. הוא לא יכול להמציא הטבות או לשנות מחירים.

המשתמש בוחר אפשרות. צומת Selector מפענח את "השנייה" ל-offer_id hash הספציפי. צומת Gatekeeper בודק כללים עסקיים — האם זה בתוך מדיניות החברה? האם המוביל ברשימה השחורה? אם יש הפרה, הגרף משהה. הוא מתמיד את מצבו למסד הנתונים, שולח בקשת אישור למנהל, וממתין. שעות לאחר מכן, כשהמנהל לוחץ "אשר," הגרף טוען מחדש את המצב המדויק וממשיך בצומת ההזמנה.

לבסוף, צומת Transactor מבצע את רצף יצירת ה-PNR — מקטעים, פרטי נוסע, תמחור, commit — בסדר המדויק שה-GDS דורש. אם ה-GDS מחזיר אזהרת שינוי מחיר (נפוץ בתחום הנסיעות), הצומת עוצר ומבקש מהמשתמש לאשר. הוא לא מזמין אוטומטית בתעריף הגבוה יותר.

כל מעבר צומת נרשם בלוג. כל החלטה ניתנת למעקב. מבקר יכול לקרוא את יומן הביצוע ולהבין בדיוק למה המערכת הזמינה טיסה ספציפית — לא על ידי פירוש של ערבוביית טוקנים, אלא על ידי קריאת רשומה מובנית: Node:Gatekeeper | Input: Price=1200 | Rule: Policy_Limit=1000 | Output: REJECT_NEED_APPROVAL.

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

האם זו לא סתם... הנדסת תוכנה רגילה?

אנשים שואלים אותי את זה כל הזמן. "אז אתה אומר שאנחנו צריכים לכתוב קוד במקום להשתמש ב-AI? מהפכני."

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

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

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

יש גם טיעון עלות שהפתיע אותי. סוכני LLM טהורים הם יקרים — לא כי ההסקה יקרה לכל קריאה, אלא בגלל לולאות הכשל. כשסוכן נתקע ומנסה שוב ושוב שגיאת GDS על ידי הזיית פרמטרים חדשים, הוא שורף אלפי טוקנים לפני שהוא נגמר בפסק זמן. סשן תקוע בודד יכול לעלות $5-$10 בקרדיטים של API. מטפלי השגיאות המקודדים קשיח שלנו תופסים את הכשלים האלה בעלות טוקנים אפסית. ומכיוון שאנחנו שולחים ל-LLM רק את 5 השדות הרלוונטיים מתוך תגובת GDS של 50KB במקום את כל הדבר, אנחנו חותכים את השימוש בחלון ההקשר בכ-90%.

אבל האם המודלים לא ישתפרו מספיק בסופו של דבר?

אולי. אני באמת לא יודע אם GPT-6 או GPT-7 יהיו אמינים מספיק כדי לתזמר תהליכי עבודה של API בני עשרה שלבים ללא מעקות בטיחות. אבל אני יודע שני דברים.

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

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

הארכיטקטורה היא המוצר

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

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

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