Использование искусственного интеллекта в работе писателя позволило сократить расходы на токены почти на 40% — без ущерба для точности.

Бен Диксон

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

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

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

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

Кризис рентабельности инвестиций в токен-максинг

Современное состояние разработки ИИ страдает от «токенмаксинга» — отраслевой тенденции, когда разработчики полагаются на огромные контекстные окна и перебор токенов в качестве замены качественного проектирования системы.

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

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

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

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

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

• Функция сжатия входного текста сжимает его для экономии места, но игнорирует последовательность ввода данных в сложных рабочих процессах.

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

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

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

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

Разбираем систему рычагов: механизмы повышения эффективности

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

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

Как отмечают исследователи из Writer в своем исследовании: «Если система управления — это слой, который преобразует запросы моделей в работу, то это также слой, который устанавливает цену работы».

Исторически сложилось так, что разработчики рассматривали тестовый модуль как одноразовый связующий код, предназначенный просто для соединения API с пользовательским интерфейсом. Исследование показывает, что теперь тестовый модуль следует рассматривать как первоклассный объект: основной программный артефакт, требующий собственного тестирования, версионирования и тщательной разработки.

Для предприятий это меняет смысл решения «собственность или аренда».

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

Внутри экспериментов

Чтобы изолировать влияние уровня оркестровки, исследователи провели эксперименты на шести базовых моделях от разных производителей и с разными весовыми категориями: Claude Sonnet 4.6, Gemini 3.1, Gemini Flash 3.5, Qwen 3.6, GLM 5.1 и собственной модели Writer, Palmyra X6.

В своих экспериментах они сравнивали замороженный, стандартный цикл работы производственного агента с готовым набором инструментов Writer Agent Harness на тех же 22 заблокированных корпоративных задачах, охватывающих такие возможности, как привязка и извлечение данных, многоэтапные рабочие процессы, использование инструментов и генерация контента. Сохраняя модели и задачи неизменными, они смогли изолировать влияние самого уровня оркестрации.

Оптимизация системы привела к значительному снижению затрат, уменьшив совокупную стоимость одной задачи на 41%, с 21 цента до 12 центов. Этого удалось достичь в основном за счет сокращения потребления токенов: количество токенов на задачу уменьшилось на 38%, с 14,2 тыс. до 8,8 тыс.

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

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

Задержка выполнения задачи от начала до конца также значительно снизилась, уменьшив среднее время выполнения на 44%, с 48 секунд до 27 секунд, благодаря кэшированию подсказок и устранению тупиковых циклов рассуждений.

Однако исследователи также обнаружили ограничения в управлении несколькими агентами. Более компактные модели, такие как Gemini Flash 3.5 и Qwen 3.6, показали результаты значительно ниже приемлемого порога надежности в задачах делегирования полномочий субагентам (0,45 и 0,42 соответственно) — эта возможность пока просто не является надежной для более легких моделей.

Надежность работы суб-агентов превысила приемлемый порог только у двух самых мощных протестированных моделей: собственной модели автора Palmyra X6 (0,86) и модели Клода Соннета 4.6 (0,85).

Руководство для разработчиков: практические выводы и компромиссы.

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

Структура для кэширования системных подсказок (двухзонная подсказка): Современные API LLM предлагают кэширование подсказок, но разработчики должны правильно структурировать свои полезные нагрузки, чтобы его активировать. Разработчики должны разделить «стабильную зону» от «изменчивой зоны». Статические, неизменяемые элементы (например, основные правила, большие схемы инструментов и стандартные операционные процедуры) размещайте в верхней части подсказки. Динамические элементы, такие как конкретный запрос пользователя или недавнее состояние задачи в разговоре, должны быть добавлены в нижнюю часть. Такой порядок позволяет системе повторно использовать кэшированный префикс в сотнях вызовов. «Это единственное разделение обеспечивает реальную работу кэширования подсказок и предотвращает повторную оплату одних и тех же инструкций на каждом из тридцати шагов агента», — сказал Аль-Ших.

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

Создавайте отказоустойчивые циклы и пересматривайте KPI: неуправляемые циклы работы агентов быстро истощают бюджеты API. Команды должны начать отслеживать количество завершенных операций на миллион токенов (CPM), чтобы понимать реальную стоимость задач, но сама система должна содержать физические ограничители. «Основной принцип заключается в том, что вы никогда не просите модель контролировать свои собственные расходы», — сказал Аль-Ших. «Ограждение должно находиться под моделью, в коде, на вашей стороне API». Это требует трех жестких проверок:

• Жесткие ограничения на количество токенов для каждой задачи: выполнение задачи завершается по истечении лимита, без исключений.

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

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

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

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

Будущее использования корпоративных технологий

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

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

«В модель никогда не попадает „разрешенное“: бюджеты, разрешения, границы данных, журналы аудита, детерминированные механизмы аварийного отключения», — сказал Аль-Ших. «Через пять лет эта система станет тоньше, но важнее. Будет меньше вспомогательного оборудования и больше управления. Какими бы функциональными ни стали возможности модели, кто-то извне все равно должен определять, на что она может тратить, что может видеть и к чему может прикасаться. Этот уровень принадлежит предприятию, и его никогда не следует арендовать».

Источник: venturebeat.com