Большинство туториалов по RAG заканчиваются именно там, где начинается продакшн. Вы разбиваете документы на чанки по 512 токенов, прогоняете их через одну модель эмбеддингов и вызываете векторную базу данных с простым top-k поиском. В демо-версии это выглядит убедительно. Спросите бота о политике отпусков в вашей компании, и он выдаст связный абзац. Все кивают. К сожалению, демо лгут.

Продакшн обнажает все недоработки. Фиксированные чанки разрезают юридические контракты прямо посреди пунктов о возмещении ущерба. Документация API превращается в наслоение шума, который заглушает нужный вам сигнал. Задержка (latency) растет до тех пор, пока пользователи не бросают запрос, не дождавшись ответа. Мы столкнулись с этой проблемой и были вынуждены все перестроить. Наш уровень извлечения эволюционировал от «семантического поиска и надежды на удачу» до выверенного, инструментированного конвейера. Результатом стали 95% полноты (recall) и сокращение задержки на 40%. Вот что действительно сработало.

Подбирайте стратегию чанкирования под тип документа

Стандарт в 512 токенов сохраняется потому, что это просто, а не потому, что это правильно. Разные документы несут смысл по-разному, и ваша стратегия чанкирования должна это отражать.

Для юридических контрактов используйте рекурсивное чанкирование, которое соблюдает структурные границы. Юридический язык имеет иерархическую структуру. Пункт зависит от раздела выше, и фиксированный разрез посреди предложения разрушает логику обязательства. Рекурсивное чанкирование сначала пытается сделать разрез по естественным разделителям — абзацам, затем предложениям — и только потом применяет лимит токенов. Это позволяет сохранять пункты о возмещении ущерба или ответственности целиком.

Для документации API используйте чанкирование с учетом функций (function-aware chunking). Разработчики не ищут случайные абзацы; они ищут эндпоинты, параметры и сигнатуры ошибок. Чанк должен содержать полную сигнатуру функции, ее описание и схему возвращаемого значения как единую логическую единицу. Если вы разделите этот блок пополам, система извлечения вернет лишь половину контекста, а модель генерации галлюцинирует остальное.

Для тикетов службы поддержки полагайтесь на семантическое чанкирование, следующее за ходами диалога. Темы поддержки линейны и повторяемы. Клиент описывает проблему, агент запрашивает логи, клиент их прикрепляет. Каждый ход — это отдельная семантическая единица. Чанкирование по ходам диалога сохраняет информацию о том, кто, что и когда сказал, что критически важно, когда пользователь спрашивает: «Что агент предложил во вторник?»

Для внутренних вики-систем попробуйте агентское чанкирование (agentic chunking). Передайте LLM раздел и попросите ее решить, где заканчивается одна тема и начинается другая. Это стоит дороже на этапе индексации, но вики-системы обычно хаотичны. Страницы содержат несвязанные обновления от разных команд, и границы, определенные человеком, редко помогают. Позволяя модели проводить границы на основе смены тем, можно радикально снизить уровень шума.

Запуск нескольких стратегий в одном конвейере требует тегирования документов по типу при их загрузке. Эта небольшая дисциплина в структуре данных окупается мгновенно.

Комбинируйте методы поиска, а не выбирайте один

Векторный поиск понимает намерение, но регулярно пасует перед точными совпадениями. Если запросить код ошибки ERR_CONNECTION_REFUSED или конкретный SKU, плотные эмбеддинги часто возвращают концептуально похожие, но фактически неверные результаты. BM25, классический метод разреженного поиска по ключевым словам, отлично справляется с точными строками, но упускает семантические нюансы. Вам нужны оба метода.

Используйте гибридный поиск. Запускайте векторный поиск и BM25 параллельно. Затем объедините их с помощью Reciprocal Rank Fusion (RRF). RRF отдает приоритет документам, которые оба метода признали релевантными, при этом выявляя сильных кандидатов из каждого подхода. Математика проста, а результат стабилен: ни один метод поиска не доминирует в итоговом ранжировании.

После объединения добавьте реранкер на базе cross-encoder. Первый этап — векторный плюс разреженный поиск — работает быстро и охватывает широкий круг документов. Затем cross-encoder оценивает каждую пару «запрос-документ» с полным вниманием (full attention), что означает, что он фактически сопоставляет кандидата с исходным вопросом. Да, это добавляет задержку. В нашем случае — примерно от пятидесяти до ста миллисекунд. Но прирост точности настолько значителен, что этот компромисс очевиден. Вы не можете позволить себе пропустить этот шаг, если вам важна полнота (recall).

Исправьте запрос, прежде чем исправлять индекс

Пользователи не пишут запросы для вашего поискового движка. Они пишут их для людей. «Это не работает» — типичный запрос в поддержку. Расплывчатое описание функции — типичный поиск по внутренней вики. Если вы будете искать в индексе по таким сырым входным данным, вы получите мусор на выходе.

Трансформируйте запрос до того, как он попадет в систему извлечения.

Use query expansion to generate multiple versions of the user’s question. If someone types “server down,” your system should also search for “service unavailable,” “502 error,” and “connection timeout.” Covering these intent variants moved our recall from 78% to 96%. It is a single step, and it costs almost nothing compared to the gain.

Use query decomposition for complex questions. When a user asks something like “How do I migrate from the legacy billing API to the new one and what breaking changes affect enterprise accounts?,” break it into sub-questions. One sub-question targets migration steps. Another targets enterprise-specific breaking changes. Each hits a different part of the index. The downstream language model synthesizes the final answer from well-retrieved chunks rather than guessing across a noisy context window.

Stop Guessing Hyperparameters

Once you have multiple chunking strategies, hybrid retrieval, and query transformation, you face a combinatorial problem. Chunk size, overlap, fusion weights, reranker depth, and expansion count all interact. Tweaking one in isolation breaks another. Grid search across this space is wasteful and slow.

Use Bayesian optimization instead. Treat this like a machine learning tuning job. Define your objective clearly: maximize recall while keeping latency under a ceiling. Build a golden dataset — a few hundred representative questions where you know precisely which chunks should be retrieved. Then let the Bayesian search explore the configuration space efficiently. It builds a probabilistic model of what works and tests the most promising regions next.

Every candidate configuration must pass the golden dataset before it reaches staging. If a new chunk size drops recall or a heavier reranker pushes you past the latency budget, the optimization catches it automatically. This removes opinion from the room. You stop debating whether 256 or 512 tokens is “better” and start reading the results.

The Outcome

The pipeline changes compounded exactly as we hoped.

  • Recall@10 climbed from 78% to 95%.
  • P95 latency dropped from 850 ms to 320 ms.
  • Hallucination rate fell from 12% to 3%.
  • Cost per query dropped by 38%, largely because better retrieval let us use a smaller generation model and fewer prompt tokens.

The latency reduction surprised some people on the team. Adding rerankers and query expansion sounds like it should slow things down. But because retrieval quality improved, the generation model needed less prompting, less speculation, and fewer retries. Good retrieval makes everything downstream cheaper.

Treat Retrieval Like Infrastructure

Retrieval is not a notebook you run once and forget. It is infrastructure, and it should be managed like code. Version your chunking strategies. When the legal team releases a new contract template, test your recursive splitter before it reaches production. Maintain your golden dataset as living documents, not a static CSV from last quarter. Automate your evaluations in CI so that a pull request modifying an embedding model or a fusion weight gets a comment with recall and latency numbers before a human ever reviews it.

Your users will never ask which embedding model you run. They will not care about your chunking heuristic or your reranker architecture. They care if the answer is correct, if it arrives fast, and if they can trust it. Build a pipeline that earns that trust, measure it honestly, and stop treating retrieval like an afterthought.

Source: Optimizing RAG At Scale
Join the discussion: GyaanSetu AI Community