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

אישה שלחה לנו מייל בשנה שעברה עם צילום מסך. היא השתמשה במתכנן טיולים פופולרי מבוסס בינה מלאכותית כדי להזמין חופשה משפחתית לקוסטה ריקה. הבינה המלאכותית המליצה על מקום שנקרא משהו כמו "Tabacon Springs Eco-Lodge" — תיאורים עשירים, מחיר של פחות מ-$200 ללילה, תמונות שנראו תואמות. היא הזמינה טיסות לארבעה אנשים. שכרה רכב. אמרה לילדיה שהם הולכים לראות קופים מבית עץ.

האכסניה לא הייתה קיימת.

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

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

מדוע הבינה המלאכותית שלכם ממציאה מלונות שלא קיימים?

הנה מה שרוב האנשים לא מבינים לגבי מודלי שפה גדולים — GPT-4, Claude, Gemini, כולם. הם לא "יודעים" דברים כמו שמסד נתונים יודע דברים. מערכת הזמנת חדרים במלון יודעת שחדר 412 ב-JW Marriott מוזמן מ-3 במרץ עד 7 במרץ. זו עובדה, מאוחסנת בשורה, ניתנת לתשאול.

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

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

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

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

הלילה שבו הבנתי ששטף הוא הבעיה

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

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

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

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

מקרה הצ'אטבוט של Air Canada הפך את זה למוחשי במונחים משפטיים. צ'אטבוט המציא מדיניות החזר כספי. בית המשפט פסק שחברת התעופה נושאת באחריות — לא ספק הבינה המלאכותית, לא הצ'אטבוט כ"כלי בטא". החברה שפרסה את הסוכן הייתה אחראית לטענות הסוכן. אם הבינה המלאכותית שלכם מבטיחה סוויטה עם נוף לים ב-$200 וב-GDS יש רק חדר סטנדרטי ב-$400, ייתכן שתישאו באחריות להפרש. או גרוע מכך, לחופשה שנהרסה.

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

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

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

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

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

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

זהו המעבר ממה שהתעשייה מכנה "LLM Wrapper" למערכת Agentic AI. וההבדל אינו הדרגתי. זהו שינוי במין. כתבתי על הארכיטקטורה הזו לעומק בגרסה האינטראקטיבית של המחקר שלנו.

דפוס המתזמר-עובד: מדוע סוכן אחד אינו מספיק

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

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

המתזמר הוא מודל בעל יכולת הסקה גבוהה — GPT-4o או Claude 3.5 Sonnet — שמדבר עם המשתמש, מתחזק היסטוריית שיחה, ומחליט מה צריך לקרות. הוא אינו נוגע ב-GDS ישירות. מתחתיו יושבים עובדים מתמחים: עובד טיסות שדובר את Amadeus Air APIs ומבין קודי IATA, עובד מלונות שדובר את Sabre's Content Services for Lodging ויודע את ההבדל בין פיקדון לערבות, עובד מדיניות שבודק כללי נסיעות תאגידיים לפני שמשהו מוצג.

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

התובנה המרכזית הייתה הפרדת החשיבה מהעשייה. המתזמר חושב. העובדים עושים. ואף אחד מהם אינו מעמיד פנים שהוא האחר.

מדוע "200 OK" כמעט הוליך אותנו שולל

הנה סיפור שעדיין גורם לי להתכווץ. היינו עמוק בתוך בדיקות אינטגרציה עם Sabre's booking APIs. עובד המלונות שלנו היה שולח בקשת הזמנה, מקבל בחזרה תגובת HTTP 200 — שבפיתוח אתרים משמעה "הצלחה" — ומעביר זאת למתזמר. המתזמר היה אומר למשתמש: "הוזמנת!"

אלא שהם לא הוזמנו. לא תמיד.

לקח לנו זמן מביך של המון עד שתפסנו את זה. תגובת ה-HTTP הייתה 200 כי ההודעה נמסרה בהצלחה. אבל בתוך גוף התגובה, קוד סטטוס הסגמנט של ה-GDS היה UC — Unable to Confirm. המלון דחה את הבקשה, בדרך כלל כי הזמינות במטמון הייתה מיושנת. החדר נמכר באלפיות השנייה שבין החיפוש לניסיון ההזמנה.

הניתוק בין שכבת התעבורה לשכבת האפליקציה הוא מלכודת קלאסית, וצעדנו היישר לתוכה. 200 OK ברמת HTTP אמר "ההודעה שלך הגיעה". UC ברמת ה-GDS אמר "ההזמנה שלך נכשלה". המערכת שלנו קראה את המעטפה והתעלמה מהמכתב שבפנים.

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

סוכן בינה מלאכותית לעולם אינו רשאי להפיק הודעת אישור אלא אם כן ניתח את קוד סטטוס הסגמנט הספציפי של ה-GDS ואימת אותו כ-HK — Holding Confirmed. כל דבר אחר הוא כשל, לא משנה מה כותרת ה-HTTP אומרת.

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

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

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

כאן מערכות אג'נטיות מוכיחות את ערכן. הפער בין "צפייה להזמנה" (Look-to-Book) הוא נפוץ מאוד בעולם התיירות — אתם מחפשים, רואים זמינות, לוחצים הזמן, והחדר נעלם. קורה כל הזמן בעונות השיא. לבינה מלאכותית מבוססת wrapper אין אוצר מילים למצב הזה. היא אומרת או "הזמנתי אותו!" (שגוי) או "זה נכשל" (לא מועיל). היא אינה יכולה לומר "הוא היה שם לפני רגע, אבל מישהו אחר חטף אותו — הנה האפשרות הבאה הטובה ביותר עבורך".

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

בעיית הנרמול שאף אחד לא מדבר עליה

דבר אחד שהפתיע אותי — הפתיע אותי באמת — היה כמה שונים מבני הנתונים בין Amadeus ל-Sabre. Amadeus מחזיר מחירים מפורקים לבסיס, סה"כ ומסים ב-JSON מקונן קפדני. Sabre לעתים כולל מס, לעתים לא, בהתאם לתוכנית התעריפים. שמות השדות שונים. amount במערכת אחת הוא totalPrice במערכת אחרת.

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

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

"פשוט תשתמש ב-GPT" — ודברים אחרים שמשקיעים אומרים

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

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

RAG מסייע עם ידע סטטי — "מהי מדיניות הוויזה לתאילנד?" — אבל הוא אינו יכול לומר לכם אם לטיסה AA123 יש מושבים זמינים עכשיו. כוונון עדין מסייע עם טון ואוצר מילים תחומי, אבל הוא אינו מחבר את המודל למלאי חי. system prompt טוב יותר מסייע עם עיצוב, אבל הוא אינו מונע מהמודל לייצר שם מלון שאינו קיים באף GDS.

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

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

ומה לגבי החלק האיטי?

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

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

האם זה מהיר כמו wrapper שממציא תשובה בשתי שניות? לא. האם זה מהיר כפי שצריך להיות עבור משתמש שרוצה תשובה אמיתית? כן.

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

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

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

לאן זה הולך הלאה

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

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

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

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