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