ادعاء عدم الاتساق
من الشكاوى المتكررة حول وكلاء LLM أنهم متقلبون: الطلب نفسه، يُدخل مرتين، يُنتج قرارين مختلفين. والتأطير هو نفسه في كل مرة تقريبًا — النموذج غير مستقر، وأخذ العينات ساخن أكثر من اللازم، والـ prompt هش. عمل Concordance من CTGT مفيد تحديدًا لأنه يرفض هذا التأطير. فهو يتتبع المسار الذي يسلكه الوكيل للوصول إلى استنتاج، ويسأل لماذا تباعد تشغيلان، بدلًا من الجزم بأنهما تباعدا. والجواب، في أكثر الحالات، أن التشغيلين لم يكونا قط التشغيل نفسه.
وفي الطرف الآخر من سلسلة الأدوات، جعلت أُطُر على طراز DeepEval تقييم المخرجات روتينيًا وعلى نطاق واسع. يمكنك تشغيل مجموعة من الحالات، وإرفاق مقاييس، والحصول على نسبة نجاح. وما لا تستطيعه تلك الأُطُر بمفردها هو تحديد موضع سبب الفشل: درجة صفر على حالة تخبرك أن الجواب كان خاطئًا، لا أي خطوة في المسار أدخلت الخطأ. والفجوة بين التتبع على طراز Concordance والتقييم على طراز DeepEval ليست فجوة في تصميم المقاييس. إنها فجوة في التقاط السياق. فأداة التتبع تستطيع تفسير التباعد لأنها تحتفظ بالمدخلات؛ وأداة التقييم تُبلّغ عن التباعد لأنها تتخلص منها.
مصادر التباين الخفي
قرار الوكيل دالة على أكثر بكثير من رسالة المستخدم. فبين تشغيلين يبدوان متطابقين من الخارج، يمكن أن تختلف كل العناصر التالية:
- السياق المسترجَع. يعيد البحث المتجهي مجموعة مرتّبة تتغير مع تحديثات الفهرس، وإصدارات نماذج الـ embedding، وكسر التعادل. قد يسترجع تشغيلان مستندات متداخلة لكن غير متطابقة، ويستدل النموذج على ما أُعطي.
- استجابات الأدوات. واجهة برمجة طقس، أو استعلام قاعدة بيانات، أو نداء بحث — كل منها يعيد بيانات حيّة. طابع زمني في حمولة أداة، أو مؤشر ترقيم صفحات، أو مجموعة نتائج أُعيد ترتيبها، يكفي لتغيير الخطوة التالية.
- الترتيب والطوابع الزمنية. ترتيب الرسائل في محادثة طويلة، والوقت الفعلي المحقون في system prompt، والتسلسل الذي تُحلّ به نداءات الأدوات المتوازية، كلها تصب في الـ prompt.
- معاملات أخذ العينات. غالبًا ما تُضبط temperature وtop-p وseed وmax tokens لكل بيئة، ونادرًا ما تُوسم بإصدارها إلى جانب الـ prompt الذي يعتمد عليها.
- انحراف تجميع الـ prompt. تُجمَّع system prompts من قوالب وأمثلة few-shot وسياق محقون. ونشر يغيّر جزءًا واحدًا يغيّر المدخل الفعلي لكل طلب، ولا شيء في درجة المخرجات يسجّل أن ذلك حدث.
والاستنتاج المقلق أن كثيرًا من «المدخلات المتطابقة ظاهريًا» ليست متطابقة بمجرد فحص أداة التشغيل. فالوكيل يتصرف بشكل حتمي نظرًا لمدخلاته؛ لكن المدخلات ببساطة لا تُثبَّت، ولا تُسجَّل، ولا تُقارَن. والتغطية الحديثة لتقييم الوكلاء تدور باستمرار حول هذه النقطة — أن التباين المثير للاهتمام يسكن في خط الأنابيب المحيط بالنموذج، لا في النموذج وحده — والمقتضى العملي هو أن تقييم المخرجات وحده سيظل يخطئ في إسناد السبب.
عقد إعادة التشغيل
الحل هو عقد: كل قرار يسجّل سياقًا كافيًا لإعادة تشغيله بدقة. وبشكل ملموس، ينبغي لسجل التتبع أن يحمل:
{
"run_id": "...",
"model": { "name": "...", "version": "...", "params": { "temperature": 0.0, "top_p": 1.0, "seed": 42 } },
"prompt": { "template_hash": "...", "assembled": "...", "fragments": ["..."] },
"retrieval": [
{ "doc_id": "...", "content_hash": "...", "score": 0.81, "rank": 1 }
],
"steps": [
{
"index": 0,
"tool": "search",
"args": { "query": "..." },
"response": { "...": "..." },
"response_hash": "..."
}
],
"output": "..."
}
يُخزَّن الـ prompt المجمَّع حرفيًا إلى جانب تجزئات أجزائه، فيصبح تغيير القالب قابلًا للكشف دون مقارنة ميغابايتات من النص. وتحمل مجموعة الاسترجاع تجزئات المستندات، فيصبح الفهرس المتغيّر مرئيًا بدلًا من مستنتَج. وتُلتقط وسائط الأدوات واستجاباتها عند كل خطوة، ما يحوّل المسار إلى تسلسل قابل لإعادة التشغيل بدلًا من سلسلة نهائية.
وبهذا السجل، تصبح إعادة التشغيل تجربة مضبوطة. جمّد المدخلات — الـ prompt نفسه، ومجموعة الاسترجاع نفسها، واستجابات الأدوات نفسها، وإصدار النموذج نفسه — وأي تباعد متبقٍّ هو تباين النموذج. وأطلق بُعدًا واحدًا في كل مرة، فتستطيع إسناد التباعد إلى الاسترجاع، أو إلى أداة، أو إلى عملية نشر. عندئذ ينتقل التقييم من الجواب النهائي إلى المسار: تُقارَن كل خطوة، ونقطة التباعد الأولى هي حيث يبدأ التحقيق. ذلك هو الفرق بين معرفة أن حالة فشلت ومعرفة أي قرار فشل.
والمقايضة حقيقية. فالتقاط السياق الكامل ثقيل على التخزين، ويُبطئ مسار الكتابة، ويفرض انضباطًا على فرق تتعامل حاليًا مع الـ prompts وإعدادات الاسترجاع كمتغيرات بيئة. كما أن التقاط استجابات الأدوات قد يلتقط حمولات حساسة، ما يستلزم التنقيح عند الكتابة لا عند التحليل. لا شيء من هذا مجاني، والاستوديو الذي يتبنى إعادة التشغيل ينبغي أن يتوقع الاستثمار في سياسة الاحتفاظ وحوكمة المخطط قبل أن يرى العائد. والبديل — تقييم مخرجات لا تستطيع إعادة إنتاجها — أرخص لكل تشغيل وأغلى لكل عيب.
ماذا يمنح هذا المشغّل
تصبح الحالة الفاشلة قابلة لإعادة الإنتاج. فبدلًا من لقطة شاشة وذاكرة غامضة لما طُلب، يملك المشغّل تتبعًا يعيد التشغيل إلى الجواب الخاطئ نفسه، وفرقًا يُظهر أي خطوة أدخلته. وإعادة الإنتاج شرط مسبق للإصلاح؛ فبدونها، يكون التنقيح تخمينًا.
وتصبح كلفة التقييم قابلة للإسناد. فتشغيل إعادة التشغيل على مدخلات مجمّدة يمارس منطق القرار دون إعادة جلب بيانات حيّة أو إعادة تشغيل استرجاع استكشافي. وهذا يجعل مجموعات الانحدار أرخص في التشغيل وأسهل في الفهم، لأن كل تشغيل يختبر شيئًا واحدًا بدلًا من خط الأنابيب كله. وتبقى التشغيلات الاستكشافية الجديدة قيّمة، لكنها تكف عن كونها الخيار الوحيد.
ويصبح الاتساق خاصية قابلة للقياس لها خط أساس. فبدلًا من معاملة الاستقرار كحكاية — «عمل بالأمس» — يستطيع المشغّل تتبع معدلات التباعد لكل خطوة عبر عمليات النشر ومعرفة ما إذا كان تغيير prompt أو ترقية نموذج قد حرّكهما. وهذا هو التحول الذي تشير إليه خيوط Concordance وDeepEval معًا: تتبّع السياق، وأعد تشغيله تحت السيطرة، وقيّم المسار. النموذج نادرًا ما يكون اللغز. المدخلات المفقودة هي اللغز.