Как устроить базу знаний, в которой можно проверить источник, дату и применимость каждого ответа

Автор: VOSHOD

Сотрудник спрашивает помощника: «Какую скидку можно согласовать клиенту?» Тот уверенно пересказывает внутреннюю инструкцию и прикладывает ссылку. Ссылка открывается, цитата существует. Проблема в том, что инструкция действовала в прошлом году и относилась к другому продукту.

Это условный пример, но он показывает важное ограничение: наличие источника ещё не делает ответ пригодным для решения. Для бизнеса полезна система, которая понимает границы документа, а при нехватке оснований останавливается.

Разберём, как спроектировать такого помощника без обещания, что он будет знать всё.

Почему загрузить папку недостаточно

Один из распространённых подходов называется RAG: система ищет подходящие фрагменты в документах и передаёт их языковой модели для подготовки ответа. В обзоре Microsoft этот подход описан как способ опираться на собственные материалы организации.

Но поиск похожего текста не равен выбору действующего правила. В общей папке могут одновременно находиться утверждённый регламент, проект следующей версии, презентация для клиентов и переписка с частным исключением.

Если система считает их одинаково авторитетными, она может собрать логичный ответ из несовместимых оснований. Более мощная модель не устранит отсутствие порядка в исходных документах.

Поэтому первый вопрос при внедрении: кто определяет, какие материалы считаются действующими и для каких задач?

Сначала назначьте владельца знания

Необязательно сразу приводить в порядок весь архив. Выберите одну область, например порядок гарантийного обслуживания. Для каждого используемого документа заведите небольшую карточку:

Кто отвечает за содержание.
Утверждён ли документ или это черновик.
Когда он начал действовать и когда перестал.
К каким продуктам, регионам и категориям клиентов относится.
Какой документ заменяет.
Кто имеет право его читать.
Где находится оригинал и конкретный раздел.

Это не бюрократия ради ИИ. Если два руководителя называют разные правила действующими, системе неоткуда получить однозначный ответ.

Владелец содержания разрешает конфликт. Разработчик обеспечивает, чтобы разрешённый конфликт отразился в поиске. Эти обязанности стоит разделить.

Полезная схема ответа

Рабочая последовательность выглядит так:

Вопрос → проверка прав сотрудника → уточнение недостающих условий → поиск допустимых документов → проверка срока и области действия → ответ с источниками или передача вопроса человеку.

Предположим, сотрудник спрашивает: «Можно ли заменить оборудование по гарантии?» Вопрос пока не содержит модели устройства, даты продажи и признаков неисправности.

Помощнику не следует сразу отвечать «да» по общему документу. Он должен запросить необходимые условия. Если точный ответ зависит от индивидуального договора, найти именно его в рамках разрешённого доступа или объяснить, кто должен проверить договор.

Сама форма ответа может быть короткой:

«В стандартном порядке предусмотрена замена при условиях А и Б. Основание: регламент, версия, раздел. По этой поставке пока неизвестна дата начала гарантии, поэтому подтвердить применимость правила нельзя. Нужен документ о передаче оборудования».

Здесь полезность состоит и в найденном правиле, и в честном обозначении того, чего не хватает.

Проверяйте ссылку и смысл отдельно

Есть как минимум три разных проверки.

Первая: существует ли источник и может ли пользователь его открыть? Ссылка на удалённый файл или закрытый раздел не помогает проверить ответ.

Вторая: подтверждает ли конкретный фрагмент сделанное утверждение? Документ может рассказывать о возвратах, но ничего не говорить о сроке, который написал помощник.

Третья: применим ли источник сейчас и к этой ситуации? Даже точная цитата из устаревшего документа может привести к неправильному действию.

Для существенных правил полезно показывать не только название файла, но и раздел, версию, дату действия. Если ответ объединяет несколько оснований, каждое важное утверждение должно иметь своё основание. Одной общей ссылки под длинным текстом недостаточно.

Доступ должен проверяться до ответа

Предположим, сотрудник поддержки может читать общий порядок компенсаций, но не индивидуальные условия крупных клиентов. Если помощник сначала извлёк закрытые условия, а затем получил инструкцию «не показывай секретное», защищённость уже зависит от поведения модели.

Надёжнее не передавать ей недоступные пользователю фрагменты. Для этого права учитывают при поиске, а ограничения сохраняют и в производных материалах: индексах, выдержках, кэше и журналах.

Отдельный тест: пользователь потерял доступ к папке. Должен ли он перестать получать её содержание через помощника? Да. Команда должна определить срок применения изменений и проверить его. Настройка прав только в день запуска проблему не решает.

Ограничение доступа к исходным сведениям и защита от вредоносных инструкций в документах тоже решают разные задачи. Как отмечает OWASP, применение RAG само по себе не устраняет риск prompt injection. Найденный текст нужно рассматривать как материал, а не как полномочие менять правила работы помощника.

Как обновлять знания без тихих конфликтов

Новая версия регламента должна не просто появиться в папке. Важно, чтобы система связала её с прежней, обновила поисковый индекс и перестала использовать отменённую версию для текущих вопросов.

При этом старый документ иногда нужен для исторического запроса: «Какое правило действовало в момент поставки?» Удаление всего старого тоже может быть ошибкой. Правильнее явно различать вопросы о текущем порядке и о прошлом периоде.

Для обновления полезен контрольный список:

Назначен ответственный и указан срок действия.
Обновлены права и связанные фрагменты индекса.
Перепроверены ответы, которые зависели от изменившегося правила.
Проверено, что поиск не выдаёт старую версию как текущую.
Зафиксировано время обновления, доступное поддержке системы.

Как понять, что помощник стал полезнее

Соберите набор вопросов из выбранного процесса. Включите простые случаи, неоднозначные формулировки, устаревшие документы, конфликты версий и вопросы без ответа в базе.

Оценивайте не только долю правильных ответов. Отдельно смотрите:

Подтверждены ли существенные утверждения источниками.
Правильно ли выбраны версия и область действия.
Не раскрывает ли помощник недоступные материалы.
Распознаёт ли ситуации, где нужно уточнение или участие человека.
Сколько времени сотрудник тратит на проверку результата.

Процент отказов сам по себе не является плохой метрикой. Если информации нет, обоснованный отказ лучше выдуманного правила. Но постоянные отказы на типовые вопросы показывают, что нужно исправлять поиск, структуру документов или полноту базы.

С чего начать владельцу бизнеса

Выберите один процесс, одного владельца содержания и ограниченный набор действующих документов. Опишите, какие вопросы помощник должен закрывать, а какие обязан передавать человеку. Только после этого обсуждайте модели и поисковые технологии.

Хорошая корпоративная база знаний позволяет не просто быстрее получить текст. Она помогает сотруднику понять, на каком основании можно действовать и где заканчивается уверенность системы.

Материал подготовлен VOSHOD. Сайт проекта · Telegram-бот.

Все ситуации в статье учебные, а не клиентские кейсы VOSHOD. При подготовке материала использован ИИ. Технические источники приведены по соответствующим темам; предложенная схема является редакционной рекомендацией, а не гарантией безошибочности.

Почему корпоративный ИИ отвечает по старым документам и как это исправить