Почему ИИ-агент тупеет на большом проекте

Представьте ситуацию: еще вчера ваш ИИ-агент писал новые API за пару минут, делал рефакторинг и находил ошибки точно под микроскопом. Но проект растет: появляются десятки новых микросервисов, сотни тысяч строк кода и куча библиотек. И наступает тот самый момент, когда ИИ начинает вести себя странно.

Агент забывает, что было пять минут назад, предлагает удалить сто раз проверенную функцию и генерирует код, который противоречит архитектуре. Здесь многие разработчики подумают: «модель совсем испортилась», но проблема не в модели, а в контексте.

Современные LLM устроены так, что качество ответа зависит не только от модели, но и от того, какую информацию она получает в запросе. Поэтому по мере увеличения кодовой базы самым сложным для модели становится управление контекстом. Уже даже появился термин — context engineering (передаем привет промт-инжинирингу), и сейчас команды, работающие над агентами, все больше внимания уделяют правильному формированию контекста.

В статье рассказываем, почему теперь недостаточно просто написать хороший промпт.

Контекстное окно — не равно память

Многие разработчики воспринимают контекстное окно как память модели, но это не совсем так. У LLM нет долговременной памяти в привычном смысле. При каждом запросе модель получает некоторый объем информации: промтп, историю диалога, файлы, ссылки, сообщения пользователя и найденные в поиске части кода. Это превращается в последовательность токенов, которая называется контекстным окном.

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

Если нужного файла нет в контексте — для модели он буквально не существует.

Размер окна — не единственная проблема

В базовой модели ChatGPT 5 — 16 000 токенов, в платных число доходит до 400 000. Если вы используете API-платформы, такие как RouterAI, то вам доступен 1 млн токенов — это примерно 750 000 слов. Вот как модели переводят слова в токены:

Действительно, миллион токенов — огромное количество, но есть важный нюанс: возможность прочитать миллион токенов совсем не означает, что модель способна одинаково хорошо использовать каждую их часть. Это подтверждает исследование Lost in the Middle 2023 года: авторы показали, что модели с большим контекстом лучше всего обрабатывают информацию, которая находится в начале или конце входного текста, а то, что в середине, можно сказать, ей упускается.

Например: агент получил 150 файлов проекта, логи, документацию, описание задачи, результаты. Формально вы положили в контекст все нужные входные данные, но далеко не факт, что модель одинаково обработает каждые из них. Считайте, что в этот момент она ищет иголку в стоге сена.

Почему большие проекты особенно сложные

Если текстовый файл обычно читается последовательно, то код — нет. Чтобы изменить один метод в бэке, агент будет искать информацию по самым разным частям репозитория, поскольку UI может лежать в одном пакете, реализация — в другом, а бизнес-логика и вовсе распределена между несколькими сервисами, и ещё, конечно, тесты.

Здесь важно учитывать, что разработчик выстраивает архитектуру и карту проекта постепенно (и зачастую не в одиночку), а модель вынуждена анализировать ее практически мгновенно. Следовательно, чем больше проект, тем выше вероятность того, что важная зависимость банально не попадет в текущий контекст. Именно поэтому агенты начинают использовать старый UI, дублировать код, нарушать архитектуру или генерировать ломающие друг друга изменения.

Вам может показаться, что агент стал менее сообразительным и перестал вас понимать, но на самом деле он перестал видеть достаточно информации для правильной реализации того или иного решения.

«Так я могу взять и загрузить весь репозиторий»

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

Но самая неприятная проблема — информационный шум, который создается при большом контексте. Представьте: перед код-ревью вам дали не один пакет или pull request, а весь репозиторий — вы потратите на это огромное количество сил и времени. С ИИ происходит примерно то же самое.

Как бороться с деградацией контекста

Может показаться, что современные AI-инструменты научились работать с огромными репозиториями — этим славятся GitHub Copilot, Claude и Cursor. Но на самом деле мало кто пытается загрузить в модель репозиторий целиком — поскольку важнее не размер контекстного окна, а качество информации. Именно поэтому нужно знать несколько архитектурных приемов.

Chunking

Это первый и самый очевидный прием: вместо хранения одного репозитория в виде одного огромного текста его заранее разбивают на смысловые фрагменты (chunks).

Казалось бы, все просто — разбить код по фиксированному количеству строк. Например, у вас 400 строк кода, которые можно разрезать по 100, но такой путь с большой вероятностью окажется ложным, поскольку смысловые фрагменты могут отделиться друг от друга, и модель получит две бессмысленные половины.

Поэтому в современных инструментах есть структурный чанкинг. В нем границы определяются элементами синтаксического дерева (AST — Abstract Syntax Tree): классом, функцией, UI, модулем, SQL-запросом и т.д. Такой подход позволяет сохранить логическую целостность кода.

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

И здесь на помощь приходит RAG.

Retrieval Augmented Generation

Сейчас RAG чаще ассоциируют с чат-ботами, которые ищут ответы в документации. Но принцип работает абсолютно так же и для кода.

Вот пример классической архитектуры:

То есть модель вообще не знает о существовании большей части репозитория. Она видит только те части проекта, которые поисковый механизм признал наиболее полезными. Поэтому именно качество поиска влияет на итоговую выдачу сильнее, чем выбор самой LLM.

Если в процессе retrieval нашлись не правильные файлы, даже GPT-5, Claude 4 или Gemini 2.5 будут уверенно рассуждать на основе неверных данных. Поэтому современные агенты все больше напоминают поисковые системы, а не просто оболочку вокруг LLM.

Но есть еще одна проблема. Например, агент анализирует задачу уже полчаса, за которые он изучил десятки файлов, сделал поисковые запросы, протестировал, сгенерировал новые модули и даже успел что-то спросить у пользователя. Все эти данные тоже начинают занимать место в контекстном окне и история диалога становится слишком большой. И здесь на помощь приходит суммаризация.

Суммаризация

Сейчас один из самых популярных методов — иерархическая структуризация. Вместо того, чтобы хранить всю историю переписки, агент периодически делает краткое описание, освобождая контекстное окно:

Реализовал новую версию UserRepository, обновил миграцию, синхронизировал тесты с новой схемой.

Сегодня агенты используют несколько уровней суммаризации: отдельного файла, задачи, проекта, предыдущих запросов и так далее.

Именно поэтому разработчики сейчас так любят Claude — создатели не просто сделали огромное контекстное окно, а пошли дальше и научили нейронку динамически искать файлы, повторно читать код при необходимости, автоматически сокращать контекст и копить знания. Получается, что модель постоянно собирает информацию под конкретную задачу.

Схема работы кодового агента

Когда большой контекст необходим

Вот основные кейсы, когда переход на модель с большим контекстным окном полностью оправдан:

• Большой рефакторинг. Например, команда решила перейти с одной библиотеки на другую, а код лежит в нескольких сотнях файлов. Модели нужно одновременно понимать старую архитектуру и предложить новую реализацию, которая не сломает приложение. В этом случае большой контекст поможет снизить количество итераций поиска.
• Монорепозитории. В крупных компаниях, например, в Google, один репозиторий может содержать десятки и даже сотни сервисов. Даже при точном поиске ограниченность узкого контекстного окна будет большой проблемой.
• Генерация больших изменений. Суть примерно та же самая, что и с рефакторингом: модель должна переписать кучу файлов, сохранить единый стиль, не нарушить связи и обновить тесты — большой контекст просто поможет удерживать всю информацию о задаче.

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

Что делать, если одной модели недостаточно

Если мы говорим о повседневных задачах, например, автодополнение кода или написание небольшой функции, то здесь важнее будет стоимость и скорость ответа, поэтому часто модели с небольшим контекстом будет достаточно.

Но в случае большого рефакторинга, монорепозиториев и других крупных проектов, где необходимо сохранить длинную историю диалога, нужен большой контекст. Поэтому многие команды внедряют архитектуру, в которой модель можно заменить без переписывания логики. Так, если сегодня вы сидите на Claude, а завтра GitHub выпустит прорывную модель, переключение должно занять минуты и затронуть как можно меньше кода.

Именно по этой причине сейчас появляется много сервисов, которые предоставляют единый доступ к различным моделям через API. Например, в RouterAI можно переключить агента на другую модель с большим контекстным окном, не меняя клиентский код и интеграцию с API. Это не решает проблему формирования контекста автоматически, но заметно упрощает эксперименты с разными моделями и позволяет выбирать инструмент под конкретный сценарий, а не подстраивать приложение под особенности каждого отдельного провайдера.

Итоги

Когда разработчикам кажется, что модель начинает «глупеть», проблема часто не в самой LLM, а в контексте, с которым она работает. И сейчас качество определяется не только количеством токенов, но и тем, как устроены RAG, суммаризация, чанкинг, а главное — поиск. Таким образом, нужно прокачивать и промпт-инжиниринг, и контекст-инжиниринг, чтобы научить модель видеть именно то, что необходимо для решения конкретной задачи.