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

إعداد استرجاع بسيط للغاية

لم أستخدم Pinecone أو أي قاعدة بيانات متجهية (vector database) ثقيلة. يعتمد الإعداد بأكمله على ملف JSON بسيط. يقوم الكود الخاص بي بتقسيم ملفي الشخصي إلى أقسام منفصلة. عندما يصل سؤال، يحسب النظام تشابه جيب التمام (cosine similarity) بين الاستعلام وكل جزء من النص، ويختار المطابقات الأقرب، ثم يضعها في المطالبة (prompt) كـ "سياق". بعد ذلك، يقوم النموذج بتوليد إجابة بناءً فقط على ما يراه في تلك النافذة.

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

الأرقام التي زعزعت ثقتي

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

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

توقف عن الاختبار باستخدام أسئلة ودية

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

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

الخطآن اللذان كانا مؤثرين

صياغة المطالبات (Prompting) ليست ضماناً. إن التعليمات الطويلة والمفصلة التي تخبر الذكاء الاصطناعي بعدم الهلوسة ليست سوى اقتراح مُغلف في شكل أمر. قد يتبعها النموذج في معظم الأوقات، لكنه سيتجاهل التعليمات في اللحظة التي تدفعه فيها الضغوط الإحصائية إلى اتجاه آخر. درجة الحرارة (Temperature)، واحتمالية الرموز (token probability)، وشكل بيانات التدريب، كلها عوامل تزن أكثر من جملة في مطالبة النظام الخاصة بك. يجب عليك قياس الطاعة بالبيانات، وليس بالأمل. التعليمات القوية ليست حقيقة مؤكدة؛ إنها مجرد طلب، والطلبات قد تُرفض. إذا كانت استراتيجية الأمان بأكملها تعتمد على صياغة مطالبتك بحزم، فقد بنيت حاجز حماية من ورق المناديل. أنت بحاجة إلى إطار تقييم يحسب عدد المرات التي يطيع فيها النموذج، وتحت أي ظروف، ولماذا يفشل عندما يفشل. الأرقام لا تهتم بنبرة صوتك.

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