Нейросеть отказывается отвечать: почему и что делать

«Модель не отвечает» — это два разных события, которые в коде обычно валят в одну обработку, и из-за этого чинят не то. Отказ модели приходит как успешный ответ: код 200, обычное тело, а внутри текст «не могу помочь с этим». Техническая проблема — неверный ключ, закрытый маршрут, превышенный лимит — возвращает код ошибки и текста не содержит вовсе. Первое не лечится повтором никогда, второе иногда лечится только повтором. Разбираем, как их различать, что делать с ложными отказами на законных задачах и почему обход фильтров — плохая основа для сервиса.

Два разных события

Различие принципиальное, и начинать надо с него.

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

Техническая ошибка. Запрос до модели не дошёл или не был обработан. Возвращается код ошибки, тела с ответом нет, токены обычно не списываются.

Отсюда практический вывод: проверять надо не только код ответа, но и содержание. Иначе отказы будут молча попадать пользователю как «ответ модели», а вы будете считать, что всё работает.

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

Почему модель отказывает

Четыре типовые причины, и только одна из них про содержание запроса.

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

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

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

Модель решила, что не хватает данных, и оформила это как отказ. Формально не отказ по правилам, но выглядит так же.

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

Что делать с ложным отказом

Порядок по убыванию эффективности. Обход правил в списке отсутствует намеренно.

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

Разбейте задачу. Часто отклоняется целое, а части проходят. Разбор длинного документа по разделам работает там, где целиком не проходит.

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

Переформулируйте от результата. Вместо описания процесса опишите, какой результат вам нужен.

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

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

Чего делать не стоит

Прямо и коротко.

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

Не повторяйте тот же запрос. При отказе модели повтор даёт тот же результат и стоит денег.

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

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

Как обрабатывать в коде

Пять правил для рабочего сервиса.

1. Различайте три исхода: ответ, отказ модели, техническая ошибка. Три ветки, а не две.
2. Распознавайте отказ по содержанию. Универсального поля нет; на практике помогает проверка на характерные формулировки плюс то, что структура ответа не соответствует ожидаемой — при строгом формате отказ виден сразу, потому что схема не выполнена.
3. Логируйте отказы отдельно. С текстом запроса, если это допустимо по вашим правилам обработки данных.
4. Показывайте понятное сообщение и предлагайте действие: переформулировать, сократить, обратиться к человеку.
5. Считайте долю отказов как метрику. Её рост — сигнал, что вендор поменял правила или ваш поток изменился.

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

Когда отказ — правильное поведение

Раздел для равновесия.

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

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

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

Разграничение, которое влияет на то, что показывать пользователю.

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

Отказ по правилам звучит как отказ: модель сообщает, что не может помочь с этим запросом. Переформулирование иногда помогает, повтор — никогда.

Нехватка данных звучит как признание: в предоставленных материалах ответа нет. Это правильное поведение, если вы сами просили честно сообщать о таких случаях. Лечится не переформулированием, а тем, что вы кладёте в контекст, — поиском нужных фрагментов.

Неспособность выполнить задачу — третий случай: модель пытается, но результат не соответствует требованиям. Здесь помогает разбиение задачи или другая позиция.

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

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

Не публикуем списки триггеров. Правила у вендоров не документированы полностью и меняются.

Не сравниваем модели по строгости. Своих замеров мы не делали; различия есть, но измерять их надо на своих запросах.

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

Не обещаем, что смена модели решит вопрос. Иногда решает, иногда нет.

Что нужно, чтобы попробовать другую модель

Ключ заводится за минуту на keydealer.ru/login — почта и пароль, без документов и без зарубежной карты. Один ключ на весь каталог: если ваша задача упирается в правила конкретной модели, проверить её на позиции из другого семейства — это правка одной строки, а не новый договор и не новая интеграция.

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

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

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

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

Как мы проверяем факты и что храним из запросов — на странице о проекте и в llms.txt. Проверить свою задачу на нескольких семействах: keydealer.ru/login.