LLM API и интеграция

Сколько стоит поддержка бота в год после запуска

Сколько стоит поддержка бота в год после запуска

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

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

Шесть статей расхода

СтатьяКогда появляетсяРастёт сама
Токенысразуда, вместе с использованием
Работа с промптамис первого месяцанет, но рывками
Обновление данных и базы знанийсо второго-третьего месяцада, вместе с объёмом
Разбор инцидентовнепредсказуемонет
Перенос при смене моделираз в несколько месяцевнет, но дорого
Проверка качества на выборкепостоянно, если делаетенет

Первая строка — единственная, которую обычно закладывают. Остальные пять всплывают по ходу.

Токены: маленькая статья, которая растёт

Начнём с очевидного и сразу снимем напряжение: на типовых задачах это недорого. Разбор тысячи обращений в месяц на дешёвой позиции укладывается в единицы рублей при ставке от 1 ₽ за миллион токенов.

Важнее другое — расход растёт без решений. Три причины, и все безобидные по отдельности:

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

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

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

Ловится это одним взглядом в журнал раз в месяц: средние токены входа на запрос. Если они растут, а задача не менялась — растёт служебная часть. Механика счёта разобрана в материале сколько стоит миллион токенов в рублях, а способы подрезать расход — в материале как сократить расходы на API.

Работа с промптами

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

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

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

Обновление данных

Если бот отвечает по вашей базе — прайсу, регламентам, памяткам, — база устаревает. Это не вопрос «если», а вопрос «когда заметят».

Расход здесь двойной. Есть работа по поддержанию актуальности — её делает человек, который знает предмет. И есть работа по переносу обновлений в тот вид, в котором их читает система.

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

Разбор инцидентов

Раз в несколько месяцев что-то идёт не так, и это нормально. Ненормально — не иметь возможности разобраться.

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

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

Перенос при смене модели

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

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

Хорошая новость в том, что стоимость переезда управляемая. Она падает, если промпты лежат в версиях, если есть выборка из тридцати реальных запросов с эталонными ответами и если имя модели не зашито в десяти местах. Механика переноса разобрана в материале как обновлять промпты при смене модели, а планирование — в материале календарь отключений моделей 2026.

Проверка качества

Единственная статья, которую можно не тратить — и единственная, отказ от которой обходится дороже всего.

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

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

Кто именно это делает

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

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

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

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

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

Что происходит, если поддержку не заложить

Сценарий предсказуемый и повторяется от внедрения к внедрению.

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

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

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

Как заложить это в бюджет

Считайте не стоимость запуска, а стоимость года. Формула простая и состоит из трёх слагаемых.

Токены на прогнозируемом объёме, умноженные на полтора. Множитель закрывает рост использования, который произойдёт сам.

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

Резерв на один переезд. Вы не знаете, когда он случится, но за год он обычно случается.

Токенную часть удобно считать там, где расход виден по каждому запросу: KeyDealer даёт один ключ на каталог из 57 позиций, 44 из которых доступны сейчас, с оплатой российской картой в рублях и ставками от 1 ₽ за миллион токенов. Ключ под каждый сценарий отдельный — тогда в конце месяца видно не общую сумму, а расход по каждому направлению, и понятно, что именно выросло.

Чего мы не утверждаем

Три оговорки.

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

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

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

Что держать в голове

Первое. Запуск — это первый счёт, а не единственный. Смета, которая заканчивается на дате запуска, неполная по построению.

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

Третье. Самый дорогой сюрприз — переезд на другую модель, и его цена определяется не вендором, а вашей готовностью: версиями промптов, выборкой для проверки и тем, в скольких местах зашито имя модели. Что мы за проект — на странице о проекте, ключ заводится на keydealer.ru/login.

Частые вопросы

Из чего складывается поддержка после запуска?

Из шести статей: токены, работа человека с промптами и базой знаний, разбор инцидентов, обновление данных, перенос при смене модели и проверка качества на выборке. Токены обычно самая маленькая из них, а самая большая — человеческие часы, которых в смете внедрения не было.

Почему расход на токены растёт сам?

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

Сколько времени в месяц уходит на сопровождение?

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

Что дороже всего в году после запуска?

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

Можно ли обойтись без поддержки вообще?

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

Как заложить это в бюджет заранее?

Считать не стоимость запуска, а стоимость года: токены на прогнозируемом объёме плюс часы на сопровождение плюс резерв на один переезд. Резерв важнее остального: именно он превращает неожиданную работу в плановую.

Источники