RAG — это связка, в которой модель сначала ищет нужные куски в вашей базе документов, а потом отвечает на их основе. Подход решает три беды чистых языковых моделей: устаревшие данные, выдуманные факты и незнание ваших внутренних документов. На бумаге всё просто, а на практике система часто отвечает мимо. Разберём, где именно она ломается.

Нарезка документов — самое слабое звено

Перед поиском документы режут на куски (чанки), и качество этой нарезки напрямую определяет качество ответов. Тут работает эффект слабого звена: каким бы умным ни был ответ модели, она оперирует только тем, что нашёл поиск. Главный компромисс прост:

  • Слишком большой кусок — вектор теряет конкретику, поиск находит его на всё подряд.
  • Слишком маленький — теряется контекст, по куску непонятно, о чём речь.

Рабочий ориентир — рекурсивная или семантическая нарезка с перекрытием в 10–20%, чтобы соседние куски не теряли связь на границах.

Иногда нарезать вообще не нужно

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

Эмбеддинги: какую модель брать

Эмбеддинг превращает кусок текста в вектор, по которому идёт поиск. Под текст обычно берут специализированные модели вроде E5, SBERT или Instruct, а векторы стоит нормализовать. Отдельный приём — late chunking, когда длинноконтекстная модель сначала прогоняет весь документ, а нарезку применяет уже к токенам. Так каждый кусок сохраняет полный контекст и поиск работает точнее.

Поиск решает половину дела

Даже с хорошими чанками поиск можно настроить лучше. Несколько проверенных решений:

  • Гибридный поиск — связка классического BM25 по словам и плотного векторного поиска. Лексический поиск вытягивает редкие термины, которые вектор пропускает.
  • HNSW с фильтрацией по метаданным — даёт ответ за десятки миллисекунд при высокой полноте.
  • Реранкинг кросс-энкодером — переупорядочивает топ результатов, когда важна точность первых ответов.

Лишний контекст вредит не меньше, чем недостающий

Кажется логичным подать модели побольше найденных кусков на всякий случай. На деле избыток избыточной или неполной информации роняет качество ответа: модель тонет в шуме и хватается не за то. Лучше отдать несколько точных кусков, чем десяток приблизительных. Поэтому реранкинг и аккуратный отбор топ-результатов часто важнее, чем расширение выдачи.

Как чинить RAG по шагам

Если система отвечает мимо, идите по цепочке от поиска к ответу:

  1. Проверьте, что поиск вообще находит нужные куски, — без этого настраивать промпт бессмысленно.
  2. Пересмотрите нарезку: размер кусков, перекрытие, не дробите ли вы короткие документы зря.
  3. Добавьте гибридный поиск, если теряются редкие термины и точные формулировки.
  4. Включите реранкинг, если нужный кусок находится, но стоит не на первом месте.
  5. Сократите число подаваемых кусков, если модель путается в шуме.

RAG ломается не в модели, а в поиске и нарезке. Начинайте отладку с того, что именно находит ваш ретривер, а не с формулировок промпта. В большинстве случаев правильные чанки и гибридный поиск дают больший прирост качества, чем смена языковой модели.