RAG в продакшене: почему большой контекст не решает задачу
Разбор того, почему техника RAG часто разочаровывает в production и где настоящее узкое место.
На волне интереса к языковым моделям одна из самых популярных архитектур последних месяцев - RAG, Retrieval-Augmented Generation. Идея простая: не обучай модель на своих данных, просто найди нужные куски и передай их в контекст запроса. Звучит как готовое решение для корпоративного поиска, внутренней базы знаний или ответов на вопросы по документации.
На пилотах это работает убедительно. На реальном масштабе картина меняется.
Что такое RAG и почему он привлекает
Суть подхода - разбить корпоративные документы на фрагменты, превратить их в векторные представления, а при поступлении вопроса найти ближайшие по смыслу фрагменты и отдать их модели вместе с вопросом. Модель отвечает, опираясь на найденный контекст.
Это снимает несколько болей: не нужно дообучать дорогую модель на каждом обновлении документации, данные можно обновлять независимо, ответ можно сопроводить ссылкой на источник.
Привлекательность понятна. Но привлекательность - это не то же самое, что готовность к эксплуатации.
Где реально ломается
Первое узкое место - качество фрагментации. Документы в компании не написаны так, чтобы их удобно было резать на куски. Длинные регламенты с перекрёстными ссылками, таблицы с аббревиатурами, контекст который понятен только тем, кто знает предысторию - всё это разбивается без учёта смысла. Модель получает куски, по которым нельзя ответить без знания соседних.
Второе - качество поиска. Векторный поиск находит семантически похожее, но не всегда нужное. Если пользователь спрашивает "что делать при отказе поставщика", а в документах это описано как "процедура управления рисками контрагента" - поиск может промахнуться.
Третье - качество самих документов. RAG усиливает то, что есть. Если документация устарела, противоречива или написана для внутреннего употребления с непроясненными допущениями - модель будет давать уверенные ответы на основе плохого материала.
Почему рост контекстного окна не решает проблему
Часто слышу аргумент: "Скоро модели будут держать в контексте весь корпус документов - тогда RAG не нужен". Это технически возможно в узких случаях, но не снимает проблему качества источников. Большой контекст позволяет передать больше материала, но модель всё равно работает с тем, что в него попало. Плохие данные в большом контексте дают такой же плохой результат, только дороже.
Кроме того, длинный контекст создаёт свои эффекты: модели хуже извлекают информацию из середины длинного контекста, чем с начала или конца. Это исследованный феномен, а не теория.
Что стоит проверить перед запуском
Прежде чем вкладывать в RAG-систему, я задаю несколько вопросов:
- Кто отвечает за актуальность документов, которые войдут в базу знаний?
- Есть ли процесс обновления - или это разовая загрузка "и посмотрим"?
- Как устроена проверка качества ответов - кто и как будет ловить галлюцинации?
- Понятны ли границы применимости системы пользователям, или они будут доверять ответу безоговорочно?
- Что происходит, когда система отвечает уверенно и неверно - каков ущерб?
RAG - хорошая техника. Но, как и любой инструмент, она решает конкретную часть задачи. Часть с данными и процессами вокруг них никуда не исчезает.