Ошибки LLM-пилота: 7 причин, почему команда буксует

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

На демо почти всегда все лучше, чем в живом потоке. Команда берет 20-30 аккуратных примеров, запускает одну модель и получает ровные ответы. Нет очередей, всплесков нагрузки, плохих сканов и странных формулировок.

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

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

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

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

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

Ошибка 1. Берут демо-кейс вместо живого потока

Команда часто начинает с 20-30 аккуратных примеров. Запросы короткие, текст чистый, формулировки понятные. На такой выборке модель почти всегда выглядит лучше, чем в реальной работе. Так и начинается перекос: демо проходит отлично, а пилот тормозит уже на первой неделе.

Живой поток выглядит иначе. Клиент копирует кусок письма с подписью и лишними строками. Оператор вставляет вопрос без контекста. Сотрудник банка отправляет длинный документ, где полезный фрагмент спрятан в середине. Если команда не проверяет такие случаи заранее, она тестирует не рабочий сценарий, а его красивую версию.

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

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

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

Ошибка 2. Работают без eval-контуров

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

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

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

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

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

Ошибка 3. Не собирают трассировку запросов

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

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

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

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

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

Ошибка 4. Выбирают модель вручную

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

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

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

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

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

Ошибка 5. Забывают про лимиты и квоты

Команды часто смотрят только на качество ответа и цену за 1 млн токенов. А пилот срывают более скучные вещи: RPM, TPM и дневные квоты. Пока трафик маленький, этого не видно. В первый заметный день все всплывает сразу.

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

Где пилот ломается

RPM ограничивает число запросов в минуту. TPM режет общий объем токенов. Дневная квота добивает систему позже, когда пилот уже встроился в процесс. Если следить только за одним лимитом, почти всегда пропускаешь другой.

Особенно больно это видно в банке, телекоме и госсекторе. Пользователь отправляет заявку, ждет 5-10 секунд, а потом получает таймаут. Он не знает, что у модели закончился запас токенов или провайдер начал резать частоту. Для него система просто не работает.

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

Что проверить до запуска

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

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

Ошибка 6. Путают быстрый старт с безопасным стартом

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

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

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

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

В российском контуре эта тема быстро упирается в 152-ФЗ и требования к хранению логов. Поэтому команды часто сразу ищут слой, где data residency, маскирование PII и audit trails встроены в сам маршрут запроса. У RU LLM это есть на уровне API-шлюза: логи и бэкапы хранятся в РФ, а метки и аудит идут вместе с запросом. Так безопаснее, чем пытаться прикрутить все это уже после запуска.

Ошибка 7. Не считают стоимость и задержку по шагам

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

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

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

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

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

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

Как это выглядит в живом пилоте

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

В бою картина быстро меняется. Клиент пишет большое обращение, вставляет номер договора, потом перескакивает на другую тему. История диалога растет, токенов становится больше, часть запросов упирается в лимиты LLM API, а часть начинает отвечать слишком медленно для живой смены. Там, где на демо ответ был аккуратным, в реальном потоке модель вдруг спорит с внутренними правилами банка или уверенно придумывает то, чего в данных нет.

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

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

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

Быстрая проверка перед запуском

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

• Возьмите 30-50 реальных запросов из будущего потока, а не красивые примеры из презентации.
• Для каждого теста зафиксируйте ожидаемый результат: ответ верный, не придуман факт, не раскрыты лишние данные, соблюден формат.
• Убедитесь, что в каждом запросе видны модель, версия промпта, число токенов и задержка.
• Прогоните нагрузку хотя бы на уровне пикового дня, а не среднего часа.
• Проверьте, что сервис маскирует PII до записи в логи.

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

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

Что сделать в ближайшие две недели

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

Первая неделя

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

Этого уже хватит, чтобы спор в духе вроде отвечает нормально заменить цифрами. После первых 50-100 прогонов часто видно, что сбой сидит не в самой модели, а в маршруте, промпте или грязных входных данных.

Вторая неделя

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

Параллельно проверьте лимиты и квоты по API, маскирование PII до записи логов, хранение логов и бэкапов в РФ, если у вас есть требования по 152-ФЗ, а также то, кто и как смотрит аудит-трейл по спорным ответам.

Если команде нужен единый OpenAI-совместимый эндпоинт с маршрутизацией моделей и российским контуром хранения, такой пилот можно быстро проверить через RU LLM на rullm.com. В этом случае меняется base_url на api.rullm.com, а SDK, код и промпты можно оставить без изменений. Это удобно не само по себе, а потому что команда быстрее понимает, где именно пилот буксует: в модели, лимитах, трассировке или качестве данных.