RAG в продакшене: что архитектору нужно решить на самом деле
Retrieval-augmented generation стал стандартным паттерном для корпоративного ИИ. Разбираю, какие архитектурные решения действительно важны - и где ловушки.
Retrieval-augmented generation - RAG - стал стандартным ответом на вопрос «как подключить LLM к данным компании». Паттерн действительно работает. Но в начале 2025 года я вижу одну и ту же ошибку: команды выбирают векторную базу данных, загружают несколько документов - и считают архитектуру готовой. Система уходит в прод, качество оказывается низким, и никто не понимает, где искать причину.
Проблема в том, что RAG - это не выбор технологии. Это набор взаимосвязанных проектных решений. Одно неверное решение снижает качество всей цепочки.
Из чего состоит RAG
Работающая RAG-система включает как минимум четыре этапа: загрузку, поиск, дополнение и генерацию. Большинство внимания достаётся последнему - модели. Но проблемы почти всегда живут в первых двух.
Загрузка - это превращение документов в поисковые фрагменты. Способ разбивки документа принципиально важен. Слишком маленькие фрагменты - теряется контекст. Слишком большие - фрагмент разбавлен нерелевантным текстом. Правильная стратегия зависит от типа документа: юридический договор разбивается иначе, чем FAQ по продукту.
Поиск - это сопоставление запроса пользователя с сохранёнными фрагментами. Чистый векторный поиск хорошо работает, когда вопрос и ответ используют похожую лексику. Он ломается, когда вопрос абстрактный, а ответ конкретный, или когда важна точная терминология. Гибридный поиск - комбинация векторного и полнотекстового - охватывает значительно более широкий диапазон реальных запросов.
Проблема метаданных
Векторный поиск находит семантически похожий текст. Он не знает, что политика была заменена в прошлом квартале, что прайс-лист относится только к региону X, или что техническая спецификация находится на пересмотре. Этот контекст должен приходить из метаданных.
В большинстве первых реализаций метаданные - это запоздалая мысль. Результат: система уверенно извлекает устаревший или предназначенный не той аудитории контент. Пользователь получает уверенный ответ на основе неправильного источника.
Проектировать схему метаданных до загрузки - а не после - одно из самых высокоэффективных решений в RAG-проекте.
Оценка качества - не опция
Частая картина: команда прогоняет демо, выглядит хорошо, система уходит в прод. Потом медленно накапливаются жалобы на неправильные ответы.
RAG-системы нуждаются в системе оценки с самого начала. Это означает тестовый набор реальных вопросов с известными правильными ответами, и метрики как для качества поиска (нашли ли нужные фрагменты?), так и для качества генерации (использовала ли модель их корректно?). Без этого настройка - угадывание, а деградация незаметна.
Это несложно поставить, но требует человека, который за это отвечает. Обычно таких нет до первых проблем.
С чего начинать
Если я консультирую команду, начинающую RAG-проект в 2025 году, я расставляю приоритеты так:
- Узко определить сценарий использования - «доступ ко всем знаниям компании» - не сценарий.
- Провести аудит источников: формат, частота обновления, область видимости, история версий.
- Спроектировать схему метаданных под требования фильтрации.
- Выбрать стратегию разбивки под тип документа, а не единую для всего.
- Собрать небольшой оценочный набор до написания первой строки поискового кода.
Выбор модели - обычно последнее решение, а не первое. Большинство проблем с качеством в корпоративном RAG не имеют отношения к тому, какой LLM выбран.