Ловушка модных фич: почему «хочу чат-бота» — плохое начало ИИ-проекта - QubStore

Ловушка модных фич: почему «хочу чат-бота» — плохое начало ИИ-проекта

Содержание статьи

Это продолжение разговора про то, что судьба автоматизации решается до первой строчки кода. В прошлый раз я разбирал четыре решения на этапе подготовки — на том же кейсе холдинга из девяти предприятий. Сейчас — про типичную ошибку старта: руководство хочет начать с самой заметной ИИ-фичи (чат-бот для клиентов, анализ звонков, умный ассистент), потому что она эффектнее всего выглядит. А выигрывают проекты, которые стартуют с невзрачной рутины. Разберу, почему эффектность процесса сама по себе почти ничего не говорит о его окупаемости на старте и почему это всё же не повод отказываться от модных фич.

Есть закономерность, которую я вижу на многих проектах. Когда собственник или директор впервые формулирует, что он хочет от ИИ, он часто называет не то, что принесёт деньги, а то, что выглядит как ИИ. Голосовой ассистент. Чат-бот, который сам отвечает клиентам. Система, которая слушает звонки менеджеров и оценивает их работу. Всё это яркое, демонстрируемое, «вау». И многие из этих идей становятся ловушкой на старте.

Что такое «модная фича» и почему она так соблазнительна

Модная фича — это процесс, автоматизация которого выглядит впечатляюще для стороннего наблюдателя. Её можно показать на совещании, ей можно похвастаться перед партнёрами, она ощущается как «настоящий ИИ». Виртуальный консьерж, который отвечает гостям отеля в любое время суток. Аналитика звонков с онлайн-подсказками менеджеру. Умная обработка клиентских опросов.

Соблазн понятен и по-человечески оправдан. Автоматизация — это инвестиция, а инвестиции хочется видеть. Ввод паспортных данных в 1С не покажешь совету директоров как достижение, даже если он экономит вдвое больше. А вот «у нас теперь ИИ-консьерж» звучит как шаг в будущее.

Проблема в том, что эффектность и окупаемость — независимые вещи. Яркая витринная фича на старте часто оказывается сложнее, рискованнее и дальше от отдачи, чем невидимая рутина.

Кейс: две эффектные фичи, которые ушли в конец очереди

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

Виртуальный консьерж для гостиницы — влияние 4, сложность 5. Идея красивая: гость сканирует QR-код в номере, пишет боту, и тот отвечает на любой вопрос про завтраки, услуги, Wi-Fi, а сложные случаи передаёт человеку. Технически — модно: LLM с RAG-контуром поверх базы типовых ситуаций, связка с системой управления отелем и каналом эскалации на администратора.

Реальная боль тоже есть: администратор ресепшна тратит 3–4 часа смены на типовые вопросы, а летом ночные обращения гостей накапливаются без ответа до утренней смены. Но давайте посмотрим на масштаб. Это одна гостиница. Сезонная. Влияние на весь холдинг из девяти предприятий — минимальное, отсюда и четвёрка. А сложность выше влияния: чат-бот, общающийся с живыми гостями, — это репутационный риск. Одна галлюцинация в ответе про аллергены в завтраке или про условия брони — и вместо экономии вы получаете разбор с недовольным гостем. Такой процесс требует тщательной проверки, ограничителей, эскалации — то есть много работы ради небольшого по меркам группы эффекта.

Речевая аналитика звонков — влияние 5, сложность 8. Эффектная история: система слушает звонки менеджеров, проверяет соблюдение скриптов, а в идеале подсказывает прямо во время разговора. Боль реальная — вручную все звонки не прослушать, качество продаж проседает.

Казалось бы, задача решаемая: расшифровать записанные звонки, классифицировать, проверить по сценарию. В постфактум-режиме это и правда заметно проще: обработка записей не требует реального времени, и запустить её можно относительно быстро. Но собственник хотел не разбор вчерашних звонков, а подсказку менеджеру прямо во время разговора. А это уже совсем другая задача: потоковое распознавание речи с низкой задержкой, отраслевой сленг и имена, интеграция с рабочим местом оператора — и всё это должно работать точно и быстро, чтобы менеджер доверял подсказке, а не отмахивался. Именно требование реального времени и вытягивает сложность на восьмёрку. Та же тема, но два совершенно разных проекта по трудоёмкости — и хотят от нас, разумеется, сложный. Средняя польза при высокой трудоёмкости: если поставить такой процесс первым, он с высокой вероятностью затянет пилот и отложит получение измеримого результата.

Ловушка модных фич: почему «хочу чат-бота» — плохое начало ИИ-проекта

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

Что окупается вместо них

Теперь верхний угол той же карты — то, что не выглядит как ИИ, но приносит деньги.

— Распознавание паспортов и сканов — влияние 10, сложность 3. Сложность невысокая, потому что речь об ограниченном наборе типовых документов с обязательным подтверждением распознанных полей оператором. Не «ИИ сам всё вводит без контроля», а «ИИ извлекает поля, человек подтверждает спорные». Задача управляемая, поэтому её реализация относительно проста.

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

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

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

Разница между этими двумя группами — не в качестве технологий, а в природе задачи. Ввод документов — это узкое пространство входов с проверяемым результатом: набор типов документов ограничен, поле распозналось верно или нет, это видно сразу. Чат-бот для гостей — широкое: спектр запросов почти безграничен, «правильность» ответа субъективна, а цена ошибки — репутация.

Точнее всего это правило звучит так: чем Уже пространство допустимых входов и чем проще проверить результат, тем предсказуемее пилот. Это не жёсткое деление на два класса — тот же ввод документов становится непредсказуемым на грязных сканах, а чат-бот может быть вполне безопасным, если ограничить его десятком сценариев и не давать генерировать ответы за пределами базы знаний. Дело в степени ограниченности задачи, а не в ярлыке «закрытая» или «открытая».

Ловушка модных фич: почему «хочу чат-бота» — плохое начало ИИ-проекта

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

Почему это не повод отказываться от модных фич

Всё сказанное — не приговор эффектным процессам. Это вопрос очерёдности, а не пригодности.

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

Есть и обратные случаи, когда эффектная фича — вполне разумный первый проект. Чат-бот годится на старте, если это внутренний ассистент для сотрудников, а не клиентский канал; если область его ответов жёстко ограничена; если цена ошибки невелика; если обращения уже накоплены и классифицированы, есть готовая база знаний, а результат измерим — через долю вопросов, закрытых без человека, время ответа и долю эскалаций. При таких условиях «модная» технология превращается в хорошего кандидата. Дело не в самой технологии — модная она или скучная, — а в условиях, в которых её запускают. Матрица влияния и сложности как раз и нужна, чтобы отличить хорошие условия от плохих, а не хорошие технологии от плохих.

Ловушка модных фич: почему «хочу чат-бота» — плохое начало ИИ-проекта

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

Поэтому правильный вопрос звучит не «стоит ли делать чат-бота», а «когда». И ответ почти всегда — не первым. Сначала — невидимая рутина, которая вернёт деньги и доверие. Потом, на этом фундаменте, — эффектные фичи, которые уже можно показывать.

Соблазн начать с яркого понятен. Но автоматизация, которая начинается с витрины, обычно до склада так и не доходит. А та, что начинается со склада, рано или поздно обязательно доходит до витрины.

Ссылка на основную публикацию