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