Что такое RAG простыми словами
RAG (retrieval-augmented generation, генерация с извлечением) связывает поиск и языковую модель. Прежде чем ответить, система находит в вашей базе фрагменты, которые относятся к вопросу, и кладёт их модели в контекст. Модель отвечает, опираясь на найденное.
Похоже на сотрудника, которому задали вопрос по внутреннему регламенту. Он открывает нужные страницы и отвечает по ним со ссылкой на пункт. RAG устроен так же, поэтому его ответы можно проверить.
Когда RAG нужен, а когда нет
RAG оправдан, когда знание живёт в документах и меняется: регламенты, договоры, техническая документация, база знаний поддержки, история проектов. Документ обновили, и система сразу отвечает по новой редакции, без переобучения.
RAG не нужен и только добавит сложности, если:
- ответ вычисляется из структурированных данных: здесь нужен запрос к базе, поиск по смыслу не поможет;
- документов мало и они целиком помещаются в контекст модели;
- задача требует действий в системах, а не знаний: это работа агента, и RAG будет только одним из его инструментов;
- нужен строго детерминированный ответ по формуле или регламенту: правило в коде надёжнее.
Как устроена RAG-система
Минимальный работающий контур состоит из шести частей, и отказать может каждая.
- Сбор документов: выгрузка из хранилищ, почты, вики, файловых шар. На этом же шаге решают, что делать со сканами и таблицами.
- Нарезка на фрагменты: документ режут на куски, которые модель получит целиком. Слишком мелкие теряют смысл, слишком крупные размывают поиск.
- Векторизация: каждый фрагмент превращается в набор чисел, который отражает смысл, и попадает в векторную базу.
- Поиск: вопрос превращается в такой же вектор, и база возвращает ближайшие фрагменты. Хорошие системы добавляют к этому обычный полнотекстовый поиск по терминам.
- Сборка контекста: отобранные фрагменты фильтруют, переупорядочивают и складывают в промпт вместе с инструкцией.
- Генерация с цитированием: модель отвечает и указывает, на каких фрагментах основан ответ.
Где RAG ломается на реальных документах
Нарезка
Самая частая причина плохих ответов. Если регламент разрезан посреди пункта, фрагмент теряет условие применения, и модель отвечает уверенно и неверно. Нарезка должна следовать структуре документа: разделам, пунктам, таблицам. Резать по фиксированному числу символов нельзя.
Таблицы, сканы и приложения
Таблица, превращённая в плоский текст, теряет связь заголовка со значением. Скан без распознавания вообще не попадает в поиск. В корпоративных архивах такого материала обычно больше, чем ждут на старте, поэтому его разбор планируют отдельной статьёй работ.
Версии и дубликаты
В базе одновременно лежат договор, его новая редакция и черновик. Поиск по смыслу с одинаковой охотой найдёт любой из них. Если у документа нет даты, статуса и приоритета версии, система будет отвечать по отменённой редакции и формально не ошибётся.
Смысл против терминов
Векторный поиск хорошо понимает переформулировки и плохо понимает точные обозначения: артикулы, номера ГОСТов, названия версий. Помогает гибридный поиск, где векторный и полнотекстовый работают вместе и их результаты объединяются.
Права доступа
Если фильтр по правам не встроен в сам поиск, система рано или поздно процитирует сотруднику документ, который ему видеть нельзя. Права должны быть частью индекса. Фильтровать уже готовый ответ поздно.
Как понять, что система работает
Ощущение «вроде отвечает неплохо» приёмкой не считается. Нужен набор вопросов с заранее известными правильными ответами и ссылками на источник. Его собирают вместе с экспертами предметной области до запуска и по нему измеряют то, что действительно важно:
- нашлись ли нужные фрагменты (качество поиска меряют отдельно от качества ответа);
- опирается ли ответ на найденное или модель добавила что-то от себя;
- есть ли в ответе ссылка на источник и ведёт ли она в правильное место;
- умеет ли система отказаться, когда ответа в документах нет. Это отдельный навык, и его проверяют специально.
Поиск и генерацию меряют по отдельности, потому что лечатся они по-разному. Если ошибка в поиске, правка промпта ничего не даст, и наоборот. Без такого разделения улучшать систему приходится наугад.
RAG, дообучение или граф знаний
Три подхода решают разные задачи, и их часто путают.
- RAG подходит, когда знание меняется и его нужно цитировать. Обновить данные почти ничего не стоит.
- Дообучение подходит, когда нужно поменять поведение и стиль модели или научить её узкому формату. Знание фактов оно даёт плохо и устаревает вместе с данными.
- Граф знаний подходит, когда важны связи между сущностями и ответ требует нескольких шагов рассуждения: кто с кем связан, что от чего зависит, какая деталь входит в какой узел.
Сильные системы обычно сочетают подходы: граф отвечает за структуру и связи, векторный поиск за формулировки, дообучение за стиль и формат. Как выбирать между графом и векторным поиском, мы разобрали отдельно.
С чего начать
- Возьмите один процесс, где вопросы повторяются и у ответа есть измеримая цена: поддержку, подбор по документации, проверку договоров.
- Соберите 30–50 реальных вопросов с эталонными ответами. Это самая ценная работа этапа, и целиком отдать её подрядчику нельзя.
- Соберите прототип на ограниченном наборе документов и проверьте его на своих вопросах.
- Расширяйте корпус только после этого. Плохую систему на большом корпусе отлаживать в разы дороже.