Не заставляйте агента «переть напролом»: стратегии контролируемой деградации для AI-продуктов
Попытки сделать AI-агента всегда правильным — тщетны. В статье обсуждается, как проектировать предсказуемое поведение при снижении возможностей модели, чтобы защитить доверие пользователей.
Зачем агенту нужны варианты, кроме «переть напролом»
В прошлом году я прототипировал AI-генератор музыки, где пользователи описывали мелодию на естественном языке, а система генерировала MIDI. Модель работала неплохо, но была неловкая ситуация: когда пользователь вводил «сыграй меланхоличный до мажор на пианино», модель что-то генерировала, но до мажор — светлая тональность, а меланхолия требует более сложной аранжировки. Результат был либо механической гаммой, либо шаблонной мелодией. Пользователи говорили, что звучит как случайные ноты.
Моя первая реакция: донастроить модель. Две недели правок почти не улучшили метрики, а удовлетворённость пользователей даже снизилась — вывод стал пресным, пропала случайность, которая давала неожиданные находки. Я понял, что проблема не в точности модели, а в отсутствии честного варианта: когда неопределённость высока, не могла ли система сказать пользователю «Я могу не справиться; вот более простая версия, или попробуйте другое описание»?
Это недооценённая инженерная проблема в AI-агентах: контролируемая деградация.
Агент не может всегда «выкладываться»
Многие команды, создающие AI-агентов, по умолчанию используют стратегию «модель выдаёт лучшее, а пользователь оценивает». Но на практике, когда модель выдаёт некачественный контент, пользователи винят продукт, а не природу модели. Особенно когда агент берётся за сложные задачи (генерация кода, написание отчётов, оркестровка процессов), ошибки быстро разрушают доверие — пользователи тратят больше времени на исправление, чем на использование.
Контринтуитивное наблюдение: ключевая способность агента — не точность модели, а осознание системой собственной неопределённости и реакция на неё. Как в автономном вождении: L4 не едет в сильный туман, а понижает уровень до L2 и просит водителя взять управление. AI-продуктам нужны аналогичные стратегии деградации.
Трёхмерная система принятия решений
Из своей практики я вывел такую систему — не из теории, а из шишек. Чтобы решить, стоит ли агенту деградировать, оцените три измерения:
1. Критичность задачи (Criticality)
Какова цена ошибки? Неправильная рекомендация песни — не страшно. Неправильный пункт контракта — юридические риски. Я делю на три уровня:
- Низкая критичность: рекомендации, развлечения, генерация идей. Ошибка малозначима, можно терпеть случайный вывод.
- Средняя критичность: обобщение, перевод, организация информации. Ошибки требуют исправления, но пользователь быстро их замечает.
- Высокая критичность: генерация production-кода, финансовые расчёты, медицинские советы. Ошибки могут привести к серьёзным потерям.
Для высококритичных задач вывод должен быть проверен человеком. Если это невозможно — деградируйте: выдайте черновик с предупреждением или откажитесь выполнять.
2. Уверенность модели (Confidence)
Модели часто выдают оценку уверенности (logits или вероятности), но многие команды игнорируют её. Я провёл эксперимент: в приложении для изучения языка модель оценивала грамматические ошибки в предложениях пользователя. Если уверенность была ниже 0.7, вместо прямого исправления система говорила «Это предложение звучит странно — вы уверены?» Пользователям это нравилось больше — они чувствовали уважение, а не исправление.
Пороги можно сделать динамическими: для низкокритичных задач — 0.3, для высококритичных — 0.8. Но уверенность модели не всегда надёжна, особенно у маленьких моделей. Я предпочитаю гибридную уверенность: комбинировать logits модели, историческую точность на похожих задачах и обратную связь пользователя (например, правил ли он вывод).
3. Экспертиза пользователя (Expertise)
Новичкам нужна более консервативная деградация, потому что они могут не заметить ошибку; эксперты справляются сами. Например, в AI-инструменте для письма: если пользователь — профессиональный журналист, требующий фактической точности, система должна явно помечать «Этот абзац сгенерирован AI, проверьте». Если пользователь — обычный блогер, пишущий о личной жизни, деградация может быть реже.
Практическое решение: при первом использовании или начале задачи дайте пользователю выбрать уровень «осторожности» — просто высокий/средний/низкий, соответствующий разным условиям деградации.
Чек-лист стратегий деградации
На основе трёх измерений вот матрица решений для диалоговых AI-агентов или функциональных модулей (пример: пользователь просит сгенерировать код):
| Критичность задачи | Уверенность модели | Экспертиза пользователя | Рекомендуемое поведение |
|---|---|---|---|
| Низкая | Высокая | Низкая | Вывести напрямую |
| Низкая | Низкая | Низкая | Вывести с отказом от ответственности |
| Средняя | Высокая | Высокая | Вывести с предупреждением о риске |
| Средняя | Низкая | Низкая | Деградировать до черновика + запросить подтверждение |
| Высокая | Любая | Любая | Деградировать до каркаса + предложить ручное написание |
Матрица не жёсткая, адаптируйте под свой продукт. Главное — сделать деградацию явным дизайном, а не багом.
Конкретные способы деградации
Деградация — это не просто «вернуть ошибку». Я пробовал несколько вариантов, упорядоченных по серьёзности:
- Упростить вывод: выполнить только часть задачи. Для генерации кода — выдать псевдокод вместо рабочего кода.
- Вывод + предупреждение: оставить вывод, но явно указать «Модель не уверена в результате, проверьте».
- Запросить уточнение: пусть модель задаст более конкретный вопрос, чтобы снизить неопределённость. Например, «Вы хотите до мажор или минор? Я предлагаю минор для меланхолии.»
- Передать человеку: предоставить канал поддержки или поставить задачу в очередь для ручной обработки. У маленьких команд может не быть техподдержки, но можно сделать «записать запрос, обработать позже, уведомить пользователя».
- Отказаться выполнять: чётко сказать «Извините, я не могу надёжно выполнить этот запрос. Попробуйте другое описание или используйте другой метод.» Это крайняя мера, но лучше, чем выдавать мусор.
В своих продуктах я чаще всего использую «вывод + предупреждение» и «запросить уточнение». Отказ применяю только при явных рисках безопасности (например, генерация вредоносного кода).
Возможные сбои и границы
Эта стратегия — не серебряная пуля. Есть несколько ловушек:
- Калибровка уверенности ненадёжна: модели уверенно ошибаются. Деградация не должна полагаться только на уверенность модели; комбинируйте с неявными сигналами (копирует ли пользователь, редактирует ли).
- Слишком частые деградации: пользователи раздражаются. Если система постоянно говорит «я не уверен», они уйдут. Нужен баланс: строго на критичных задачах, либерально на некритичных.
- Низкое качество упрощения: если упрощённый вывод слишком плох, пользователи предпочтут оригинал. Упрощение должно сохранять ключевую информацию, а не просто обрезать.
Заключение
Создавая AI-продукты, особенно агентов, легко впасть в единственный образ мыслей «повысить точность модели». Но когда продукт попадает к пользователям, восприятие надёжности — это не только правильность, но и предсказуемость. Агент, который знает, когда сказать «я не могу», вызывает больше доверия, чем тот, который всегда «прёт» и часто ошибается.
PaxLee