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