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