Explainable-агенты против чёрного ящика: чем платить

Агент на базе GPT-4 или Claude получает задачу «оптимизируй расходы на облако» и через час удаляет неиспользуемый, как ему показалось, S3-бакет с бэкапами. Логи покажут, какие инструменты он вызвал, но не покажут, почему он решил, что бакет не нужен. Это и есть водораздел между двумя подходами к архитектуре агентов: одни строятся так, чтобы решение можно было проследить и оспорить, другие оптимизируются только под результат. Разница ощущается не в демо, а в момент, когда что-то ломается.

Что стоит за двумя терминами

Black-box агент — это система, где вы видите вход (промпт, доступные инструменты) и выход (действия, результат), но не имеете достоверного описания рассуждений между ними. Классический ReAct-агент, который выводит «Thought: ...», формально что-то объясняет, но это объяснение сгенерировано той же моделью постфактум и не обязано отражать реальную причину действия.

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

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

Почему «Thought:» — это не объяснение

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

Где какой подход уместен

Спор «explainable против black-box» не решается универсально. Он решается ценой ошибки в конкретном сценарии.

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

Цена вопроса в деньгах и токенах

Прозрачность не бесплатна. Explainable-обвязка обычно добавляет:

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

Конкретные суммы зависят от модели и объёма — сверяйте актуальные цены за токены на странице тарифов вашего провайдера, они меняются несколько раз в год. Порядок величины: агент с планированием и самопроверкой легко расходует в 2–4 раза больше токенов на ту же задачу, чем прямой black-box вызов.

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

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

1. Разделите план и исполнение. Пусть агент сначала выдаёт структурированный план (список шагов с ожидаемым результатом), а потом исполняет. План легко показать человеку до запуска необратимых шагов.
2. Привязывайте выводы к источникам. Каждое утверждение агента — со ссылкой на документ, строку в базе или результат вызова инструмента. Без источника — не факт, а догадка.
3. Ставьте human-in-the-loop на необратимое. Удаление, платёж, отправка письма клиенту — через подтверждение. Это дешевле любого объяснения постфактум.
4. Логируйте вызовы инструментов, а не только текст. Что именно агент дёрнул, с какими аргументами и какой получил ответ — это объективный след, в отличие от сгенерированных «мыслей».
5. Тестируйте на состязательных кейсах. Специально подсовывайте двусмысленные задачи и смотрите, где агент выдумывает обоснование.

Самое честное объяснение агента — это не его слова, а лог того, что он реально сделал. Слова можно проверить только сопоставлением с логом.

Регуляторный контекст

Прозрачность перестаёт быть вопросом вкуса там, где появляется регулятор. Европейский AI Act вводит требования к документированию и надзору за высокорисковыми системами, и «мы не знаем, почему агент так решил» — плохой ответ для аудита. Для сценариев, где агент влияет на деньги клиентов, доступ к персональным данным или юридически значимые действия, объяснимость становится не преимуществом, а условием допуска на рынок.

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

¹ Речь о так называемой проблеме faithfulness (достоверности) рассуждений модели — расхождении между сгенерированным объяснением и фактической причиной вывода. Это активная область исследований, единого решения на 2024 год нет. ↩