التطوير المُوجَّه بالتقييم لأنظمة الذكاء الاصطناعي المالية

يعني التطوير المُوجَّه بالتقييم أن تكتب الاختبار المُقيَّم قبل أن تبني الميزة. فأنت تُعرّف مجموعة من الحالات المُقيَّمة التي تُرمّز شكل الإجابة الصحيحة، وتربطها بالتكامل المستمر (CI)، وتجعلها تحكم كل تغيير في مسار الذكاء الاصطناعي. أي طلب سحب (pull request) يُخفّض الدرجة لا يُدمَج. مجموعة التقييم هي العقد؛ وعلى الشيفرة أن تفي به.

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

ابنِ مجموعة التقييم قبل الميزة

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

مصدر الحالات أهم من عددها. استخلص من ثلاثة أماكن:

• آثار تشغيل (traces) حقيقية، مأخوذة كعيّنات عبر أنواع المستندات والمدينين والفترات المُبلَّغ عنها، بحيث يطابق التوزيع ما يراه النظام فعلًا لا ما يسهل اختباره.
• الحوادث السابقة. كل رقم خاطئ وصل إلى إنسان يصير حالة دائمة. هذا هو تقييم الانحدار (regression eval)؛ وما إن يدخل عيبٌ إلى المجموعة، لا يمكنه العودة بصمت.
• حالات خصامية (adversarial) تصنعها عمدًا: الإقرار المُعدَّل، والكشف الذي يحمل فخّ استباق (lookahead) حيث تناقض صفحة لاحقة صفحة سابقة، والاسم الذي يُحلّ إلى طرفين مقابلين مختلفين.

تستحق الصحة عند نقطة زمنية محدّدة (point-in-time correctness) عنايةً خاصة. فإن غذّى تقييمك النموذج ببيانات لم تكن لتوجد عند تاريخ القرار، فأنت تختبر مقابل تسرّب (leakage) ودرجاتك متضخّمة. جمّد كل حالة على المعلومات المتاحة عند تاريخها المرجعي (as-of date)، وقيّم الإجابة مقابل ما كان معروفًا آنذاك.

قيّم بأصرم أسلوب تسمح به المهمة. الرقم المحسوب يخضع لفحص عددي دقيق أو مبني على هامش تفاوت (tolerance). والاستشهاد يخضع لمُحلِّل (resolver) يؤكّد أن المستند والسطر المُشار إليهما موجودان فعلًا ويقولان ما يدّعيه النموذج. احتفظ بالمعايير المُقيَّمة بحَكَم نموذجي (LLM-judged rubrics) للصفات المُقيَّمة تدريجيًا حقًا مثل الاكتمال أو النبرة، وذلك فقط بعد أن تتحقّق من توافق الحَكَم مع التسميات البشرية على عيّنة محجوزة (holdout). فالحَكَم غير المُتحقّق منه ليس سوى مولّد أرقام عشوائية بقواعد نحوية سليمة.

اجعل كل تغيير يمرّ عبر بوابة في التكامل المستمر

ما إن توجد المجموعة، يُشغَّل التقييم ضمن التكامل المستمر (CI) على كل طلب سحب يمسّ مسار الذكاء الاصطناعي: التوجيهات (prompts)، والاسترجاع (retrieval)، والتقطيع (chunking)، وإصدار النموذج، وتعريفات الأدوات، والمعالجة اللاحقة. تُقيّم المهمة البناء الحالي وتقارنه بعتبات مُجمّدة لكل مقياس. أي هبوط دون العتبة على أي مقياس محمي يُفشل الفحص، فيحجب طلب السحب تمامًا كما يفعل اختبار وحدة ساقط.

بضع ممارسات تُبقي هذا نزيهًا.

• افصل المقاييس بدل دمجها في رقم واحد. تتبّع دقّة المطابقة التامة (exact-match)، وصحّة الاستشهاد، ومعدّل الرفض على المُدخلات خارج النطاق، وميزانية إيجابياتك الكاذبة (false-positive)، كلٌّ على حدة. فالدرجة المدموجة تسمح لمكسبٍ في موضع أن يُخفي انحدارًا في آخر.
• ثبّت النموذج ومعاملات فك الترميز (decoding parameters)، وسجّلها في التشغيلة. حين تتحرّك الدرجة، عليك أن تعرف هل تغيّرت الشيفرة أم تغيّر المورّد. اضبط حدود اللاحتمية (non-determinism) ببذور (seeds) ثابتة حيث توجد، وبالتشغيل حتى تجميعٍ مستقرّ حيث لا توجد.
• احتفظ بشريحة محجوزة (holdout) لا يراها أبدًا المطوّرون الذين يكتبون التوجيهات. فالضبط مقابل كل حالة مرئية يؤدّي في النهاية إلى فرط ملاءمة (overfitting) التوجيه للتقييم، والشريحة المحجوزة هي وسيلتك لاكتشاف ذلك.

اضبط العتبات بتحفّظ. لا تُثبّتها على الدرجة الحالية وتمنع كل حركة؛ بل تضع أرضية تحمي السلوكيات التي وعدت بها وتدع الضوضاء العادية تمرّ. رفع العتبة قرار يُتّخذ ضمن المراجعة، مع نَسَب الأثر (trace lineage) الذي يُظهر أي الحالات تحرّكت ولماذا.

عامِل التقييم بوصفه أثرًا مَحكومًا

مجموعة التقييم التي تحكم قرارات الإنتاج هي نفسها جزء من مسار التدقيق (audit trail). أخضِعها للإصدار، وراجِع التغييرات عليها في طلبات السحب، واشترط سببًا عند تحرير حالة أو حذفها. فحذف حالة غير مريحة أو خفض عتبة بصمت هو المكافئ في عالم الذكاء الاصطناعي لتحرير الاختبار كي يمرّ البناء بلون أخضر، وينبغي أن يكون ظاهرًا كأي تغيير آخر في الضوابط. ضمن إطار مخاطر النماذج مثل SR 11-7، تُشكّل مجموعة التقييم جزءًا كبيرًا مما يعنيه “الرصد المستمر” (ongoing monitoring) و”التحدّي الفعّال” (effective challenge) بشكل ملموس بالنسبة لنموذج لغوي، وتشير توقّعات اختبار الصمود في لائحة DORA للأنظمة الحرجة إلى الاتجاه نفسه.

العائد يتراكم. فكل حادثة تصير حالة تجعل التقاط الانحدار التالي أرخص. وكل نوع مستند جديد يُؤخَذ كعيّنة في المجموعة يوسّع ما تحميه البوابة. على مدى ربع سنة، تصير مجموعة التقييم أدقّ وصفٍ لديك لما يفعله النظام، بانحرافه وكل شيء، لأنها الوصف الوحيد الذي يُنفَّذ عند كل تغيير بدل أن يُكتب مرة ثم يُترك ليتعفّن. وحين يسأل مدقّق لماذا تثق بنموذج يمسّ دفتر أستاذ عامًّا (general ledger) أو قرارًا سلبيًا (adverse-action)، تكون مجموعة التقييم هي الجواب، ويكون سجلّ إصداراتها وسجلّ عمليات الدمج المحجوبة هو الدليل الذي يسندها.