مطوّر على Habr يبني بحثًا وكيليًا على نماذج مفتوحة المصدر ويختبر أين ينهار

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

ما المسألة التي يعالجها المؤلف

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

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

مم يتكوّن عادةً مثل هذا النظام

لا يسرد المؤلف المكوّنات في الخلاصة التعريفية، لذا فإن ما يلي هو المخطط العام الذي تُبنى وفقه أنظمة من هذا النوع. وهو ليس وصفًا لتصميمه.

• طبقة البحث: محرك بحث ميتا أو API لنتائج البحث يعيد قائمة بعناوين URL.
• أداة تحميل الصفحات: تجلب HTML وتنقّيه إلى نص مقروء، وتتعامل مع JavaScript وحالات الحظر.
• المخطِّط: LLM مفتوح يقسّم السؤال إلى استعلامات فرعية ويقرر متى يتوقف.
• المستخرِج: يستخرج من الصفحة الواقعة المطلوبة مع اقتباس حرفي.
• المدقِّق: يتحقق من أن عنوان URL موجود فعلًا، ومن أن الاقتباس موجود حقًا في الصفحة.

يجيب البند الأخير عن السؤال الرئيسي للمؤلف. فالرابط المختلق يظهر عندما يبني النموذج إجابته من الذاكرة لا من المستند الذي جرى تحميله. وإذا مرّ كل عنوان URL في الإجابة عبر فحص «الصفحة فُتحت والاقتباس عُثر عليه»، يتحول اختلاق الرابط من خطأ غير مرئي إلى نتيجة مرفوضة.

أين تتعطل هذه الأنظمة عادةً

يقول العنوان صراحةً إن شيئًا ما تعطّل. ونقاط الفشل المعتادة في البحث الوكيلي معروفة جيدًا، ومن المرجح أن المؤلف يصف بعضها.

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

كيف تستخدم هذا النهج عمليًا

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

• نسبة الإجابات التي تتضمن رابطًا صالحًا؛
• نسبة الإجابات التي يوجد فيها الاقتباس حرفيًا في الصفحة؛
• تكلفة الإجابة الناجحة الواحدة، لا تكلفة التشغيل الواحد؛
• عدد الخطوات حتى التوقف، ونسبة عمليات التشغيل التي دخلت في حلقات.

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