Архитектура агентов — это задача распределения вычислительных ресурсов
Три независимые группы недавно пришли к одному и тому же выводу в области проектирования ИИ-агентов.
Anthropic опубликовала пост в блоге о стратегии «советника» (advisor strategy). Они используют дешевую модель для выполнения основного цикла. Дорогая модель вызывается только тогда, когда дешевая заходит в тупик. Такая конфигурация в BrowseComp позволила достичь точности 41,2%, затратив при этом всего 15% от стоимости использования топовой модели для всех задач.
Тоби Лютке из Shopify поделился похожей схемой в X. Он запускает локальную модель для исследований и использует передовую (frontier) модель в качестве советника. Разработчики создали open-source версии этого подхода всего за несколько часов.
HazyResearch опубликовала статью о фреймворке «компрессор-предиктор» (compressor-predictor). Маленькая модель дистиллирует контекст, чтобы большая модель могла провести рассуждения. Их система восстановила 99% точности, затратив лишь 26% от стоимости.
Это схождение не случайно. Оно следует определенному закону проектирования: принципу кривой затрат (cost-curve frame).
Я обосновывал этот принцип на трех уровнях в этой серии материалов:
- Уровень 1 (Retrieval): Почему циклы с инструментами (tool-loops) эффективнее RAG в большинстве задач по написанию кода.
- Уровень 2 (Storage): Почему SQLite лучше векторных баз данных для графов символов.
- Уровень 3 (Orchestration): Почему стратегия «советника» выигрывает при выборе модели.
Логика та же: большинство задач агента состоят из множества низкоценных операций и лишь немногих высокоценных решений.
Если вы используете дорогую модель для каждого токена, вы тратите деньги впустую на рутинную работу, такую как чтение контекста или форматирование текста. Стратегия «советника» разделяет эти пути. Вы используете дешевого исполнителя (executor) для основной работы и дорогого советника только для критически важных точек принятия решений.
Если вы создаете агентов, обратите внимание на эти три инженерные проблемы:
- Исходящие данные (Data Egress): Отправка контекста удаленному советнику может привести к утечке конфиденциальных данных. Используйте слой маскирования (redaction layer).
- Политика эскалации (Escalation Policy): Решение о том, когда именно вызывать советника, — задача непростая. Слишком ранний вызов тратит деньги. Слишком поздний — тратит время.
- Проектирование передачи задач (Handoff Design): Советник должен предоставлять краткий план, а не полное решение.
Этот паттерн реален, потому что он эффективен. Перестаньте платить по тарифам frontier-моделей за токены, которые в этом не нуждаются.
Optional learning community: https://t.me/GyaanSetuAi