بعد أربعة أشهر من نقل خط معالجة التوليد المعزز بالاسترجاع (RAG) من دفتر Jupyter notebook إلى خدمة حية، حدد المؤلف خمسة خيارات ملموسة حولت العرض التجريبي المبهر إلى نظام يمكن للمستخدمين الاعتماد عليه فعلياً. يظهر الفرق في الأرقام: تغيير بسيط في طريقة تقسيم النصوص رفع معدل نجاح الاسترجاع من 61% إلى 83%، كما أن مجموعة تقييم متواضعة مكونة من 200 استعلام حقيقي تكتشف الآن معظم التراجعات في الأداء قبل وصولها إلى العملاء.
لماذا يهم هذا الأمر
تبدو عروض RAG التوضيحية مثيرة للإعجاب - فهي تجلب فقرة وتنتج إجابة منطقية في ثوانٍ. أما في بيئة الإنتاج، فغالباً ما تعيد نفس الطريقة حقائق قديمة، أو رموز خطأ مفقودة، أو جملًا غير مترابطة، مما يؤدي إلى تآكل ثقة المستخدم. نادراً ما يكون عنق الزجاجة هو النموذج اللغوي؛ بل هي الطريقة التي يتم بها استيعاب المحتوى وفهرسته وتقديمه. إن ضبط خط المعالجة بشكل صحيح قد يعني الفرق بين منتج يضيف قيمة ومنتج يصبح عبئاً.
1. توقف عن استخدام كتل ثابتة الحجم
تقوم العديد من النماذج الأولية بتقطيع كل مستند إلى كتل مكونة من 512 رمزاً (tokens). هذا يعمل مع النصوص القصيرة ولكنه يمزق الأدلة التقنية، وسلاسل الدعم، ومقتطفات الكود. يتم تقسيم الجمل، وتختفي العناوين، ولا يستطيع محرك الاسترجاع مطابقة السياق الذي يتوقعه المستخدم.
انتقل إلى التجزئة المدركة للبنية (structure-aware chunking) — مثل التقسيم عند العناوين، أو حدود المحادثة، أو حدود الكود (code fences) — للحفاظ على الوحدات الدلالية. في نظام المؤلف، أدى هذا وحده إلى رفع نسبة الاستعلامات التي وجدت فقرة ذات صلة من 61% إلى 83%. يأتي التحسن من تغيير تنسيق البيانات؛ بينما يظل النموذج الأساسي كما هو.
2. استخدم البحث الهجين
يتفوق البحث الشعاعي الصرف (المعتمد على تشابه التضمين/embedding) في العثور على الفقرات ذات المعنى نفسه، لكنه يتعثر في المعرفات الدقيقة مثل رموز الخطأ، أو أرقام الإصدارات، أو المصطلحات الخاصة. قد يحصل المستخدم الذي يبحث عن رمز خطأ مثل "ERR-XXXX" على فقرة مشابهة دلالياً ولكنها لا تحتوي على الرمز على الإطلاق.
يجمع البحث الهجين بين فهرس شعاعي كثيف وفهرس BM25 تقليدي (المعتمد على تكرار المصطلح). ومن خلال ترجيح الدرجتين، يسترجع النظام العناصر التي تكون قريبة دلالياً وتحتوي أيضاً على المصطلحات الدقيقة التي كتبها المستخدم. بالنسبة للإنتاج، يعد البحث الهجين متطلباً أساسياً وليس مجرد ميزة إضافية.
3. تعامل مع البيانات القديمة
إن جداول الأسعار، أو وثائق السياسات، أو ملاحظات إصدار البرامج الثابتة (firmware) غير المحدثة تدمر المصداقية بسرعة. هناك ثلاث خطوات عملية للحفاظ على حداثة الفهرس:
- وسم كل مستند بطابع إصدار أو طابع زمني.
- تطبيق "تعزيز الحداثة" (recency boost) أثناء تسجيل النقاط بحيث تتفوق العناصر الأحدث على النسخ الأقدم.
- تشغيل عملية إعادة فهرسة تراكمية (incremental re-indexing) ليلية لجلب التغييرات من الأنظمة المصدر.
تمنع هذه الضمانات النظام من تقديم سعر كان صالحاً في الربع الأخير أو سياسة تم استبدالها بالفعل.
4. أعد الترتيب بدلاً من ترقية النماذج
توفر ترقية نموذج التضمين (embedding model) دفعة بسيطة في الجودة فقط، بينما يوفر إضافة مُعيد ترتيب من نوع cross-encoder قفزة أكبر بكثير بتكلفة أقل.
يقوم تدفق الإنتاج بجلب 20 مرشحاً رخيصاً باستخدام البحث الهجين، ثم يمررهم عبر مُعيد الترتيب (reranker) لاختيار أفضل خمسة. يحقق هذا النهج ثنائي المراحل قفزة نوعية أكبر في الجودة بجزء بسيط من تكلفة ترقية النموذج بالكامل.
5. ابنِ مجموعة تقييم حقيقية
لا يمكنك تحسين ما لا يمكنك قياسه. جمع المؤلف مجموعة اختبار مكونة من 200 استعلام حقيقي للمستخدمين، كل منها مقترن بإجابة صاغها خبير. يتم تشغيل كل تغيير في الكود مقابل هذه المجموعة؛ ويتم اكتشاف أي تراجع في الأداء قبل النشر.
عندما يبلغ مستخدم عن إجابة سيئة، أضف الاستعلام إلى مجموعة التقييم فوراً، مما يحول الإخفاقات في العالم الحقيقي إلى ضمانات مستقبلية. إن التسجيل المستمر لكل إجابة يتم إنشاؤها يغذي حلقة التقييم، مما يحافظ على توافق النظام مع الاستخدام الفعلي.
خط المعالجة في الإنتاج من الناحية العملية
- الاستيعاب (Ingest): التجزئة المدركة للبنية تحافظ على العناوين، وكتل الكود، وتحولات المحادثة.
- الفهرسة (Index): تخزين كل من التضمينات الكثيفة (dense embeddings) وإحصائيات مصطلحات BM25.
- الاسترجاع (Retrieve): يعيد البحث الهجين 20 مرشحاً، موازناً بين التشابه الدلالي والمطابقة الدقيقة للمصطلحات.
- إعادة الترتيب (Rerank): يقوم cross-encoder بتضييق القائمة إلى أكثر خمس فقرات واعدة.
- التوليد (Generate): يتلقى نموذج LLM هذه الكتل العليا بالإضافة إلى البيانات الوصفية الخاصة بها لصياغة الإجابة النهائية.
- التقييم (Evaluate): يتم تسجيل كل استجابة؛ ويتم تغذية الإخفاقات مرة أخرى في مجموعة اختبار الـ 200 استعلام.
المخاطر والمقايضات
يقلل مسار العمل (pipeline) المضبوط بدقة من الهلوسة، ويحسن صلة الإجابة، ويخفض تكلفة النماذج ذات الموارد المفرطة. وتتمثل الميزة في زيادة رضا المستخدمين وتقليل أعباء الدعم الإضافية. أما تجاهل هذه الخطوات فيؤدي إلى خدمة هشة تقوض الثقة في العلامة التجارية وتفرض عمليات "إطفاء حرائق" مكلفة.
ما يجب مراقبته لاحقاً
مع نضوج التضمينات (embeddings) مفتوحة المصدر وقواعد البيانات المتجهة (vector databases)، سيتلاشى الخط الفاصل بين الاسترجاع "الكثيف" (dense) و"المتفرق" (sparse)، لكن مبدأ الجمع بين المطابقة الدلالية والمطابقة الدقيقة سيظل قائماً.
الخلاصة: في نظام RAG، نادراً ما يكون النموذج اللغوي هو نقطة الاختناق. يكمن العمل الحقيقي في كيفية تقسيم وفهرسة وإظهار المحتوى الأساسي. إن اتخاذ هذه القرارات بشكل صحيح يحول العرض التوضيحي المبهر إلى منتج موثوق.