GPT-4 فشل بنسبة 99.4% — فتوقّفنا عن السماح له باتخاذ القرارات

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

ليست مدينة خاطئة مختلفة في كل مرة — بل نفس المدينة الخاطئة. دلهي بدلاً من ديهرادون. كان المستخدم قد كتب «ديهرادون» بوضوح. وكان الـ LLM قد حللها بشكل صحيح في سلسلة تفكيره الاستدلالي. ثم، عندما ولّد استدعاء API، استبدل بها رمز مطار دلهي. بثقة. وبصمت. ثلاث مرات.

كان شريكي المؤسس على المكالمة. قال: «إنه يعرف الإجابة الصحيحة. انظر إلى أثر الاستدلال. إنه يقول ديهرادون حرفياً. ثم يفعل شيئاً آخر.»

كانت تلك الليلة التي توقفت فيها عن الاعتقاد بأن التوجيهات (prompts) الأفضل ستنقذنا.

كنا نبني وكيل ذكاء اصطناعي لحجز السفر — من النوع الذي يتحدث إلى أنظمة التوزيع العالمية مثل Amadeus وSabre، تلك الأنظمة الخلفية العتيقة من حقبة الحواسيب المركزية (mainframe) التي تشغّل كل حجز طيران على هذا الكوكب. وكنا نفعل ما كان يفعله الجميع في عام 2023: تغليف GPT-4 بطبقة تنسيق رقيقة، وإعطاؤه أدوات، والدعاء.

لم يكن الدعاء ينفع.

الرقم الذي غيّر كل شيء

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

معدل النجاح الإجمالي لـ GPT-4: 0.6%.

ليس 60%. ليس 6%. صفر فاصلة ستة بالمئة.

قرأته ثلاث مرات. ثم استحضرت المنهجية للتأكد من أنهم لم يرتكبوا خطأً. لم يرتكبوا. عندما تطلب من أكثر نماذج اللغة تقدماً في العالم أن يخطط رحلة تحترم ميزانية، ويربط الرحلات بالفنادق بالمطاعم، ولا ينتهك المنطق الزمني الأساسي — فإنه يفشل 99.4% من الوقت.

عندما طُلب من GPT-4 تخطيط رحلات بقيود واقعية، نجح 0.6% من الوقت. أما الوكيل العصبي-الرمزي الذي حلّ المشكلة نفسها فسجّل 97%.

لم يستخدم النظام الذي سجّل 97% نموذجاً أذكى. بل استخدم بنية مختلفة جوهرياً — بنية يترجم فيها الـ LLM طلب المستخدم إلى بيانات مهيكلة، ثم يقوم مُحلِّل حتمي بالتخطيط الفعلي. كان الـ LLM هو المترجم. وكانت الشيفرة البرمجية هي العقل.

لم يكتفِ ذلك المعيار بتأكيد إحباطنا. بل منحنا مخططاً تفصيلياً.

لماذا يستمر وكيل الذكاء الاصطناعي لديك في الفشل؟

إليك الأمر الذي لا يريد أحد في حُمّى الذهب لـ«وكلاء الذكاء الاصطناعي» الحديث عنه: نماذج LLM لا تستدل. بل تتنبأ.

عندما «يقرر» GPT-4 استدعاء واجهة برمجة تطبيقات (API) للبحث، فإنه لا ينفّذ منطقاً. بل يتنبأ بالرمز (token) الأكثر احتمالاً إحصائياً بناءً على الأنماط في بيانات تدريبه. في محادثة، عادةً ما يكون هذا التنبؤ جيداً بما يكفي. أما في سير عمل من عشر خطوات عبر واجهات برمجة التطبيقات حيث تعتمد كل خطوة على المُخرَج الدقيق للخطوة السابقة؟ فتلك كارثة.

بدأت أسمّي هذه الظاهرة سلسلة الاحتمالات، وهي مشكلة. افترض أن الـ LLM لديك يصيب كل خطوة بنسبة 90% من الوقت — وهو تقدير سخي للاستخدام المعقد للأدوات. إليك الحساب:

• خطوة واحدة: نجاح 90%
• 5 خطوات: نجاح ~59%
• 10 خطوات: نجاح ~34%

سير عمل حجز رحلة طيران — بحث، تصفية، اختيار، تسعير، جمع بيانات المسافر، إنشاء PNR، تحقّق، دفع، إصدار تذكرة — يتجاوز عادةً عشر خطوات. عند نجاح نظري بنسبة 34%، فأنت لا تبني برمجيات. بل تبني آلة قمار.

و34% هي السقف. الأداء في العالم الواقعي أسوأ بسبب ظاهرتين ظللنا نصطدم بهما في بيئة الإنتاج.

شلال الهلوسة

الأولى هي ما أسمّيه شلال الهلوسة. في بنية متسلسلة، يصبح مُخرَج الخطوة 2 مُدخَلاً للخطوة 3. إذا ارتكب الـ LLM خطأً دقيقاً في وقت مبكر — كأن يخطئ في قراءة وقت وصول رحلة فيجعله 2:00 مساءً بدلاً من 2:00 صباحاً — فإن ذلك الخطأ لا يُكتشف. بل ينتشر. يحجز الوكيل تسجيل دخول فندق في اليوم الخطأ بناءً على الوقت المُهَلوَس. لا تعرف واجهة GDS البرمجية (API) من الوكيل نيّتَه، بل تعرف فقط مُدخَله، لذا تعالج الطلب بنجاح. يرى الوكيل استجابة 200 OK فيعزّز خطأه الخاص.

ينتهي بك الأمر إلى أثر تنفيذ «ناجح» يُنتج نتيجة كارثية في العالم الواقعي. يظن الوكيل أنه أتقن المهمة. ثم يصل العميل إلى المطار ليكتشف عكس ذلك.

أما الظاهرة الثانية فهي انحراف السياق. بينما يعمل الوكيل خلال خطة متعددة الخطوات، تمتلئ نافذة السياق ببيانات وسيطة — نتائج بحث، واستجابات API، ورسائل المستخدم. تنتشر آلية الانتباه في النموذج بشكل متزايد الرِّقّة عبر كل تلك الرموز (tokens). وبحلول الخطوة 10، يكون قد «نسي» فعلياً قيد الميزانية الذي حدّده بشكل صحيح في الخطوة 2. تتخفّف درجات الانتباه، التي تحكمها دالة softmax، عبر عدد كبير جداً من الرموز غير ذات الصلة.

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

نعم. إنه ببساطة ينسى.

ماذا يحدث عندما يلتقي الذكاء الاصطناعي بحاسوب مركزي؟

لتفهم حقاً لماذا احتجنا إلى نهج مختلف، عليك أن تفهم كيف يكون العمل مع أنظمة التوزيع العالمية.

Amadeus وSabre وTravelport — هذه هي العمود الفقري للسفر الجوي العالمي. صُمّمت في حقبة الحواسيب المركزية، وتتصرف بناءً على ذلك. حجز رحلة الطيران ليس استدعاءً واحداً لواجهة برمجة التطبيقات (API). بل هو آلة حالات منتهية ذات تسلسل دقيق من العمليات لا يمكن إعادة ترتيبه أو تخطّيه أو تقريبه.

تُصادِق فتحصل على رمز جلسة (session token). يجب تمرير ذلك الرمز في كل ترويسة لاحقة — فإذا «نسيه» الـ LLM أو هلوَس رمزاً جديداً، يُفقَد سياق المعاملة بأكمله. ثم تبحث عن رحلات، فيُعيد GDS حمولات JSON متداخلة ضخمة — غالباً 50 كيلوبايت فأكثر — تحتوي على رموز أساس الأجرة، ونماذج الأمتعة، ومراجع القطاعات. يحتاج الـ LLM إلى استخراج offerId محدد من تلك الحمولة كي يتابع. لكن نماذج LLM هي ضواغط ذات فقدان (lossy). فهي تلخّص. وتقتطع. و«بحُسن نية» تُطبّع تنسيقات البيانات التي يشترط GDS أن تكون دقيقة، حتى مستوى البايت.

ذات ليلة، أمضينا أربع ساعات في تصحيح فشل حجز. كان الـ LLM قد «صحّح» رمز أساس أجرة — إذ غيّر حرفاً صغيراً إلى حرف كبير، لأن ذلك بدا «أصح» لنموذج مُدرَّب على نص إنجليزي. رفضه GDS بخطأ غامض: ERR 1209 - SEQUENCE ERROR. لا تفسير. لا اقتراح. مجرد جدار.

نماذج LLM هي ضواغط ذات فقدان. عندما تنقل البيانات بين استدعاءات API، فإنها «تصحح تلقائياً» و«تُطبّع» بطرق تكسر السلامة التشفيرية التي تشترطها أنظمة المؤسسات.

وعندما يُعيد GDS خطأً مثل UC (Unable to Confirm - تعذّر التأكيد)، لا يملك الـ LLM أدنى فكرة عما يفعله. إنه مُدرَّب على أن يكون مفيداً، فيفسّر الخطأ على أنه خلل عابر ويعيد إرسال الطلب نفسه تماماً. مرة أخرى. ثم أخرى. شاهدنا وكلاء يستنزفون آلاف الرموز ويصطدمون بحدود معدل استدعاء API، عالقين فيما بدأنا نسمّيه «حلقة الموت» — يرتطمون مراراً بجدار لا يستطيعون فهمه.

الليلة التي قلبنا فيها البنية

جاءت نقطة التحول أثناء جدال.

كنا قد أمضينا ثلاثة أشهر في المشروع. أراد قائد فريق الهندسة لدينا مواصلة تحسين التوجيهات (prompts) — رسائل نظام أطول، وأمثلة أكثر، وتعليمات تسلسل التفكير. ظل يقول: «نحن قريبون جداً. لو أننا فقط هيكلنا التوجيه بشكل أفضل لخطوة إنشاء PNR...»

استحضرت سجلاتنا. في الأسبوع السابق، كان لدينا 47 محاولة حجز فاشلة في بيئة الاختبار لدينا. إحدى عشرة منها كانت حلقة الموت. وتسع منها كانت رموز مطارات مُهَلوَسة. وست منها كانت الـ LLM يحاول تثبيت PNR قبل إضافة حقل «Received From» الإلزامي — خطأ تسلسل لم يبدُ أن أي قدر من التوجيه يصلحه، لأن النموذج لم يكن لديه مفهوم متأصل للترتيب الزمني يتجاوز ما استوعبه من بيانات التدريب.

قلت: «نحن لسنا قريبين. نحن عند السقف. البنية هي المشكلة.»

في ذلك الأسبوع، أعدنا كتابة كل شيء. توقفنا عن مطالبة الـ LLM بالتنسيق. توقفنا عن السماح له بتقرير الخطوة التالية. توقفنا عن تغذيته باستجابات GDS الخام على أمل أن يستخرج الحقول الصحيحة.

بدلاً من ذلك، بنينا مُخطَّطاً بيانياً.

للاطلاع على التفصيل التقني الكامل لما بنيناه ولماذا، كتبت ورقة بحثية مفصّلة تتعمق في البنية.

كيف يعمل الذكاء الاصطناعي العصبي-الرمزي فعلياً؟

الفكرة الجوهرية بسيطة بشكل خادع: تدفّق التحكم ليس مهمة لغوية.

تقرير ما يجب فعله تالياً في عملية أعمال صارمة لا ينبغي أن يكون مسألة تنبؤ بالرموز. بل ينبغي أن يكون مسألة منطق شرطي. قرار «طلب الدفع» يجب أن يُطلَق فقط إذا كانت «الرحلة مختارة» و«السعر مؤكد». هذا شرط منطقي (boolean)، وليس اقتراحاً احتمالياً.

قسّمنا نظامنا إلى طبقتين:

أصبح الـ LLM طبقة الواجهة — المترجم. فهو يحلّل اللغة الطبيعية للمستخدم («أريد رحلة صباحية إلى ديهرادون، ليست باهظة جداً») إلى بيانات مهيكلة: {origin: "DEL", destination: "DED", date: "2024-03-15", time_preference: "morning", budget: "economy"}. هذا ما تبرع فيه نماذج LLM حقاً: فهم النيّة البشرية الفوضوية.

وأصبح المخطط البياني طبقة التنفيذ — المدير. فهو يتلقى تلك البيانات المهيكلة وينفّذ منطق الأعمال باستخدام شيفرة حتمية. عُقَد مُبرمَجة بشكل صريح. مخططات حالة ذات أنواع محددة. حواف شرطية تفحص المتغيرات، لا الانطباعات.

استخدمنا LangGraph لبناء هذا، لأنه يمنحك البِنى الأولية التي تحتاجها: مخطط حالة مشترك (مدعوم بقاعدة بيانات، لا بسجل محادثة)، وعُقَد ليست سوى دوال Python، وحواف شرطية توجّه بناءً على القيم الفعلية للمتغيرات.

ينبغي أن يكون الـ LLM هو العامل — يستخرج البيانات، ويلخّص النصوص، وينسّق JSON — بينما ينبغي أن يكون المدير برمجيات مُبرمَجة بشكل صريح. هذا العكس في التحكم هو السمة المميزة للأنظمة الوكيلة المتينة.

في بنيتنا، الـ LLM حرفياً لا يستطيع تخطّي الخطوات. من المستحيل مادياً أن يحاول النظام الحجز قبل أن يُملأ متغير selected_offer_id في الحالة. ليس لأننا أخبرنا الـ LLM «لا تفعل ذلك» في توجيه، بل لأن حافة المخطط البياني لن تُطلَق. الأمر أشبه بمحاولة القيادة عبر جدار — الشيفرة ببساطة لا تسمح بذلك.

كيف يبدو النظام الفعلي؟

دعني آخذك عبر ما يحدث عندما يقول أحدهم «احجز لي رحلة من مومباي إلى لندن الثلاثاء المقبل.»

أولاً، عقدة Collector — مدعومة بـ LLM — تحلّل تلك الجملة إلى حقول مهيكلة. تستخدم التوليد الموجَّه (JSON Mode) لإخراج مخطط محدد. يتحقق مُدقِّق Python مما إذا كانت رموز المطارات حقيقية. «لندن» غامضة — هيثرو أم غاتويك؟ — لذا يوجّه المخطط البياني إلى عقدة إزالة الغموض. الـ LLM لا يخمّن. بل يسأل.

بمجرد أن تتوفر لدينا معايير بحث مُتحقَّق منها، عقدة Retriever تستدعي واجهة Amadeus البرمجية (API). هذه شيفرة خالصة. لا وجود لـ LLM. تعود الاستجابة، وتُخزَّن مؤقتاً في الحالة، وفقط عندها تقوم عقدة Summarizer — وهي LLM — بتحويل النتائج الخمس الأولى إلى رسالة قابلة للقراءة البشرية. لكنها مقيّدة بصرامة: لا يمكنها عرض سوى البيانات الموجودة في JSON المخزّن مؤقتاً. لا يمكنها اختلاق مزايا أو تغيير الأسعار.

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

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

كل انتقال بين العُقَد يُسجَّل. كل قرار قابل للتتبع. يمكن لمُدقِّق أن يقرأ سجل التنفيذ ويفهم بالضبط لماذا حجز النظام رحلة محددة — ليس بتفسير فوضى من الرموز، بل بقراءة سجل مهيكل: Node:Gatekeeper | Input: Price=1200 | Rule: Policy_Limit=1000 | Output: REJECT_NEED_APPROVAL.

كتبت عن البنية الكاملة، بما في ذلك المخططات التفاعلية، في النسخة التفاعلية من الورقة البحثية.

أليس هذا مجرد... هندسة برمجيات عادية؟

يسألني الناس هذا باستمرار. «إذن أنت تقول إن علينا كتابة شيفرة بدلاً من استخدام الذكاء الاصطناعي؟ ثوري.»

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

النهج العصبي-الرمزي ليس مناهضاً للذكاء الاصطناعي. بل هو مؤيد للبنية. نستخدم نماذج LLM بقوة — لتحليل النيّة، ولإزالة الغموض، وللتلخيص، ولمعالجة المشكلة الصعبة حقاً المتمثلة في فهم ما يعنيه الإنسان عندما يكتب شيئاً غامضاً. لكننا لا نسمح للـ LLM بلمس عجلة القيادة حين تكون السيارة على الطريق السريع.

يمكنك بناء روبوت محادثة يتحدث عن أداء العمل، أو يمكنك تصميم وكيل يؤدّي العمل فعلاً. الفرق هو المخطط البياني.

هناك أيضاً حجة تتعلق بالتكلفة فاجأتني. وكلاء الـ LLM الخُلَّص مكلفون — ليس لأن الاستدلال مكلف في كل استدعاء، بل بسبب حلقات الفشل. عندما يعلق وكيل في إعادة محاولة خطأ GDS عبر هلوسة معاملات جديدة، فإنه يستنزف آلاف الرموز قبل أن تنتهي مهلته. يمكن أن تكلّف جلسة واحدة عالقة 5 إلى 10 دولارات من أرصدة API. تلتقط معالِجات الأخطاء المُبرمَجة لدينا تلك الإخفاقات بتكلفة رموز صفرية. ولأننا لا نرسل إلى الـ LLM سوى الحقول الخمسة ذات الصلة من استجابة GDS بحجم 50 كيلوبايت بدلاً من إرسالها بالكامل، فإننا نقلّص استخدام نافذة السياق بنحو 90%.

لكن ألن تصبح النماذج جيدة بما يكفي في النهاية؟

ربما. أنا حقاً لا أعرف ما إذا كان GPT-6 أو GPT-7 سيكون موثوقاً بما يكفي لتنسيق سير عمل من عشر خطوات عبر API دون حواجز حماية (guardrails). لكنني أعرف أمرين.

أولاً، حتى لو تحسّنت النماذج بشكل جذري، فإن مشكلة سلسلة الاحتمالات رياضية، لا تقنية. إذا كان نموذجك موثوقاً بنسبة 99% لكل خطوة — وهو إنجاز استثنائي — فإن سير عمل من عشر خطوات لا يزال يفشل 10% من الوقت. بالنسبة لمعاملات المؤسسات، لا يزال هذا غير مقبول. المخطط البياني يقضي على هذا تماماً لأن التوجيه ليس احتمالياً.

ثانياً، انتظار تحسّن النماذج ترف لا تملكه معظم المؤسسات. إنها تحتاج إلى وكلاء يعملون الآن، وقابلين للتدقيق الآن، وممتثلين لمتطلبات الشفافية في قانون الذكاء الاصطناعي الأوروبي (EU AI Act) الآن. النهج العصبي-الرمزي لا يراهن على المستقبل. بل يبني على مبادئ هندسية مثبتة مع استخدام أفضل قدرات الذكاء الاصطناعي المتاحة اليوم.

البنية هي المنتج

لقد جلست في ما يكفي من الغرف مع مستثمرين ومشترين من المؤسسات لأعرف أن صناعة الذكاء الاصطناعي بدأت تستيقظ. السؤال يتحول من «مَن يملك النموذج الأذكى؟» إلى «مَن يملك النظام الأكثر متانة؟». العروض التوضيحية التي تبهر في محاضرة مؤتمر — تلك التي يحجز فيها وكيل رحلة طيران بلا أخطاء في بيئة مضبوطة — رخيصة. أما المُكلِف، وما يهم فعلاً، فهو بناء شيء يعمل عند الطلب رقم عشرة آلاف بنفس موثوقيته عند الطلب الأول.

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

لم يكن السحر قط في التوجيه. بل كان دائماً في البنية.