Бизнес ·
RAG отвечает не за память ИИ, а за право сослаться на источник
Когда сотрудник спрашивает ИИ о внутренних правилах компании, модель не должна угадывать ответ по общим знаниям. RAG позволяет сначала найти подходящие фрагменты документов и только потом сформулировать ответ. Но полезная система начинается не с векторной базы, а с решения, каким документам можно доверять и кому их можно показывать.
Что происходит между вопросом и ответом
RAG — сокращение от retrieval-augmented generation, «генерация с дополнением найденными данными». В обычной схеме вопрос сначала превращается в поисковый запрос к разрешённым источникам. Система отбирает фрагменты, передаёт их модели вместе с вопросом, а модель собирает ответ с указанием опоры. Если подходящего материала нет, правильным результатом может быть честное «не найдено».
Это не обучение модели на всех документах компании. Изменившийся документ можно обновить в поисковом контуре без переобучения модели, хотя индексу тоже нужна синхронизация. И наличие фрагмента в контексте не гарантирует верного ответа: модель может неверно прочитать таблицу, пропустить исключение или соединить несовместимые версии правил.
Сначала владельцы знания, потом индекс
Представим вопрос: «Можно ли обещать клиенту доставку завтра?» Один файл описывает обычный срок, другой — исключение для конкретного склада, третий устарел. Если загрузить всё без статусов, система найдёт убедительный, но неправильный текст. Поэтому до технической сборки следует определить владельца каждого источника, дату действия, версию, связь с подразделением и правило удаления старой версии.
У знаний должен быть путь исправления. Сотрудник обнаружил неверный ответ — кто правит исходный документ, кто проверяет изменение и когда обновляется поиск? Без этого RAG превращает беспорядок в документах в быстрый беспорядок в ответах.
Доступ проверяют до поиска
Пользователь может задать безобидный вопрос, а поиск найти закрытый договор или персональные данные. Запретить модели «не показывать секретное» после получения фрагмента недостаточно: закрытый материал уже оказался в контексте. Отбор источников должен учитывать права спрашивающего до передачи текста модели.
Стоит отдельно проверить журналы запросов, срок хранения и доступ поставщика модели к передаваемым данным. Архитектура зависит от состава документов и условий обработки, а не только от качества ответа в демонстрации.
Проверяют поиск и ответ по отдельности
Соберите небольшой набор настоящих вопросов сотрудников: обычные, спорные, с устаревшим правилом и без ответа в документах. Для каждого зафиксируйте допустимый источник и ожидаемое поведение. Сначала проверяйте, найден ли нужный фрагмент и не утекли ли чужие документы. Затем — отражает ли ответ источник, показывает ли оговорки и умеет ли отказаться от догадки.
Так видно, где ошибка: в отсутствующем документе, правах доступа, поиске или формулировании ответа. Правка промпта не заменит исправление неверной базы знаний. Полезно сохранять версию источника рядом с ответом, чтобы при изменении документа можно было понять, на чём он основывался.
Когда RAG избыточен
Если сотрудники задают несколько повторяющихся вопросов по короткому неизменному регламенту, достаточно обычной страницы с поиском и ответственным редактором. Если требуется выполнить действие — изменить заказ или отправить письмо, — одного RAG мало: нужны интеграция, права на действие и подтверждение результата. Он решает задачу поиска опоры для ответа, а не автоматизирует весь процесс.
Первый шаг — один проверяемый вопрос
Начните с одного набора документов и одного типа вопросов, по которому можно проверить точность и границы доступа. После испытания станет ясно, нужен ли RAG, достаточно ли хорошего поиска или пора проектировать полноценного ИИ-помощника. В работе над внедрением ИИ я бы начинал именно с этого решения: какая информация допустима, кто ею владеет и что система должна сказать, когда надёжного ответа нет.
ИИ для конкретного процесса
Если вы рассматриваете внедрение ИИ, начнём с процесса, доступных данных, границ автоматизации и способа проверить результат.