لا تزال معظم الفرق تبني أول خط أنابيب استرجاع (retrieval pipeline) لها بنفس الطريقة؛ حيث يختارون حداً ثابتاً للرموز (tokens)، ربما 512، ويقسمون المستندات إلى كتل موحدة، ثم يغذون تلك الكتل في قاعدة بيانات متجهية (vector database). في مجموعات البيانات الصغيرة ذات الأسئلة البسيطة، يبدو هذا الأمر سحرياً، ولكن في بيئة الإنتاج، ينهار كل شيء.
تتمزق العقود القانونية إلى شظايا غير ذات معنى عندما يتم تقسيم بند في منتصف الجملة. وتتحول وثائق واجهة برمجة التطبيقات (API documentation) إلى خليط مشوش إذا ابتلعت كتلة واحدة ثلاث وظائف غير مرتبطة ببعضها. وتفقد تذاكر دعم العملاء تسلسلها السردي بالكامل في غياب التداخل (overlap) بين الأجزاء. والنتيجة متوقعة: زمن استجابة (latency) مفرط، ومعدل استدعاء (recall) ضعيف، وإجابات تجبر النموذج المولد على الهلوسة.
لقد قمنا بهدم طبقة الاسترجاع لدينا وأعدنا بناءها من الصفر. وكانت النتيجة قفزة في معدل الاستدعاء من 78% إلى 95%، وخفضاً في زمن الاستجابة بنسبة 62%، وخط أنابيب يعمل أخيراً كبنية تحتية حقيقية بدلاً من كونه مجرد حل سريع وغير مدروس. إليكم ما نجح بالفعل.
التقسيم الذكي (Smart Chunking): الهيكلية أهم من عدد الرموز
الخطأ الأول هو افتراض أن كل مستند يتحدث اللغة نفسها. فالتقسيم إلى كتلة من 512 رمزاً قد يكون منطقياً للنثر السردي، لكنه لا يصلح لأي شيء آخر تقريباً. لقد انتقلنا إلى استراتيجية تحترم تشريح المصدر.
بالنسبة للمستندات القانونية، نستخدم التقسيم المتكرر (recursive chunking). تحاول الخوارزمية أولاً التقسيم بناءً على حدود عالية المستوى مثل الأقسام والمواد. وإذا كان القسم لا يزال طويلاً جداً، فإنها تبحث عن الأقسام الفرعية، ثم الفقرات، ثم الجمل. هذا يحافظ على التسلسل المنطقي للبنود؛ حيث تظل اتفاقية عدم المنافسة سليمة، ولا تختلط التعريفات مع شروط التعويض.
تتطلب وثائق API تقسيماً يراعي الهيكلية. فتوقيع الدالة (function signature)، وجدول المعلمات (parameter table)، وطلب المثال الخاص بها، كلها تنتمي إلى بعضها البعض. غالباً ما يؤدي التقسيم بعد عدد ثابت من الرموز إلى ترك المعلمات في كتلة والأمثلة في كتلة أخرى. بدلاً من ذلك، نقوم بالتقسيم حسب كائن المستند (document object)؛ حيث تحتوي كل كتلة على نقطة نهاية (endpoint) كاملة أو دالة واحدة. وبذلك يمكن للمسترجع تقديم مرجع مكتفٍ ذاتياً يجيب على السؤال بالفعل.
وتناسب تذاكر الدعم بطبيعتها التقسيم الدلالي (semantic chunking). فبدلاً من القطع عند حدود الرموز، نكتشف المكان الذي يتغير فيه الموضوع. فالتذكرة التي تبدأ بشكوى تتعلق بتسجيل الدخول ثم تنتقل إلى سؤال حول الفواتير، تُقسم إلى قطعتين متماسكتين. تحمل كل قطعة البيانات الوصفية (metadata) التي تحتاجها، ولم يعد على النموذج التخمين بشأن المشكلة التي تهم المستخدم حقاً.
أما الويكي (wikis) الداخلية فهي أكثر فوضوية، حيث تمزج بين النثر والجداول والرسوم التوضيحية والمواضيع المضمنة. بالنسبة لهذه الحالات، نستخدم التقسيم القائم على الوكلاء (agentic chunking). حيث يقوم نموذج لغوي صغير بالقراءة مسبقاً ويقرر أين تنتهي الوحدة المكتملة موضوعياً. يتطلب هذا تكلفة أعلى قليلاً عند وقت الإدخال (ingestion time)، ولكنه يلغي العمل اليدوي الشاق المتمثل في ضبط القواعد يدوياً لكل تنسيق صفحة جديد.
الاسترجاع الهجين (Hybrid Retrieval): غطِّ كافة الجوانب
البحث المتجهي (Vector search) ممتاز في التقاط المعاني الغامضة؛ فإذا سألت عن بطء الرفع، سيعيد لك بكل سرور فقرات حول زمن الاستجابة وعرض النطاق الترددي (bandwidth). لكنه سيئ السمعة في تشويه المطابقات الدقيقة. فإذا بحث مطور عن رمز الخطأ ERR_CONNECTION_REFUSED ، فإن التضمينات الكثيفة (dense embeddings) غالباً ما تعامله كضجيج عام.
أما خوارزمية BM25، وهي خوارزمية الكلمات المفتاحية الكلاسيكية، فتقوم بالعكس تماماً. فهي تتقن تحديد السلاسل النصية الدقيقة والمصطلحات النادرة، ومع ذلك فإنها تفتقر إلى الفروق الدلالية الدقيقة. فاستعلام حول "توقيع الاتفاقية" قد لا يظهر أبداً المحتوى المصنف تحت "تنفيذ العقد".