نموذج لغوي يختلق رقم خط مساعدة: لماذا لا يحمي التوجيه النصي (البرومبت) من الهلوسة

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

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

المشكلة ليست في سوء نية ولا في برومبت رديء الصياغة. فالنماذج اللغوية مدرَّبة على التنبؤ بالرمز (token) التالي بحيث تبدو النتيجة مفيدة وملائمة قدر الإمكان في السياق المعطى. وحين يتطلب السياق بيانات اتصال، يولّدها النموذج. فتعليمة «لا تختلق» تتنافس مع سلوك مكتسب لدى مليارات المعاملات التي ضُبطت عبر RLHF على الإفادة (helpfulness). وفي هذا التنافس يخسر البرومبت في معظم الأحيان. فرغبة النموذج في أن يكون مفيدًا تتفوق على أي حظر لفظي.

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

ما الذي ينجح بدلًا من البرومبت؟

الفصل المعماري. تُخزَّن جهات الاتصال في قاعدة بيانات موثَّقة، لا في أوزان النموذج. ويتعرف الـLLM على قصد المستخدم ثم يستدعي دالة أو يُجري استعلام RAG، فيحصل على رقم محدد من صف محدد في جدول. النموذج لا يولّد الأرقام، بل يستخرجها. والفرق جوهري.

استدعاء الدوال (function calling، tool use) يحل المسألة مباشرة. تصف أداة مثل get_crisis_contact(region, type)، وعند توافر القصد المناسب يستدعيها النموذج بدلًا من أن يختلق. فالإجابة تُؤخذ من قاعدة البيانات، لا من التوزيع الاحتمالي للرموز. وثمة نمط مشابه هو RAG بصيغة إجابة صارمة: إذا لم يُعثر على المستند، فعلى النموذج أن يُعلن ذلك صراحةً بدلًا من أن يؤلّف جوابًا.

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

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

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

والخلاصة بسيطة: البرومبت ليس وسيلة تحكّم، بل أمنية. فإذا كان السلوك حاسمًا لسلامة المستخدم، فأخرِج البيانات المحددة من نطاق التوليد الذي يتحكم فيه النموذج. أعطِه دوال وقواعد بيانات وأدوات. دعه يفهم السياق ويفسّر القصد، لكن لا تدعه يخترع الحقائق. هذه هي البنية المعمارية، لا مجموعة كلمات سحرية في system prompt.