Автор статьи на Хабре — инженер, полгода работающий с AI-агентами — задался вопросом: почему агенты начинают тупить, галлюцинировать и нарушать правила именно на длинных сессиях? Ответ он нашёл не в «плохих моделях», а в фундаментальных свойствах трансформеров, задокументированных в девяти публичных исследованиях. И в обновлённых гайдах OpenAI и Anthropic, которые говорят одно и то же: начинайте с минимального промпта.
Контекст
Разговор начался после статьи про Cursor и сжатие контекста. В комментариях завязался спор: виноват компактинг? Attention dilution? Alignment? Проблема в том, что у большинства практикующих инженеров нет целостной картины — они видят симптомы (агент удалил базу, точность упала, модель галлюцинирует), но не понимают механизм.
Ключевые работы здесь — Liu et al. (2023) «Lost in the Middle», Du et al. (2024) «Context Length Alone Hurts LLM Performance Despite Perfect Retrieval» и Turpin et al. (2023) о природе Chain-of-Thought. Плюс свежие гайды от OpenAI и Anthropic, вышедшие для их новейших моделей.
Контекст проблемы шире одного инструмента. Cursor, Claude Code, любой agentic-фреймворк с компактингом — все они сталкиваются с одним и тем же: длинный контекст создаёт шум, который модель не может отфильтровать даже при идеальном поиске нужной информации.
Аналитика
Самый важный результат — Du et al. (2024). Авторы проверили: если модель идеально находит нужную информацию в длинном контексте, поможет ли длина? Нет. Производительность падает на 13,9%–85% только от увеличения длины входа — даже когда нерелевантный контекст заменён пробелами, а вся нужная информация расположена прямо перед вопросом. Контекст сам по себе источник шума.
Chain-of-Thought добавляет иллюзию прозрачности. Turpin et al. (2023) и Lanham et al. (2023) показали: CoT — это пост-хок нарратив, не трассировка реального решения. Модель меняет ответ под влиянием подсказок в контексте, а затем генерирует убедительное объяснение, никак не связанное с реальной причиной. Когда агент пишет «я нарушил правила, извините» — это не рефлексия, это озвучка.
Liu et al. (2023) зафиксировали U-образную кривую внимания: информация в начале и конце контекста обрабатывается хорошо, в середине — плохо. Компактинг через суммаризацию сохраняет факты, но теряет логические связи между ними. «Агент подключился к API» может оказаться в сжатом контексте, а связка «пароль взят из config.yml» — нет. Через 10 шагов агент не знает, откуда взялись его учётные данные.
Кейсы применения в бизнесе
B2B-SaaS стартап с AI-агентами в продукте. Если агент работает в многошаговых сессиях (онбординг, техподдержка, CRM-обновления), важнейшее изменение — ввести принцип «recite before solve»: перед каждым ответом агент коротко пересказывает релевантный контекст, а потом действует. Du et al. показали, что это даёт измеримый прирост точности. Плюс — перейти на validate-then-repair в обвязке: вместо расширения промпта добавить слой исправления типовых ошибок tool calls.
Корпорация с RAG-системой на legacy-данных. Типичная ошибка — накачивать модель максимальным числом фрагментов из базы, надеясь повысить точность. Это прямо противоречит результатам Du et al. Правильный подход: топ-3 фрагмента, отранжированных по релевантности, а не топ-20. Меньше токенов — выше точность при том же retrieval-качестве.
SMB в Кыргызстане или СНГ, внедряющий ИИ-ассистента. При ограниченном бюджете важно не раздувать системный промпт инструкциями «на все случаи». Начать с минимального промпта (как рекомендует OpenAI: «Start with the smallest prompt that preserves the product contract»), отслеживать реальные ошибки и дополнять только под конкретные паттерны сбоев.
Кейсы в личной жизни
Разработчик, работающий с AI-агентами. Если агент систематически делает одни и те же 4–5 ошибок в tool calls — скорее всего, проблема в обвязке, а не в модели. Автор статьи реализовал validate-then-repair для DeepSeek V4 Pro и получил результат: модель обходит Claude Opus 4.7 в 6 из 10 случаев на своих эвалах. Без изменения модели — только смена архитектуры обвязки.
Контент-мейкер или фрилансер, активно использующий Claude или GPT. Если точность ответов падает в длинном диалоге — не добавляйте уточнений в тот же чат. Начните новый с компактным системным промптом и только нужным контекстом. Это прямое следствие «Lost in the Middle»: свежий короткий контекст даст лучший результат, чем длинная история с правильными фактами в середине.
Студент или аналитик, работающий с длинными документами. Попробуйте технику «recite before answer»: попросите модель сначала выписать ключевые факты из документа коротко, а затем ответить на вопрос. На бенчмарке RULER это дало +4% к GPT-4o. На практике разница ощущается на сложных многоступенчатых запросах.
Как применить сегодня
- Начните с минимального промпта. OpenAI прямо пишет: «Start with the smallest prompt that preserves the product contract». Добавляйте контекст только если без него явно хуже.
- Recite before solve. В системном промпте агента добавьте инструкцию: перед ответом на сложный вопрос — сначала перечислить релевантные факты из контекста коротко, потом отвечать.
- Validate-then-repair в обвязке. Не расширяйте промпт для борьбы с типовыми ошибками tool calls — добавьте слой постпроцессинга, который исправляет известные паттерны (null вместо пропуска, строка вместо массива и т.д.).
- Не доверяйте CoT как доказательству. Убедительное рассуждение агента — не подтверждение правильности его решения. Проверяйте результат, а не объяснение.
- Следите за телеметрией ошибок. Логируйте, на каких парах (модель + инструмент) чаще срабатывает repair — это укажет, где обвязка слабее всего.
«The sheer length of the input alone can hurt LLM performance, independent of retrieval quality and without any distraction» — Du et al. (2024)