Как собрать базу знаний, чтобы ИИ-агент отвечал по вашим условиям

Начните с обращений, а не с папки документов

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

Для первого запуска достаточно пяти групп:

• прайс и состав услуг;
• часы работы и каналы связи;
• условия, исключения и ограничения;
• порядок передачи вопроса человеку;
• изменения, которые уже вступили в силу.

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

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

Разделите знания и правила действий

Знание отвечает на вопрос «что верно сейчас». Правило действий отвечает на вопрос «что делать с этим знанием». Их стоит хранить и обновлять раздельно.

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

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

Сделайте каждую запись проверяемой

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

Ниже — учебный пример: он показывает форму записи, а не условия реальной компании.

Плохо: «Доставка обычно быстрая, стоимость зависит от заказа».

Хорошо:

Тема: доставка в пределах города

Действующее условие: стоимость и срок рассчитываются сотрудником после уточнения адреса и состава заказа.

Исключения: срочная доставка и удалённые адреса рассматриваются отдельно.

Действие агента: собрать адрес и состав заказа; передать запрос сотруднику.

Первоисточник: внутренний регламент доставки, редакция от 08.11.2026.

Владелец: руководитель операций.

Дата следующей проверки: при изменении регламента.

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

Понимайте RAG без технического тумана

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

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

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

Не оставляйте конфликтующие условия без решения

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

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

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

Проверьте базу десятью вопросами до запуска

Тестировать нужно не только простые вопросы, на которые в базе есть прямой ответ. Добавьте отсутствие данных, исключения и противоречивые формулировки. Microsoft рекомендует после добавления источника задавать вопросы для проверки и учитывать готовность источника и доступ к нему; детали этого подхода описаны в материале о тестировании знаний. Это рекомендация для соответствующего продукта, а не описание функций Smokva.

Вот стартовый набор вопросов для вашей базы:

1. Какова актуальная цена основной услуги?
2. Что входит в эту цену, а что оплачивается отдельно?
3. В какие часы можно получить консультацию?
4. Какое правило действует в нестандартный день?
5. Есть ли ограничение по региону или категории клиента?
6. Что ответить, если нужной информации нет в базе?
7. Кому передать спорную ситуацию?
8. Что делать при двух разных версиях условия?
9. Какой первоисточник подтверждает ответ?
10. Когда эту запись последний раз пересматривали?

Отмечайте не только «правильно» или «неправильно». Фиксируйте тип сбоя: не нашёл источник, нашёл устаревшее, не учёл исключение, дал ответ там, где нужна передача. Так следующая правка будет предметной.

Дайте команде одно понятное поручение

База быстро устаревает, если обновление зависит от памяти одного человека. Введите простой маршрут: владелец условия сообщает об изменении, ответственный обновляет карточку, другой сотрудник задаёт тестовые вопросы. Для координации можно использовать ИИ-команду Smokva, если сценарий и права участников настроены под вашу работу.

Готовый текст поручения на сегодня:

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

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

Частые ошибки

Загружают всё без отбора. Большая папка не равна полезной базе. Начните с вопросов, которые реально повторяются.

Хранят цену без даты и владельца. Непонятно, действует ли она и кто подтвердит изменение.

Смешивают правило и факт. При обновлении меняется только половина ответа.

Не описывают исключения. Агент применяет общее правило там, где оно не работает.

Проверяют только удачные сценарии. Именно вопросы без ответа и конфликтующие условия показывают границы базы.

Ожидают, что агент решит противоречие сам. Сначала согласуйте действующее условие, затем обновляйте знания.

Короткие вопросы перед подключением

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

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

Что делать, если ответа нет? Настроить понятную передачу человеку и пополнять базу только после подтверждения нового условия.