Transcription
Внутренне, за одну ночь, мы выпустили это, и, как и все, были просто в панике, потому что они говорили: «О боже, вот оно». >> Сегодня я разговариваю с Иззи Миллером, инженером по ИИ в Hex. Они занимаются поставкой агентов данных еще до того, как большинство команд вообще думали о них. >> И становилось все более очевидным, что у нас был этот зверь с высокой мощностью, едущий 25 миль в час в школьной зоне. Похоже, то, что мы здесь используем, нуждается в большем контексте, не только из ячейки, но и из всего проекта. Иззи описывает один из сценариев сбоя при создании агентов и то, как доступ к большему контексту в поведении пользователя привел к большим успехам. >> И если вы введете противоречивый контекст, он потратит 30 минут на размышления, говоря: «Подождите, дайте мне посмотреть. Хм, на самом деле», и войдет в этот сумасшедший режим коллапса. >> Чтобы агенты рассуждали так же хорошо, как и человек-аналитик данных, требуются некоторые хитроумные подходы. Я углубляюсь в то, как Hex начинал с отдельных агентов и почему это меняется. >> Люди говорили: «О, почему потоки могут делать это, а почему потоки не могут писать на Python, а агент блокнота может?» И объединение всего этого вместе оказало интересное влияние на уровне кода на то, как мы организуем наши инструменты, подсказки и навыки в пакеты. >> В самом конце Иззи рассказывает о наборе тестов Eval. Он создает 90-дневную симуляцию, в которой агенты учатся на контексте и улучшаются в течение более длительного периода времени. >> Если агент демонстрирует навыки и поведение, которые мы от него ожидаем, то к 90-му дню все вопросы и заявки тщательно составлены таким образом, чтобы он должен был правильно ответить на 100% вопросов. Sonnet 4.6. Шесть получает 24% на 90-й день. Это очень дорого в эксплуатации. Мне нужны, мне нужны кредиты, пожалуйста. >> Добро пожаловать на Max Agency, подкаст, который глубоко погружается в то, как лучшие агенты создаются такими же строителями, как вы. Иззи, очень рад, что вы здесь. Я думаю, Hex была одной из компаний, которая раздвинула границы возможного в области агентов. Вы выпустили много за последний год. Мы много используем их внутри компании. Я думаю, агент блокнота — это то, о чем я слышу восторженные отзывы. Что это такое и как это появилось? >> Ядро Hex всегда было этим интерфейсом блокнота, в котором вы можете, знаете ли, чередовать ячейки SQL, Python, текста или диаграмм и создавать очень сложные или простые анализы таким образом, который очень масштабируем, доступен, понятен, как грамотное программирование. Я думаю, мы были первым реальным продуктом, который выпустил функцию преобразования текста в SQL для реальных платящих пользователей, которые использовали ее. >> Каким был этот продукт в то время? Было ли это: введите, получите SQL? >> Это была ячейка, верно? У нас был этот блокнот, который содержал все эти ячейки, и мы ограничивали все наши функции ИИ для работы в пределах ячеек. И это было задолго до того, как кто-либо думал об агентах. Это было просто, знаете ли, вы открываете ячейку SQL, запрашиваете запрос, запрос появляется. Это работает на GPT 3.5 Turbo или что-то в этом роде. И мы такие: «О боже». >> Что сейчас кажется очень старомодным. А затем в течение следующего года или около того мы были очень сосредоточены на этом рабочем процессе с одним выстрелом, который, я думаю, во многих отношениях уникально проклят в анализе данных, потому что это итеративная область, в которой вы получаете ответ, и он интересен. Я хочу продолжить. И поэтому я думаю, что агенты не были тем, что, я имею в виду, возможно, за исключением вас, я чувствую, что люди не говорили: «Это грядет». И поэтому нам потребовалось много времени, чтобы перейти от ИИ, работающего в ячейке, к ИИ, работающему по всем ячейкам. И мы пробовали, и, честно говоря, я думаю, модели не были готовы первые несколько раз, когда мы пробовали. И поэтому мы искали в другом месте и создали все эти другие ИИ-штуки. А потом был такой момент, когда мы просто сказали: модели здесь, и нам нужно сделать это снова, и это сработает. И мы добавили боковую панель в блокнот и дали ей все те же функции или те же инструменты, к которым пользователь мог получить доступ в блокноте, и, как и за одну ночь внутри компании, мы выпустили это, и все были просто в панике, потому что они говорили: «О боже, вот оно». >> Вы помните, было ли что-то, что заставило вас понять, что пора вернуться к этой идее? >> Я думаю, было две вещи. Я думаю, одно — отслеживание возможностей моделей, и не обязательно их текущего состояния, а очевидной траектории их увеличения, и становилось все более очевидным, что у нас был этот зверь с высокой мощностью, едущий 25 миль в час в школьной зоне. Похоже, то, что мы здесь используем, нуждается в большем контексте, не только из ячейки, но и из всего проекта, знаете ли, ему нужно уметь делать два шага, три шага и так далее. Так что одна сторона — это модели, а другая — то, что это просто не работало. Честно говоря, я думаю, что данные — это уникально сложная среда, в которой можно попытаться сделать хороший одноразовый преобразование текста в SQL или текста в код или текста в ответ, потому что это итеративно, и это связано с уточнением и оценкой ответа, изменением и поворотом и углублением в кроличью нору. И поэтому я думаю, что мы очень усердно работали и поняли, что мы буксуем, и этот более гибкий подход, очевидно, был необходим. >> И какие вопросы люди задавали или хотели задать, будь то в одном выстреле или в агенте, который появился позже? Было ли это создание блокнота? Был ли это получение ответа? Что вы видели, как люди делали? >> Да, это все вышеперечисленное. Я имею в виду, это круто работать с данными в целом, я думаю, но также и работать с таким гибким продуктом, как Hex, заключается в том, что люди задают вопросы, начиная от того, сколько виджетов мы продали на прошлой неделе, и они просто хотят знать число, до «создай мне сумасшедшую предиктивную модель того, как наши автомобили ездят в снежных условиях, когда температура такая». И у нас такой дикий спектр клиентов, и они все создают сумасшедшие сложные вещи в своей области. И Hex, я не знаю, насколько рано вы были пользователем, но задолго до всего этого ИИ-штуки, основное обещание Hex заключалось в том, что вы делаете этот блокнот, вы строите всю свою логику, а затем все там становится строительным блоком для создания этого приложения, которое намного более гибкое, чем панель управления, и поэтому было довольно забавно, когда мы начали работать с агентом, потому что Hex всегда был этим инструментом, который приходил и задавал ваши самые сложные, самые сумасшедшие, самые гибкие вопросы и углублялся, и я думаю, что из-за ограничений модели и системы, ИИ-штуки всегда были так тесно ограничены по сравнению со всем рабочим процессом, который пользователи хотели ответить. Это как будто вы приходите, у вас есть эта огромная вещь в голове, и вы говорите: «Хорошо, я буду работать с ИИ, и мне нужно задавать ему крошечные кусочки». И я думаю, что самое интересное в агенте блокнота — это то, что да, клиенты приходят и говорят: «Хорошо, мы только что запустили эту новую функцию, создай мне отчет о том, как пользователи, имеющие к ней доступ, относятся к ней». И это то, что агент блокнота будет работать около 20 минут и даст ответ не только на это, но и на многие подвопросы, которые возникают по пути. >> Что он делает и как он это делает? Он пишет ячейки блокнота, которые затем выполняются? >> Агент блокнота работает в блокноте почти исключительно, за одним исключением: мы позволяем ему запускать временные запросы SQL, которые не отображаются в блокноте. Но вся остальная работа, которую он выполняет, в некотором роде способствует созданию этого артефакта, который пользователь может отслеживать по мере его выполнения, и который он может в конечном итоге использовать для создания какого-либо отчета, который он может использовать или отправить кому-то еще, или что-то в этом роде. Я забываю точное слово, но Барри, наш генеральный директор, пошел на какой-то летний лагерь для венчурных капиталистов, и я думаю, там был Сатча Наделла, и он сказал что-то вдохновляющее о том, сколько кнопок в Microsoft Word на всех его панелях инструментов. И это как будто агент должен уметь использовать все это. Как будто вся мощь этого очень сложного инструмента должна быть всего лишь в одном запросе. И я думаю, что мы пришли в Hex или к созданию агента блокнота именно с этой мыслью, что это сложный мощный инструмент для технических пользователей, и у него есть миллион маленьких кнопок и вещей, которые нужно сделать. Можем ли мы просто не менять ничего из этого, не вводить никаких новых возможностей. Можем ли мы просто сделать все это доступным через простой естественный язык? >> Я думаю, что агенты, которыми пользуется большинство людей, — это кодирующие агенты, и они тоже своего рода итеративны, верно? Как вы рассматриваете различия и сходства между агентами данных и кодирующими агентами? Я думаю, здесь есть две большие вещи. То, о чем я говорил раньше, заключается в том, что большая часть того, как я кодирую, особенно сейчас, когда модели намного более способны, вы сначала намечаете план, и он выполняется. Вы пишете спецификацию, создаете ее, и она ее создает, а затем вы получаете ее, и вы говорите: «Потрясающе». Вы либо говорите «да», либо «нет». И я думаю, что когда вы занимаетесь хорошей наукой о данных или хорошим анализом данных, есть много точек принятия решений по ходу проекта, в которых вы не просто говорите «хорошая работа, плохая работа», а говорите: «О, это интересно». Стоит ли нам посмотреть на это так или, о, я думаю, мы разделим это? Видим ли мы другую тенденцию? И я думаю, что это то, что опять же действительно не подходит для простого «вопрос-ответ». И поэтому я думаю, что агенты действительно решают эту проблему. И я думаю, что вы можете видеть по блокнотизации, принятию ее. И если вы когда-либо пробовали, это довольно замечательный опыт для такой работы. Я думаю, что самая большая проблема, которая остается на переднем крае, заключается в том, что все эти точки принятия решений очень трудно проверить и подтвердить результат. И я думаю, что кодирование все больше становится очень проверяемой задачей, верно? И именно поэтому модели становятся намного лучше в этом, потому что они могут обучаться на этом с этим проверяемым вознаграждением. И вы говорите: «Создай панель управления с этими пятью кнопками», и она это делает. И вы говорите: «Есть пять кнопок, и они работают». И, возможно, код за кулисами не очень хороший, но задача выполнена правильно. И я думаю, что с данными это гораздо менее ясно, и это на самом деле большая проблема: как проверить точность этого вопроса и, следовательно, как обучить модели быть очень хорошими в этом, и как использовать их в вашей системе? И поэтому я думаю, что это все еще своего рода интересная часть головоломки, в то время как я думаю, что агенты по сравнению с одноразовым запросом решили более раннюю часть головоломки «интересный ИИ-данные». Я хочу поговорить больше об этом этапе оценки позже, но, возможно, последний вопрос высокого уровня. Какие еще агенты, кроме агентов блокнота, вы создаете? И когда мы говорили раньше, вы сказали, что все это, возможно, сливается каким-то образом. Я бы хотел услышать больше об этом. >> Это все очень изменчиво в нашей кодовой базе прямо сейчас. Мы начали с агента блокнота, о котором мы только что говорили, и это было очень похоже на «вот что-то, что уже существует, и нашим пользователям это очень нравится и приносит огромную пользу, и можем ли мы просто сделать работу с этим проще, в основном, и автоматизировать ее с помощью этого агента. Следующим шагом было создание чего-то, и это продукт для технических людей, которые, знаете ли, комфортно работают в блокноте с SQL и Python, и, конечно, как только вы сделаете его более доступным, нетехнические люди тоже начнут это делать, и поэтому у нас есть много нетехнических людей, которые сейчас работают в блокноте над созданием сложных проектов, но есть другой демографический сегмент в данных, это настоящие «самообслуживающиеся» люди, которые хотят задать вопрос и получить ответ, и поэтому наш второй агент, который мы называем threads, действительно очень, очень, очень похож на агент блокнота, но это своего рода более абстрактный диалоговый интерфейс. >> Так просто чат. >> Именно. Он выглядит гораздо больше как разговор в ChatGPT, но по пути, знаете ли, появляются эти интерактивные и исследуемые артефакты данных, так же, как и в любой другой части Hex, но весь код был своего рода абстрагирован и скрыт. И он ведет себя немного иначе. Это не вопрос-ответ. Это вроде как вопрос, куча всего, возможно, продолжение, ветвление, кроличья нора, а затем, наконец, ответ. Но он предназначен для того, чтобы вы заходили с вопросом и хотели получить ответ. В то время как агент блокнота гораздо больше связан с созданием какого-то сложного неизвестного отчета или глубоким погружением во что-то. Мы также представили некоторые возможности семантического редактирования ранее в этом году, где вы можете писать семантическую модель непосредственно в Hex, а также импортировать их из, знаете ли, dbt или чего-либо еще, и мы также представили модель там. Интересное в этой модели не столько видимые возможности, сколько сбор контекста, который она выполняет, чтобы иметь возможность точно вносить вклад в ваши семантические модели. Мы говорили об унификации, но мы очень рано дали агенту семантического моделирования возможность читать множество других артефактов из рабочей области Hex, которые могли бы, знаете ли, раскрыть интересные вещи, которые делают люди, и поднять их в модель, и теперь это возможность, которая распространяется на всех агентов в качестве первой стороны. >> И когда вы говорите «другие артефакты», это как другие блокноты и тому подобное, что создали люди, которые могут информировать? >> Да, блокноты, другие потоки, разговоры, всевозможные части контекста внутри Hex. Это, я думаю, наша большая информационная архитектурная задача — выложить этот граф всего контекста, который является своего рода семантической моделью, основанной на хранилище, пользователь говорит что-то в потоке, администратор говорит что-то, как все это объединяется и синтезируется. Так что у нас на самом деле за кулисами есть агент контекста, который помогает синтезировать все это. У нас есть агент «чат с вашим приложением». Так что, если вы создали приложение для данных поверх вашего блокнота, у вас есть очень похожий на потоки опыт и с ним. И да, все это, по сути, стремится к тому, чтобы стать одним и тем же. >> Одно и то же с какой точки зрения — с точки зрения UI/UX? С точки зрения основной системы и архитектуры? >> Я думаю, что UI/UX — это часть, которая сейчас более неопределенна и интересна. Я думаю, что это возможности, которые есть у агента. Если окажется, что, как ни удивительно, вы взаимодействуете с чем-то, что выглядит довольно похоже в одном и том же продукте в разных местах, вы ожидаете, что у вас будут те же инструменты, возможности и доступ. И наши первоначальные агенты были совершенно разными вещами. И поэтому люди говорили: «О, почему потоки могут делать это?» Но, например, почему потоки не могут писать на Python, а агент блокнота может? И почему агент семантического редактирования может, знаете ли, читать мои другие проекты, а агент блокнота не может? И поэтому просто объединение всего этого вместе, что оказало интересное влияние на уровне кода на то, как мы организуем наши инструменты, подсказки и навыки в пакеты. Мы называем это «возможностями». >> Отличный переход. Давайте углубимся в это. Как эти агенты, возможно, агент блокнота? Как это выглядит под капотом? >> Существует своего рода высокоуровневый рабочий процесс, который выполняется агентом блокнота с множеством подзадач. Мы построили свой собственный оркестратор для выполнения всего этого. Возможно, позже мы поговорим о том, как мы в конечном итоге перешли от этого мира, ориентированного на один выстрел, к этому миру, ориентированному на длительную работу агентов. Когда я думаю об агенте, простейшая форма — это, как я думаю, LLM, работающий в цикле, вызывающий инструменты. Это, по сути, то, что у вас есть, или у вас есть более предвзятые рабочие процессы вокруг этого? >> Это, по сути, то, что у нас есть. Предвзятость в основном связана с контекстом. >> Отлично. Как работает контекст? >> Я думаю, мы разбиваем наше понятие контекста на динамический и статический контекст. >> И затем разные агенты, которые вы предоставляете, имеют разные наборы возможностей, по сути. Пока что, хотя мы исследуем, как это работает, когда у них очень похожие наборы возможностей. Но да, возможности объединяют инструменты, статический контекст, подсказки, а также некоторые странные эзотерические, причудливые вещи, такие как поведение в последнем повороте, как должен работать агент при завершении своего проекта. Я думаю, что, как я сказал ранее, фактический высокоуровневый цикл агента, я имею в виду, это тонкая инженерия, но она действительно сводится к простому запуску LLM в цикле, а интересное — это конвейер сбора контекста, а затем все эти причудливые мелочи о том, как он работает в последний раз, как он знает, когда закончить, как долго мы позволяем ему идти, все эти интересные вещи, как он работает в последний раз. Я думаю, что это одна из вещей, которую мы всегда пытались настроить и подкорректировать, чтобы она правильно завершалась. И я думаю, что на самом деле это довольно интересно с более длительными задачами, более способными агентами, уплотнением, которое становится чем-то, более длинными окнами контекста. Я запускаю свои кодирующие агенты вечно сегодня. Я надеюсь, я хотел бы, чтобы не было последнего поворота. Я хочу, чтобы он продолжался. И сегодня мы все еще применяем жесткий потолок на количество итераций. И поэтому, если он находится в середине чего-то, когда он достигает этого, мы вынуждаем его завершиться определенным образом из любопытства. >> Вы знаете, вы делаете эти технические выборы, когда модели находятся на определенном уровне возможностей. И когда у вас есть пять таких, их легко продвигать по мере того, как катится мяч. Но я думаю, когда у вас их 500, я чувствую, что каждый день мы просыпаемся и понимаем, что есть эта вещь, которая сдерживает агента. И почему? Это вроде как, о, ну, знаете ли, это раньше помогало агенту. Я думаю, что замечательное количество вещей, которые мы когда-то очень гордились тем, что создали, и которые были фактически необходимы, теперь сдерживают агента. На самом деле, на этой неделе мы работали над тем, чтобы выяснить, можем ли мы удалить эту очень сложную систему, которую мы построили для изменения того, как наши агенты видят статические идентификаторы артефактов в Hex, будь то ячейки, проекты, соединения данных и т. д. У нас есть миллион таких вещей, у всех них есть статический идентификатор, длинные уникальные номера, и в более ранних версиях моделей, на которых мы построили первые агенты, был своего рода потолок, после которого они начали галлюцинировать эти идентификаторы или выдумывать их или менять местами. И поэтому, если у вас был блокнот с более чем 50 или 60 ячейками, вы начинали получать сумасшедшее поведение. Мы построили эту сумасшедшую сложную систему для сопоставления коротких ссылок и идентификаторов. И это своего рода фундаментальная часть агентов. И только на этой неделе кто-то провел оценку и сказал: «Да, нам это больше не нужно. Они в порядке». И мы всегда исправляем ошибки и разбираемся с этим реестром компенсации. И поэтому, вероятно, еще пять примеров на этой неделе. И это то, когда вы входите в хорошее и плохое в создании собственной вещи. Мы построили свою собственную очень настраиваемую систему оркестрации. Она позволила нам год назад компенсировать этот серьезный недостаток модели и построить на очень низком интимном уровне это сопоставление, которое позволило нам построить и выпустить агент блокнота и масштабировать его, и он стал этой невероятной вещью и изменил траекторию продукта Hex. Но теперь это технический долг, багаж, ненужный, и очень трудно избавиться от технического долга, когда он существует. Когда вы вносите эти изменения в систему, они инкрементальны, или был ли когда-нибудь момент, когда вы сказали: «Эй, мы просто полностью перепишем эту систему. Это будет агент v2, агент v3». И я полагаю, что в эти моменты вы рассматривали возможность использования готовой системы или не создания ее самостоятельно? И какие были соображения, и как вы об этом думаете? >> Мы рассмотрели множество инструментов и технологий оркестрации и приняли это решение в основном на основе того, что все движется очень быстро, и мы хотели иметь возможность продолжать двигаться быстро с ними на наших собственных условиях. Даже если это означало нести на себе большую часть этих накладных расходов на обслуживание на постоянной основе, в фоновом режиме, незаметно для наших пользователей, мы мигрировали все из этого очень ориентированного на один выстрел потока к чему-то на основе Temporal, которое имеет надлежащую оркестрацию рабочих процессов длительной работы. Это была огромная задача, и, я имею в виду, худшая часть — это то, что вам приходится поддерживать две вещи одновременно, и, знаете ли, мы всегда проходим через две вещи одновременно, когда мы вводим новую версию чего-то, но в конце прошлого года мы перешли к этому новому, лучшему миру, который с тех пор позволил нам создавать все эти другие агенты и тому подобное. Это не было настоящим препятствием, но это было своего рода самоналоженное препятствие для создания других агентов: мы хотим фактически работать в правильной структуре, прежде чем делать это. Вы упомянули ранее, что агент блокнота должен уметь делать все в блокноте, что может сделать человек. Я полагаю, это много инструментов, и теперь вы говорите о комбинировании нескольких агентов. Как вы справляетесь с таким количеством инструментов? >> О, так много инструментов. Я думаю, это слишком много инструментов. >> Сколько это инструментов? >> Не совсем 100 000, но примерно столько же токенов в наборе инструментов, что слишком много, чтобы быть ясным. Это слишком много инструментов. Я не горжусь этим. >> Одна вещь здесь — это уменьшить количество инструментов и упростить и консолидировать, но другая вещь — это реализовать какой-то поиск инструментов или извлечение инструментов, что становится большой проблемой для основных кодирующих агентов, которые должны, знаете ли, обращаться к множеству MCP. Я думаю, если у вас есть куча установленных MCP, облачный код теоретически может использовать тысячи инструментов. Поэтому мы внедрили поиск инструментов, что помогло снять это давление. Я не обязательно претендую на то, чтобы быть экспертом в этом. У нас есть только наш эмпирический опыт, но у нас был инструмент для создания ячейки диаграммы, инструмент для обновления ячейки диаграммы, удаления, все эти своего рода очень нормализованные наборы инструментов, и всегда немного интересно и неясно, если вы не оцениваете и не тестируете. Нужно ли повторять одно и то же в каждом из этих инструментов? Можно ли сказать это в системной подсказке? Является ли сказанное в одном инструменте таким же хорошим, как сказанное во всех? И это вроде как, но мы в основном видим, что мы еще не везде это сделали, потому что это просто работа. Но я провел тест и запустил оценку, как мы можем консолидировать все это в один инструмент диаграммы, и это работает нормально. Так что есть такого рода бессмысленный взрыв инструментов. Но также есть большое искушение вводить множество мелких инструментов, когда у вас есть продукт, который не работает на уровне кодирования командной строки. >> Вы думали о том, чтобы он работал на уровне кодирования командной строки? Потому что вы, вы также уже запускаете его в среде блокнота, верно? Мы делаем, что не совсем командная строка. Он работает в своего рода ядре IPI, не совсем, но похоже. >> Но у него есть среда кодирования с функциями. >> Он может выполнять произвольный код Python, и тем не менее мы создали для него инструмент для проверки того, установлен ли определенный пакет в среде или нет. И часть причины этого заключается в том, хотите ли вы, чтобы агент запускал быстрый эфемерный инструмент, или вы хотите, чтобы он писал код Python, который, знаете ли, становится ячейкой и виден пользователю, например, должны ли мы позволить ему запускать эфемерный код Python, и тогда вы столкнетесь со всеми интересными поведением, связанным с тем, как только вы позволите агенту, особенно современным агентам, запускать секретные эфемерные запросы SQL и код Python, они действительно любят в наши дни быть очень уверенными в себе, прежде чем вернуться к вам, и поэтому, особенно модели серии GPT 5, если вы зададите GPT 5.4 вопрос, и это неправильный вопрос, и он оказывается очень сложным. В зависимости от того, как он себя чувствует, он может запустить около 50 эфемерных запросов SQL, просто чтобы быть очень уверенным, прежде чем он фактически начнет выполнять какую-либо реальную работу. И поэтому у этих вещей есть компромиссы. Так что да, мы могли бы дать ему очень общие инструменты для простого запуска кода, но введение очень специфических инструментов позволяет нам вводить эти виды поведенческого руководства о том, когда использовать этот инструмент или когда предпринять это действие, я полагаю, что вы не обязательно имеете, если вы просто говорите: «Вот инструмент Python, и используйте свое лучшее суждение». >> Так что я не знал этого, но весь код, который он пишет, по сути, отображается как ячейка в блокноте. >> для агента блокнота. Почти весь код, который он пишет. Да. >> Но у него есть этот эфемерный инструмент SQL. Мне было бы интересно узнать, почему это так и как вы видите его использование? >> Это возвращается к тому, что я сказал ранее о том, насколько важно иметь возможность выполнять много работы при ответе на вопрос о данных. Если вы спросите, было ли у нас больше пользователей этой функции продукта на этой неделе, чем на прошлой, и если у вас есть хорошо смоделированная красивая семантическая модель, то, возможно, это просто мгновенно, но у многих людей нет, и я думаю, что многие люди, которые думают, что у них есть, тоже нет. И, знаете ли, вам может потребоваться провести некоторые быстрые проверки и сказать: «Хорошо, действительно ли эта таблица содержит нужную мне информацию? Мне нужно объединить две таблицы. В каком формате находятся данные в этом столбце?» И есть все эти вещи, которые вы можете обнаружить итеративно путем отладки, основанной на ошибках. Вы можете выбросить запрос SQL и получить ошибку, он выглядит неправильно, и уточнять, уточнять, уточнять. Но мы обнаружили, что это более эффективный рабочий процесс и лучше для пользователя, если вместо этого он выполняет эти очень маленькие, атомные, эфемерные исследовательские запросы. А затем, как только он соберет достаточно информации, чтобы правильно написать основной запрос с первого раза, он напишет его, поместит в блокнот, и это гораздо лучший опыт для пользователя, чем необходимость многократно уточнять и итерировать этот запрос. Но опять же, как и в большинстве вещей, которые вы даете агентам, это имеет непреднамеренные последствия, где мы постоянно боремся со случаем, когда пользователь задает действительно простой вопрос, а он просто сообщает вам ответ, потому что он запустил маленький секретный SQL-запрос, а пользователь говорит: «Где диаграмма? Где доказательство?» Агент говорит: «Поверьте мне на слово». И поэтому выяснение этих маленьких поведенческих крайних случаев — это всегда то, когда вы вводите новый инструмент, который не просто пишет код. Но также, знаете ли, я много использую codecs, я люблю использовать codecs для кодирования, и codecs имеют особую склонность, или GPT 5.4, я полагаю, к запуску сумасшедшего bash, и я заметил, что он пишет команды pearl. Я вроде как смутно понимаю, что происходит, когда он пишет bash, но не совсем. Но вместо того, чтобы запускать команды pearl, я понятия не имею, что он делает. И я думаю, что это снова одна из тех вещей, когда это вроде как, хорошо, может быть, сделать это для аудитории технических агентов блокнота, но у нас есть эти агенты, которые работают в разных контекстах для разных пользователей. И я думаю, что многое из этого сводится к UX, чтобы точно знать, что делает агент, потому что они занимают время, и они думают, и они размышляют, и они запускают кучу инструментов. Я думаю, что инженеры, руки которых отрываются от клавиатуры, говорят: «Да, работайте 50 минут, и мне все равно, что вы делаете, главное, чтобы вы делали это правильно». И я думаю, что, возможно, бизнес-стейкхолдеры тоже скоро до этого дойдут, но я думаю, что больше, чем вы думаете, они на самом деле заинтересованы в отслеживании того, что происходит. >> Что вы показываете этим бизнес-стейкхолдерам? Вы показываете им каждую команду, которая выполняется? Вы сворачиваете их и показываете, как код Claude, знаете ли, размышляет или что-то еще, что у них есть? Я, возможно, считаюсь внутри компании своего рода клоуном-шутником, и я ненавижу эту маленькую штуку с размышлениями. Это мой самый большой Гринч, как Скрудж Макдак. Мы добавили какую-то версию, и я сказал: «Нет, нет, это как будто я не знаю, для некоторых это не объяснение. Я просто Гринч по этому поводу». Мы говорим «думаю, очень профессионально». Пока агент работает, мы показываем вам, что он делает, развернуто, а затем, когда он закончен, мы сворачиваем его, что, я думаю, на данный момент является хорошей парадигмой. Но я не знаю, играли ли вы с GPT53 codec spark или чем-то еще. Это новейший от OpenAI. >> Самый быстрый. >> Тест Cerebrus, по сути. Он настолько быстрый, что нет смысла показывать пользователю, что происходит. Нет способа реалистично показать пользователю, что происходит. Это как будто, и поэтому я исхожу из предположения, что это будет одна из тех вещей, которые мы сегодня считали очень крутыми, но через несколько месяцев мы будем отчаянно пытаться понять, как мы вырвем поведение «пользователь следит», потому что мы хотим разблокировать наших агентов, чтобы делать больше и, знаете ли, работать более многословно или делать, знаете ли, миллион вызовов инструментов параллельно, не перегружая пользователя. И я уже вижу, что это скоро станет точкой трения между UX и возможностями. >> А как насчет конечных результатов, которые создают агенты? Это ответ? Это ячейка блокнота или несколько ячеек блокнота? Это диаграмма? Я предполагаю, что это некоторая комбинация всего вышеперечисленного, но каково распределение, которое, по вашему мнению, люди используют для этого? >> Не будучи слишком большим фанатом Hex, я думаю, что это одна из крутых вещей в Hex — это такой гибкий продукт, и он всегда был таким гибким продуктом. Я думаю, что я раньше работал в Looker, до Hex, который является инструментом, позволяющим вам создавать панели управления и запускать исследователи, которые, по сути, являются диаграммами. Они выглядят одинаково. Я люблю Looker, на самом деле. Но одна из вещей, которая меня больше всего волновала в Hex, — это разнообразие отчетов и ответов, которые вы могли создавать. И я думаю, что мы перенесли это в мир агентов: агент threads, агент блокнота, вы можете создавать поистине все, что вы мечтаете, интерактивные приложения, которые вы нажимаете, и они запускают какой-то рабочий процесс и обновляют сумасшедшие формы, вы можете создавать действительно дикие вещи, но даже в threads это действительно зависит, и я думаю, что эта гибкость, если вы задаете вопрос, очень проста, я всегда пытаюсь заставить агента дать вам ответ с наименьшим когнитивным бременем. И поэтому, если вы говорите: «Быстрый вопрос, сколько пользователей у этой компании, приложения?» Вы просто хотите знать. Вы не хотите отчет. >> Думаете ли вы, что важно, чтобы агент «показывал свою работу»? >> Вот почему блокнот так хорош, и я думаю, почему мы так далеко и так быстро продвинулись с агентом блокнота, потому что, как известно, блокноты — это грамотное программирование. Это, по сути, их главная цель — иметь возможность самодокументировать работу, которая выполняется таким образом, который удивительно хорошо подходит для того, чтобы агенты могли писать код. И я также думаю, что есть своего рода ощущение, что когда вы пишете код с помощью ИИ для технического пользователя, есть своего рода ожидание, что они могут следить и проверять и подтверждать. Но когда вы делаете это для бизнес-стейкхолдера, который не знает SQL или не знает Python, это становится гораздо более философски иначе. >> Это Codex, запускающий команду Pearl, за которой я не могу следить. Я запускаю Codex с отключенными выводами. Так что я даже не знаю, что он делает. Я прошел мимо этого. Я думаю, что концепция «показывать свою работу» — это не правильная концепция для работы с данными с точки зрения цитирования и проверяемости. Я думаю, что это должна быть более сильная форма проверки или уверенности или точности. Это то, над чем мы сейчас работаем и пытаемся выяснить. >> Что это значит? Какие у вас есть идеи? >> У нас еще не так много всего выяснено. Есть один действительно очевидный замечательный способ сделать это в мире данных, а именно использовать семантическую модель. Если вы определите замечательную семантическую модель и позволите пользователям использовать ее в разумных пределах, вы, вероятно, можете быть относительно уверены, что они получают правильные ответы. Люди всегда найдут способ навредить себе. Я бы всегда навредил себе с идеальными семантическими моделями Looker. >> Но это один из способов узнать, и тогда вам не обязательно нужен этот отдельный хитрый цикл проверки, потому что вы, по сути, всегда работаете с доверенным, управляемым контекстом как с одной половиной. Мы делаем это с семантическими моделями. Мы делаем это с своего рода одобрением или проверкой администратором различных активов и т. д. Но модели любят писать SQL и код. И иногда вам нужно выйти за рамки семантической модели, потому что в этом вся суть задачи. И я думаю, тогда вы попадаете в этот интересный мир, где проверка и проверяемость становятся очень трудными для данных. И часто это очень расплывчато, что такое истина, в зависимости от того, как две команды определяют метрику или обновление конвейера данных меняет число из-под вас. И поэтому я думаю, что это просто очень сложная область. Я думаю, что способ, которым мы будем решать это, способ, которым мы уже решаем это, — это множество циклов обратной связи от пользователя обратно к команде данных, наблюдаемость, фактически встроенная в платформу. У нас есть новая студия контекста, которая, по сути, дает администраторам команды данных обзор того, какие вопросы задают люди, какие ответы они получают. Мы помечаем, используя отдельный LLM в качестве судьи, случаи, когда мы думаем, что что-то могло пойти не так, или когда агент мог быть сбит с толку, или есть предупреждение, которое противоречит вашей семантической модели. Сегодня все эти вещи выполняются как своего рода пост-действие и дают администраторам возможность улучшить контекст, который позволяет агенту работать лучше. Так что это своего рода система «человек в цикле» для модели, которая что-то делает. Пользователь, возможно, получает неправильный ответ. Он помечается. Команда данных узнает об этом, они могут улучшить руководство или семантическую модель, чтобы это не повторилось. Возможно, вы сообщите пользователю, что произошло, и т. д. Как только вы построите систему «человек в цикле», возникает вопрос: как мы начнем автоматизировать это и масштабировать это и сделать так, чтобы это работало лучше, быстрее с ИИ и агентами в цикле? Будет ли это выглядеть как агент, обновляющий сам контекст? >> Да, мы работали над этим агентом контекста внутри компании и прототипировали, как это может выглядеть, чтобы агент мог это делать. >> Это то, что вы бы назвали памятью для агентов Hex? >> Отчасти. Я думаю, что интересное в памяти и в том, как она играет в этом, заключается в том, что память, как ее понимают пользователи, я думаю, это очень пользовательский концепт. Ваша память ChatGPT помнит ваши разговоры, и то, что вы сказали ей, что у вас есть собака по имени Ровер, поэтому, когда вы спрашиваете «моя собака больна», она говорит: «О, мне жаль слышать о Ровере». Я думаю, это менее значимо и почти страшно на самом деле. Я знаю, почти очень страшно для команд данных и администраторов, которые беспокоятся, что произойдет противоположное тому, о чем мы только что говорили, в пределах небольшой памяти пользователя, где пользователь задает вопрос и получает неправильный ответ или что-то еще, или пользователь говорит агенту: «Нет, это неправильно. Эта метрика определяется так». И, возможно, этот пользователь ошибается или устарел, и это сохраняется в памяти, и тогда у вас есть эти своего рода противоречивые уровни контекста. >> Потому что разные уровни могут быть на уровне пользователя, на уровне команды или сколько? >> Да, потенциально даже больше. >> Потенциально. И команда данных устанавливает эти руководства и семантические модели. Примирение, как, я думаю, одна вещь, с которой агенты и модели сегодня справляются очень плохо, — это противоречивые, диссонирующие ситуации. Мы фактически провели интересную оценку этого, и она на самом деле не обязательно смотрела на точность в отношении того, как она может разрешить противоречивую ситуацию с советами, а просто на количество времени, которое она тратит на размышления. Ваш агент, знаете ли, Claude Sonnet 4.6, на котором мы это запускаем, и он на самом деле работает довольно эффективно и быстро до определенного момента, а затем, если вы вводите фрагмент противоречивого контекста, он противоречит другой информации, которую он имеет, он потратит 30 минут на размышления, говоря: «Подождите, но дайте мне посмотреть. Хм, на самом деле», и войдет в этот сумасшедший своего рода режим коллапса. И я думаю, что это часто происходит на гораздо меньшем уровне, и поэтому я думаю, что без секретного соуса или ответов я думаю, что это то, с чем мы только начинаем мириться: администраторы должны иметь возможность предоставлять очень сильное управление и руководство. Один из способов сделать это — семантическая модель, и тогда все будет на рельсах, но если вы сделаете это, вы упустите этот славный мир более гибкой работы. Есть своего рода «о, как будто» на горизонте, это как будто, знаете ли, что если вы можете просто сказать LLM вещи, и он будет осторожен? Это, по сути, то, что люди делают с руководствами и файлами правил и т. д. >> У ваших агентов есть концепция навыков в этом смысле? >> У них есть. Мы называем их «руководствами», но они моделируются точно так же, как навыки, с постепенным раскрытием. Агент, когда он работает, может видеть все доступные руководства из этой рабочей области, а затем может извлекать их и читать их во время работы. >> И именно так эта память передается агенту, или часть ее также вставляется в системную подсказку, и что определяет, что куда идет? >> Все это сейчас тестируется. Пока что мы держим память отдельно от этих других источников контекста, которые в большей степени управляются командой данных и администраторами. Я думаю, что основной цикл обратной связи Hex, улучшающийся сегодня, обусловлен командой данных. Это пользователи, которые выполняют работу, их работа или своего рода выхлоп их работы, который предоставляется команде данных в интерфейсе, который позволяет им замечать ошибки, улучшать руководства, модели, контекст хранилища и т. д. И тогда этот цикл обратной связи поворачивается, когда человеческая память является сбивающим с толку фактором, который может вносить всевозможный шум в этот цикл на уровне пользователя сегодня. И поэтому мы очень продуманно подходим к тому, как мы его развертываем. Я думаю, у нас еще есть тестирование. Вы несколько раз упоминали наблюдаемость и оценку в форме LLM как судьи. Как вы думаете о наблюдаемости, которую вы имеете как разработчики агента, по сравнению с тем, что вы предоставляете администраторам или людям в, я думаю, это был контроль агента или >> студия контекста. >> Студия контекста. Да. Это то же самое, что вы используете внутри компании? Или это другое? Каковы сходства? Каковы различия? Моя горячая ставка внутри компании, о которой люди всегда спорят, заключается в том, что они должны быть одинаковыми. >> Так что я предполагаю, что они не одинаковые. Это горячая ставка. >> Они не одинаковые. Я построил внутреннюю систему наблюдаемости и экспериментов. Я мечтаю о прекрасном утопическом будущем, в котором мы используем те же инструменты, что и наши пользователи, чтобы понять, что делают агенты в продукте Hex, и как мы можем сделать их лучше. И я имею в виду это для наблюдаемости и оценки. Мы только начинаем думать о том, как мы предоставляем инструменты оценки пользователям. У нас есть своего рода очень рудиментарная настройка для этого. Сейчас, если вы редактируете свой контекст, вы можете запускать некоторые тесты. Я хотел бы, чтобы эти вещи были конвергентными. Сегодня инструменты наблюдаемости, которые мы построили, я построил первую версию их в прекрасные довременные времена, до того, как мы выпустили это для каких-либо пользователей, и это было только внутреннее использование, и у нас были полные привилегии паноптикума, и это был открытый сезон на все данные, и мы все еще имеем это в некоторой степени для нашего внутреннего использования, которое очень полезно, чтобы иметь возможность видеть даже ваше собственное локальное использование для разработки, чтобы иметь возможность глубоко интроспектировать все это. Я думаю, что, очевидно, мы не можем сделать это для реальных пользовательских данных. Б. Я не знаю, хотят ли администраторы или команды данных, чтобы их работа заключалась в просмотре всех разговоров и синтезировании всего этого. Мне кажется, это работа агента. И поэтому, когда я думаю о наших внутренних инструментах наблюдаемости и о том, куда они движутся, а также о том, куда движутся инструменты, ориентированные на обратную связь в студии контекста, которые мы предоставляем нашим пользователям, я думаю, они, вероятно, должны стать более агентическими или, по крайней мере, более высокоуровневыми. Вещи, которые мы можем видеть о данных использования из производства, — это кластеры проблем, которые возникают, виды сбоев, которые возникают в агенте, и каковы эти кластеры и как они меняются со временем. Так что вы можете видеть это, потому что вы запускаете некоторые LLM как судьи, которые кластеризуют теги, а затем, возможно, вы кластеризуете эти кластеры или что-то еще, а затем это данные, к которым у вас есть доступ, которые обрабатывают все базовые трассировки как будто вы не имеете этих необработанных данных, у вас есть только своего рода кластеры или идеи от LLM. >> Именно так. Есть пост в блоге от Anthropic. Это об этом. >> Мы фактически встроили это в lang. Да, я думаю, это очень, да, отличная идея. Защита конфиденциальности что-то что-то что-то. >> Да, именно. Я думаю, что это снова одна из тех ситуаций, когда мы построили свой собственный стек наблюдаемости и оценки здесь из-за этого. Я не знаю, буду ли я комментировать, действительно ли это правильно или нет, но это своего рода воспринимаемая потребность в возможности двигаться очень, очень, очень быстро и эта неопределенность относительно того, как будет выглядеть агент или продукт, или модель через 3 месяца в будущем, и страх ограничения, если мы не построим свою собственную вещь, и налог огромен. Я провел большую часть прошлой недели, делая очень мало, кроме обновления и рефакторинга и работы над нашей системой оценки, чтобы сделать ее более удобной для пользователя. Наша система оценки внутри компании, мы называли ее «коробка для обуви», которую я пытался, я пытался n >> потому что я не хотел, чтобы она длилась, я хотел, чтобы она была как коробка для обуви, мы просто складываем все наши квитанции и кладем ее под кровать, а затем она прижилась и все еще существует. Коробка для обуви, которая предоставляет некоторые возможности оценки, всегда была своего рода инструментом «высшего жречества», доступным только инженерам ИИ, которые активно итерировали агентов и подсказки. Ее было очень трудно использовать, и у нее был ужасный UX, и это был своего рода «много ножных ловушек», так что вам нужно было знать, как ее использовать, чтобы на самом деле хорошо ее использовать. Но теперь грань между инженером ИИ и любым другим инженером сильно размыта внутри компании. У нас есть все эти агенты. Большинство наших новых функций носят агентический характер или каким-то образом
связанные с ИИ, и все хотят запускать оценки и проверять, улучшает ли функция, над которой они работают, или ухудшает ли она что-либо, или, знаете ли, вы проводите большую рефакторизацию и просто хотите дважды проверить, что ничего не испортили, и поэтому мы перерабатываем систему оценки, чтобы сделать ее действительно, действительно простой для любого в компании, чтобы запускать оценки изменений, которые они внесли. Два вопроса, которые вы хотите задать: оказало ли мое изменение желаемый эффект? И оказало ли мое изменение какие-либо нежелательные эффекты? И возможность ответить на эти два вопроса — это цель для любого в компании. Как именно выглядит этот процесс? Есть ли один большой набор данных из тысячи примеров, и у всех у них есть истинная истина, и вы запускаете его против этого набора данных, а затем сравниваете его с истинной истиной с помощью LM в качестве судьи, или это отличается от этого, и каким-то образом ответвляется от этого? >> Попал в точку. >> Хорошо. Сколько, сколько примеров в вашем наборе данных для оценки? Например, это то, о чем мы часто слышим, спрашивая, насколько большими должны быть мои наборы для оценки, прежде чем, и, возможно, интересно услышать, развивалось ли это со временем. >> У меня много мнений по этому поводу. Я думаю, что, как правило, большинство наборов для оценки плохие, если над ними активно не работают. Я думаю, что почти или, по крайней мере, в области данных, почти каждый раз, когда я заглядывал под капот какого-либо бенчмарка данных или оценки, я был очень разочарован тем, что увидел. Я видел, я не хочу никого порочить, но просто сортировать, но правило применяется ко всем, кого я видел, плохая истинная истина, некорректная истинная истина, проблематичная оценка, некоторые люди пытаются проводить детерминированную оценку, что является доблестным стремлением, но в вашем скрипте есть ошибки или он не принимает процент в качестве десятичной точки, и все такое прочее. Некоторые вопросы просто плохие или нерепрезентативные. Существует очень популярный набор бенчмарков, который мы на самом деле используем в немного измененном виде, и он довольно сложен, если вы не знаете, как бы, единственный секрет бенчмарка. И многие, многие, многие вопросы в этом связанном с данными бенчмарке вращаются вокруг того, правильно ли агент обрабатывает пустой массив как то же самое, что и null, или нет. И есть это эзотерическое крошечное правило где-то в руководстве, и это делает или ломает. И это не, это не бенчмарк данных. Это как иголка в стоге сена, как бенчмарк, учитывающий контекст. И я думаю, что многие бенчмарки смешивают это. Речь шла конкретно об аналитическом рассуждении и способности работать с данными. Я думаю, что многие бенчмарки смешивают синтаксис SQL и поиск, и вот это вот иголка в стоге сена с реальным желаемым аналитическим поведением и научным рассуждением, которое вы хотели бы иметь возможность делать. Этот процесс, который я описал в самом начале, где вы получаете промежуточный ответ, и теперь у вас есть точка принятия решения, например, принимаете ли вы его? Говорит ли это вам, что делать дальше? Отклоняете ли вы его? Я думаю, что это поведение очень трудно оценить, и большинство общедоступных наборов для оценки вообще не оценивают его. >> Как выглядит хороший набор данных для оценки? >> Ну, у меня есть некоторые мнения. Я думаю, что один из них заключается в том, что хороший набор для оценки должен быть настолько мал, чтобы вы, как заинтересованная сторона, могли его как бы держать в уме. Это может быть очень спорно. Я не знаю. Мне нравится знать, почему все мои наборы для оценки, например, у нас есть эти амбициозные наборы для оценки, на которых наши агенты работают очень плохо, на которых все агенты работают очень плохо, например, Opus 4.6 max получает около 20% на супер сложном. Я думаю, что этот набор для оценки гораздо полезнее, если я знаю почему, знаете ли, G72 EVAL, например, терпит неудачу, где есть эти четыре причины. И поэтому я действительно вручную создал все эти режимы отказа, ловушки, как я их называл, в которые я хочу, чтобы модель попала. И существует множество бенчмарков, подобных тому, о котором я говорил с пустым массивом. Это около 390, 470 тысяч оценок. Большинство из них — просто варианты этой одной уловки. И я думаю, что интереснее иметь пару уловок, которые вы можете держать в голове, а затем просто запускать на них тонны повторений, а не разбрасывать их по множеству разных случаев и усложнять вещи. Так что это одно мнение. Наши наборы для оценки составляют от 30 до 50 для этих очень, очень сложных случаев. Но опять же, мы запускаем на них несколько повторений. Я также думаю, что многие наборы данных для оценки сейчас больше не отражают тип работы, которую пользователи фактически выполняют. Они гораздо больше похожи на то, о чем я говорил раньше, на этот тип вопросов с одной попыткой, как викторина, где, например, сколько пользователей у нас было 16 апреля 2019 года? Можете ли вы синтаксически перестроить этот английский в SQL? >> Это как оценка модели кодирования на автодополнении, когда все пытаются попросить меня написать полноценные вещи. >> Да, именно так. И поэтому многие из наших самых интересных оценок — это оценки агентов в блокнотах, которые начинаются в середине очень сложного блокнота, который уже был агрессивно построен, и пользователь говорит что-то вроде: «Это странно». Это не то число, которое я ожидал получить. И оценка была тщательно составлена таким образом, что в данных и SQL-запросах, которые агент должен как бы распутать и исследовать, есть цепочка из трех ошибок. И просто взгляд на состояние, в котором находится блокнот, говорит о первой ошибке, но фактически скрывает вторую и третью ошибку. И поэтому это должен быть действительно тщательный процесс, чтобы фактически устранить все ошибки и получить ответ. >> Вы берете их из реальных траекторий или из того, что вы видите, или это полностью синтетические, вымышленные? У нас есть роскошь иметь тонны внутреннего использования Hex для реальных вещей, и я многое моделирую на основе этого, потому что данные — это сложно, и мы совершаем ошибки внутри. Кроме того, моя любимая оценка, на которой все текущие модели, которые я тестировал, потерпели неудачу, хотя новые модели терпят неудачу на ней дольше, — это внутренняя панель инструментов, реальная внутренняя панель инструментов о наших продажах, например, достижении квот AE. И я взял панель инструментов. Я намеренно ввел ошибку распространения, которая заставляет всех AE выглядеть так, будто они доминируют. Например, все находятся как минимум на 900% от квоты, например, убивают ее. Лучший квартал когда-либо. А потом вы спрашиваете агента: «Как дела у лучших исполнителей в этом квартале?» И каждый агент говорит: «О, боже мой, это лучший квартал когда-либо. Ваш бизнес процветает». Когда вы сравниваете это с прошлым кварталом, это как скачок, знаете ли? Например, у Джози 1200% от ее квоты. Например, они все в восторге. И я фактически протестировал, вы можете увеличить это до тысяч процентов от квоты, прежде чем модели начнут говорить: «Может быть, есть ошибка в конвейере точности данных или что-то еще», и почти ни одна, ну, буквально ни одна из них не ловит ошибку. Но если вы тогда скажете, что это не кажется правильным, им потребуется 10 секунд, чтобы поймать ошибку. Это то, что я считаю наиболее интересным для оценки. Я говорю очень грандиозно. У нас также есть совершенно нормальный набор обычных оценок, которые помогают нам понять, хорош ли наш продукт изо дня в день, и мы стараемся поддерживать разумный процент прохождения на них, и это помогает нам предотвращать регрессии и позволяет нам оценивать новые функции и т. д. Просто обычные вопросы по данным, на которые есть правильный ответ, и, возможно, есть грязный склад или что-то еще. Но тогда я также считаю интересным поддерживать этот очень амбициозный набор, который измеряет то, в чем модели сейчас очень плохи. И есть ряд случаев, подобных этому, где просто наличие человека в цикле для некоторых из этих вещей по-прежнему имеет очень большое значение в отношении способности агента как бы ловить ошибки или иметь этот своего рода интересный, как бы, их уши не встают так, как уши человеческого аналитика. И у нас есть несколько очень интересных оценок для этого. >> Говоря о моделях, поскольку новые модели выходят и становятся лучше, но также вводят новые возможности в API, как вы думаете о обновлении этих моделей, а также об обновлении оболочки вокруг этих новых вещей в API? >> Аналитика данных и наука о данных — это задача, требующая общего интеллекта, а не доменного интеллекта. И поэтому я думаю, что просто более умные модели — это здорово для нас и для наших клиентов. Поэтому мы всегда стараемся использовать самые умные, новейшие модели. >> Какие, по вашему мнению, это прямо сейчас? Open AAI и throttle. >> Opus 4.6 и GPT 54 чрезвычайно способны в нашей области. У них есть все эти ручки и рычаги для настройки, ползунки, и поэтому сложнее, чем я думаю, люди предполагают, сказать: «Это лучшее, то лучшее». Например, ну, GPT54 делает немного лучше, но занимает в два раза больше времени. И это как бы, ну, вы можете снизить усилия, и тогда это займет на самом деле вдвое меньше времени. Это как бы, ну, но тогда он не работает так хорошо. И я думаю, что усилия — это своего рода новая вещь, начиная с Opus 45, я думаю, и GPT53, обе эти лаборатории встроили эту концепцию усилий. Я думаю, что Open называет это соком внутри, что смешно. И это то, что я еще не до конца понимаю. Мы провели внутренний тест. У нас был своего рода выбор усилий, и полученные отзывы были: «Это работает?» Похоже, что это на самом деле не оказывает никакого эффекта, потому что иногда при низких усилиях модель путается и уходит в спираль, а иногда при высоких усилиях она, знаете ли, просто отвечает на вопрос, как будто. Итак, чтобы ответить на ваш первоначальный вопрос, мы всегда стараемся использовать последнюю самую умную модель, теперь мы всегда стараемся использовать ее с достаточными усилиями, чтобы она хорошо оценивалась, не заставляя наших пользователей ждать 10 минут, чтобы получить ответ на простой вопрос. Что становится все более интересным и сложным, я думаю, это то, что, возможно, вы имели в виду, все эти другие маленькие дополнения, которые приходят с ними, такие как API поиска инструментов или, например, серверное сжатие, и это все вещи, которые очень ценны для использования, а также своего рода боль в заднице для обслуживания, особенно когда мы построили все свое собственное. >> Так что вы делаете? Вы их используете? >> Мы делаем. Ну, мы используем их там, где они помогают. Я думаю, что частью преимущества наличия собственного и наличия оценки является то, что мы можем фактически сказать, что это помогает. Помогает ли окно контекста в 1 миллион токенов или вредит? Ну, это вредит на периферии, потому что вы не можете заполнить это окно, не понеся довольно серьезного интеллекта, или интеллект — это почти неправильное слово. Это как бы, модель начинает делать странные вещи на концах этого окна. Так что это нормально, мы хотим сжимать очень рано, но, знаете ли, доступ к модели с 1 миллионом токенов через какой-то бета-заголовок на самом деле ценен, чтобы мы могли сжимать при, скажем, 300 000 вместо 200 000, потому что мы обнаружили, что это лучше. Так что мы поддерживаем все эти вещи, когда это возможно. Я действительно думаю, что, разговаривая с лабораториями в эти дни, я думаю, что у них есть заинтересованность в том, чтобы вы использовали их проприетарные заблокированные вещи, и техника, техника психологической войны, которую, как мне кажется, они используют на нас, чтобы заставить нас использовать эти вещи, — это слова в распределении. И я еще не совсем знаю, что я об этом думаю, где они говорят, знаете ли, если вы используете SDK агента облачного кода, вы будете в распределении для того, на чем мы обучили модель, или Open, знаете ли, если вы используете наше, например, состояние серверного выполнения или что-то еще, вы будете очень в распределении для новых моделей, и я очень открыт к тому, чтобы это было правдой. Мне интересно, как быстро это выходит из окна, как только вы добавляете свой собственный инструмент для создания диаграммы или SQL-запроса, и это как бы, вы снова выходите из распределения или попадаете в странный случай с кодексом, где говорится: «К черту ваши инструменты, я буду использовать, например, Perl», так что я не совсем знаю, что я об этом думаю, но кажется, что это тенденция, верно? Это как бы, есть все эти маленькие кусочки, которые встроены в новые модели, и некоторые из них очень полезны, и мы стараемся их принять. Я думаю, что нам очень трудно думать о переходе от этого типа принятия по меню к фактическому вызову состояния, например, серверного >> потому что вы откажетесь от большого контроля, который вам нравится. >> Я думаю, потому что вы откажетесь от большого контроля, и я думаю, что на данный момент количественная выгода мне не совсем ясна. У меня еще нет сильной интуиции относительно того, насколько важно быть в распределении, потому что эти модели очень хороши в обучении в контексте, и я не знаю, я имею в виду, модель использует нашу оболочку довольно хорошо, и мне неясно, что еще большее нахождение в распределении может нам дать по сравнению с компромиссами быть немного более заблокированным. >> Вы бы описали себя как инженера агентов, как инженера ИИ? Что вы делаете изо дня в день и как вы туда попали? Я думаю, что моя официальная должность — инженер ИИ. Мне кажется, что я никогда по-настоящему не имел должности в Hex. Я был одним из первых сотрудников, присоединился, чтобы заниматься маркетингом, разработкой сообщества, техническим маркетингом для разработчиков и всем таким прочим. И когда вы присоединяетесь к этому в очень маленькой компании, где вы единственный маркетолог, вы в конечном итоге делаете очень много всего. И я занимался этим около 4 лет. И я думаю, что я всегда хотел быть инженером ИИ. Просто такой должности не существовало. Я всегда был техническим. Я всегда был в первую очередь практиком, специалистом по данным, не обязательно полноценным инженером. Но моя философия разработчика всегда заключалась в том, что вы не должны быть маркетологом. Вы должны создавать вещи, а затем говорить о них, и вы не должны говорить ни о чем, что вы не можете создать, потому что это то, что я называю ложью. Я предпочитаю более честную форму маркетинга. И поэтому я всегда был техническим, всегда очень интересовался ИИ. Я помог фактически создать нашу первую версию старых рабочих процессов преобразования текста в SQL с одной попыткой просто из интереса. И честно говоря, я не думаю, что я мог бы быть инженером ИИ до GPT01. Я не знаю, я не знаю, когда модели стали достаточно мощными, чтобы позволить мне быть продуктивным членом инженерной команды и фактически вносить ценный, значимый, чистый код. Но где-то за последние полтора года модели достигли точки, когда мой опыт работы с Hex, мои мнения, моя эмпатия к пользователям, накопленная за четыре года работы разработчиком для Hex, в сочетании с Claude или чем-то еще, позволили мне очень быстро стать инженером, что здорово. И я думаю, что был, я просто размышлял об этом. Был очень короткий период, когда я писал весь свой код вручную. Я думал: «Я инженер. Это так круто. Я не могу поверить, что я инженер». А потом я начал копировать и вставлять код все больше и больше. И теперь я как бы вернулся туда, где был раньше. Мне кажется, я забыл, как на самом деле кодировать, и я вернулся к самому началу два года назад, потому что я, я имею в виду, я очень хорошо читаю код, но я больше не пишу много кода. Это интересно. >> Каким вы видите правильный профиль для инженера ИИ в Hex? >> Я думаю, что предстоит проделать много разной работы. Мы нанимаем людей из очень разных областей. У нас есть математики, всевозможные люди, маркетологи. Я думаю, что сейчас я чувствую то же самое по отношению к инженерии, что и к работе разработчика-маркетолога: лучший человек — это тот, кто действительно заботится о проблеме, которую вы пытаетесь решить. Это всегда было то, что я говорил людям нанимать для разработчиков. И это как бы, вы можете научить их маркетингу. Например, они плохо пишут. Я не знаю. Вы, вероятно, можете научить их быть немного лучше, но вы не можете научить их, как действительно заботиться о вашей области достаточно, чтобы оставаться допоздна и создавать эту крутую функцию, которая станет той, которая, например, станет вирусной на Hacker News или что-то в этом роде. И я думаю, что этого просто не существовало для инженерии, потому что это как бы, ну, вы должны быть хорошим инженером. Если вы хотите создавать невероятные вещи, вы не можете просто иметь мнения и действительно заботиться. Вы также должны уметь это делать. И я думаю, что по-прежнему очень важно иметь старших инженеров. И я думаю, что я читаю и рецензирую и вручную редактирую весь свой код, но в основном я думаю, что моя работа — это просто заботиться и иметь мнение. И поэтому я думаю, что если вы сможете найти таких людей, я думаю, это очень интересно. Один из наших самых продуктивных членов нашей команды старения был пользователем, и он дал нам достаточно обратной связи, что однажды мы схватили его, накрыли ему голову капюшоном и посадили в кресло, и сказали: «Ты теперь работаешь на нас». И он преуспевает. Но раньше он был специалистом по данным, а не инженером ИИ или каким-либо инженером. И он, знаете ли, феноменально продуктивен в основном благодаря своим мнениям и своим инстинктам и интуиции в отношении вещей, которые будут полезны нашим пользователям. И это своего рода смешно, как я почти в своей голове, может быть, это антропоморфизм или хуже, но агент блокнота и агент потоков — это специалист по данным, аналитик данных. Мы говорим ему, что это как бы, вы агент потоков Hex, вы аналитик данных. И поэтому наличие этой эмпатии к пользователю, я думаю, на самом деле делает людей лучше в создании самого агента, потому что вы знаете, как он должен работать, и вы можете сказать, когда он делает странные вещи, которые могут быть признаком. Не то чтобы он был в беде или что-то в этом роде, но что-то его сдерживает или что-то мешает ему на этом золотом пути, по которому он должен идти. >> Они могут поставить себя на место агента и подумать: «Ну, если бы я решал это, я бы сделал это так». Им бы это достаточно заботило. >> Я думаю, да. Но я думаю, что доменная экспертиза незаменима. Я думаю, что очень специфическое место, где я думаю, что она незаменима, — это визуализация, которая на самом деле является местом, где у меня не так много мнений. У меня много мнений о, знаете ли, основах того, как не совершать преступлений с диаграммами, но не на невероятно глубоком уровне. Но у нас есть два человека в команде, Мелин и Николас, я не знаю, какой уровень выше эксперта, но они как бы, как шукунин, эксперты по визуализации. И все чаще, я думаю, их работа, я надеюсь, они не будут против, если я скажу это, заключается в том, чтобы иметь невероятно сильные мнения о том, как все это должно работать. И половину времени они напрямую кодируют их в агентов. Половину времени они говорят другим, что они сделали что-то неправильно или что им следовало бы построить это так, и помогают другим строить таким образом, который более предвзят. Когда вы создаете продукты в эпоху ИИ, это всегда забавный танец ваших мнений, мнений пользователей. Пользователи иногда ожидают, что смогут просто ввести что-то, и продукт будет выглядеть совершенно иначе. Но я думаю, что с данными и визуализацией и всем таким важно иметь эти сильные мнения, основанные на доменной экспертизе, которые вы можете кодировать в продукт, чтобы сделать его восхитительным. И я думаю, что особенно в отношении, например, визуализации и всего такого, я думаю, мы получаем много отзывов, в которых говорится, что Hex ошеломляет. Например, агент Hex Threads потрясающий. И иногда, когда вы углубляетесь в это, людям почти трудно точно сказать, почему. Они говорят: «Я получил нужный ответ. Это было намного лучше, чем, скажем, другой инструмент». А потом вы действительно углубляетесь в то, почему и почему, и почему, и часто, по крайней мере, когда я разговариваю с пользователями, они говорят: «Да, это было лучше». И я думаю, что это очень интересная уникальность, потому что, например, точность — это хорошо, но если ответ — это длинный отчет с пятью диаграммами и этими пунктами и предложением посмотреть на это дальше, это то, что, я имею в виду, невозможно оценить. Я не сплю по ночам, пытаясь понять, как оценить эту неопределенность того, что значит быть великим в данных, помимо просто получения правильного ответа в очень, очень сложной ситуации. >> Вы думаете, что это основная ценность, которую вы предоставляете, — помочь агентам быть великими в этом и получать эти великие ответы, даже когда это трудно оценить количественно? >> Я думаю, да. Я думаю, что это то, что мы всегда должны пересматривать: насколько это модель, а насколько это оболочка. И я думаю, что Барри, наш генеральный директор, очень увлекся тем, что говорит, что является песком, а что — камнем в продукте, знаете ли, если модели станут в два раза лучше, чем сегодня, что окажется песком, который можно смыть, а что останется камнем и будет очень значимым. И я думаю, что по мере того, как агенты естественным образом становятся более способными к науке о данных, аналитике и всему такому, я думаю, что в течение долгого времени, по крайней мере. Я не скажу всегда, но я думаю, что в течение долгого времени будет ценность в мнениях и доменной экспертизе, закодированных наряду с инструментами, которые сделают Hex лучше, чем соединитель Snowflake с документом Markdown, который вы запускаете в командной строке. Я скажу, что это как бы эта часть пирога, и большая часть другого пирога — это контекстный выхлоп, о котором мы говорили ранее, и этот цикл обратной связи, где, если вы работаете в Hex, и вы производите артефакты и получаете ответы, и создаете проекты, и все это становится источниками информации, потенциально проверенными для агента, чтобы, знаете ли, валидировать или направлять его будущую работу. Это большая часть ценности, которую предоставляет продукт. И я имею в виду, невозможно предоставить эту ценность с первого дня. Так что я думаю, что версия Hex с первого дня лучше, чем ваш случайный соединитель. Я думаю, в основном в форме предвзятости и дружелюбия к пользователю, и, как бы, я бы на самом деле, может быть, это горячий взгляд, но я думаю, что с первого дня Claude с соединителем Snowflake, вероятно, я, вероятно, так же хорош, но ценность заключается в этом, как бы, со временем, это не просто инструмент, это как бы платформа, на которой все работают, и маховик заставляет ее улучшаться со временем, и поэтому к 90-му дню вы работаете в совершенно другой лиге. >> Чего вы больше всего ждете в будущем? Есть одна вещь, связанная с оценками, которая довольно интересна. То, как я построил склад данных, который мы используем для наших внутренних наборов оценок, сделано очень амбициозно, или я оставил дверь открытой для гораздо большего, что можно сделать в плане оценок здесь. Итак, сегодня у нас есть склад Snowflake с реалистичным репрезентативным объемом бизнес-данных о вымышленной компании Shorelane Commerce, которая продает всякую всячину. И я очень тщательно вручную ввел все эти ужасные проблемы с качеством данных в склад данных, которые вызывают у агента трудности, и ему приходится проталкиваться через кучу null, испорченных столбцов и соединений, которые не совсем работают. Всевозможные вводящие в заблуждение, сбивающие с толку вещи. Это как бы V0ero нашего бенчмарка, это как бы все эти вопросы, которые очень реалистичны для того, что пользователи спрашивают у очень реалистично беспорядочного, как бы, наполовину смоделированного, но наполовину беспорядочного, наполненного проблемами качества, реалистичного склада данных. В дополнение к этому снимку, самый интересный способ оценить агентов данных и работу с данными — это долгосрочная перспектива. И я думаю, что это входит в некоторую ценность, которую, как я думаю, Hex предоставляет, о которой мы говорили о производительности с первого дня по сравнению с производительностью на 90-й день, когда маховик провернулся. Несправедливо просить Claude ответить на кучу сложных вопросов сразу, и у него никогда не будет возможности попробовать еще раз. И это то, что большинство наборов для оценки. Это как бы, кто президент Малайзии, и вы говорите «хорошо», и это как бы «неправильно», и тогда вы никогда не возвращаетесь к этому, и никакой ценности из этого не вышло. Я думаю, что Hex как продукт — это своего рода продукт, который должен становиться лучше со временем, каждый день. Он должен становиться все лучше и лучше в ваших задачах. И поэтому, если мы не оцениваем наш продукт таким образом, который позволяет агенту, знаете ли, фактически продемонстрировать свою способность к накоплению, мы оцениваем только эту часть системы в данный момент. Мы не оцениваем полный маховик. И поэтому полное видение этого набора оценок заключается в том, что снимок базы данных с первого дня фактически используется для запуска батареи эталонных вопросов, которые являются оценкой. Многие из них почти невозможно ответить с информацией, доступной агенту в первый день. Но я построил 90-дневную симуляцию, в течение которой тикают часы, и каждый раз, когда наступает новый день, запускаются модели DBT и изменяют склад данных, чтобы он оставался как бы сдвинутым по времени и актуальным. Новые строки поступают, что-то ломается, запускаются новые продукты, происходит мошенничество, и билеты поступают от заинтересованных сторон к агенту в виде электронных писем. Ему нужно ответить, и они задают вопросы по данным, и они дают ему информацию, и по пути он как бы обнаруживает вещи о складе данных, и как только он ответил на билет, оценка не заканчивается, или разговор не заканчивается. Ему говорят: «Вы ответили на билет». Теперь у вас есть доступ к инструменту для завершения хода. Но если вы хотите провести небольшую проактивную работу по получению знаний перед завершением хода, вы можете это сделать. Вы можете следить за свободными нитями из этого разговора, документировать некоторые из своих выводов, чистить вики и т. д. И мы позволяем агенту проактивно делать свое дело, а затем завершать ход, когда он захочет. И это происходит каждый день в течение 90 дней. И предположение заключается в том, что если агент демонстрирует навыки и поведение, которые мы хотим, то к 90-му дню все вопросы и билеты тщательно составлены таким образом, чтобы он должен был ответить на 100% вопросов правильно. И поэтому сегодня это очень дорого в исполнении. Мне нужны кредиты, пожалуйста. Соннет 4.6 получает 24% на 90-й день. >> Сколько он получает в первый день? >> Около 4%. Но опять же, мне неинтересно, сколько он получает. Например, может быть, если бы он получил 100%, я бы сказал: «Ну, мой бенчмарк отстой». Но, опять же, я думаю, что для этих очень сложных вопросов производительность в первый день не является продуктивным числом, потому что она не реалистична. Это не то, как выглядит реальный мир, когда они оценивают это. Это своего рода состояние лаборатории сумасшедшей науки прямо сейчас, но в свободное время я вожусь с тем, чтобы сделать это чем-то гораздо более легитимным. Итак, мы фактически можем оценить нашу, и это основано на моделях прямо сейчас. Это работает в своего рода собственной оболочке. У него есть очень простые инструменты. Это вообще не оценивает агента Hex. Это просто оценивает поведение модели. Часть этого заключается в том, что я хочу наблюдать. Если я хочу увидеть, думая о, например, в распределении, как модель любит организовывать свою вики? Какие информационные самородки она любит хранить? Как она их извлекает? Что она находит? Что она упускает? Это почти как исследовательский проект по поиску фактов, чтобы мы могли улучшить нашу оболочку. >> Вы также запускаете агента Hex на этом бенчмарке? До и после. >> Я еще не разобрался, как это сделать. >> Это очень, как я сказал, это лаборатория сумасшедшей науки в данный момент, >> но я очень планирую это сделать. >> Очень круто. Это честная оценка, верно? Я думаю, любая одноразовая оценка неинтересна. Многие люди сообщают о прохождении K или чем-то в этом роде, но это просто означает параллельно. Насколько мне известно, единственные люди, которые проводят действительно интересную работу по долгосрочной оценке, — это Anthropic и Andon Labs на Vending Bench, что, по сути, вдохновило это. И у этого есть своего рода долгосрочная награда. Есть ли у агента Hex прямо сейчас инструмент для, например, ведения заметок в реальной жизни? >> Пока нет. Так что прямо сейчас все происходит через этот этап синтеза после, по сути. Я думаю, может быть, должно быть. Я думаю, это интересная вещь для рассмотрения. Например, я недавно спорил с коллегой об этом, есть ли ценность в агенте контекста или агенте синтеза, который может видеть 20 потоков, прежде чем сохранить информацию, по сравнению с сохранением информации в данный момент. Есть сильные аргументы в обе стороны. У обоих есть плюсы и минусы. То, что он реализовал, на чем я настаивал, — это этап синтеза, где он видит все, и поэтому он может фактически проверить что-то или просто дублировать его и т. д. Я думаю, это сканируется, но я также задаюсь вопросом, есть ли какой-то механизм предложения, который должен происходить в реальном времени во время потока. Например, я как бы намекнул, что это делает вещи очень трудными для оценки, если вы позволяете агенту динамически изменять систему во время оценки, а затем вам приходится запускать эти симуляционные оценки. Судейство становится действительно трудным. Даже просто организация этой симуляции становится полной головной болью. У меня еще нет всех ответов здесь, но я очень сильно чувствую, что оценки, которые мы делаем сегодня, которые являются одноразовыми. Я думаю, они очень интересны, очень полезны. Они помогают нам понять производительность агента, но я на самом деле не думаю, что они являются честной оценкой такой системы, как Hex, которая является этой платформой, разработанной для накопления со временем. Так что, я, э, там чего-то не хватает, что мне интересно исследовать. >> Как назывался бенчмарк? Vending Bench. Vending Bench — это то, что построил Anthropic. Я назвал свой Metric City. >> Является ли Vending Bench с открытым исходным кодом? >> Vending Bench закрыт. Я думаю, что он на самом деле сделан небольшой компанией под названием Andon Labs, которая является этой странной шведской компанией. Я не знаю, читали ли вы о Claudius, торговом автомате. >> Это своего рода связано с Vending Bench. Andon также управляет торговым автоматом. >> Ну, он не с открытым исходным кодом. Я хочу на нем работать, >> верно? Я тоже хотел бы, но я просто удивлен, что никто другой не потратил, хотя я еще не выпустил свой. Я надеюсь открыть исходный код этого бенчмарка Metric City. >> Я хотел бы попробовать. Да, я имею в виду, я думаю, что это действительно связано с памятью. Мы много думаем о памяти в наших оболочках агентов, и там, да, их трудно оценить, и поэтому, если там, я имею в виду, да, мы можем сделать один, но, как бы, я думаю, что что-то вроде этого должно полностью существовать. Спасибо, что послушали мой разговор с Иззи Миллер. Это первый эпизод Max Agency, подкаста, где я разговариваю со строителями агентов и углубляюсь в детали, архитектуру, цикл улучшения и то, что работает или не работает. Если вам понравился этот эпизод, оставьте отзыв и подпишитесь. Отправляйте отзывы или вопросы на max agency lane.dev. Мы хотим услышать от вас.