Most RAG tutorials end exactly where production begins. You split your documents into 512-token chunks, push them through a single embedding model, and call a vector database with simple top-k retrieval. In a demo, this looks convincing. Ask the bot about your company leave policy and it returns a coherent paragraph. Everyone nods. Unfortunately, demos lie.

Production exposes every shortcut. Fixed chunks slice through legal contracts in the middle of indemnification clauses. API documentation turns into overlapping noise that drowns the signal you actually need. Latency creeps up until users abandon the query before the answer arrives. We hit this wall and had to rebuild. Our retrieval layer evolved from “semantic search and hope” into a measured, instrumented pipeline. The result was 95% recall and a 40% cut in latency. Here is what actually worked.

Match the Chunking Strategy to the Document

The 512-token default persists because it is easy, not because it is correct. Different documents carry meaning differently, and your chunking strategy should reflect that.

For legal contracts, use recursive chunking that respects structural boundaries. Legal language is nested. A clause depends on the section above it, and a fixed cut mid-sentence destroys the logic of an obligation. Recursive chunking attempts splits on natural separators first—paragraphs, then sentences—before imposing a token limit. This keeps indemnification or liability clauses intact.

For API documentation, use function-aware chunking. Developers do not search for random paragraphs; they search for endpoints, parameters, and error signatures. A chunk should contain the full function signature, its description, and the return schema as one logical unit. If you split that block in half, the retrieval system returns half the context and the generation model hallucinates the rest.

For support tickets, rely on semantic chunking that follows conversation turns. Support threads are linear and repetitive. A customer repeats the problem, an agent asks for logs, the customer attaches them. Each turn is its own semantic unit. Chunking by turns preserves who said what and when, which matters when the user asks, “What did the agent suggest on Tuesday?”

For internal wikis, try agentic chunking. Hand an LLM a section and ask it to decide where one topic ends and another begins. This costs more at ingest time, but wikis are messy. Pages contain unrelated updates from different teams, and a human-defined boundary rarely helps. Letting a model draw boundaries based on topic shifts cuts noise dramatically.

Running multiple strategies in one pipeline requires tagging documents by type at ingest. That small bit of schema discipline pays off immediately.

Combine Search Methods, Don’t Choose One

Vector search understands intent, but it routinely fails on exact matches. Ask for error code ERR_CONNECTION_REFUSED or a specific SKU, and dense embeddings often return conceptually similar but factually wrong results. BM25, the classic keyword sparse retrieval method, handles exact strings beautifully but misses semantic nuance. You need both.

Use hybrid retrieval. Run vector search and BM25 in parallel. Then combine them with Reciprocal Rank Fusion (RRF). RRF rewards documents that both methods agree are relevant, while still surfacing strong candidates from either approach. The math is simple and the result is stable: no single retrieval method dominates the final ranking.

After fusion, add a cross-encoder reranker. The first stage — vector plus sparse retrieval — is fast and broad. The cross-encoder then scores each query-document pair with full attention, meaning it actually reads the candidate against the original question. Yes, this adds latency. In our case, roughly fifty to one hundred milliseconds. But the gain in precision is sharp enough that the trade is obvious. You cannot afford to skip this if you care about recall.

Fix the Query Before You Fix the Index

Users do not write queries for your search engine. They write them for humans. “It doesn’t work” is a common support query. A vague feature description is a common internal wiki search. If you search the index with that raw input, you get garbage back.

Transform the query before it hits the retriever.

Використовуйте розширення запитів (query expansion), щоб генерувати кілька варіантів запитання користувача. Якщо хтось вводить «server down», ваша система також має шукати «service unavailable», «502 error» та «connection timeout». Охоплення цих варіантів намірів дозволило підвищити наш показник повноти (recall) з 78% до 96%. Це лише один крок, який майже нічого не коштує порівняно з отриманим результатом.

Використовуйте декомпозицію запитів (query decomposition) для складних питань. Коли користувач запитує щось на кшталт «Як мені перейти з legacy billing API на нове та які критичні зміни (breaking changes) стосуються корпоративних акаунтів?», розбийте це запитання на підпитання. Одне підпитання стосується кроків міграції. Інше — критичних змін, специфічних для корпоративного сегмента. Кожне з них звертається до різних частин індексу. Подальша мовна модель синтезує фінальну відповідь із якісно знайдених фрагментів (chunks), а не намагається вгадати її в умовах зашумленого контекстного вікна.

Припиніть вгадувати гіперпараметри

Коли у вас з'являється кілька стратегій чанкування (chunking), гібридний пошук (hybrid retrieval) та трансформація запитів, ви стикаєтеся з комбінаторною проблемою. Розмір чанка, перекриття (overlap), ваги злиття (fusion weights), глибина реранкера (reranker depth) та кількість розширень — усе це взаємодіє. Зміна одного параметра ізольовано порушує роботу іншого. Пошук по сітці (grid search) у такому просторі є марним і повільним.

Замість цього використовуйте байєсівську оптимізацію. Ставтеся до цього як до завдання з налаштування машинного навчання. Чітко визначте свою мету: максимізувати recall, тримаючи затримку (latency) нижче певного порогу. Створіть «золотий набір даних» (golden dataset) — кілька сотень репрезентативних запитань, для яких ви точно знаєте, які чанки мають бути знайденими. Потім дозвольте байєсівському пошуку ефективно дослідити простір конфігурацій. Він будує ймовірнісну модель того, що працює, і далі тестує найбільш перспективні області.

Кожна потенційна конфігурація повинна пройти перевірку на «золотому наборі даних», перш ніж потрапити на стейджинг. Якщо новий розмір чанка знижує recall або важчий реранкер виводить вас за межі бюджету затримки, оптимізація автоматично це виявить. Це усуває суб'єктивність. Ви перестаєте сперечатися, чи «краще» 256 чи 512 токенів, і починаєте аналізувати результати.

Результат

Зміни в пайплайні дали кумулятивний ефект саме такий, як ми сподівалися.

  • Recall@10 зріс із 78% до 95%.
  • P95 latency знизилася з 850 мс до 320 мс.
  • Рівень галюцинацій впав із 12% до 3%.
  • Вартість одного запиту знизилася на 38%, переважно тому, що кращий пошук дозволив нам використовувати меншу модель генерації та менше токенів у промпті.

Зменшення затримки здивувало деяких членів команди. Здається, що додавання реранкерів та розширення запитів має сповільнити систему. Але оскільки якість пошуку покращилася, моделі генерації знадобилося менше промптів, менше припущень і менше повторних спроб. Якісний пошук робить усі наступні етапи дешевшими.

Ставтеся до пошуку як до інфраструктури

Пошук (retrieval) — це не блокнот, який ви запускаєте один раз і забуваєте. Це інфраструктура, і керувати нею слід як кодом. Версіонуйте свої стратегії чанкування. Коли юридичний відділ випускає новий шаблон контракту, протестуйте свій рекурсивний спліттер (recursive splitter) перед тим, як він потрапить у продакшн. Підтримуйте свій «золотий набір даних» як живий документ, а не як статичний CSV-файл з минулого кварталу. Автоматизуйте оцінювання в CI, щоб будь-який pull request, який змінює модель ембедінгів (embedding model) або вагу злиття, отримував коментар із показниками recall та затримки ще до того, як його перегляне людина.

Ваші користувачі ніколи не запитають, яку модель ембедінгів ви використовуєте. Їх не хвилюватиме ваша евристика чанкування чи архітектура реранкера. Їм важливо, чи правильна відповідь, чи швидко вона приходить і чи можна їй довіряти. Побудуйте пайплайн, який заслуговує на цю довіру, чесно вимірюйте її та припиніть ставитися до пошуку як до другорядного завдання.

Джерело: Optimizing RAG At Scale
Приєднуйтесь до обговорення: GyaanSetu AI Community