Transcription
Круто. Эм, привет всем. Меня зовут Нуно, и я хотел поговорить с вами о том, как мы провели последние 4 месяца, обучая кодовых агентов мастерски работать с электронными таблицами. Эм, так, по сути, наша цель состояла в том, чтобы кодовые агенты стали так же хороши в работе с электронными таблицами, как они хороши в, знаете ли, Python, JavaScript или любом другом вашем любимом языке. Эм, мы начали с точностью около 50% на бенчмарке финансового анализа и достигли 92%. Итак, я расскажу о том, что действительно принесло результат, а что нет, и о тупиках, и, эм, да, посмотрим. Эм, так, электронные таблицы немного сложнее для ИИ, чем вы можете подумать на первый взгляд. Эм, если вы, эм, если вы подумаете о том, как бы вы, знаете ли, если бы вы открыли Excel, эм, как бы вы ориентировались в файле Excel, который вы не знаете, это на самом деле очень визуальная вещь, и вы, знаете ли, вы просто мгновенно видите структуру. Здесь таблица доходов, там предположения, там график, эм, и это просто, знаете ли, кажется интуитивно понятным, и вы даже не задумываетесь об этом. Эм, а эм, LLM на самом деле ничего этого не видит. Она, знаете ли, если вы спросите ее: «Каков доход?» то ей придется выяснить, какой именно доход вы имеете в виду? Знаете, есть чистый доход, валовой доход, доход за это, доход за то, эм, какой, какой, эм, квартал, какой год, эм, а затем, эм, является ли найденное число фактическим вводом? Это формула? Эм, это, это на самом деле обманчиво сложная задача. Одна, эм, вещь, которую мы попробовали в самом начале, заключалась в разделении работы на трех агентов. Эм, так, центральным был агент редактирования, у которого был пятиступенчатый процесс, эм, эм, который, знаете ли, вы определяли конечное состояние, вы составляли план, вы выполняли, вы проверяли, все, все вещи, которые вы должны делать. И это, эм, как бы изменило тип ошибок, которые мы получали. Эм, без этого агент просто совершал бы ошибки при фактическом построении финансовой модели или чего-то подобного, а с этим он, возможно, совершал бы эти ошибки при планировании, что было намного легче исправить. Эм, но эта архитектура в итоге оказалась слишком жесткой, потому что, знаете ли, обнаружение происходило один раз в начале, эм, а затем вы не могли вернуться к нему, и, эм, контекст не передавался между разными агентами. Так что это оказалось просто тупиком. Эм, затем еще несколько тупиков. Эм, мы, я думаю, попробовали, вероятно, каждый мыслимый способ представления электронной таблицы для LLM. Эм, ни один из них не работал как самостоятельное представление, но два, эм, оказались полезными в качестве методов внутри REPL, который мы в итоге, эм, создали. Эм, но все они имели что-то в теории, и именно поэтому мы попробовали, верно? Итак, SQL существует уже десятилетия, так что, знаете ли, очень популярен в обучающих данных LLM, поэтому агенты очень хорошо с ним справляются, предполагается. Отличный способ работы со структурированными данными, эм, но оказывается, что, знаете ли, это не совсем подходит для этого. Эм, XML — это то, как файлы Excel представлены на диске, так что, знаете ли, возможно, это была хорошая идея. Это не было. Эм, и, эм, знаете ли, многие другие. В итоге, эм, мы получили две, эм, полезные вещи из этого. Одной из них была концепция наличия представлений CSV или TSV части электронной таблицы. Эм, это оказалось не очень хорошим способом взаимодействия с электронной таблицей, но как одна часть большего решения, эм, оказалось, что используется очень, очень часто. Эм, а HTML также был шагом в правильном направлении, поскольку он, знаете ли, ввел идею макета и форматирования и так далее. Эм, так что это привело к тому, что мы построили движок рендеринга, чтобы позволить, эм, эм, агенту видеть, как выглядит отрисованная электронная таблица в виде изображения. Эм, а затем, эм, знаете ли, в конечном итоге мы, эм, наткнулись на, эм, что, вероятно, оказалось самым большим, эм, прорывом, который заключался в замене, знаете ли, множества инструментов, которые мы накопили за время. Я думаю, в то время у нас было около 15 инструментов, эм, одним единственным инструментом, которым был REPL Node.js. Эм, итак, знаете ли, все 15 инструментов, которые у нас были, просто стали различными функциями JavaScript, которые, эм, агент мог комбинировать в этом одном вызове REPL. И почему, почему JavaScript? Эм, нам нужен был скриптовый язык, который легко песочнить, его легко для LLM, знаете ли, очень знакомы с ним, и, эм, Python, вероятно, работал бы одинаково хорошо. Мы просто выбрали JavaScript. Эм, но фактическая реализация кода, который работает с электронной таблицей, на самом деле написана на совершенно другом языке, на C#, эм, эм, и в этом заключается преимущество этой архитектуры. Вы просто, знаете ли, используете скриптовый язык для того, в чем он хорош, а именно для того, чтобы агенты могли с ним взаимодействовать, и используете правильный язык для работы с фактическими файлами. И как это выглядело до и после. Итак, раньше, чтобы агент исследовал электронную таблицу и получил ответ, обычно требовалось 10 или 15 вызовов инструментов. Эм, и это на самом деле очень часто приводило к тайм-аутам и занимало много времени, потому что это просто, знаете ли, делалось последовательно. Даже параллельные вызовы инструментов не особо помогали, потому что вы не могли комбинировать результаты каким-либо образом. А после этого агент мог просто комбинировать, знаете ли, разные вещи, которые он хотел сделать, в одном вызове инструмента и получать все результаты одновременно. Эм, так что некоторые из вас будут знакомы с идеей кодового режима. Я думаю, что это становится все более популярным, появилось в API Anthropic, и Cloudflare много об этом говорила. REPL на самом деле, а кодовый режим, знаете ли, уже очень полезен, верно? Потому что это, это основная идея объединения нескольких инструментов в один, эм, в один вызов инструмента. Эм, но REPL на самом деле идет дальше, и разница в том, что это, по сути, кодовый режим с постоянным состоянием. Так что, знаете ли, агент вызывает инструмент REPL один раз, определяет несколько переменных, а затем видит результаты, тратит еще несколько токенов на рассуждения, а затем в следующий раз, когда он вызывает инструмент, эти переменные все еще там. Так что это означает, что он действительно может, знаете ли, строить на своей работе. И то, что мы наблюдали с этим, это то, что чистый кодовый режим без семантики REPL, эм, агенты очень часто писали довольно длинные скрипты, например, 50 строк JavaScript было бы довольно обычным делом. Эм, что, что здорово, означает, что они делают много вещей одновременно. Но с REPL они на самом деле писали более короткие скрипты, эм, что означало, что он мог, по сути, делать больше чередований рассуждений между каждой из вещей, которые делал агент, эм, что во многих случаях приводило к тому, что агент быстрее получал лучший ответ. Потому что это было менее статично. И еще одна приятная особенность этого дизайна заключается в том, что, эм, в предыдущем способе, где у нас были отдельные инструменты, если мы, знаете ли, если мы выяснили: «О, есть новый, эм, новый метод, к которому нам нужно дать агенту доступ, чтобы, я не знаю, исследовать зависимости между формулами или что-то еще». Так что это означало бы создание еще нескольких инструментов, которые войдут в схему инструментов, и нам нужно посмотреть, как они взаимодействуют друг с другом. Эм, тогда как с этим подходом, эм, все, что это означает, это предоставление нескольких дополнительных методов в REPL JavaScript и информирование агентов об этом так же просто, как создание файла определений типов TypeScript и помещение его в промпт, и это работает очень хорошо. И, эм, так что результаты, эм, из всего этого были, эм, знаете ли, мы перешли от, как я сказал, 50% до REPL, затем 74, а затем, знаете ли, со временем мы внесли еще изменения, ни одно из которых не было таким драматичным, как REPL, что в конечном итоге привело нас к 92% на этом, эм, внутреннем бенчмарке, который у нас есть. И эти изменения включали предоставление агенту лучшего нечеткого поиска или функций отслеживания формул для зависимостей, или улучшение системного промпта, или просто исправление ошибок. Эм, но, знаете ли, все это складывается в хороший результат. И еще одна вещь, которую я хочу, эм, отметить, это тайм-ауты. Так что, эм, этот подход в итоге действительно, знаете ли, исправил задачи, которые приводили к тайм-аутам. Мы обычно запускали задачи с 5-минутным тайм-аутом, потому что если ответ на вопрос об электронной таблице занимает более 5 минут, это не особенно полезно. Эм, и этот подход, по сути, привел к нулевым тайм-аутам, потому что агенту было гораздо эффективнее делать свое дело. Эм, существует много параллелей между электронными таблицами и программированием. Эм, я уверен, что вы все используете Claude Code или Codex или любой другой кодовый агент, эм, каждый день, и он работает намного лучше, когда он может, скажем, запускать компилятор для вашего языка или линтер или ваши тесты, а затем итерировать на основе этих результатов. И, эм, знаете ли, когда мы пишем код вручную, это тоже верно, верно? Если нам не разрешено компилировать, линтировать или тестировать код, то великого результата не будет. И то же самое верно и для электронных таблиц. И, но чтобы обеспечить это для работы с электронными таблицами, нам пришлось построить пару движков, которые могут замкнуть этот цикл обратной связи. Два наиболее важных из них — это движок формул для расчета формул. И другой — это движок рендеринга для отрисовки содержимого диапазона в, скажем, изображение со всем форматированием и макетом и так далее. И это своего рода источник истины. Это цикл проверки, который позволяет агенту, знаете ли, подтвердить, что он сделал правильную вещь. И когда он сделал неправильную вещь, пойти и исправить формулу или пойти и исправить форматирование, чтобы сделать ее правильной. Но это работает только в том случае, если движок действительно имеет высокую точность. Так что, если вы используете неполный движок, который реализует, скажем, 50% формул в Excel, то то, что вы получите, на самом деле хуже, потому что агент напишет формулу, которая, по его мнению, будет работать, а на практике будет работать. А затем он попытается ее вычислить, и он получит неправильный результат или ошибку, потому что она не реализована в движке. Так что этот цикл проверки действительно так же хорош, как и движки, которые его поддерживают. Так что это приводит, знаете ли, к двум разным вещам. Одно — это REPL, и это интерфейс. Это то, как мы представляем наши инструменты агенту. И, знаете ли, REPL — это лучший интерфейс, который мы смогли придумать сегодня, потому что программирование — это то, в чем текущее состояние моделей лучше всего. Но это не обязательно будет так навсегда, верно? Лаборатории много работают над использованием компьютеров. Так что, знаете ли, в конечном итоге, возможно, модели будут так же хороши в использовании компьютеров с мышью и клавиатурой, как и в программировании. И в этот момент, возможно, REPL не будет лучшим интерфейсом. Но это лучший на сегодняшний день. Что не изменится, так это потребность в, знаете ли, в этом цикле проверки. И то, что стоит за этим, на самом деле, я думаю, более долговечная часть, потому что чем более способны модели, как они были, я не знаю, четыре или пять выпусков моделей, пока мы работали над этим, и каждый раз, когда мы видели, что модель становится более способной, тем больше они могут получить от этого цикла проверки. И еще одна вещь, которую мы в итоге сделали, это добавление знаний предметной области в промпты. И это на самом деле, знаете ли, пережило все различные итерации инструментов. И и это всегда, знаете ли, давало улучшенные результаты. И это не столько потому, что LLM из коробки не знают, что, я не знаю, означает доход или ARR. Это скорее потому, что они, знаете ли, знают много-много вещей, и вам нужно немного их, знаете ли, загнать в рамки того, на чем вы хотите, чтобы они сосредоточились для конкретной задачи, которую вы имеете. И это на самом деле очень портативно, как этот почти точно такой же промпт будет работать для REPL или отдельных инструментов или любого другого подхода. Я также хочу немного коснуться оценки. Оказалось, что это большая работа — оценивать эти вещи, и это на самом деле было, знаете ли, действительно важной частью того, что позволило нам быть уверенными, было ли, знаете ли, представление CSV или SQL хорошим, если мы можем фактически оценить это. И правильная оценка оказалась своего рода путешествием. Мы начали с LLM как судьи только. И, знаете ли, это работает в некоторой степени, и иногда это единственный вариант, который у вас действительно есть. Но раздражает то, что иногда вы не можете действительно сказать, изменил ли агент что-то, когда меняется оценка, или изменил ли оценщик то, что он выводит. Поэтому мы в итоге проделали большую работу, чтобы заменить его детерминированными сравнениями везде, где это было возможно, что не всегда возможно. Но там, где мы могли, например, знаете ли, взять эталонную электронную таблицу, которая имела набор входных данных и набор выходных данных, а затем использовать это как своего рода черный ящик для тестирования электронной таблицы, которую произвела модель, говоря: «Эй, если вы введете некоторые числа в эти входные данные, вы получите что-то из этих выходных данных». А затем вы вводите те же числа в электронную таблицу, которую произвела модель, и смотрите, получаете ли вы те же выходные данные. И это оказывается, знаете ли, иногда более надежным, чем просто использование LLM для оценки этой работы. И, как и во всем, есть ошибки и ошибки инфраструктуры при создании агентов. Многие ошибки в итоге выглядят как, знаете ли, ошибки рассуждений, и может показаться: «О, модель делает что-то не так». Но на самом деле во многих случаях оказывается, знаете ли, это ошибка, где у вас просто ошибка в коде или навыке, или в промпте есть неправильный пример, и модель очень точно следует этому. Или на самом деле, знаете ли, ошибка в инструментах, и они терпят неудачу, а затем модель продолжает повторные попытки, и кажется, что модель глупа, но, знаете ли, она просто пытается обойти проблему. Так что, знаете ли, есть много пользы от того, чтобы действительно смотреть на эти трассировки и видеть, что идет не так, и пытаться выяснить, это, знаете ли, модель не совсем понимает, или это то, что мы можем исправить. Эм, так что я хотел бы закончить, эм, кратким изложением того, что, по моему мнению, обобщается на другие задачи. И я думаю, первое — это то, что если ваш агент совершает много последовательных вызовов инструментов или даже параллельных вызовов инструментов, то вы, по сути, изобрели плохой скриптовый язык. Так что вам лучше просто дать агенту настоящий. И это может быть кодовый режим или REPL или что угодно. Второе — я думаю, циклы обратной связи действительно важны. И если вы работаете в области, где вы можете создавать эти циклы обратной связи с существующими инструментами, то отлично. Меньше работы для вас. Но если вы не работаете в области, где эти циклы обратной связи на самом деле не существуют, я думаю, действительно стоит потратить время на создание этого движка рендеринга или движка расчета или всего, что применимо к вашей конкретной области. Эм, третье — я думаю, интерфейсы очень важны. И, как я объяснил ранее, эм, REPL действительно изменил результаты, которые мы получили. Так что вам действительно стоит потратить время на выяснение того, какой лучший интерфейс. Но вы должны ожидать, что вам придется пересмотреть это. Потому что модели, возможности моделей будут продолжать меняться, и по мере того, как они становятся лучше в других вещах, вы можете обнаружить, что лучший интерфейс — это что-то другое, и вам нужно найти, что это следующее. Далее, я думаю, знаете ли, мы не должны недооценивать силу планирования и думать, прежде чем действовать. И да, иногда простые вещи действительно имеют значение. Так что не, знаете ли, действительно потратьте время и на них. Знания предметной области, я думаю, очень важны, и вам действительно нужно потратить много времени, думая о том, что, какие вещи вам нужно напомнить модели. Это не столько обучение модели, сколько напоминание ей уделять больше внимания этому, чем другим вещам. И, наконец, да, оценка, я думаю, чем больше вы можете проводить детерминированную оценку, тем лучше, что не означает, что вы должны, знаете ли, избегать LLM как судьи. Это просто означает, что если это единственный вариант, который у вас есть, то именно это вы и должны делать. Но если вы можете оценить каким-либо другим способом, сделайте это. И всегда проверяйте свои трассировки и свою инфраструктуру, потому что иногда путаница агента — это просто ошибки, и вам следует это исправить. Спасибо.