הכרח הנוירו-סימבולי: ארכיטקטורת סוכנים דטרמיניסטיים בעידן הסתברותי

תקציר מנהלים

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

Veriprajna ממקמת את עצמה כתרופה לשבריריות ארכיטקטונית זו. באמצעות ניתוח מעמיק של מדדי תעשייה—במיוחד שיעור ההצלחה הקטסטרופלי של 0.6% של GPT-4 בהערכות TravelPlanner—ולמידה מעמיקה של מערכות לגאנית מורכבות כמו מערכות הפצה גלובליות (GDS), קבענו מתודולוגיה חדשה לבינה מלאכותית ארגונית: תזמור נוירו-סימבולי . נייר עמדה זה טוען שהמסלול לבינה מלאכותית סוכנית אמינה לא נמצא במודלים גדולים יותר או בחלונות הקשר ארוכים יותר, אלא בניתוק ההנמקה הקוגניטיבית מזרימת הבקרה . על ידי הטמעת LLMs הסתברותיים בתוך גרפים קשיחים ומקודדים-קשיח באמצעות מסגרות כמו LangGraph, ארגונים יכולים להשיג את הטוב משני העולמות: הגמישות של בינה מלאכותית גנרטיבית לחילוץ נתונים ואמינות בלתי-מתפשרת של מכונות מצב סופיות (FSMs) לביצוע תהליכים.

1. אשליית העוטף: פירוק מחזור ההייפ ה"סוכני"

העלייה המהירה של בינה מלאכותית גנרטיבית, בהובלת ארכיטקטורת הטרנספורמר, דמוקרטיזציה של גישה ליכולות הבנת שפה טבעית (NLU) שהיו בעבר תחום מעבדות מחקר מיוחדות. דמוקרטיזציה זו, אולם, יצרה ביטחון מוקדם מדי באוטונומיה של המודלים. התעשייה חזתה התפוצצות של מסגרות "סוכן"—AutoGPT, BabyAGI ויישומים נאיביים של ReAct (Reasoning + Acting)—שפעלו על הנחה מפתה אך פגומה: ש-LLM, עם מטרה ברמה גבוהה וערכת כלים, יכול לגזור אוטונומית את רצף הפעולות האופטימלי להשגת כל מטרה.

1.1 סמנטיקת הכשל

הבעיה המרכזית נמצאת בפער הסמנטי בין "סבירות" לבין "נכונות". LLMs הם מנועים הסתברותיים שתוכננו לחזות הטוקן הבא ברצף על בסיס הסבירות הסטטיסטית. ¹ בכתיבה יצירתית או במשימות שיחה, אופי הסתברותי זה הוא יתרון, שמאפשר יצירתיות וניואנס. בזרימות עבודה ארגוניות—כמו לוגיסטיקה של שרשרת אספקה, ביקורת פיננסית או הזמנת נסיעות—יתרון זה הופך לבאג קריטי. כאשר LLM "ממציא" (hallucinates), הוא למעשה מבצע חיזוי סטטיסטית סביר אך שגוי מבחינה עובדתית. בממשק צ'אט, זה מטרד; בשרשרת עסקאות API, זה כשל מערכת. ²

Veriprajna מגדירה תופעה זו כ**"אשליית העוטף"** : האמונה שמודל סטוכסטי יכול להיות כפוי לתנהגות דטרמיניסטית באמצעות הנדסת פרומפטים בלבד. מחקרנו מצביע שככל שמורכבות המשימה גדלה ליניארית, הסבירות לכשל גדלה אקספוננציאלית בארכיטקטורות LLM טהורות. זה לא רק עניין של "פרומפטים טובים יותר"; זו אי-התאמה יסודית בין ארכיטקטורת המודל (ללא מצב, מבוססת-תשומת-לב) לדרישות המשימה (עם מצב, מבוססת-לוגיקה). ³

1.2 מלכודת הסטוכסטיות של שרשור סדרתי

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

אם נניח ש-LLM פועל נכון 90% מהזמן (הערכה נדיבה למשימות הנמקה מורכבות), האמינות המתמטית של זרימת עבודה רב-שלבית מתדרדרת במהירות.

●​ שלב 1: 90% סבירות הצלחה

●​ 5 שלבים: $0.90^5 \approx 59%$ סבירות הצלחה

●​ 10 שלבים: $0.90^{10} \approx 34%$ סבירות הצלחה

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

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

1.3 עמדת Veriprajna: לוגיקה אינה משימה לשונית

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

הפילוסופיה שלנו מעבירה ה"אינטליגנציה" משכבת התזמור לצמתי הענף. ה LLM צריך להיות העובד —מחלץ נתונים, מסכם טקסט, מעצב JSON—בעוד המנהל (לוגיקת התזמור) צריך להיות תוכנה מקודדת-קשיח. הבחנה זו היא הבסיס של הגישה הנוירו-סימבולית, וזה המסלול היחיד לאמינות של 99.9% במערכות סוכניות. ⁸

2. המציאות האמפירית: ניתוח מדד TravelPlanner Benchmark

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

2.1 ממצאי מדד TravelPlanner

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

מדד	GPT-4 (LLM טהור)	סוכן נוירו-סימבולי (מונע-קוד)
שיעור הצלחה כולל	0.6%	97.0%
עמידה באילוצים קשיחים שיעור	~4.4%	~99.0%
שיעור אספקה	~93%	100%

נתונים מסונתזים מ. ⁵

הפער החד בין 0.6% ל97% לא יכול להיות מוגזם. הוא מייצג ההבדל בין מחולל מספרים אקראי ומוצר תוכנה תפקודי.

2.2 ניתוח פוסט-מורטם של כשל

מדוע המודל המתקדם בעולם נכשל 99.4% מהזמן? הכשל אינו לשוני; GPT-4 מבין הבקשה בצורה מושלמת. הכשל הוא סיבולת קוגניטיבית ו תחזוקת מצב .

2.2.1 תופעת סחף ההקשר

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

2.2.2 מפולת ההזיות

בארכיטקטורה של שרשרת כלים, הפלט של שלב אחד הופך להקלט של הבא. אם הסוכן עושה שגיאה עדינה בשלב 2—למשל, קורא שעת הגעה של טיסה כ-2:00 PM במקום 2:00 AM—הוא מפיץ השגיאה במורד הזרם. הוא עשוי להזמין צ'ק-אין למלון ביום הלא נכון על בסיס השעה המדומיינת. API של GDS לא יודע את הכוונה של הסוכן, רק את ההקלט, ולכן מעבד הבקשה. הסוכן, לראות תגובת API מוצלחת, מחזק את השגיאה שלו. מפולת ההזיות יוצרת עקב ביצוע "מוצלח" שמסתיים בתוצאה קטסטרופית בעולם האמיתי. ²

2.2.3 "אי-התאמה הנמקה-פעולה"

מדדים חושפים "אי-התאמה הנמקה-פעולה" תכופה, שבה המונולוג הפנימי של המודל (Chain of Thought) מזהה נכון אילוץ, אבל קריאת הכלי הבאה מפרה אותו. המודל עשוי "לחשוב": אני צריך למצוא טיסה מתחת ל-$500, אבל אז ליצור קריאת כלי לטיסה שעולה $600 כי טיסה זו הופיעה בולטת יותר בהקשר תוצאות החיפוש. ניתוק זה מדגיש השבריריות של שימוש ביצירת טקסט כתחליף ל ביצוע לוגיקה. ¹³

2.3 התיקון הנוירו-סימבולי

המערכת שהשיגה 97% הצלחה לא השתמשה ב-LLM "טוב יותר". היא השתמשה בארכיטקטורה נוירו-סימבולית . היא ניצלה ה-LLM לפרסור הבקשה של המשתמש לשאילתה מובנית, אבל אז העבירה השאילתה לSolver (אלגוריתם דטרמיניסטי) לביצוע החיפוש ו האופטימיזציה. ה-LLM התייחס כ"מתרגם," לא כ"מתכנן. שינוי ארכיטקטוני זה מבטל סחף הקשר כי ה-solver שומר המצב (תקציב, תאריכים) במשתנים, לא בטוקנים. ¹⁰

3. מבחן המורכבות: מערכות הפצה גלובליות (GDS)

כדי להבין מדוע Veriprajna תומכת בגרפים מקודדים-קשיח, אחד חייב להעריך סביבת APIs ארגוניים עוינת. הזמנת טיסות אינה בקשת REST GET פשוטה; זו אינטראקציה מורכבת עם מערכות הפצה גלובליות (GDS) כמו Sabre, Amadeus ו Travelport. מערכות אלה, שתוכננו בעידן המיינפריים, לא סובלות עמימות.

3.1 מכונת המצב של GDS: מורשת הקשיחות

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

1.​ איתחול סשן (אימות): ​ התהליך מתחיל באימות מול GDS לקבלת טוקן סשן. טוקן זה מייצג "Workbench" או "State." הוא חייב להיות מועבר במפורש בכל כותרת עוקבת. אם LLM "שוכח" לכלול טוקן זה, או ממציא אחד חדש, כל הקשר העסקה אובד.¹⁵

2.​ Air Shopping (חיפוש וניהול הצעות): ​ הפקודה Air_Sell או FlightOffersSearch מחזירה רשימת "Offers." חשוב, Offer הוא אובייקט זמני. המחיר והזמינות דינמיים. GDS מחזיר מבנים מורכבים, מקוננים של JSON או XML שמכילים Fare Basis Codes, מודלים של הקצבת כבודה ו-Segment References.

○​ מצב הכשל: LLMs מתקשים לעכל payloads מסיביים (לעיתים 50kb+) מבלי לקצץ אותם. כשהם מסכמים האפשרויות למשתמש, הם לעיתים קרובות מסירים offerId או segmentReference הקריטיים לשלב הבא, מה שהופך הבחירה לבלתי-ניתנת לביצוע. ¹⁷

3.​ עסקת "Price": ​ לפני ההזמנה, אחד חייב לקרוא לנקודת קצה "Price" או "Confirm". זה נועל המלאי. ההקלטים כאן חייבים להתאים לפלטי החיפוש ביט-ביט.

○​ מצב הכשל: LLMs פועלים כ"מדחסים עם אובדן." בהעברת נתונים מ פלט החיפוש להקלט Price, הם לעיתים קרובות "מתקנים אוטומטית" או "מנרמלים" נתונים (למשל, משנים פורמט תאריך או מתקנים טעות נתפסת בקוד תעריף), מה ש שובר את יושרה קריפטוגרפית הנדרשת על ידי API. ¹⁹

4.​ יצירת PNR (Passenger Name Record): ​ יצירת PNR היא תת-שגרה רב-שלבית. אחד חייב להוסיף:

○​ מקטעי מסלול.

○​ אלמנטי שם (בפורמט קפדני: LAST/FIRST MR).

○​ אלמנטי קשר (AP - Address Phone).

○​ Ticketing Time Limit (TKTL).

○​ אלמנט "Received From" (RF).

○​ Commit Transaction (ET).

○​ מצב הכשל: הסדר חשוב. אי אפשר לבצע commit (ET) לפני הוספת

שדה "Received From" (RF). LLM, שאין לו קונספט מובנה של רצף זמני מעבר למה שלמד מנתוני אימון, לעיתים קרובות מנסה "לשמור" ההזמנה לפני שכל השדות החובה מאוכלסים, מה שמוביל לקודי שגיאה קריפטיים כמו ERR 1209 - SEQUENCE ERROR. ¹⁵

3.2 לולאת משוב קריפטית

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

●​ תגובת LLM: המודל, שאומן להיות מועיל, לעיתים קרובות מפרש השגיאה כ"תקלה" ופשוט מנסה שוב את אותה הבקשה.

●​ לולאות אינסופיות: זה מוביל ל"לולאת המוות," שבה הסוכן שורף טוקנים ומגבלות קצב API, וחוזר שוב ושוב על מחיצה שהוא לא מבין. ⁶

●​ פתרון Veriprajna: צומת ErrorHandler מקודד-קשיח בגרף ממפה קודי שגיאה ספציפיים (למשל, UC) לאסטרטגיות התאוששות ספציפיות (למשל, "Trigger Re-Shop Workflow"). ה LLM מדולג לחלוטין במהלך התאוששות זו, ומונע הלולאה. ²²

4. תחייה נוירו-סימבולית: מסגרת תיאורטית

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

4.1 הטוב משני העולמות

●​ רשתות עצביות ("מוח System 1"): מצטיינות בזיהוי תבניות, התאמה מטושטשת והבנת שפה טבעית. הן מצטיינות בתפיסה : הבנת מה המשתמש מתכוון כשאומר, "אני רוצה טיסה שלא מוקדמת מדי."

●​ בינה מלאכותית סמבולית ("מוח System 2"): מצטיינת בביצוע חוקים, לוגיקה, חשבון ו עקביות. היא מצטיינת בהנמקה : הבטחה ש_אם A > B, אז C_ .

בארכיטקטורה של Veriprajna, אנו מקצים אחריות בהתאם לחוזקות אלה:

●​ ה-LLM הוא שכבת הממשק . הוא מתרגם כוונה לא מובנית של משתמש לנתונים מובנים (JSON).

●​ הגרף הוא שכבת הביצוע . הוא מקבל הנתונים המובנים ומבצע הלוגיקה העסקית באמצעות קוד דטרמיניסטי. ⁸

4.2 מצינורות לגרפים

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

●​ LangChain (בצורתו הבסיסית) הפופלריזציה של DAG לשרשראות LLM.

●​ LangGraph מציג הגרף המחזורי, ומאפשר יצירת מכונות מצב שבהן קצוות יכולים לחזור לצמתים קודמים על בסיס לוגיקה מותנית. ²⁴

4.3 דפוס "Supervisor"

אנו מיישמים ארכיטקטורת "Supervisor" שבה מכונת מצב מרכזית מקודדת-קשיח מנהלת מחזור החיים של הבקשה. ה-LLM מורד מדירקטור ל"עובד משימה."

●​ Supervisor (גרף) קובע: "אנחנו במצב Booking. השלב הבא הוא CollectPassengerInfo."

●​ Worker (LLM) מבצע: "חלץ שם הנוסע מטקסט האימייל."

●​ Supervisor (גרף) מאמת: "השם תקין? כן. מעבר מצב לPayment."

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

5. ארכיטקטורת דטרמיניזם: מסגרת LangGraph

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

5.1 פרימיטיבים של בקרה

LangGraph פועל על שלוש קונספטים מרכזיים: State, Nodes וEdges .

5.1.1 סכימת State משותפת

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

class FlightBookingState(TypedDict):
    # The conversational history for context
    messages: Annotated[list[AnyMessage], operator.add]

    # Structured variables extracted from the conversation
    origin: Optional[str]
    destination: Optional[str]
    travel_dates: Optional

    # The GDS Session Token (Crucial for transactional integrity)
    session_id: Optional[str]

    # The selected offer object (Raw JSON from API)
    selected_offer: Optional

    # Business logic flags
    is_price_locked: bool
    manager_approval_status: Enum("PENDING", "APPROVED", "REJECTED")

סכימה זו היא "מקור האמת." היא נמשכת בכל זרימת העבודה. גם אם ה-LLM ממציא, הוא לא יכול לדרוס session_id אלא אם מאושר במפורש על ידי צומת שתוכנן לעדכן שדה זה. ²⁵

5.1.2 Nodes: יחידות עבודה דטרמיניסטיות

כל צומת בגרף הוא פונקציה Python.

●​ Agent Nodes: קוראים ל-LLM לביצוע משימה קוגניטיבית ספציפית (למשל, "Extract Dates").

●​ Tool Nodes: קוראים ל-API חיצוני (למשל, "Amadeus Search").

●​ Logic Nodes: מבצעים קוד Python טהור (למשל, "Validate Date Format").

על ידי בידוד קריאות API ל"Tool Nodes" שמבוצעים על ידי קוד Python (לא קוד שנוצר על ידי LLM), אנו מבטלים "זרקת הזיות." קריאת API נבנית באמצעות המשתנים המאומתים מState, ומבטיחה שה-payload מושלם תחבירית בכל פעם. ²⁸

5.1.3 Conditional Edges: מערכת העצבים

"אינטליגנציה" של הניתוב חיה בConditional Edges . אלה פונקציות ש בוחנות State וקובעות הצומת הבא.

●​ גישת LLM סטנדרטית: המודל מפיק "Call Search Tool." (הסתברותי).

●​ גישת LangGraph: פונקציית Edge קוראת if state.origin AND state.destination: return "Search_Node" else: return "Ask_User_Node". (דטרמיניסטי).

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

5.2 התמדה ו-Checkpointing

זרימות עבודה ארגוניות רצות זמן רב. משתמש עשוי להתחיל הזמנה, להיעצר ו לחזור שעות אחרי. תכונת Checkpointing של LangGraph שומרת המצב למסד נתונים (למשל, Postgres, Redis) אחרי כל מעבר צומת.

●​ המשך סשן: כשהמשתמש חוזר, הגרף טוען מחדש המצב המדויק מ המסד נתונים. הוא יודע בדיוק איפה הפסיק (למשל, "Waiting for Payment"). הוא לא צריך לקרוא מחדש את כל היסטוריית הצ'אט ולגזור מחדש ההקשר; ההקשר מובנה ו שמור. ²⁷

●​ דיבוג Time Travel: אם סוכן נכשל בייצור, מפתחים יכולים לטעון checkpoint ממש לפני הכשל ולהריץ מחדש ביצוע הצומת לאבחון הבעיה. אפשרות תצפית זו בלתי אפשרית עם שרשראות LLM בתיבה שחורה. ²⁶

6. תוכנית Veriprajna: מקרה בוחן בהזמנת טיסות עמידה

כדי להדגים יישום מעשי של עקרונות אלה, אנו מציגים סוכן טיסות Veriprajna ארכיטקטורת ייחוס Reference . זה לא מודל תיאורטי; זו תוכנית ל מערכת ברמה ייצורית שמסוגלת לאינטראקציה עם Sabre/Amadeus GDS.

6.1 סקירת ארכיטקטורה

המערכת מתוכננת כגרף מצב היררכי .

●​ Master Graph: מטפל בניתוב ברמה גבוהה (הזמן טיסה מול בטל טיסה מול FAQ).

●​ Sub-Graph (הזמנת טיסה): מטפל ב-FSM הספציפי של תהליך ההזמנה.

6.2 סקירת צמתים מפורטת

צומת 1: "Collector" (שכבה קוגניטיבית)

●​ פונקציה: צומת זה משתמש ב-LLM לפרסור הקלט בשפה טבעית של המשתמש.

●​ מטרה: לאכלס SearchCriteria ב-State.

●​ טכניקה: אנו משתמשים בGuided Generation (למשל, JSON Mode או Function Calling) כדי לאלץ ה-LLM להפיק סכימה ספציפית: {origin: str, dest: str, date: str}.

●​ אימות: מאמת Python בודק אם קודי שדה תעופה תקינים (למשל, "LHR" תקין, "London" עמום). אם עמום, הגרף חוזר לצומת "Disambiguation", ומבקש מהמשתמש להבהיר "Heathrow או Gatwick?". ה-LLM לא מורשה לנחש. ⁷

צומת 2: "Retriever" (שכבת כלים)

●​ פונקציה: מבצע חיפוש GDS.

●​ הקלט: SearchCriteria המאומת מ-State.

●​ פעולה: קורא ל-Amadeus.shopping.flight_offers_search.get().

●​ לוגיקה:

○​ אם Response == 200: שמור JSON גולמי ל-state.flight_cache. מעבר לSummarizer.

○​ אם Response == Empty: מעבר לצומת BroadenSearch (שמציע +/- 3 ימים).

○​ אם Response == Error: מעבר ל-GDS_ErrorHandler.

●​ תובנה מרכזית: ה-LLM מדולג לחלוטין כאן. האינטראקציה עם API היא קוד טהור.

צומת 3: "Summarizer" (שכבה קוגניטיבית)

●​ פונקציה: ממיר JSON גולמי להודעה ידידותית למשתמש.

●​ הקלט: 5 ההצעות הטובות מ-state.flight_cache.

●​ אילוץ: פרומפט ה-LLM מורה בקפדון להציג רק נתונים קיימים ב JSON. אסור להמציא הטבות או לשנות מחירים.

●​ פלט: "מצאתי 5 טיסות. האפשרות הטובה ביותר היא United ב-$450..."

צומת 4: "Selector" (שכבת מצב)

●​ פונקציה: לוכד בחירת המשתמש.

●​ פעולה: המשתמש אומר "הזמן השנייה." ה-LLM ממפה "השנייה" ל offer_id הספציפי ב-flight_cache.

●​ עדכון: state.selected_offer_id = "eJzTD9..." (ה-hash ארוך של GDS).

●​ מעבר: מעבר לPre_Booking_Validation.

צומת 5: "Gatekeeper" (שכבת ממשל)

●​ פונקציה: בודק חוקי עסק לפני עסקה.

●​ לוגיקה:

○​ המחיר בתוך מגבלת מדיניות החברה?

○​ הטיסה על נושא ברשימה שחורה?

●​ Conditional Edge:

○​ אם הפרה: ניתוב לManagerApproval (HITL).

○​ אם נקי: ניתוב לCreatePNR.

צומת 6: "Transactor" (שכבת כלים)

●​ פונקציה: מבצע רצף יצירת PNR.

●​ רצף:

1.​ AddSegments(state.selected_offer_id)

2.​ AddPassenger(state.passenger_details)

3.​ PricePNR() -> בדיקה קריטית: השוואת מחיר מוחזר מול מחיר cached.

4.​ CommitPNR()

●​ טיפול בשגיאות: אם GDS מחזיר אזהרת "Price Change" (נפוץ בנסיעות), הצומת עוצר ומנתב לצומת PriceChangeNotification, ומבקש מהמשתמש לאשר המחיר החדש. הוא לא מזמין אוטומטית בשיעור גבוה יותר. ¹⁵

6.3 טבלה: ארכיטקטורה Veriprajna מול עוטף סטנדרטי

תכונה	עוטף LLM סטנדרטי	Veriprajna (גרף נוירו-סימבולי)
זרימת בקרה	הסתברותי (LLM קובע השלב הבא)	דטרמיניסטי (קצוות גרף קובעים)
התמדת מצב	מרומז (היסטוריית צ'אט)	מפורש (מגובה-מסד נתונים סכימה)
אינטראקציה GDS	LLM מייצר גוף JSON (נוטה לשגיאות)	קוד מייצר גוף JSON (Type-safe)
התאוששות משגיאות	"אני מתנצל, נכשלתי." (מוותר) "Error 8102 זוהה.	מנסה שוב עם Format B." לולאות
סיכון לולאה אינסופית (ניקוז	טוקנים) לולאות מבוקרות עם	Max_Retries רגולציה
"תיבה שחורה" אטומה	עקב ביקורת מלא של צמתי	לוגיקה 7. האלמנט האנושי: ממשל ו-HITL

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

רגעים שבהם שיפוט אנושי נדרש משפטית או תפעולית. שרשראות LLM טהורות מתקשות להשהות ולהמתין לאנשים; LangGraph הופך זאת לפרימיטיב מקורי. 7.1 דפוס "Interrupt"

אנו משתמשים בפונקציונליות interrupt_before של LangGraph ליצירת "Airgaps" בזרימת העבודה.

●​ תרחיש: טיסה עולה $2,000. מדיניות דורשת אישור מנהל.

●​ מנגנון: הגרף מבצע עד צומת Booking. Conditional Edge מזהה

price > 1000. הוא מפעיל Interrupt . ●​ הקפאת מצב: הגרף מושהה ביצוע. State נשמר למסד הנתונים. ה

זיכרון משוחרר. ●​ פעולה מחוץ לרשת: המערכת שולחת אימייל למנהל עם קישור.

●​ המשך: המנהל לוחץ "Approve." API שולח אות ל

Supervisor של הגרף. הגרף טוען מחדש State, מעדכן approval_status = APPROVED, ו

ממשיך זרימת העבודה בצומת Booking. 7.2 עקב ביקורת ורגולציה ²⁹

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

(שכוללות עסקאות פיננסיות כמו הזמנת נסיעות). ●​ בעיית העוטף: עקב LLM הוא רק ערימת טוקנים. קשה להוכיח מדוע

הסוכן הזמין טיסה ספציפית. ●​ פתרון הגרף: Veriprajna מספקת יומן ביצוע צמתים .

○​ רשומת יומן: [2023-10-27 14:00:01] Node:Gatekeeper | Input: Price=1200 | Rule:

Policy_Limit=1000 | Output: REJECT_NEED_APPROVAL ○​ יומן זה קריא לביקורת. הוא מוכיח שהמערכת פעלה בהתאם למדיניות

ממשל דטרמיניסטית. 8. הטיעון הכלכלי: יעילות ועלות ³⁴

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

LLM טהורים יקרים מבחינה חישובית. 8.1 עלות לולאות הזיות

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

הוא מייצר אלפי טוקנים קלט/פלט. סשן "תקוע" בודד יכול לעלות $5-$10 בקרדיטים API לפני timeout. באמצעות מטפלי שגיאות מקודדים-קשיח, Veriprajna מונע לולאות אלה. השגיאה נתפסת על ידי קוד (עלות 0), מנותחת ומתוקנת. ה-LLM נקרא רק כשהכרחי לחלוטין. 8.2 אופטימיזציה של טוקנים²

בארכיטקטורה נוירו-סימבולית, אנו לא צריכים להזין ל-LLM את כל תגובת GDS של 50kb.

תגובה. צומת "Fetcher" (קוד) מפרסר JSON, מחלץ 5 השדות הרלוונטיים ו מעביר רק אותם לצומת "Summarizer" (LLM). זה מפחית שימוש בחלון ההקשר ב-90%, ומוריד משמעותית עלויות inference וlatency. ³⁶

9. תחזית עתידית: אבולוציה של הגרף

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

Veriprajna חוזה את עליית פרוטוקולים סוכן סטנדרטיים —ספריות של Sub-Graphs מוכנים מראש ומאומתים למשימות נפוצות (למשל, LangGraph.Hub.FlightBooking, LangGraph.Hub.SalesforceUpdate). ארגונים ירכיבו אפליקציות על ידי חיבור גרפים מאומתים אלה, וישתמשו ב-LLMs רק כדבק לשטח ממשק שפה טבעית.

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

סיכום

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

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

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

מקורות

1. LLM Recap: LLM Limitations and how to overcome them | by Chanon Krittapholchai | Medium, נצפה ב-11 בדצמבר 2025, https://medium.com/@chanon.krittapholchai/llm-recap-llm-limitations-and-how-to-overcome-them-cecdddf9af8d

2. Why Do Multi-Agent LLM Systems Fail? Insights for Owners | SEO Locale, נצפה ב-11 בדצמבר 2025, https://seolocale.com/why-do-multi-agent-llm-systems-fail-insights-for-owners/

3. What drives Multi-Agent LLM Systems Fail ? - Hugging Face, נצפה ב-11 בדצמבר 2025, https://huggingface.co/blog/Musamolla/multi-agent-llm-systems-failure

4. Evaluating LLMs on Sequential API Call Through Automated Test Generation arXiv, נצפה ב-11 בדצמבר 2025, https://arxiv.org/html/2507.09481v2

5. TravelPlanner: A Benchmark for Real-World Planning with Language Agents arXiv, נצפה ב-11 בדצמבר 2025, https://arxiv.org/html/2402.01622v4

6. Why do Multi-Agent LLM Systems Fail - Galileo AI, נצפה ב-11 בדצמבר 2025, https://galileo.ai/blog/multi-agent-llm-systems-fail

7. [D] A contract-driven agent runtime: separating workflows, state, and LLM contract generation : r/MachineLearning - Reddit, נצפה ב-11 בדצמבר 2025, https://www.reddit.com/r/MachineLearning/comments/1phl090/d_a_contractdriven_agent_runtime_separating/

8. How Neurosymbolic AI Brings Hybrid Intelligence to Enterprises - Orange Bridge Marketing, נצפה ב-11 בדצמבר 2025, https://orange-bridge.com/latest-ai-data-trends/neurosymbolic-ai-promises-to-bring-hybrid-intelligence-to-enterprises

9. Neurosymbolic Programming for AI Agents | by Dorian Smiley - Medium, נצפה ב-11 בדצמבר 2025, https://dorians.medium.com/neurosymbolic-programming-for-ai-agents-2720257db7f3

10. CHINATRAVEL: A REAL-WORLD BENCHMARK FOR LANGUAGE AGENTS IN CHINESE TRAVEL PLANNING - OpenReview, נצפה ב-11 בדצמבר 2025, https://openreview.net/pdf?id=9dfRC2dq0R

11. TravelPlanner Benchmark - Emergent Mind, נצפה ב-11 בדצמבר 2025, https://www.emergentmind.com/topics/travelplanner-benchmark

12. ChinaTravel: A Real-World Benchmark for Language Agents in Chinese Travel Planning, נצפה ב-11 בדצמבר 2025, https://arxiv.org/html/2412.13682v2

13. Why Do Multi-Agent LLM Systems Fail? - arXiv, נצפה ב-11 בדצמבר 2025, https://arxiv.org/pdf/2503.13657

14. Why Do Multi-Agent LLM Systems Fail? - OpenReview, נצפה ב-11 בדצמבר 2025, https://openreview.net/pdf?id=MqBzKkb8eK

15. Air Booking Guide - Support, נצפה ב-11 בדצמבר 2025, https://support.travelport.com/webhelp/JSONAPIs/Airv11/Content/Air11/Book/BookingGuide.htm

16. Sabre API Integration Guide for Travel Portals Flights Hotel - phptravels, נצפה ב-11 בדצמבר 2025, https://phptravels.com/blog/sabre-api-integration

17. Flight APIs Tutorial - Amadeus for Developers, נצפה ב-11 בדצמבר 2025, https://developers.amadeus.com/self-service/apis-docs/guides/developer-guides/resources/flights/

18. Sabre Air API Solutions | Flight Shopping & Pricing API - Traveltekpro, נצפה ב-11 בדצמבר 2025, https://traveltekpro.com/sabre-air-api-solutions-flight-shopping-pricing-api/

19. Toolchaining: The Problem No One is Talking About | Scale, נצפה ב-11 בדצמבר 2025, https://scale.com/blog/toolchaining-llm-plans

20. Sabre API Integration: Hands-On Experience with a Leading GDS - AltexSoft, נצפה ב-11 בדצמבר 2025, https://www.altexsoft.com/blog/sabre-api-integration/

21. How to Integrate a Flight Booking API: A Step-by-Step Guide - Traveltekpro, נצפה ב-11 בדצמבר 2025, https://traveltekpro.com/how-to-integrate-a-flight-booking-api-a-step-by-step-guide/

22. LangGraph State Machines: Managing Complex Agent Task Flows in Production, נצפה ב-11 בדצמבר 2025, https://dev.to/jamesli/langgraph-state-machines-managing-complex-agent-task-flows-in-production-36f4

23. Building Better Agentic Systems with Neuro-Symbolic AI | Cutter Consortium, נצפה ב-11 בדצמבר 2025, https://www.cuter.com/article/building-bett er-agentic-systems-neuro-symbolic-t ai

24. LangChain vs LangGraph: Explained - Peliqan, נצפה ב-11 בדצמבר 2025, https://peliqan.io/blog/langchain-vs-langgraph/

25. What is LangGraph and How It Is Useful In Building LLM-Based Applications? Ampcome, נצפה ב-11 בדצמבר 2025, https://www.ampcome.com/articles/what-is-langgraph-how-it-is-useful-in-building-llm-based-applications

26. LangChain Vs LangGraph: Best, Definitive 2025 Agents Guide, נצפה ב-11 בדצמבר 2025, https://binaryverseai.com/langchain-vs-langgraph-decision-guide-framework/

27. LangGraph State: The Engine Behind Smarter AI Workflows - CloudThat Resources, נצפה ב-11 בדצמבר 2025, https://www.cloudthat.com/resources/blog/langgraph-state-the-engine-behind-smarter-ai-workflows

28. AI Agent Workflows: A Complete Guide on Whether to Build With LangGraph or LangChain, נצפה ב-11 בדצמבר 2025, https://towardsdatascience.com/ai-agent-workflows-a-complete-guide-on-whether-to-build-with-langgraph-or-langchain-117025509fa0/

29. Why use LangGraph? : r/AI_Agents - Reddit, נצפה ב-11 בדצמבר 2025, https://www.reddit.com/r/AI_Agents/comments/1l4uq7v/why_use_langgraph/

30. LangChain vs. LangGraph: A Developer's Guide to Choosing Your AI Workflow, נצפה ב-11 בדצמבר 2025, https://duplocloud.com/blog/langchain-vs-langgraph/

31. What is LangGraph? - IBM, נצפה ב-11 בדצמבר 2025, https://www.ibm.com/think/topics/langgraph

32. Constraining LLM Outputs with Finite State Machines | by Chirag Bajaj | Medium, נצפה ב-11 בדצמבר 2025, https://medium.com/@chiragbajaj25/constraining-llm-outputs-with-finite-state-machines-79ca9e336b1f

33. Human in the Loop AI: Benefits, Use Cases, and Best Practices - WitnessAI, נצפה ב-11 בדצמבר 2025, https://witness.ai/blog/human-in-the-loop-ai/

34. What Is Human In The Loop (HITL)? - IBM, נצפה ב-11 בדצמבר 2025, https://www.ibm.com/think/topics/human-in-the-loop

35. The Human-AI Agents Partnership: In-, On-, or Out-of-the-Loop? - Lumenova AI, נצפה ב-11 בדצמבר 2025, https://www.lumenova.ai/blog/ai-agents-the-human-ai-partnership/

36. LLM Inference Optimization Techniques | Clarifai Guide, נצפה ב-11 בדצמבר 2025, https://www.clarifai.com/blog/llm-inference-optimization/

37. Effective context engineering for AI agents - Anthropic, נצפה ב-11 בדצמבר 2025, https://www.anthropic.com/engineering/efective-context-engineering-for-ai-agfents