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