الضرورة العصبية-الرمزية: هندسة وكلاء حتميين في عصر احتمالي

الملخص التنفيذي

يقف مشهد الذكاء الاصطناعي عند منعطف حرج، وقد انقسم بفعل سوء فهم جوهري للفرق بين القدرة والموثوقية. في أحد الجانبين يقع «روبوت الدردشة» (Chatbot)—وهو محرك احتمالي للتوليف اللغوي، قادر على محاكاة المحادثة البشرية بطلاقة مذهلة. وفي الجانب الآخر يقع «الوكيل» (Agent)—وهو منفّذ حتمي لمنطق الأعمال، مكلَّف بالتعامل مع العالم المادي والرقمي عبر تكاملات واجهات برمجة التطبيقات (API) والمعاملات المالية وتدفقات العمل ذات الحالة. وقد دأب الاتجاه السائد في الصناعة على الخلط بين هذين الكيانين المتمايزين، عبر تغليف النماذج اللغوية الكبيرة (LLMs) بطبقات تنسيق رقيقة وتوقُّع أن تؤدي دور مستدلّات مستقلة متعددة الأغراض. هذا النهج، الذي كثيرًا ما يُسمى «سلسلة الموجهات» (prompt chaining) أو نموذج «غلاف النموذج اللغوي الكبير» (LLM Wrapper)، قد أشعل أزمة موثوقية في النشر المؤسسي.

تقدّم Veriprajna نفسها بوصفها الترياق لهذه الهشاشة المعمارية. فمن خلال التحليل الدقيق لمعايير قياس الصناعة—وأبرزها معدل النجاح الكارثي البالغ 0.6% الذي سجّله GPT-4 في تقييمات TravelPlanner—والانخراط العميق مع الأنظمة القديمة المعقدة مثل أنظمة التوزيع العالمية (GDS)، قمنا بتقنين منهجية جديدة للذكاء الاصطناعي المؤسسي: التنسيق العصبي-الرمزي . وتطرح هذه الورقة البيضاء أن الطريق إلى ذكاء اصطناعي وكيلي موثوق لا يكمن في نماذج أكبر أو نوافذ سياق أطول، بل في فصل الاستدلال المعرفي عن تدفق التحكم . فمن خلال تضمين النماذج اللغوية الكبيرة الاحتمالية داخل مخططات صارمة مكتوبة برمجيًا بشكل ثابت باستخدام أطر عمل مثل LangGraph، يمكن للمؤسسات أن تحقق أفضل ما في العالمين: مرونة الذكاء الاصطناعي التوليدي لاستخراج البيانات، والموثوقية الفولاذية لآلات الحالة المحدودة (FSMs) لتنفيذ العمليات.

1. وهم الغلاف: تفكيك دورة الضجيج «الوكيلي»

إن الصعود السريع للذكاء الاصطناعي التوليدي، بقيادة معمارية المحوِّلات (transformer)، قد أتاح للجميع الوصول إلى قدرات فهم اللغة الطبيعية (NLU) التي كانت في السابق حكرًا على مختبرات البحث المتخصصة. غير أن هذه الإتاحة الواسعة ولّدت ثقة سابقة لأوانها في استقلالية هذه النماذج. فقد شهدت الصناعة انفجارًا في أطر عمل «الوكلاء»—AutoGPT وBabyAGI والتطبيقات الساذجة لنهج ReAct (الاستدلال + التصرف)—التي عملت وفق فرضية مغرية لكنها معيبة: أن النموذج اللغوي الكبير، إذا أُعطي هدفًا عالي المستوى ومجموعة من الأدوات، يمكنه أن يستنتج ذاتيًا التسلسل الأمثل من الإجراءات لتحقيق أي غاية.

1.1 دلالات الفشل

تكمن المشكلة الجوهرية في الفجوة الدلالية بين «المعقولية» و«الصحة». فالنماذج اللغوية الكبيرة محركات احتمالية مصممة للتنبؤ بالرمز (token) التالي في تسلسل ما استنادًا إلى الأرجحية الإحصائية. ¹ في الكتابة الإبداعية أو المهام الحوارية، تُعدّ هذه الطبيعة الاحتمالية ميزة، إذ تتيح الإبداع ودقة التعبير. أما في تدفقات العمل المؤسسية—مثل لوجستيات سلاسل التوريد، أو التدقيق المالي، أو حجز السفر—فتتحول هذه الميزة إلى خلل حرج. فعندما «يهلوس» النموذج اللغوي الكبير، فإنه في جوهره يقدّم تنبؤًا محتملًا إحصائيًا لكنه غير صحيح واقعيًا. في واجهة دردشة، يكون هذا مصدر إزعاج؛ أما في سلسلة معاملات عبر واجهة برمجة التطبيقات (API)، فهو فشل للنظام. ²

تُعرّف Veriprajna هذه الظاهرة باسم «وهم الغلاف» : الاعتقاد بأن نموذجًا عشوائيًا يمكن إجباره على سلوك حتمي بمجرد هندسة الموجهات وحدها. وتشير أبحاثنا إلى أنه مع تزايد تعقيد المهمة خطيًا، يتزايد احتمال الفشل أسّيًا في معماريات النماذج اللغوية الكبيرة الخالصة. وليست هذه مجرد مسألة «موجهات أفضل»؛ بل هي عدم توافق جوهري بين معمارية النموذج (عديمة الحالة، القائمة على الانتباه) ومتطلبات المهمة (ذات الحالة، القائمة على المنطق). ³

1.2 الفخ العشوائي للسَّلسَلة المتتابعة

تعتمد المنهجية السائدة لبناء الوكلاء—السَّلسَلة المتتابعة للأدوات—على النموذج اللغوي الكبير ليقوم بدور المنسّق المركزي. في هذا النموذج، يتلقى النموذج اللغوي الكبير مخرجات من الأداة A، ويقرر أي أداة يستدعيها تاليًا (الأداة B)، ويهيّئ المدخلات للأداة B، ويكرر العملية حتى إنجاز المهمة. وهذا يخلق «سلسلة من الاحتمالات».

إذا افترضنا أن النموذج اللغوي الكبير يتصرف بشكل صحيح في 90% من الحالات (وهو تقدير سخي لمهام الاستدلال المعقدة)، فإن الموثوقية الرياضية لتدفق عمل متعدد الخطوات تتدهور بسرعة.

●​ خطوة واحدة: احتمال النجاح 90%

●​ 5 خطوات: احتمال النجاح $0.90^5 \approx 59%$

●​ 10 خطوات: احتمال النجاح $0.90^{10} \approx 34%$

في تدفق عمل لحجز رحلة طيران يشمل البحث والتصفية وإنشاء سجل اسم المسافر (PNR) وإدخال بيانات المسافرين والدفع وإصدار التذاكر، كثيرًا ما يتجاوز عدد الخطوات عشر عمليات. ومعدل نجاح بنسبة 34% أمرٌ غير مقبول في برمجيات المؤسسات، ومع ذلك فهذا هو السقف النظري للعديد من وكلاء النماذج اللغوية الكبيرة الخالصة. ⁴ وترسم معايير القياس في العالم الحقيقي صورة أشد قتامة، إذ كثيرًا ما تُظهر معدلات نجاح أقل من 1% في مهام التخطيط المعقدة. ⁵

تعجّ الصناعة بوكلاء «إثبات المفهوم» الذين يعملون بشكل رائع في بيئة عرض توضيحي مضبوطة لكنهم ينهارون أمام تباين بيانات العالم الحقيقي. وهذه الإخفاقات نادرًا ما يُعلن عنها، مما يخلق «انحياز الناجين» في الإدراك العام لقدرات الذكاء الاصطناعي. إننا نرى وكلاء يعلقون في حلقات لا نهائية، ووكلاء يحجزون التواريخ الخاطئة بكل ثقة، ووكلاء يهلوسون معاملات ناجحة لم تحدث قط. ²

1.3 موقف Veriprajna: المنطق ليس مهمة لغوية

تؤكد Veriprajna أن تدفق التحكم ليس مهمة لغوية. فتحديد ما ينبغي فعله تاليًا في عملية أعمال صارمة لا ينبغي أن يكون مسألة تنبؤ بالرموز؛ بل ينبغي أن يكون مسألة منطق شرطي. فقرار «طلب الدفع» لا ينبغي أن يحدث إلا إذا كانت «الرحلة مختارة» و«السعر مؤكدًا» (AND). هذا شرط بولياني، لا اقتراح احتمالي. ومن خلال إسناد هذا المنطق إلى النموذج اللغوي الكبير، يتخلى المطورون عن التحكم في آلة حالة تطبيقهم لصالح صندوق أسود. ⁴

تنقل فلسفتنا «الذكاء» من طبقة التنسيق إلى العقد الطرفية. فينبغي أن يكون النموذج اللغوي الكبير هو العامل —يستخرج البيانات، ويلخّص النصوص، وينسّق JSON—بينما ينبغي أن يكون المدير (منطق التنسيق) برمجية مكتوبة بشكل ثابت. وهذا التمييز هو أساس النهج العصبي-الرمزي، وهو السبيل الوحيد إلى موثوقية 99.9% في الأنظمة الوكيلية. ⁸

2. الواقع التجريبي: تحليل معيار قياس TravelPlanner

للانتقال إلى ما هو أبعد من النقد النظري، يجب أن نفحص البيانات التجريبية. إن مجال السفر يعمل بمثابة البوتقة المثالية لاختبار القدرات الوكيلية لأنه يقع عند تقاطع القيود البشرية "الفوضوية" (التفضيلات والتواريخ والميزانيات) وقيود النظام "الصارمة" (مخططات واجهات برمجة التطبيقات، وتوافر الرحلات الجوية، ومنطق رحلات الربط).

2.1 نتائج معيار TravelPlanner

يقدم معيار TravelPlanner، وهو إطار تقييم صارم مصمم لاختبار النماذج اللغوية الكبيرة في تخطيط مسارات السفر متعددة الأيام، أقوى دليل إدانة ضد التنسيق الخالص بالنماذج اللغوية الكبيرة. يتطلب هذا المعيار من الوكلاء تخطيط السفر داخل الولايات المتحدة، مع الالتزام بقيود تتعلق بالنقل والإقامة وتناول الطعام والميزانية. ¹⁰

المقياس	GPT-4 (نموذج لغوي كبير خالص)	الوكيل العصبي-الرمزي (مدفوع بالكود)
معدل النجاح الإجمالي	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 مساءً بدلًا من 2:00 صباحًا — فإنه ينشر ذلك الخطأ إلى المراحل اللاحقة. وقد يحجز تسجيل وصول إلى فندق في اليوم الخطأ بناءً على ذلك الوقت المُهلوَس. لا تعرف واجهة برمجة تطبيقات نظام التوزيع العالمي (GDS) نية الوكيل، بل مدخلاته فقط، ولذلك تعالج الطلب. والوكيل، إذ يرى استجابة ناجحة من واجهة برمجة التطبيقات، يرسّخ خطأه بنفسه. وهكذا يُنشئ شلال الهلوسة هذا أثر تنفيذ "ناجحًا" يفضي إلى نتيجة كارثية في العالم الواقعي. ²

2.2.3 "عدم التطابق بين الاستدلال والفعل"

تكشف المعايير عن حالة متكررة من "عدم التطابق بين الاستدلال والفعل"، حيث يحدد الحوار الداخلي للنموذج (سلسلة التفكير) القيد بشكل صحيح، لكن استدعاء الأداة اللاحق ينتهكه. قد "يفكر" النموذج: أحتاج إلى العثور على رحلة بأقل من $500، ثم يولّد استدعاء أداة لرحلة تكلف $600 لأن تلك الرحلة ظهرت بشكل أبرز في سياق نتائج البحث. يبرز هذا الانفصال هشاشة استخدام توليد النص كبديل لتنفيذ المنطق. ¹³

2.3 التصحيح العصبي-الرمزي

النظام الذي حقق نسبة نجاح 97% لم يستخدم نموذجًا لغويًا كبيرًا "أفضل"، بل استخدم بنية عصبية-رمزية معمارية. فقد استعان بالنموذج اللغوي الكبير لتحليل طلب المستخدم وتحويله إلى استعلام منظم، لكنه بعد ذلك سلّم ذلك الاستعلام إلى حلّال (خوارزمية حتمية) لتنفيذ البحث والتحسين. عومل النموذج اللغوي الكبير بوصفه "مترجمًا" لا "مخططًا". هذا التحول المعماري يقضي على انحراف السياق لأن الحلّال يحتفظ بالحالة (الميزانية والتواريخ) في متغيرات، لا في الرموز. ¹⁰

3. بوتقة التعقيد: أنظمة التوزيع العالمية (GDS)

لفهم سبب مناصرة Veriprajna للمخططات المُرمَّزة بشكل ثابت، يجب على المرء أن يستوعب البيئة العدائية لواجهات برمجة التطبيقات المؤسسية. إن حجز الرحلات الجوية ليس طلب REST GET بسيطًا؛ بل هو تفاعل معقد مع أنظمة التوزيع العالمية (GDS) مثل Sabre وAmadeus وTravelport. هذه الأنظمة، المصممة في عصر الحواسيب المركزية، لا تتسامح مع الغموض.

3.1 آلة الحالة في نظام التوزيع العالمي (GDS): إرث من الصرامة

معاملة حجز الرحلة الجوية هي آلة حالات منتهية (FSM) . وهي تتطلب تسلسلًا دقيقًا من العمليات التي لا يمكن إعادة ترتيبها أو تخطّيها.

1.​ تهيئة الجلسة (المصادقة): ​ تبدأ العملية بالمصادقة لدى نظام التوزيع العالمي (GDS) للحصول على رمز جلسة. وهذا الرمز يمثل "منضدة العمل" أو "الحالة". ويجب تمريره صراحةً في كل ترويسة لاحقة. فإذا "نسي" النموذج اللغوي الكبير تضمين هذا الرمز، أو هلوس رمزًا جديدًا، يضيع سياق المعاملة بأكمله.¹⁵

2.​ التسوق الجوي (البحث وإدارة العروض): ​ يعيد الأمر Air_Sell أو FlightOffersSearch قائمة من "العروض". والأهم من ذلك أن العرض كائن عابر. فالسعر والتوافر ديناميكيان. ويعيد نظام التوزيع العالمي (GDS) بنى معقدة ومتداخلة من JSON أو XML تحتوي على رموز أساس الأجرة (Fare Basis Codes) ونماذج حدود الأمتعة المسموح بها (Baggage Allowance Models) ومراجع القطاعات (Segment References).

○​ نمط الفشل: تكافح النماذج اللغوية الكبيرة في استيعاب هذه الحمولات الضخمة (غالبًا 50kb+) دون اقتطاعها. وعندما يلخّصون الخيارات للمستخدم، غالبًا ما يحذفون offerId الحرج أو segmentReference اللازم للخطوة التالية، مما يجعل الاختيار غير قابل للتنفيذ. ¹⁷

3.​ معاملة "السعر" (Price): ​ قبل الحجز، يجب استدعاء نقطة نهاية "Price" أو "Confirm". وهذا يقفل المخزون. يجب أن تطابق المدخلات هنا مخرجات البحث بتطابق حرفي تام.

○​ نمط الفشل: تتصرف النماذج اللغوية الكبيرة كـ"ضاغطات فاقدة" (lossy compressors). وعند نقل البيانات من مخرجات البحث إلى مدخلات السعر، فإنها كثيرًا ما "تصحّح تلقائيًا" أو "تُوحّد" البيانات (مثل تغيير تنسيق التاريخ أو تصحيح خطأ مُدرَك في رمز الأجرة)، مما يكسر السلامة التشفيرية التي تتطلبها واجهة برمجة التطبيقات. ¹⁹

4.​ إنشاء PNR (سجل اسم المسافر): ​ إنشاء PNR هو إجراء فرعي متعدد الخطوات. يجب إضافة:

○​ مقاطع المسار.

○​ عناصر الاسم (منسّقة بدقة: LAST/FIRST MR).

○​ عناصر الاتصال (AP - Address Phone).

○​ حد زمني لإصدار التذكرة (TKTL).

○​ عنصر "Received From" (RF).

○​ تأكيد المعاملة (ET).

○​ نمط الفشل: الترتيب مهم. لا يمكنك تأكيد المعاملة (ET) قبل إضافة

حقل "Received From" (RF). والنموذج اللغوي الكبير، الذي لا يملك مفهومًا جوهريًا للتسلسل الزمني بخلاف ما تعلّمه من بيانات التدريب، يحاول كثيرًا "حفظ" الحجز قبل اكتمال جميع الحقول الإلزامية، مما يؤدي إلى رموز أخطاء غامضة مثل ERR 1209 - SEQUENCE ERROR. ¹⁵

3.2 حلقة التغذية الراجعة الغامضة

عندما يعيد نظام GDS خطأ، نادرًا ما يكون وصفيًا. خطأ مثل UC (Unable to Confirm) أو NO RECAP لا يمنح النموذج اللغوي الكبير أي دلالة دلالية حول كيفية إصلاح المشكلة.

●​ استجابة النموذج اللغوي الكبير: النموذج، المدرَّب على أن يكون مفيدًا، غالبًا ما يفسّر الخطأ على أنه "عطل" ويعيد المحاولة بنفس الطلب تمامًا.

●​ الحلقات اللانهائية: يؤدي ذلك إلى "حلقة الموت" (Loop of Death)، حيث يحرق الوكيل الرموز المميزة وحدود معدل واجهة برمجة التطبيقات، وهو يتعثر مرارًا في جدار لا يستطيع فهمه. ⁶

●​ حل Veriprajna: عقدة ErrorHandler مكتوبة برمجيًا بشكل ثابت في المخطط تربط رموز أخطاء محددة (مثل UC) باستراتيجيات تعافٍ محددة (مثل "تشغيل سير عمل إعادة البحث"). ويُتجاوز النموذج اللغوي الكبير بالكامل أثناء هذا التعافي، مما يمنع الحلقة. ²²

4. النهضة العصبية-الرمزية: إطار نظري

إن حل هذه الإخفاقات ليس "مزيدًا من الذكاء الاصطناعي"، بل "علوم حاسوب أفضل". وتدعو Veriprajna إلى معمارية عصبية-رمزية، وهي نموذج يدمج التقليدين العظيمين للذكاء الاصطناعي: الاتصالية (الشبكات العصبية) والرمزية (المنطق/القواعد).

4.1 أفضل ما في العالمين

●​ الشبكات العصبية (دماغ "النظام 1"): ممتازة في التعرف على الأنماط والمطابقة الضبابية وفهم اللغة الطبيعية. وتتألق في الإدراك: فهم ما يقصده المستخدم عندما يقول: "أريد رحلة ليست مبكرة جدًا."

●​ الذكاء الاصطناعي الرمزي (دماغ "النظام 2"): ممتاز في تنفيذ القواعد والمنطق والحساب والاتساق. ويتألق في الاستدلال: ضمان أن إذا كان A > B، فإن C .

في معمارية Veriprajna، نُسند المسؤوليات وفق هذه القوى:

●​ النموذج اللغوي الكبير هو طبقة الواجهة . يترجم نية المستخدم غير المهيكلة إلى بيانات مهيكلة (JSON).

●​ المخطط هو طبقة التنفيذ . يستقبل البيانات المهيكلة وينفّذ منطق الأعمال باستخدام كود حتمي. ⁸

4.2 من خطوط الأنابيب إلى المخططات

يستخدم البرنامج التقليدي خطوط الأنابيب (تنفيذ خطي). وتتطلب تدفقات العمل الوكيلية دورات (حلقات). يحتاج الوكيل إلى القدرة على تجربة خطوة، والفشل، وتحليل الخطأ، وإعادة المحاولة. يتطلب ذلك الانتقال من الرسوم البيانية الموجّهة غير الدائرية (DAGs)—التي تتحرك فقط للأمام—إلى رسوم الحالة الدائرية.

●​ LangChain (في شكله الأساسي) شهّر بـDAG لسلاسل النماذج اللغوية الكبيرة.

●​ LangGraph يقدّم الرسم البياني الدائري، مما يتيح إنشاء آلات حالة حيث يمكن للحواف أن تعود إلى العقد السابقة بناءً على منطق شرطي. ²⁴

4.3 نمط "المشرف" (Supervisor)

ننفّذ معمارية "مشرف" حيث تحكم آلة حالة مركزية مكتوبة برمجيًا بشكل ثابت بدورة حياة الطلب. ويُخفَّض النموذج اللغوي الكبير من "الرئيس التنفيذي" إلى "عامل مهام".

●​ المشرف (المخطط) يقرر: "نحن في حالة الحجز. الخطوة التالية هي CollectPassengerInfo."

●​ العامل (النموذج اللغوي الكبير) ينفّذ: "استخرج اسم المسافر من نص هذا البريد الإلكتروني."

●​ المشرف (المخطط) يتحقق: "هل الاسم صالح؟ نعم. انتقل إلى حالة الدفع."

هذا انقلاب في التحكم—حيث يستدعي الكود النموذج اللغوي الكبير، بدلًا من أن يكتب النموذج اللغوي الكبير الكود—هو السمة المميّزة للأنظمة الوكيلية المتينة. ⁷

5. هندسة الحتمية: إطار عمل LangGraph

يعمل LangGraph بمثابة العمود الفقري التكنولوجي لمنهجية Veriprajna. ويوفر البنى الأولية اللازمة لبناء تطبيقات متعددة الفاعلين ذات حالة، مقاومة للطبيعة الاحتمالية للنماذج اللغوية الكبيرة.

5.1 بنى التحكم الأولية

يعمل LangGraph على ثلاثة مفاهيم أساسية: الحالة والعقد والحواف .

5.1.1 مخطط الحالة المشتركة

على عكس روبوتات الدردشة القياسية التي تعتمد على سجل محادثة (قائمة سلاسل نصية)، يعتمد LangGraph على مخطط حالة . وهذا هيكل بيانات مُنمَّط (عادة نموذج 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")

هذا المخطط هو "مصدر الحقيقة". وهو يستمر عبر سير العمل بأكمله. وحتى إذا هلوس النموذج اللغوي الكبير، فلا يمكنه الكتابة فوق session_id ما لم يُصرَّح بذلك صراحةً من عقدة مصمَّمة لتحديث ذلك الحقل. ²⁵

5.1.2 العقد: وحدات عمل حتمية

كل عقدة في المخطط هي دالة Python.

●​ عقد الوكلاء: تستدعي نموذجًا لغويًا كبيرًا لأداء مهمة معرفية محددة (مثل "استخراج التواريخ").

●​ عقد الأدوات: تستدعي واجهة برمجة تطبيقات خارجية (مثل "بحث Amadeus").

●​ عقد المنطق: تنفّذ كود Python خالصًا (مثل "التحقق من تنسيق التاريخ").

من خلال عزل استدعاءات واجهة برمجة التطبيقات في "عقد أدوات" يُنفَّذ بواسطة كود Python (وليس كودًا يولّده النموذج اللغوي الكبير)، نزيل "حقن الهلوسة". ويُبنى استدعاء واجهة برمجة التطبيقات باستخدام المتغيرات المُتحقَّق منها من الحالة، مما يضمن أن الحمولة صحيحة نحويًا في كل مرة. ²⁸

5.1.3 الحواف الشرطية: الجهاز العصبي

تكمن "ذكاء" التوجيه في الحواف الشرطية . وهذه دوال تفحص الحالة وتحدد العقدة التالية.

●​ نهج النموذج اللغوي الكبير القياسي: يُخرج النموذج "استدعِ أداة البحث." (احتمالي).

●​ نهج LangGraph: تقرأ دالة الحافة if state.origin AND state.destination: return "Search_Node" else: return "Ask_User_Node". (حتمي).

وهذا يضمن أن الوكيل لا يستطيع تخطي الخطوات. من المستحيل فعليًا أن يحاول الوكيل الحجز قبل أن يُملأ المتغير selected_offer في الحالة. ²⁴

5.2 الاستمرارية وحفظ نقاط التفتيش

تدفقات العمل المؤسسية طويلة الأمد. قد يبدأ المستخدم حجزًا، يُقاطَع، ثم يعود بعد ساعات. توفّر ميزة حفظ نقاط التفتيش في LangGraph حفظ الحالة في قاعدة بيانات (مثل Postgres أو Redis) بعد كل انتقال بين العقد.

●​ استئناف الجلسة: عند عودة المستخدم، يعيد المخطط تحميل الحالة بالضبط من قاعدة البيانات. وهو يعرف بالضبط أين توقّف (مثل "في انتظار الدفع"). ولا يحتاج إلى إعادة قراءة سجل المحادثة بأكمله واستنتاج السياق من جديد؛ فالسياق مهيكل ومحفوظ. ²⁷

●​ تصحيح الأخطاء بالسفر عبر الزمن: إذا فشل وكيل في الإنتاج، يمكن للمطورين تحميل نقطة التفتيش مباشرة قبل الفشل وإعادة تشغيل تنفيذ العقدة لتشخيص المشكلة. هذه القابلية للمراقبة مستحيلة مع سلاسل النماذج اللغوية الكبيرة ذات الصندوق الأسود. ²⁶

6. مخطط Veriprajna: دراسة حالة في حجز رحلات جوية متين

لإظهار التطبيق العملي لهذه المبادئ، نقدّم وكيل الرحلات الجوية من Veriprajna — معمارية مرجعية . وهذا ليس نموذجًا نظريًا؛ بل مخطط لنظام جاهز للإنتاج قادر على التفاعل مع أنظمة GDS مثل Sabre/Amadeus.

6.1 نظرة عامة على المعمارية

يُصمَّم النظام كـمخطط حالة هرمي .

●​ المخطط الرئيسي: يتولى التوجيه عالي المستوى (حجز رحلة مقابل إلغاء رحلة مقابل الأسئلة الشائعة).

●​ المخطط الفرعي (حجز الرحلة): يتولى آلة الحالة المحدودة الخاصة بعملية الحجز.

6.2 جولة تفصيلية في العقد

العقدة 1: "المجمّع" (الطبقة المعرفية)

●​ الوظيفة: تستخدم هذه العقدة نموذجًا لغويًا كبيرًا لتحليل مدخل المستخدم بلغة طبيعية.

●​ الهدف: ملء SearchCriteria في الحالة.

●​ التقنية: نستخدم التوليد الموجَّه (مثل وضع JSON أو استدعاء الدوال) لإجبار النموذج اللغوي الكبير على إخراج مخطط محدد: {origin: str, dest: str, date: str}.

●​ التحقق: يتحقق مُحقِّق Python من صحة رموز المطارات (مثل "LHR" صالح، "London" غامض). وإذا كان غامضًا، يعود المخطط إلى عقدة "إزالة الغموض"، سائلًا المستخدم: "Heathrow أم Gatwick؟". ولا يُسمح للنموذج اللغوي الكبير بالتخمين. ⁷

العقدة 2: "المسترجع" (طبقة الأدوات)

●​ الوظيفة: ينفّذ بحث GDS.

●​ المدخل: SearchCriteria المُتحقَّق منه في الحالة.

●​ الإجراء: يستدعي Amadeus.shopping.flight_offers_search.get().

●​ المنطق:

○​ إذا كان Response == 200: احفظ JSON الخام في state.flight_cache. انتقل إلى الملخّص.

○​ إذا كان Response == فارغ: انتقل إلى عقدة BroadenSearch (التي تقترح +/- 3 أيام).

○​ إذا كان Response == خطأ: انتقل إلى GDS_ErrorHandler.

●​ بصيرة رئيسية: يُتجاوز النموذج اللغوي الكبير بالكامل هنا. والتفاعل مع واجهة برمجة التطبيقات هو كود خالص.

العقدة 3: "الملخّص" (الطبقة المعرفية)

●​ الوظيفة: يحوّل JSON الخام إلى رسالة سهلة للمستخدم.

●​ المدخل: أفضل 5 عروض من state.flight_cache.

●​ القيد: يُوجَّه الموجّه للنموذج اللغوي الكبير بصرامة لعرض البيانات الموجودة فقط في JSON. ويُحظر عليه اختراع مزايا أو تغيير الأسعار.

●​ المخرج: "وجدت 5 رحلات. أفضل خيار هو United بسعر 450 دولار..."

العقدة 4: "المُختار" (طبقة الحالة)

●​ الوظيفة: يلتقط اختيار المستخدم.

●​ الإجراء: يقول المستخدم "احجز الثانية." يحلّ النموذج اللغوي الكبير "الثانية" إلى offer_id المحدد في flight_cache.

●​ التحديث: state.selected_offer_id = "eJzTD9..." (تجزئة GDS الطويلة).

●​ الانتقال: انتقل إلى Pre_Booking_Validation.

العقدة 5: "حارس البوابة" (طبقة الحوكمة)

●​ الوظيفة: يتحقق من قواعد الأعمال قبل المعاملة.

●​ المنطق:

○​ هل السعر ضمن حد السياسة المؤسسية؟

○​ هل الرحلة على شركة محظورة؟

●​ الحافة الشرطية:

○​ إذا كان هناك مخالفة: وجّه إلى ManagerApproval (HITL).

○​ إذا كان نظيفًا: وجّه إلى CreatePNR.

العقدة 6: "المُنفِّذ" (طبقة الأدوات)

●​ الوظيفة: ينفّذ تسلسل إنشاء PNR.

●​ التسلسل:

1.​ AddSegments(state.selected_offer_id)

2.​ AddPassenger(state.passenger_details)

3.​ PricePNR() -> فحص حرج: قارن السعر المُعاد مقابل السعر المخزَّن مؤقتًا.

4.​ CommitPNR()

●​ معالجة الأخطاء: إذا أعاد نظام GDS تحذير "تغيير السعر" (شائع في السفر)، تتوقف العقدة وتوجّه إلى عقدة PriceChangeNotification، سائلة المستخدم تأكيد السعر الجديد. ولا تحجز تلقائيًا بالسعر الأعلى. ¹⁵

6.3 جدول: معمارية Veriprajna مقابل الغلاف القياسي

الميزة	غلاف النموذج اللغوي الكبير القياسي	Veriprajna (مخطط عصبي-رمزي)
تدفق التحكم	احتمالي (النموذج اللغوي الكبير يقرر الخطوة التالية)	حتمي (حواف المخطط تقرر)
استمرارية الحالة	ضمنية (سجل المحادثة)	صريحة (مخطط مدعوم بقاعدة بيانات)
التفاعل مع GDS	النموذج اللغوي الكبير يولّد جسم JSON (عرضة للأخطاء)	الكود يولّد جسم JSON (آمن النوع)
التعافي من الأخطاء	"أنا آسف، فشلت." (يستسلم) "تم اكتشاف الخطأ 8102.	إعادة المحاولة بالتنسيق B." التكرار
خطر حلقة لانهائية (استنزاف	الرموز) حلقات مضبوطة مع	Max_Retries الامتثال
صندوق أسود معتم	سجل تدقيق كامل لعقد	المنطق العقد

7. العنصر البشري: الحوكمة وHITL

في المؤسسة، هدف الذكاء الاصطناعي ليس الاستقلالية الكاملة؛ بل تعزيز الإنتاجية . هناك لحظات تتطلب فيها الحكم البشري قانونيًا أو تشغيليًا. وتعاني سلاسل النماذج اللغوية الكبيرة الخالصة من صعوبة التوقف وانتظار البشر؛ أما LangGraph فيجعل ذلك أصلًا أصيلًا.

7.1 نمط "المقاطعة" (Interrupt)

نستخدم وظيفة interrupt_before في LangGraph لإنشاء "فجوات عزل" في سير العمل.

●​ السيناريو: رحلة تكلف 2000 دولار. تتطلب السياسة موافقة المدير.

●​ الآلية: ينفّذ المخطط حتى عقدة الحجز. تكتشف الحافة الشرطية price > 1000. وتُطلق مقاطعة .

●​ تجميد الحالة: يُعلِّق المخطط التنفيذ. وتُحفَظ الحالة في قاعدة البيانات. وتُحرَّر الذاكرة.

●​ إجراء خارج الخط: يرسل النظام بريدًا إلكترونيًا إلى المدير مع رابط.

●​ الاستئناف: ينقر المدير "موافقة." ترسل واجهة برمجة التطبيقات إشارة إلى

مشرف المخطط. يعيد المخطط تحميل الحالة، ويحدّث approval_status = APPROVED، و يستأنف سير العمل عند عقدة الحجز. ²⁹

7.2 سجل التدقيق والامتثال التنظيمي

يتطلب قانون الذكاء الاصطناعي للاتحاد الأوروبي واللوائح الناشئة في الولايات المتحدة الشفافية لأنظمة الذكاء الاصطناعي عالية المخاطر (التي تشمل المعاملات المالية مثل حجز السفر).

●​ مشكلة الغلاف: أثر النموذج اللغوي الكبير مجرد فوضى من الرموز. من الصعب إثبات لماذا حجز الوكيل رحلة محددة.

●​ حل المخطط: توفّر Veriprajna سجل تنفيذ العقد .

○​ إدخال السجل: [2023-10-27 14:00:01] Node:Gatekeeper | Input: Price=1200 | Rule: Policy_Limit=1000 | Output: REJECT_NEED_APPROVAL

○​ هذا السجل قابل للقراءة من قبل المدققين. وهو يثبت أن النظام اتبع سياسة الحوكمة بشكل حتمي. ³⁴

8. الحجة الاقتصادية: الكفاءة والتكلفة

بخلاف الموثوقية، هناك حجة اقتصادية مقنعة لنهج Veriprajna. فوكلاء النماذج اللغوية الكبيرة الخالصة مكلفون حسابيًا.

8.1 تكلفة حلقات الهلوسة

عندما يعلق وكيل نموذج لغوي كبير في حلقة—محاولًا إصلاح خطأ GDS عبر هلوسة معاملات جديدة—يولّد آلاف الرموز المميزة للمدخل/المخرج. ويمكن أن تكلف جلسة واحدة "عالقة" 5-10 دولارات من أرصدة واجهة برمجة التطبيقات قبل انتهاء المهلة. وباستخدام معالجات أخطاء مكتوبة برمجيًا بشكل ثابت، تمنع Veriprajna هذه الحلقات. يُلتقط الخطأ بواسطة الكود (تكلفة 0)، ويُحلَّل، ويُصلَح. ولا يُستدعى النموذج اللغوي الكبير إلا عند الضرورة القصوى.²

8.2 تحسين الرموز المميزة

في معمارية عصبية-رمزية، لا نحتاج إلى إطعام النموذج اللغوي الكبير استجابة GDS البالغة 50 كيلوبايت بأكملها. عقدة "الجالب" (الكود) تحلل JSON، وتستخرج الحقول الخمسة ذات الصلة، وتمرّر فقط تلك إلى عقدة "الملخّص" (النموذج اللغوي الكبير). وهذا يقلّل استخدام نافذة السياق بنسبة 90%، مما يخفض بشكل كبير تكاليف الاستدلال وزمن الاستجابة. 9. التوقعات المستقبلية: تطور المخطط ³⁶

إن الانتقال من روبوتات الدردشة إلى المخططات ليس اتجاهًا مؤقتًا؛ بل هو نضج صناعة الذكاء

الاصطناعي. ومع أن تصبح القدرات "الوكيلية" معيارًا، سينتقل التمايز من "من الاصطناعي. ومع أن تصبح القدرات "الوكيلية" معيارًا، سينتقل التمايز من "من يمتلك أذكى نموذج؟" إلى "من يمتلك أقوى مخططًا؟"

تتوقع Veriprajna صعود بروتوكولات وكلاء موحَّدة —مكتبات من مخططات فرعية مُسبقة البناء ومُتحقَّق منها لمهام شائعة (مثل LangGraph.Hub.FlightBooking، LangGraph.Hub.SalesforceUpdate). ستُركَّب المؤسسات التطبيقات عبر ربط هذه المخططات المُتحقَّق منها، مستخدمة النماذج اللغوية الكبيرة مجردًا كغراء لتنعيم واجهة اللغة الطبيعية.

نحن ندخل عصر الذكاء الاصطناعي الحتمي . السحر ليس في الموجّه؛ بل في المعمارية.

الخاتمة

إن فشل النماذج اللغوية الكبيرة في غزو معيار "TravelPlanner" بشكل موثوق ليس إدانة للذكاء الاصطناعي؛ بل إدانة لمنهجية "الغلاف". فبطلب من النماذج الاحتمالية أداء تنسيق حتمي، أعدت الصناعة نفسها للفشل. تقدّم Veriprajna مسارًا مثبتًا إلى الأمام. فمن خلال تبنّي التنسيق العصبي-الرمزي، نستفيد من النموذج اللغوي الكبير فيما يجيده—فهم دقة النية البشرية—مع

الاحتفاظ بصرامة هندسة البرمجيات فيما تجيده: تنفيذ عمليات أعمال معقدة ذات حالة ومتوافقة. بالنسبة للمؤسسة الحديثة، الخيار واضح: يمكنك بناء روبوت دردشة يتحدث عن إنجاز العمل، أو يمكنك هندسة وكيل ينجز العمل. الفرق هو المخطط.

المراجع 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

1. 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/

2. What drives Multi-Agent LLM Systems Fail ? - Hugging Face، تم الوصول إليه في 11 ديسمبر 2025، https://huggingface.co/blog/Musamolla/multi-agent-llm-systems-failure

3. Evaluating LLMs on Sequential API Call Through Automated Test Generation arXiv، تم الوصول إليه في 11 ديسمبر 2025، https://arxiv.org/html/2507.09481v2

4. TravelPlanner: A Benchmark for Real-World Planning with Language Agents arXiv، تم الوصول إليه في 11 ديسمبر 2025، https://arxiv.org/html/2402.01622v4

5. Why do Multi-Agent LLM Systems Fail - Galileo AI، تم الوصول إليه في 11 ديسمبر 2025، https://galileo.ai/blog/multi-agent-llm-systems-fail

6. [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/

7. 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

8. Neurosymbolic Programming for AI Agents | by Dorian Smiley - Medium، تم الوصول إليه في 11 ديسمبر 2025، https://dorians.medium.com/neurosymbolic-programming-for-ai-agents-2720257db7f3

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