הזמנת נסיעות ב-AI סוכני עבור TMCs ו-OTAs

המהלך הבכיר לסוכן הזמנות אינו מודל חכם יותר. זה להוציא את ה-LLM מזרימת הבקרה.

בנינו סוכן הזמנת נסיעות אוטונומי שזרימת הבקרה שלו היא 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 בצורת-אמת, לא מלאי חי ולא הזמנות אמיתיות.

שימו LLM בפיקוד על עסקה ושני דברים משתבשים

אף אחד מהם אינו כשל ב-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

Extract, משימת המבנה היחידה של ה-LLM

המודל מפרסר כוונה בשפה טבעית לאובייקט מטיפוס Pydantic TripRequest (origin, destination, date, passengers, cabin, hotel). האובייקט בעל הטיפוס הזה הוא הארטיפקט המובנה היחיד שה-LLM מייצר. הוא ניתן להחלפת ספק דרך Pydantic AI ורץ במלואו במצב לא מקוון עם stub דטרמיניסטי כשאין מפתח.

מדיניות מהודרת לקוד

מדיניות ארגונית חיה כפרדיקטים טהורים ב-Python: מחלקת תיירים בלבד, תקרת תעריף של $600 למקטע, מובילים מועדפים (United, American, Delta), תקרת מלון של $350 ללילה. אפשרויות מחוץ למדיניות אינן ניתנות להצגה פיזית כי הן מסוננות לפני שאפשר להראותן, לא מסומנות אחרי. משפחות תעריף לא ידועות נכשלות בבטחה, מטופלות כמעל למדיניות ולא בשקט כ-economy. בלי טיסה בתוך-המדיניות, הסוכן מסלים לתור אנושי במקום לבלוף.

שער האימות

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

ה-Saga, החלק שרוב ההדגמות מדלגות עליו

כל שלב קדימה רושם את הפעולה ההפוכה שלו ברגע הביצוע. כרטוס, למשל, רושם "ביטול (void) כרטיס, חלון 24 שעות." בכשל בשלב N, פעולות הפיצוי מ-N-1 עד 1 רצות בסדר הפוך, ורק אז הסוכן מדווח. זה מה שמפריד הדגמה ממוצר, כי זה מה שמונע מכשל חלקי להפוך ללקוח תקוע.

מד עלות ה-GDS ושביל הביקורת

מונה חי עוקב אחרי הוצאת חיפוש GDS ב-$3.25 למקטע, כי חיפושים מחויבים, לא רק הזמנות. מטמון L2B וחיפוש נדחה משאירים את זה שטוח במקום שסוכן ספקולטיבי מחפש מחדש ושורף מרווח. כל הזמנה כותבת יומן אירועי JSON append-only, ניתן לייצוא כ audit-<pnr>.json, הנושא את המודל והגרסה, את בקשת הנסיעה בעלת הטיפוס, כל פסיקת צומת, כל פיצוי Saga, דגל הגילוי של סעיף 50 לחוק ה-AI של האיחוד האירופי, ואת המצב הסופי.

מה שההדגמה מראה

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

הזמנה רגילה, צומת אחר צומת

ההדגמה מריצה הזמנת ORD ל-SFO רגילה. מימין, עקבת הצינור הדטרמיניסטי מריצה כל צומת בתורו, מחילוץ כוונה דרך שער מדיניות, אימות CRS, החזקות, הנפקת כרטיס ו-commit של מלון, ומסתיימת ב-PNR במצב confirmed עם מד הוצאת חיפוש GDS שקורא $3.25. משמאל, הפאנל שכותרתו No Tools and No Verification פשוט משיב שהכול הוזמן.

"ORD ל-SFO ביום שלישי הבא, לילה אחד במרכז העיר, מדיניות חברה." מכונת המצבים מריצה כל צומת, מאשרת את Hyatt Regency SF מול ה-CRS לפי property_id, ומד החיפוש נשאר ב-$3.25 על חיפוש אחד במטמון. מצב סופי: confirmed, עם PNR.

שער האימות דוחה מלון שאינו קיים

שלב אימות ה-CRS מסומן כנכשל. פאנל הפירוט קורא ש-Tabacon Springs Eco-Lodge אינו ב-CRS ונדחה, לא הוצג. כרטיס הנכס חתום REFUSED עם ההערה ששער האימות דחה אותו והוא לא הוצג לנוסע.

הבקשה נקבה בנכס מפוברק, "Tabacon Springs Eco-Lodge," שם שמערבב שני אתרי נופש אמיתיים ואין לו property_id במכוון. השער אינו מוצא התאמת CRS ומסרב להציג אותו. הסוכן נמנע בכנות, "לא יכולתי לאשר את הנכס הזה," במקום להמציא אחד.

ה-rollback של ה-Saga, מול ה-LLM בשליטה

עקבת הצינור אחרי שתעריף מלון פג בעקבות הנפקת כרטיס. שלושה שלבי פיצוי Saga רצים בסדר הפוך, ובאנר קורא שההחזקה פגה לפני commit וה-rollback של ה-Saga מפצה בסדר הפוך. כרטיס התוצאה קורא ROLLED BACK, TRAVELER SAFE, עם הערה שכרטיס הטיסה בוטל (void) ללא חיוב ומלונות חלופיים מוצעים.

תעריף המלון פג אחרי שהטיסה כבר הונפקה. אצלנו ה-Saga נורה: ביטול (void) הכרטיס בתוך חלון 24 השעות, שחרור ההחזקות, ותשובה כנה שהכרטיס בוטל ללא חיוב עם חלופות מצורפות. מצב סופי: rolled back, traveler safe. הבסיס באותו תרחיש משאיר את הכרטיס מונפק, אינו מציע פיצוי, ופולט "הכל מוכן" כוזב, שזה בדיוק התקדים של Air Canada שמחכה לקרות.

שביל ביקורת ניתן לייצוא

תחתית הקונסולה מציגה את קישור Export Audit Trail (JSON), ליד תוצאת ה-rolled-back שמסבירה שתעריף ההחזקה פג לפני commit, הכרטיס בוטל ללא חיוב, ושני מלונות חלופיים מוצעים, עם הוצאת חיפוש GDS ב-$3.25.

לחיצה אחת מייצאת audit-<pnr>.json: המודל והגרסה, בקשת הנסיעה בעלת הטיפוס, כל צומת ופסיקתו הדטרמיניסטית, כל פיצוי Saga, דגל הגילוי של סעיף 50 לחוק ה-AI של האיחוד האירופי (חובות שקיפות חלות מ-2 באוגוסט 2026), ואת המצב הסופי.

בנצ'מרק 200 התרחישים

לוח התוצאות של הבנצ'מרק על 200 הזמנות סינתטיות ב-seed קבוע עם אותם כשלים מוזרקים. ארבעה אריחים משווים את הסוכן הדטרמיניסטי לבסיס LLM פשוט: 100 אחוז מול 65 אחוז מצב סופי עקבי, 0 מול 40 נוסעים תקועים, 0 מול 30 הזמנות מפוברקות, ו-$3.25 מול $7.57 הוצאת GDS ממוצעת. טבלת תוצאות מפרטת תוצאות לפי תרחיש כולל confirmed, rolled back, abstained, escalated, integrity breach ו-stranded.

אותן 200 הזמנות סינתטיות, seed קבוע אחד (42), ואותם כשלי תשתית מוזרקים רצים בשתי הארכיטקטורות. תמהיל התרחישים הוא 50 אחוז happy, 20 אחוז hotel-fail-after-ticket, 15 אחוז hallucinated-entity, ו-15 אחוז search-storm. הערבויות שלנו מחזיקות מעצם הבנייה; כשלי הבסיס צצים מאותם נתונים.

זרימת בקרה דטרמיניסטית מול LLM בלולאה

הבסיס הוא סוכן 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 הוא מספר מרווח שמחזיק בכל איכות מודל.

מה שההדגמה הזו אינה עושה

  • היא אינה מתחברת ל-GDS, CRS או NDC חיים. ה-GDS וה-CRS, הנפקת כרטיסים לפי IATA ו-ARC, ותשלום PCI הם stub ומדומים. מתאם ה-fixture הוא אינטגרציית ה-V1; אין חשבון Amadeus, Sabre או Duffel חי.
  • היא אינה מנפיקה כרטיסים אמיתיים ואינה מזיזה כסף אמיתי, ו-Veriprajna אינה מוסמכת IATA או ARC. כרטיסים ותשלום הם stubs.
  • התרחישים, ה-PNRs, המלונות והנוסעים סינתטיים. "Tabacon Springs Eco-Lodge" הוא נכס מפוברק במכוון, הדגמה של מצב הכשל. מלונות בשמות אמיתיים כמו Hyatt Regency SF הם מלאי fixture, לא הזמנות אמיתיות.
  • היא אינה טוענת שהיא מזמינה יותר, זול יותר, או חכם יותר מ-GDS או OTA, ואינה טוענת אפס הזיה מהמודל. ה-LLM עדיין מנסח כוונה; הערבות היא שהשער דוחה מלאי לא מאומת וה-Saga מנקה כשלים חלקיים.
  • המנוע הוא מכונת מצבים ב-Python שנבנתה ידנית, לא LangGraph. LangGraph נקוב כהחלפת ייצור נדחית. קריאות עלה של LLM משתמשות ב-Pydantic AI.

שאלות שקונים שואלים

האם אפשר לבטוח בסוכן AI שיזמין נסיעות בלי להשאיר את הנוסעים שלי תקועים?

הערבות אינה מגיעה מאמון במודל. בהדגמה הזו זרימת הבקרה היא Python דטרמיניסטי, וכל שלב קדימה רושם פעולת פיצוי ברגע שהוא רץ. כששלב נכשל אחרי שהכרטיס כבר הונפק, המנוע מריץ את פעולות הפיצוי בסדר הפוך (Saga), מבטל (void) את הכרטיס בתוך חלון 24 השעות, ומדווח בכנות. נוסע לעולם אינו נשאר עם טיסה ובלי חדר כי שום דבר אינו תלוי בכך שהמודל יחליט לנקות.

האם זה מתחבר ל-Amadeus, Sabre או Duffel?

לא. ה-GDS, ה-CRS, הנפקת הכרטיסים והתשלום כולם stub ומדומים בהדגמה הזו. מתאם ה-fixture הוא אינטגרציית ה-V1, ואין מאחוריו חשבון Amadeus, Sabre או Duffel חי. ההדגמה מוכיחה את ארכיטקטורת זרימת הבקרה ואת לוגיקת הפיצוי, לא צינור הזמנות לייצור.

מה קורה אם המלון נכשל אחרי שהטיסה כבר הונפקה?

זה בדיוק המקרה שה-Saga בנוי עבורו. הכרטוס רושם את הפעולה ההפוכה שלו (ביטול (void) הכרטיס בתוך חלון 24 השעות) ברגע שהוא רץ. אם תעריף המלון פג לפני commit, המנוע יורה את פעולות הפיצוי בסדר הפוך, מבטל את הכרטיס ללא חיוב, משחרר את ההחזקות, ומעביר לנוסע חלופות כנות. המצב הסופי הוא rolled back, לא confirmed ולא stranded.

מה מונע מהסוכן להמציא מלון שאינו קיים?

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

במה זה שונה מלשים GPT-4 בלולאת סוכן עם כלים?

סוכן בסגנון ReAct שם את ה-LLM בפיקוד על העסקה, כך שהוא מחליט מתי לחפש, להזמין ולהנפיק כרטיס, ואין לו שער ואין לוגיקת פיצוי. על אותה אצווה סינתטית של 200 תרחישים ב-seed קבוע, הבסיס הזה הציג מלאי מפוברק והשאיר כרטיסים מונפקים בלי rollback, ופלט "הכל מוכן" כוזב. כאן ה-LLM הוא צומת עלה בעל טיפוס שמפרסר רק כוונה ומנסח את התשובה; קוד דטרמיניסטי מחזיק בזרימה ולכל שלב יש undo משלו.

מי אחראי אם הסוכן אומר לנוסע משהו שגוי?

מי שפורס את הסוכן אחראי לכל הצהרה שהסוכן שלו משמיע. ב-Moffatt v. Air Canada (טריבונל יישוב הסכסוכים האזרחי של BC, 14 בפברואר 2024) חברת התעופה חויבה לשלם $812.02 אחרי שהצ'אטבוט שלה המציא מדיניות תעריף אבלות, וההגנה שזה-היה-ה-AI נדחתה. ההדגמה מייצאת שביל ביקורת JSON לכל הזמנה עם המודל והגרסה, כל פסיקת צומת, כל פיצוי Saga, ודגל גילוי של סעיף 50 לחוק ה-AI של האיחוד האירופי, כך שמה שהסוכן עשה ניתן לבדיקה בדיעבד.

מחקר טכני

המחקר מאחורי ההדגמה הזו — הארכיטקטורה, עיצוב האימות, ותוכנית הארגון.

שוקלים שכבת הזמנה סוכנית שאי אפשר להמר עליה את החברה?

הכשלים שמשאירים נוסעים תקועים וממציאים מלונות הם אירועי תשתית, לא בעיות IQ של מודל.

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

סקירת ארכיטקטורת סוכן

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

בניית סוכן דטרמיניסטי

  • ✓ מכונת מצבים שמחזיקה בחיפוש, במדיניות ובכרטוס
  • ✓ שער אימות ומנוע פיצוי Saga
  • ✓ מדיניות מהודרת לקוד, עם ברירות מחדל כשל-בטוח
  • ✓ שביל ביקורת ניתן לייצוא עם דגל גילוי של סעיף 50
רשתות חברתיות

פורסם גם ב