[nevr]
· 12 мин чтения

AI идёт в разнос: почему чем дольше разговор, тем хуже результат

Error chain growing in context

Вот ситуация, которую видел каждый, кто работает с AI: модель делает ошибку. Вы указываете на ошибку. Модель извиняется и делает другую ошибку. Вы объясняете подробнее. Модель генерирует что-то совсем странное. Через 10 итераций вы получаете результат хуже, чем был на первом шаге.

Это не баг конкретной модели. Это фундаментальное свойство архитектуры transformer. И понимание этого свойства — разница между “AI бесполезен” и “AI — мой самый мощный инструмент”.

Почему AI не может признать, что ошибся

Языковая модель не “думает”. Она генерирует наиболее вероятный следующий токен на основе всего контекста — системного промпта, истории разговора, вашего последнего сообщения.

Ключевое слово — всего контекста. Когда модель делает ошибку и эта ошибка попадает в историю, она становится частью контекста. У неё появляется вес.

Attention bias: ошибка как якорь

Механизм self-attention в transformer работает так: каждый токен “смотрит” на все предыдущие токены и решает, какие из них релевантны. Ошибочный ответ модели — это десятки или сотни токенов, которые теперь навсегда в контекстном окне.

Когда вы просите “исправь ошибку”, модель видит:

  1. Ваш исходный запрос
  2. Свой ошибочный ответ (полный, развёрнутый, уверенный)
  3. Вашу поправку (короткая, одно предложение)

По объёму ошибочный ответ может быть в 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

  1. Новый чат > продолжение — если AI ошибся, часто быстрее начать новый чат с уточнённым запросом, чем исправлять
  2. Конкретика > объяснения — не объясняйте почему ошибка, а укажите что конкретно исправить
  3. Короткие сессии > длинные — через 20-30 сообщений качество падает, это нормально

Для разработчиков AI-продуктов

  1. Ограничивайте контекст — sliding window, project brief вместо полной истории
  2. Разделяйте агентов — генерация и проверка = разные контексты
  3. Max retries = 3 — после этого новый агент, не retry
  4. Мониторьте деградацию — если длина ответов растёт, а конкретика падает, контекст загрязнён

Для руководителей

AI — не сотрудник, которому можно дать задачу и через час проверить результат. AI — инструмент, который нужно направлять. Блестящий результат с первого раза → отлично. Ошибся → чистый лист, не “переделай”. Это не слабость AI. Это архитектурное свойство, с которым нужно работать, а не бороться.

Компании, которые это понимают, получают от AI в 10 раз больше, чем те, которые “просто дали подписку сотрудникам”.


Factory OS: как я управляю AI-агентами | nevr@aicpo.com