תכנון סוכנים דטרמיניסטיים בעידן הפרובביליסטי
סוכני LLM טהורים נכשלים ב-99.4% מהמקרים בזרימות עבודה ארגוניות מורכבות. התעשייה ערבבה בין צ'אטבוטים לסוכנים, עוטפת מודלים פרובביליסטיים בשכבות תזמון דקות ומצפה שיתפקדו כ מנמקים אוטונומיים. זוהי "אשליית העוטף".
התזמור הנוירו-סימבולי של Veriprajna משיג שיעורי הצלחה של 97% באמצעות הפרדת ההסקה הקוגניטיבית מזרימת הבקרה—הטמעת מודלי LLM בתוך גרפים נוקשים בקידוד קשיח (hard-coded), עם פריימוורקים כמו LangGraph.
Veriprajna שותפה לארגונים שמפעילים בינה מלאכותית סוכנית (agentic AI) לזרימות עבודה קריטיות למשימה—הזמנת נסיעות, טרנזקציות פיננסיות, לוגיסטיקה של שרשרת אספקה, ושילוב מערכות legacy.
עברו מ"אב טיפוס (Proof of Concept)" לייצור. הארכיטקטורה הנוירו-סימבולית שלנו מחסלת את פער האמינות ומשיגה זמינות של 99.9% לזרימות עבודה stateful שעוטפי LLM טהורים אינם מסוגלים לספק.
הפסיקו להילחם בלולאות הזיה ובסחף הקשר. מכונות המצבים של LangGraph מעניקות לכם שליטה מדויקת בביצוע זרימת העבודה, תוך ניצול מודלי LLM להבנת שפה טבעית.
הפחיתו את עלויות ה-API של LLM ב-90% באמצעות אופטימיזציה של טוקנים. הארכיטקטורה שלנו מונעת לולאות הזיה יקרות ומעבירה אל ה-LLM רק את הנתונים החיוניים—לא תגובות API גולמיות בהיקף 50KB.
האמונה שאפשר לכפות על מודל סטוכסטי התנהגות דטרמיניסטית באמצעות הנדסת פרומפטים בלבד.
מודלי LLM מנבאים את הטוקן הבא על בסיס סבירות סטטיסטית. בכתיבה יוצרת זו תכונה; בשרשראות של טרנזקציות API זהו כשל מערכתי. "סבירות לכאורית" ≠ "נכונות".
אם כל שלב מצליח ב-90% מהמקרים, לזרימת עבודה של 10 שלבים יהיה שיעור הצלחה של 34% בלבד. הזמנת טיסה כוללת 10+ פעולות—חיפוש, סינון, תמחור, יצירת PNR, תשלום, הנפקת כרטיסים.
זרימת בקרה אינה משימת שפה. ההחלטה "מה לעשות כעת" צריכה להיות לוגיקה מותנית, לא חיזוי טוקנים. העבירו את האינטליגנציה מהתזמור אל צמתי העלה.
"ככל שמורכבות המשימה גדלה באופן ליניארי, ההסתברות לכישלון גדלה אקספוננציאלית בארכיטקטורות LLM טהורות. זו אינה סוגיה של 'פרומפטינג טוב יותר'—זהו חוסר התאמה מהותי בין הארכיטקטורה של המודל (חסר-מצב, מבוסס-קשב) לבין דרישות המשימה (עם-מצב, מבוססת-לוגיקה)."
— Whitepaper טכני של Veriprajna, 2025
שרשור טורי של כלים יוצר סיכון כישלון אקספוננציאלי. כאשר LLM מתזמר זרימות עבודה מרובות שלבים, כל החלטה מצטברת בשיעור השגיאה.
זרימת עבודה של הזמנת טיסה כוללת: חיפוש → סינון → בחירת הצעה → נעילת מחיר → יצירת PNR → פרטי נוסעים → תשלום → הנפקת כרטיסים. זהו רצף טורי של 8+ שלבים שבו שגיאה בודדת מתגלגלת במורד הזרימה.
התאימו את המחוונים כדי לראות כיצד הדיוק בכל שלב ומורכבות זרימת העבודה משפיעים על הסתברות ההצלחה הכוללת.
דיוק אופייני של LLM למשימות הסקה מורכבות
הזמנת טיסה דורשת בדרך כלל 10-15 שלבים
תחום הנסיעות נמצא בנקודת המפגש של אילוצים אנושיים "מבולגנים" ואילוצי מערכת "נוקשים"—מה שהופך אותו לכור ההיתוך המושלם לבחינת יכולות סוכניות (agentic).
| מדד | GPT-4 (LLM טהור) | סוכן נוירו-סימבולי | שיפור |
|---|---|---|---|
| שיעור הצלחה כולל | 0.6% | 97.0% | 161× טוב יותר |
| שיעור מעבר של אילוצים קשיחים | ~4.4% | ~99.0% | 22× טוב יותר |
| שיעור מסירה | ~93% | 100% | +7% |
| שיעור מעבר של היגיון בריא | ~63% | ~100% | +37% |
כאשר הסוכן מבצע איטרציות על שלבי התכנון, חלון ההקשר מתמלא בנתוני ביניים ומדלל את הקשב. בשלב 10, המודל "שוכח" את התקציב שחושב בשלב 4.
שגיאה עדינה בשלב 2 (קריאה שגויה של שעת ההגעה כ-2:00 PM במקום 2:00 AM) מתפשטת במורד הזרימה. הסוכן מזמין מלון ליום הלא נכון ובכך מחזק את שגיאתו שלו.
שרשרת החשיבה (Chain of Thought) של המודל מזהה נכונה "מצא טיסה עד $500", אך קריאת הכלי שלאחר מכן מזמינה טיסה ב-$600 מכיוון שזו הופיעה בולטת בתוצאות החיפוש.
הזמנת טיסה איננה בקשת REST GET פשוטה. זו אינטראקציה מורכבת של מכונת מצבים סופית (FSM) מול מערכות GDS כמו Sabre, Amadeus ו-Travelport—שתוכננו בעידן המיינפריים ואינן סובלות עמימות.
ביצוע אימות לקבלת טוקן סשן. חובה להעביר אותו בכל כותרת (header) שלאחר מכן. אם ה-LLM שוכח או מזייה, כל ההקשר אובד.
ה-GDS מחזיר JSON מקונן של 50KB+ עם "Offers" חלפיים. מודלי LLM משמיטים לעיתים קרובות את ה-offerId הקריטי הדרוש לשלב הבא בעת הסיכום.
הקלטים חייבים להתאים bit-for-bit לפלטים של ה-Search. מודלי LLM מבצעים "תיקון אוטומטי" לפורמטי תאריכים או קודי מחיר, ושוברים את השלמות הקריפטוגרפית.
תת-שגרה מרובת שלבים עם סדר נוקשה. אי אפשר לבצע commit (ET) לפני הוספת "Received From" (RF). מודלי LLM מפרים את הסדר ומקבלים ERR 1209.
שגיאות GDS הן לעיתים רחוקות תיאוריות. "UC" (Unable to Confirm) או "NO RECAP" אינם מעניקים ל-LLM שום רמז סמנטי. הוא מנסה שוב ושוב את אותה בקשה בדיוק, ושורף טוקנים בלולאות אינסופיות.
צומת ErrorHandler בקידוד קשיח ממפה קודי שגיאה ספציפיים לאסטרטגיות התאוששות. "UC" מפעיל את זרימת העבודה Re-Shop. ה-LLM נעקף לחלוטין במהלך ההתאוששות.
מיזוג בין קונקשיוניזם (רשתות נוירונים) לבין סימבוליזם (לוגיקה/כללים). ה-LLM הוא שכבת הממשק. הגרף הוא שכבת הביצוע.
מצטיין ב תפיסה: זיהוי תבניות, התאמה מטושטשת (fuzzy matching), הבנת שפה טבעית. מצטיין בהבנת מה שהמשתמש מתכוון אליו כשהוא אומר "אני רוצה טיסה שלא מוקדמת מדי."
מצטיין ב הסקה: ביצוע כללים, לוגיקה, אריתמטיקה ועקביות. מצטיין בהבטחה ש אם A > B, אז C. מבטיח קיום אילוצים.
תוכנה מסורתית משתמשת בצינורות ליניאריים. זרימות עבודה סוכניות דורשות מחזוריות—את היכולת לנסות, להיכשל, לנתח ולנסות שוב.
מבנה נתונים בעל טיפוס (Pydantic/TypedDict) משמש כ"זיכרון." נשמר לאורך כל זרימת העבודה. ה-LLM אינו יכול לדרוס את session_id אלא אם קיבל הרשאה מפורשת.
יחידות עבודה דטרמיניסטיות. צמתי Agent קוראים ל-LLMs. צמתי Tool קוראים ל-APIs. צמתי Logic מריצים Python. קריאות API נבנות מתוך משתני State מאומתים.
האינטליגנציה של הניתוב מתגוררת כאן, לא ב-LLM. פונקציית Python בוחנת את ה-State ומחזירה את שם הצומת הבא. דטרמיניסטי, לא פרובביליסטי.
יכולות מוכנות לייצור שעוטפי LLM טהורים אינם מסוגלים לספק
זרימות עבודה ארוכות (משתמש מתחיל הזמנה, נקטע, חוזר רק בעוד שעות). LangGraph שומר את ה-State למסד הנתונים אחרי כל מעבר בין צמתים.
מטרת ה-AI הארגוני: פרודוקטיביות מוגברת, לא אוטונומיה מלאה. רגעים משפטיים/תפעוליים דורשים שיקול דעת אנושי. LangGraph הופך זאת לפרימיטיבה טבעית.
חוק ה-AI של האיחוד האירופי (EU AI Act) מחייב שקיפות עבור AI בסיכון גבוה (טרנזקציות פיננסיות). עקבות ביצוע של LLM טהור הן בלגן של טוקנים. Veriprajna מספקת יומני ביצוע צמתים קריאים.
סוכני LLM טהורים יקרים מבחינה חישובית. לולאות הזיה מייצרות אלפי טוקנים. סשן תקוע בודד יכול לעלות $5-$10 בקרדיטים של API.
מערכת ברמת ייצור המסוגלת לתקשר עם GDS של Sabre/Amadeus באמצעות גרפי מצבים היררכיים
משתמש ב-LLM לניתוח קלט בשפה טבעית. מטרה: מילוי SearchCriteria ב-State. משתמש ב-Guided Generation (JSON Mode) כדי לאלץ פלט לפי סכימה ספציפית.
מבצע חיפוש GDS באמצעות SearchCriteria מאומת. קורא ל-API של Amadeus. ה-LLM נעקף לחלוטין—האינטראקציה היא קוד טהור.
ממיר JSON גולמי להודעה ידידותית למשתמש. הפרומפט מורה בהקפדה להציג נתונים מה-JSON בלבד—אסור להמציא הטבות או לשנות מחירים.
בודק כללים עסקיים לפני הטרנזקציה. האם המחיר עומד במדיניות החברה? האם חברת התעופה נמצאת ברשימה השחורה?
מבצע את רצף יצירת ה-PNR: AddSegments → AddPassenger → PricePNR (השוואה מול cached) → CommitPNR.
המערכת שהשיגה 97% הצלחה ב-TravelPlanner לא השתמשה ב-LLM "טוב יותר". היא השתמשה ב ארכיטקטורה נוירו-סימבולית.
ה-LLM טופל כ מתרגם, לא כ מתכנן. סולבר (Solver) דטרמיניסטי ביצע את החיפוש והאופטימיזציה, תוך שמירת המצב במשתנים—לא בטוקנים.
שלושה מצבי כישלון מצטברים גורמים לסוכני LLM טהורים להגיע ל-0.6% הצלחה בלבד ב-Benchmark של TravelPlanner. ראשית, שרשרת ההסתברות: אם כל שלב מצליח ב-90% מהמקרים, לזרימת עבודה של 10 שלבים יהיה שיעור הצלחה של 34% בלבד (0.9 בחזקת 10). הזמנת טיסה דורשת 10+ פעולות טוריות. שנית, סחף הקשר: ככל שחלון ההקשר מתמלא בנתוני ביניים, קשב ה-softmax מתפזר דק מדי, והסוכן 'שוכח' אילוצים כמו מגבלות תקציב שנקבעו בשלבים מוקדמים. שלישית, מפל הזיות: שגיאה עדינה בשלב 2 (קריאה שגויה של 2:00 AM כ-2:00 PM) מתפשטת בכל השלבים שבמורד הזרימה, כאשר הסוכן מחזק את שגיאותיו שלו. הבעיה היסודית היא ארכיטקטונית: זרימת בקרה (ההחלטה מה לעשות כעת) היא משימת לוגיקה, לא משימת שפה.
ההיפוך הארכיטקטוני המרכזי הוא התייחסות ל-LLM כמתרגם (תפיסה), לא כמתכנן (שליטה). בארכיטקטורה של Veriprajna: זרימת בקרה משתמשת בקשתות גרף דטרמיניסטיות (לוגיקה מותנית של Python), לא בחיזוי טוקנים פרובביליסטי. שימור מצב משתמש בסכימות מסד נתונים מפורשות בעלות טיפוס (Pydantic/TypedDict), לא בהיסטוריית צ'אט מרומזת. אינטראקציית API משתמשת ב-JSON מיוצר-קוד בטוח-טיפוסים, לא במטענים מיוצרי-LLM הנוטים לשגיאות פורמט. התאוששות משגיאות משתמשת באסטרטגיות דטרמיניסטיות ממופות, לא בלולאות 'לנסות ולקוות'. ה-LLM מטפל במה שהוא מצטיין בו — חילוץ נתונים מובנים משפה טבעית, פתרון התייחסויות עמומות ויצירת סיכומים ידידותיים לאדם. הגרף מטפל במה שדורש דטרמיניזם — אימות תקציב, סידור קריאות API ובדיקת אילוצים. הדבר מחסל את סחף הקשר, כי האילוצים חיים במשתני State בעלי טיפוס, לא בחלונות קשב.
LangGraph מספק ארבע יכולות ארגוניות קריטיות. שימור ונקודות צ'קפוינט (Persistence and Checkpointing): ה-State נשמר למסד הנתונים אחרי כל מעבר בין צמתים, מה שמאפשר התחדשות סשן שעות לאחר מכן ודיבוג נסיעה בזמן שבו המהנדסים יכולים לטעון כל צ'קפוינט ולשחזר את הביצוע. אדם בלולאה (HITL): דפוסי הפרעה טבעיים שבהם הגרף מושהה בשערי האישור (למשל, כשעלות הטיסה חורגת ממגבלת המדיניות של $1,000), שולח אימייל למנהל וממשיך רק לאחר אישור אנושי. מסלול ביקורת וציות: יומני ביצוע צמתים מראים בדיוק מדוע קיבלה כל החלטה, בהתאמה לדרישות השקיפות של חוק ה-AI של האיחוד האירופי עבור AI בסיכון גבוה. אופטימיזציית עלויות: מטפלי שגיאות בקידוד קשיח מונעים לולאות הזיה (שעולות $5-$10 לכל סשן תקוע), ודחיסת הקשר מונעת-קוד מפחיתה את השימוש בטוקנים ב-90% — העברת 5 שדות רלוונטיים בלבד אל ה-LLM במקום תגובות GDS גולמיות של 50KB.
ההבדל הוא הגרף. המתודולוגיה הנוירו-סימבולית של Veriprajna לא רק משפרת את שיעורי ההצלחה—היא משנה באופן יסודי את הארכיטקטורה של מערכות אוטונומיות.
קבעו ייעוץ כדי לתכנן ארכיטקטורה של agentic AI ברמת ייצור עבור זרימות העבודה הארגוניות שלכם.
דוח הנדסי מלא: ארכיטקטורת LangGraph, תכנון סכימת State, ניתוח Benchmark של TravelPlanner, דפוסי שילוב GDS, זרימות HITL, ציות לחוק ה-AI של האיחוד האירופי, וביבליוגרפיה מקיפה.