База знаний с ИИ: как находить актуальные ответы, а не просто документы

Что такое база знаний с ИИ

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

Один из распространённых подходов — RAG: сначала система находит подходящие фрагменты, затем передаёт их языковой модели для подготовки ответа. Такой принцип описан в документации Microsoft по retrieval-augmented generation. Наличие RAG само по себе не гарантирует верного ответа: важны качество поиска, содержимое документов и проверка результата.

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

Три разных задачи, которые часто смешивают

Если сотрудникам нужен только первый результат, удобного каталога и нормальных названий файлов иногда достаточно. Второй требует работы с содержанием. Третий — ещё и связи между событиями: кто принял решение, что его изменило и действует ли оно сейчас.

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

Как подготовить источники

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

1. Уберите неоднозначность версий. У документа должны быть дата обновления, статус и понятная связь с заменённой версией.
2. Отделите факты от черновиков. Предложение в переписке не должно выглядеть как утверждённое правило.
3. Сохраните ссылки и происхождение. Ответ без доступного основания сложнее проверить и исправить.
4. Определите права. Пользователь не должен получать закрытую информацию через ответ системы, если не может видеть её источник.
5. Установите порядок обновления. Кто меняет документы, как быстро изменение попадёт в поиск, что происходит после удаления?

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

Как должен выглядеть проверяемый ответ

Представим условную ситуацию. В старом регламенте написано, что скидку подтверждает руководитель продаж. В новой инструкции лимит изменён. В переписке есть разовое исключение для одного клиента. Хороший ответ не склеивает эти три источника в универсальное правило.

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

Проверка ссылки — отдельный шаг. Открывающийся документ ещё не доказывает, что в нём есть утверждение из ответа. Сверять нужно конкретный фрагмент. Для важных решений оставьте возможность перейти к первичному материалу и задать уточняющий вопрос владельцу.

Тестовый набор вопросов перед запуском

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

• Простой вопрос с ответом в одном документе.
• Вопрос, для которого нужно соединить несколько согласованных источников.
• Вопрос об устаревшем правиле и его новой версии.
• Два документа, которые противоречат друг другу.
• Информация, которой в базе нет.
• Материал, закрытый для тестового пользователя.
• Удалённый документ или отозванное право доступа.
• Неполный вопрос, на который нельзя ответить без уточнения.

Проверяйте не только верность ответа, но и качество основания, актуальность, соблюдение прав и время до полезного результата. Отказ при отсутствии данных — нормальный результат, а не всегда недостаток системы.

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

Типичные ошибки внедрения

Загрузить всё и ждать порядка

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

Считать любую ссылку доказательством

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

Не учитывать стоимость поддержки

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

Когда нужна рабочая память Executive AI

Если вопросы касаются не только регламентов, но и решений — «что договорились сделать», «почему изменили срок», «какое ограничение действует сейчас» — полезно рассматривать сценарий рабочей памяти. На странице Business Memory Executive AI он описан через решения, причины, обязательства и первичные источники.

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

Новые решения удобно сохранять сразу после встречи: об этом — материал «ИИ для совещаний». План проверки результата и затрат собран в статье о внедрении ИИ в бизнес.

Частые вопросы