Перевод LLM в продакшен: что проверить после пилота

Что меняется после пилота

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

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

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

После пилота обычно меняется сразу несколько вещей:

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

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

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

Как начать переход в продакшен

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

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

Потом посчитайте нагрузку. Смотрите не только на среднее число запросов в день, но и на пики: утро понедельника, конец месяца, рассылка, массовый вход пользователей после обновления приложения. Если в пилоте было 300 запросов в день, а в релизе функция появится у всей службы поддержки, нагрузка может вырасти в 20 раз за пару часов. Отдельно оцените длину промптов и ответов, потому что и счет, и задержка зависят не только от числа запросов.

Запуск лучше делить на этапы:

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

Так проще увидеть, где ломается логика, где модель отвечает слишком долго и где расходы уходят выше плана.

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

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

Как настроить лимиты без лишних блокировок

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

Ограничения стоит ставить сразу в нескольких плоскостях:

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

Один RPM не спасает, если часть вызовов уходит в длинные ответы. И наоборот, токены не покажут, что какой-то клиент слишком часто бьет API мелкими запросами.

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

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

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

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

Что включить в наблюдаемость

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

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

Что писать по каждому запросу

Минимальный набор полей лучше сделать одинаковым для всех сервисов:

• время старта и полная задержка до ответа пользователю
• модель, провайдер, версия промпта и тип задачи
• статус ответа: успех, таймаут, ошибка, пустой текст, сломанный JSON
• число входных и выходных токенов и фактическая стоимость
• request_id, чтобы собрать всю цепочку от API до экрана или CRM

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

Отдельно ловите тихие сбои. Для LLM это обычная история: сервис вернул статус 200, но внутри пустая строка, оборванный JSON или текст не того формата. Формально запрос успешный, по факту задача не выполнена. Такие случаи лучше считать отдельным типом ошибки, иначе метрики будут выглядеть лучше, чем реальная картина.

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

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

Как разделить доступы и контуры

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

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

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

Полезный минимум обычно такой:

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

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

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

Как выбрать модели для разных задач

Общий тест "какая модель лучше" почти всегда дает ложный ответ. Для продакшена полезнее собрать 3-5 типовых задач, которые правда проходят через систему каждый день. Иначе модель выбирают по красивому демо, а не по рабочей нагрузке.

Чаще всего хватает такого набора:

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

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

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

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

Запасной вариант нужен с первого дня. Провайдер может резко увеличить задержку, уткнуться в лимит или временно стать недоступным. Если приложение работает через один OpenAI-совместимый шлюз, например AI Router на airouter.kz, основную и резервную модель проще держать за одним и тем же API. Маршрут можно менять отдельно от кода, а приложение этого не замечает.

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

Пример рабочего сценария

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

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

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

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

Ошибки, которые тормозят запуск

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

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

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

С метриками команды тоже часто упрощают картину. Средняя задержка почти всегда выглядит терпимо. Но пользователи чувствуют не среднее значение, а длинный хвост. Если 90% запросов проходят за 2 секунды, а остальные ждут 18, жалобы все равно придут. Поэтому смотрите хотя бы P95, P99, таймауты и долю ошибок по каждому сценарию.

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

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

Короткий чек-лист перед релизом

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

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

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

Перед запуском полезно пройтись по короткому списку:

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

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

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

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

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

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

• через 7 дней проверить ошибки, задержку, расход токенов и долю эскалаций
• через 14 дней разобрать реальные диалоги, где ответ оказался слабым, слишком дорогим или слишком медленным
• через 30 дней пересобрать правила маршрутизации, лимиты и роли доступа по факту, а не по ожиданиям

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

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

Для команд из Казахстана после запуска быстро всплывают и организационные требования: хранение данных внутри страны, маскирование PII, аудит-логи, лимиты на уровне ключа и один OpenAI-совместимый API для разных провайдеров. В таких случаях отдельный шлюз вроде AI Router может снять часть операционной нагрузки и упростить управление доступом и маршрутами.

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