Постоянные ИИ-агенты на практике: затраты, отклонение памяти и проблема 80%.

Примерно два года стандартным способом использования модели был диалог. Вы вводите сообщение, читаете ответ, затем используете его или спорите с ним. Вы находитесь в цикле и проверяете каждый результат перед тем, как он попадёт куда-либо дальше. Затем подход изменился: перестали вводить промпты, начали использовать агентов, которые работают самостоятельно, имеют память, инструменты и разрешение выполнять задачи без постоянного наблюдения на каждом этапе. Попробуйте это в течение недели с агентами, которые читают код, выполняют команды и открывают pull-requests — в некоторых случаях этот подход срабатывает. Однако во многих случаях он не срабатывает. Сбои проявляются в довольно предсказуемом порядке.

Почему люди отказались от промптов

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

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

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

Счёт

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

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

Другим риском является неуконтролируемое увеличение затрат. Цикл, который постоянно пытается выполнить что-то, что не может увенчаться успехом, продолжает формировать счета. Ходят истории о компаниях, которые получили счета на полмиллиарда долларов именно из-за такой ситуации. Независимо от того, точны ли эти цифры, вполне вероятно, что один некорректно настроенный агент может потратить всю ежедневную сумму бюджета на десятиминутную ручную задачу. Наиболее тревожным является то, что всё кажется в порядке во время выполнения задачи: агент работает, просто делает круги.

Решение, которое оказалось эффективным на практике, состоит из трех компонентов:

• Четкий ежедневный бюджет для каждого агента, контролируемый вне самого агента
• Динамическое окно контекста, благодаря которому более ранние шаги удаляются и не накапливаются
• Передача рутинных задач дешевой модели, а только сложные случаи — более мощной

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

Первый pull request — это уловка

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

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

Это часто называют проблемой 80%. Инструменты обеспечивают выполнение очевидных 80% требований, но постоянно упускают 20%, включающие нефункциональные требования, сценарии сбоев и архитектурную целостность, поскольку для этого 20% нужен контекст, которого у инструментов нет. Они создают код, который запускается, а не код, который будет работать долго.

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

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

Память бывает двух видов

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

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

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

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

Задачи разработчика изменились

Сам разработчик не исчез. Просто его задачи переместились, и результат оказался менее драматичным, чем предполагали как сторонники, так и критики.

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

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

Под всем этим скрывается сдержанная язвительность. Одно исследование измеряло время работы разработчиков над реальными проектами и обнаружило, что они работают примерно на 19% медленнее, хотя сами считали, что быстрее на 20%. Ощущение скорости и реальная скорость оказались разными вещами. Постоянные агенты увеличивают эту разницу, когда им это позволяется, поскольку они отлично умеют создавать иллюзию скорости. То, что сужает эту разницу, — это простое, но необходимое: регулирование, проверка, спецификация, соответствующая реальности, и лимит на расходы.

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