Most teams build their first retrieval system the same way: slice every document into fixed 512-token chunks, push them into a vector database, and hope the embedding model does the hard work. That hope gets you through a demo. It does not survive contact with real users.

In production, a legal contract falls apart when you sever a liability clause from its exceptions. API documentation turns useless when a code sample gets detached from its function signature. A customer support thread becomes noise when you rip a single complaint out of its conversational history. The problem is rarely the language model sitting at the end of the pipeline. The problem is what you feed it.

We learned this the hard way. Our initial retrieval layer looked standard but behaved inconsistently. So we rebuilt it around a simple idea: treat retrieval as measured infrastructure, not magic. Here is exactly what changed, and how we pushed recall to 95 percent while cutting the 95th-percentile latency from 850 ms to 320 ms.

The Fixed-Chunk Trap

Uniform token counts are easy to code and easy to explain. That convenience masks a basic truth: documents have structure. When you ignore that structure, you destroy signal.

Consider a ten-page master service agreement. A fixed 512-token slice will land mid-obligation, splitting a clause from the very cap table that limits it. The retrieval step then returns half a thought. The generator hallucinates the rest. In API documentation, a chunk that is too large dilutes the embedding with boilerplate headers, burying the specific method a developer needs. In support tickets, a fixed window treats a conversation as a bag of sentences, stripping away the back-and-forth that reveals what actually failed.

We stopped treating chunk size as a hyperparameter we guessed. We started treating it as a mapping exercise between the document type and the information architecture inside it.

Match Your Chunking to the Data

The fix is not one perfect chunk size. The fix is three distinct strategies tuned to three distinct data shapes.

Legal documents now go through recursive splitting. The algorithm first looks for the largest natural boundaries—sections, then subsections, then numbered clauses—and only falls back to smaller splits when necessary. This keeps a termination clause attached to its survival conditions. The retrieval step sees complete logical units, which sharply reduces the model’s temptation to invent missing exceptions.

API and code documentation get structure-aware chunking. Markdown headers, code fences, and parameter tables are parsed as atomic units. We do not split inside a code block. We keep docstrings adjacent to their signatures. The result is that a query for a specific class method retrieves the full context a developer needs: the description, the typed parameters, and the working example.

Support and conversational data use semantic chunking. Instead of counting tokens, we look for shifts in topic or intent. If a customer describes a bug in message three and pastes a stack trace in message seven, we chunk by meaning, not by message index. The retrieval layer then returns the full arc of the problem rather than a orphaned sentence.

Why Vector Search Alone Fails

Even perfect chunks die in a pure vector search. Dense embeddings excel at capturing meaning and synonymy, but they are notoriously fuzzy on exact strings. If an engineer searches for the precise error code ERR_CONNECTION_REFUSED, vector similarity might return a dozen conceptual neighbors and miss the exact match buried at rank fourteen.

Keyword search with BM25 has the opposite problem. It finds exact tokens but misses semantic intent. A user asking “why is my database down” will never match a document that says “troubleshooting connection timeouts.”

We now run both. Vector and keyword results are fed into Reciprocal Rank Fusion, which blends the two ranked lists without requiring calibrated scores. The fused list is then passed through a cross-encoder reranker. The reranker is slower than the initial retrieval, but it is far more precise because it judges query-document relevance directly rather than through compressed embeddings. That hybrid pipeline alone lifted our recall by 15 percent.

Fixing Bad Queries Before They Hit the Index

لا يكتب المستخدمون استعلامات بحث مثالية؛ بل يلصقون أسطر سجلات (logs) مبتورة، أو يكتبون "إنه معطل"، أو يستخدمون مصطلحات تقنية لم تتبناها وثائقك أبداً. إذا كنت تثق في الاستعلام الخام، فأنت تثق في الضجيج.

نحن نقوم الآن بتوسيع كل استعلام وارد إلى ثلاث إلى خمس متغيرات قبل إرسالها إلى طبقة الاسترجاع (retrieval layer). قد يكون أحد المتغيرات إعادة صياغة مباشرة، والآخر قد يكون عنوان مستند مثالي افتراضي، أما الثالث فيقوم بإزالة الحشو الكلامي ويعزل الكلمات المفتاحية التقنية. يتم تحويل كل متغير إلى تمثيل رقمي (embedding) والبحث عنه، ثم نقوم بإزالة التكرار ودمج مجموعات المرشحين.

هذا الأمر ليس مجانياً؛ فعمليات الـ embedding الإضافية تلك تكلف مالاً وتضيف بضعة أجزاء من الثانية. لكن التأثير على الاستدعاء (recall) كان هائلاً: انتقلنا من 78% إلى 96% من خلال توسيع الاستعلامات قبل الاسترجاع. ولأن الاسترجاع الأفضل يقلص نافذة التوليد (generation window) ويثبت النموذج في سياق صحيح، انتهى بنا الأمر إلى توفير المال في المراحل اللاحقة. فخطوة الاسترجاع الأكثر تكلفة قليلاً هي أرخص من خطوة توليد طويلة مليئة بالهلوسة (hallucination).

توقف عن التخمين. ابدأ بالبحث.

بمجرد وضع التقسيم (chunking) الصحيح، والاسترجاع الهجين (hybrid retrieval)، وتوسيع الاستعلام في مكانهما، واجهنا فوضى من الاحتمالات المتداخلة. فحجم الجزء (chunk size)، وتداخل الأجزاء (chunk overlap)، وعمق استرجاع top-k، وحدود إعادة الترتيب (reranker cutoffs)، وأوزان الدمج، كلها تتفاعل مع بعضها البعض. كان البحث الشبكي اليدوي (manual grid search) سيستغرق أسابيع ولن يوصلنا إلا إلى حلول محلية قصوى (local maximum).

انتقلنا إلى التحسين البايزي (Bayesian optimization) لاستكشاف هذه المساحة. فبدلاً من اختبار كل تركيبة بشكل شامل، تحافظ خوارزمية البحث على اعتقاد بشأن التكوينات التي من المرجح أن تؤدي بشكل جيد، وتضيق النطاق تدريجياً نحو المناطق الواعدة.

المخرج ليس إعداداً واحداً مثالياً، بل هو "جبهة باريتو" (Pareto frontier) من الخيارات. فمن ناحية، لدينا تكوين رشيق مُحسَّن لنقطة نهاية واجهة برمجة التطبيقات (API) الخاصة بنا ذات الإنتاجية العالية: استدلال سريع، استدعاء متوسط، وأقل زمن انتقال (latency) ممكن. ومن الناحية الأخرى، لدينا تكوين هجومي للمراجعة القانونية: استرجاع أعمق، إعادة ترتيب (reranking) أكثر كثافة، وتداخل أضيق، حيث نضحي بالأجزاء من الثانية في سبيل الدقة والشمولية. ولأن هذه الجبهة واضحة، يمكننا اختيار النقطة المناسبة للمنتج بدلاً من التظاهر بأن حلاً واحداً يناسب الجميع.

كيف تبدو الأرقام في الواقع

نقلت هذه التغييرات النظام من نموذج أولي هش إلى خط إنتاج مدروس.

  • تحسن الاستدعاء عند عشرة (Recall at ten) من 78% إلى 95%. وهذا يعني أنه عندما تكون الإجابة الصحيحة موجودة في مجموعة بياناتنا (corpus)، فإننا نجدها تسع عشرة مرة من أصل عشرين.
  • انخفض زمن الانتقال (Latency) عند المئين الخامس والتسعين من 850 مللي ثانية إلى 320 مللي ثانية. قد تبدو المجموعة الهجينة (hybrid stack) أثقل على الورق، ولكن الفهرسة الأذكى، وأدوات إعادة الترتيب الأصغر، والقدرة على تقديم الأجزاء المكثفة فقط عند الحاجة، جعلت النظام بأكمله أسرع.
  • انخفض معدل الهلوسة (Hallucination rate) —الذي تتبعه فرق التقييم البشري على مجموعة بيانات ذهبية (golden dataset) معزولة— من 12% إلى 3%. فعندما يتلقى النموذج سياقاً كاملاً وذا صلة، يتوقف عن اختراع الحقائق.
  • انخفضت التكلفة لكل استعلام من $0.008 إلى $0.005. فمن أجل الاسترجاع الأفضل يعني مطالبات (prompts) أقصر وأكثر تركيزاً لنماذج اللغة الكبيرة (LLM) ومحاولات استرداد أقل. إن الإنفاق الإضافي على الـ embedding لتوسيع الاستعلام يتضاءل أمام التوفير في عملية التوليد.

ابنِ مجموعة بيانات ذهبية وعامل الاسترجاع كأنه كود برمجي

إذا كنت ستخرج بشيء واحد من هذا، فليكن الانضباط في القياس. لقد بنينا مجموعة بيانات ذهبية صغيرة من الأسئلة الحقيقية ومواقع الإجابات التي تم التحقق منها. وقبل أن يطبق أي تغيير في بيئة الإنتاج، يتم اختباره مقابل تلك المجموعة. ويتم مراقبة الاستدعاء وزمن الانتقال في الوقت الفعلي، وليس بمجرد النظر إليها في دفتر ملاحظات (notebook).

الاسترجاع ليس مجرد عرض تجريبي للأبحاث، بل هو بنية تحتية. إنه يستحق اختبارات الوحدة (unit tests)، ومعايير قياس التراجع (regression benchmarks)، والتحسين الآلي تماماً مثل بقية مكونات نظامك. قم بالتقسيم بناءً على بنية المستند، وليس بناءً على خرافات عدد الرموز (tokens). ادمج البحث المتجهي (vector search) والبحث بالكلمات المفتاحية مع أداة إعادة ترتيب (reranker). قم بتوسيع الاستعلامات التي يكتبها مستخدموك بالفعل. ثم اترك خوارزمية البحث تضبط الإعدادات بدلاً من الاعتماد على حدسك.

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