منع الهلوسة - وثائق Entity Enricher

منع الهلوسة

عندما تُنتج نماذج الـ LLM بيانات مُهيكلة، يمكن أن تختلق حقائق تبدو معقولة. يستخدم Entity Enricher 8 طبقات دفاعية لضمان حصولك على بيانات دقيقة أو لا بيانات على الإطلاق — لا خيالًا يبدو واثقًا.

مشكلة الهلوسة المُهيكلة

في النص الحر، تكون الجملة المُهلوَسة غامضة بوضوح. أما في المخرجات المنظَّمة، فيبدو الحقل المُهلوَس مثل "founded_year": 1987 موثوقًا ويكاد يستحيل تمييزه عن قيمة صحيحة. وهناك ثلاثة عوامل تجعل ذلك خطيرًا بوجه خاص:

دقة زائفة

تبدو قيمة JSON المهلوَسة تمامًا مثل القيمة الحقيقية. لا تحفّظ، ولا "تقريبًا" — مجرد نقطة بيانات نظيفة وواثقة تصادف أنها خاطئة.

ضغط المخطط

تُجبر الحقول المطلوبة نموذج LLM على إنتاج قيمة حتى عندما لا تتوفر لديه أي معرفة. فيختلق النموذج بيانات بدلاً من ترك فجوة في البنية.

الانتشار الصامت

تتدفق البيانات المهيكلة مباشرة إلى قواعد البيانات والتحليلات والأتمتة. تنتشر أي قيمة خاطئة عبر المسارات دون مراجعة بشرية.

أنماط الهلوسة الشائعة

نمطمثالالسبب
اختلاق واثق"ceo": "John Smith"يملأ LLM الحقل المطلوب باسم مقبول ظاهرياً
الالتباس الزمني"revenue": "$2.3B"حد بيانات التدريب أو الخلط بين الفترات
خلط الكياناتسمات من الشركة A على الشركة Bأسماء متشابهة في بيانات تدريب متداخلة
قيم افتراضية معقولة"employees": 500يختار LLM رقماً «معقولاً» بدلاً من الاعتراف بعدم المعرفة
علاقات مُختلقة"subsidiary_of": "Alphabet"يستنتج LLM علاقة غير موجودة

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

8 طبقات دفاعية

لا يعتمد Entity Enricher على تقنية واحدة. بل يجمع بين 8 طبقات دفاع مستقلة، تستهدف كل منها نمط إخفاق مختلفًا. وإذا فاتت إحدى الطبقات رصد هلوسة، تلتقطها الطبقة التالية.

1
التصنيف المسبق

قبل بدء الإثراء، يُصنّف نموذج LLM سريع ما إذا كان الكيان يطابق نوع المخطط. يمنع ذلك هلوسة الكيان بالكامل من المصدر.

مثال: يُوسَم «Titan» عند قياسه مقابل مخطط «كوكب» بأنه قمر — وتتلقى نماذج الإثراء هذا السياق وتستخدم null للحقول الخاصة بالكواكب.

2
المجاهيل المُصرَّح بها والمطالبة المتحفظة

تُوجِّه جميع الاستراتيجيات الـ LLM: «كن دقيقًا ومتحفظًا — لا تختلق أي قيمة أبدًا.» يُصرّح النموذج بالحقول التي تعذّر عليه تحديدها بدلًا من ملئها بقيم بديلة، وتتحوّل هذه التصريحات إلى قيم null صادقة في المُخرَجات.

يعالج هذا مباشرةً ضغط المخطط — السبب الأول للهلوسة المُهيكلة. كما يزيل المجهول المُصرَّح به الالتباس عن الإجابات الحقيقية: فالقيمة 0 التي يتبنّاها النموذج بيانات، أما القيمة 0 المُصرَّح بأنها مجهولة فليست كذلك.

3
تحديد نطاق مجال الخبرة

تُجمَّع خصائص المخطط حسب مجال الخبرة. لا يرى كل استدعاء LLM سوى الحقول ضمن مجاله، مع تعليمات بالتركيز حصرياً على ذلك المجال.

النطاق الأضيق يعني فرصة أقل للهلوسة. فالخبير المالي لا يخمّن أبداً بشأن البيانات التنظيمية.

4
التركيز على مفتاح البحث

يتم إبراز الخصائص المفتاحية (المعلَّمة is_key: true) في التوجيهات لتثبيت الـ LLM على المعلومات التعريفية قبل ملء الحقول الأخرى.

يؤسّس هذا النموذج على حقائق معروفة، مما يقلّل الانحراف نحو تفاصيل مُلفَّقة.

5
التحقق من المخطط والتصحيح الذاتي

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

حتى 5 محاولات تصحيح تلقائية داخل تشغيل واحد للوكيل. (يصحّح توليد المخطط نفسه بطريقة مختلفة — لكل خطوة، مع بدائل حتمية.)

6
الحفاظ على المنطق

تُستعاد الحقول المميَّزة بـ preserve: true (المعرّفات وأكواد SKU ومعرّفات الاستيراد) إلى قيم إدخالها الأصلية بعد الإثراء — فلا يستطيع LLM الكتابة فوق البيانات المرجعية الموثوقة. ويجب أن توفّر طلبات الإثراء قيمةً لكل حقل محفوظ، حتى لا يُثبَّت أي شيء على null أو يُختلَق.

داخل المصفوفات، تُطابَق العناصر المُثراة مع عناصر إدخالك بحسب حقول المفتاح الخاصة بها؛ أما العناصر التي يكتشفها الذكاء الاصطناعي فتحصل على null بدلًا من معرّف مُختلَق.

7
توافق متعدد النماذج

تشغيل الكيان نفسه عبر نموذجين مستقلين أو أكثر ومقارنة المخرجات حقلًا بحقل. ويُشار إلى الاختلافات باعتبارها هلوسات محتملة.

إذا قال Claude إن الإيرادات 2.3 مليار دولار وقال GPT-4 إنها 1.8 مليار دولار — فسيُكتشَف هذا التعارض ويُعرَض.

8
حلّ التعارضات والتحكيم

تُحَلّ التعارضات المكتشفة عبر تصويت قائم على القواعد (الأغلبية، الوسيط، الاتحاد) أو عبر محكّم LLM مخصّص يقيّم الدقة والاكتمال والاتساق.

يتضمّن كل قرار مفاضلة تبريره ومستوى ثقته — شفافية كاملة في كيفية حل التعارضات.

خط الدفاع

1التصنيف المسبقحظر أنواع الكيانات الخاطئة
2قابل للإبطال + مطالبات محافظةتقليل ضغط المخطط
3تحديد نطاق مجال الخبرةتضييق ما يجب أن يجيب عنه نموذج LLM
4تركيز مفتاح البحثالارتكاز على المُعرّفات
5التحقق والتصحيح الذاتيإصلاح الأخطاء الهيكلية
6الحفاظ على المنطقحماية البيانات المرجعية
7توافق متعدد النماذجاكتشاف الاختلافات
8تحكيم التعارضاتالحل مع الاستدلال
ما قبل الإثراء
أثناء الإثراء
ما بعد الإثراء

فلسفة التصميم

المبدأ الأساسي

البيانات المفقودة أفضل دائماً من البيانات الخاطئة. كل طبقة تعزز هذا المبدأ — فالنظام مصمم لإرجاع null بدلاً من اختلاق يبدو معقولاً.

ماذا يفعل Entity Enricher
  • يمنح نماذج LLM إذنًا صريحًا بإرجاع null
  • يتحقق تحققًا متقاطعًا باستخدام نماذج مستقلة متعددة
  • يحمي البيانات المعروفة السلامة من الكتابة فوقها
  • يُظهر شفافية كاملة في حل التعارضات
ما تفعله الأدوات المعتادة
  • إجبار نماذج LLM على ملء كل حقل مهما كان
  • الاعتماد على نموذج واحد دون التحقق المتقاطع
  • السماح لـ LLM بالكتابة فوق بيانات الإدخال بحرية
  • إرجاع النتائج كصندوق أسود دون مسار تدقيق