Оптимизация контекста ИИ-агентов: как снизить стоимость сессии в пять раз

Habr AI · оригинал

Материал подготовлен автоматизированной редакционной системой. Факты можно сверить по указанному первоисточнику.

Разработчик описал эксперимент по оптимизации работы ИИ-агента, который позволил снизить стоимость 30-шагового сценария с 48 до 8 рублей за счет локального хранения данных и динамической загрузки контекста. Однако тесты на реальных коротких задачах показали, что такие механизмы могут увеличивать расходы, требуя адаптивного подхода к включению оптимизаций.

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

В работе с ИИ-агентами одной из главных статей расходов становится повторная передача контекста модели. Поскольку большинство LLM API не имеют встроенной памяти, клиент вынужден каждый раз отправлять всю историю диалога, включая логи, результаты инструментов и схемы вызовов. Разработчик описал ситуацию, когда на 30-м шаге сценария входной запрос достигал 123 856 токенов, а общая стоимость сессии составляла 48,26 рубля. Основная проблема заключалась в том, что значительная часть данных уже была обработана ранее, но продолжала «ездить» в модель, увеличивая затраты без необходимости.

Для решения этой задачи автор разработал комплексный подход, включающий несколько механизмов. Ключевым элементом стал локальный архив: полные результаты инструментов оставались на компьютере пользователя, а в запрос к модели попадало лишь краткое описание и ссылка на оригинал. Если детали требовались, агент мог запросить их через специальный инструмент. Дополнительно были внедрены загрузка схем инструментов по требованию, создание «скелета» сессии (оглавления действий) и локальная песочница для вычислений, чтобы модель не читала большие файлы целиком.

Результаты синтетического теста оказались впечатляющими. На том же 30-шаговом сценарии использование полного набора оптимизаций снизило количество входных токенов на 82,56%, а стоимость — до 8,40 рубля. При этом качество работы не пострадало: агент успешно решил все 30 задач и прошел все проверки памяти, в то время как контрольный вариант без оптимизаций справился лишь с 25 из 30.

Однако автор подчеркивает важность критического взгляда на эти цифры. Тест проводился на синтетическом стенде, где инструменты подставлялись сценарием, а не выбирались агентом. В реальных условиях агент может совершать ошибки, делать лишние запросы или неправильно использовать механизмы оптимизации. Более того, на коротких задачах накладные расходы самих механизмов (служебные ссылки, метаданные) могут превышать экономия. Живой тест на легкой сессии показал, что оптимизированный вариант потребовал больше токенов и обращений, чем прямой.

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