كل عرض تجريبي لـ RAG (توليد الإجابات اعتمادًا على مستنداتك الخاصة) رأيناه خلال العامين الماضيين يبدو سحريًا، وكل نظام RAG في بيئة الإنتاج طُلب منا إصلاحه خلال الاثني عشر شهرًا الماضية كان يعاني المشكلات نفسها بالضبط. الفجوة بين العرض التجريبي والإنتاج ليست في النموذج — بل في كل ما يحيط بالنموذج.
حين نطلق نظام retrieval-augmented generation، أول ما نبنيه هو eval harness (منظومة اختبار جودة الذكاء الاصطناعي). لا الـ prompt، ولا خط أنابيب الـ embeddings. المنظومة أولًا — وهي عادةً 200–2,000 مثال مرجعي تغطي الأسئلة التي يفترض بنظامنا أن يجيب عنها، مقرونة بالإجابات التي نعرف يقينًا أنها صحيحة.
من دون هذه المنظومة، كل تغيير في النظام مجرد تخمين. ومعها، كل تغيير قابل للقياس. وبعد ستة أشهر، حين يُحدَّث النموذج، تصبح لديك إجابة بضغطة واحدة: هل نفع التحديث أم أضرّ؟
الشيء الثاني الذي نبنيه هو الاسترجاع الهجين. BM25 يلتقط ما يفوت البحث الشعاعي. وإعادة الترتيب (re-ranking) تلتقط ما يفوت الاسترجاع الهجين. وإعادة صياغة الاستعلام تلتقط ما تُضيّعه أسئلة المستخدمين الرديئة. كل طبقة من هذه الطبقات تشتري لك قدرًا قابلًا للقياس من الاسترجاع، والمفروض أن تعرف أي طبقة تؤدي العمل فعلًا.
الشيء الثالث — وهو الجزء الذي تتخطاه معظم الفرق — هو القابلية للمراقبة. كل عملية استرجاع، وكل prompt، وكل استجابة، مسجّلة ومربوطة بـ trace ID يعيدها إلى سؤال المستخدم الأصلي. وحين يختلّ شيء بعد ستة أشهر من الآن، تريد أن تكون قادرًا على الإجابة عن سؤال «لماذا أجاب بهذا؟» في أقل من دقيقة.
RAG من أنفع ما يمكنك بناؤه اليوم. وهو في الوقت نفسه من أسهل ما يُقدَّم كعرض تجريبي، ومن أصعب ما يُبقى حيًّا في الإنتاج. لا تتخطَّ الأجزاء غير البرّاقة.
بقلم فريق brainiac/studio. ننشر أعمالًا أصلية يكتبها المهندسون والمصممون والمسوّقون الذين ينفّذون العمل بأنفسهم — ولا نُسندها أبدًا إلى مصنع محتوى.