Меня зовут Александр, я COO в SaaS-платформе аналитики данных. Последний год активно изучаю внедрение AI-решений в кросс-функциональные процессы. Делюсь полезными материалами, которые считаю стоят внимания. В основном про AI, изменение процессов, тренды и продуктовое видение.

У себя в телеграм-канале делюсь сжатыми и структурированными саммери статей. 

Статья на основе презентации от Sayash Kapoor (соавтор книги и популярного блога «AI Snake Oil», один из самых влиятельных людей в сфере ИИ по версии TIME), очень наглядно и точно открывает проблемы, которые стоят перед AI-агентами и AI-инженерами. Очень рекоменду к чтению/просмотру.

Проблемы оценки эффективности AI-агентов

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

Существует несколько десятков определений AI-агентов. Одно из них гласит, что это системы, где языковые модели управляют потоком работы. Фактически, даже когда люди по наивности рассматривают ChatGPT и Claude просто как модели, эти инструменты уже являются примерами рудиментарных агентов — у них есть входные и выходные фильтры, они могут выполнять определённые задачи, вызывать инструменты и так далее.

В некотором смысле агенты уже широко используются и показывают успешные результаты. Мы видим мейнстримные продукты, способные на гораздо большее: OpenAI o1 может выполнять открытые задачи в интернете, Deep Research Tool может создавать 30-минутные отчёты практически на любую тему.

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

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

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

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

В реальности пару лет спустя, фактически совсем недавно, FTC оштрафовала DoNotPay на сотни тысяч долларов. Причина штрафа — заявления о производительности, которые делала компания, оказались полностью ложными.

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

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

Мы также слышали о примерах AI-агентов, которые скоро автоматизируют все научные исследования. Вот пример стартапа Sakana.ai. Sakana заявляла, что создала "исследователя-учёного", способного полностью автоматизировать открытые научные исследования.

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

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

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

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

Позже Sakana выдвинула ещё одно утверждение о создании агента для оптимизации CUDA-ядер. Заявления были действительно впечатляющими — якобы их система могла обеспечить 150-кратное улучшение по сравнению со стандартным CUDA-ядром, которое поставляется с PyTorch.

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

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

Ограничения статических бенчмарков

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

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

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

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

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

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

В Принстоне мы разработали лидерборд агентов, который пытается решить некоторые из этих проблем. В частности, для CoreBench, о котором я упоминал ранее, можно оценить несколько агентов с учётом стоимости и точности. На этом графике фронта Парето вы видите агентов вроде Claude 3.5, который набирает столько же, сколько модели OpenAI o1, но модель Claude стоит $57 для запуска, тогда как o1 — $664.

Даже если бы производительность OpenAI o1 была на несколько процентных пунктов выше (чего, кстати, в данном случае нет), для большинства AI-инженеров выбор очевиден — вы бы в любой день недели выбрали модель, которая стоит в 10 раз меньше, но работает примерно так же хорошо.

В ответ на это двумерное представление Парето меня часто спрашивают: "Разве LLM не становятся слишком дешёвыми для измерения? Зачем вообще заботиться о стоимости запуска агента, если стоимость создания этих моделей стремительно падает?"

Действительно, за последние годы стоимость резко снизилась. Если сравнить text-davinci-003, модель OpenAI 2022 года, с сегодняшней GPT-4o mini, которая в большинстве случаев превосходит эту старую модель, стоимость упала более чем на два порядка. Но если вы создаёте приложения, которым нужно масштабироваться, этот подход всё ещё довольно дорог, особенно с точки зрения выпуска прототипов. Один из барьеров для инженеров — необходимость итераций в открытом режиме, и если вы не учитываете стоимость, ваш прототип может быстро обойтись в тысячи долларов.

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

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

Как мы можем автоматизировать всё это? С помощью Holistic Agent Leaderboard (HAL) мы разработали способ автоматического запуска оценок агентов уже на 11 различных бенчмарках, и в планах ещё много новых.

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

Например, Cosin привлёк посевной раунд финансирования на основе своих результатов в S-bench. Фактически, разработчик агентов Cognition привлёк $175 миллионов при оценке в $2 миллиарда, в основном благодаря тому, что их агент хорошо показал себя в S-bench.

К сожалению, производительность на бенчмарках очень редко переносится в реальный мир. Вот отличный анализ работы Devin (агент, разработанный Cognition) от весьма впечатляющих специалистов из Answer. Вместо того чтобы полагаться на стандартные бенчмарки, они действительно попытались интегрировать Devin в реальный мир. Они обнаружили, что за месяц использования для 20 различных задач он был успешен только в трёх из них.

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

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

Разрыв между возможностями и надёжностью

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

Грубо говоря, возможности означают то, что модель может делать в определённые моменты времени. Для технически подкованных слушателей это означает точность "pass@k" модели при очень высоком K, то есть один из K ответов, которые выдаёт модель, является правильным.

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

В частности, я считаю, что методы обучения моделей, которые позволяют достичь 90% (что, по словам специалистов, является работой инженера машинного обучения), не обязательно позволяют достичь 99,999%, что часто называют "пятью девятками" надёжности. Устранение этого разрыва между 90% и 99,9% — это работа AI-инженера.

Я думаю, именно это привело к неудачам таких продуктов, как Humane, Spin и Rabbit R1 — разработчики не предвидели, что отсутствие надёжности в таких продуктах приведёт к провалу. Другими словами, если ваш персональный помощник правильно оформляет заказы еды в DoorDash только в 80% случаев, это катастрофический провал с точки зрения продукта.

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

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

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

Инженерия надёжности как новый подход

Так в чём же решение? Я думаю, задача для AI-инженеров — понять, какие программные оптимизации и абстракции необходимы для работы с изначально стохастическими компонентами, такими как LLM. Другими словами, это проблема системного проектирования, а не просто проблема моделирования, где нужно обходить ограничения изначально стохастической системы.

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

Если посмотреть на заголовок статьи, он указывает на одну из областей, где мы уже преодолели определённые типы ограничений стохастических систем — с рождением вычислительной техники. Компьютер ENIAC 1946 года использовал более 17 000 вакуумных ламп, многие из которых в начале процесса выходили из строя так часто, что компьютер был недоступен половину времени.

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

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

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

Итак, я оставляю вас с тремя ключевыми выводами:

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

2. Статические бенчмарки часто не отражают реальную производительность агентов; необходимы более комплексные методы оценки с участием экспертов предметной области.

3. Следует сосредоточиться на инженерии надёжности, а не только на возможностях, чтобы преодолеть разрыв между 90% и 99,999% точности, необходимый для успешных продуктов.