Transcription
Агент, который обеспечивает работу движка, на самом деле использует песочницу в качестве инструмента. Система Langchain работает внутри развертывания Langsmith, совершая вызовы в песочницу Langsmith. >> Сегодня я разговариваю с Беном Тэнни Хиллом, менеджером по продукту в Langchain. Месяц назад его команда выпустила Langsmith Engine, нашего агента, который ищет сбои в ваших агентах, приоритизирует проблемы и составляет исправление. У нас есть этот компетентный основной агент, который затем будет делегировать задачи этим менее компетентным и гораздо более дешевым, гораздо более быстрым сканерам. Обычно субагент-сканер является основным способом, которым мы исследуем трассировки. >> Он объясняет маловероятный способ, которым движок стал самосовершенствующимся агентом. >> Движок как агент создает свои собственные трассировки, и поэтому у нас есть другой движок, который работает поверх этих трассировок. >> Так мета. >> Это супер мета. Мы предполагали, что это будет отстой. Это становится все более и более одним из основных способов, которым мы находим улучшения, которые нужно внести в движок. >> Мы углубляемся в то, как вы создаете оценки для агента, который никогда не перестает работать. >> Мы фактически делаем это теневое производство, запуская реальные трассировки на них, но не создавая реальных проблем для пользователя >> и скачок, над которым Бен работает прямо сейчас, где движок предлагает исправление, а затем доказывает, что оно работает. >> Этот процесс запуска новой версии вашего агента с предложенным исправлением против этих новых оценок очень сложен, но это то, что, я думаю, действительно захватывающе. Добро пожаловать в Max Agency, подкаст, который глубоко погружается в то, как лучшие агенты создаются такими же строителями, как вы. Langsmith существует уже несколько лет. Langsmith Engine намного новее. Прежде чем углубляться в движок, что такое Langsmith? >> Да. Э-э, Langsmith — это наша платформа для наблюдения и оценки агентов в производстве. И поэтому у нас, очевидно, есть наша платформа наблюдаемости, которая предназначена для отправки трассировок ваших агентов, чтобы вы могли понять, что делает ваш агент в производстве. Как он совершает определенные вызовы инструментов? Как он использует различные подсказки, которые вы ему даете, чтобы лучше понять, как ваш агент фактически работает в дикой природе. Langsmith также предлагает эту возможность запускать оценки и проводить эксперименты. Эм, поэтому у нас есть возможность хранить наборы данных в Langsmith, и вы можете легко передавать их вашему агенту, чтобы он мог затем работать, и вы можете просматривать эти эксперименты после факта в Langsmith. Есть много других интересных функций, которые у нас есть, таких как простой способ создания наборов данных с использованием подсказок для аннотирования, игровая площадка, где вы можете настраивать и экспериментировать с различными подсказками. Но это Linksmith в целом >> и это существует уже некоторое время, а затем движок вышел около месяца назад. И что такое движок и почему вы создали движок? >> Движок в некоторых отношениях является агентом для Lang или агентом для инженера агентов. >> Что это значит? >> Да, это отличный, это отличный, это своего рода метафора, верно? Агент для инженера агентов. Когда мы создавали движок, мы заметили этот процесс, через который проходил инженер агентов, где они создавали или модифицировали агента, которого они имели в производстве, внося изменения в подсказку, в его код и т. д., запуская тесты, чтобы убедиться, что эти изменения, которые они внесли, были адекватными и что они прошли различные оценки, которые у них были, или были уместными, а затем развертывая их в производстве, а затем возвращаясь в Langsmith и отслеживая, используя наш инструмент наблюдаемости, чтобы понять, что делал их агент. И поэтому этот процесс, который мы обсуждали, как жизненный цикл разработки агента, имеет много ручных шагов. И поэтому движок — это фактически агент, который пытается, вы знаете, поощрять процесс прохождения этого цикла, помогая инженеру агентов лучше понимать своего агента и трассировки, которые он создает, чтобы более легко создавать исправления для ошибок, которые они видят, а затем более легко запускать тесты на них. Так что это своего рода основные категории, верно? Например, поиск проблем по вашим трассировкам, предложение исправлений для этих проблем, которые он находит, и затем помощь в процессе тестирования этих исправлений, которые он предлагает, все перед тем, как вы развернете. >> Погружаясь в некоторые детали, что именно делает движок под капотом? >> Да, под капотом движок — это агент. Эм, и именно поэтому мы называем его, например, Elangsmith агент или агент для агента. Агент для инженеров агентов. >> Это mouthful. >> Это mouthful. Эм, и поэтому мы просто начали называть его движком. Агент под капотом — это глубокий агент, один из наших продуктов Langchain, верно? Эта система агентов. И глубокий агент работает для приема и понимания огромного количества трассировок из вашего проекта наблюдаемости Lang. Эм, он принимает эти трассировки и проводит анализ, чтобы понять, есть ли очень явные ошибки? Есть ли места, где потребности пользователя не удовлетворены каким-либо образом? Есть ли интересные сигналы для исправлений, которые можно внести? И он берет эти различные ошибки и кластеризует их в эти действенные проблемы и затем предоставляет эти проблемы пользователю, где он может сказать: «Да, это очень реально. Вы знаете, мы совершаем неправильный вызов инструмента в этом обстоятельстве». И движок делает следующий шаг и предлагает исправление, обычно через PR против репозитория ваших агентов. И тогда я могу очень быстро реализовать изменение подсказки или промежуточное ПО, которое улучшит моего агента и напрямую устранит это исправление. И тогда этот агент снова, завершая цикл здесь, предложит примеры наборов данных для добавления в мои Langals, чтобы я мог запускать эти примеры позже. Но все это обеспечивается этим агентом, который исследует, кластеризует, а затем генерирует это исправление кода и генерирует эти оценки. >> Давайте, возможно, разберем это немного. Итак, как запускается движок? Человек отправляет сообщение или он работает в фоновом режиме? Что происходит? >> Да, сегодня он работает в фоновом режиме и работает по расписанию. Эм, движок может быть сконфигурирован в Langsmith, и он позволяет пользователю в основном настраивать, какой репозиторий использует их агент, а также определять, возможно, некоторые из их приоритетов, вещи, которые они особенно заинтересованы в том, чтобы видеть. И тогда движок всегда включен и работает и отслеживает входящие трассировки, которые поступают в Langsmith. Так внезапно, когда мой агент производит тонну трассировок в понедельник днем, движок подхватывает их, кластеризует и выявляет проблемы. Вероятно, существует мир, где, вы знаете, движок может быть вызван по-другому. >> Прямо сейчас он работает по этому расписанию и сам кластеризуется. >> Как именно работает это кластеризация, когда я знаю, что у нас есть клиенты с миллионами трассировок в их проекте трассировки? Как работает кластеризация по большим объемам трассировок? Это очень сложно для нас, и прием тонны различных трассировок — это одна из вещей, которую мы постоянно пытаемся улучшить. Реалистично, движок не может принимать миллионы трассировок одновременно, и поэтому это то, что мы всегда пытаемся улучшить, чтобы иметь возможность экономически эффективно принимать все больше и больше трассировок. Способ, которым мы это делаем, — это очень сложный агент, у которого есть различные субагенты, которые выполняют различные задачи. Один из способов, которым мы работаем, чтобы справиться с этой огромной нагрузкой трассировок, — это проведение первоначального прохода по этим сжатым или обобщенным версиям трассировок. Так вместо приема всего 500 килобайтного трассировки или 10 000 таких различных трассировок, движок, используя один из наших инструментов командной строки Lang, позволит ему отправить сжатую версию в движок. И поэтому, возможно, эта сжатая версия содержит только общий размер трассировки, ввод, и некоторые интересные качества о ней, что >> Да, я собирался спросить, как именно выглядит эта сжатая версия, и существовала ли она до движка или она была специально создана для движка? >> Да, это, как и многие другие вещи, было специально создано для движка. Это одна из преимуществ создания агента внутри нашей собственной программной платформы, заключается в том, что она подчеркнула множество способов, которыми мы можем сделать нашу собственную программную платформу Lang гораздо более дружелюбной к агентам и действительно нативной для агентов. Эм, и поэтому эта обобщенная версия. Да, она может, как я сказал, содержать, в основном, ввод, общее количество использованных токенов, общее время этой трассировки. Это своего рода отправная точка, это только первоначальный проход, к которому имеет доступ агент, и это очень простой способ обнаружить очевидные ошибки. Если базовый уровень трассировки займет две минуты, внезапно, когда он увидит 10 трассировок, которые превышают 10 минут, это гораздо более интересный сигнал для движка, чтобы углубиться и более внимательно изучить. Но да, возвращаясь к вашему предыдущему вопросу, это именно так. Эта обобщенная версия этой трассировки — это то, над чем мы работали, чтобы позволить движку работать легче и иметь больше доступа, и это одна из многих вещей, которые мы сделали для улучшения Lang для агентов. >> Есть ли другие примеры улучшения Lang для агентов, которые сделали это, особенно в области контекстного инжиниринга для агентов, например, когда вы взаимодействуете со всеми этими данными Langsmith, как вы лучше всего представляете их агентам? Есть ли какие-либо другие выводы или изменения, которые вы внесли там? >> Да, еще одно, что было интересно, это то, что нам нужно углубляться все глубже и глубже в то, что ценно из трассировки, и мы хотим представлять агенту как можно меньше этой информации. Если мы предоставляем ему больше контекста, чем необходимо, это просто увеличит стоимость запуска этого всегда включенного агента. И поэтому первое — это своего рода ультра-сжатая версия. Она покажет базовую статистику о трассировке. Следующее — это то, что мы улучшили в Langsmith. есть так называемое представление сообщений, и это своего рода очень приятный, правильный пользовательский интерфейс для просмотра поворотов между пользователем и агентом. Не было очень хорошей конечной точки для агента, чтобы фактически получить этот приятный вид, и вместо этого наши варианты были действительно этим совершенно новым своего рода высокоуровневым статистическим вариантом, который у нас был, или полным, всей трассировкой. И поэтому теперь у нас есть этот своего рода средний вариант, который не содержит каждого метаданных, связанных с трассировкой, но он теперь имеет обратную связь между пользователем и агентом, которая имеет больше контекста, внезапно более ценна, позволяет движку понять еще больше о разговоре. Была ли ошибка в этом разговоре? Был ли пользователь расстроен в этом разговоре? И поэтому этот процесс определения все большего и большего количества этих конечных точек, из которых движок может извлекать, чтобы найти то, что ценно из трассировки, я думаю, вероятно, лучший ответ на этот вопрос о том, чтобы сделать Lang более дружелюбным к агентам. >> Вы упомянули, что это было частью CLI. Так вы даете весь CLI агенту, и это тот же CLI, который люди могут использовать для взаимодействия с Langsmith? Вы контролируете, что агент делает с этим CLI, или он действительно открыт? Да, я имею в виду, мы могли бы говорить только об этом одном вопросе до конца нашей беседы. Было так много интересных обсуждений о том, что мы можем превратить в рабочий процесс, или что мы просто передаем агенту и позволяем ему работать. >> И когда вы говорите рабочий процесс, что именно вы имеете в виду под рабочим процессом? Когда я говорю рабочий процесс, я имею в виду что-то более детерминированное, верно? Я мог бы сказать агенту >> Было бы это как инструмент или скрипт, или как вы представляете? Да, что-то вроде скрипта, например, когда этот ответ получен агентом, всегда выполняйте этот скрипт, верно? Внезапно это очень детерминировано. Я не даю агенту контроля, чтобы, да, сказать, что он хочет взаимодействовать таким образом. Очень легко придумывать эти рабочие процессы и говорить: «О, мы превратим весь этот процесс в рабочий процесс, и первый шаг агента всегда должен вызывать эту команду CLI, а затем эту». Очень легко сделать это, и очень легко ошибиться, и создать эти неэффективные рабочие процессы, которые также имеют огромное количество кода. И поэтому сила агентов действительно в том, что вам не нужно выполнять такую работу, и внезапно они способны и достаточно компетентны, чтобы определить, какие рабочие процессы наиболее эффективны. Это не значит, что с движком мы даем агенту никакого руководства, верно? Мы, безусловно, даем ему контроль и возможность совершать эти вызовы CLI как вызовы инструментов, но мы даем ему много руководства с течением времени, когда мы видим места, где он действует неэффективно. Так что, возможно, в более повествовательном формате. Как я уже сказал, вначале мы были соблазнены этими различными рабочими процессами и очень явно определяли различные шаги, которые должен предпринять агент >> и чтобы сделать это конкретным, например, вначале движок был в основном рабочим процессом Lang Graph, это то, что вы имеете в виду под явными шагами и >> Вначале это все еще был глубокий агент, но мы писали скрипты для различных вещей, которые происходили. Так что, например, до того, как глубокий агент фактически работал в каком-либо виде, мы бы уже загрузили все трассировки из определенного окна, которые, как мы думали, не будут ценными, и мы бы отфильтровали их по определенным вещам, а затем передали эту отфильтрованную версию трассировок агенту. Так что внезапно мы уже приняли решение. Мы уже определили что-то, что агент мог бы определить сам. >> Но поскольку мы думали, что это, возможно, более эффективно или более разумный способ сделать это, мы сделали это. Но со временем мы начали бы вносить коррективы в это и понимать, что, возможно, нам не нужно быть настолько явными с этим рабочим процессом, и, возможно, агент, имеющий контроль над выполнением этих действий в нужное время, — это просто более простой способ проектирования этого. И поэтому есть своего рода опыт «отслаивания» и передача большего, когда речь идет о полном спектре того, к чему имеет доступ агент и что он может делать. Агент имеет, как мы говорили, доступ к этим командам CLI, и поэтому он может извлекать, когда он развернут в своей собственной среде. Он может извлекать из трассировок Langsmith, и он может извлекать существующие оценщики, которые у вас есть, чтобы понять их. И поэтому у него есть весь этот процесс извлечения информации из Langsmith. >> Да, я собирался спросить о песочницах, потому что мы говорили о CLI, и я предполагаю, что он работает внутри песочницы, и я думаю, что много говорят о том, как агенты взаимодействуют с песочницами. Они работают внутри песочницы или они работают снаружи и подключаются к песочнице через инструмент? Мне интересно, можете ли вы поделиться каким-либо пониманием того, как движок работает в этом отношении. >> Да, агент, который обеспечивает работу движка, на самом деле использует песочницу в качестве инструмента. Вместо того, чтобы запускаться внутри этой песочницы, он вызывает песочницу Langsmith. Поэтому мы фактически используем наш собственный продукт для этой песочницы для запуска и выполнения этих различных скриптов. Агент фактически работает в развертывании Lang, также в одном из наших продуктов. Так что наши глубокие агенты, вы знаете, система агентов Langchain, которую мы имеем, работает внутри развертывания Langsmith, совершая вызовы в песочницу Langsmith снаружи для выполнения. >> Так много продуктов Langsmith. >> Это много продуктов Langsmith. Все по этому циклу мы получили? >> Эм, вы упомянули субагентов раньше. Сколько различных субагентов использует движок и что это такое? >> Да, прямо сейчас, я думаю, у него четыре различных субагента. Это снова одна из тех вещей, с которыми мы постоянно экспериментируем и пытаемся понять, какова оптимальная структура различных субагентов, которые у нас есть прямо сейчас. Наиболее важным является сканер, или, я должен сказать, что у нас есть своего рода основной агент, который является мозгом операции и определяет, когда запускать эти различные субагенты. Он совершает некоторые первоначальные вызовы для настройки среды, он совершает первоначальный вызов того, что мы используем как память пользователя, а затем он немедленно запускает этот субагент-сканер. Субагент-сканер — это основной способ, которым мы исследуем трассировки. Чтобы избежать взрыва контента, или, прошу прощения, контекста агента, мы отправляем этих агентов-сканеров, которые всегда будут иметь доступ ко всей трассировке. Если когда-либо возникнет необходимость посмотреть не на эту чрезвычайно обобщенную сжатую версию трассировки, даже не на эту среднюю версию трассировки, а на полную длину трассировки. Если это когда-либо потребуется для того, чтобы движок определил, что что-то не так в трассировке, все это всегда обрабатывается сканером. Так что сканер — это тот, кто в конечном итоге совершает вызов, и способ, которым это что-то интересное для поверхностного возвращения к этому исходному основному агенту. Основной агент также обрабатывает это и передает его агенту-верификатору, и агент-верификатор выполняет окончательную, очень быструю, очень легкую проверку, чтобы убедиться, да, это проблемная трассировка. Она должна быть включена в проблему и т. д. Как я уже сказал, мы постоянно экспериментируем с различными субагентами, которые у нас есть, и различной структурой. У нас есть субагент, который фактически создает проблему. Он пишет хорошую диагностику и связывает с ней конкретные трассировки. Но это всегда меняется, и я думаю, что одна из вещей, которую мы узнаем, это то, что есть что-то странно знакомое в проектировании организационной диаграммы, своего рода, как у нас есть эта компетентная основная модель, основной агент, который затем будет делегировать задачи этим сканерам, которые менее компетентны и гораздо дешевле, гораздо быстрее, обычно, но они менее способны к этим более сложным решениям, но, возможно, они очень хороши в чтении трассировок и понимании очень мелких проблем в них. Так что, похоже на организационную диаграмму, способ, которым мы распространяем вещи и определяем, кто лучше всего подходит для какой работы. >> Использует ли движок навыки вообще или это не исследованный нами путь? >> Это не исследованный нами путь. Мы много об этом говорили. Я имею в виду, мы говорили о том, что мы определенно должны использовать навыки для нашей подсказки, верно? Это просто очевидный способ уменьшить контекст. Не каждый этап выполнения должен понимать весь контекст нашей системной подсказки. Так что это то, что нам нужно улучшить. >> Многие из вещей, о которых мы недавно говорили, кажется, что это активные области исследования. Я представляю, что для проведения исследований нужны хорошие оценки. >> Так что, возможно, переходя к этому. Как выглядят оценки для движка? >> Это очень сложно, как вы очень хорошо знаете. И это сложная задача. Движок оценивает несколько различных вещей во время своего выполнения, верно? Он не просто выполняет очень простую очевидную задачу, которую мы можем оценить с помощью одного набора данных входов и выходов. Вместо этого есть все эти различные этапы выполнения движка. Он ищет иголку в стоге сена, верно? Он находит проблемные трассировки в этом большом, потенциально огромном списке трассировок и определяет, что одна из них имеет проблему, а затем он правильно классифицирует эту проблему и определяет, что именно с ней не так. Соответствует ли она существующим проблемам? Он генерирует исправления. Он генерирует оценки. Так что есть все эти различные этапы. То, на чем мы остановились как, возможно, самый важный из этих этапов для нас, чтобы действительно освоить, чтобы движок был высококачественным агентом, — это процесс идентификации трассировки ошибки из этого стога проблемных или, я бы сказал, нормальных трассировок. Так что у нас был, и вы были очень вовлечены в это, процесс создания, по сути, эталонного теста для нас, чтобы понять производительность движка на наборе трассировок и подмножестве трассировок ошибок и большем наборе трассировок. >> Да, возможно, я могу поговорить об этом немного, потому что это единственное место, где мне посчастливилось внести какой-то вклад в движок, но да, мы работаем над чем-то, что мы называем своего рода "issue bench". Это коллекция, надеюсь, около 50 задач, очень направленных, по крайней мере, изначально, на идентификацию проблем. Мы используем Harbor, который является отличной платформой с открытым исходным кодом, которая обеспечивает работу других эталонных тестов, таких как terminal bench 2. Мы создаем синтетические среды для этих трассировок. Так что мы хотим сделать, потому что мы хотим знать точно, какие трассировки являются проблемными, точно, какие из них являются проблемами, какая их категория, потому что одна из вещей, которую движок также делает, имеет различные категории ошибок, и мы хотим убедиться, что они сгруппированы вместе. Так что, чтобы сделать это, мы создаем эту синтетическую среду с этими проблемами, своего рода, предварительно заполненной в ней, чтобы нам не пришлось брать реальные данные, а затем пытаться их маркировать, потому что маркировка десятков тысяч трассировок была бы действительно очень трудной. Так что мы создаем эту синтетическую среду, запускаем кучу трассировок, а затем запускаем ее в Harbor. И другая вещь, которая действительно интересна здесь, это то, что движок взаимодействует со многими состояниями служб. Так что он использует этот CLI, который вы упомянули ранее, который может взаимодействовать с Langsmith. И да, большая часть этого — чтение, но некоторая часть этого может быть и записью обратно в Langsmith. И поэтому, очевидно, мы даже не хотим читать из реального Lang, и мы определенно не хотим писать в реальный Lang. Так что мы создали своего рода заглушку сервера и, по сути, использовали ее для взаимодействия и имитировали все эти различные конечные точки. И я думаю, что это довольно обобщаемо в будущем для того, где будут оценки для многих долго работающих, состоящих в состоянии агентов. Это своего рода офлайн-оценка, своего рода бенчмаркинг. Была другая сторона, в которой я не участвовал, и я думаю, что мы делаем больше своего рода онлайн-теневого тестирования. Я не знаю, можете ли вы об этом говорить. Самый большой способ, которым мы проводим онлайн-тестирование, — это все еще запуск на наших внутренних агентах, верно? У нас есть наш агент для выхода на рынок внутри компании. У нас есть асинхронный агент кодирования, которому мы отправляем трассировки в Langsmith, и мы можем проводить всевозможные тесты и работать над движком, чтобы улучшить его на основе трассировок от них. Мы берем реальные трассировки, запускаем их, но не создаем реальных проблем для пользователя. >> Мы форкаем проект? Мы создаем новый проект? >> Именно так. >> Да, так что это действительно работает на наших внутренних агентах. Мы создаем реальные проблемы. Команды, которые работают над этими агентами, фактически могут просматривать эти проблемы и т. д. и понимать изменения, которые мы там внесли. Возможно, на более ранней стадии разработки мы фактически делаем это теневое производство, где мы фактически берем форк этих проектов трассировки, хранилище трассировок, которые отправляются в Langsmith, и мы запускаем движок на этой, знаете ли, форкнутой партии трассировок, и эта версия движка в разработке будет создавать новые проблемы. Иногда это ужасные проблемы, и мы можем понять, что пошло не так. Это не создает проблем для наших команд, которые работают над нашими внутренними проблемами. Они их не видят. Но это дает нам своего рода второй проход или еще одну быструю проверку проблем, которые создаются. Выглядят ли они правильно? Написаны ли они должным образом? Являются ли они высококачественными таким образом, который немного труднее уловить из этих эталонных оценок, которые мы проводим на Harbor. >> Когда у нас работает агент в производстве в реальной жизни, какие метрики мы отслеживаем, чтобы получить представление о том, как он работает? Мы отслеживаем тонну, и у нас есть так много классных инструментов, которые делают это очень простым для нас, верно? Мы используем, у нас есть наши фактические таблицы баз данных, которые могут информировать нас о том, сколько клиентов активно используют движок, кто его включил, как часто он работает, сколько трассировок он принимает в каждом из этих запусков. Эти фактические, своего рода, базы данных очень полезны для нас, чтобы иметь высокоуровневый обзор того, кто использует инструмент. >> Движок фактически сообщает о многих своих метриках. Например, я только что упомянул, что мы сможем видеть количество трассировок, которые принимает движок. Есть множество вещей, которые движок будет своего рода возвращать нам и информировать нас, например, x количество трассировок было проанализировано. Он дает нам представление о размере этих трассировок, которые он принимает, задержке его собственных запусков, как мы начинаем немного больше понимать, как движок работает для различных клиентов, с которыми мы работаем. Так что это своего рода внутренние статистики движка, которые мы можем видеть. >> Мы также проводим много отслеживания пользователей, чтобы понять, как пользователи взаимодействуют с фактическими проблемами. Мы много говорили об агенте и о том, что находится под движком, за движком, верно? Как он исследует и выявляет эти проблемы, но есть также весь этот продуктовый аспект, где пользователи взаимодействуют с этими проблемами и вносят коррективы в предложенные им исправления. И поэтому у нас есть много аналитики пользователей там. Но я упомянул, что у нас есть так много замечательных инструментов. Мы используем агент Hex тонну для создания новых панелей мониторинга каждый день для вещей, которые мы смотрим, и это, на мой взгляд, один из агентов, которым я пользуюсь чаще всего. >> Одна из самых интересных вещей о движке, я думаю, заключается в том, что это своего рода амбиентный агент. Он просто работает в фоновом режиме, работает по расписанию. Я думаю, что это также создает действительно интересные соображения по пользовательскому интерфейсу и опыту. Когда вы привлекаете человека? >> Как человек взаимодействует с этим агентом, который работает в фоновом режиме? >> Не могли бы вы немного рассказать о том, как вы думаете о пользовательском интерфейсе и опыте для движка? Какие-либо эволюции, которые произошли, и какой выглядит этот человек в цикле для этих амбиентных агентов? Самая первая версия движка, как эта, самая простая форма, заключалась в том, что он просто создавал PR и просто создавал PR для различных проблем, которые он находил, и многие из этих PR были плохими, и внезапно это было просто очень шумно, верно? Никто не хочет иметь дело с огромным списком PR, которые им нужно сортировать и понимать коммиты. Независимо от того, насколько хорошим является ваше описание этого PR, это просто слишком много. И поэтому очень быстро концепция своего рода почтового ящика стала хорошим вариантом, и мы начали ее обсуждать с нашими ранними тестировщиками и клиентами. И это просто имело смысл, потому что есть эти различные кластеризованные проблемы, которые движок сможет идентифицировать, которые имеют свою собственную историю. И поэтому этот почтовый ящик дает вам четкую диагностику того, какая проблема была встречена, что именно происходит, а также представление о том, как часто это происходит. Это долгосрочная вещь, которую вы видели в течение месяца? Происходит ли это со всеми вашими трассировками или с небольшой подгруппой из них? Но все это своего рода новый сигнал, с которым пользователь может взаимодействовать. >> Но с каждым из этих сигналов, вместо того, чтобы просто быть осведомленным, есть ряд действий, которые можно предпринять. >> И это то, что мы делаем каждый день, внося коррективы: каковы оптимальные шаги для пользователя? Каковы самые простые способы для пользователя взять набор проблемных трассировок и получить лучшего агента, и как мы можем оптимизировать этот поток от видения и понимания того, что что-то идет не так в моем агенте. Это именно то исправление, которое мне нужно внести, и это то, как его развернуть или протестировать наиболее эффективно. Так что этот процесс был большим. Это, честно говоря, было проблемой перейти от простого выявления проблемы или PR к информированию пользователя правильным образом и поощрению его исправить ее правильным образом. Последнее, что я отмечу, также было трудно учесть в уравнении. У пользователя есть так много уникальных предпочтений и так много уникальных идей о проблемах и о самом агенте. Мы часто находим, что вещи, которые являются реальными проблемами, которые мы можем, знаете ли, назвать объективными проблемами с агентом, просто не важны для проблемы. Они просто не важны для человека. И поэтому эта команда может не заботиться о временах, когда контекст взорвался, или они могут не заботиться об этих незначительных галлюцинациях. И поэтому этот процесс, когда вы говорите: «Да, это реальная проблема. Мне неважно, чтобы ее решать. Давайте двигаться дальше», также был интересным, поскольку мы пытались научить движок все больше и большему от пользователя. Одна из главных вещей, о которых мы пытаемся говорить с клиентами при создании агентов, — это попытаться выяснить области работы, где вы можете проделать тонну работы, но в конце все равно остается человек. И я думаю, что мы немного практикуем то, что проповедуем с движком, потому что я думаю, что он делает всю эту работу, но все еще есть человек, прежде чем он откроет PR, прежде чем он добавит оценщик или добавит набор данных. Но я думаю, что мы можем заставить его делать много этой работы. >> Вы упомянули в конце, что есть все эти проблемы, которые люди могут не заботиться по какой-либо причине. Я представляю, что было бы довольно раздражающе, если бы мы продолжали поднимать одни и те же проблемы снова и снова для пользователей. >> Как вы думаете о памяти в движке? >> В самом движке, я упомянул в начале, что есть возможность для пользователя описать вещи, которые его интересуют прямо вначале, прежде чем, вы знаете, движок даже выполнит свой первый запуск. Это может быть, как мы говорили, конкретные категории, которые важны для пользователя. Это также может быть важные узлы информации, которые движок должен иметь о моем агенте, например, эй, он вызывает этот отдельный субагент. Важно, чтобы вы понимали разницу между ними. Всевозможные эти различные предпочтения или понимания, которые пользователь может выразить нашему агенту. Способ, которым мы обрабатываем память, — это то, что мы называем документом об обзоре агента. >> Он в основном похож на файл quad MD или agent MD, на который движок может ссылаться, и он ссылается на каждый запуск, чтобы понять, изменились ли предпочтения пользователя, отличаются ли его интересы, была ли скорректирована структура агента. И поэтому на него ссылаются при каждом запуске, он обновляется при каждом запуске, он обновляется по мере взаимодействия пользователя с этими различными проблемами. Процесс создания хранилища памяти и его обновления очень прост, его очень трудно сделать в контекстно-эффективном виде. >> Также очень трудно, пользовательский интерфейс, чтобы поощрять извлечение важной информации от пользователя для добавления в эту память. Очевидно, что движок не будет очень хорошо работать для определенной подгруппы клиентов прямо из коробки, и он будет работать очень плохо с, знаете ли, запутанной памятью, которая содержит всевозможные вещи, которые их не волнуют. Но попытка действительно понять, что волнует пользователя, очень, очень сложно. >> Даем ли мы людям возможность оставлять отзывы на естественном языке о проблемах? >> Да, мы делаем. Каждый раз, когда они игнорируют или разрешают, или говорят, что это не высокий приоритет, это низкий приоритет, у них есть возможность добавить: «Это низкий приоритет, не говорите мне об этом в будущем». >> Да, я думаю, это здорово. И я думаю, что захват всего этого, а затем передача его — то, что я думаю, действительно интересно о памяти с движком, на самом деле, заключается в том, что в целом мы видим, что есть два разных способа, которыми вы можете иметь память для агентов. Один, вы можете иметь агента, когда он работает и взаимодействует с пользователем, фактически обновляет свою собственную память. И тогда другой способ, которым вы можете это сделать, — это иметь процесс, который работает в фоновом режиме и смотрит на все взаимодействия, которые он имел недавно, а затем обновляет свою память своего рода в фоновом режиме. >> Мы как бы объединяем их здесь, потому что никогда нет места, где человек напрямую взаимодействует с движком. >> Они оставляют отзывы, а затем это подхватывается при фоновом запуске. И поэтому это своего рода то, что, да, немного сбило меня с толку, где это своего рода странный гибрид, где да, движок делает это, движок может обновлять свой обзор агента всякий раз, когда он запускается и смотрит на все эти отзывы, и у него есть это, но это своего рода фоновый процесс. Так что я думал, что это своего рода интересный компромисс для некоторых из этих вещей. >> Мы говорили о затратах немного раньше, и да, я имею в виду, я представляю, что запуск движка по тонне трассировок может быть дорогим. >> Как мы гарантируем, что мы не разорим Langchain? >> Да, это очень сложно, и я часто получаю сообщения от вас или от нашего руководителя отдела инженерии, сообщающие мне, что наши счета за выводы зашкаливают. >> Это то, над чем мы постоянно работаем над улучшением. Это стало одной из вещей, над которыми было весело экспериментировать в процессе улучшения агента. Есть всевозможные различные препятствия или различные узкие места, которые мы можем идентифицировать, а затем работать над их улучшением. >> Если бы мы запустили современную модель Opus для выполнения всего, что делает агент, скринер использует Opus или современную модель от OpenAI, если она работает на одной из этих мощных моделей, это приведет к огромному счету для нас. И поэтому процесс определения, опять же, возвращаясь к выбору модели, определения того, какие модели могут использоваться для различных задач, был очень интересным. Где мы можем использовать менее компетентную, гораздо более дешевую модель для выполнения этого процесса, и все это возвращается к этому своего рода процессу запуска оценок, где у нас есть гипотеза, мы можем провести исследование, чтобы понять, что эта часть выполнения отвечает за 33% нашей общей стоимости, как мы можем уменьшить эту конкретную часть выполнения? Можем ли мы заменить элементы этого на другую модель? Такое исследование очень интересно, а затем это тонна экспериментов и подъема по склону против наших оценок с различными изменениями, которые мы внесли. >> Практически говоря, какие модели мы используем сегодня для различных частей агента? >> Прямо сейчас мы используем, честно говоря, коктейль из различных моделей. Мы используем модели Anthropic. Мы используем Opus в качестве основного агента. Мы также используем модели от OpenAI, такие как 5.5. Мы используем модели Haiku для многих наших сканеров или наших верификаторов. Мы в разное время подставляли модели Gemini. Мы также исследовали множество различных моделей с открытым исходным кодом, особенно для этих менее сложных задач, таких как субагенты-сканеры, которые выполняют очень быстрый анализ трассировки, но это действительно часто меняется. Мы выпустили движок, я думаю, публично около месяца назад, на данный момент. >> Каким был выпуск движка от, скажем, первоначальной идеи до настоящего времени, и на кого мы его выпустили? Как мы учли обратную связь? Каким выглядит выпуск агента? >> Это было просто медленное расширение числа клиентов, которые были подключены к этой новой функции. И вы знаете, у нас были действительно замечательные партнеры по дизайну на ранних этапах, которые были взволнованы видением и очень доверяли очень ранней, очень плохой версии агента. Самую раннюю версию агента, мы называли ее Forge тогда, этот своего рода ранний прототип работал с некоторыми из наших клиентов, такими как Credit Genie или Unifi. И я упоминал ранее, что он создавал эти PR, и было очень легко получить обратную связь, потому что эти команды очень хорошо знакомы со своими агентами и типами ошибок, на которые им следует обращать внимание. Эти команды — инженеры агентов, которые привыкли просматривать трассировки Langsmith, выявлять проблемы, а затем предлагать исправления для этих точных проблем, которые они выявили. И поэтому цикл обратной связи был действительно сильным, особенно в отношении способности агента находить значимые трассировки и предлагать хорошие исправления для них. Но это действительно был просто этот процесс расширения группы пользователей, которые его используют. Где-то в марте, я думаю, мы начали выпускать самую раннюю версию движка, возможно, для пяти-десяти клиентов. У нас был своего рода расширенный бета-тест, закрытый бета-тест, где больше клиентов использовали его. У нас внезапно появился интерфейс в Langsmith, с которым они могли взаимодействовать, опять же, низкого качества, но что-то, что позволило нам получить много обратной связи, а затем просто прервать, мы выпустили нашу более доступную версию движка, и тогда у нас был этот поток обратной связи, который пришел. >> Я думаю, что одна из вещей, которые мы подчеркиваем как компания, — это быстрое развертывание, а затем быстрое итеративное улучшение после этого, и я думаю, что мы сделали это довольно хорошо здесь. Я помню, вы и Палаш, и некоторые члены команды очень быстро выпустили версию этого, и было невероятно видеть, как вы сказали, мы фактически увеличили количество трассировок. Мы попробовали это на внутренних агентах, а затем мы попробовали это с двумя партнерами по дизайну, а затем, я думаю, к моменту выпуска у нас было около 20 партнеров по дизайну, использующих его, а затем он пошел, я думаю, да, мы определенно практиковали эту философию «быстро выпускать, быстро итерировать». >> И я думаю, что то, что сделало это возможным, — это наша способность писать и развертывать код чрезвычайно быстро с помощью кодирующих агентов. Теперь мы действительно можем вносить значимые изменения в агента за считанные часы. Так что мы получаем обратную связь утром от одного из наших партнеров по дизайну, вносим быстрое изменение, снова запускаем движок для них и получаем дополнительную обратную связь к полудню. И поэтому темп был пугающим. >> Давайте, возможно, поговорим об этом немного. Как выглядит команда, создающая движок? >> Это очень отличается от того, к чему я привык как менеджер по продукту. Я привык к команде инженеров по продукту и какому-то архитектору, который занимается больше инфраструктурой в команде. У нас, очевидно, все еще много продуктового инжиниринга. У нас есть интерфейс в Lang. Очевидно, есть много компонентов инфраструктуры, поскольку мы используем наш продукт развертывания Lang. У нас есть эти песочницы, которые использует движок. Но есть также эта своего рода новая ветвь, где у нас есть наши инженеры агентов в команде. Есть очень разный процесс для двух команд, верно? У вас есть, это уже не совсем гибко с такой скоростью, с которой мы работаем с новыми кодирующими агентами, это чрезвычайно быстро, но это включает в себя, что мы говорим: вот очень конкретный продуктовый результат, который мы хотим, мы сделаем какой-то своего рода ранний дизайн-документ или исследование этого, а затем мы очень быстро реализуем это. Теперь с кодирующими агентами процесс для второй части нашей команды, этой прикладной команды инженеров агентов, очень отличается, где, как мы говорили, это больше похоже на этот экспериментальный поток, где мы сидим вместе и приходим к выводу, вау, агент потребляет тонну токенов для выполнения этого конкретного процесса, или этот субагент занимает вечность. Какие есть потенциальные способы уменьшить это, и мы приходим к этим различным гипотезам? И затем в течение недели мы обычно говорим: вот гипотезы, которые мы хотим реализовать. Давайте протестируем их. Мы запускаем наши оценки против них, а затем обычно во второй половине недели мы реализуем что-то вроде этого. Так что потоки и своего рода стиль инжиниринга так сильно отличаются между двумя командами. И тогда, очевидно, есть места, где они пересекаются. >> У нас есть другие продукты AI в Langsmith. И я думаю, что в некотором смысле движок является их эволюцией, но в других отношениях нам все еще нужно выяснить, как заставить их хорошо работать вместе. Возможно, я немного расскажу о том, как я вижу некоторые эволюционные моменты, а затем мне будет очень интересно услышать ваше мнение о чем-либо, что я упустил, а затем, каким будет будущее. Так что я думаю, что два предыдущих опыта AI, которые у нас были и до сих пор есть в Langsmith, — это Insights и Polly. Так что Insights, он в основном кластеризует, он работает над трассировками, подобно движку. Он кластеризует их. Он выполняет два уровня иерархической кластеризации и, по сути, показывает вам идеи, различные тенденции того, что происходит в ваших данных трассировки. Polly — это чат-бот, который находится внутри Langsmith. Я на самом деле не уверен, какой из них был выпущен. Вы знаете, какой из них был выпущен первым? >> Я понятия не имею. Я думаю, это было до того, как я здесь работал. Я думаю, что Insights был выпущен первым, хотя чат — это более простая вещь. >> Но чат, мы действительно не хотели делать просто общий чат-бот, и поэтому мы старались сосредоточиться на местах, где он принесет пользу, и два из этих мест были в пределах проекта трассировки. Он был в пределах трассировки и в пределах потока, и вы могли бы спросить его, что именно идет не так, а затем другое место было в игровой площадке, и вы могли бы попросить его исправить подсказку, которая была там. И в некотором смысле я, по сути, рассматриваю движок как объединение лучших частей обоих. Так что Insights работал над всеми вашими трассировками, интересно, но не действенно. Чтобы предпринять действие, вам пришлось бы подумать о том, что делать, а затем сделать это, а затем Insights также был своего рода широким. Он давал вам эти кластеры. Polly был очень сосредоточен на конкретных вещах, и в игровой площадке вы могли бы попросить его исправить вещи. И поэтому я думаю, что движок объединяет лучшее из обоих миров, потому что один из недостатков Polly — у нас никогда не было режима, где вы могли бы общаться с ним и просить его выполнять массивный анализ трассировки, потому что это сложная проблема. И поэтому движок, он позволяет вам работать над всеми вашими трассировками, как и Insights, и решает проблему Polly, но затем он производит эти действительно действенные вещи, которые вы можете сделать, что было проблемой Insights, но то, что Polly делал хорошо. Так что я, по сути, рассматриваю это как объединение лучшего из обоих миров. Мне интересно с вашей точки зрения, создавая движок и взаимодействуя с другими, будут ли они все частью движка в будущем? Есть ли различия? Как вы думаете об этом? Есть различия между тремя узлами, о которых мы говорили, между Insights, Engine и Polly. Я думаю, что есть что-то действительно захватывающее для меня в действенности движка. Прямо сейчас я собираюсь не просто понимать свои трассировки, но я теперь могу использовать их для внесения изменений в своего агента, что, я думаю, действительно круто, и я думаю, что это своего рода
правильном направлении. Я все еще думаю, что есть, скажем так, компоненты инсайтов и поли, с которыми движок справляется не очень хорошо. Например, движок действительно хорош в том, чтобы давать вам, знаете ли, очень конкретные проблемы, которые я собираюсь исправить, но я на самом деле не так много понимаю о статусе моего агента от движка. Я могу посмотреть список проблем и определить, что у меня здесь 15 проблем. Что-то серьезно сломано, когда на самом деле это могут быть мелкие проблемы, и это не дает хорошего представления о состоянии моего агента или его общих метриках. И поэтому инсайты, возможно, сегодня не справляются с этим идеально, верно? Он дает нам несколько приятных кластеров того, как пользователи взаимодействуют с моим агентом. Но есть этот увеличенный вид инсайтов, который, я думаю, действительно важен, и я думаю, что движку этого не хватает. И поэтому, возможно, есть комбинация этих двух, где я могу видеть как очень действенный набор проблем, которые я собираюсь решить, так и общий обзор того, все ли в порядке с моим агентом? Как люди используют моего агента? Что они у него спрашивают? Вы знаете, какие общие проблемы мы видим или категории проблем, которые мы видим? Переходя к поли, мы говорили о том, как движок работает по расписанию прямо сейчас, и у него нет интерфейса для легкого взаимодействия с пользователем, но мы также видели случаи, когда пользователь не хочет просто получать этот список оповещений или проблем, и они хотят задавать вопросы движку, например, вы знаете, AC по всему моему агенту, ухудшается ли моя задержка, это то, что движок, благодаря своей способности просматривать трассировки, мог бы очень легко сделать с некоторыми небольшими настройками, но прямо сейчас он этого не позволяет, поэтому я думаю, что есть своего рода элементы этих других компонентов, которые мы построили в Langmith сегодня, которые, я думаю, движку, вероятно, следует принять, или, возможно, есть мир, где они полностью сливаются в одного агента, который работает поверх Langmith. Хотя я думаю, что все они могли бы хорошо сочетаться. Продолжая это, вы знаете, мы говорим о движке как об агенте для инженерии агентов. Какие еще части инженерии агентов мы могли бы автоматизировать или помочь сделать с помощью агентов в будущем, будь то часть движка или что-то еще? Самое главное, что меня действительно волнует, и есть много неизвестных и много проблем, которые мы обсуждали и наметили, но прямо сейчас движок, я думаю, больше сосредоточен на этой функции мониторинга работы инженера агента. Он смотрит на трассировки, исследует их и кластеризует в вещи, которые более легко усваиваются инженером агента. И поэтому он выполняет эту функцию очень хорошо. Он, вероятно, мог бы значительно улучшить свою способность вносить исправления и создавать для этих агентов и делать этих агентов лучше, но он делает это сегодня. Компонент, которого, я думаю, движку не хватает сегодня, это способность тестирования. Прямо сейчас движок найдет проблему, предоставит ее пользователю вместе с предлагаемым исправлением. Пользователь, если он следует стандартным практикам инженерии агентов, прежде чем внедрить или объединить это исправление в производство, убедится, что оно проходит их оценку. и они запустят эти регрессионные тесты, чтобы убедиться, что это подходящее исправление. Оно не уничтожит все эти другие варианты использования, которые мы видели ранее с агентами. Это очень легко сделать, если вы вносите изменение в подсказку. И поэтому прямо сейчас движок создает примеры наборов данных на основе этих производственных трассировок. Если пользователь сказал что-то неуместное, и ваш агент справился с этим плохо, он создаст эталонный пример набора данных этого ввода, чтобы ваши оценки могли включить это в будущем. Это действительно все, что идет дальше. Он на самом деле не запускает этот эксперимент. Процесс запуска вашего агента, не совсем вашего агента, а новой версии вашего агента с этим предлагаемым исправлением против этих новых оценок очень сложен, но я думаю, что это очень интересно. Что это фактически будет означать, так это то, что движок найдет проблемы из ваших производственных трассировок, предложит исправления, которые протестированы и как бы закалены, потому что они были запущены против ваших оценок, чтобы мы могли с некоторой степенью уверенности сказать, знаете ли вы, это хорошее исправление. Оно не ухудшит другие входные данные, которые вы видели с вашим агентом в прошлом. Так что это направление, которое меня очень волнует. Есть масса проблем. Мы немного говорили об этом. Каковы некоторые из проблем? Первая — это, знаете ли, этот вопрос о запуске вашей ветки агента, верно? Например, если движок собирается предложить исправление, он внесет изменение в вашего агента. И как мы, как мы запускаем этого агента? У нас должны быть все переменные окружения. У нас должны быть, скажем так, ключи API, доступные нам. Легко внести изменение и создать запрос на извлечение против конкретного агента. Очень сложно запустить этого агента в какой-либо среде. Компоненты, необходимые для запуска этого агента, я думаю, трудно определить. Это один из компонентов. Другой элемент, который, я думаю, очень сложен, заключается в том, что существует подмножество агентов, которые выполняют только вызовы инструментов для чтения, например, у нас есть внутренний агент под названием chat lang chain, который является нашим агентом документации, и он будет задавать или отвечать на вопросы о нашей документации или о том, на что способен lang, что такое глубокие агенты, агент, подобный этому, просто читает из разных источников данных и не вносит никаких обновлений в эти источники данных, чтобы запустить ветку этого агента очень легко, потому что он может выполнять эти вызовы инструментов без реального эффекта. Неважно, если он вызывает мой производственный вызов инструмента к моей документации. Он не внесет изменений. Если я запускаю ветку моего агента, который выполняет реальные вызовы инструментов для записи, внезапно я могу изменять свою базу данных. Я могу отправлять электронные письма клиенту и взаимодействовать с реальным миром таким образом, который все еще находится на стадии разработки. Это действительно процесс создания среды оценки для этих агентов с правами записи, я думаю, очень сложен, и я на самом деле не думаю, что многие команды, которые создают агентов, точно знают, как создавать эти среды. Да, я полностью согласен. Я имею в виду, я думаю, что запуск оценок действительно интересен, но сначала вам нужно иметь оценку, верно? И если вы, если мы не поможем людям создавать оценки, что, я думаю, тоже очень интересное направление. Вы говорили о процессе, скажем так, воссоздания этих сред для запуска оценок для движка, верно, где у нас есть, скажем так, заглушки для lang, может быть, вы можете об этом рассказать, скажем так, что это за процесс, который клиентам придется пройти, если они захотят запустить оценку тоже? К сожалению, это открытый исследовательский вопрос, я думаю, это очень-очень сложно, и одна из причин этого в том, что в этом участвует много предметных знаний. Возьмем, к примеру, chat lang chain. Если бы мы хотели создать, скажем так, это реальная вещь, мы используем mintify для нашей документации, и мы используем его в chat lang chain, но мы не хотели использовать его для нашей оценки, потому что мы потенциально думали о том, чтобы делать RL, и мы не хотели делать много развертываний и перегружать серверы mintlifi. Поэтому мы думали о создании этой синтетической среды, и один из способов сделать это — это, хорошо, давайте направим ее на трассировки, мы можем получить хорошее представление о том, какие вопросы задаются, это определенно осуществимо, мы можем иметь некоторое представление о том, какие инструменты используются, и схемы ввода и схемы вывода, вполне осуществимо, мы можем получить некоторое представление о документах и базовых данных, не обо всех, но о некоторых из них. И вы можете представить, как направить агент кодирования на кучу трассировок и сказать: «Эй, создай, скажем так, какой-то синтетический мок-сервер, который просто не является правильным способом его создания. Самый простой способ его создать — это: «Эй, у нас есть вся документация в формате markdown в нашем репозитории. Давайте просто скачаем ее, поместим на диск, создадим некоторые синтетические вопросы, по сути, взяв документ, найдя ответ, а затем создав вопрос для него, а затем, по сути, используем, скажем так, GP или что-то еще в качестве поддельного поиска и используем это для имитации сервера. Это гораздо надежнее. Это просто лучше сделать. И поэтому, я не думаю, что агент кодирования, которому было поручено просматривать кучу трассировок, когда-либо смог бы придумать это. Я имею в виду, и поэтому, возможно, вы просто скажете: «Эй, в этих сценариях, да, люди должны быть вовлечены и делать это, но для других сценариев мы можем автоматизировать это, и это скорее открытый исследовательский вопрос, очень сложная проблема, но я думаю, что это было бы очень-очень интересно. Забавно, потому что это очень применимо к движку и улучшению движка. Но причина, по которой это применимо к движку, заключается в том, что это очень применимо просто к этим инженерам агентов. Этот процесс определения этого очень-очень сложен. И многие клиенты, с которыми я разговариваю, задают этот вопрос: «Вау, круто, что движок предлагает исправление, но как он тестирует исправление?» Да. И я объясню: «Ну, вам придется протестировать, скажем так, у нас нет действительно очевидного способа создать эту среду для запуска оценок. Прямо сейчас движок в основном используется для собственных агентов, которые создают команды, и он предлагает кучу исправлений кода и добавляет оценки и добавляет наборы данных. Я думаю, что это также, но этот процесс запуска агента по трассировкам — это, я думаю, общий процесс, и я думаю, что есть другие вещи, для которых вы можете его использовать. У меня есть одна идея, которая приходит на ум, и тогда мне было бы интересно узнать, какие еще у вас есть. Итак, я бы сказал, что одна из них — это память. Мы выпустили видео ранее сегодня об использовании движка для обеспечения долговременной памяти для агента, в частности, используя его как фоновый вычислительный ресурс. Мы отследили все взаимодействия с Langmith с помощью обычного отслеживания, а затем мы запустили движок по всем этим трассировкам и направили его на наш контекстный центр. И в нашем контекстном центре у нас была память агента. У нас были его файлы agent.mmd и некоторые навыки, а затем этот фоновый процесс движка, по сути, предлагал изменения в файлах навыков и в agent.mmd, и как только они были объединены, они могли быть возвращены для будущих запусков агента. И таким образом, я думаю, вы можете использовать движок как память. Для чего еще вы можете использовать движок? То, для чего мы также получили много запросов, — это для запуска движка поверх агентов кодирования, и это звучит очень похоже на то, что мы делаем для этих специализированных агентов, которые наши клиенты создают, а затем отслеживают в Langmith. Разница в том, что они не вносят изменений в промежуточное ПО, в подсказки агента. Вместо этого они вносят изменения в навыки или, скажем так, в эти файлы agent.md. Это очень похоже, верно? По сути, это все еще одно и то же: получение и анализ проблем по различным трассировкам, кластеризация их в группы, которые имеют смысл, а затем предложение конкретного исправления. В данном случае исправление — это, возможно, не изменение подсказки или корректировка кода. Это просто, скажем так, создание нового навыка или корректировка существующего навыка. Так что это, я имею в виду, очень-очень похоже, но есть разница в том смысле, что его нужно настроить для трассировок кода или для трассировок codex, верно? его нужно немного изменить, а затем у него есть это, в некотором смысле, это очень связано с вашим пунктом о памяти, верно, это другой тип файла, который является результатом этого. Это на самом деле поднимает еще один момент, который я хотел упомянуть, а именно то, что мы в настоящее время запускаем движок поверх трассировок движка. >> h >> ум >> находит ли он много вещей? >> Да, это очень ценно. Движок работает поверх трассировок существующего агента, иногда это агент клиента, но, знаете ли, для этого варианта использования, который я описываю, это наши внутренние агенты. Движок как агент генерирует свои собственные трассировки, и поэтому у нас есть другой движок, который работает поверх этих трассировок. >> Так что мета. >> Это очень мета. Когда мы впервые подумали об этом, это было очень рано, мы шутили об этом и предполагали, что это будет ерунда, и что это на самом деле никак не поможет найти реальные трассировки, но это было чрезвычайно полезно, и на самом деле это один из способов, которым мы находим улучшения для движка. Моя мечта — чтобы наша команда просто использовала движок для любой инженерии агентов, чтобы мы могли находить проблемы в наших производственных трассировках и вносить исправления. Так что это интересный процесс, но то, что вы описываете, как использование памяти и использование движка для этих различных вещей, просто напомнило мне, что движок — это своего рода цикл улучшений для любого типа агента, будь то агент кодирования, будь то что-то, что полагается на память, будь то сам движок, верно, он просто является этим драйвером улучшений. Спасибо, что слушали Max Agency. Если вам понравился этот выпуск, оставьте отзыв и подпишитесь. Отправляйте отзывы или вопросы на max agency langchain.dev. Мы хотим услышать от вас.