AI идёт в разнос: почему чем дольше разговор, тем хуже результат
Вот ситуация, которую видел каждый, кто работает с AI: модель делает ошибку. Вы указываете на ошибку. Модель извиняется и делает другую ошибку. Вы объясняете подробнее. Модель генерирует что-то совсем странное. Через 10 итераций вы получаете результат хуже, чем был на первом шаге.
Это не баг конкретной модели. Это фундаментальное свойство архитектуры transformer. И понимание этого свойства — разница между “AI бесполезен” и “AI — мой самый мощный инструмент”.
Почему AI не может признать, что ошибся
Языковая модель не “думает”. Она генерирует наиболее вероятный следующий токен на основе всего контекста — системного промпта, истории разговора, вашего последнего сообщения.
Ключевое слово — всего контекста. Когда модель делает ошибку и эта ошибка попадает в историю, она становится частью контекста. У неё появляется вес.
Attention bias: ошибка как якорь
Механизм self-attention в transformer работает так: каждый токен “смотрит” на все предыдущие токены и решает, какие из них релевантны. Ошибочный ответ модели — это десятки или сотни токенов, которые теперь навсегда в контекстном окне.
Когда вы просите “исправь ошибку”, модель видит:
- Ваш исходный запрос
- Свой ошибочный ответ (полный, развёрнутый, уверенный)
- Вашу поправку (короткая, одно предложение)
По объёму ошибочный ответ может быть в 10 раз больше вашей поправки. Механизм attention распределяет “внимание” пропорционально. Результат: модель пытается согласовать свой предыдущий ответ с вашей поправкой, а не переделать с нуля.
Это как спросить у человека, который написал 3 страницы обоснования решения: “А ты уверен?” Он не выбросит 3 страницы. Он будет объяснять, почему 3 страницы всё ещё правильные, только с “небольшой корректировкой”.
Confirmation loop: каждый retry усиливает ошибку
С каждой попыткой исправления контекст растёт:
| Итерация | Контекст | Вес ошибки |
|---|---|---|
| 1 | Запрос + ответ | 50% |
| 2 | + поправка + исправление | ~55% (ошибка + попытка fix) |
| 3 | + ещё поправка + ещё fix | ~60% |
| 5 | + 5 раундов fixes | ~70% |
| 10 | + 10 раундов | ~80% |
Каждая попытка исправления добавляет в контекст:
- Вашу поправку (маленькая)
- Новый ответ модели, который ссылается на предыдущие ответы (большой)
Модель не может “забыть” свои предыдущие ответы — они в контексте, они имеют вес, они фонят. Она пытается быть консистентной со всем, что уже сказала. Даже если то, что она сказала — неправильно.
Sunk cost в контексте
Это аналог sunk cost fallacy, но на уровне архитектуры. Человек продолжает неудачный проект, потому что “уже столько вложили”. Модель продолжает ошибочную линию рассуждений, потому что в контексте столько токенов, подтверждающих эту линию.
Разница: человек может осознать fallacy. Модель — нет. У неё нет meta-cognition. Она не может посмотреть на свой контекст и сказать: “70% этого контекста — мусор, проигнорирую”.
Иллюзия, которая дорого обходится
Из-за этого свойства возникает опасная иллюзия: “AI может решать сложные задачи итеративно”. Менеджер даёт задачу, видит 80%-ный результат, просит доделать. AI доделывает, но вносит новые ошибки. Менеджер просит исправить. Цикл повторяется. Через час результат хуже, чем был через 5 минут.
AI блестяще решает задачи с чистого листа. Когда нет контекста с ошибками, когда модель идёт правильным маршрутом с первого шага — результат впечатляет. 8500 строк кода за сессию, ноль ручного вмешательства, всё работает.
Но стоит модели свернуть не туда — и каждая следующая итерация ухудшает положение. Не потому что модель глупая, а потому что ошибочные рассуждения получили вес и фонят на все последующие решения.
Что делать: reset, не retry
Я столкнулся с этим при построении Factory OS. Первые версии: Builder-агент делает ошибку → CEO просит исправить → Builder делает хуже → CEO просит ещё раз → катастрофа.
Решение оказалось контринтуитивным: не пытаться исправить, а начать заново с чистого контекста.
1. Правило трёх попыток
Если агент не справился за 3 попытки — не давать 4-ю. Вместо этого:
- Сохранить результат первой попытки (часто лучший)
- Породить нового агента с чистым контекстом
- Передать ему: задачу + конкретное описание ошибки (но не весь диалог с ошибками)
Новый агент не несёт бремя предыдущих ошибок. У него нет 500 токенов ошибочных рассуждений в контексте. Он начинает с нуля и идёт правильным маршрутом.
2. Separation of concerns: генерация ≠ исправление
В Factory OS Builder никогда не проверяет свой собственный код. Quality-агент — отдельный, с чистым контекстом. Он не видел процесс написания, не знает какие гипотезы были отвергнуты, не привязан к решениям Builder-а.
Это архитектурное решение, а не процессное. Один агент = один чистый контекст = нет confirmation bias.
3. Конкретный feedback вместо “исправь”
Когда исправление неизбежно (первые 3 попытки), feedback должен быть максимально конкретным:
Плохо: “Это неправильно, переделай” — модель будет гадать что неправильно, ссылаясь на весь предыдущий контекст.
Хорошо: “Строка 45: gross_profit должен быть 47.4M, а не 45.2M. Формула: revenue (120.5M) - COGS (73.1M) = 47.4M” — модель получает точный адрес ошибки и правильный ответ. Минимум простора для “интерпретации” из загрязнённого контекста.
4. Context window как ресурс
Контекстное окно — не бесконечный блокнот. Это ресурс, который расходуется. Каждое сообщение добавляет вес. Ошибочные сообщения добавляют отрицательный вес.
Практическое правило: если >30% контекста — ошибки и исправления, эффективность модели падает ниже 50%. Дешевле начать заново, чем продолжать.
Научный контекст
Это явление связано с несколькими исследованными феноменами:
Exposure bias (Ranzato et al., 2015) — модели, обученные на teacher forcing, плохо восстанавливаются после собственных ошибок во время инференса. Каждая ошибка увеличивает вероятность следующей.
Degeneration (Holtzman et al., 2019) — при длинной генерации модели склонны к повторению и зацикливанию. Контекст “заражается” повторяющимися паттернами.
Lost in the middle (Liu et al., 2023) — модели хуже используют информацию из середины длинного контекста. Ранние ошибки могут доминировать над поздними исправлениями просто по позиции.
Sycophancy (Perez et al., 2022) — модели склонны соглашаться с пользователем, даже если это противоречит их предыдущим ответам. Но при этом не могут полностью отбросить свои предыдущие рассуждения — получается внутренне противоречивый ответ.
Практические выводы
Для пользователей AI
- Новый чат > продолжение — если AI ошибся, часто быстрее начать новый чат с уточнённым запросом, чем исправлять
- Конкретика > объяснения — не объясняйте почему ошибка, а укажите что конкретно исправить
- Короткие сессии > длинные — через 20-30 сообщений качество падает, это нормально
Для разработчиков AI-продуктов
- Ограничивайте контекст — sliding window, project brief вместо полной истории
- Разделяйте агентов — генерация и проверка = разные контексты
- Max retries = 3 — после этого новый агент, не retry
- Мониторьте деградацию — если длина ответов растёт, а конкретика падает, контекст загрязнён
Для руководителей
AI — не сотрудник, которому можно дать задачу и через час проверить результат. AI — инструмент, который нужно направлять. Блестящий результат с первого раза → отлично. Ошибся → чистый лист, не “переделай”. Это не слабость AI. Это архитектурное свойство, с которым нужно работать, а не бороться.
Компании, которые это понимают, получают от AI в 10 раз больше, чем те, которые “просто дали подписку сотрудникам”.