ИИ-помощник откажется работать ровно тогда, когда он нужнее всего. Что держать про запас

20 июля Hugging Face разбирал взлом собственной инфраструктуры. Логов набралось на 17 тысяч действий атакующего — вручную это недели работы, поэтому инженеры отдали их коммерческим моделям на разбор. Модели отказались. Встроенные фильтры увидели в логах фрагменты вредоносного кода и не отличили специалиста, который расследует инцидент, от того, кто атаку готовит. Разбор в итоге сделала модель с открытыми весами, поднятая на своём железе: те же логи она приняла без возражений и закрыла работу за часы. Но Hugging Face держит собственное железо и инженеров, которые умеют такое разворачивать. У обычной компании запасного пути под рукой не окажется.

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

Отказ модели на безобидной задаче — штатное поведение, и оно измерено.

Есть открытый бенчмарк OR-Bench: 80 тысяч безопасных запросов, которые модели всё равно отклоняют. Главный вывод оттуда неприятный: связь между «моделью, которая надёжно отсекает вредное» и «моделью, которая отказывает на безобидном» очень сильная — коэффициент корреляции 0,88. Провайдеры покупают безопасность ценой ложных отказов, и наоборот. Размер модели тут почти ни при чём.

Свежий замер мая 2026 по 19 передовым моделям даёт вторую цифру: на одних и тех же запросах доля отказов у разных провайдеров разошлась от 0,1% до 94,6%. Юрисдикция значения почти не имела, а вот конкретный провайдер — имел. И отдельно: у одного из вендоров очередное обновление флагманской модели подняло отказы на безобидных научных запросах на 43,7 пункта. Способность отличать безобидное от по-настоящему опасного при этом просела на 65%.

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

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

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

У меня есть своя открытая библиотека llm-rotator: она перебирает провайдеров и модели, когда что-то идёт не так. Ошибки разбираются по типам: 429 — упёрлись в лимит, блокируем эту пару «ключ плюс модель» на время из заголовка ответа; 401 — ключ мёртв глобально; 5xx — один быстрый повтор, потом переключение на следующего провайдера. Работает надёжно, потому что все эти случаи приходят кодом ошибки, а код легко поймать.

Отказ по фильтру безопасности приходит иначе. Это 200 OK и вежливый текст «я не могу помочь с этим запросом». Для библиотеки это успешный ответ, для конвейера дальше по цепочке — валидный вход. Ротация не сработает, алерт не поднимется, счётчик ошибок останется нулевым. В отчётах вы увидите стопроцентную доступность сервиса.

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

Запасной контур — это заранее проверенный второй путь для узкого класса задач.

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

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

И самый дешёвый контур, который почему-то ставят последним: путь эскалации на человека. Если модель отказала, задача должна попасть в очередь к сотруднику с пометкой «отклонено фильтром», а не потеряться в логах.

Отказ модели — её штатное поведение, настроенное провайдером под свои риски, а не под ваши. Планировать надо не «если откажет», а «когда откажет и на чём именно».

Зависимость от одного провайдера опаснее не в момент, когда он лежит, — падение видно всем и чинится быстро. Она опаснее в момент, когда он работает, отвечает 200 OK и молча не делает работу.

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

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

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

Свои разборы и грабли выкладываю в Telegram — @dmitra_ai.