رفعت Legora دقة الاستشهادات القانونية من 70% إلى 99% من دون الوصول إلى البيانات

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

تبني Legora عملية التقييم بطريقة مختلفة. ينشئ المهندسون والمحامون بيئات اختبار تشبه العمل الحقيقي: مساحات تضم آلاف الملفات، ومهام للعثور على بنود داخل العقود، وإعداد المسودات، والتحقق من الاستشهادات. ليست هذه نسخة مثالية من ملفات العملاء، لكنها ميدان اختبار قريب بما يكفي لاكتشاف الأخطاء المتكررة قبل الإصدار.

كيف تختبر ما لا يمكنك رؤيته

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

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

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

المقاييس أهم من عرض توضيحي مبهر

يُعد مثال الاستشهادات كاشفًا على نحو خاص. وفقًا للاوريتزن، كان النموذج في أحد الاختبارات يشير إلى المصادر الصحيحة في نحو 70% من الحالات. وبعد تحديث لاحق للنموذج الأساسي، ارتفعت النسبة إلى 99%، رغم أن Legora لم تغيّر نظامها. هذه أخبار جيدة للمنتج، لكنها تحذير في الوقت نفسه: جودة الوكيل لا تعتمد على شفرتك وحدها. فقد يصلح مزود النموذج نقطة ضعف فجأة، أو يعطل ما كان يعمل بالأمس.

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

ما الذي يمكن نقله إلى منتج اعتيادي

لا يقتصر نفع نهج Legora على المحامين. فالمساعد المصرفي أو الوكيل الطبي أو محرك البحث المؤسسي يواجه الحد نفسه: يجب تحسين المنتج، لكن لا يمكن منح المطورين البيانات الخام. تتألف الوصفة العملية من أربعة أجزاء: وصف سيناريوهات العمل الحقيقية، وبناء نظائر آمنة لها، ووضع علامات على النتائج المتوقعة، والاحتفاظ بفهرس للأعطال المتكررة.

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

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