TL;DR
AI может давать связный, уверенный, внутренне непротиворечивый вывод — и при этом быть системно неправильным. Исследование описывает 7 паттернов, при которых стандартные способы проверки качества не замечают поломки. Все семь наблюдались в реальных системах, обрабатывающих миллиарды событий в день.
Главная находка — иллюзия когерентности: когда AI делает ошибку на раннем шаге, каждый следующий шаг добавляет "подтверждения" правильности первого. Итоговый ответ выглядит аргументированным и уверенным — но его фундамент неверный с самого начала. Это хуже случайной ошибки: её сложнее заметить именно потому, что всё выглядит правильно. Второй опасный паттерн: AI даёт правильный ответ с ложным объяснением — и стандартные метрики этого вообще не замечают.
Для каждого паттерна есть конкретный способ обнаружения. Большинство из них переводятся в промпт-техники для обычного чата: проверка уверенности на каждом шаге, тест объяснения через "а что если", перефразирование задачи для проверки согласованности, явное разделение "того что считаем" и "того чего хотим на самом деле".
Схема: 7 паттернов и как их ловить
ПАТТЕРН 1: Иллюзия когерентности (Cascade Error)
Ошибка шага 1 → шаг 2 подтверждает → шаг 3 подтверждает →
итог: уверенный, связный, неправильный вывод
ЧЕМ ЛОВИТЬ → проверка уверенности на каждом шаге
ПАТТЕРН 2: Тихая деградация из-за устаревших данных (Tool Cascade)
Источник вернул неполные данные → модель не сообщила →
вывод выглядит полным, но сделан на пустоте
ЧЕМ ЛОВИТЬ → явный запрос полноты источников
ПАТТЕРН 3: Схлопывание разнообразия (Distribution Collapse)
Метрики хорошие → но все ответы становятся похожи →
система "застряла" в узком паттерне
ЧЕМ ЛОВИТЬ → аудит разнообразия выводов
ПАТТЕРН 4: Непоследовательность на разных формулировках (Consistency Collapse)
"Есть ли доступ у пользователя X?" через разные поверхности →
разные ответы на один и тот же вопрос
ЧЕМ ЛОВИТЬ → перефразирование + сравнение результатов
ПАТТЕРН 5: Ложное объяснение правильного вывода (Explanation Decoupling)
Вывод правильный → но объяснение указывает на неверную причину →
отладка идёт не туда, аудит вводит в заблуждение
ЧЕМ ЛОВИТЬ → тест возмущения (что изменится если убрать X?)
ПАТТЕРН 6: Тихая деградация под нагрузкой (Latency Pressure)
Система перегружена → переключается на упрощённый путь →
метрики зелёные, качество тихо ухудшилось
ЧЕМ ЛОВИТЬ → корреляция нагрузки и качества
ПАТТЕРН 7: Дрейф к прокси-цели (Proxy Goal Convergence)
Цель — "полезный контент" → метрика — кликабельность →
модель оптимизирует клики, теряет полезность
ЧЕМ ЛОВИТЬ → разделение прокси-метрики и истинной цели
Пример применения
Самые применимые паттерны для обычного чата: FM-1 (иллюзия когерентности в многошаговых задачах), FM-5 (тест объяснения), FM-4 (тест согласованности), FM-7 (прокси vs истинная цель).
Задача: Ты попросил Claude проанализировать идею нового продукта — мобильное бронирование столиков в ресторанах класса "выше среднего" в Москве. Модель выдала уверенный анализ: "Высокий потенциал, аудитория платёжеспособная, конкуренция умеренная." Ты хочешь проверить — это реальный анализ или иллюзия когерентности?
Промпт (тест FM-5 — проверка объяснения):
Ты только что написал, что у идеи "высокий потенциал" и "умеренная конкуренция".
Проверь своё объяснение через тест возмущения:
1. Что изменится в твоём выводе, если я скажу, что Яндекс Рестораны
уже занимают 60% этого сегмента в Москве?
2. Что изменится в выводе, если целевая аудитория — рестораны
со средним чеком 3000+ рублей, а не масс-маркет?
3. Какой факт, если бы он изменился, сделал бы твой вывод
"высокий потенциал" неверным?
Если твой вывод не меняется ни при одном из этих изменений —
объясни почему. Если меняется — скорректируй исходную оценку.
Результат: Если объяснение модели было реальным — она скорректирует оценку при значимых изменениях вводных. Если объяснение было "украшением" уже готового вывода — она либо не изменит ответ вообще, либо начнёт противоречить себе. Это и есть FM-5 в действии: тест показывает, связано ли объяснение с фактическими причинами вывода.
Почему это работает
LLM генерирует текст по паттерну — следующий токен, наиболее вероятный с учётом предыдущего. Внутренняя согласованность текста для модели — это её "комфортная зона". Чем дольше контекст, тем сильнее давление продолжать в том же духе. Поэтому ранняя ошибка в многошаговом рассуждении усиливается, а не компенсируется: модель нанизывает аргументы, которые делают ошибочный фундамент ещё более "очевидным".
Тест возмущения ломает этот паттерн принудительно. Когда ты убираешь конкретный фактор и спрашиваешь "что изменится?", модель вынуждена заново проверить связь между объяснением и выводом. Если связь была поверхностной — это немедленно обнаруживается.
Тест согласованности работает иначе: ты подаёшь одну задачу в двух разных формулировках и сравниваешь ответы. Если ответы существенно расходятся — модель реагирует на форму вопроса, а не на суть. Это прямой признак FM-4.
Рычаги управления: - Число шагов в проверке возмущения → больше тестовых сценариев = строже проверка логики - Формулировка "что изменится" vs "измени вывод" → первое честнее, второе провоцирует согласие - Явный запрос на несогласие ("найди 3 причины почему твой вывод неверен") → активирует критический режим, снижает давление когерентности
Шаблон промпта
Шаблон 1: Тест объяснения (FM-5)
Ты только что дал вывод: {вывод_модели}.
Проверь это объяснение через тест возмущения:
1. Что изменится в выводе, если {ключевой_факт_1} окажется неверным?
2. Что изменится, если {ключевой_факт_2} изменится на противоположное?
3. Какой один факт, если бы он изменился, сделал бы твой вывод ложным?
Если вывод не меняется ни при одном изменении — объясни почему.
Если меняется — скорректируй исходный вывод.
Шаблон 2: Тест согласованности (FM-4)
Я дам тебе два описания одной задачи — сформулированные по-разному.
Дай ответ на каждое независимо, затем сравни ответы.
Формулировка А: {задача_формально}
Формулировка Б: {та_же_задача_неформально}
Если ответы расходятся — объясни почему. Какой из ответов ближе
к правильному и почему?
Шаблон 3: Разделение прокси и истинной цели (FM-7)
Моя задача: {задача}
Явная метрика успеха (что легко измерить): {прокси_метрика}
Истинная цель (что я на самом деле хочу): {настоящая_цель}
Сначала реши задачу под настоящую цель, игнорируя прокси.
Затем проверь: улучшает ли решение прокси-метрику или нет?
Если они расходятся — объясни почему и предложи компромисс.
Шаблон 4: Проверка уверенности в многошаговом рассуждении (FM-1)
Реши задачу пошагово: {задача}
На каждом шаге:
- Укажи что делаешь
- Оцени свою уверенность в этом шаге (0–100%)
- Если уверенность ниже 70% — остановись и напиши
"ТОЧКА НЕОПРЕДЕЛЁННОСТИ: [что именно неясно]"
вместо того чтобы продолжать с непроверенным допущением
🚀 Быстрый старт — вставь в чат:
Вот шаблон для проверки качества AI-объяснений.
Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про твой конкретный вывод, который хочешь проверить, и какие факты считать ключевыми — потому что тест возмущения работает только на конкретных переменных, а не на абстрактных "предположениях".
Ограничения
⚠️ FM-6 и FM-2 почти не применимы в чате: Деградация под нагрузкой и проблема устаревших инструментов — это системные паттерны. В обычном чате у тебя нет инструментов (если не используешь агентов) и нет latency budget. Эти два паттерна актуальны только при работе с AI-агентами, которые сами обращаются к внешним источникам.
⚠️ FM-3 слабее в одном сеансе: Схлопывание разнообразия — это долгосрочный паттерн, заметный через десятки сессий. В одном разговоре его сложнее поймать. Помогает явный запрос разнообразия: "Дай 5 вариантов, намеренно разных, не похожих друг на друга."
⚠️ Тест возмущения требует, чтобы ты знал что проверять: FM-5 работает только если ты понимаешь, какие факторы должны влиять на вывод. Модель не покажет тебе сама, что её объяснение фиктивное — ты должен задать нужные вопросы.
⚠️ Сам метод — инфраструктурный код: PAEF (Production Agentic Evaluation Framework) — готовая система с Python-реализацией для мониторинга продакшен-систем. Для обычного чата нужны только принципы, не код.
Ресурсы
Evaluating Agentic AI in the Wild: Failure Modes, Drift Patterns, and a Production Evaluation Framework — Mukund Pandey, Independent Researcher
Открытая реализация PAEF: github.com/mukund1985/llm-eval-toolkit
Связанные работы упомянутые в статье: HELM, BIG-bench, MT-Bench, AgentBench, WebArena, SWE-bench — бенчмарки для оценки LLM. SHAP, LIME — методы post-hoc объяснения модельных решений. Goodhart's Law — принцип из экономики: "когда мера становится целью, она перестаёт быть хорошей мерой" — фундамент FM-7.