ملخص تقني: LEDGER – رسوم بيانية لتتبع الادعاء إلى الدليل لأغراض تدقيق وكلاء النماذج اللغوية الكبيرة (LLM)

بيان المشكلة

مع تطور وكلاء النماذج اللغوية الكبيرة (LLM) من أنظمة الإجابة على الأسئلة أحادية الدور إلى عمال تفاعليين قادرين على تنفيذ سير عمل تقني طويل الأمد (يتضمن استخدام الأدوات، تنفيذ الكود، تعديل الملفات، وإنشاء المصنوعات الرقمية/Artifacts)، انتقل العائق الرئيسي في الإنتاجية من توليد المخرجات إلى قابلية التدقيق (Auditability). بينما توفر أنظمة المراقبة الحالية (مثل LangSmith) رؤية دقيقة لأحداث التنفيذ (المطالبات، استدعاءات الأدوات، الأخطاء، والمخرجات الوسيطة)، فإن هذه الرؤية لا تعني بالضرورة قابلية التدقيق.

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

المنهجية: نظام LEDGER

يقدم المؤلفون نظام LEDGER (رسوم بيانية لطبقات الأدلة والقرارات للمراجعة التنفيذية)، وهو نظام تتبع ومراجعة جانبي يعمل بجانب جلسات الوكلاء التفاعلية دون تعديلها. لا يستبدل LEDGER أنظمة المراقبة، بل يعيد تنظيم السجلات الملتقطة في رسم بياني دلالي متعدد الطبقات مصمم للمراجعة البشرية.

1. التقاط وتسجيل التتبع

أساس LEDGER هو سجل التتبع (Trace Record)، وهو ركيزة مستقرة وغير تفسيرية لبيانات الجلسة الملتقطة.

• الآلية: يستخدم النظام خطافات دورة الحياة (مثل SessionStart و PreToolUse و PostToolUse) وإعادة بناء النص (Transcript) لالتقاط حمولات JSON تحتوي على الرسائل، واستدعاءات الأدوات، والنتائج، وتفاعلات الملفات.
• النزاهة: تحفظ هذه السجلات الترتيب والمحتوى الأصلي للجلسة، بما في ذلك الروابط إلى النص المصدر. وهي تعمل كـ "مصدر للحقيقة"، متميزة عن أي هيكل مستنتج.

2. بناء الرسم البياني الطبقي

ينظم LEDGER سجلات التتبع في هيكل رسومي ثلاثي المستويات:

• عقد الأدلة (Evidence Nodes): تجمع هذه العقد سجلات التتبع ذات الصلة الوثيقة (مثل استدعاء أداة ونتيجتها) في وحدات عمل قابلة للفحص. ويتم تصنيفها حسب النوع (إجراء مقابل مصنوع رقمي) والفئة (مثل user_message أو tool_call أو control أو artifact). تمثل عقد المصنوعات الرقمية (Artifact nodes) تحديدًا كائنات قابلة للفحص مثل تصحيحات الكود (patches)، أو المخططات البيانية، أو الجداول، أو مخرجات الأوامر.
• عقد سير العمل (Workflow Nodes): تجمع هذه العقد عقد الأدلة ذات الصلة في مراحل مهام أعلى مستوى (مثل context و plan و inspect و execute و validate و claim). يسمح هذا التجريد للمراجعين بعرض الجلسة على مستوى المرحلة بدلاً من مستوى الحدث الواحد.
• الحواف الدلالية (Semantic Edges): تربط الحواف الموجهة والمصنفة العقد ببعضها لتعريف العلاقات. تشمل أنواع الحواف الرئيسية ما يلي:
  • uses (يستخدم): وحدة عمل تستهلك مصنوعًا رقميًا.
  • produces (ينتج): وحدة عمل تنشئ أو تعدل مصنوعًا رقميًا.
  • checked_by (تم التحقق بواسطة): يتم التحقق من تغيير بواسطة خطوة محددة.
  • supports (يدعم): دليل يبرر ادعاءً.
  • informs (يُخبر/يؤثر على): نتيجة تشكل خطة لاحقة.
  • frames (يؤطر): متطلب يضع السياق لمهمة ما.

3. الواجهة وسير عمل المراجعة

يوفر النظام لوحة تحكم محلية تدمج:

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

المساهمات الرئيسية

1. بناء رسم بياني لتتبع الادعاء إلى الدليل: طريقة لتحليل جلسات الوكلاء غير المعدلة إلى رسم بياني دلالي طبقي حيث تمثل عقد المصنوعات الرقمية أدلة قابلة للفحص، وتربط الحواف المصنفة الادعاءات بخطوات الإجراء والتحقق الداعمة لها بشكل صريح.
2. واجهة مراجعة مرتكزة على الأدلة: لوحة تحكم توحد مسارات تدقيق مستوى الرسم البياني مع السجلات والمصنوعات المصدرية، مما يسمح للمراجعين بالتحرك بسلاسة بين الهيكل المنطقي لسير العمل وبين الأدلة الخام.
3. الفصل بين الالتقاط والتفسير: تصميم يفصل بصرامة بين السجلات المصدرية الحتمية (سجلات التتبع) والهيكل المستنتج (عقد الأدلة وسير العمل)، مما يضمن بقاء الرسم البياني وسيلة مساعدة للتدقيق وليس مصدرًا غامضًا للحقيقة.

النتائج ودراسات الحالة

تحقق من صحة LEDGER من خلال دراستي حالة باستخدام وكيل Codex مع تفعيل التتبع الحي:

• دراسة الحالة 1: تحليل البيانات الجدولية: قام وكيل بتحليل بيانات جودة الهواء لإنشاء تقرير نمط يومي. نجح رسم التتبع البياني في كشف تسلسل المصنوعات الرقمية (artifact lineage)، حيث ربط الادعاء النهائي عبر المخططات المولدة وجداول الملخص وصولاً إلى خطوات تنظيف البيانات المصدرية. كما سلط الضوء على تسلسل الخطأ والإصلاح، موضحًا كيف تم تتبع تنفيذ نص برمجي فاشل (بسبب نقص في التبعيات)، ثم إصلاحه، ثم إعادة التحقق منه، مما جعل عملية الإصلاح شفافة.
• دراسة الحالة 2: إضافة ميزة إلى قاعدة كود (Codebase): قام وكيل بإضافة وظيفة (utility) "المسار الأقصر" إلى مكتبة NetworkX. ميز الرسم البياني بين التنفيذ الأولي واختبارات التراجع وتصحيحات الحماية (regression testing and guard patches) اللاحقة. سمح للمراجعين بتتبع الخيار التصميمي (وضع الوظيفة في وحدة برمجية محددة) وصولاً إلى فحص المستودع وقراءة التوثيق، وإلى الأمام نحو الاختبارات المحددة التي تحققت من السلوك.

في كلتا الحالتين، أظهر النظام القدرة على جعل "مسار التدقيق" صريحًا، مما سمح للمراجعين بالتحقق ليس فقط من أن ادعاءً قد تم، بل من كيفية دعمه بواسطة مصنوعات وفحوصات محددة.

الأهمية والادعاءات

تضع الورقة LEDGER كضرورة لتطور المراقبة في الوكلاء. تكمن أهميته في التحول من الرؤية (رؤية ما حدث) إلى قابلية التدقيق (فهم لماذا يمكن الوثوق باستنتاج ما).

• الادعاءات المتواضعة: يذكر المؤلفون صراحة أن بناء الرسم البياني ليس حتميًا بالكامل؛ حيث يقوم المتتبع بتفسير السجلات التي تنتمي لبعضها البعض وتعيين الحواف الدلالية. لذلك، يُقدم الرسم البياني كـ وسيلة مساعدة للتدقيق، وليس كمصدر للحقيقة. تم تصميم الواجهة لإبقاء السجلات الأساسية مرئية حتى يتمكن المراجعون من التحقق من بناء الرسم البياني.
• الاتجاه المستقبلي: تقترح الورقة أن العمل المستقبلي يجب أن يهدف إلى استبدال الهيكل المستنتج بواسطة النموذج بهيكل حتمي أو قابل للتحقق بشكل مستقل (على سبيل المثال، عبر أدوات قياس أقوى أو خلفيات واعية بالأصل/Provenance-aware backends) وتحسين المفردات المرئية للتمييز بشكل أفضل بين العلاقات الحتمية والمستنتجة.

في النهاية، يهدف LEDGER إلى دعم الحاجة المتزايدة للإشراف البشري في سير عمل الوكلاء المعقد من خلال الحفاظ على الوصول إلى السجلات المصدرية مع جعل الروابط بين الإجراءات، والمصنوعات، والاستنتاجات قابلة للفحص والتتبع.