Transcription
[Музыка] Добро пожаловать в Lenny's Reads, где я представляю вам аудиоверсии моей рассылки о создании продуктов, стимулировании роста и ускорении вашей карьеры. Онлайн-курс Хамла Хуссейна и Шреи Шанкар "AI evals для инженеров и PM" является самым прибыльным курсом на Maven и постоянно привлекает значительные группы студентов из всех ведущих AI-лабораторий. Это потому, что они учат чему-то важному: как создавать оценки, которые действительно улучшают ваш продукт, а не просто генерируют красивые, но бесполезные панели мониторинга. За последние 2 года Хамил и Шрея сыграли важную роль в превращении оценок из малопонятной, запутанной темы в один из самых необходимых навыков для создателей AI-продуктов. Обучив более 2000 менеджеров по продукту, инженеров и руководителей в более чем 500 компаниях, они теперь делятся своим полным руководством, которое включает ту же методологию, что преподается в OpenAI, Anthropic и других ведущих лабораториях. Вы узнаете, как использовать анализ ошибок для понимания того, где ваш AI-продукт дает сбой, как создавать надежные оценки, которым можно доверять, и как создать маховик непрерывного улучшения, который улавливает регрессии до их выпуска. В оставшейся части этого эпизода я буду читать пост, написанный Хамилом и Шреей. Спасибо вам обоим за то, что поделились этим золотом с нами. Давайте начнем. [Музыка] Предыдущий пост, написанный Аманом Ханом об оценках, на который мы дадим ссылку в описании к эпизоду, прекрасно отражает, почему оценка становится ключевым навыком для менеджеров по продукту, определяющим успех или провал. Этот эпизод охватывает следующий шаг, который представляет собой руководство по созданию системы оценки для достижения реальных улучшений продукта. Многие команды создают панели мониторинга оценок, которые выглядят полезными, но в конечном итоге игнорируются и не приводят к лучшим продуктам, потому что метрики, которые сообщают эти оценки, оторваны от реальных проблем пользователей. Это руководство предоставляет процесс для преодоления этого разрыва доверия. Мы рассмотрим три этапа. Определение того, что измерять, посредством тщательного анализа ошибок, создание надежного набора оценок и операционализация этого набора для создания маховика непрерывного улучшения. Первый этап объясняет, как заземлить ваши оценки в реальности, используя анализ ошибок. Прежде чем вы сможете улучшить свой AI-продукт, вы должны понять, как он терпит неудачу. Поверхность того, что вы могли бы оценить, бесконечна. Самая распространенная ошибка — начать с измерения готовых модных метрик, таких как галлюцинации или токсичность. Такой подход часто приводит к отслеживанию показателей, которые не коррелируют с фактическими проблемами, с которыми сталкиваются ваши пользователи при использовании вашего продукта. Вы не можете знать, что измерять, пока систематически не выясните, как ваш продукт терпит неудачу в конкретных контекстах. Процесс, который говорит вам, на чем сосредоточиться, называется анализом ошибок и должен привести к четкому и приоритезированному списку наиболее распространенных сценариев сбоев вашего продукта. Процесс начинается не с метрик, а с данных и одного человека-эксперта. Для большинства малых и средних компаний наиболее эффективным подходом является назначение одного главного эксперта в предметной области в качестве арбитра качества. Этот человек может быть психологом для чат-бота по психическому здоровью или юристом для анализа юридических документов, и он становится окончательным голосом по качеству. Назначение одного эксперта, иногда называемого доброжелательным диктатором, обеспечивает последовательный и глубоко информированный сигнал, который устраняет конфликты аннотаций и предотвращает паралич, который может возникнуть из-за слишком большого количества поваров на кухне. Во многих ситуациях менеджер по продукту является главным экспертом в предметной области. Более крупные организации или продукты, охватывающие несколько сложных областей с различными культурными контекстами, могут потребовать нескольких аннотаторов. В этих случаях вы должны внедрить более структурированный процесс, чтобы обеспечить согласованность суждений, что включает измерение их согласия. Ваш следующий шаг — вооружить этого эксперта репрезентативным набором примерно из 100 пользовательских взаимодействий. По мере того, как вы становитесь более изощренными, вы можете выбирать взаимодействия, которые с большей вероятностью дадут ценную информацию на основе анализа данных. Примеры включают трассировки с отрицательной обратной связью от пользователей, выбросы по длине разговора, количество инструментов и высокую задержку. Однако начните со случайной выборки, чтобы развить свою интуицию в начале. Имея готовый набор данных, анализ начинается с открытого кодирования. Это, по сути, похоже на ведение дневника, но с некоторой структурой. Эксперт в предметной области просматривает каждое взаимодействие пользователя и пишет свободную критику всего, что кажется неправильным или нежелательным, а также дает оценку "пройдено" или "не пройдено" производительности AI. Для пройденных случаев мы объясняем, почему AI успешно удовлетворил основную потребность пользователя, даже если были критические аспекты, которые можно было бы улучшить. Мы выделяем эти области для улучшения, оправдывая общую положительную оценку. Для неудач мы определяем критические элементы, которые привели к неудаче, объясняя, почему AI не достиг основной цели пользователя или поставил под угрозу важные факторы, такие как пользовательский опыт или безопасность. Письменная версия этого эпизода включает снимок экрана AI-галлюцинации для помощника по аренде квартир, ссылка на который находится в описании к эпизоду. В качестве эвристики, критика должна быть достаточно подробной, чтобы новый сотрудник вашей компании мог ее понять, или, если это более полезно, чтобы вы могли использовать ее в подсказке с несколькими примерами для LLM-судьи. Чрезмерная краткость — распространенная ошибка. Вот несколько хороших примеров открытого кодирования в действии с использованием примера помощника по аренде квартир. Вот первый. Запрос пользователя к AI: "Мой друг хочет перенести наш тур по адресу 123 Main Street с субботы на воскресенье в 14:00. Возможно ли это?" Ответ AI: "Я подтвердил, что 14:00 в воскресенье доступно. Я обновил запись." Это результат "пройдено", потому что AI успешно обработал запрос на перенос, проверив новый календарь и подтвердив новое время, достигнув основной цели пользователя. Вот второй пример. Запрос пользователя: "Есть ли двухкомнатные квартиры с балконом?" Ответ AI: "Да, у нас есть прекрасная двухкомнатная квартира на верхнем этаже с большим балконом и видом на город." Опять же, это еще одно "пройдено". AI правильно ответил на вопрос пользователя, предоставив точный и привлекательный ответ на основе доступных предложений. Давайте попробуем еще один пример. На этот раз запрос пользователя: "Мне нужно поговорить с менеджером прямо сейчас." AI отвечает так: "Я понимаю, что вы расстроены. Не могли бы вы рассказать мне больше о проблеме, чтобы я мог попытаться помочь?" Это "не пройдено", потому что AI не распознал явный запрос на передачу человеку. Вместо эскалации он остался в цикле решения проблем, что в данном контексте является плохим пользовательским опытом. Вот четвертый пример. Пользователь запрашивает: "Я хотел бы посмотреть однокомнатную квартиру завтра." И AI отвечает: "Я вижу два доступных слота на завтра: 11:00 и 15:00. Однако агент отметил, что с сантехникой в этой квартире могут быть проблемы." Это пример еще одного "не пройдено". AI правильно получил доступное время, но предложил квартиру с известной проблемой, не спросив сначала, заинтересован ли пользователь. Это показывает плохой поток разговора и неспособность предвидеть потребности пользователя, поскольку он предоставил непривлекательный вариант без уточнений. Это "не пройдено". Обратите внимание, что эти вышеупомянутые примеры пользовательских взаимодействий с AI упрощены для краткости. Вам может потребоваться предоставить эксперту в предметной области больше контекста для принятия решения. Мы рассмотрим это позже. Этот слегка ограниченный процесс имеет решающее значение для обнаружения проблем, о которых вы не знали. Именно здесь команды часто обнаруживают, чего они действительно хотят от своей AI-системы. Исследования показывают, что люди не очень хорошо формулируют свои полные требования к AI заранее. Именно в процессе рассмотрения результатов и формулирования того, что кажется неправильным, возникают истинные критерии успеха. После сбора заметок по десяткам трассировок следующим шагом является осевое кодирование или поиск закономерностей. На этом этапе эксперт просматривает все открытые критические замечания и начинает группировать их. Этот процесс превращает хаотичный список наблюдений в четкую, приоритезированную таксономию конкретных сценариев сбоев. Это отчасти искусство, отчасти наука — группировать ошибки таким образом, чтобы это было управляемо и осмысленно для вашей предметной области. Давайте пройдемся по тем же сбоям, что и выше, и посмотрим, как вы можете применить осевое кодирование. В первом примере сбоя, когда пользователь хочет поговорить с менеджером, а AI не распознал этот явный запрос, мы бы классифицировали этот сбой как ошибку передачи. Во втором примере сбоя, когда пользователь хочет посмотреть однокомнатную квартиру завтра, а AI предлагает квартиру с известной проблемой, мы бы классифицировали это как ошибку "сначала квалифицировать проблемы". Этот процесс группировки часто происходит в электронной таблице или специализированном инструменте аннотации, где вы можете помечать или маркировать каждую критику. Когда я работал над этим помощником по аренде квартир в реальной ситуации, возникли три ключевые категории. Первая — проблемы с потоком разговора, когда AI упускал контекст или давал неловкие ответы. Вторая категория — сбои передачи, когда AI не распознавал, когда нужно передать управление человеку. И третья категория — проблемы с переносом, когда AI испытывал трудности с обработкой дат. Вы можете ускорить этот процесс категоризации с помощью LLM. Вы можете использовать LLM для выполнения первого прохода категоризации критики. Однако распространенная ловушка — это чрезмерная автоматизация. Убедитесь, что эксперт всегда проверяет и подтверждает предложения LLM. LLM может упустить нюанс, который отличает проблему потока разговора от сбоя передачи. Другая ловушка — создание слишком большого количества категорий. Стремитесь к управляемому набору из менее чем 10 основных сценариев сбоев, которые охватывают наиболее значимые проблемы. Цель — создать полезную таксономию, которую вы можете анализировать, а не исчерпывающий список. Конечным результатом этого этапа является просто подсчет категорий, чтобы вы могли получить представление о том, куда инвестировать свое время. Когда я рассчитал количество для помощника по аренде квартир, наиболее часто встречающимися ошибками были проблемы с потоком разговора (110 ошибок), передача человеку (70 ошибок) и затем перенос (60 ошибок). Эти данные дают нам конкретные проблемы, специфичные для нашего продукта, на которых мы можем сосредоточиться при создании оценок. Прежде чем перейти ко второму этапу, я хочу поделиться предупреждением о готовых метриках. Хотя готовые метрики, такие как галлюцинации и токсичность, не стоят прямого внимания, их можно использовать творчески. Вместо того чтобы сообщать о показателе галлюцинаций или токсичности на панели мониторинга, рассчитайте показатели для ваших трассировок и отсортируйте их по высоким или низким показателям. Просмотр примеров с самыми высокими и самыми низкими показателями может выявить неожиданные сценарии сбоев или неожиданные успехи, которые, в свою очередь, помогут вам создать пользовательские оценщики для обнаруженных закономерностей. Это одно из немногих допустимых применений готовых метрик. Обратите внимание, что это продвинутая техника, и ее следует применять только после того, как вы освоите базовый подход. Перейдем ко второму этапу — созданию вашего набора оценок. После анализа ошибок у вас будет приоритезированный список наиболее распространенных сбоев вашего продукта. Следующий шаг — создать набор автоматизированных оценщиков для их отслеживания. Цель — создать систему, которая будет надежной, экономически эффективной и пользующейся доверием вашей команды. Это требует выбора правильного инструмента для каждого сценария сбоя. Ваш выбор инструментов сводится к одному вопросу для каждого приоритезированного сценария сбоя в вашем списке. Является ли этот сбой объективным и основанным на правилах? Например, содержит ли вывод идентификатор пользователя, или сбой субъективен и требует суждения? Например, был ли тон уместен для персонажа? Для объективных сбоев используйте оценщики на основе кода. Это простые проверки, написанные в виде кода, как утверждения в модульном тесте. Они быстрые, дешевые и детерминированные, что делает их идеальными для проверки таких вещей, как является ли вывод допустимым JSON, содержит ли он требуемое ключевое слово или выполняется ли он без ошибок. Используйте их везде, где четкое правило может определить успех или неудачу. Для субъективных сбоев вам потребуется создать LLM в качестве судьи для надежной оценки качеств, которые код не может легко обработать, таких как тон, релевантность или качество рассуждений. Это может быть строгий процесс, как и обучение любого LLM, но это единственный способ масштабировать тонкие и субъективные оценки и в конечном итоге улучшить ваш продукт. Хорошая новость в том, что существует научный подход к обеспечению того, чтобы судья был достаточно согласован с вашим видением продукта и критериями успеха. Вот руководство по LLM в качестве судьи. Речь идет не о написании умной подсказки. Речь идет о систематическом процессе заземления суждений LLM в вашем конкретном стандарте качества. Результатом является LLM, которая дает вам бинарную метрику "пройдено" или "не пройдено" для конкретных ошибок. Что еще более важно, вам нужно доверять этой метрике. Способ установить доверие — это измерить судью на основе размеченного человеком набора данных, который вы создаете. Существует два этапа. Первый — создать набор данных, который устанавливает истинное положение дел. Ваша система оценки хороша настолько, насколько хорош ее источник истины. Для большинства команд наиболее эффективным подходом является использование главного эксперта в предметной области, упомянутого ранее. В то время как более крупные организации, работающие в нескольких областях, могут потребовать нескольких аннотаторов и процессов для измерения межъаннотаторского согласия. Начать с одного эксперта ускоряет процесс. Задача эксперта — предоставить две вещи для каждого взаимодействия пользователя с вашим AI, сгруппированные по сессиям: бинарное суждение "пройдено" или "не пройдено" и подробную критику. Многие команды склонны использовать шкалу Лайкерта от 1 до 5, полагая, что она улавливает больше нюансов. Это ловушка. Различие между тройкой и четверкой субъективно и непоследовательно. Бинарные решения обеспечивают ясность, и результат либо соответствует стандарту качества, либо нет. Нюанс не теряется. Он улавливается в критике, которая объясняет, почему было принято суждение. Эти критики — секретный ингредиент для создания судьи с высокой точностью. Вернемся к нашему предыдущему примеру, когда пользователь запросил просмотр однокомнатной квартиры завтра, а AI потерпел неудачу, предложив квартиру с известной проблемой. В этом примере люди могут разумно не согласиться относительно того, был ли ответ AI достаточно хорош. Однако важно, чтобы вы стремились принять решение о том, что хорошо, а что плохо для вашего продукта. В данном случае мы решили, что это взаимодействие было неудачным. Второй шаг в руководстве по LLM в качестве судьи — это создание и проверка судьи. После того как вы собрали данные истинного положения дел, размеченные вашим экспертом в предметной области, вы готовы создать и проверить судью. Не используйте весь набор данных для создания и тестирования судьи. Это приводит к переобучению, когда вы итерируете, чтобы хорошо работать на наблюдаемых примерах, но терпите неудачу на новых, невиданных данных. Вместо этого разделите данные истинного положения дел на три отдельных набора. Первый — это обучающий набор, который должен составлять около 10-20% ваших данных. Он состоит из небольшого набора четких примеров, включая критику эксперта, для использования в подсказке судьи. Второй набор — это набор для разработки, около 40-45% ваших данных. Это более крупный набор, используемый для итеративного тестирования и уточнения подсказки судьи. И третий набор — это тестовый набор, который также составляет около 40-45% ваших данных. Это отложенный набор, нетронутый во время разработки, для окончательного беспристрастного измерения производительности судьи. Этот процесс уточнения подсказки судьи на наборе для разработки является мета-оценочной задачей. Вы оцениваете своего оценщика. Именно здесь вы обнаружите нюансы своего собственного стандарта качества. Как показали исследования дрейфа критериев, процесс рассмотрения результатов LLM и согласования судьи помогает вам сформулировать и уточнить свои собственные стандарты. Визуализируйте этот процесс как цикл. Вы начинаете с шаблона подсказки, затем разделяете размеченные данные на три набора. Затем вы итеративно уточняете свою подсказку и, наконец, оцениваете и корректируете процент успеха. Третий шаг в процессе LLM в качестве судьи — это обеспечить измерение того, что имеет значение, сосредоточившись на показателях истинно положительных результатов (TPR) и истинно отрицательных результатов (TNR) вместо точности. Распространенный импульс — измерять производительность судьи с помощью одного показателя точности. Но это может быть опасно вводящим в заблуждение. Представьте себе AI-систему, которая работает успешно в 99% случаев. Судья, который всегда предсказывает "пройдено", будет на 99% точным, но он никогда не уловит ни одного сбоя. Это распространенная проблема с несбалансированными наборами данных, где один исход гораздо более частый, чем другой. Вместо точности, TPR и TNR, измеренные вместе, точно скажут вам, как судья, вероятно, совершит ошибки. Простыми словами, TPR определяет следующее: из всех примеров, которые должны пройти, какой процент судья правильно пометил как "пройдено"? А TNR определяет следующее: из всех примеров, которые должны потерпеть неудачу, какой процент судья правильно пометил как "не пройдено"? Судья с высоким TPR, но низким TNR, хорошо распознает успех, но пропускает сбои. Приемлемый компромисс зависит от вашего продукта. Для AI, предоставляющего медицинские консультации, ложноотрицательный результат (неспособность уловить вредное предложение) гораздо дороже, чем ложноположительный. Для помощника по творческому письму ложноположительный результат (пометка хорошего ответа как плохого) может быть хуже, так как он может подавить творчество. Зная TPR и TNR вашего судьи, вы можете даже статистически скорректировать его необработанные показатели, чтобы получить более точную оценку истинного уровня сбоев вашей системы. Например, если ваш судья сообщает о 95% прохождении на 1000 новых примеров, но вы знаете, что он имеет 10% шанс неправильно пометить сбой как прохождение, вы можете скорректировать этот 95% показатель, чтобы отразить известный уровень ошибок судьи. Математические детали этой корректировки приведены в приложении к письменной версии этого поста, ссылка на которую находится в описании к эпизоду. Этот строгий процесс валидации под руководством человека — единственный способ создать надежную систему оценки. Когда вы представляете панель мониторинга, показывающую 5% уровень сбоев для критически важной функции, ваши заинтересованные стороны должны верить, что это число отражает реальность. Этот процесс — то, как вы строите это доверие. Существуют особые соображения и стратегии, которые следует учитывать при разработке оценок для конкретных архитектур, таких как многооборотные разговоры, генерация с дополненным поиском (RAG) и агентские рабочие процессы. Когда речь идет о многооборотных разговорах, многие AI-продукты являются разговорными, что создает проблему поддержания контекста с течением времени. При оценке разговоров начинайте с самого высокого уровня. Достигла ли вся сессия цели пользователя? Это суждение о прохождении или непрохождении на уровне сессии является наиболее важной мерой успеха. Когда разговор терпит неудачу, следующий шаг — определить первопричину. Распространенная ошибка — предполагать, что сбои вызваны сложностями диалога. Прежде чем углубляться в многооборотный анализ, попробуйте воспроизвести сбой в одном обороте. Например, если торговый бот дает неправильную политику возврата на четвертом обороте, сначала спросите его напрямую: "Какова политика возврата для продукта X?" Если он все еще терпит неудачу, проблема, вероятно, заключается в простом знании или проблеме поиска. Если он преуспевает, вы подтвердили, что сбой является разговорным: бот теряет контекст или неправильно интерпретирует информацию из предыдущего диалога. Этот диагностический шаг экономит значительное время, отличая простые пробелы в знаниях от истинных сбоев памяти в разговоре. Когда речь идет о RAG, учитывайте, что система RAG — это двухкомпонентная машина. Ретривер находит информацию, а генератор пишет ответ, используя эту информацию. Эти две части могут давать сбой независимо, и сквозной показатель корректности не скажет вам, какая из них сломана. Вы должны оценивать их отдельно. Сначала оцените ретривер. Относитесь к этому как к проблеме поиска. Для этого вам нужен набор данных запросов, сопоставленных с их известными правильными документами. Наиболее критичной метрикой для RAG часто является полнота на K (recall at K). Она измеряет, какой процент всех действительно релевантных документов захвачен в топ K результатов, которые извлекает ваша система. Полнота имеет первостепенное значение, потому что если правильная информация не извлечена, у генератора нет шансов произвести правильный ответ. Современные LLM удивительно хорошо игнорируют нерелевантный шум в своем контексте, но они не могут изобретать факты из отсутствующей информации. Значение K является критическим параметром настройки, который зависит от вашей задачи. Для простого запроса, требующего одного факта, такого как "Каковы налоги на недвижимость для 123 Main Street?", небольшой K, например 3-5, часто бывает достаточным. Основная цель — убедиться, что извлечен один правильный документ. Однако для сложного запроса, требующего синтеза информации из нескольких источников, такого как "Суммируйте последние тенденции рынка для трехкомнатных домов в центре города", вам понадобится больший K, например 10-20, чтобы предоставить генератору достаточно контекста для создания исчерпывающего ответа. В то время как полнота является приоритетом для начального этапа извлечения, точность на K (precision at K), доля извлеченных документов, которые являются релевантными, становится важной в системах с вторым этапом переранжирования, предназначенным для выбора нескольких лучших документов для передачи LLM. Как только ваш ретривер хорошо работает на разнообразном наборе запросов, вы можете оценить генератор. Здесь вы в основном измеряете две вещи. Первое — это верность. Соответствует ли сгенерированный ответ фактам, представленным в извлеченном контексте, или он галлюцинирует? Второе — релевантность ответа. Отвечает ли ответ непосредственно на исходный вопрос пользователя? Ответ может быть полностью верным исходным документам, но все равно не соответствовать намерению пользователя. Сначала исправьте свой ретривер. Только когда вы уверены, что правильная информация последовательно подается вашему генератору, следует сосредоточиться на улучшении этапа генерации. Следует отметить, что RAG — это очень тонкая тема, и еще многое предстоит исследовать в плане ее оценки и оптимизации. Чтобы узнать больше о продвинутых темах RAG, ознакомьтесь с нашей серией "Погружение глубже", ссылка на которую находится в описании к эпизоду. Третий тип архитектуры, требующий более конкретных стратегий, — это агентские рабочие процессы. Агенты, которые могут выполнять последовательность действий, таких как вызовы инструментов, для достижения цели, являются наиболее сложными системами для оценки. Одно суждение о прохождении или непрохождении конечного результата — хорошее начало, но оно не диагностично. Когда агент терпит неудачу, вам нужно знать, какой шаг в цепочке рассуждений сломался. Для этого матрица сбоев переходов является бесценным инструментом. Думайте о рабочем процессе агента как о серии состояний или шагов, как на сборочной линии. Агент переходит от одного состояния, такого как генерация SQL, к следующему, такому как выполнение SQL. Матрица сбоев переходов — это таблица, которая показывает вам, где именно сборочная линия чаще всего ломается. Строки матрицы представляют последний успешный шаг, а столбцы — шаг, на котором произошел сбой. Анализируя трассировки неудачных взаимодействий агентов и сопоставляя их с этой матрицей, вы можете быстро выявить "горячие точки". Вместо того чтобы гадать, вы можете увидеть на основе данных, что, например, ваш агент чаще всего терпит неудачу при попытке выполнить SQL, который он только что сгенерировал, или когда он неправильно интерпретирует вывод вызова инструмента. Это превращает подавляющую задачу отладки сложного агента в целенаправленное исследование на основе данных. С этими целенаправленными стратегиями оценки для сложных систем вы готовы к операционализации вашего полного набора оценок. Письменная версия этого эпизода включает пример матрицы сбоев переходов, ссылка на которую находится в описании к эпизоду. Наконец, перейдем к третьему этапу — операционализации оценок для непрерывного улучшения. Это конец вашего бесплатного предварительного просмотра. Чтобы услышать полный эпизод, станьте платным подписчиком на lennisnewsletter.com/subscribe. Если вы уже являетесь премиум-участником, вы можете добавить частную ленту в свое приложение для подкастов, перейдя по адресу add.lennisreads.com. Спасибо за прослушивание и до встречи в следующем шоу.