Сделают ли более умные модели менее необходимыми инструменты для агентов или сделают их ещё более важными?

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

Что такое harness и чем он не является

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

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

Чтобы узнать подробнее о том, как распределяются обязанности между моделью и инструментальной средой в одном агенте, ознакомьтесь с статьей о том, откуда на самом деле берётся надёжное поведение ИИ. Здесь рассматривается, как меняется это распределение со временем.

Аргументы в пользу более простой инструментальной среды

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

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

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

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

Расширение возможностей — расширение сферы применения

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

• Модель, способная кратко обобщить один документ, вскоре будет прослежена оценить сотню документов.
• Модель, умеющая написать один SQL-запрос, будет прослежена решить бизнес-задачу, затрагивающую несколько систем.
• Модель, способная вызвать один API, получит в своё распоряжение целую программную среду.

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

Способные агенты ставят системные вопросы

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

• Какие действия разрешено совершать агенту?
• Какую информацию он может читать?
• Когда ему необходимо запрашивать разрешение?
• Что происходит, если инструмент выходит из строя?
• Как предотвратить циклы и дублирование действий?
• Как кто-либо может восстановить причины принятия агентом определенного решения?
• Как оценивать рабочий процесс, который длится 30 минут, вместо того чтобы предоставить один ответ?
• Что происходит, если модель ошибается, но уверена в своем решении?

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

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

• Инструменты: с чем может взаимодействовать агент.
• Контекст: какая информация ему показывается.
• Состояние: что он запоминает между шагами.
• Разрешения: что ему разрешено изменять.

Обратная связь: способ, с помощью которого модель понимает, что что-то пошло не так.

Оценка: способ измерения успеха.

Границы: момент, когда модель должна остановиться или передать управление человеку.

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

Сложность склонна к изменению, а не к исчезновению

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

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

В некоторых аспектах менее важно, в других — более

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

Примерный ход развития выглядит следующим образом:

• Ранее: модель была подключена почти напрямую к приложению.
• Сейчас: модель находится между промптами, технологиями RAG, инструментами, агентами и механизмами оценки перед тем, как попасть в приложение.
• В будущем: модель и фреймворк вместе образуют автономную систему.

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

Практический тест для вашего собственного решения

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

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

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

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

Основные выводы

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