RAG система не сработала: год ошибок и путь к рабочей архитектуре

Автор оригинальной статьи на Habr больше года ведёт RAG-проект в небольшой компании. Задача: не просто искать фрагменты в документации, а научить ИИ-помощника диагностировать проблемы пользователей. Путь от первого наивного прототипа до рабочей архитектуры оказался длиннее и поучительнее, чем обещают учебники.

Что понадобится

• Любая локальная LLM (большая языковая модель, нейросеть, которая генерирует текст) или API облачной модели. В оригинале использовались модели от 3 до 8 миллиардов параметров через LM Studio
• Векторная база данных для хранения эмбеддингов (числовых «слепков» смысла текста)
• Набор корпоративных документов: инструкции, переписки из рабочих чатов, тикеты из helpdesk
• Реранкер (модель, которая пересортировывает найденные фрагменты по релевантности). В оригинале упоминается Cohere
• Терпение и технический писатель. Без качественной документации RAG система не заработает, сколько ни крути параметры
• Время: от нескольких недель на подготовку данных до нескольких месяцев на отладку

Как перейти от наивного RAG к рабочей системе?

1. Проверьте, достаточно ли у вас данных. Прежде чем писать код, честно оцените документацию. Если она неполная, противоречивая или устаревшая, сначала наведите порядок в ней. Как формулирует автор: «Мусор на входе даёт мусор на выходе». RAG система не создаёт знания, она ищет их в том, что вы ей дали.

2. Начните с наивного RAG и поймите его границы. Наивный (Naive) RAG работает так: документы режутся на куски, каждый кусок прогоняется через эмбеддер (модель, которая превращает текст в набор чисел), результат записывается в векторную базу. Когда пользователь задаёт вопрос, его текст тоже превращается в вектор, и система ищет ближайшие по смыслу куски. Этого достаточно, если задача: найти конкретный фрагмент в большом массиве документов. Не усложняйте, если ваш сценарий именно такой.

3. Соберите пары «вопрос и решение» из реальных переписок. Выгрузите тикеты, чаты, письма. Пропустите их батчами (порциями) через LLM с промптом, который отсекает мусор и оставляет только полезные пары. Пример промпта:

ROLE: Ты специалист по разметке данных.
Тебе на вход подаётся сырой кусок переписки из рабочего чата.
Задача: отсечь мусор (приветствия, поздравления) и найти
полезные пары «вопрос и ответ», касающиеся бизнес-логики.
Ответ считается полезным, если на него есть благодарность
или обратная связь от задавшего вопрос.
Формат ответа: TXT, разделитель между парами — "*****".

Такой подход даёт сразу два результата: готовые кейсы для базы знаний и живой, не синтетический набор для оценки (eval-набор) будущей RAG системы.

1. Переходите к гибридному поиску. Наивный RAG плохо справляется с аббревиатурами и кодами (например, «01-ЦФИ.Я2»), потому что их смысл нельзя адекватно записать в вектор. Гибридный поиск совмещает семантический (по смыслу) и BM25 (по ключевым словам). Добавьте реранкер, который пересортирует найденные фрагменты и отбросит нерелевантные.

2. Разделите задачи «найти» и «понять». Главная находка из оригинала: наивный RAG хорош как поисковик, но не умеет в диагностику. Если вам нужно, чтобы бот не просто находил «чек-бокс на такой-то вкладке», а объяснял, почему он не работает («потому что в настройках отключён режим такой-то»), RAG система должна уметь связывать несколько фрагментов и рассуждать по ним. Это требует другой архитектуры промптов (промпт-инжиниринга) и, скорее всего, более мощной модели.

3. Закройте пробелы в доменных знаниях. Часть знаний живёт только в головах сотрудников. Выделите AI-инженера и технического писателя в связку: один формализует знания, другой превращает их в данные, пригодные для RAG системы.

Что делать прямо сейчас, по ролям?

Автору на Дзене. Если вы пишете про технологии или ведёте экспертный канал, разбор чужих ошибок с RAG даёт готовый формат для серии постов. Покажите своей аудитории, что «ИИ-помощник» без подготовки данных не работает.

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

Предпринимателю в РФ. Все описанные инструменты доступны: LM Studio работает локально, векторные базы данных опенсорсные. Из облачных LLM, доступных в России, можно использовать YandexGPT или GigaChat вместо зарубежных API. Главное: начинайте с аудита документации, а не с выбора фреймворка.

Путь от «загрузил 50 инструкций и жду чуда» до работающей RAG системы проходит через неудобную правду: сначала документация и данные, потом архитектура и модели. Кто это принял, у того бот диагностирует проблемы, а не пересказывает оглавление.