Чтобы создавать отличные ИИ-продукты, нужно быть очень хорошим в создании оценок (evals). Это деятельность с самой высокой рентабельностью инвестиций, в которую вы можете вложиться. Этот процесс доставляет много удовольствия. Каждый, кто этим занимается, немедленно подсаживается на него, когда вы создаете ИИ-приложение. Вы просто многому учитесь. Что круто в этом, так это то, что вам не нужно делать это много, много раз. Для большинства продуктов вы выполняете этот процесс один раз, а затем строите на его основе. >> Цель не в том, чтобы идеально проводить оценки. Цель — действенно улучшать ваш продукт. >> Я не осознавал, сколько споров и драмы существует вокруг оценок. Есть много людей с очень сильными мнениями. Люди были обожжены оценками в прошлом. Люди плохо проводили оценки, потом перестали им доверять и говорили: "О, я против оценок". >> Каковы некоторые из наиболее распространенных заблуждений людей относительно оценок (EVAL)? Первое — мы живем в эпоху ИИ. Разве ИИ не может сам оценить это? Но это не работает. Термин, который вы использовали в своем посте и который мне очень нравится, — это идея благосклонного диктатора. Когда вы занимаетесь этим открытым кодированием, многие команды увязают в том, что этим занимается комитет. Для многих ситуаций это совершенно ненужно. Вы не хотите делать этот процесс настолько дорогим, чтобы вы не могли его выполнить. Вы можете назначить одного человека, чьему вкусу вы доверяете. Это должен быть человек с экспертными знаниями в предметной области. Часто это менеджер по продукту. Сегодня моими гостями являются Хамиль Хуссейн и Шрея Шанкар. Одной из самых популярных тем на этом подкасте за последний год стал рост оценок. Оба главных директора по продуктам Anthropic и OpenAI заявили, что оценки становятся самым важным новым навыком для создателей продуктов. И с тех пор это стало повторяющейся темой среди многих ведущих создателей ИИ, которых я приглашал. 2 года назад я никогда не слышал термина "оценки". Теперь он постоянно всплывает. Когда в последний раз появлялся новый навык, которым создателям продуктов нужно было овладеть, чтобы добиться успеха? Хамил и Шрея сыграли важную роль в превращении оценок из малоизвестной загадочной темы в один из самых необходимых навыков для создателей ИИ-продуктов. Они преподают definitive онлайн-курс по оценкам, который является курсом № 1 на Maven. Они обучили более 2000 менеджеров по продукту и инженеров из 500 компаний, включая большие группы команд OpenAI и Anthropic, а также каждую другую крупную ИИ-лабораторию. В этом разговоре мы много показываем вместо того, чтобы рассказывать. Мы проходим процесс разработки эффективной оценки, объясняем, что такое черт возьми оценки и как они выглядят, развеиваем многие распространенные заблуждения относительно оценок, даем вам первые шаги, которые вы можете предпринять, чтобы начать создавать оценки для вашего продукта, а также делимся множеством лучших практик, разработанных Хамилом и Треем за последние несколько лет. Этот выпуск — самый глубокий, но при этом самый понятный вводный курс, который вы найдете о мире оценок, и, честно говоря, он заставил меня с энтузиазмом писать оценки. Даже несмотря на то, что мне нечего оценивать, я думаю, вы почувствуете то же самое, когда будете смотреть это. Если этот разговор вас вдохновит, обязательно ознакомьтесь с курсом Хамила и Шреи на Maven. Мы дадим ссылку на него в описании выпуска. Если вы используете код Lenny's List при покупке курса, вы получите скидку 35% от цены курса. А теперь я представляю вам Хамила Хуссейна и Шрею Шанкар. Этот выпуск представлен Finn — ИИ-агентом № 1 для обслуживания клиентов. Если ваши заявки в службу поддержки накапливаются, вам нужен Finn. Finn — это ИИ-агент с самой высокой производительностью на рынке, со средним уровнем решения проблем 65%. Finn решает даже самые сложные запросы клиентов. Ни один другой ИИ-агент не работает лучше. В прямых сравнениях с конкурентами Finn выигрывает каждый раз. Да, переход на новый инструмент может быть пугающим, но Finn работает с любой службой поддержки без необходимости миграции, что означает, что вам не придется перестраивать свою текущую систему или сталкиваться с задержками в обслуживании ваших клиентов. И Finn пользуется доверием более 5000 лидеров служб поддержки и ведущих ИИ-компаний, таких как Anthropic и Synthesia. И поскольку Finn работает на движке Finn AI, который является постоянно совершенствующейся системой, позволяющей легко анализировать, обучать, тестировать и развертывать, Finn может постоянно улучшать ваши результаты. Итак, если вы готовы трансформировать свое обслуживание клиентов и масштабировать поддержку, попробуйте Finn всего за 99 центов за решение. Кроме того, Finn поставляется с 90-дневной гарантией возврата денег. Узнайте, как Finn может работать для вашей команды на f.ai.ai/lenny. Это finn.ai/lenny. Этот выпуск представлен Doutt. Сегодня от дизайн-команд ожидают быстрого движения, но при этом и правильного выполнения. Вот где на помощь приходит Doutt. Dcout — это универсальная исследовательская платформа, созданная для современных продуктовых и дизайн-команд. Независимо от того, проводите ли вы юзабилити-тесты, интервью, опросы или полевые исследования, Doutt позволяет легко связываться с реальными пользователями и быстро получать реальные результаты. Вы даже можете тестировать свои Figma-прототипы непосредственно на платформе. Никакой возни с инструментами, никакой погони за призрачными участниками. А благодаря самой надежной в отрасли панели, а также анализу на основе ИИ, ваша команда получает ясность и уверенность для создания лучшего без замедления. Итак, если вы готовы оптимизировать свои исследования, ускорить принятие решений и создавать дизайн с влиянием, зайдите на dscout.com, чтобы узнать больше. Это dscout.com. Ответы, которые вам нужны, чтобы действовать уверенно. Хаммел и Шрея, большое спасибо, что пришли и добро пожаловать на подкаст. Спасибо, что пригласили. >> Да, очень рады. >> Я еще более рад. Итак, пару лет назад я никогда не слышал термина "оценки". Теперь это, по сути, одна из самых популярных тем на моем подкасте: чтобы создавать отличные ИИ-продукты, нужно быть очень хорошим в создании оценок. >> Также выясняется, что некоторые из самых быстрорастущих компаний в мире в основном создают и продают и разрабатывают оценки для ИИ-лабораторий. Я только что приглашал на подкаст генерального директора Merkore. Так что здесь происходит что-то очень большое. >> Я хочу использовать этот разговор, чтобы помочь людям глубоко понять эту область. Но давайте начнем с основ. Что, черт возьми, такое EVALs? Для тех, кто понятия не имеет, о чем мы говорим, дайте нам краткое представление о том, что такое оценка (eval). И давайте начнем с Хамла. >> Конечно. Оценки — это способ систематически измерять и улучшать ИИ-приложение. И это действительно не должно быть страшно или недоступно. По сути, это аналитика данных вашего LLM-приложения систематическим способом анализа этих данных и, где это необходимо, создания метрик для измерения того, что происходит, а затем для итерации и проведения экспериментов и улучшения. Так что это очень хороший общий способ думать об этом. Если углубиться еще на один уровень, чтобы дать людям еще более конкретный способ представить и визуализировать, о чем мы говорим, даже если у вас есть пример для демонстрации, это было бы еще лучше. >> Есть ли более глубокий способ понять, что такое оценка? >> Давайте предположим, у вас есть приложение-помощник по недвижимости, и оно работает не так, как вы хотите. Оно не пишет письма клиентам так, как вы хотите, или оно не вызывает нужные инструменты, или любые другие ошибки. И до оценок вы бы остались в догадках. Вы могли бы исправить промпт и надеяться, что вы не сломаете ничего другого этим промптом, и вы могли бы полагаться на "проверки на ощупь" (vibe checks), что вполне нормально, и "проверки на ощупь" хороши, и вы должны делать их изначально, но это может очень быстро стать неуправляемым, потому что по мере роста вашего приложения очень трудно полагаться на "проверки на ощупь". Вы просто чувствуете себя потерянным. И поэтому оценки помогают вам создавать метрики, которые вы можете использовать для измерения того, как работает ваше приложение, и дают вам способ улучшить ваше приложение с уверенностью, что у вас есть сигнал обратной связи, по которому можно итерировать. >> Так, чтобы сделать это очень реальным. Представьте себе этого агента по недвижимости, возможно, он помогает вам забронировать объект или посмотреть открытый дом. Идея в том, что у вас есть этот агент, который общается с людьми. Он отвечает на вопросы, указывает им на вещи. Как создателю этого агента, как вы узнаете, дает ли он хорошие советы, хорошие ответы? Говорит ли он им что-то совершенно неправильное? >> Так вот, идея оценки, по сути, заключается в создании набора тестов, которые говорят вам, как часто этот агент делает что-то неправильное, чего вы не хотите, чтобы он делал? И есть множество способов определить "неправильно". Это может быть просто выдумывание чего-то. Это может быть просто ответ в очень странной манере. >> То, как я думаю об оценках, и скажите мне, если я ошибаюсь, это просто модульные тесты для кода, а вы улыбаетесь. Вы говорите: "Нет, идиот". >> О, это не то, о чем я думал. >> Хорошо. Расскажите мне, как это ощущается как метафора? >> Итак, мне нравится то, что вы сказали вначале, что у нас было очень широкое определение. Оценки — это большой спектр способов измерения качества приложения. Теперь модульные тесты — это один из способов сделать это. Возможно, есть некоторые не подлежащие обсуждению функции, которые вы хотите, чтобы ваш ИИ-помощник имел, и модульные тесты смогут это проверить. Теперь, возможно, вы также, поскольку эти ИИ-помощники выполняют такие открытые задачи, вы также хотите измерить, насколько хорошо они справляются с очень расплывчатыми или неоднозначными вещами, такими как реагирование на новые типы запросов пользователей или, знаете ли, выяснение, есть ли новые распределения данных, например, приходят новые пользователи и используют вашего агента по недвижимости, о которых вы даже не знали, что они будут использовать ваш продукт, и вдруг вы думаете: "О, есть другой способ, которым вы хотите как-то приспособить эту новую группу людей". Так что оценки также могут быть, знаете ли, способом регулярно просматривать ваши данные, чтобы находить эти новые когорты людей. Оценки также могут быть, например, метриками, которые, знаете ли, вы просто хотите отслеживать с течением времени, например, вы хотите отслеживать, как люди говорят "да", "большой палец вверх", "мне понравилось ваше сообщение". >> Вы хотите очень, очень базовые вещи, которые не обязательно связаны с ИИ, но могут вернуться в этот цикл улучшения вашего продукта. >> Так что я бы сказал, что в целом модульные тесты — это очень маленькая часть этой большой головоломки. >> Отлично. Вы на самом деле принесли пример оценки, чтобы показать нам, что именно мы имеем в виду. Мы говорим о больших идеях. Так как насчет того, чтобы мы вывели один и показали людям, вот что такое оценка. >> Да. Позвольте мне немного подготовить почву. Итак, чтобы повторить слова Шреи, очень важно, чтобы мы не думали об оценках только как о тестах. Это распространенная ловушка, в которую попадают многие люди, потому что они сразу переходят к тестам, типа "давайте напишем несколько тестов", и обычно это не то, что вы хотите делать. Вы должны начать с какого-то анализа данных, чтобы понять, что вообще следует тестировать. И это немного отличается от разработки программного обеспечения, где у вас гораздо больше ожиданий относительно того, как будет работать система. С LLM гораздо большая площадь поверхности. Это очень стохастично. Так что у нас здесь немного другой подход. И поэтому пример, который я вам сегодня покажу, на самом деле является примером из сферы недвижимости. Это другой вид примера из сферы недвижимости. Это от компании под названием Nurture Boss. Я могу поделиться своим экраном, чтобы показать вам их веб-сайт, чтобы помочь вам понять этот сценарий использования. Итак, позвольте мне поделиться своим экраном. >> Это компания, с которой я работал. Она называется Nurture Boss, и это ИИ-помощник для управляющих недвижимостью, которые управляют квартирами. И он помогает с различными задачами, такими как входящие заявки, обслуживание клиентов, бронирование встреч и так далее, и тому подобное, все различные операции, которые вы можете выполнять как управляющий недвижимостью. Он помогает вам с этим. И вы можете увидеть, что они делают. Это очень хороший пример, потому что он имеет много сложностей современного ИИ-приложения. Так что есть много разных каналов, через которые вы можете взаимодействовать с ИИ, таких как чат, текст, голос, а также вызовы инструментов, много вызовов инструментов для бронирования встреч, получения информации о доступности и так далее. Также есть RAG-поиск, получение информации о клиентах и объектах недвижимости и тому подобное. Так что это довольно полнофункциональное ИИ-приложение. И они были очень щедры со мной и позволили мне использовать их данные в качестве учебного примера, и мы анонимизировали их, но то, что я собираюсь показать сегодня, это: хорошо, давайте создадим, давайте сделаем первую часть того, как мы начнем создавать оценки для Nurture Boss, почему мы вообще захотим это сделать? Итак, давайте пройдем самый первый этап, который мы называем анализом ошибок, то есть давайте посмотрим на данные их приложения и сначала начнем с того, что идет не так. Итак, я перейду к следующему и открою инструмент наблюдения, и вы можете использовать любой, какой захотите. Я просто случайно загрузил эти данные в инструмент под названием Brain Trust, но вы можете загрузить их в любой другой, знаете ли, у нас нет любимого инструмента или чего-то подобного. В блоге, который мы написали с вами, у нас был тот же пример, но в Phoenix Arise, и я думаю, что Аман в вашем блоге также использовал Phoenix Arise, и есть также Langsmith, так что это своего рода разные инструменты, которые вы можете использовать. Итак, то, что вы видите здесь на экране, это журналы из приложения, и позвольте мне показать вам, как это выглядит. Итак, то, что вы видите здесь, и позвольте мне сделать его полноэкранным. Итак, это одно конкретное взаимодействие, которое клиент имел с приложением Nurture Boss. И это подробный журнал всего, что произошло. Итак, это называется трассировкой (trace) и это просто инженерный термин для журналов последовательности событий. Концепция трассировки существует уже очень давно, но она особенно важна, когда речь идет об ИИ-приложениях. Итак, у нас есть все различные компоненты и части, и информация, которые нужны ИИ для выполнения своей работы, и мы все это регистрируем, и мы смотрим на представление этого. И вы видите здесь системный промпт. Промпт ассистента гласит: "Вы — ИИ-ассистент, работающий в команде по аренде в Acme Apartments. Помните, я сказал, что это анонимизировано. Поэтому название Acme Apartments. Ваша основная роль — отвечать на текстовые сообщения как от текущих, так и от потенциальных жильцов. Ваша цель — предоставлять точную, полезную информацию и так далее". И затем есть много деталей о руководящих принципах того, как мы хотим, чтобы это работало. >> Это их фактический системный промпт, кстати, для этой компании? >> Да. Это реальный системный промпт. >> Это потрясающе, потому что это действительно редкость, когда видишь реальные системные промпты продуктов компаний. Это часто их драгоценные жемчужины. Так что это само по себе очень круто. >> Да. Да. Это действительно круто. И вы видите все эти различные виды функций, которые они хотят, или различные сценарии использования. Так что это касается планирования туров, обработки заявок, руководства по тому, как разговаривать с разными персонами, и так далее. И вы можете видеть, как пользователь просто вступает сюда. Он говорит: "Хорошо, у вас есть однокомнатная квартира с кабинетом?" Я видел это на виртуальных турах. И тогда вы можете видеть, что LLM вызывает некоторые инструменты. Он вызывает этот инструмент "получить информацию об индивидуальном лице" и извлекает информацию об этом человеке, а затем получает доступность сообщества. Так что он запрашивает базу данных с информацией о доступности для этого жилого комплекса. И, наконец, ИИ отвечает: "Привет, у нас есть несколько однокомнатных квартир, но ни одна из них не указана конкретно с кабинетом. Вот несколько вариантов". И затем он говорит: "Можете ли вы сообщить мне, когда появится квартира с кабинетом?" И затем он говорит: "В настоящее время у меня нет конкретной информации о доступности однокомнатной квартиры". Пользователь говорит: "Спасибо". И ИИ говорит: "Пожалуйста. Если у вас есть еще вопросы, не стесняйтесь обращаться". Теперь это пример трассировки, и мы смотрим на одну конкретную точку данных. И поэтому одна вещь, которая действительно важна при анализе данных вашего LLM-приложения, — это смотреть на данные. Теперь вы можете спросить, здесь много этих журналов. Это немного беспорядочно. Здесь много всего происходит. Как, черт возьми, вы должны смотреть на эти данные? Вы хотите просто утонуть в этих данных? Как вообще анализировать эти данные? >> Так вот, оказывается, есть способ сделать это, который полностью управляем, и это не то, что мы изобрели. Это существует в машинном обучении и науке о данных уже очень давно, и это называется анализ ошибок. И то, что вы делаете, первый шаг к освоению таких данных, — это просто делать заметки. Хорошо? Так что вам нужно надеть шляпу продукта, поэтому мы разговариваем с вами, потому что люди, занимающиеся продуктом, должны быть в комнате. >> И они должны быть вовлечены в это. >> Обычно разработчик не подходит для этого, особенно если это не приложение для кодирования. >> И я просто хочу повторить, почему вы это говорите, потому что это пользовательский опыт вашего продукта. Люди, говорящие с этим агентом, — это весь продукт, по сути. И поэтому имеет смысл, чтобы человек, занимающийся продуктом, был вовлечен, очень вовлечен в это. >> Да. Итак, давайте поразмыслим над этим разговором. Хорошо. Пользователь спросил о доступности. ИИ сказал: "О, у нас этого нет. Хорошего дня". >> Для продукта, который помогает вам с управлением лидами, это хорошо? Как вы думаете, так должно идти? >> Не идеально. Да. Не идеально. И я рад, что вы это сказали. Многие люди сказали бы: "О, это здорово. ИИ сделал правильную вещь. Он сказал, что у нас этого нет, он посмотрел, сказал, что этого нет, и этого нет". Но с точки зрения продукта, вы знаете, это неправильно. И поэтому вы бы просто написали здесь быструю заметку. Вы бы сказали: "Хорошо, хм, вы знаете, вы могли бы вставить сюда, позвольте мне просто, и вы можете написать заметку. Итак, каждое приложение для наблюдения имеет возможность писать заметки, и вы не будете пытаться выяснить, неправильно ли что-то в этом приложении, знаете ли, в этом случае оно как бы не делает правильную вещь. >> Но вы просто пишете быструю заметку. >> "Должен был передать человеку". >> И когда мы наблюдаем за этим, вы упомянули это, и вы объясните больше, это кажется очень ручным и не масштабируемым, но, как вы сказали, это всего лишь один шаг процесса, и у этого есть система, и это только первая часть. >> И вам не нужно делать это для всех ваших данных, вы можете выбрать образец данных и просто посмотреть, и удивительно, как много вы узнаете, когда делаете это. Каждый, кто этим занимается, немедленно подсаживается на это и говорит: "Это величайшее, что вы можете сделать при создании ИИ-приложения". Вы просто многому учитесь. Вы думаете: "Хм, это не то, как я хочу, чтобы это работало". Хорошо. И, таким образом, это просто пример. Итак, вы пишете эту заметку, и затем мы можем перейти к следующей трассировке. >> Это следующая трассировка. Я просто нажал горячую клавишу на клавиатуре. Позвольте мне вернуться к просмотру. >> И эти инструменты облегчают просмотр большого количества и быстрое добавление этих заметок. >> Да. И это еще одна. Похожий системный промпт. Нам не нужно проходить все это. Опять же, мы просто перейдем прямо к вопросу пользователя. Хорошо. Я пишу вам весь день. Может быть, это смешно. >> Хм, хм, и пользователь говорит: "Пожалуйста, хорошо, да, это просто ошибка в приложении, где, знаете ли, это приложение для текстовых сообщений, и поэтому, знаете ли, это текстовое сообщение, извините, канал, через который общается клиент, — это текстовое сообщение, и оно просто становится очень искаженным". И вы можете видеть здесь, что это как бы не имеет смысла, знаете ли, слова обрезаются, как "тем временем", а затем система не знает, как ответить, потому что, знаете ли, как люди отправляют текстовые сообщения, они пишут короткие фразы, они разбивают предложение на четыре или пять разных сообщений. Так что в этом случае. >> Что вы делаете с чем-то подобным? >> Да. Так что это другой вид ошибки. >> Это скорее "мы неправильно обрабатываем это взаимодействие". Это скорее техническая проблема, >> чем "ИИ не делает именно то, что мы хотим". >> Так что мы бы записали тоже, как это удивительно, что вы это тоже ловите здесь, иначе вы бы понятия не имели, что это происходит. >> Да, вы можете не знать, что это происходит, верно? И поэтому вы бы просто сказали: "Хорошо, хм, вы бы написали заметку, типа "поток разговора корявый из-за текстовых сообщений", и мне нравится, да, мне нравится, что вы используете слово "корявый". >> Это показывает, насколько неформальным это может быть на этом этапе. >> Да, это должно быть непринужденно, просто не переусердствуйте. И есть способ сделать это. Так что вопрос всегда возникает: как это сделать? Вы пытаетесь найти все различные проблемы в этой трассировке? О чем вы пишете заметку? >> И ответ: просто запишите первое, что вы видите, что неправильно, самую верхнюю ошибку. Не беспокойтесь обо всех ошибках. Просто зафиксируйте первое, что вы видите, что неправильно, и остановитесь и двигайтесь дальше. И вы можете стать очень хороши в этом. Первые два-три могут быть очень болезненными, но, знаете ли, мы можем, знаете ли, сделать много из них очень быстро. >> Итак, вот еще один. И, хм, давайте снова пропустим системный промпт. И пользователь спрашивает: "Привет, я ищу квартиру с двумя-тремя спальнями, с одной или двумя ванными комнатами. Вы предлагаете виртуальные туры?" И вызывается куча инструментов, и говорится: "Привет, Сара, в настоящее время у нас есть квартира с тремя спальнями и двумя с половиной ванными комнатами за 2175 долларов. >> К сожалению, у нас нет двухкомнатных вариантов в данный момент. Мы предлагаем виртуальные туры. Вы можете запланировать тур, бла-бла-бла". >> Просто так получилось, что виртуального тура нет. >> Верно? >> Так вот, хм, знаете ли, он галлюцинирует что-то, чего не существует, и вам приходится использовать свой контекст как инженера или даже свой контекст продукта и говорить: "Эй, это как-то странно, знаете ли, мы не должны рассказывать человеку о виртуальном туре, когда он не предлагается". >> Так что вы бы сказали: "Хорошо, хм, вы знаете, предложил виртуальный тур", и вы просто, знаете ли, вы просто пишете заметку. >> Так что вы можете видеть, что мы видим разнообразие различных видов ошибок, и мы на самом деле многое узнаем о вашем приложении за очень короткое время. >> Один распространенный вопрос, который мы получаем от людей на этом этапе: "Хорошо, я понимаю, что происходит. Могу ли я попросить LLM выполнить этот процесс за меня?" >> Отличный вопрос. И мне нравится последний пример Хамила, потому что обычно мы обнаруживаем, что когда мы пытаемся попросить LLM выполнить этот анализ ошибок, он просто говорит, что трассировка выглядит хорошо, потому что у него нет необходимого контекста, чтобы понять, является ли что-то "плохим продуктовым запахом" или, например, галлюцинацией о планировании тура, верно? Я могу гарантировать, я бы поставил на это деньги, если бы я ввел это в ChatGPT и спросил, есть ли ошибка, он бы сказал "нет", сделал бы отличную работу. Но у Хамила был контекст знания, "о, у нас на самом деле нет этой функции виртуального тура", верно? Так что, я думаю, в этих случаях очень важно убедиться, что вы делаете это вручную. >> И мы можем поговорить немного больше о том, когда использовать LLM в процессе позже, но вот первая ловушка: люди говорят: "Давайте автоматизируем это с помощью LLM". >> Вы думаете, мы дойдем до места, где агент сможет это сделать? >> О, нет, нет, нет. Извините. Есть части анализа ошибок, для которых подходит LLM, о которых мы можем поговорить позже в этом подкасте. >> Но прямо сейчас на этом этапе свободного написания заметок это не место для LLM. >> И это то, что вы называете открытым кодированием. >> Да, абсолютно. >> Еще один термин, который вы использовали в своем посте и который мне очень нравится, и который подходит к этому шагу, — это идея благосклонного диктатора. Может быть, просто расскажите об этом, и, возможно, Шрея расскажет об этом. >> Да. Так что Хамил на самом деле придумал этот термин. >> Хорошо, может быть, Хамил ответит. >> Нет проблем. И мы на самом деле покажем автоматизацию LLM в этом примере, потому что мы возьмем этот пример, мы пройдем его до конца. >> Потрясающе. >> И, таким образом, благосклонный диктатор — это просто запоминающийся термин для того факта, что когда вы занимаетесь этим открытым кодированием, многие команды увязают в том, что этим занимается комитет. И для многих ситуаций это совершенно ненужно, как, знаете ли, люди очень нервничают по поводу того, что "хорошо, мы хотим, чтобы все были на борту, мы хотим, чтобы все участвовали" и так далее. Вам нужно прорваться сквозь шум. >> В большинстве организаций, если вы посмотрите очень глубоко, особенно в малых и средних компаниях, действительно есть возможность назначить одного человека, чьему вкусу вы доверяете. >> И вы можете сделать это с небольшим количеством людей, и часто с одним человеком. И это действительно важно, чтобы сделать это управляемым. Вы не хотите делать этот процесс настолько дорогим, чтобы вы не могли его выполнить. Вы упустите. Так что это идея благосклонного диктатора: "Эй, вам нужно упростить это по всем возможным измерениям". Еще одна вещь, которую мы обсудим позже, это когда речь идет о создании LLM в качестве судьи, вам нужна бинарная оценка. Вы не хотите думать о том, является ли это как бы 1, 2, 3, 4, 5, типа присвоить оценку. Вы не можете. Это замедлит процесс. >> Чтобы сделать этот пункт о благосклонном диктаторе действительно ясным. По сути, это человек, который делает это нотирование, и в идеале он является экспертом в этом деле. Так что, если это юридические вопросы, возможно, есть юрист, который этим занимается. Это может быть менеджер по продукту. Дайте нам совет, кто должен быть этим человеком. >> Да, это должен быть человек с экспертными знаниями в предметной области. Так что в этом случае, знаете ли, это будет человек, который понимает бизнес аренды квартир и имеет контекст, чтобы понять, имеет ли это смысл. Это всегда эксперт в предметной области, как вы сказали. Для юридических вопросов это будет юрист, для психического здоровья — эксперт по психическому здоровью, будь то психиатр или кто-то еще. >> Круто. >> Хм, часто это менеджер по продукту. >> Круто. Так что совет здесь: выберите этого человека. Может быть, это не кажется очень справедливым, что он главный, но он благосклонный. Все будет хорошо. >> Да, все будет хорошо. Вы просто пытаетесь. Это не совершенство. Вы просто пытаетесь добиться прогресса и быстро получить сигнал, чтобы иметь представление о том, над чем работать, потому что это может стать бесконечно дорогим, если вы не будете осторожны. >> Да. Хорошо, круто. Давайте вернемся к вашим примерам. >> Да, без проблем. >> Итак, это еще один пример, где кто-то говорит: "Хорошо, у вас есть какие-нибудь специальные предложения?" И ассистент или ИИ отвечает: "Привет, у нас есть 5% скидка для военных". Пользователь отвечает: "Можете ли вы", и меняет тему, "сказать мне, сколько этажей?" Есть ли у вас однокомнатные квартиры или однокомнатные квартиры на первом этаже? И ИИ отвечает: "Да, хорошо. У нас есть несколько однокомнатных квартир". И затем пользователь хочет подтвердить, есть ли какие-либо из них на первом этаже. И сколько стоят однокомнатные квартиры? И также является ли он текущим резидентом. Так что они также спрашивают: "Мне нужна заявка на техническое обслуживание". Это на самом деле довольно, вы можете видеть беспорядок реального мира здесь. И ассистент просто вызывает инструмент "перевести звонок", >> но ничего не говорит. Он просто резко переводит звонок. >> Так что это довольно коряво, я бы сказал, как это просто не, знаете ли, еще одна корявость. >> Еще один вид корявости. Так что вы не хотите, когда пишете открытую заметку, говорить "коряво", потому что мы хотим понять, что происходит. И когда мы смотрим на заметки позже, мы хотим понять, что произошло. >> Так что вы просто хотите сказать: "Хорошо, хм, не подтвердил перевод звонка с пользователем". >> Это не обязательно должно быть идеально. Вам просто нужно иметь общее представление о том, что происходит. >> Круто. >> Итак, хорошо. Итак, скажем, мы делаем это, и мы с Треей рекомендуем сделать по крайней мере сто таких. Вопрос всегда в том, сколько этого делать? И поэтому нет волшебного числа. Мы говорим 100, потому что мы знаем, что как только вы начнете делать это, как только вы сделаете 20 из них, вы автоматически найдете это настолько полезным, что продолжите делать это. Так что мы просто говорим 100, чтобы мысленно разблокировать вас, чтобы это не было пугающим, типа, не волнуйтесь, вы сделаете только 100, и есть термин для этого, так что правильный ответ — продолжайте смотреть трассировки, пока не почувствуете, что больше не узнаете ничего нового. >> Да, есть на самом деле термин в анализе данных и качественном анализе, называемый теоретической насыщенностью. >> Что это означает, это когда вы выполняете все эти процессы просмотра ваших данных, когда вы останавливаетесь? Это когда вы насыщаетесь или не обнаруживаете никаких новых типов заметок, новых типов концепций или ничего, что бы материально изменило следующую часть вашего процесса. >> И это требует некоторой интуиции для развития. Так что обычно люди не знают, когда они достигли теоретической насыщенности. Это совершенно нормально. Когда вы сделаете два или три примера или раунда этого, вы разовьете интуицию. Многие люди понимают, типа, "О, хорошо, типа, мне нужно сделать только 40. Мне нужно сделать только 60. На самом деле, мне нужно сделать только 15. Я не знаю. >> Типа, зависит от приложения и развивается, как зависит от того, насколько вы разбираетесь в анализе ошибок. >> Определенно. >> И ваш пункт о том, что вы, вероятно, захотите сделать много, я представляю, потому что вы просто говорите: "О, я обнаруживаю все эти проблемы. Мне нужно посмотреть, что еще происходит". >> Точно. И я обещаю, в какой-то момент вы не будете обнаруживать новые типы проблем. >> Да. Отлично. Итак, скажем, вы сделали сто таких. Каков следующий шаг? >> Да. Хорошо. Итак, вы сделали сто таких. Теперь у вас есть все эти заметки. Так вот где вы можете начать использовать ИИ, чтобы помочь вам. >> Так что часть, где вы смотрели на эти данные, важна. Как мы обсуждали, вы не хотите слишком сильно автоматизировать эту часть. У людей все еще будут рабочие места. Это вывод здесь. Это здорово. >> Да. Просто просмотр трассировок. По крайней мере, пока есть одна работа. >> Да. Так что, да, точно. >> И, так, хорошо, у вас есть все эти заметки. Теперь, чтобы превратить это во что-то полезное, вы можете делать базовый подсчет. >> Так что базовый подсчет — это самая мощная аналитическая техника в науке о данных, потому что она так проста и часто недооценивается во многих случаях. И поэтому она очень доступна для людей. И поэтому первое, что вы хотите сделать, — это взять эти заметки, и вы можете категоризировать их с помощью LLM. И есть много разных способов сделать это. Прямо перед этим подкастом я взял три разных агента для кодирования или, знаете ли, ИИ-инструмента и попросил его категоризировать эти заметки. Так что одно — это хорошо, я загрузил это в облачный проект. Я загрузил CSV этих заметок и просто экспортировал их напрямую из этого интерфейса. >> Есть много разных способов сделать это, но я показываю вам простой, глупый способ, самый базовый способ делать вещи. И поэтому я забросил CSV сюда и сказал: "Пожалуйста, проанализируйте следующий файл CSV. Есть, и я сказал ему, что есть поле метаданных, в котором есть заметка". Но что я сказал, это я использовал слово "открытые коды". Я сказал: "Эй, у меня есть разные открытые коды, и это термин из области, это то, что LLM знают, что такое открытые коды, и они знают, что такое осевые коды, потому что это концепция, которая существует уже очень давно. Так что эти слова помогают мне сократить то, что я пытаюсь сделать". >> Это потрясающе. И конец промпта — это указание ему создать осевые коды. >> Да, создание кодов. >> Так что, возможно, стоит поговорить о том, что такое осевые коды, или о том, в чем смысл? >> У вас есть беспорядок открытых кодов, верно? И у вас нет 100 отдельных проблем, на самом деле многие из них повторяются, но потому, что вы сформулировали их по-разному, верно? И при этом вы не должны были пытаться создать свою таксономию ошибок во время открытого кодирования, вы просто хотите записать, что неправильно, а затем организовать, хорошо, какой самый распространенный режим отказа? >> Так что цель осевого кода, по сути, — это просто режим отказа. Это как метка или категория. И наша цель — добраться до этих кластеров режимов отказа и выяснить, что является наиболее распространенным. >> Так что вы можете пойти и решить эту проблему. >> Это очень полезно. По сути, вы просто синтезируете все эти категории и темы. >> Очень круто. И мы включим этот промпт в наши заметки к выпуску, чтобы людям не пришлось сидеть и делать скриншоты и пытаться напечатать его самостоятельно. >> Да, отличная идея. >> И, таким образом, Claude, знаете ли, проанализировал файл CSV, решил, как его разобрать, бла-бла-бла, нам не нужно беспокоиться обо всем этом. Но он придумал кучу осевых кодов. По сути, осевые коды — это категории, как сказала Шрея. Так что один — это хорошо, ограничения возможностей, искажение информации, нарушения протокола обработки, проблемы с передачей человеку, качество связи. Он создал эти категории. Теперь, нравятся ли мне все категории? Не очень. Мне нравятся некоторые из них. Это хороший первый шаг. Я бы, вероятно, немного переименовал их, потому что некоторые из них слишком общие. Что такое ограничения возможностей? Это немного слишком широко. Это не действенно. Я хочу сделать их немного более действенными, чтобы, если я решу, что это проблема, я знал, что делать. Но мы обсудим это немного позже. >> Так что вы можете сделать это с чем угодно. И это самый глупый способ сделать это, но глупость иногда — хороший способ начать. >> И это то, в чем ИИ действительно хорош, брать много информации и синтезировать. >> Абсолютно. Синтезировать для нас, чтобы мы могли понять, верно? Обратите внимание, что он не говорит нам, он не предлагает автоматически исправления или что-то еще. Это наша работа. >> Но, знаете ли, теперь мы можем гораздо легче разобраться в этом беспорядке открытых кодов. Еще одна интересная вещь в этом промпте для генерации осевых кодов заключается в том, что вы можете быть очень подробными, если хотите, верно? Вы можете сказать: "Я хочу, чтобы каждый осевой код на самом деле был, знаете ли, каким-то действенным режимом отказа, и, возможно, LLM поймет это и предложит его, или я хочу, чтобы вы сгруппировали эти открытые коды по, знаете ли, на каком этапе истории пользователя он находится". Так что здесь вы можете, знаете ли, быть креативными или делать то, что лучше для вас как менеджера продукта или инженера, работающего над этим, и это поможет вам в дальнейшем улучшении. >> Хорошо. Так что нет окончательного промпта, вот единственный способ сделать это. Вы говорите, что вы можете итерировать, посмотреть, что работает для вас. >> Абсолютно. >> Интересно, что инструменты не хотят этого делать, или они пытаются, но просто не делают это хорошо? >> Нет, я не думаю, что они это делают. Мы кричали с крыш, пожалуйста, пожалуйста, сделайте это. Я думаю, это немного сложно, верно? Как часть всего этого опыта с курсом оценок, который мы с Хамилом преподаем, это то, что многие люди на самом деле не знают этого. >> Так что, возможно, люди этого не знают и не знают, как создавать для этого инструменты. >> И, надеюсь, мы сможем демистифицировать часть этого волшебства. >> И чтобы удвоить этот пункт, это не то, что делают или знают все. Это то, что вы двое разработали на основе своего опыта анализа данных и науки о данных в других компаниях. >> Ну, я хочу оговориться. Мы не изобрели анализ ошибок. Мы на самом деле не хотим изобретать вещи. Это плохой сигнал. Если кто-то приходит к вам с способом сделать что-то, что является совершенно новым и не основано на сотнях лет теории и литературы, тогда вы должны, я не знаю, быть немного осторожны с этим. Но то, что мы попытались сделать, это дистиллировать, хорошо, какие новые инструменты и методы вам нужно знать, чтобы разобраться в анализе ошибок LLM, а затем мы создали учебную программу или структурированный способ сделать это. Так что все это очень адаптировано к LLM, но, знаете ли, термины "открытое кодирование", "осевое кодирование" основаны на социальной науке. >> Потрясающе. Хорошо. Мне смешно, что вы двое это делаете, я просто хочу пойти и сделать это где-нибудь. У меня нет ИИ-продукта, чтобы сделать это, но это просто, о, это было бы так весело. Просто сидеть там и находить все проблемы, с которыми я сталкиваюсь, и категоризировать их, а затем пытаться их исправить. Восхитительно. >> Мне это нравится. >> Хамил вывел видео. Что у вас там происходит? >> Да. Я вывел видео, чтобы подчеркнуть точку зрения Шреи: мы ничего не изобретаем. Так что то, что вы видите на экране, это Эндрю Ын, один из известных исследователей машинного обучения в мире, который обучил много людей, честно говоря, машинному обучению. И вы можете видеть, что это видео 8-летней давности. И он говорит об анализе ошибок. И это техника, которая использовалась для анализа стохастических систем веками. >> И это то, что вы просто используете те же идеи и принципы машинного обучения, привнося их сюда, потому что, опять же, это стохастические системы. >> Отлично. Ну, одна вещь, которую мы работаем над тем, чтобы пригласить Эндрю на подкаст, мы общаемся. Так что это будет очень весело. >> Два, мне нравится, что мой другой подкаст-эпизод вышел сегодня в вашей ленте, и он там хорошо выделяется. Так что я очень доволен этой миниатюрой. >> Очень приятно. Да, рекомендательный алгоритм. >> Да. Вот оно. Надеюсь, вы нажмете на это. Не портите мой алгоритм. >> Хорошо, круто. Итак, мы провели некоторую синтезацию. Что, я знаю, мы не будем проходить весь шаг. Это как бы у вас есть целый курс, который занимает много дней, чтобы изучить весь этот процесс. Что еще вы хотите рассказать о том, как пройти этот процесс? >> Хорошо, вы можете сделать это через что угодно, и, знаете ли, я использовал то же самое, что прекрасно работает в ChatGPT. Тот же самый промпт. Вы можете видеть, что он создал осевые коды. Мне очень нравится использовать Julius AI. >> Это один из моих любимых инструментов. Julius — это своего рода сторонний инструмент, но он использует ноутбуки. Лично я очень люблю Jupyter Notebooks. И поэтому это больше относится к науке о данных, но многие менеджеры по продукту сейчас изучают ноутбуки, и это своего рода круто, это как бы веселая игровая площадка, где вы можете писать код и смотреть на данные. Но нам не нужно углубляться в это, просто хотел упомянуть, что вы можете использовать много, знаете ли, ИИ действительно хорош в этом. >> Итак, перейдем к самой интересной части. Вот оно. >> Итак, теперь у нас есть все ИИ. У нас есть эти осевые коды. Так что первое, что я люблю делать, у меня есть эти открытые коды, и у меня есть осевые коды, которые, скажем так, мы назначили из облачного проекта или из ChatGPT. И поэтому то, что я делаю, это я собираю их сначала и смотрю, нравятся ли мне эти осевые коды, и я смотрю на соответствие между различными осевыми кодами и открытыми кодами, и я прохожу упражнение и говорю: "Хм, нравятся ли мне эти коды? Могу ли я их улучшить? Могу ли я их уточнить? Могу ли я сделать их более конкретными?" >> Вместо того, чтобы быть общими, я делаю их очень конкретными и действенными. >> Так что вы видите те, которые я придумал: проблемы с планированием туров, перепланированием, проблемы с передачей человеку или переводом, ошибка форматирования в выводе, поток разговора. Мы видели проблему с потоком разговора с текстовыми сообщениями. >> Создание последующих обещаний, которые не выполняются. И, таким образом, по сути, то, что я могу сделать, что вы можете сделать сейчас, это у вас есть эти осевые коды, и >> Так что я просто собираю их в список. >> Это формула Excel, просто собирает эти коды в список. >> Так что теперь у нас есть список этих кодов, разделенных запятыми. И тогда то, что вы можете просто сделать, это вы можете взять свои заметки, у вас есть эти открытые коды, и вы можете сказать ИИ, и это использует Gemini AI просто для простоты. Это как бы, знаете ли, опять же, мы пытаемся сохранить простоту, категоризировать следующий заметку в одну из следующих категорий. >> Это способ для тех, кто смотрит, есть как бы все эти разные промпты и формулы, которые вы показываете. Это как бы Google Sheets AI AI промпт. >> Да. >> И поэтому, по сути, то, что вы можете сделать, это затем вы можете иметь, вы можете категоризировать свои трассировки в одну из категорий, и это то, что у нас есть здесь. Мы категоризировали все эти проблемы, с которыми мы столкнулись, в одну из этих вещей. >> И это автоматически, что очень захватывающе. Я имею в виду, ИИ делает это. Так что это также подчеркивает, что ваши открытые коды должны быть подробными, верно? Вы не можете просто сказать "коряво", потому что если ИИ читает "коряво", он не сможет его категоризировать. Даже человек не сможет, верно? Ему придется вспомнить, почему вы сказали "коряво". >> Так что важно быть, знаете ли, несколько подробным в вашем открытом коде. >> Хорошо. Так что избегайте слова "коряво" — это хорошее эмпирическое правило. >> Или другие слова. >> Хорошо. >> Я шутил. >> Да. Хорошо. >> Какие еще слова, которые приходят на ум, люди часто используют, которые, по вашему мнению, не хороши? >> Я не думаю, что это конкретные слова. Я думаю, что люди просто недостаточно подробны в открытом коде. Так что трудно проводить категоризацию. >> Отлично. И, кстати, причина, по которой вам нужно сопоставить их обратно, заключается в том, что, скажем, Claude GPT дал вам предложения, а вы их изменили и итерировали на них. Так что вы не можете просто вернуться и сказать: "Круто, что в каждом баке?" >> Да. Да. >> Отличный вопрос на самом деле. Хорошо итерировать и немного подумать об этом: нравятся ли мне эти открытые коды? Имеют ли они смысл для меня? Как и все, что делает ИИ, очень хорошо, что вы как бы ставите себя в середину. >> Все еще в цикле. >> Да. >> Одна из вещей, которую я люблю делать на этом этапе, если я пытаюсь использовать ИИ для этой маркировки, это также иметь новую категорию "ничего из вышеперечисленного". >> Так что ИИ может на самом деле сказать "ничего из вышеперечисленного" в осевом коде, и это информирует меня, "хорошо, мои осевые коды неполны". Типа, давайте посмотрим на эти открытые коды. Давайте выясним, какие новые категории есть, или выясним, как переформулировать мои другие осевые коды. >> Отлично. И что круто в этом, так это то, что вам не нужно делать это много, много раз. >> Нет. >> Для большинства.

продукты, вы делаете этот процесс один раз, а затем строите на нем, я полагаю, и просто дорабатываете его со временем. >> Абсолютно. И это становится так быстро. Например, люди делают это примерно раз в неделю, и вы можете сделать все это примерно за 30 минут, и внезапно ваш продукт становится намного лучше, чем если бы вы никогда не знали ни о каких из этих проблем. >> Да. Это абсурдно чувствовать, что вы не знали бы, что это происходит, как будто наблюдая за этим. Я думаю, как вы можете не делать этого со своим продуктом? >> Многие люди понятия не имеют. >> Большинство людей. Да. >> Да. Мы поговорим об этом. Есть целые дебаты вокруг этих вещей, которые мы хотим обсудить. Хорошо, круто. Итак, у вас есть это, у вас есть лист. Что дальше? >> Хорошо. Итак, вот большое разоблачение. >> Это волшебный момент прямо сейчас. >> Итак, у нас есть все эти коды, которые, как вы знаете, мы применили те, которые нам понравились в наших трассировках. Теперь вы можете сделать та-да. Вы можете их посчитать. Итак, вот сводная таблица, и мы можем просто сделать сводную таблицу по ним, и мы можем посчитать, сколько раз встречались эти разные вещи. Итак, что мы находим? На этих трассировках, которые мы категоризировали, мы обнаружили 17 проблем с разговорным потоком. И мне очень нравятся сводные таблицы, потому что вы можете делать классные вещи. Вы можете дважды щелкнуть по ним. Вы можете сказать: «О, хорошо. Позвольте мне взглянуть на них». Но это уход в сторону о сводных таблицах, насколько они круты. Но, э-э, вы знаете, теперь у нас есть просто хороший черновой вариант того, какие у нас проблемы, и теперь мы перешли от хаоса к некоторому осмыслению того, что, знаете ли, это мои самые большие проблемы, которые мне нужно исправить, разговорные проблемы, знаете ли, возможно, эти проблемы с передачей человеку. Не обязательно количество — это самое важное, знаете ли, это может быть что-то, что просто очень плохо, и вы хотите это исправить. Но хорошо, теперь у вас есть способ взглянуть на свою проблему, и теперь вы можете подумать, нужны ли вам оценки для некоторых из них. Итак, вы знаете, что некоторые из этих вещей могут быть просто глупыми инженерными ошибками, для которых вам не нужно писать оценку, потому что очень очевидно, как их исправить. Возможно, ошибка форматирования с выводом. Возможно, вы просто забыли сказать LLM, как вы хотите, чтобы он был отформатирован, и вы даже не сказали этого в подсказке. Так что просто исправьте подсказку, может быть, знаете ли, и мы можем решить, хотите ли вы написать электронное письмо для этого? Вы можете по-прежнему захотеть написать электронное письмо для этого, потому что вы можете протестировать это просто с помощью кода. Вы можете просто протестировать строку. Имеет ли она правильное форматирование, потенциально не запуская LLM? Итак, есть компромисс между затратами и выгодой для оценки. Вы не хотите увлекаться этим. Но вы хотите начать, вы обычно хотите опираться на свои фактические ошибки. Вы не хотите пропускать этот шаг. И поэтому причина, по которой я так много времени уделяю этому, заключается в том, что именно здесь люди теряются. они идут прямо в оценку, как будто позвольте мне просто написать несколько тестов, и именно тогда все идет наперекосяк. Итак, давайте, давайте, хорошо, давайте предположим, что мы хотим заняться одной из этих вещей. Например, давайте предположим, что мы хотим заняться этой проблемой передачи человеку, и мы думаем: «Хм, я не совсем уверен, как это исправить». Это своего рода субъективное решение, знаете ли, должны ли мы передавать человеку, и я не знаю, как это немедленно исправить. Это не совсем очевидно, само по себе. Да, я могу изменить свою подсказку, но я не уверен. Я не на 100% уверен. Ну, это может быть интересная вещь для LLM в качестве судьи, например. Итак, есть разные виды оценок. Одна из них — основанная на коде, которую вы должны стараться делать, если можете, потому что они дешевле. Вам не нужно, знаете ли, LLM в качестве судьи — это своего рода мета-оценка. Вам нужно оценить эту оценку, чтобы убедиться, что LLM, который судит, делает правильные вещи, о чем мы поговорим через секунду. Итак, хорошо, LLM в качестве судьи, это одна вещь. Хорошо, как вы создаете LLM в качестве судьи? Прежде чем мы перейдем к этому, просто чтобы убедиться, что люди точно знают, что вы описываете, есть два типа оценок. Один, вы сказали, основан на коде, другой — LLM в качестве судьи. Может быть, Шрея просто поможет нам понять, что такое оценка на основе кода? Это просто как, это по сути модульный тест. Это простой способ думать об этом? >> Возможно, оценка — это не совсем правильный термин здесь, но думайте об этом как об автоматизированном оценщике. Итак, когда мы находим эти режимы сбоев, одна из вещей, которую мы хотим, это: «Хорошо, можем ли мы теперь проверить распространенность этого режима сбоя в автоматическом режиме, без того, чтобы я вручную маркировал и делал все кодирование и группировку, и я хочу запустить это на тысячах и тысячах трассировок. Я хочу запускать это каждую неделю. Это нормально. Вам, вероятно, следует создать автоматизированный оценщик для проверки этого режима сбоя. Теперь, когда мы говорим «на основе кода» против «на основе LLM», мы говорим: «Хорошо, возможно, я мог бы написать функцию Python или фрагмент кода для проверки наличия этого режима сбоя в трассировке или нет». И это возможно для определенных вещей, таких как проверка того, что вывод является JSON, или проверка того, что это markdown, или проверка того, что он короткий, — все это вещи, которые вы можете захватить в коде или приблизительно захватить в коде. Когда мы говорим о LLM-судье здесь, мы говорим, что это сложный режим сбоя, и мы не знаем, как его оценить в автоматическом режиме. Так что, возможно, мы попытаемся использовать LLM для оценки этого очень, очень узкого, специфического режима сбоя передачи. >> Итак, просто чтобы попытаться отразить то, как вы описываете, вы хотите протестировать, что делает ваш агент или продукт ИИ. Вы задаете ему вопрос, он возвращает что-то. Один из способов проверить, дает ли он правильный ответ, заключается в том, последовательно ли он делает одно и то же, что вы могли бы написать код, чтобы сказать вам, что это правда или ложь. Например, скажет ли он когда-нибудь, что есть виртуальный тур? Так что вы могли бы спросить >> предоставляете ли вы виртуальные туры? >> Он говорит да или нет, а затем вы могли бы написать код, чтобы сказать вам, правильно ли это на основе этого конкретного ответа. Но если вы спрашиваете о чем-то более сложном, и это не бинарно, вам почти нужен, в одном мире, человек, чтобы сказать вам, что это правильно. Решение, чтобы избежать того, чтобы людям приходилось каждый раз автоматически проверять все это, — это LLM, заменяющие человеческое суждение, и вы называете это LLM в качестве судьи. LLM является судьей, правильно это или нет. >> Абсолютно. Вы угадали. >> Итак, люди всегда думают: «О, это, по крайней мере, так же сложно, как моя проблема создания исходного агента». И это не так, потому что вы просите судью сделать одну вещь, оценить один режим сбоя. Так что объем проблемы очень мал, а вывод этого LLM-судьи — это своего рода «пройдено» или «не пройдено». Так что это очень, очень строго ограниченная вещь, с которой LLM-судьи очень способны справляться очень надежно. >> И цель здесь — просто иметь набор тестов, которые запускаются перед отправкой в продакшн, которые говорят вам, что вещи идут так, как вы хотите, так, как ваш агент взаимодействует. Прекрасная вещь в LLM-судье — вы можете использовать их в модульных тестах или CI, но вы также можете использовать их онлайн для мониторинга, верно? Например, я могу взять выборку из тысячи трассировок каждый день, запустить свой LLM-судья на реальных производственных трассировках и увидеть, каков здесь процент сбоев. Это не модульный тест, но все же теперь у нас есть чрезвычайно точная мера качества приложения. >> Круто, это действительно отличный момент, потому что многие люди считают это нереальным. Это то, что вы тестируете до того, как оно фактически окажется в реальном мире. >> И что на самом деле происходит в реальном мире. Вы говорите, что вы можете фактически, вы должны фактически сделать именно это. Тестируйте свою реальную вещь, работающую в продакшне, и это своего рода ежедневная или ежечасная вещь, которую вы можете запускать. >> Полностью. >> Отлично. Хорошо. У Хамиля есть пример реальной оценки LLM в качестве судьи. Так что давайте посмотрим. >> Мне нравится, как Шрея действительно подготовила почву для меня. Так что большое вам спасибо. Итак, у нас есть подсказка LLM в качестве судьи для этого одного конкретного сбоя. Как сказала Шрея, вы захотите сделать один конкретный сбой, и вы хотите сделать его бинарным, потому что мы хотим упростить вещи. Мы не хотим: «О, оцени это по шкале от одного до пяти, насколько это хорошо?» Это в большинстве случаев просто трусливый способ не принимать решения. Нет, вам нужно принять решение. Достаточно ли это хорошо или нет? Да или нет. Может быть больно думать о том, что это такое, но вы абсолютно должны это сделать. В противном случае эта вещь станет очень неуправляемой. И тогда, когда вы сообщаете эти метрики, никто не знает, что означает 3,2 по сравнению с 3,7. >> Это да, мы видим это все время. И даже с экспертным контентом в Интернете, который выглядит так: «О, вот ваш оценщик LLM-судьи. Вот шкала от одного до семи». И я всегда думаю, я всегда пишу Хамилю: «О нет, теперь нам придется бороться с дезинформацией снова, потому что мы знаем, что кто-то попробует это, а затем вернется к нам и скажет: «О, у меня среднее 4,2». И мы скажем: «Хорошо, это дико, сколько драмы в пространстве оценок. Мы доберемся до этого». О, боже. Этот эпизод предоставлен Mercury. Я пользуюсь услугами Mercury уже много лет, и, честно говоря, я не могу представить себе другой способ ведения банковских операций. Я перешел из Chase, и, черт возьми, какая разница. Отправка переводов, отслеживание расходов, предоставление моей команде доступа для перемещения денег — все это чертовски просто. Там, где большинство традиционных банковских веб-сайтов и приложений громоздки и трудны в использовании, Mercury тщательно разработан, чтобы быть интуитивно понятным и простым. И Mercury объединяет все способы использования денег в одном продукте, включая кредитные карты, выставление счетов, оплату счетов, возмещение расходов для ваших коллег и капитал. Независимо от того, являетесь ли вы финансируемым технологическим стартапом, ищущим способы платить подрядчикам и получать доход от ваших неиспользуемых денежных средств, или агентством, которому необходимо выставлять счета клиентам и поддерживать их в актуальном состоянии, или электронной коммерцией бренд, которому необходимо следить за денежным потоком и избыточным капиталом, Mercury может быть адаптирован для помощи вашему бизнесу работать на самом высоком уровне. Узнайте, что любят более 200 000 предпринимателей в Mercury. Посетите mercury.com, чтобы подать заявку онлайн за 10 минут. Mercury — это финтех, а не банк. Банковские услуги предоставляются через партнерские банки Mercury, застрахованные FDIC. Для получения более подробной информации ознакомьтесь с заметками к выпуску. Итак, это ваша подсказка судьи. Нет единственного способа сделать это. Это нормально использовать LLM для создания подсказки, но опять же, поставьте себя в цикл. Не принимайте слепо то, что делает LLM. И во всех этих случаях мы так и поступили. Как и с осевыми кодами, мы как бы итерировали над этим. Вы можете использовать LLM, чтобы помочь вам создать эту подсказку, но убедитесь, что вы ее прочитали. Убедитесь, что вы ее отредактировали, что угодно. Это не обязательно идеальная подсказка. Это просто глупая, очень простая, чтобы показать вам идею: «Хорошо, для этого сбоя передачи, э-э, я сказал: «Хорошо, я хочу, чтобы вы вывели «истина» или «ложь», это бинарно. Это бинарный судья. Это то, что мы рекомендуем. А затем я просто прохожу и говорю: «Хорошо, когда следует делать передачу?» И я просто перечисляю их: «Хорошо, явный запрос человека проигнорирован или зациклен». >> Некоторые переводы, предписанные политикой, проблемы с конфиденциальными данными, недоступность данных инструмента, запросы на однодневные визиты или туры, вам нужно поговорить с человеком для этого. И так далее, верно? И идея в том, что теперь, когда я знаю, что это сбой из моих данных, я заинтересован в его итерации, потому что я знаю, что это происходит постоянно. И, как сказала Ша, было бы неплохо иметь способ не только оценить это на имеющихся у меня данных, но и на производственных данных, чтобы получить представление о том, в каком масштабе это происходит? Позвольте мне найти больше трассировок. Позвольте мне иметь способ итерировать над этим. И поэтому мы можем взять эту подсказку, и я снова буду использовать электронную таблицу. Итак, первый шаг: «Хорошо, когда я делаю этого судью, я написал подсказку. Теперь многие люди останавливаются там и говорят: «Хорошо, у меня есть моя подсказка судьи, мы закончили, хорошо? Давайте просто, давайте просто отправим ее, и пусть подсказка говорит, что если судья говорит, что это неправильно, то это неправильно». Они просто принимают это как истину в последней инстанции: «Хорошо, LLM говорит, что это неправильно, это должно быть неправильно». Не делайте этого, потому что это самый быстрый способ иметь оценки, которые не соответствуют тому, что происходит. И когда люди теряют доверие к вашим оценкам, они теряют доверие к вам. Так что очень важно, чтобы вы этого не делали. И поэтому, прежде чем вы выпустите свой LLM в качестве судьи, вы хотите убедиться, что он соответствует человеку. Как вы это делаете? Вы фактически берете эти осевые коды и хотите измерить своего судью по сравнению с осевым кодом и сказать: «Эй, он согласен со мной? Мой собственный судья согласен со мной?» Просто измерьте это. И вот что у нас есть: «Хорошо, я говорю: «Оцените эту LLM-трассировку». Опять же, я использую просто электронные таблицы. «Оцените эту LLM-трассировку в соответствии с этими правилами». И правила — это просто подсказка, которую я только что показал вам. И я спрашиваю: «Хорошо, произошла ли ошибка передачи, истина или ложь?» Итак, эта колонка, позвольте мне немного увеличить масштаб. Колонка H, у меня есть: «Хорошо, произошла ли эта ошибка?» В колонке G — это то, что я думал, произошла ли ошибка или нет. Вы можете видеть >> вы проходите через это вручную. Вы делаете это. >> Да. Да. И мы уже сделали это. Мы уже прошли через это вручную. Так что нам не нужно делать это снова, потому что у нас есть этот чит-код из осевого кодирования. Мы уже сделали это. >> Вы можете пройти через это снова, если вам нужно больше данных, и есть много деталей в этом о том, как это сделать правильно. Вы хотите разделить свои данные и сделать все эти вещи, чтобы вы не обманывали, но я просто хочу показать вам концепцию, и, по сути, вы можете измерить согласие. >> Одна вещь, которую вы должны знать как менеджер продукта, заключается в том, что многие люди идут прямо к этому согласию. Они говорят: «Хорошо, мой судья согласен с человеком в определенном проценте случаев». Теперь это звучит привлекательно, но это очень опасная метрика для использования, потому что во многих случаях ошибки случаются на длинном хвосте и случаются не так часто. Так что, если ошибка случается только в 10% случаев, то вы можете легко получить 90% согласия, просто заставив судью сказать, что он проходит все время. Имеет ли это смысл? Так что 90% согласия может выглядеть хорошо на бумаге, но может быть вводящим в заблуждение. >> И это редко. Это редко. >> Да. >> Так что, знаете ли, как менеджер продукта или кто-то, даже если вы не делаете этот расчет сами, если кто-то когда-либо сообщает вам о согласии, вы должны немедленно спросить: «Расскажите мне больше». Вам нужно, вам нужно углубиться, чтобы получить больше интуиции. Вот матрица, хорошо, этой конкретной судьи в Google Sheets. И это снова сводная таблица, просто сохраняя ее глупой и простой: «Хорошо, в строках у меня то, что думал человек, то, что я думал, была ли ошибка, истина или ложь, а затем была ли ошибка у моего судьи, истина или ложь? >> Интуиция здесь именно такова, как сказал Хамил, верно? Вам нужно посмотреть на каждый тип ошибки. Итак, когда человек сказал «ложь», а судья сказал «истина» или наоборот. Так что эти незеленые диагонали здесь, и если они слишком велики, то итерируйте свою подсказку, сделайте ее более понятной для LLM-судьи, чтобы вы могли уменьшить это несоответствие. Вы хотите достичь точки, когда большинство, у вас будет некоторое несоответствие, это нормально. Мы также говорим в нашем курсе о том, как исправить это несоответствие с помощью кода, но на этом этапе, если вы менеджер продукта, а человек, который создает оценку LLM-судьи, не сделал этого, они говорят: «О, он согласен на 75% случаев, мы в порядке». У них нет этой матрицы, и они не итерировали, чтобы убедиться, что эти два типа ошибок снизились до нуля, тогда это плохой знак. Попросите их исправить это. >> Отлично. Это действительно хороший совет, на что обращать внимание, когда кто-то делает это неправильно. >> Да. >> На самом деле, не могли бы вы вернуть нас к подсказке LLM в качестве судьи? Я просто хочу выделить что-то действительно интересное здесь. У меня недавно были гости на подкасте, которые говорили, что оценки — это новые PRD. И если вы посмотрите на это, это именно то, что это. Как менеджеры продуктов, продуктовые команды, верно? Вот каким должен быть продукт. Вот все требования. Вот как он должен работать. Они построили вещь. А затем они часто тестируют ее вручную. Что круто в этом, так это то, что это именно то же самое. И это работает постоянно. Это говорит вам: «Вот как этот агент должен реагировать в очень специфических случаях». Если это, это, это, сделайте это. Если это, это, это, сделайте это. И поэтому это именно то, что я слышал снова и снова. Вы можете увидеть прямо здесь. Это как бы чистейшее проявление того, каким должен быть документ с требованиями к продукту, это оценщик-судья, который говорит вам, каким он должен быть, и это автоматически и работает постоянно. >> Да, абсолютно. И это как бы выведено из наших собственных данных. Так что, конечно, это ожидания менеджера продукта. Что я нахожу, что многие люди упускают, это то, что они просто ставят свои ожидания, прежде чем смотреть на свои данные. Но когда мы смотрим на наши данные, мы обнаруживаем больше ожиданий, о которых мы даже не могли мечтать. И это в конечном итоге попадает в эту подсказку. Так что это интересно. Так что ваш совет не заключается в том, чтобы сразу переходить к оценкам и подсказкам LLM-судьи, прежде чем вы создадите продукт. Все еще пишите традиционные одностраничные PRD, чтобы рассказать своей команде, что мы делаем, почему мы это делаем, как выглядит успех, но затем в конце вы, вероятно, сможете использовать это и даже улучшить исходный PRD, если вы развиваете продукт с помощью этого процесса. >> Я бы пошел еще дальше и сказал, что вы улучшите. Это изменится. Вы никогда не узнаете, какими будут режимы сбоев заранее, и вы всегда будете открывать новые, знаете ли, настроения, которые, по вашему мнению, должен иметь ваш продукт, верно? Вы действительно не знаете, чего хотите, пока не увидите это с этими LLM. Так что вам придется быть гибкими, смотреть на свои данные, PRD — это отличная абстракция для размышлений об этом, но это не конец всего. Это изменится. >> Мне это нравится. И Хамил выводит какой-то крутой исследовательский отчет. О чем это? >> О, это один из самых крутых исследовательских отчетов, которые вы можете прочитать, если хотите узнать об оценках. Он был написан кем-то по имени Шрея Шанкар. >> О боже. >> И ее соавторами, и поэтому он называется «Кто проверяет валидатора?» >> Это лучшее название для исследования, которое я когда-либо слышал. Это так хорошо. >> Спасибо. >> Так что я должен позволить Треи рассказать об этом. Я думаю, что одна из самых важных вещей, на которую стоит обратить внимание в этой статье, — это дрейф критериев. >> Да. >> И что она нашла. >> Мы провели это супер веселое исследование, когда мы проводили пользовательские исследования с людьми, которые пытались писать LLM-судьи или просто валидировали свои собственные выходные данные LLM. И это было, я думаю, это было до того, как оценки стали чрезвычайно популярны в Интернете. Мы провели этот проект примерно в конце 2023 года, когда мы начали его. Но тогда то, что действительно беспокоило меня как исследователя, это: «Почему эта проблема так сложна?» У нас есть машинное обучение и ИИ так давно. Это не ново. Но внезапно на этот раз все действительно сложно. Поэтому мы провели это пользовательское исследование с группой разработчиков и поняли: «Хорошо, что здесь нового, так это то, что вы не можете заранее определить свои рубрики. Мнения людей о хорошем и плохом меняются по мере того, как они просматривают больше выходных данных. Они думают о режимах сбоев только после того, как увидят 10 выходных данных, о которых они никогда бы не подумали в первую очередь. И это эксперты, верно? Это люди, которые создали множество конвейеров LLM и агентов раньше, и просто вы никогда не сможете придумать все заранее. И я думаю, что это так важно в современном мире разработки ИИ. >> Хорошо, это действительно хороший момент. Это очень сильно подкрепляет то, о чем мы только что говорили, и именно поэтому Хамил вытащил это, это просто «Хорошо». >> Да. >> Хорошо, отлично. У вас все еще есть продукт, который нужно делать так же, но теперь у вас есть этот очень мощный инструмент, который помогает вам убедиться, что то, что вы построили, правильно. Это не заменит процесс PR. >> Круто. >> Сколько оценок этих, сколько, скажем, я не знаю, подсказок LLM-судьи у вас обычно бывает? Я знаю, очевидно, зависит от сложности продукта, но каково это, число из вашего опыта? >> Для меня, где-то между четырьмя и семью. >> О, вот и все. >> Это не так много, потому что многие режимы сбоев, как сказал Хамил ранее, могут быть исправлены просто исправлением вашей подсказки. Вы просто не подумали включить это в свои подсказки, а теперь вы включили это в свои. Вам не следует делать оценку для всего, только для тех надоедливых, которые вы описали свое идеальное поведение в подсказке агента, но оно все еще терпит неудачу. >> Понятно. Итак, скажем, вы нашли проблему, вы ее исправили. В традиционной разработке программного обеспечения вы бы написали модульный тест, чтобы убедиться, что это больше не произойдет. Ваш вывод здесь: даже не стоит писать оценку вокруг этого, если это просто ушло? >> Я думаю, вы можете, если хотите, но вся игра здесь заключается в приоритизации. У вас есть ограниченные ресурсы и ограниченное время. Вы не можете написать оценку для всего. Так что приоритизируйте те, которые являются более надоедливыми областями. >> И, вероятно, те, которые наиболее рискованны для вашего бизнеса, если они говорят что-то вроде «Мека Гитлер Грок»? >> Круто. Хорошо, это очень успокаивает, потому что эта подсказка — это большая работа, чтобы действительно продумать все эти детали. >> Но это большая разовая стоимость, а теперь навсегда вы можете запускать это на своем приложении. >> Правильно. И я хочу сказать: «Хорошо, анализ данных очень мощный, он приведет к множеству улучшений вашего приложения очень быстро». Мы показали самый базовый вид анализа данных, который является подсчетом, который доступен всем. Вы можете получить более сложный анализ данных. Есть много разных способов взять выборку, посмотреть на данные. Мы сделали это так, чтобы это выглядело легко, в некотором смысле, но здесь есть много навыков, чтобы сделать это хорошо. Вы знаете, выработка интуиции и чутья, как разбираться в этих данных. Например, скажем, я нахожу разговорные проблемы, эти разговорные проблемы потока. Возможно, если бы я пытался дальше разобраться в этой проблеме, я бы подумал о способах найти другие проблемы разговорного потока, которые я не кодировал. Вы знаете, я бы, возможно, покопался в данных несколькими способами. И есть, знаете ли, разные способы сделать это. Это очень похоже, если не почти точно так же, как традиционные методы аналитики, которые вы бы использовали для любого продукта. Дайте нам краткое представление о том, что дальше, а затем давайте поговорим о дебатах вокруг оценки. >> Итак, что дальше после того, как вы создали свой LLM-судья? Ну, мы обнаружили, что люди просто пытаются использовать это везде, где могут. Так что они будут помещать LLM-судью в модульные тесты, как вы, и они будут знать: «О, вот несколько примеров трассировок, где мы видели этот сбой, потому что мы его маркировали». Теперь мы сделаем их частью модульных тестов и убедимся, что каждый раз, когда мы вносим изменение в наш код, эти тесты проходят. Они также используют его для онлайн-мониторинга. Люди создают на этом панели инструментов, и я думаю, что это невероятно. Я думаю, что продукты, которые делают это правильно, имеют очень четкое представление о том, насколько хорошо работает их приложение. И люди не говорят об этом, потому что это их преимущество, верно? Так что люди не собираются делиться всем этим, потому что это имеет смысл, верно? Если вы являетесь помощником по написанию электронных писем, и вы делаете это, и вы делаете это хорошо, вы не хотите, чтобы кто-то другой создал помощника по написанию электронных писем, а затем вытеснил вас из бизнеса. Так что я действительно хочу подчеркнуть, что вы должны стараться использовать эти артефакты, которые вы создаете, везде, где это возможно, онлайн, неоднократно. Используйте их для улучшения вашего продукта. Часто Хамил и я говорим людям, как это сделать, и тогда это щелкает для людей, и они больше никогда не возвращаются. Так что либо они, я не знаю, бросили работу, они больше не занимаются разработкой ИИ, либо они знают, что делать дальше. Я думаю, что это последнее, но я думаю, что это очень мощно. Просто наблюдать за вами, как вы это делаете, действительно открыло мне глаза на то, что это такое и насколько систематичен процесс. Я всегда представлял, что вы просто сидите за компьютером, «Хорошо, какие вещи я должен убедиться, что они работают правильно». И то, что вы нам показываете, это: «Вот, это очень простой пошаговый процесс, основанный на реальных вещах, которые происходят в вашем продукте. Как их поймать, идентифицировать, приоритизировать, а затем >> абсолютно >> поймать их, если они снова произойдут, и исправить их. >> Да, это не магия. Любой может это сделать. Вам придется практиковать этот навык, как и любой новый навык, вам придется практиковать, но вы можете это сделать. И я думаю, что очень важно то, что менеджеры продуктов делают это и могут это делать, и действительно могут создавать очень, очень прибыльные продукты с этим набором навыков. >> Отлично. Отличный переход к дебатам, в которые мы как бы были втянуты, которые происходили в X на днях. Я не осознавал, сколько противоречий и драмы вокруг оценок. Есть много людей с очень сильными мнениями. Сабат, Шрея, дайте нам просто представление о двух сторонах дебатов о важности и ценности оценок, а затем дайте нам свою точку зрения. >> Да. Итак, хорошо, я буду немного умиротворять и скажу, что, по-моему, все на одной стороне. Я думаю, что заблуждение заключается в том, что у людей очень жесткие определения того, что такое оценка. Например, они могут думать, что оценка — это просто модульные тесты, или они могут думать, что оценка — это только часть анализа данных, а не онлайн-мониторинг или мониторинг специфических для продукта метрик, таких как фактическое количество чатов, в которых участвовали, или что-то еще. Так что я думаю, что у каждого свой подход к оценкам. И еще я скажу, что люди были обожжены оценками в прошлом. Так что я думаю, что люди делали оценки плохо. Один конкретный пример этого: они пытались сделать LLM-судью, но он не соответствовал их ожиданиям. Они обнаружили это только позже, а затем перестали ему доверять. И тогда они говорят: «О, я против оценок». И я полностью сочувствую этому, потому что, знаете ли, вы должны быть против, например, масштабного LLM-судьи. Я абсолютно согласен с вами. Мы тоже против этого. Так что многие заблуждения возникают из двух вещей, верно? Люди имеют узкое определение оценок, а затем люди делают это плохо, а затем обжигаются и хотят, чтобы другие люди не совершали эту ошибку, и тогда, к сожалению, X или Twitter — это среда, где люди неправильно интерпретируют то, что говорят все, и вы просто получаете все эти сильные мнения вроде «не делайте оценок, это плохо, мы пробовали, это не работает, мы клонировали код» или «вы знаете, или любой другой известный продукт, и мы не делаем оценок», и просто так много нюансов за всем этим, потому что, потому что многие из этих приложений стоят на плечах оценок, кодирование агентов — отличный пример этого, код Claude, они стоят на плечах базовой модели Claude, не базовой, но доработанных моделей Claude были оценены на многих кодовых бенчмарках, против этого не поспоришь. >> И просто чтобы уточнить, о чем вы говорите, где одна из глав, я думаю, возможно, главный инженер Claude Code, пошел на подкаст, и он сказал: «О, мы не делаем оценок, мы просто живем, мы просто смотрим на настроения», а настроения означают, что они просто используют его и чувствуют, правильно это или неправильно. >> И я думаю, что это работает. Есть две вещи, связанные с этим, верно? Во-первых, они стоят на плечах оценок, которые делают их коллеги для кодирования. >> Базовой модели Claude. >> Абсолютно верно, мы знаем, что они сообщают эти цифры, потому что мы видим бенчмарки, мы знаем, кто там хорошо справляется. Другое дело, что они, вероятно, очень систематичны в анализе ошибок в некоторой степени. Я уверен, что они отслеживают, кто использует Claude, сколько людей использует Claude, сколько чатов создается, сколько длится эти чаты. Они также, вероятно, отслеживают в своей внутренней команде, они занимаются дог-фудингом. Как только что-то не так, у них, возможно, есть очередь, или они отправляют это человеку, разрабатывающему Claude Code, и этот человек неявно выполняет некоторую форму анализа ошибок, о которой говорил Хамил. Все это оценка, верно? Нет такого мира, в котором они просто говорят: «Я сделал Claude Code, я никогда ни на что не смотрю». И, к сожалению, когда вы не думаете об этом или не говорите об этом, я думаю, что сообщество, большинство сообщества — новички, или люди, которые не знают об оценках и хотят узнать о них. И это посылает неверный сигнал. Теперь я не знаю, что делает Claude Code, очевидно, но я готов поспорить на деньги, что они делают что-то в форме оценок. >> Также скажу, что кодирующие агенты принципиально отличаются от других ИИ-продуктов, потому что разработчик является экспертом в предметной области. Так что вы можете обойти многие вещи, и разработчик использует его весь день. Так что есть своего рода дог-фудинг и своего рода экспертиза в предметной области, которая, вы знаете, вы можете сократить действия. Вам не нужно столько данных. Вам не нужно столько обратной связи или исследований, потому что вы знаете, что ваш процесс оценки должен выглядеть иначе. >> Потому что вы видите код, вы видите код, который он генерирует, вы можете сказать, что это отлично, это ужасно. >> Да, да. >> И поэтому, и поэтому я думаю, что многие люди обобщили кодирующие агенты, потому что кодирующие агенты — это первый ИИ-продукт, выпущенный в мир, и я думаю, что это ошибка пытаться обобщить это на заряд. >> Другое дело, да, у инженеров есть личность дог-фудинга. Есть множество приложений, где люди пытаются создавать ИИ в определенных областях, и они не занимаются дог-фудингом, например, для врачей, которые не пытаются получить самый неправильный совет от ИИ и быть терпимыми и восприимчивыми к этому. Так что очень важно учитывать эти нюансы. Итак, что я слышу от вас, Шрея, интересно, что если вы, если люди в команде проводят очень тщательный анализ данных, анализ ошибок, безумный дог-фудинг, вы описываете это как то, что находится под зонтиком оценки. Так что вы можете сделать это так, если у вас есть время и мотивация для этого, или вы можете настроить эти вещи автоматически. >> Абсолютно. И это также связано с навыками, верно? Люди, которые работают в Anthropic, очень, очень высококвалифицированы. Они обучены анализу данных, разработке программного обеспечения или ИИ и так далее, верно? >> И вы знаете, вы можете достичь этого. Любой может достичь этого, конечно, путем изучения концепций, но >> большинство людей сейчас не обладают этим навыком. >> Дог-фудинг — это опасная вещь, только потому, что многие люди говорят, что они занимаются дог-фудингом. Они говорят: «Да, мы занимались дог-фудингом». Но действительно ли они? И многие люди на самом деле не занимаются дог-фудингом на том висцеральном уровне, который вам понадобится, чтобы замкнуть этот цикл обратной связи. Так что это единственная оговорка, которую я бы добавил. Есть также своего рода аргумент соломенного чучела: оценка против A/B-тестов. >> Поговорите о своих мыслях по этому поводу, потому что это кажется большой частью этих дебатов, которые люди ведут: нужно ли вам оценивать, если у вас есть A/B-тесты, которые тестируют метрики на уровне продакшена? A/B-тесты — это снова своего рода оценка, я полагаю, верно? Когда вы проводите A/B-тест, у вас есть два разных экспериментальных условия, а затем у вас есть метрика, которая количественно оценивает успех чего-либо, и вы сравниваете метрику, и снова, оценка в нашем понимании — это систематическое измерение качества, некоторая метрика. Вы не можете действительно провести A/B-тест без оценки для сравнения. >> Так что, возможно, возможно, у нас просто другой странный взгляд на это. Да. Хорошо. Итак, я слышу, что вы считаете A/B-тесты частью набора оценок, которые вы проводите. Я думаю, когда люди думают об A/B-тестах, это как будто мы меняем что-то в продукте. Мы собираемся посмотреть, улучшит ли это какую-то метрику, которая нас волнует. Это достаточно? Почему нам нужно тестировать каждую мелочь? Как будто это влияет на метрику, которая нас волнует как бизнес, у нас есть куча A/B-тестов, которые постоянно запускаются. >> Это теперь отличный момент. >> Итак, я думаю, что многие люди преждевременно проводят A/B-тесты, потому что, знаете ли, они никогда раньше не проводили никакого анализа ошибок. Они просто гипотетически придумали свои требования к продукту и верят, что, знаете ли, мы должны тестировать эти вещи. Но оказывается, когда вы углубляетесь в данные, как показал Хамил, ошибки, которые мы видим, — это не то, что вы думали, что ошибки могут быть. Это были эти странные проблемы с передачей или, я не знаю, эта штука с текстовыми сообщениями была странной. Так что я бы сказал, что если вы собираетесь проводить A/B-тесты, и они основаны на фактическом анализе ошибок, как мы показали сегодня, то это отлично. Идите и делайте это. Но если вы просто собираетесь делать их, что, как мы обнаружили, люди пытаются делать, просто хотите делать их на основе того, что вы гипотетически считаете важным, тогда я бы призвал людей переосмыслить это и как бы обосновать свои гипотезы. >> У вас есть мысли о том, что Stat Sig собирается делать в OpenAI? Есть ли там что-нибудь интересное? Я просто, это было большое дело, огромное приобретение компании A/B-тестов, люди говорят: «О, A/B-тесты — это будущее». Мысли? Знаете, чтобы добавить к предыдущему вопросу немного: почему существует этот спор между A/B-тестированием и оценками? Я думаю, что фундаментально оценка — это люди пытаются понять, как улучшить свои приложения, и фундаментально вам нужно заниматься наукой о данных. Наука о данных полезна в продуктах, таких как просмотр данных, проведение аналитики данных. Есть много разных наборов инструментов, и вам не нужно изобретать ничего нового, конечно, вам не обязательно нужен весь спектр науки о данных, и это выглядит немного иначе, просто немного с LLM. Вы знаете, ваши тактики могут быть разными. И поэтому на самом деле это использование аналитических инструментов для понимания вашего продукта. Теперь люди говорят, что слово «оценка» пытается как бы выделить эту новую вещь и сказать: «О, оценка, а затем A/B-тестирование», но если вы увеличите масштаб, это та же наука о данных, что и раньше. И я думаю, что именно это вызывает путаницу: «Эй, нам нужно мышление в области науки о данных, и ИИ-продукт, просто полезно иметь это мышление в ИИ-продуктах, как и в любом продукте». Это мой взгляд на это. Так что да, это действительно хороший взгляд. Я думаю, что просто слово «оценка» теперь вызывает у людей раздражение. >> И если вы просто назовете это «мы просто занимаемся анализом ошибок, используем науку о данных, чтобы понять, где наш продукт ломается, и просто настраиваем тесты, чтобы убедиться, что мы знаем». >> Это скучно. Это звучит скучно. >> Нет, нет, нет, нам нужен таинственный термин, такой как «оценки», чтобы действительно придать импульс. Ваш вопрос о статистике. >> Я думаю, это очень захватывающе, честно говоря. Я мало что об этом знаю, потому что, знаете ли, я просто представляю, что это компания, которую многие, это инструмент, которым пользуются многие люди, и, возможно, так получилось, что OpenAI приобрела их. Я уверен, что они использовали их в прошлом. >> Я уверен, что конкуренты OpenAI >> также используют Stat Sig. >> Так что, возможно, в этом приобретении есть что-то стратегическое. Я понятия не имею. Я ничего там не знаю. Но я думаю, что это действительно более важные вопросы для меня, чем, знаете ли, принципиально ли это меняет A/B-тестирование или делает оценки более приоритетными. Я думаю, что они всегда были приоритетом. Я думаю, что OpenAI всегда занималась чем-то подобным, и OpenAI исторически зашла так далеко, что, например, просматривала все настроения в Твиттере и пыталась провести своего рода ретроспективу, а затем связать это со своими продуктами. Так что, безусловно, они проводят некоторое количество оценок перед выпуском своих новых базовых моделей, но они идут гораздо дальше и говорят: «Хорошо, давайте найдем все твиты, которые жалуются на это, все ветки Reddit, которые жалуются на это, чтобы попытаться понять, что происходит». Так что это показывает, что оценки очень, очень важны. Никто еще не разобрался. Люди используют все доступные источники сигналов, которые они могут, чтобы улучшить свои продукты. Что я скажу, так это то, что я очень надеюсь, что это может сместить наш творческий фокус в OpenAI. Надеюсь, до сих пор многие крупные лаборатории, по понятным причинам, сосредоточились на общих бенчмарках, таких как оценка MMLU, человеческая оценка, которые очень важны для базовых моделей, и знаете ли, те, которые не очень связаны с оценками, специфичными для продукта, такими как те, о которых мы говорили сегодня, но, например, передача и тому подобное, знаете ли, они, как правило, не коррелируют. >> Да, они не коррелируют с решением математических задач, к сожалению. >> Точно. И поэтому, знаете ли, если вы посмотрите на продукты оценки, скажем, те, которые до недавнего времени были у некоторых крупных лабораторий, у них нет анализа ошибок. У них есть общий набор общих инструментов, косинусное сходство, оценка галлюцинаций, что угодно, и это не работает. Это хорошая первая попытка. Это нормально. Знаете ли, по крайней мере, вы что-то делаете, заставляя людей, возможно, это как бы заставляя людей смотреть на данные, но в конечном итоге, на что мы надеемся увидеть, это, хорошо, немного больше мышления в области науки о данных в этом процессе оценки. Надеюсь, инструменты, которые мы получим >> Хамил и я не должны быть единственными двумя людьми на планете, которые продвигают структурированный способ мышления о оценках, специфичных для приложений. >> Мне это просто поражает. Почему мы единственные два человека, которые это делают? Весь мир, что не так? Я надеюсь, что мы не единственные, и что больше людей присоединятся. >> Ну, тот факт, что ваш курс на Maven является самым прибыльным курсом на Maven, явно есть спрос и интерес, и больше людей, я думаю, на вашей стороне. Интересно, просто пример, который вы делились в Твиттере, который, я думаю, информативен. Все говорили, что Claude Code не заботится об оценках. Они все о настроениях, и все такие: «Что?» И они лучший кодирующий агент. Так что, очевидно, это правильно. Совсем недавно все говорили о codecs, OpenAI codecs лучше, и все переключаются, и они так сильно поддерживают оценки. >> Я знаю. >> Что? Да. Так что >> это меня каждый раз. Интернет настолько непоследователен. Мое любимое было, как вчера, я думаю, пара моих коллег по лаборатории и я вышли за десертом или чем-то еще, и кто-то сказал: «О, тебе больше нравится Codex или Claude, или что-то еще?» И другой человек сказал: «О, мне нравится Claude». А затем кто-то еще сказал: «Но новая версия Codex лучше». А затем первый человек сказал: «О, но в последний раз, когда я проверял, было два дня назад, так что, возможно, мои мысли, возможно, я не в курсе». И я такой: «О боже, >> это так верно. >> Это мир, в котором мы живем». О боже. >> Хорошо, я хочу спросить о просто главных заблуждениях, которые есть у людей с оценками, и главных советах и хитростях для успеха. Так что, может быть, просто поделитесь по одному или два из каждого. Итак, позвольте мне просто начать с заблуждений, и, возможно, я перейду к Хамилу первым. Просто какие несколько самых распространенных заблуждений, которые люди до сих пор имеют с оценками? Первое — это: «Эй, я могу просто купить инструмент, подключить его, и он сделает оценку за вас». Зачем мне об этом беспокоиться? Мы живем в эпоху ИИ. Разве ИИ не может просто оценить это? Это самое распространенное заблуждение. И люди так сильно этого хотят, что люди продают это, но это не работает. Так что это первое. Черт, нам все еще нужны люди. Отлично. Я думаю, это отличная новость. >> Второе, которое я вижу много, это: «Эй, просто не смотрите на данные». Так что в моем консалтинге люди приходят ко мне с проблемами все время, и первое, что я скажу, это: «Давайте посмотрим на ваши трассировки», и вы можете увидеть, как их глаза распахиваются: «Что вы имеете в виду? Да, давайте посмотрим на это прямо сейчас», и они удивляются, что я собираюсь посмотреть на отдельные трассировки. И мы всегда, 100% времени, многому учимся и выясняем, в чем проблема. И поэтому, я думаю, люди просто не знают, насколько мощным является просмотр данных, как мы показали на этом подкасте. >> Я бы согласился с этим. >> Это два главных. Хорошо. Есть ли что-нибудь еще, или это те, которые решают эти проблемы? >> О, это определенно. И тогда, я думаю, я бы добавил, что нет единственного правильного способа проводить оценки. Есть много неправильных способов проводить оценки, но есть и много правильных способов сделать это. И вам придется подумать о том, где вы находитесь со своим продуктом, сколько у вас ресурсов, и придумать план, который лучше всего подходит для вас. Он всегда будет включать некоторую форму анализа ошибок, как мы показали сегодня, но то, как вы операционализируете эти метрики, будет меняться в зависимости от того, где вы находитесь. >> Потрясающе. Хорошо. Какие есть пара советов и хитростей, которые вы хотите оставить людям, когда они начинают свой путь оценки или просто пытаются стать лучше в том, что они уже делают? >> Итак, совет номер один: просто не пугайтесь и не пугайтесь смотреть на свои данные. Процесс, мы стараемся сделать его максимально структурированным. Неизбежно возникнут вопросы. Это совершенно нормально. Вы можете чувствовать, что делаете это не идеально. Это тоже нормально. Цель — не делать оценки идеально. Цель — действенно улучшать ваш продукт. И мы гарантируем вам, независимо от того, что

Вы делаете, вы выполняете части этих процессов. Вы найдете способы действенного улучшения. И затем вы будете итерировать свой собственный процесс оттуда. Другой совет, который я бы дал, это то, что мы очень поддерживаем ИИ. Используйте LLM, чтобы помочь вам организовать любые мысли, которые у вас возникают на протяжении всего этого процесса. Так, это может быть все, начиная от первоначальных требований к продукту, верно? Разберитесь, как их организовать для себя, разберитесь, как улучшить этот документ с требованиями к продукту на основе открытых кодов, которые вы создали, верно? Не бойтесь использовать ИИ способами, которые, как вы знаете, лучше представляют информацию для вас. >> Отлично. Так что не бойтесь. Используйте LLM как можно больше на протяжении всего процесса, >> но не для того, чтобы заменить себя. >> Верно. Хорошо. Отлично. Работа есть. Отлично. Привет. >> Да, позвольте мне фактически поделиться своим экраном. Итак, когда я что-то показываю, >> чтобы развить то, что сказала Трея: если вы слышали какую-либо фразу в этом подкасте, вы, вероятно, слышали "смотрите на свои данные больше всего". И поэтому очень важно, чтобы мы учили, что вы должны создавать свои собственные инструменты, чтобы сделать это как можно проще. Итак, я показал вам некоторые инструменты, когда мы проходили живой пример того, как аннотировать данные. Большинство людей, с которыми я работаю, понимают, насколько это важно, и они сами пишут код для своих инструментов, или мы не должны говорить "пишут код". Они просто создают свои собственные инструменты, и это дешевле, чем когда-либо прежде, потому что у вас есть ИИ, который может помочь вам, а ИИ очень хорошо создает простые веб-приложения, которые могут показывать вам данные, которые имеют, вы знаете, которые могут записывать в базу данных. Это очень просто. И поэтому для варианта использования "nurture boss" мы хотели устранить все препятствия при просмотре данных. И поэтому то, что вы видите здесь, это просто несколько скриншотов того, как выглядит приложение, которое они создали. Это просто хорошо. У них есть разные каналы: голос, электронная почта, текст. У них есть разные ветки. Они скрыли системный промпт по умолчанию. Небольшие улучшения качества жизни. А затем у них была эта часть аксиального кодирования, где вы можете видеть, хорошо, красным цветом количество различных ошибок. Они автоматизировали эту часть красивым способом, и они просто создали это за несколько часов. И поэтому очень трудно иметь универсальное решение для просмотра ваших данных. Вам не обязательно идти сюда немедленно, но стоит подумать о том, чтобы сделать это как можно проще, потому что, опять же, это самая мощная деятельность, в которой вы можете участвовать. Это деятельность с самой высокой рентабельностью инвестиций, в которой вы можете участвовать. И поэтому, вы знаете, с ИИ, да, просто устраните все препятствия. Это потрясающе. И опять же, я думаю, что аспект рентабельности инвестиций настолько важен. Мы даже не коснулись этого достаточно. Цель здесь — сделать ваш продукт лучше, что сделает ваш бизнес более успешным. Это не просто небольшое упражнение, чтобы поймать ошибки и тому подобное. Это способ сделать ИИ-продукты лучше, потому что опыт — это то, как пользователи взаимодействуют с вашим ИИ. Абсолютно. Если что-нибудь, вы знаете, мы учим наших студентов: эй, когда вы делаете эти оценки, если вы видите что-то неправильное, просто исправьте это. Вся суть не в том, чтобы иметь набор оценок, на который вы можете указать, отредактировать и сказать: "О, посмотрите на мои оценки". Нет, просто исправьте свое приложение, сделайте его лучше. Сделайте это, если это очевидно. Так что полностью согласен с вами. Потрясающе, как долго я задаю вопрос, но я думаю, что это то, о чем думают люди: сколько времени вы на это тратите? Сколько времени обычно занимает это в первый раз? >> Я могу ответить за себя. Для приложений, над которыми я работаю, обычно я трачу три-четыре дня, действительно работая с кем-либо, чтобы провести первоначальные раунды анализа ошибок, много маркировки, чувствую, что мы в хорошем положении, чтобы создать таблицу, которую имел Хамил, и все в целом согласны и убеждены, и даже несколько оценщиков-судей LLM. Но это единовременные затраты. Как только я понял, как интегрировать это в модульные тесты, или у меня есть скрипт, который автоматически запускает его на образцах, и я создам задание cron, чтобы просто делать это каждую неделю. Я бы сказал, что я не знаю, я, вероятно, трачу больше времени на просмотр данных, потому что я просто жажду данных, я так любопытен. Я получил так много от этого процесса, и это вывело меня за рамки любых моих сотрудничеств с людьми. Поэтому я хочу продолжать это делать, но мне не обязательно. Я бы сказал, что, возможно, 30 минут в неделю после этого. >> Итак, это неделя, по сути, неделя изначально, а затем около 30 минут, чтобы продолжать улучшать и добавлять к своему набору. >> Да, это действительно не так много времени. Я думаю, люди просто перегружены тем, сколько времени они тратят изначально, а затем думают, что им придется продолжать делать это все время. >> Потрясающе. Есть ли что-нибудь еще, чем вы хотели бы поделиться или оставить слушателям? Есть ли что-нибудь еще, на чем вы хотели бы остановиться, прежде чем мы перейдем к нашему очень захватывающему молниеносному раунду? Итак, я бы сказал, что этот процесс на самом деле очень веселый. Так что это может быть так: хорошо, вы смотрите на данные. О, звучит так, будто вы аннотируете вещи. Хорошо, на самом деле, я вчера смотрел данные клиента. Точно такой же процесс. Это приложение, которое отправляет электронные письма, рекрутинговые письма, чтобы попытаться привлечь кандидатов для подачи заявки на работу. И мы решили начать смотреть на трассировки. Прямо погрузиться. Эй, давайте посмотрим на ваши трассировки. Мы посмотрели на трассировку. Первое, что я увидел, это такое электронное письмо, которое сформулировано как "учитывая ваш опыт, бла-бла-бла-бла-бла". Поэтому я сразу же спросил человека, и вот где нужно надеть шляпу продукта и просто быть критичным, и вот где веселье. Я сказал: "Знаете что, я ненавижу это письмо". Вам нравится письмо "учитывая ваш опыт", когда, когда я получаю сообщение "учитывая ваш опыт", я просто удаляю его. Так что я думаю: что это такое, "учитывая ваш опыт в области машинного обучения и бла-бла-бла"? Это что-то общее. Так что я спросил человека: "Эй, вы знаете, можем ли мы сделать лучше, чем это? Это похоже на общее рекрутирование", и они сказали: "О, да, может быть, да". Это ИИ, потому что они были горды этим. ИИ делает правильные вещи, отправляет это письмо с правильной информацией, с правильной ссылкой, с правильным именем, всем. И вот где веселье: наденьте свою шляпу продукта и спросите: "Действительно ли это хорошо? Хочу ли я это сделать?" Я хочу убедиться, что мы охватим это, прежде чем перейдем к очень захватывающему молниеносному раунду. Это только верхушка айсберга всего, что вам нужно знать, чтобы делать это хорошо. Я думаю, это лучший вводный курс, который я когда-либо видел, как это делать хорошо. Приятно. >> Но вы, я думаю, мы справились. Но вы преподаете курс, который идет гораздо глубже для людей, которые действительно хотят стать хорошими в этом и относиться к этому очень серьезно. Расскажите, что еще вы преподаете на курсе, что мы не охватили, и что еще вы получаете как студент, будучи частью курса, который вы преподаете в Maven. >> Да, я могу немного рассказать о программе, а затем Хамил может рассказать обо всех преимуществах. >> Итак, мы проходим жизненный цикл анализа ошибок, затем автоматизированные оценщики, затем как улучшить ваше приложение, как создать этот маховик для себя. У нас также есть несколько специальных тем, которые, как мы находим, почти никто никогда не слышал или не преподавал раньше, что волнующе. Одна из них — как создавать свои собственные интерфейсы для анализа ошибок. Так что мы проходим реальные интерфейсы, которые мы создали, и мы также кодируем их в прямом эфире на месте для новых данных. И мы показываем, как мы используем cloud code cursor или что бы мы ни чувствовали в данный момент, чтобы создавать эти интерфейсы. И мы также говорим о, в целом, оптимизации затрат. Так что у нас есть несколько человек, с которыми я работал, они достигли точки, когда их оценки очень хороши, их продукт очень хорош, но все это очень дорого, потому что они используют передовые модели. Так как же мы можем заменить некоторые виды использования самых дорогих моделей GPT5 на, скажем, 5 nano, 4 mini и тому подобное, и сэкономить много денег, но при этом сохранить то же качество. Так что мы даем несколько советов и по этому поводу. >> Хамил, ты хочешь? У нас также есть много преимуществ. >> Да. Расскажи о преимуществах. >> Хорошо. Преимущества. >> Так, мой любимый бонус — это книга на 60 страниц, тщательно написанная, которую мы создали, которая подробно описывает весь процесс оценки. Так что вам не нужно сидеть и делать все эти заметки. Мы сделали всю тяжелую работу за вас, и мы подробно документировали ее. Вы знаете, и организовали вещи. Так что это очень полезно. Еще одна очень интересная вещь, и что-то, что я взял у тебя, Ленни: хорошо, это курс по ИИ. Образование не должно быть такой вещью, где вы только смотрите лекции и выполняете домашние задания. Так что студенты должны иметь доступ к ИИ, который также им помогает. Так что мы сделали, вы знаете, так же, как есть Lennybot, который у вас есть >> да, lennybot.com, мы сделали то же самое с тем же программным обеспечением, которое вы используете, и мы поместили туда все, что мы когда-либо говорили об оценках. Так что каждый урок, каждый офис-час, каждый чат в Discord, любые блоги, статьи, все, что мы когда-либо говорили публично и в нашем курсе, мы поместили туда, и мы протестировали это с кучей студентов, и они сказали, что это полезно. Так что мы даем всем студентам 10 месяцев бесплатного неограниченного доступа к этому наряду с курсом. >> Потрясающе. А потом вы будете брать за это плату позже, такова идея. Я беру по одному месяцу за раз. Я не знаю, что мы делаем. >> Восемь месяцев, а потом нам придется разобраться. Я думал, что все это интервью должно было быть просто нашими ботами, разговаривающими друг с другом. >> Это потрясающе. Я бы посмотрел это только минут 10, потом я не знаю, о чем они говорят. >> Да, может быть, 30 секунд. Вы обучили его голосовому режиму, кстати? Это моя любимая функция продукта Deli. Если нет, вам следует это сделать. >> О, >> Я не помню. >> Я должен посмотреть. Определенно уверен. Теперь, когда у нас есть этот эпизод подкаста, вы можете использовать этот контент для обучения. Он работает на 11 языках, он так хорош. >> Хорошо. Так вот как они туда попадают, я полагаю, это хорошо. Они попадают туда, когда становятся >> зарегистрируйтесь на курс, а затем вы получите кучу электронных писем. Все будет понятно, надеюсь. >> Потрясающе. Хорошо. У нас также есть Discord >> всех студентов, которые когда-либо проходили курс, и этот Discord настолько активен. >> Я не могу уехать в отпуск, не получив уведомление в самолете или >> горько-сладко, горько-сладко. Невероятно. Хорошо. С этим мы достигли нашего очень захватывающего молниеносного раунда. У меня есть пять вопросов для вас. Вы готовы? >> Да. Поехали. >> Давайте сделаем это. Хорошо. Итак, я буду переключаться между вами двумя. Поделитесь чем-нибудь, если хотите. Вы можете пропустить, если хотите. Первый вопрос. Шрея. Какие две или три книги вы чаще всего рекомендуете другим? >> Итак, я люблю рекомендовать художественную книгу, потому что жизнь — это больше, чем оценки. Так что недавно я прочитала "Паченко" Нинджан Ли, очень хорошая книга, а затем я также читаю "Яблоко в Китае", имя автора ускользает от меня, но это скорее экспозиция, написанная журналистом о том, как Apple занималась производственными процессами в Азии за последние несколько десятилетий. Очень познавательно. >> Потрясающе. Хамил. >> Да, у меня они здесь. Итак, я ботаник. Хорошо, я не такой крутой, как Ра. Так что у меня на самом деле есть учебники, которые мне нравятся. Так что это очень классический учебник. "Машинное обучение" Митчелла. Сейчас он несколько теоретический, но мне нравится то, что он действительно подчеркивает тот факт, что бритва Оккама присутствует не только в науке, но и в машинном обучении и ИИ. Так что часто самый простой подход обобщается лучше. И это то, что я глубоко усвоил из этой книги. И мне также очень нравится эта. Еще один учебник. Я сказал вам, что я ботаник. Это тоже очень старый. >> Вау. >> И это, знаете ли, алгоритмы Норманна, и это просто, мне это очень нравится, потому что это просто человеческая изобретательность, и это очень, много умных полезных вещей. >> Они по соседству. >> Вычисления. >> Я в Беркли. >> Люди, которые проводили это исследование. >> Да. >> Да. Авторы учебников. >> Очень круто. О, черт возьми, ботаники. Я люблю это. Хорошо, следующий вопрос. Любимый недавний фильм или телешоу? Я начну с Хамила. Хорошо. Итак, я отец двоих детей. У меня двое родителей. >> У меня нет Ой, извините. >> Двое детей. Так что да, я отец двоих детей, и у меня действительно нет времени смотреть телевизор или фильмы. Так что я смотрю то, что смотрят мои дети. Так что я смотрел "Холодное сердце" три раза за последнюю неделю. >> Только три? О, хорошо. За последнюю неделю. Хорошо. Да. Так что это >> "Холодное сердце". Я люблю это. Хорошо. Шрея. >> Да. >> У меня нет детей, так что я могу дать все эти потрясающие ответы. Так что мой муж и я недавно смотрели "Прослушку". Мы никогда не смотрели ее, когда росли. Так что мы начали смотреть, и это здорово. >> Я думаю, все в конечном итоге проходят через это в своей жизни. Они решают: "Я посмотрю "Прослушку"". >> Я знаю. Так что мы в этом >> году вашей жизни. Я Это отличное шоу. О, черт возьми. И но это так много серий, и каждая длится час. >> Я знаю. Мы смотрим две или три в неделю. Так что >> так что мы очень медленные. >> Стоит того. Хорошо, следующий вопрос. У вас есть любимый продукт, который вы недавно обнаружили и который вам очень нравится? И мы начнем со Шреи. >> Да, мне очень нравится использовать Cursor. Честно говоря, теперь Cloud Code. >> Я скажу почему. Так что я думаю, как исследователь, больше всего остального. Я пишу статьи, я пишу код, я создаю системы, все. И я считаю, что инструмент, я так уверен в программировании с помощью ИИ, потому что мне приходится носить много шляп все время. И теперь я могу быть более амбициозным в том, что я строю и пишу статьи. Так что я очень рад этому. Cursor был моей отправной точкой в этом. Но я начинаю обнаруживать, что всегда пытаюсь не отставать от всех этих инструментов для программирования с помощью ИИ. >> Хамил. Да, мне очень нравится Cloud Code, и он мне нравится, потому что я чувствую, что UX выдающийся. В него вложено много любви. Это просто очень впечатляет как терминальное приложение, которое так приятно. >> Иронично, что вы оба любите Cloud Code, когда он построен только на вибрациях. >> Я думаю, это ложь. Это не просто построено на вибрациях. >> Вот так. Хорошо, еще два вопроса. >> Хамил, у вас есть любимый жизненный девиз, который вы используете и к которому возвращаетесь в работе или в жизни? >> Продолжайте учиться и думайте как новичок. >> Прекрасно. Шрея. >> Мне это нравится. >> Для меня это всегда стараться думать об аргументе другой стороны. Я иногда встречаю аргументы в интернете, такие как недавние дебаты по оценкам, и действительно думаю: "Хорошо, поставьте себя на их место". Вероятно, есть щедрый взгляд, щедрая интерпретация, и я думаю, что мы все намного сильнее вместе, чем если мы начнем ссориться. Мое видение оценок не в том, чтобы Хамил и я стали миллиардерами. Это в том, чтобы каждый мог создавать ИИ-продукты, и мы все были на одной волне. >> / Все станут миллиардерами. >> Да. >> Да. >> Потрясающе. Последний вопрос. Когда у меня два гостя, я всегда люблю задавать этот вопрос, и я начну с Хамила. Что вам больше всего нравится в Шрее? Что вам больше всего нравится в Шрее? И я задам ей тот же вопрос в обратном порядке. Да, Шрея — один из самых мудрых людей, которых я знаю, >> особенно для своего возраста по сравнению со мной. Я чувствую, что она намного мудрее меня, честно говоря. Серьезно. Она очень приземленная и имеет очень ровную перспективу на вещи. И поэтому я всегда очень впечатлен этим. >> Шрея. >> Да. >> Да. Мое любимое в Хамиле — это его энергия. Я не знаю никого, кто бы последовательно поддерживал такой же темп и энергию, как Хамил. Я часто думаю, что я бы гораздо меньше заботился об оценках, если бы не Хамил. И каждому нужен Хамил в своей жизни, безусловно. М. О, ну, у нас у всех теперь есть Хамил в нашей жизни. Это было невероятно. Это было все, на что я надеялся. Я чувствую, что это самый интересный, глубокий, усваиваемый вводный курс по оценкам, который я когда-либо видел. Я очень благодарен, что вы уделили время этому. >> Два финальных вопроса. Где вас можно найти? Где можно найти курс? И как слушатели могут быть полезны вам? >> Я начну со Шреи. >> Да. >> Вы можете связаться со мной по электронной почте. Это на моем сайте. Если вы поищете мое имя в Google, это самый простой способ попасть на мой сайт. Вы можете найти курс. Если вы поищете "AI evals for engineers and product managers" или просто "AI evals course", вы найдете его. >> Мы отправим несколько ссылок, надеюсь, после этого, так что это будет легко. И как быть полезным. Две вещи всегда для меня. Одна — задавайте мне вопросы, когда они у вас есть. Я постараюсь ответить на них. Отвечу как можно скорее. Другое — рассказывайте о своих успехах. Одна из вещей, которая поддерживает нас, — это когда кто-то рассказывает нам, что они внедрили или что они сделали, реальный пример, и Хамил и я так радуемся этому, и это действительно поддерживает нас. Так что, пожалуйста, поделитесь. >> Да. >> Меня довольно легко найти. Мой сайт hamill.dev. Я дам вам ссылку. >> Вы можете найти меня в социальных сетях, LinkedIn, Twitter. >> То, что наиболее полезно, — это повторить то, что сказала Шрея: мы будем в восторге, если мы не единственные, кто преподает оценки. Мы хотели бы, чтобы другие люди преподавали оценки. И поэтому любые блоги, статьи, особенно те, которые вы пишете, когда проходите через это и учитесь этому, которыми вы хотите поделиться, мы будем рады помочь перепостить или усилить. >> Потрясающе. Очень щедро. Большое спасибо, что пришли. >> Я очень ценю это, и у вас много дел. Так что, так что спасибо. >> Спасибо, Ленни, что пригласили нас и за все комплименты. >> С удовольствием. До свидания всем. >> Большое спасибо за прослушивание. Если вы нашли это ценным, вы можете подписаться на шоу на Apple Podcasts, Spotify или вашем любимом подкаст-приложении. Также, пожалуйста, рассмотрите возможность поставить нам оценку или оставить отзыв, так как это действительно помогает другим слушателям найти подкаст. Вы можете найти все прошлые эпизоды или узнать больше о шоу на lennispodcast.com. Увидимся в следующем эпизоде.

Get Our Mobile App

Why AI evals are the hottest new skill for product builders | Hamel Husain & Shreya Shankar

Transcription