Модель, с которой я работаю, в 100 раз меньше вашей, а мой ИИ-агент все равно отлично справляется

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

И здесь небольшое признание: окно в 131 тысячу — это не теоретический выбор. Модель, которая пишет у меня код, — это Qwen2.5-Coder-32B, открытая модель, которая работает у меня локально на одном A100, — она на порядки меньше моделей, с которыми вы общаетесь через API. Когда модель маленькая, у вас нет привилегии надеяться, что она «просто справится». Каждая ее слабость встречается с вами лицом к лицу, быстро и без службы поддержки, которая сгладит углы. И первая слабость — это арифметика начальной школы. Агент накапливает контекст с каждым действием — каждый прочитанный файл, каждый результат поиска, каждый вывод терминала накапливаются в окне — и задача не ограничена никаким размером.

Моим первым инстинктом инженера было сжатие. Я построил механизм, который сжимает каждое чтение файла — каркас объявлений плюс краткое содержание вместо полного контента — экономия от пяти до двадцати раз на чтение. Агент снова рухнул, чуть позже. Потому что сжатие улучшает константу, а проблема растет линейно. И нет, миллион токенов этого не решает. Я уже слышу первый ответ: «Для этого сегодня есть модели с окном в миллион». Верно. Давайте все же произведем расчет, который слайд пропустил. Контекстное окно, каким бы большим оно ни было, является константой. Контекст агента растет с каждым шагом, а задачи, которые мы даем агентам, растут еще быстрее — больший репозиторий, более долгое исследование, задача на день вместо часа. Миллион токенов отодвигает стену в восемь раз дальше. Впечатляет. Средний корпоративный монорепозиторий съедает этот разрыв до послеобеденной встречи.

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

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

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

Изменить алгоритм, а не ведро

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

Но расчет меняется в корне: 200 чтений файлов одним агентом — 300 тысяч токенов, крах. Пять под-агентов, каждый из которых читает сорок файлов и возвращает краткое содержание — двадцать тысяч токенов у «отца». Контекст главного агента ограничен количеством под-агентов, а не количеством файлов в репозитории. Асимптотическое изменение, а не улучшение константы — и совершенно безразличное к размеру окна. Со 131 тысячей или с миллионом, это работает одинаково. Стена просто перестает быть актуальной, без того, чтобы кто-то что-то обновил.

И это, кстати, единственный критерий, которому я действительно доверяю: та же модель, та же задача, с рычагом и без него. Три репозитория из вступления — те, что требовали 287, 513 и 633 тысячи токенов и падали — сегодня проходят от начала до конца, с той же самой моделью. И для тех, кто хочет цифру из источника, который не я: Anthropic опубликовали, что переход к архитектуре мульти-агентов улучшил у них показатели исследовательских задач более чем на 90 процентов по сравнению с одиночным агентом на тех же моделях.

Кастинг вместо промпта

Модель слепа? Наденьте на нее очки. Модель, которая пишет у меня код, полностью текстовая. Пользователь, который приложил скриншот визуального бага — сломанная кнопка, развалившаяся верстка — раньше получал ровным счетом ничего. Что я сделал вместо этого: я подключил крошечную отдельную модель зрения — Qwen2.5-VL-3B, в десять раз меньше модели кода — в качестве инструмента. Она получает изображение и возвращает структурированное описание — верстка, элементы, состояние, подозреваемые — и текстовый программист отлаживает UI на основе текста. Модель, которая не видит, исправляет визуальные баги.

Две проблемы, которые не исправляет ни один промпт, и чем меньше модель, тем они острее: у нее нет чувства завершенности и нет самокритики. Решение — кастинг. Те же самые веса работают у меня в нескольких ролях, которые режиссирует инфраструктура: исполнитель, который пишет код; проверяющий, который работает в абсолютно чистом контексте; и в критических задачах также скептик, который встает утром, чтобы найти изъяны. И решение «мы закончили» полностью вышло из рук модели — нет подтверждения от проверяющего, нет завершения. Модель, как аспирант, никогда не сдает работу, если ее не забрать силой.

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

Память — это проблема поиска

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

Веса — это товар, архитектура накапливается. Каждые полгода выходит «модель, которая меняет правила игры», и каждый январь объявляется «годом агентов». Тем временем обратите внимание, что общего у всего, что я описал: ни один рычаг не требует более умной модели, и ни один из них не выбрасывается в мусор, когда выходит новая модель. Новая модель поднимает пол; архитектура поднимает потолок. И инвестиции в нее, в отличие от модели, которая меняется каждые полгода, накапливаются. Поэтому, когда выходит новая модель, я, конечно, скачиваю и проверяю, как и все — моя зависимость не отличается от вашей, я просто плачу за нее электричеством. Но я больше не спрашиваю «насколько она умна». Я спрашиваю, как далеко моя инфраструктура ее занесет.

Иегуда Нойман — CTO и главный архитектор PAIS.