Kill switch для LLM: как отключать риск без релиза

Когда один промпт ломает весь поток

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

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

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

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

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

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

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

Что лучше выключать по отдельности

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

Поэтому kill switch для LLM лучше разделить на несколько независимых переключателей. Тогда команда не гасит весь сервис из-за одной ошибки и не делает аварийный релиз под давлением. В продакшене это особенно важно: простой даже на 15 минут иногда обходится дороже самой ошибки.

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

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

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

Полезно заранее описать, что должно происходить после каждого отключения. Например:

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

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

Где держать переключатель

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

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

Имя у флага должно быть скучным и понятным. Не safe_mode_2 и не temp_fix_prod. Намного лучше работают названия вроде disable_tool_export_csv, block_prompt_support_v4 или route_off_deepseek_for_kb_bot. Во время инцидента человек должен понять смысл без созвона на полчаса.

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

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

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

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

Как ввести kill switch по шагам

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

Сначала опишите, что именно можно выключать

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

Каждому элементу нужен стабильный идентификатор. Не "новый промпт для саппорта", а что-то вроде prompt.support.refund_v2 или route.kyc.primary. Имя не должно меняться после каждого редактирования, иначе флаг быстро потеряет смысл и команда начнет путаться.

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

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

Заранее задайте безопасный сценарий

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

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

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

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

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

Какие сигналы должны сработать первыми

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

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

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

Вот типовые сигналы, которых обычно достаточно:

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

Ручной и автоматический запуск

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

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

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

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

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

Пример: бот поддержки начал слать лишние данные

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

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

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

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

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

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

Ошибки, из-за которых switch не сработает

Чаще всего kill switch для LLM ломается не в момент инцидента, а намного раньше, когда его делают "на всякий случай" и ни разу не проверяют в деле. Внешне флаг есть, но быстро выключить риск нельзя.

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

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

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

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

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

Хороший switch обычно проверяют по пяти вопросам:

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

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

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

Короткий список проверок

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

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

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

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

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

С чего начать на этой неделе

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

Обычно это:

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

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

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

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

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

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