وكيل مفتوح المصدر في مواجهة 1C Napparnik: نظام RAG هجين على DeepSeek ينتصر عملياً

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

أخذ Habr أسئلة حقيقية من مطوري 1C وقارن وكيلاً مفتوح المصدر بـ Napparnik التجاري. وجاءت النتائج غير متوقعة.

البنية: نظام RAG هجين على LangGraph

اختِيرت النماذج من الطبقة الأعلى: deepseek-v4-flash و gpt-6.1-sol و glm-5.3-flash. تعمل جميعها بالطريقة نفسها مع الأدوات، ولديها نافذة سياق كافية. وتبيّن أن العامل الحاسم لم يكن النموذج نفسه، بل بيئته المحيطة.

الإطار المستخدم هو LangGraph (Deep Agents)، مع التخطيط، وتفويض المهام إلى وكلاء فرعيين، والتحكم في السياق عبر تلخيص السجل.

أما للمعرفة، فقد اعتُمد نظام RAG هجين. يرتكز الفرع النصي الكامل على FTS في PostgreSQL مع قاموس روسي، ويرتكز الفرع المتجهي على pgvector مع فهرس HNSW. تُدمج النتائج عبر Reciprocal Rank Fusion: ترتفع المرشحات ذات الترتيب العالي في كل نتيجة إلى القائمة النهائية.

لمصادر التهيئات النموذجية، بُني فهرس سريع لـ236 ألف ملف و193 ألف دليل. وأُضيف محلل للبيانات الوصفية: يجمع الكائنات، والخصائص، والروابط بينها، ما يساعد على التنقل بين الوحدات.

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

ثلاثة اختبارات على مهام حقيقية

1. سجل تقني لمهلات الأقفال المُدارة.

قدّم الوكيل تهيئة مع مرشّح لحالات الانتظار الطويلة (أحداث TLOCK >1 ثانية، وTTIMEOUT، وTDEADLOCK)، وحلّل حقل WaitConnections للعثور على الاتصال المُعطِّل، واقترح تتبّع تصرفاته: الاستعلامات الطويلة، والاتصالات بخدمات خارجية، والمعالجة المطوّلة داخل معاملة.

قدّم Napparnik أيضاً تهيئة وذكر WaitConnections، لكنه ركّز على جمع المواد للتحقيق دون تحليل الجانب المُعطِّل.

2. ربط دليل مرجعي غير نموذجي بنظام BSP للتحكم بالإصدارات.

الوكيل: إضافة النوع إلى الأنواع القابلة للتعريف ВерсионируемыеДанные وВерсионируемыеДанныеОбъект، وتنفيذ معالج ПриОпределенииНастроекВерсионированияОбъектов في مدير الدليل المرجعي، واستدعاء التهيئة في النموذج من حدث ПриСозданииНаСервере. الاشتراك ЗаписатьВерсиюОбъекта يستمع فعلاً إلى الحدث المطلوب. قدّم الوكيل الكود وأوضح أن هذا الاشتراك بعينه هو المستخدم للدلائل المرجعية، لا ЗаписатьВерсиюДокумента.

اقترح Napparnik آلية أخرى: خاصية سجل بيانات الدليل المرجعي ومهمة مجدولة تستدعي ИсторияДанных.ОбновитьИсторию(). وهذا حل صحيح، لكنه بديل، لا ربط فعلي بنظام BSP النموذجي.

3. منع إلغاء التثبيت عند وجود دفعات مُصرَّف عنها.

قدّم الوكيل معالج ОбработкаУдаленияПроведения مع استعلام على سجل ТоварыПоПартиям، ومرشّح على حركات الصرف، وتحقّق عبر РезультатЗапроса.Пустой(). وتحذير مهم: للحماية من الصرف المتزامن، يلزم قفل مُدار (وهو غير موجود في المثال).

قدّم Napparnik مخططاً دون التوسع في الخيارات الممكنة.

الاستنتاج

نموذج مفتوح مع فهرسة عالية الجودة — RAG هجين، وتحليل البيانات الوصفية، واختيار مصادر صحيح — يقدّم في كثير من الأحيان نتيجة لا تقل عن نموذج متخصص ضيق. ومن الأجدى اقتصادياً استثمار المال في بنية البحث التحتية بدلاً من إعادة التدريب. يتعامل 1C Napparnik بكفاءة مع الأسئلة النموذجية، لكن إجاباته على الأسئلة المعقدة تبقى أكثر سطحية.