הזמנת נסיעות ב-AI סוכני עבור TMCs ו-OTAs
בנינו סוכן הזמנת נסיעות אוטונומי שזרימת הבקרה שלו היא Python דטרמיניסטי. המודל רק מפרסר את בקשת הנסיעה ומנסח את התשובה. כל שלב הזמנה רושם פעולת פיצוי, כך שכאשר תעריף מלון פג אחרי שהטיסה כבר הונפקה, הסוכן מבטל (void) את הכרטיס בתוך חלון 24 השעות ומעביר לנוסע חלופות כנות במקום להשאיר אותו תקוע.
100%
מצב סופי עקבי, מעצם הבנייה
אצווה סינתטית של 200 תרחישים ב-seed קבוע, מול 65% לבסיס LLM-in-control
0 / 0
נוסעים תקועים, הזמנות מפוברקות שהוצגו
אותה אצווה, מול 40 ו-30 בבסיס
$3.25
הוצאת חיפוש GDS ממוצעת להזמנה
מול בסיס $7.57; GDS מחייב לפי חיפוש, Lufthansa העלתה עמלות ב-1 בינואר 2026
כל התרחישים סינתטיים על GDS ו-CRS מדומים; קודי שדות תעופה ושמות מלונות הם fixtures בצורת-אמת, לא מלאי חי ולא הזמנות אמיתיות.
אף אחד מהם אינו כשל ב-IQ של המודל. שניהם כבר מחלקת באגים של 2026.
הסוכן מנפיק כרטיס טיסה, שלב המלון נכשל, ובלי לוגיקת פיצוי הוא עדיין אומר "הכל מוכן." מישהו נשאר עם טיסה ובלי חדר. מודל מושלם עדיין משאיר נוסע תקוע אם שום דבר אינו מבטל (void) את הכרטיס.
הוא ממציא מלון סביר ומזמין אותו. הנכס מעולם לא היה ב-CRS. שום דבר לא בדק לפני שהגיע לנוסע, כי בלולאת הסקה המודל הוא גם המציע וגם השופט.
הסיבה שמודל טוב יותר אינו מתקן זאת היא שהכשלים הם אירועי תשתית ושימוש, בלתי תלויים באיכות המודל. תעריף פג בין שתי קריאות API. החזקה (hold) נדחית אחרי שהכרטיס כבר הונפק. סערת חיפושים שורפת מרווח. הסקה סטוכסטית מחמירה מול אלה: עשרה שלבים ב-90 אחוז אמינות מגיעים בערך ל-34 אחוז מקצה לקצה, ו-GPT-4 עם ReAct משלים מסלולים אמיתיים של כמה ימים ב-0.6 אחוז (TravelPlanner, OSU NLP, arXiv 2402.01622). אי אפשר לצאת מכשל סטוכסטי מצטבר בעזרת prompt.
ומי שפורס את הסוכן אחראי לכל הצהרה שהסוכן משמיע. ב-Moffatt v. Air Canada (טריבונל יישוב הסכסוכים האזרחי של BC, 14 בפברואר 2024) חברת התעופה חויבה לשלם $812.02 אחרי שהצ'אטבוט שלה המציא מדיניות תעריף אבלות, והטענה שה-AI הוא ישות נפרדת נדחתה.
זרימת הבקרה היא מכונת מצבים ב-Python שנבנתה ידנית, בערך עשרה צמתים. ה-LLM מוגבל לשתי משימות עלה. כל מה שביניהן דטרמיניסטי.
input → extract (LLM leaf) → search → policy gate → verify gate → hold → ticket → hotel-book → commit
המודל מפרסר כוונה בשפה טבעית לאובייקט מטיפוס Pydantic TripRequest (origin, destination, date, passengers, cabin, hotel). האובייקט בעל הטיפוס הזה הוא הארטיפקט המובנה היחיד שה-LLM מייצר. הוא ניתן להחלפת ספק דרך Pydantic AI ורץ במלואו במצב לא מקוון עם stub דטרמיניסטי כשאין מפתח.
מדיניות ארגונית חיה כפרדיקטים טהורים ב-Python: מחלקת תיירים בלבד, תקרת תעריף של $600 למקטע, מובילים מועדפים (United, American, Delta), תקרת מלון של $350 ללילה. אפשרויות מחוץ למדיניות אינן ניתנות להצגה פיזית כי הן מסוננות לפני שאפשר להראותן, לא מסומנות אחרי. משפחות תעריף לא ידועות נכשלות בבטחה, מטופלות כמעל למדיניות ולא בשקט כ-economy. בלי טיסה בתוך-המדיניות, הסוכן מסלים לתור אנושי במקום לבלוף.
כל מלון מאומת מול ה-CRS לפי property_id. נכס שהמודל ממציא פשוט אינו ב-CRS, ולכן הוא נדחה ולעולם אינו מוצג, וההזמנה מגיעה למצב הסופי abstained. השער דוחה מלאי לא מאומת; הוא אינו מבקש מהמודל לדרג את הפלט שלו עצמו.
כל שלב קדימה רושם את הפעולה ההפוכה שלו ברגע הביצוע. כרטוס, למשל, רושם "ביטול (void) כרטיס, חלון 24 שעות." בכשל בשלב N, פעולות הפיצוי מ-N-1 עד 1 רצות בסדר הפוך, ורק אז הסוכן מדווח. זה מה שמפריד הדגמה ממוצר, כי זה מה שמונע מכשל חלקי להפוך ללקוח תקוע.
מונה חי עוקב אחרי הוצאת חיפוש GDS ב-$3.25 למקטע, כי חיפושים מחויבים, לא רק הזמנות. מטמון L2B וחיפוש נדחה משאירים את זה שטוח במקום שסוכן ספקולטיבי מחפש מחדש ושורף מרווח. כל הזמנה כותבת יומן אירועי JSON append-only, ניתן לייצוא כ audit-<pnr>.json, הנושא את המודל והגרסה, את בקשת הנסיעה בעלת הטיפוס, כל פסיקת צומת, כל פיצוי Saga, דגל הגילוי של סעיף 50 לחוק ה-AI של האיחוד האירופי, ואת המצב הסופי.
ארבעה כפתורים, זה לצד זה מול בסיס LLM-in-control אמיתי על אותו תרחיש. כל צילום מסך למטה נלכד מהאפליקציה הפועלת.
"ORD ל-SFO ביום שלישי הבא, לילה אחד במרכז העיר, מדיניות חברה." מכונת המצבים מריצה כל צומת, מאשרת את Hyatt Regency SF מול ה-CRS לפי property_id, ומד החיפוש נשאר ב-$3.25 על חיפוש אחד במטמון. מצב סופי: confirmed, עם PNR.
הבקשה נקבה בנכס מפוברק, "Tabacon Springs Eco-Lodge," שם שמערבב שני אתרי נופש אמיתיים ואין לו property_id במכוון. השער אינו מוצא התאמת CRS ומסרב להציג אותו. הסוכן נמנע בכנות, "לא יכולתי לאשר את הנכס הזה," במקום להמציא אחד.
תעריף המלון פג אחרי שהטיסה כבר הונפקה. אצלנו ה-Saga נורה: ביטול (void) הכרטיס בתוך חלון 24 השעות, שחרור ההחזקות, ותשובה כנה שהכרטיס בוטל ללא חיוב עם חלופות מצורפות. מצב סופי: rolled back, traveler safe. הבסיס באותו תרחיש משאיר את הכרטיס מונפק, אינו מציע פיצוי, ופולט "הכל מוכן" כוזב, שזה בדיוק התקדים של Air Canada שמחכה לקרות.
לחיצה אחת מייצאת audit-<pnr>.json: המודל והגרסה, בקשת הנסיעה בעלת הטיפוס, כל צומת ופסיקתו הדטרמיניסטית, כל פיצוי Saga, דגל הגילוי של סעיף 50 לחוק ה-AI של האיחוד האירופי (חובות שקיפות חלות מ-2 באוגוסט 2026), ואת המצב הסופי.
אותן 200 הזמנות סינתטיות, seed קבוע אחד (42), ואותם כשלי תשתית מוזרקים רצים בשתי הארכיטקטורות. תמהיל התרחישים הוא 50 אחוז happy, 20 אחוז hotel-fail-after-ticket, 15 אחוז hallucinated-entity, ו-15 אחוז search-storm. הערבויות שלנו מחזיקות מעצם הבנייה; כשלי הבסיס צצים מאותם נתונים.
הבסיס הוא סוכן LLM-in-control בסגנון ReAct אמיתי שרץ על אותם תרחישים, עוגן כנה ולא איש קש. המספרים למטה הם על האצווה הסינתטית של 200 תרחישים ב-seed קבוע (benchmark.py, seed 42, n=200).
| מדד | סוכן דטרמיניסטי (שלנו) | בסיס (LLM-in-control) |
|---|---|---|
| מצב סופי עקבי | 100.0% | 65.0% |
| נוסעים תקועים | 0 | 40 |
| הזמנות מפוברקות שהוצגו | 0 | 30 |
| הוצאת חיפוש GDS ממוצעת להזמנה | $3.25 | $7.57 |
ה-100 אחוז, ה-0 וה-0 מחזיקים מעצם הבנייה על האצווה הסינתטית ב-seed הקבוע הזה, לא כערבות ייצור בעולם פתוח. הטענה צרה ועמידה: הזמנה חלקית לעולם אינה מוצגת כ-confirmed, ונוסע לעולם אינו נשאר תקוע. הפער $3.25 מול $7.57 הוא מספר מרווח שמחזיק בכל איכות מודל.
הערבות אינה מגיעה מאמון במודל. בהדגמה הזו זרימת הבקרה היא Python דטרמיניסטי, וכל שלב קדימה רושם פעולת פיצוי ברגע שהוא רץ. כששלב נכשל אחרי שהכרטיס כבר הונפק, המנוע מריץ את פעולות הפיצוי בסדר הפוך (Saga), מבטל (void) את הכרטיס בתוך חלון 24 השעות, ומדווח בכנות. נוסע לעולם אינו נשאר עם טיסה ובלי חדר כי שום דבר אינו תלוי בכך שהמודל יחליט לנקות.
לא. ה-GDS, ה-CRS, הנפקת הכרטיסים והתשלום כולם stub ומדומים בהדגמה הזו. מתאם ה-fixture הוא אינטגרציית ה-V1, ואין מאחוריו חשבון Amadeus, Sabre או Duffel חי. ההדגמה מוכיחה את ארכיטקטורת זרימת הבקרה ואת לוגיקת הפיצוי, לא צינור הזמנות לייצור.
זה בדיוק המקרה שה-Saga בנוי עבורו. הכרטוס רושם את הפעולה ההפוכה שלו (ביטול (void) הכרטיס בתוך חלון 24 השעות) ברגע שהוא רץ. אם תעריף המלון פג לפני commit, המנוע יורה את פעולות הפיצוי בסדר הפוך, מבטל את הכרטיס ללא חיוב, משחרר את ההחזקות, ומעביר לנוסע חלופות כנות. המצב הסופי הוא rolled back, לא confirmed ולא stranded.
שער אימות מאשר כל נכס מול ה-CRS לפי ה-property_id שלו לפני שאפשר להציגו. כשהבקשה נקבה בנכס מפוברק בהדגמה שלנו, השער לא מצא התאמת CRS וסירב להציג אותו, והסוכן נמנע בכנות במקום להזמין אותו. השער אינו מסמן מלון בדוי בדיעבד; הוא הופך אותו לבלתי ניתן להצגה פיזית.
סוכן בסגנון ReAct שם את ה-LLM בפיקוד על העסקה, כך שהוא מחליט מתי לחפש, להזמין ולהנפיק כרטיס, ואין לו שער ואין לוגיקת פיצוי. על אותה אצווה סינתטית של 200 תרחישים ב-seed קבוע, הבסיס הזה הציג מלאי מפוברק והשאיר כרטיסים מונפקים בלי rollback, ופלט "הכל מוכן" כוזב. כאן ה-LLM הוא צומת עלה בעל טיפוס שמפרסר רק כוונה ומנסח את התשובה; קוד דטרמיניסטי מחזיק בזרימה ולכל שלב יש undo משלו.
מי שפורס את הסוכן אחראי לכל הצהרה שהסוכן שלו משמיע. ב-Moffatt v. Air Canada (טריבונל יישוב הסכסוכים האזרחי של BC, 14 בפברואר 2024) חברת התעופה חויבה לשלם $812.02 אחרי שהצ'אטבוט שלה המציא מדיניות תעריף אבלות, וההגנה שזה-היה-ה-AI נדחתה. ההדגמה מייצאת שביל ביקורת JSON לכל הזמנה עם המודל והגרסה, כל פסיקת צומת, כל פיצוי Saga, ודגל גילוי של סעיף 50 לחוק ה-AI של האיחוד האירופי, כך שמה שהסוכן עשה ניתן לבדיקה בדיעבד.
המחקר מאחורי ההדגמה הזו — הארכיטקטורה, עיצוב האימות, ותוכנית הארגון.
פתרון מלא
חקרו את פתרון הזמנת הנסיעות ב-AI סוכני →הכשלים שמשאירים נוסעים תקועים וממציאים מלונות הם אירועי תשתית, לא בעיות IQ של מודל.
אם הצוות שלכם שוקל היכן ה-LLM שייך בסוכן הזמנות בסיכון גבוה, וכיצד למנוע מכשל חלקי להפוך לאחריות בסגנון Air Canada, נשמח באמת להחליף רשמים. הבעיה רוחבית-תעשייה וגם התשובות יהיו.