ИИ по базе знаний: как проверить ответы до подключения к клиентам

Начните с конкретной работы помощника

Представим компанию, которая поставляет оборудование. Менеджеры ищут условия гарантии, инструкции и совместимость комплектующих в разных папках. ИИ-помощник может помочь найти подходящий материал и кратко объяснить его. Но задача «отвечать на любые вопросы о компании» слишком широкая для первой проверки. Сначала выберите одну область, где есть надёжные документы и человек, способный оценить ответ.

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

Разберите сами документы

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

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

Отделите поиск от составления ответа

В распространённой схеме RAG система сначала находит подходящие фрагменты, затем использует их при ответе. Microsoft в руководстве по проектированию такой системы рекомендует оценивать этапы отдельно. Если найден не тот документ, улучшение формулировки запроса к модели может не решить основную проблему. А хороший поиск ещё не гарантирует точного объяснения найденного.

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

Соберите набор проверочных вопросов

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

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

Оцените качество по нескольким признакам

Для каждого ответа отметьте фактическую корректность, полноту, соответствие вопросу и подтверждение источником. Не сводите всё к одной оценке «понравилось». Короткий ответ может быть верным, но не содержать важного исключения. Длинный — звучать убедительно, но добавлять неподтверждённые условия. Оценивающий сотрудник должен понимать предмет и иметь время проверить спорные места.

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

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

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

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

Назначьте процесс обновления

После запуска кто-то должен заменять документы, разбирать ошибочные ответы и поддерживать тестовый набор. Без владельца базы даже хорошо настроенный помощник со временем начинает отвечать по старым условиям. Укажите, как быстро изменение источника становится доступно, что происходит с удалёнными файлами и где сотрудник сообщает о неверном ответе.

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

Что проверить в своей задаче

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