LLM-пилот не готов к масштабу: как объяснить руководству

Почему пилот рано считают готовым

Руководству часто показывают пилот, который выглядит спокойнее и дешевле, чем будет в реальной работе. На демо LLM отвечает быстро и уверенно, но это еще не значит, что систему можно безболезненно вывести на большой поток.

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

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

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

Обычно никто не считает и скрытые затраты пилота. Команда тратит время на разбор странных ответов, проверку логов, повторные прогоны, ручную разметку и объяснения коллегам, почему результат "почти нормальный". Пока это делают несколько человек между другими задачами, пилот кажется дешевым.

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

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

Что меняется, когда пилот растет

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

Когда пользователей становится больше, меняется не только объем. Меняется сама картина ошибок. Люди задают вопросы короче, пишут с опечатками, присылают неполные данные и просят то, чего команда на пилоте просто не видела.

Пока запросов мало, неудачный ответ легко списать на случайность. При росте это уже повторяемый сценарий. Если ошибка случается даже в 1% случаев, на сотне запросов ее почти не замечают, а на десяти тысячах это уже ежедневный поток проблем.

Поэтому хорошее демо проверяет только одно: работает ли идея. Масштаб проверяет другое - выдерживает ли система обычную жизнь.

Служба поддержки чувствует это одной из первых. Операторы начинают чаще перепроверять ответы вручную, разбирать жалобы, объяснять клиентам, почему ответ был неточным, и переделывать уже закрытые обращения. Работа не ускоряется, а местами даже тормозится.

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

На малом объеме такие сигналы тонут в общей картине. На большом они складываются в понятную экономику: больше проверок, больше ожидания, больше недовольных пользователей. В этот момент разговор стоит переводить с "у нас иногда ошибается модель" на "у нас растет стоимость каждого полезного ответа".

Как говорить о качестве без жаргона

Руководству мало помогает фраза "модель иногда галлюцинирует". Это внутренний термин, который не показывает масштаб проблемы. Намного понятнее сказать: "Система иногда дает уверенный неверный ответ". В этом и риск: текст звучит убедительно, хотя по сути он ошибочен.

Дальше лучше переходить от общих слов к наблюдаемым цифрам. Не "качество стало выше", а "из 100 ответов сотрудники исправили 17". Еще лучше, если видно, что именно они правили: название тарифа, срок доставки, условия возврата, сумму комиссии.

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

Полезно разделять ошибки по последствиям. Мелкая ошибка - ответ неточный, но человек поправит его за минуту. Слабый ответ - формально без явной ошибки, но клиент не получил решения и пишет повторно. Опасная ошибка - система уверенно советует неверное действие, путает правила или придумывает факт.

Такое деление помогает не спорить, "хорошая" модель или "плохая". Для бизнеса важнее другое: сколько стоит каждый тип ошибки. Лишний чат с поддержкой - это одна цена. Неверный ответ про возврат денег, персональные данные или условия договора - совсем другая.

Хорошо работает простой пример на одном и том же вопросе клиента. Допустим, человек спрашивает, можно ли вернуть товар после 14 дней. Хороший ответ называет точный срок, условие возврата и следующий шаг. Слабый ответ звучит расплывчато и отправляет клиента "уточнить у оператора". Недопустимый ответ уверенно пишет, что возврат всегда возможен, хотя это не так.

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

Как перевести риски на язык бизнеса

Руководство редко спорит с тем, что модель "иногда ошибается". Такой риск звучит слишком общо. Разговор становится предметным, когда ошибка получает цену: потерянная выручка, лишние часы команды, срыв срока, жалоба клиента или проверка со стороны комплаенса.

Фраза "точность 93%" почти ничего не решает. Намного яснее звучит так: из 1000 ответов около 70 придется исправлять вручную. Это значит, что команда потратит еще 12-15 часов в неделю, а часть клиентов получит ответ позже и вернется с повторным обращением.

Перевод на язык бизнеса обычно выглядит просто. Неверный ответ клиенту означает повторное обращение, нагрузку на поддержку и риск оттока. Ошибка в документе ведет к задержке согласования и ручной проверке. Неверная классификация заявки дает пропущенный срок и недовольного клиента. Лишняя "уверенность" модели повышает шанс, что сотрудник заметит проблему слишком поздно.

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

Данные, логи и контроль в РФ лучше обсуждать как отдельный риск, а не как техническую деталь. У руководства обычно три простых вопроса: какие данные уходят в модель, где хранятся логи и кто потом сможет показать историю решения. Если на это нет четкого ответа, тормозить будут не только ИБ, но и закупка, юристы и внутренний аудит.

Если команде нужен OpenAI-совместимый шлюз с хранением логов и бэкапов в РФ, можно заранее проверить RU LLM. У сервиса есть единый OpenAI-совместимый эндпоинт, аудит-трейлы по каждому запросу, маскирование PII и биллинг внутри РФ. Это не снимает все риски, но помогает закрыть базовые вопросы про данные и контроль до масштабирования.

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

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

Откуда берутся операционные расходы

Руководство часто смотрит на одну цифру: сколько стоят токены. Для пилота этого почти хватает. Для масштаба - уже нет. Основные расходы появляются вокруг ответа модели, а не только внутри него.

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

Повторные запросы тоже быстро раздувают бюджет. Модель может не понять вопрос с первого раза, потерять контекст или дать слишком общий ответ. Тогда пользователь пишет еще раз, оператор отправляет уточнение, а система делает новый вызов. Формально это мелочь. По факту цена одного полезного ответа растет, потому что до него доходят со второй или третьей попытки.

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

Последний пункт часто вспоминают слишком поздно. Если сервис работает с клиентскими данными, команда должна видеть, что именно пошло не так, где ответ сломался и кто это заметил. Для банков, телекома, ритейла и госсектора к этому добавляются логи, аудит действий, хранение данных в РФ и маскирование персональных данных. Это не украшения для архитектуры, а ежедневные затраты на нормальную работу.

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

Поэтому полезно считать не "стоимость токенов", а стоимость одного полезного ответа. Вопрос простой: сколько стоит довести ответ до состояния, когда его можно безопасно отправить клиенту, и сколько стоит сбой, если плохой ответ все же ушел.

Пример: бот для поддержки клиентов

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

Проблема начинается после роста до 5000 обращений в день. В поток попадают спорные случаи: нестандартные возвраты, ошибки в оплате, жалобы на списания, сообщения с неполными данными. Бот по-прежнему может отвечать уверенно, но уверенный ответ не всегда верный. Если доля спорных ответов растет даже с 2% до 8%, это уже не мелочь. При 5000 обращений это 400 диалогов в день, которые кто-то должен проверить, исправить или разобрать с клиентом заново.

И тут меняется экономика. Раньше оператор лишь иногда смотрел переписку. Теперь он читает больше диалогов, дольше думает над спорными случаями и чаще перехватывает разговор на середине. Если на перепроверку одного сомнительного диалога уходит в среднем 2 минуты, 400 случаев дадут около 13 часов дополнительной работы в день. Это уже не "бот разгружает поддержку", а "поддержка страхует бота".

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

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

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

Как провести разговор по шагам

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

Удобнее идти по простой последовательности.

1. Сначала назовите цель на языке бизнеса. Не "внедрить LLM", а, например, сократить время ответа в поддержке на 20% или убрать часть ручной обработки заявок.
2. Затем покажите, что пилот уже делает без сбоев. Лучше узкий, но честный результат, чем широкое обещание.
3. После этого спокойно назовите ограничения простыми словами: где система ошибается, где ей нужен человек и где она начинает обходиться слишком дорого.
4. Принесите цифры за последние 7 дней: объем запросов, долю удачных ответов, число эскалаций на людей, время проверки спорных случаев и прямые расходы.
5. В конце зафиксируйте условие следующего этапа. Не просите "одобрить масштабирование" вообще. Сформулируйте порог: при каких метриках идете дальше, а при каких нет.

Одна деталь часто решает исход встречи: не спорьте с ожиданием "почему нельзя запустить сейчас", а переводите его в выбор. Либо компания идет в рост с понятными ограничениями и дополнительными затратами, либо сначала закрывает несколько слабых мест. Такой формат звучит взрослее, чем спор о технологиях.

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

Частые ошибки в таком разговоре

Разговор с руководством часто ломается не из-за самой идеи, а из-за того, как команда описывает пилот. Одной общей тревоги мало. Нужны простые факты: где модель ошибается, сколько стоит каждый ответ и что придется делать руками после запуска.

Первая ошибка - обещать, что качество само поднимется после выхода в прод. Обычно происходит обратное. На малом объеме пилот видит понятные сценарии, а после запуска приходят редкие случаи, спорные запросы и злые пользователи. Если команда не показала эти слабые места заранее, руководство слышит не оценку риска, а обычную перестраховку.

Вторая ошибка - показывать только средний результат. Среднее число выглядит спокойно, но оно прячет провалы. Если бот правильно отвечает в 90% диалогов, это еще не значит, что бизнес в безопасности. Оставшиеся 10% могут попасть в возвраты, жалобы, неверные обещания клиенту или утечку чувствительных данных. Один плохой сценарий иногда стоит дороже сотни хороших.

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

Часто забывают и про ручные исправления. Если сотрудники каждый день перечитывают ответы, чинят промпты, перезапускают запросы или дописывают клиенту правильный вариант, модель работает не сама. Она забирает время команды. Эти часы нужно считать так же честно, как счета от провайдера моделей.

Отдельная ошибка - молчать о данных и аудите. Для руководства это может казаться "технической деталью", пока не всплывет вопрос: где лежат логи, кто видит персональные данные, можно ли доказать, почему бот дал именно такой ответ. Для компаний с требованиями по 152-ФЗ и внутреннему контролю это часть бюджета и сроков, а не мелочь на потом.

Полезнее говорить коротко и прямо. Не "качество хорошее в среднем", а "в 7 из 100 случаев нужен человек". Не "пилот недорогой", а "при полном трафике сумма вырастет в четыре раза". Не "риски под контролем", а "у нас пока нет понятного аудита и правил по данным".

Так разговор становится взрослее. Руководство видит не спор о технологии, а обычное управленческое решение с понятной ценой ошибки.

Быстрая проверка перед решением о росте

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

Во-первых, какая ошибка для бизнеса недопустима? Не "низкое качество", а конкретный сбой: бот придумал условия возврата, раскрыл чужие данные или отправил клиента не туда. Пока этот порог не назван, спор о рисках будет пустым.

Во-вторых, сколько стоит один полезный ответ? Считать надо не цену запроса, а полный результат: модель, повторные попытки, проверка человеком, исправления и поддержка. Иногда ответ за 2 рубля в итоге обходится в 12.

В-третьих, какова доля ручных правок? Если сотрудники переписывают каждый пятый ответ, пилот еще держится на людях, а не на процессе. При росте такая схема быстро начинает съедать время команды.

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

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

Последний пункт часто недооценивают. Для российских компаний это не формальность. Если в пилоте есть данные клиентов или сотрудников, требования 152-ФЗ, хранение логов в РФ и понятный аудит запросов влияют и на срок запуска, и на бюджет. Поэтому вопрос "где работает модель" лучше обсуждать до масштабирования, а не после первого инцидента.

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

Что делать дальше

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

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

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

Короткий этап перед масштабом

Полный запуск лучше отложить на короткий переходный этап. Обычно хватает 2-4 недель, если заранее выбрать понятные метрики и ограничить объем.

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

Если нужен OpenAI-совместимый шлюз, его лучше проверить до масштабирования, а не после первых проблем. Для российских команд обычно важны три вещи: где хранятся логи и бэкапы, есть ли аудит-трейлы по каждому запросу и как устроен биллинг. Поэтому такие варианты, как RU LLM, логично сравнивать еще на переходном этапе, пока архитектуру и процессы можно поменять без лишней боли.

Финал такого этапа должен быть скучным и ясным. Не "в целом все неплохо", а одно из трех решений: масштабируем сейчас, дорабатываем еще один цикл или ставим паузу. Если пилот не готов к масштабу, это не провал. Это нормальный результат проверки, который экономит деньги, время команды и лишние обещания бизнесу.