Всем привет!
Меня зовут Александр, я COO в SaaS-платформе аналитики данных. Последний год активно изучаю внедрение AI-решений в кросс-функциональные процессы. Делюсь полезными материалами, которые считаю стоят внимания. В основном про AI, изменение процессов, тренды и продуктовое видение.

У себя в телеграм-канале делюсь сжатыми и структурированными саммери статей.

Сегодняшний перевод — Mastering AI Evals: A Complete Guide for PMs

Успешные AI-продукты отличаются от посредственных не выбором инструментов, а скоростью итераций, основанных на системе оценки (Evals). Компании, делающие акцент на измерении качества, отладке проблем и быстром изменении поведения продукта, создают положительный цикл постоянного улучшения. Наличие надежной системы оценки AI также открывает "суперспособности": возможность эффективного файн-тюнинга, синтеза качественных данных и быстрой отладки проблем.

Evals - это специализированные тестовые процедуры и инструменты для систематической проверки и сравнения возможностей моделей искусственного интеллекта. В отличие от общего понятия «оценка», evals охватывают стандартизированные сценарии, метрики и автоматизированные проверки, что особенно важно для разработки и внедрения современных AI-систем. Примером такого подхода служит OpenAI Evals - открытая платформа для оценки языковых моделей, которая стала отраслевым стандартом и используется для объективного анализа их производительности

Создайте bottom-up таксономию ошибок AI, записывая все проблемы в обычную таблицу, а затем используя LLM для классификации, вместо применения готовых метрик вроде "галлюцинации". В NurtureBoss это позволило выявить всего три ключевые ошибки, составлявшие 60% проблем.

1. Зачем нам нужны AI Evals

Привет, это Hamel Husain. Я начал работать с языковыми моделями пять лет назад, когда возглавил команду, создавшую CodeSearchNet, предшественник GitHub CoPilot.

С тех пор я видел множество успешных и неудачных подходов к созданию LLM-продуктов. Я обнаружил, что неудачные продукты почти всегда имеют общую первопричину: неспособность создать надежные системы оценки.

Вот обычная ситуация из моей консультационной работы:

— Вот наша архитектура агента. Здесь у нас используется RAG, там - маршрутизатор, а ещё мы применяем этот новый фреймворк для… — Как вы измеряете работает ли всё это на самом деле?

Эта ситуация повторялась десятки раз за последние два года. Команды тратят недели на создание сложных AI-систем, но не могут сказать мне, помогают или вредят их изменения.

Это неудивительно. Поскольку каждую неделю появляются новые инструменты и фреймворки, естественно фокусироваться на осязаемых вещах, которые мы можем контролировать: какую векторную базу данных использовать, какого провайдера LLM выбрать или какой фреймворк для агентов применить.

Но помогая более 30 компаниям создавать AI-продукты, я обнаружил, что успешные команды почти не говорят об инструментах. Вместо этого они одержимы измерением и итерациями.

В следующем пункте мы обсудим кейс-стади (одного из моих клиентов), где evals значительно улучшили AI-продукт.

2. Маховик AI Evals: Цепочка положительных изменений

Как и в разработке программного обеспечения, успех с AI зависит от скорости итераций.

У вас должны быть процессы и инструменты для:

Оценки качества (например, тесты)
Отладки проблем (например, логирование и проверка данных)
Изменения поведения продукта (например, prompt engineering, fine-tuning, кодирование)

Хорошее выполнение всех трех действий создает цепочку положительных изменений, отличающий отличные AI-продукты от посредственных.

Если вы оптимизируете процесс оценки, все остальные действия становятся простыми.

Это очень похоже на то, как тесты в разработке программного обеспечения приносят огромные дивиденды в долгосрочной перспективе, несмотря на требуемые начальные инвестиции.

Чтобы связать этот пост с реальной ситуацией, я расскажу о примере, в котором мы создали систему для быстрого улучшения.

Пример: Lucy, AI-ассистент по недвижимости

Rechat — это SaaS-приложение, которое позволяет специалистам по недвижимости выполнять различные задачи, такие как управление контрактами, поиск объявлений, создание креативных материалов, управление встречами и многое другое в одном месте.

AI-ассистент Rechat, Lucy, является каноническим AI-продуктом: разговорный интерфейс, который устраняет необходимость кликать, печатать и перемещаться по программному обеспечению.

На начальных этапах работы Lucy был достигнут быстрый прогресс с помощью prompt engineering. Но по мере расширения сферы применения Lucy ее производительность достигла плато:

Решение одной проблемы приводило к появлению других
Была ограниченная видимость эффективности AI-системы в различных задачах
Промпты расширились до длинных и громоздких форм, пытаясь охватить множество пограничных случаев и примеров

Мы столкнулись с проблемой: Как систематически улучшать AI?

Чтобы преодолеть это плато, мы создали систематический подход к улучшению Lucy, сосредоточенный на оценке:

Маховик AI Evals: Цепочка положительных изменений

Эта диаграмма — максимально точная попытка проиллюстрировать мою ментальную модель улучшения AI-систем. В реальности процесс может отличаться.

Строгая и систематическая оценка — это самая важная часть всей системы. Большую часть времени вы должны тратить на то, чтобы сделать вашу оценку более надежной и оптимизированной.

Я буду ссылаться на компоненты этой системы в следующем пункте.

3. Три уровня оценки AI

Существуют три уровня оценки, которые следует учитывать:

Уровень 1: Модульные тесты
Уровень 2: Оценка модели и человека (включая отладку)
Уровень 3: A/B-тестирование

Стоимость Уровня 3 > Уровня 2 > Уровня 1. Это определяет способ их выполнения. Например, я обычно:

Запускаю оценки Уровня 1 при каждом изменении кода.
Запускаю Уровень 2 по определенному графику, после решения значительной части Уровня 1.
Запускаю Уровень 3 только после значительных изменений продукта.

Нет строгой формулы относительно того, когда вводить каждый уровень тестирования. В случае сомнений руководствуйтесь здравым смыслом.

3.1 Уровень 1: Модульные тесты (Утверждения)

Модульные тесты для LLM — это утверждения (как те, что вы бы написали в pytest). В отличие от типичных модульных тестов, вы должны организовать эти утверждения для использования в местах помимо модульных тестов, таких как очистка данных и автоматические повторные попытки (используя ошибку утверждения для корректировки курса) во время вывода модели.

Важно то, что эти утверждения должны выполняться быстро и дешево по мере разработки приложения, чтобы вы могли запускать их каждый раз при изменении кода.

Если у вас возникают трудности с придумыванием утверждений, вам следует критически изучить ваши трассировки и режимы отказа. Также не стесняйтесь использовать LLM, чтобы помочь вам придумать утверждения!

Шаг 1: Написание модульных тестов

Наиболее эффективный способ думать о модульных тестах — это разбить область действия вашего LLM на функции и сценарии. Например, одна из функций Lucy — это возможность находить объекты недвижимости, которую мы можем разбить на сценарии следующим образом:

Функция: Поиск объявлений

Эта функция, которую нужно протестировать, — это вызов функции, которая отвечает на запрос пользователя о поиске объявления о недвижимости. Например, "Пожалуйста, найди объявления с более чем 3 спальнями стоимостью менее $2 млн в Сан-Хосе, Калифорния"

LLM преобразует это в запрос, который выполняется против CRM. Затем утверждение проверяет, что возвращается ожидаемое количество результатов.

Для упрощения, в нашем наборе тестов у нас есть три пользовательских ввода, которые запускают каждый из сценариев ниже, которые затем выполняют соответствующие утверждения:

Также есть общие тесты, которые не специфичны для какой-либо одной функции. Например, общий тест, который гарантирует, что ни один из UUID (уникальных ID из CRM) не упоминается в выводе.

Rechat имеет сотни таких модульных тестов. Мы постоянно обновляем их на основе новых сбоев, которые мы наблюдаем в данных, когда пользователи бросают вызов AI или когда продукт развивается.

Эти модульные тесты имеют решающее значение для быстрого получения обратной связи при итерации вашей AI-системы (prompt engineering, улучшение RAG и т.д.). Важно не пропускать этот шаг!

Шаг 2: Создание тестовых примеров

Для тестирования этих утверждений вы должны создать тестовые примеры или входные данные, которые будут запускать все сценарии, которые вы хотите протестировать.

Я часто использую LLM для синтетического создания этих входных данных. Например, вот один из таких промптов, который Rechat использует для создания синтетических входных данных для функции, которая создает и извлекает контакты:

Write 50 different instructions that a real estate agent can give to his assistant to create contacts on his CRM. The contact details can include name, phone, email, partner name, birthday, tags, company, address and job.

For each of the instructions, you need to generate a second instruction which can be used to look up the created contact.

The results should be a JSON code block with only one string as the instruction like the following:

[\
  ["Create a contact for John (johndoe@apple.com)",\
  "What's the email address of John Smith?"]\
]

Используя приведенный выше промпт, мы создаем тестовые примеры, как показано ниже:

[\
    [\
        'Create a contact for John Smith (johndoe@apple.com) with phone number 123-456-7890 and address 123 Apple St.',\
        'What\'s the email address of John Smith?'\
    ],\
    [\
        'Add Emily Johnson with phone 987-654-3210, email emilyj@email.com, and company ABC Inc.',\
        'What\'s the phone number for Emily Johnson?'\
    ],\
    [\
        'Create a contact for Tom Williams with birthday 10/20/1985, company XYZ Ltd, and job title Manager.',\
        'What\'s Tom Williams\' job title?'\
    ]\
]

Для каждого из этих тестовых примеров мы выполняем первый пользовательский ввод для создания контакта. Затем мы выполняем второй запрос для получения этого контакта. Если CRM не возвращает ровно 1 результат, мы знаем, что была проблема либо с созданием, либо с получением контакта.

Мы также можем запустить общие утверждения, например, для проверки того, что UUID нет в ответе.

Вы должны постоянно обновлять эти тесты по мере того, как вы наблюдаете данные с помощью человеческой оценки и отладки. Ключевым моментом является сделать их как можно более сложными, при этом представляя взаимодействие пользователей с системой.

Вам не нужно ждать производственных данных для тестирования вашей системы. Вы можете делать обоснованные предположения о том, как пользователи будут использовать ваш продукт, и создавать синтетические данные.

Вы также можете позволить небольшому набору пользователей использовать ваш продукт и позволить их использованию уточнить вашу стратегию создания синтетических данных.

Один из признаков того, что вы пишете хорошие тесты и утверждения, — это когда модели сложно их пройти. Эти режимы отказа становятся проблемами, которые вы можете решить с помощью таких методов, как fine-tuning позже.

Кстати, в отличие от традиционных модульных тестов, вы не должны стремиться к 100% показателю прохождения. Ваш показатель прохождения — это решение продукта, зависящее от сбоев, которые вы готовы терпеть. На самом деле, 100% прохождение — это красный флаг.

Шаг 3: Регулярно запускайте и отслеживайте свои тесты

Существует множество способов организации тестов Уровня 1. Rechat использует инфраструктуру CI (например, GitHub Actions, GitLab Pipelines и т.д.) для выполнения этих тестов. Но инструменты для этой части рабочего процесса только зарождаются и быстро развиваются.

Мой совет - организовывать тесты, которые вызывают наименьшее количество трудностей в вашей технологической инфраструктуре

Помимо отслеживания тестов, вам необходимо отслеживать результаты ваших тестов с течением времени, чтобы видеть, прогрессируете ли вы. Если вы используете CI (непрерывную интеграцию), вы должны собирать метрики вместе с версиями ваших тестов/промптов за пределами вашей системы CI для удобного анализа и отслеживания.

Я рекомендую начинать просто и использовать вашу существующую аналитическую систему для визуализации результатов тестов.

Например, Rechat использует Metabase для отслеживания результатов LLM-тестов с течением времени. Ниже представлен скриншот панели мониторинга, которую Rechat создал с помощью Metabase:

AI Evals. На этом скриншоте показана распространенность определенной ошибки (выделена желтым) в Lucy до (слева) и после (справа) того, как мы ее устранили.

3.2 Уровень 2: Оценка модели и человека

После того, как вы создали прочную основу из тестов Уровня 1, вы можете перейти к другим формам проверки, которые нельзя протестировать только с помощью утверждений.

Предварительным условием для выполнения оценки человеком и моделью является логирование ваших трассировок.

Логирование трассировок

Трассировка — это концепция, которая существует уже давно в разработке программного обеспечения, и представляет собой лог последовательности событий, таких как пользовательские сессии или поток запросов через распределенную систему. Другими словами, трассировка — это логическая группировка логов.

В контексте LLM трассировки часто относятся к разговорам, которые вы ведете с LLM. Например, сообщение пользователя, за которым следует ответ AI, за которым следует еще одно сообщение пользователя, было бы примером трассировки.

Существует большое количество решений для логирования трассировок LLM. Rechat использует LangSmith, который логирует трассировки и позволяет просматривать их в удобном для человека виде с интерактивной площадкой для итерации по промптам.

Иногда для логирования трассировок требуется инструментирование кода. В этом случае Rechat использовал LangChain, который автоматически логирует события трассировки в LangSmith за вас.

Вот скриншот того, как это выглядит:

AI Evals: LangChain автоматически логирует события трассировки в LangSmith

Мне нравится LangSmith. Он не требует использования LangChain и является интуитивно понятным и простым в использовании.

Поиск, фильтрация и чтение трассировок — это важные функции для любого решения, которое вы выберете. Я обнаружил, что некоторые инструменты не реализуют эти функции правильно!

Просмотр трассировок

Сначала вы должны устранить все сложности при просмотре данных. Это означает отображение ваших трассировок специфическим для домена способом.

Я часто обнаруживал, что лучше создать свой собственный инструмент для просмотра и маркировки данных, чтобы я мог собрать всю необходимую информацию на одном экране.

В случае с Lucy нам нужно было смотреть на многие источники информации (лог трассировки, CRM и т.д.), чтобы понять, что сделал AI. Это именно тот тип сложностей, который необходимо устранить. В случае Rechat это означало добавление информации, такой как:

Какой инструмент (функция) и сценарий оценивался.
Является ли трассировка результатом синтетического ввода или реального пользовательского ввода.
Фильтры для навигации между различными комбинациями инструментов и сценариев.
Ссылки на CRM и систему логирования трассировок для текущей записи.

Я создавал разные варианты этого инструмента для каждой проблемы, над которой работал. Иногда мне даже нужно встраивать другое приложение, чтобы увидеть, как выглядит взаимодействие пользователя. Ниже представлен скриншот инструмента, который мы создали для оценки трассировок Rechat:

Еще одно проектное решение, специфичное для Lucy, заключается в том, что мы заметили, что многие сбои связаны с небольшими ошибками в конечном выводе LLM (формат, содержание и т.д.). Мы решили сделать конечный вывод редактируемым человеком, чтобы мы могли курировать и исправлять данные для fine-tuning.

Эти инструменты можно создать с помощью легких фронтенд-фреймворков, таких как Gradio, Streamlit, Panel или Shiny, менее чем за день. Показанный выше инструмент был создан с помощью Shiny для Python.

Кроме того, существуют такие инструменты, как Lilac, который использует AI для семантического поиска и фильтрации данных, что невероятно удобно для поиска набора схожих точек данных при отладке проблемы.

Я часто начинаю с маркировки примеров как хороших или плохих. Я обнаружил, что присвоение оценок или более детальных рейтингов сложнее управлять, чем бинарные рейтинги.

Существуют продвинутые методы, которые вы можете использовать, чтобы сделать оценку человеком более эффективной или точной (например, активное обучение, консенсусное голосование и т.д.), но я рекомендую начинать с чего-то простого.

Наконец, как и в случае с модульными тестами, вы должны организовать и анализировать результаты оценки человеком, чтобы оценить, прогрессируете ли вы с течением времени.

Как будет обсуждаться позже, эти размеченные примеры измеряют качество вашей системы, проверяют автоматическую оценку и курируют высококачественные синтетические данные для fine-tuning.

Сколько данных вы должны просмотреть?

Меня часто спрашивают, сколько данных нужно изучить. Когда вы начинаете, вы должны изучить как можно больше данных. Я обычно читаю трассировки, созданные из ВСЕХ тестовых примеров и созданные пользователями трассировки как минимум.

Вы никогда не можете перестать смотреть на данные. Однако со временем вы можете выборочно просматривать данные, уменьшая нагрузку.

Отслеживайте корреляцию между оценкой на основе модели и оценкой человеком

Многие поставщики хотят продать вам инструменты, которые утверждают, что устраняют необходимость человеку смотреть на данные. Но хорошая идея — периодически оценивать человеком хотя бы выборку трассировок.

Я часто обнаруживаю, что "правильность" несколько субъективна, и вы должны согласовать модель с человеком.

Вы должны отслеживать корреляцию между оценкой на основе модели и оценкой человеком, чтобы решить, насколько вы можете полагаться на автоматическую оценку.

Кроме того, собирая критику от разметчиков, объясняющую, почему они принимают решение, вы можете итерировать по модели оценки, чтобы согласовать ее с людьми через prompt engineering или fine-tuning. Однако я склоняюсь к предпочтению prompt engineering для согласования модели оценки.

Мне нравится использовать простые решения, такие как Excel, для итерации по согласованию оценки на основе модели с людьми.

Например, я отправлял своему коллеге Phillip следующую таблицу каждые несколько дней для оценки для другого случая использования, связанного с генератором запросов на естественном языке.

Эта таблица содержала следующую информацию:

model response: это предсказание, сделанное LLM.
model critique: это критика, написанная (обычно более мощной) LLM о предсказании вашей исходной LLM.
model outcome: это бинарная метка, которую модель критики присваивает model response как "хорошее" или "плохое."

Затем Phillip заполняет свою версию той же информации - то есть свою критику, результат и желаемый ответ для 25-50 примеров за раз (это столбцы с префиксом "phillip" ниже):

Сравнение оценки на основе модели и оценки человеком при AI evals

Бесплатный шаблон (File > Download).

Эта информация позволила мне итерировать по промпту модели критики, чтобы сделать ее достаточно согласованной с Phillip со временем. Это также легко отслеживать в таблице:

Отслеживание корреляции между оценкой на основе модели и оценкой человеком

Бесплатный шаблон (File > Download)

Это скриншот таблицы, где мы записывали наши попытки согласовать оценку на основе модели с оценкой человека.

Общие советы по оценке на основе модели:

Используйте самую мощную модель, которую вы можете себе позволить. Часто для хорошей критики требуются продвинутые способности рассуждения. Вы часто можете использовать более медленную, но более мощную модель для критики выводов по сравнению с той, что используете в производстве.
Вы должны поддерживать дополнительную мини-систему оценки для отслеживания качества оценки на основе модели. Иногда я делал fine-tuning модели на этом этапе (но стараюсь этого не делать).
После приведения модели-оценщика в соответствие с человеком вы должны продолжать периодические упражнения для мониторинга согласия модели и человека.

Мой любимый аспект создания хорошей модели-оценщика заключается в том, что ее критика может использоваться для управления высококачественных синтетических данных, о чем я расскажу позже.

3.3 Уровень 3: A/B-тестирование

Наконец, всегда полезно проводить A/B-тесты, чтобы убедиться, что ваш AI-продукт стимулирует желаемое поведение пользователей или результаты. A/B-тестирование для LLM по сравнению с другими типами продуктов не слишком отличается.

Если вы хотите узнать больше об A/B-тестировании, я рекомендую прочитать блог Eppo (который был создан коллегами, с которыми я раньше работал, и которые являются звездами в A/B-тестировании).

Нормально отложить этот этап, пока вы не будете достаточно готовы и убеждены, что ваш AI-продукт подходит для показа реальным пользователям. Этот уровень оценки обычно подходит только для более зрелых продуктов.

3.4 Оценка RAG

Помимо оценки вашей системы в целом, вы можете оценивать подкомпоненты вашего AI, такие как RAG. Оценка RAG выходит за рамки этого поста, но вы можете узнать больше об этой теме в посте Jason Liu.

4. Метрики AI Eval: Анализ снизу вверх и сверху вниз

При определении типов ошибок вы можете использовать подход "сверху вниз" или "снизу вверх".

Подход сверху вниз начинается с общих метрик, таких как "галлюцинации" или "токсичность", плюс метрик, уникальных для вашей задачи. Хотя это удобно, этот подход часто упускает проблемы, специфичные для домена.

Более эффективный подход снизу вверх заставляет вас смотреть на реальные данные и позволяет метрикам естественно появляться.

В NurtureBoss мы начали с таблицы, где каждая строка представляла собой разговор. Мы писали открытые заметки о любом нежелательном поведении.

Затем мы использовали LLM для создания таксономии общих режимов отказа. Наконец, мы сопоставили каждую строку с конкретными метками режимов отказа и подсчитали частоту каждой проблемы.

Результаты были поразительными — всего три проблемы составили более 60% всех проблем:

Проблемы с потоком разговора (отсутствие контекста, неуклюжие ответы)
Сбои передачи (неспособность распознать, когда передать управление людям)
Проблемы с перепланированием (трудности с обработкой дат)

Влияние было немедленным. Команда обнаружила так много полезных идей, что им потребовалось несколько недель только для реализации исправлений для проблем, которые мы уже нашли.

Если вы хотите узнать больше об этом подходе, посмотрите это видео с объяснением от Jacob Carter, основателя NurtureBoss:

5. Три бесплатных суперспособности, которые открывают системы Eval

Помимо быстрой итерации, системы оценки открывают возможность fine-tuning и отладки, что может вывести ваш AI-продукт на новый уровень.

Три бесплатных суперспособности, которые открывают системы Eval

5.1 Fine-Tuning

Rechat разрешил многие режимы отказа с помощью fine-tuning, что было невозможно с помощью prompt engineering в одиночку.

Fine-tuning лучше всего подходит для изучения синтаксиса, стиля и правил, тогда как такие техники, как RAG, снабжают модель контекстом или актуальными фактами.

99% работы, связанной с fine-tuning, заключается в подготовке высококачественных данных, охватывающих поверхность вашего AI-продукта. Но если у вас есть надежная система оценки, у вас уже есть мощный механизм генерации и управления данных.

5.2 Синтез и управление данных

Чтобы проиллюстрировать, почему управление и синтез данных почти бесплатны, как только у вас есть система оценки, рассмотрим случай, когда вы хотите создать дополнительные данные fine-tuning для упомянутого ранее поиска объявлений.

Сначала вы можете использовать LLM для создания синтетических данных с помощью промпта, подобного этому:

Imagine if Zillow was able to parse natural language. Come up with 50 different ways users would be able to search listings there. Use real names for cities and neighborhoods.

You can use the following parameters:

<ommitted for confidentiality>

Output should be a JSON code block array. Example:

[\
"Homes under $500k in New York"\
]

Это почти идентично упражнению по созданию тестовых примеров! Затем вы можете использовать тесты Уровня 1 и Уровня 2 для фильтрации нежелательных данных, которые не проходят утверждения или которые модель критики считает неправильными. Вы также можете использовать свои существующие инструменты оценки человеком для просмотра трассировок для управления трассировок для набора данных fine-tuning.

5.3 Отладка

Когда вы получаете жалобу или видите ошибку, связанную с вашим AI-продуктом, вы должны иметь возможность быстро отладить это. Если у вас есть надежная система оценки, у вас уже есть:

База данных трассировок, которую вы можете искать и фильтровать.
Набор механизмов (утверждения, тесты и т.д.), которые могут помочь вам отметить ошибки и плохое поведение.
Инструменты поиска и навигации по логам, которые могут помочь вам найти первопричину ошибки. Например, ошибка может быть в RAG, в коде или в плохо работающей модели.
Возможность вносить изменения в ответ на ошибку и быстро тестировать ее эффективность.

Короче говоря, существует невероятно большое перекрытие между инфраструктурой, необходимой для оценки, и той, что необходима для отладки.

6. Шаблоны AI Eval для скачивания

6.1 Таблица ручной оценки AI

Этот шаблон основан на разделе "3.2 Уровень 2: Оценка модели и человека:"

Google Drive (File > Download)

6.2 Премиум: Шаблон приложения для просмотра данных LLM Evals

Общее веб-приложение, созданное с помощью Lovable, которое позволяет пользователям:

Просматривать трассировки LLM
Оценивать трассировки LLM
Предварительно просматривать оценки на основе модели (в метаданных)
Отслеживать корреляцию между оценкой на основе модели и оценкой человеком
Импортировать / экспортировать данные

Шаблон приложения для просмотра данных LLM Evals

Вы можете предварительно просмотреть его здесь: https://trace-tuner-lucy-review.lovable.app/

Руководство по созданию системы оценки качества AI