مراقبة نماذج اللغة الكبيرة وتتبّعها في أعباء العمل المالية

يكون النظام المالي المبني على نماذج اللغة الكبيرة (LLM) قابلاً للتشخيص عندما يمكن إعادة بناء أي إجابة أنتجها في الربع الماضي إعادةً دقيقة: المطالبة (prompt) بصيغتها النهائية المُجمَّعة، والسياق المُسترجَع وإصداراته، والمُخرَج الخام، وعدد الرموز (tokens)، واسم النموذج. المراقبة (observability) هي انضباط التقاط ذلك الأثر (trace) عند كل استدعاء، ثم إجراء فحوصات زهيدة التكلفة عليه في بيئة الإنتاج بحيث يظهر أي تراجع على هيئة تنبيه لا على هيئة شكوى من عميل.

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

الأثر شجرة، وتلك الشجرة هي وحدة عملك

يمكن أن يتفرّع سؤال واحد من المستخدم إلى خطوة استرجاع، وثلاثة استدعاءات أدوات (tool calls)، وتمريرة إعادة ترتيب (re-ranking)، وإكمالين للنموذج. فإذا سجّلتَ ذلك على هيئة أسطر منفصلة، فلن تستطيع الإجابة عن السؤال الوحيد المهم حين يتعطّل شيء ما: ماذا فعل خطّ المعالجة بأكمله لهذا المُدخَل تحديداً. لذا فإن النطاق (span) الذي يعنيك هو الأثر (trace)، وهو شجرة تربط كل استدعاء فرعي بجذر واحد، بمعرّف ثابت يمكنك تسليمه لمحلّل أو لصقه في تذكرة (ticket).

نلتقط لكل عقدة في تلك الشجرة ما يلي:

• المطالبة بصيغتها النهائية، بعد تصيير القالب (template) وحقن السياق، لا القالب نفسه. القالب يخبرك بالنيّة؛ أما المطالبة النهائية فتخبرك بما ذهب فعلاً إلى النموذج، بما في ذلك الأرقام المُسترجَعة التي قد تكون خاطئة.
• السياق المُسترجَع مع معرّفات المستندات وتواريخ الإصدار أو تواريخ الصلاحية (as-of dates). هنا تكمن الصحّة عند لحظة زمنية محدّدة (point-in-time). فإذا سحب المُسترجِع نموذج 10-Q مُعاد بيانه (restated) لم يكن موجوداً في تاريخ القرار، تبدو الإجابة قابلة للدفاع عنها بينما تُسرِّب بهدوء معلومات مستقبلية.
• المُخرَج الخام للنموذج قبل أي تحليل نحوي (parsing). المُحلِّلات النحوية تخفي الأعطال. فحين يتراجع استخلاص JSON إلى قيمة افتراضية، تريد أن ترى المُخرَج المشوَّه الذي سبّب ذلك.
• عدد الرموز للمُدخَل والمُخرَج، واسم النموذج وإصداره، ودرجة الحرارة (temperature)، وزمن الاستجابة لكل عقدة.

قاعدتان عمليّتان. الأولى، مرِّر معرّف الأثر عبر كل قفزة، بما في ذلك استدعاءات الأدوات التي تغادر عمليّتك، وإلا فقدت الشجرة فروعاً. الثانية، لا تأخذ أي عيّنة على مسار الكتابة في المجال المالي. التخزين أرخص من كسر تسوية (reconciliation) غير قابل لإعادة الإنتاج في نهاية الربع. خُذ العيّنات لاحقاً، حين تقرّر ما الذي ستصنّفه.

عدد الرموز أبكر إشارة انحراف لديك

تعامل الفرق عدد الرموز بوصفه بنداً في الفاتورة. لكنه أيضاً أنقى إشارة إنذار مبكّر لديك للانحراف السلوكي. فخلل استرجاع يبدأ في حشو ضعف كمية السياق في المطالبة يظهر على هيئة تغيّر مفاجئ في رموز المُدخَل قبل أيام من ملاحظة أي أحد أن الإجابات صارت أكثر غموضاً. ومحاولة حقن مطالبة (prompt injection) تجعل النموذج يُسهب تظهر على هيئة ارتفاع مفاجئ في رموز المُخرَج على مجموعة ضيّقة من الآثار.

لذا نحاسب الرموز لكل أثر، ولكل قالب مطالبة، ولكل مستأجِر (tenant)، ونطلق التنبيهات على تحوّلات التوزيع لا على الإجماليات:

• رموز المُدخَل لكل قالب. القفزة تعني أن عملية تجميع السياق قد تغيّرت، عادةً لأن المُسترجِع أعاد مستندات أكثر عدداً أو أطول ممّا صُمِّمت له المطالبة.
• رموز المُخرَج لكل قالب. القفزة في مهمّة يُفترض أن تُنتج مخطّطاً ثابتاً تعني أن النموذج توقّف عن احترام التنسيق، وهو غالباً أول عَرَض لتغيير إصدار النموذج من جهة المزوّد.
• التكلفة المنسوبة إلى المستأجِر وسير العمل، بحيث يمكن قراءة معدّلات المعالجة الآلية المباشرة (straight-through processing) مقابل الإنفاق. فسير عمل يحتاج إلى ثلاث محاولات إعادة لكل نجاح يخبرك بشيء لن يخبرك به مخطّط متوسّط زمن الاستجابة.

المقصود أن قياسات الرموز، المُلتقَطة على مستوى الأثر، تعمل في الوقت نفسه بوصفها مراقباً سلوكياً. أنت تدفع أصلاً لعدّ الرموز من أجل الفاتورة. وجِّه الأرقام نفسها إلى نظام التنبيه لديك.

يجب أن يجري التقييم في بيئة الإنتاج أيضاً

مجموعات التقييم دون اتصال (offline) تلتقط ما خطر لك أن تختبره. أما بيئة الإنتاج فتلتقط الباقي. وتزداد أهمية هذه الفجوة في المجال المالي أكثر منها في المحادثة العامة، لأن مُدخَلاتك عدائية بطبيعتها: تُعاد بيانات الإقرارات المالية، وتتصادم أسماء الكيانات عبر الشركات التابعة، وطرف مقابل كان كياناً قانونياً واحداً الشهر الماضي صار كيانين بعد فصلٍ (carve-out). مجموعة تقييم مُجمَّدة في مارس لن تحتوي على الحالات الحدّيّة التي تطرأ في يونيو.

نُجري مستويين من الفحوصات باستمرار. الفحوصات التي لا تتطلّب مرجعاً (reference-free) تعمل على كل طلب ولا تحتاج إلى وسوم:

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

المستوى الثاني هو تقييم مُصنَّف على شريحة مُعيَّنة، باستخدام معيار تصنيف (rubric) ومراجعة بشرية أو نموذج بوصفه حَكَماً (model-as-judge) تُسجِّل مُخرَجاته وتدقّقها أنت أيضاً. أنت لا تصنّف كل أثر؛ بل تصنّف عيّنة طبقيّة (stratified) إضافةً إلى كل أثر أخفق في فحص لا يتطلّب مرجعاً، لأن هذه هي المواضع التي تستحق فيها الوسوم ما تدفعه مقابلها. أعِد تغذية الأعطال المؤكَّدة في المجموعة دون اتصال حتى يُختبَر الإصدار التالي مقابلها. تلك الحلقة، لا لوحة المعلومات، هي ما يُبقي النظام أميناً بين نهايات الأرباع.

أمرٌ أخير من السهل تخطّيه ومكلفٌ أن تتخطّاه. اربط مخزن التتبّع (trace store) بمتطلّبات التدقيق وتتبّع الأصل (lineage) لديك منذ اليوم الأول. فحين يسأل جهة تنظيمية أو مراجع داخلي عن سبب إنتاج النظام لرقم مُعيَّن في تاريخ مُعيَّن، تكون الإجابة معرّف أثر وشجرته الكاملة، محفوظَين تحت الضوابط نفسها المطبَّقة على البيانات الأساسية. فإن بنيتَ المراقبة بوصفها وسيلة تصحيح مريحة وأضفتَ الاحتفاظ لاحقاً، فستكتشف أن الآثار المفيدة قد انتهت صلاحيتها في الأسبوع السابق للحظة التي احتجتها فيها.