RAG точно настраивать опасно: как погоня за precision убивает поиск на 40%
Вот это новость: когда компании тонко настраивают свои RAG-модели для лучшей точности, они одновременно ломают саму способность системы находить информацию. По исследованию Redis, при попытке улучшить распознавание структурных нюансов — например, отличить «собака укусила человека» от «человек укусил собаку» — точность поиска падает на 40% на популярных средних моделях. На малых моделях потери скромнее, но всё равно 8–9%. Тихо, незаметно, но катастрофично.
Почему это особенно опасно для AI-агентов
Представь: в обычном поиске ошибка возвращает неправильный результат. Всё, система выглядит глупо. Но в AI-агентах, где агент принимает решения на основе найденной информации, одна ошибка поиска может запустить цепочку неправильных действий. Агент действует, потом действует снова, а потом — бах — система уже натворила дел. Это как домино из ошибок. Если ты разрабатываешь AI-агентов и хочешь следить за новостями в этой сфере, подпишись на Telegram-канал ProAi, где регулярно обсуждаются такие проблемы и решения.
Вот почему качество поиска здесь определяет всё остальное. А если поиск молчаливо деградирует, никто долго не заметит.
Что на самом деле происходит под капотом
Embeddings работают просто: берут целое предложение и сжимают его в одну точку в пространстве высокой размерности. Похожие по теме документы оказываются рядом. Звучит логично, да? Беда в том, что предложения с противоположным смыслом, где меняется только структура, тоже оказываются рядом — потому что модель смотрит только на слова, а не на их порядок.
Когда ты настраиваешь модель учитывать структурные различия, она перестаёт использовать часть пространства для широкого поиска по темам. Два объекта конкурируют за один вектор. Система отвоёвывает точность в структуре и теряет широту поиска. Геометрия жестока.
И вот что ещё хуже: некоторые ошибки вообще почти не исправляются даже после настройки. Binding errors — когда модель путает, что к чему относится (например, кому именно принадлежит обязательство в контракте) — практически не улучшаются. А это как раз те случаи, где ошибка стоит дороже всего.
Почему никто об этом не говорит
Потому что метрики, на которые смотрят компании во время тонкой настройки, измеряют только то, что они настраивают. Модель показывает отличные улучшения в отклонении близких непопаданий. Но никто не проверяет, что происходит с поиском по другим темам. Регрессия всплывает только в production — когда уже поздно.
Почему стандартные трюки не спасают
Hybrid search? Когда объединяют embeddings с поиском по ключевым словам — классический ход. Но если проблема в том, что система неправильно читает структуру (а не пропускает слова), keyword search помочь не может. «Рим ближе, чем Париж» и «Париж ближе, чем Рим» содержат одни и те же слова. Поиск не сможет их различить.
MaxSim reranking? Некоторые системы добавляют второй слой, который сравнивает отдельные слова между собой. Это улучшает метрики, но полностью летает на структурных близких непопаданиях. MaxSim оптимизирован для релевантности, а не для идентичности — совсем разные задачи.
Cross-encoders? Они работают идеально в лаборатории — сравнивают каждое слово с каждым словом, дают точный результат. Но в production они ломаются от объёма запросов. Слишком дорого.
Contextual memory или agentic memory? Народ говорит, это спасение от RAG. Правда? Нет. Эти системы тоже опираются на поиск в момент запроса — значит, те же ошибки применяются к ним. Это не исправляет проблему, а просто ослабляет требования к задержкам.
Что реально работает: двухэтапная архитектура
Суть всех неудач одна: одна система оценки пытается делать две работы сразу. Решение — перестать так делать.
Этап первый: recall. Обычный поиск, как есть. Embedding-модель сжимает документы в векторы, находит близайшие к запросу. Широкая сеть, быстрый результат. Никаких перфекционизма — просто хорошие кандидаты.
Этап второй: precision. Вот здесь живёт решение. Вместо одного числа похожести маленькая обученная Transformer-модель смотрит на запрос и каждого кандидата на уровне отдельных слов. Она ловит структурные несоответствия: отрицания, перестановки ролей. Верификация, которую одиночный вектор не может провести.
Результат? Этот двухэтапный подход надежнее всего прочего в отклонении близких структурных непопаданий. Единственный, который ловит то, чего одиночная система упускает.
Цена? Добавляется задержка. Зависит от того, насколько глубоко проверять. В legal или accounting — можно проверять каждый запрос полностью. Для обычного поиска — лёгкая проверка достаточна.
Что делать компаниям
Перестраивать всё с нуля не нужно. Но нужно давить на предположения, которые никто никогда не проверял. Что твоя модель на самом деле делает? Какие метрики вообще стоят доверия? Где скрываются реальные дыры в production?
Первый шаг — просто понять, что регрессия существует. Перед tuning нужно оценить систему по трём критериям: correctness, completeness, usefulness. Если система хорошо смотрится на бенчмарках, но падает на структурных непопаданиях — это опасная иллюзия готовности.
И вот важное: RAG не мёртв. Есть голоса, что его пора отправлять на пенсию. Бред. RAG — это простой pipeline, который может развернуть почти кто угодно без особых усилий. Исследование не говорит против RAG как такого. Оно говорит против веры в то, что одноэтапный RAG с fine-tuned embeddings готов к production для precision-sensitive задач.
И да, двухэтапное решение работает, но не бесплатно. Это не запретительно сложно, но задержка добавляется. Как говорят: это не проблема, которую можно решить. Это проблема, которую можно смягчить.