Нейросеть для поиска ответов на вопросы по документам компании — это инструмент, который берёт факты из регламентов, договоров и инструкций самой организации и отвечает с ссылкой на источник, вместо ответа из общих знаний о мире. Чем это отличается от обычного чата с приложенным файлом? Разница — в масштабе и надёжности ответа. Критерий готовности контура один — высокая доля честных ответов «нет данных» там, где нужного документа в базе ещё нет.
Три режима
У нейросети для поиска ответов на вопросы по документам компании три режима — обычный чат общими знаниями, чат с одним приложенным файлом и поиск по базе из сотен документов с цитатой источника; для регламентов и договоров компании годится только третий.
Первый режим — обычный чат без документов: модель отвечает из общих знаний и на фактах компании гладко выдумывает, если факта под рукой нет. Спросить такой чат про порог скидки конкретной компании — значит получить уверенный, но случайный ответ.
Второй режим — чат с приложенным файлом: работает на одном-пяти документах за раз, а с ростом объёма модель теряет часть текста. Для разового вопроса по одному договору этого достаточно, для потока вопросов по всей базе регламентов — уже мало.
Третий режим — поиск по базе документов с цитатой источника: подходит для сотен документов, каждый ответ проверяется по абзацу, откуда он взят. В общем виде такой подход называют поиском по векторной базе или гибридным поиском, а устроен он как отдельный слой поверх модели, который сначала находит нужные фрагменты и только потом отдаёт их модели для ответа.
| Режим | Объём документов | Главный риск |
|---|---|---|
| Обычный чат без документов | ноль — общие знания модели | выдумка фактов о компании |
| Чат с приложенным файлом | один-пять документов за раз | модель теряет часть текста в длинном файле |
| Поиск по базе документов с цитатой | сотни документов | источник виден, ошибка проверяется по цитате |
Определения терминов — в словаре: векторный поиск и гибридный поиск, а архитектура целиком разобрана в статье как устроена RAG-архитектура.
Как проверить
Проверку строят на двадцати реальных вопросах сотрудников вместо демонстрационных примеров поставщика.
Для каждого ответа смотрят два параметра: ссылку на абзац источника и то, отвечает ли модель «нет данных» там, где факта нет, — второй параметр важнее первого, потому что модель, которая молчит при отсутствии факта, безопаснее модели, которая гладко выдумывает.
Главный сигнал качества — доля вопросов, где модель честно признаёт «нет данных». Выдуманный факт с уверенным тоном — противоположный и куда более рискованный сценарий.
Условный пример — отдел продаж с вопросами про условия договоров: пороги скидок, сроки поставки, что входит в гарантию. Если ответ раз за разом сверяется юристом и совпадает — контур готов к работе всего отдела; если расхождения повторяются — база документов или разбивка текста на части требуют доработки.
Пример отдела продаж
Один и тот же вопрос сотрудника от заявки до ответа с цитатой проходит так:
- Менеджер спрашивает про порог скидки для конкретной суммы заказа
- Контур находит абзац в действующем прайсовом регламенте и цитирует его
- Менеджер видит готовую фразу ответа вместе с цитатой и номером документа
- При отсутствии актуального регламента контур честно отвечает «нет данных»
Такая цепочка сокращает время на поиск нужного документа вручную — по нашему опыту внедрений, менеджер находит ответ за минуту вместо блуждания по общей папке с файлами. Юрист при этом остаётся в цепочке: он проверяет цитату, а переписывать ответ заново ему незачем — и это меняет саму роль юриста в потоке типовых вопросов, с автора ответа на контролёра источника.
Отдел продаж тонет в поиске условий по договорам?
От чего зависит точность
Точность ответа держится на четырёх практических вещах, а модель среди них почти всегда вторична.
- Разбейте документы на смысловые части — по разделам или абзацам; произвольные куски фиксированной длины дают устойчиво более слабый результат
- Обновляйте базу при каждой новой версии регламента — устаревший документ отвечает уверенно и ошибочно
- Формулируйте вопросы тестового набора так, как их пишут сотрудники — с сокращениями и без точных терминов из документа
- Сравнивайте ответ с цитатой источника построчно — совпадение цитаты с реальным текстом документа обязательно
Слабое звено чаще в разбивке документов на части, а модель здесь почти всегда вторична — крупный кусок текста размывает точный ответ, мелкий обрезает контекст.
Ответственного за базу назначают заранее, отдельным пунктом — иначе обновление регламентов идёт своим чередом, а база документов для нейросети живёт отдельной устаревающей копией. Проще всего встроить обновление базы в тот же процесс, где утверждают новую версию документа: пока регламент согласовывают, базу готовят параллельно.
Границы применения
Контур подходит для сотен документов и растёт вместе с базой компании — регламенты, договоры, инструкции, переписка по проектам.
Сборка такого контура под документы компании — тема нейросетей для документов: с оценкой объёма базы, форматов файлов и требований к доступу сотрудников.
Готовая база знаний на этом принципе разобрана в статье RAG-база знаний для компании, а частный случай для линии поддержки — в материале нейросеть для базы знаний из истории тикетов.
Общий термин RAG и его архитектура разобраны отдельно, для читателя с интересом к техническим деталям сверх бизнес-вывода этой статьи.
Компании с несколькими юридическими лицами или брендами обычно держат отдельную базу под каждое — общий контур на все регламенты сразу усложняет проверку прав доступа и путает источники при похожих, но разных документах у разных юрлиц. Разделение баз с самого начала избавляет от болезненной переработки контура позже.
Запуск такого контура редко ограничивается одним отделом: компания, которая начала с продаж, через несколько месяцев обычно расширяет базу на бухгалтерию и поддержку — принцип разбивки документов и проверки цитат переносится без изменений, меняется только набор файлов.
Отдельный вопрос — доступ сотрудников к базе: часть документов логично оставлять видимой только своему отделу, и права доступа к исходным файлам стоит настраивать до подключения нейросети, заранее — так безопаснее, чем разбираться с этим уже после первого инцидента с чувствительным документом в чужих руках.