Пошаговое руководство по построению контроля качества ИИ с использованием больших языковых моделей
Делиться
Когда я впервые услышал об идее использования ИИ для оценки ИИ , также известной как «магистр права как судья», моя реакция была:
«Ладно, мы официально сошли с ума».
Мы живём в мире, где даже туалетная бумага позиционируется как «на основе искусственного интеллекта». Я полагал, что это просто очередной тренд, вызванный шумихой в нашем хаотичном и быстро меняющемся мире искусственного интеллекта.
Но как только я разобрался, что на самом деле означает степень магистра права в качестве судьи, я понял, что ошибался. Позвольте объяснить.
Есть одна картина, которую каждый специалист по обработке данных и инженер машинного обучения должен держать в голове. Она отражает весь спектр сложности модели, размера обучающего набора и ожидаемого уровня производительности:
Если задача простая , наличие небольшого обучающего набора обычно не является проблемой. В некоторых крайних случаях её можно решить даже с помощью простого подхода на основе правил. Даже когда задача становится более сложной , часто можно достичь высокой эффективности, если у вас большой и разнообразный обучающий набор.
Настоящие проблемы начинаются, когда задача сложная, а у вас нет доступа к полному обучающему набору. В этом случае простого рецепта не существует. Вам потребуются эксперты в предметной области, ручной сбор данных и тщательные процедуры оценки, а в худшем случае вам могут потребоваться месяцы или даже годы работы только для создания надёжных меток.
… это было до появления больших языковых моделей (LLM).
Парадигма магистра права как судьи
Обещание LLM простое: вы получаете знания, близкие к уровню доктора философии (PhD), во многих областях, доступные всего одним вызовом API. Мы можем (и, вероятно, должны) спорить о том, насколько «интеллектуальны» эти системы на самом деле. Появляется всё больше свидетельств того, что LLM ведёт себя скорее как чрезвычайно мощный инструмент сопоставления образов и извлечения информации, чем как по-настоящему интеллектуальный агент [вам обязательно стоит это посмотреть].
Однако одно трудно отрицать. Когда задача сложная , её трудно формализовать, и у вас нет готового набора данных , степень магистра права может быть невероятно полезна . В таких ситуациях они дают вам высокоуровневые рассуждения и знания предметной области по запросу, задолго до того, как вы сможете собрать и разметить достаточно данных для обучения традиционной модели.
Итак, вернёмся к нашему « большому » красному квадрату. Представьте, что у вас есть сложная задача и только очень грубая первая версия модели. Возможно, она была обучена на небольшом наборе данных, а может быть, это уже существующая модель, которую вы вообще не настраивали (например, BERT или какая-то другая модель встраивания).
В подобных ситуациях вы можете воспользоваться услугами магистра права (LLM) для оценки эффективности модели V0. LLM становится оценщиком (или судьёй ) вашего раннего прототипа, предоставляя вам немедленную обратную связь без необходимости использования большого набора размеченных данных или огромных усилий, о которых мы упоминали ранее.
Это имело бы множество полезных применений в дальнейшем:
- Оценка состояния V0 и его производительности
- Создание обучающего набора для улучшения существующей модели
- Мониторинг стадии существующей модели или доработанной версии (в соответствии с пунктом 2).
Итак, давайте построим это!
Магистр права в качестве судьи в производстве
Итак, возникает ложный силлогизм: раз не нужно обучаться на степень магистра права (LLM), а использование их в интерфейсе ChatGPT/Anthropic/Gemini интуитивно понятно, то создать систему LLM должно быть легко . Но это не так.
Если ваша цель — не простая функция «подключи и работай», то вам необходимо приложить активные усилия, чтобы убедиться, что ваша LLM надежна, точна и максимально свободна от галлюцинаций, спроектировав ее так, чтобы она изящно выходила из строя в случае отказа (не если , а когда ).
Вот основные темы, которые мы рассмотрим, чтобы создать готовую к использованию систему LLM-as-aJudge.
- Системный дизайн
Мы определим роль магистра права, как он должен себя вести и какую перспективу или «персону» он должен использовать во время оценки. - Примеры нескольких снимков
Мы приведем конкретные примеры для LLM, которые покажут, как именно должна выглядеть оценка для различных тестовых случаев. - Запуск цепочки мыслей
Мы попросим магистра права (LLM) делать заметки, промежуточные рассуждения и определять уровень уверенности, чтобы инициировать более надёжную цепочку мыслей. Это побуждает модель действительно «думать». - Пакетная оценка
Чтобы сократить затраты и задержки, мы будем отправлять несколько входных данных одновременно и повторно использовать одну и ту же подсказку для группы примеров. - Форматирование вывода
Мы будем использовать Pydantic для реализации структурированной схемы вывода и предоставления этой схемы непосредственно LLM, что делает интеграцию более чистой и безопасной для производства.
Давайте погрузимся в код! 🚀
Код
Весь код можно найти на следующей странице GitHub [здесь]. Я рассмотрю его основные части в следующем абзаце.
1. Настройка
Давайте начнем с уборки.
Вся грязная работа кода выполняется с помощью OpenAI и обёрнута в llm_judge. Поэтому всё, что вам нужно импортировать, — это следующий блок:
Примечание: вам понадобится ключ API OpenAI.
Весь код производственного уровня обрабатывается на бэкенде (спасибо потом). Продолжим.
2. Наш вариант использования
Допустим, у нас есть модель классификации настроений, которую мы хотим оценить. Модель анализирует отзывы клиентов и прогнозирует: положительные, отрицательные или нейтральные.
Вот пример данных, классифицированных нашей моделью:
Для каждого прогноза мы хотим знать:
– Корректен ли этот вывод?
– Насколько мы уверены в этом суждении?
– Почему это правильно или неправильно?
– Как мы будем оценивать качество?
Вот тут-то и вступает в дело LLM-как-судья. Обратите внимание, что ground_truth на самом деле отсутствует в нашем реальном наборе данных; именно поэтому мы изначально используем LLM. 🙃
Единственная причина, по которой вы видите его здесь, — это отображение классификаций, в которых наша исходная модель неэффективна (индекс 2 и индекс 3).
Обратите внимание, что в данном случае мы притворяемся , что используем более слабую модель с некоторыми ошибками. В реальной ситуации это происходит при использовании небольшой модели или адаптации нетонко настроенной модели глубокого обучения.
3. Определение роли
Как и в случае любой оперативной инженерии, нам необходимо четко определить:
1. Кто будет судьей? Магистр права будет выступать в роли судьи, поэтому нам нужно определить его опыт и опыт.
2. Что они оценивают? Конкретная задача, которую должен оценить LLM.
3. Какие критерии следует использовать? Что должен сделать магистр права, чтобы определить, является ли результат хорошим или плохим.
Вот как мы это определяем:
Некоторые рекомендации: используйте чёткие указания . Укажите, что именно должен делать LLM (а не то, чего не должен). Будьте предельно конкретны в процедуре оценки.
4. Парадигма ReAct
В нашу структуру встроен шаблон ReAct (Рассуждение + Действие). Каждое суждение включает в себя:
1. Оценка (0–100) : Количественная оценка качества
2. Вердикт : бинарное или категорическое суждение
3. Уверенность : насколько уверен судья
4. Рассуждение : объяснение с помощью цепочки мыслей
5. Примечания : Дополнительные наблюдения
Это позволяет:
– Прозрачность : вы можете видеть, почему судья принял каждое решение.
– Отладка : выявление закономерностей в ошибках
– Человек в петле : передавать людям решения с низкой степенью уверенности
– Контроль качества : отслеживание работы судей с течением времени
5. Примеры нескольких снимков
Теперь давайте приведем еще несколько примеров, чтобы убедиться, что у LLM есть некоторый контекст для оценки реальных случаев:
Мы поместим эти примеры вместе с подсказкой, чтобы магистр права научился выполнять задание на основе приведенных нами примеров.
Некоторые заметки к рецепту: опишите различные сценарии : правильный, неправильный и частично правильный. Укажите градуировку баллов (100 — идеальный ответ, 20–30 — явные ошибки, 60 — спорные случаи). Подробно объясните причину . Приведите ссылки на конкретные слова/фразы из входных данных.
6. Определение судьи магистра права
Все это упаковано в следующий блок кода:
Вот так. 10 строк кода. Давайте используем это:
7. Побежали!
Вот как выполнить весь вызов API LLM Judge:
Итак, мы сразу видим, что LLM Judge верно оценивает эффективность имеющейся «модели». В частности, он обнаруживает, что последние два результата модели неверны, чего мы и ожидали.
Хотя это и хорошо демонстрирует, что всё работает, в рабочей среде мы не можем просто «вывести» вывод в консоль: нам нужно сохранить его и убедиться, что формат стандартизирован. Вот как это делается:
И вот как это выглядит.
Обратите внимание, что мы также используем «пакетирование», то есть отправляем несколько входных данных одновременно. Это экономит время и деньги.
8. Бонус
А теперь самое интересное. Допустим, вам нужно оценить совершенно другую задачу. Например, вы хотите оценить реакцию чат-бота на вашу модель. Весь код можно рефакторить, добавив несколько строк:
Поскольку два разных «судьи» меняются только на основе подсказок, которые мы предоставляем LLM, изменения между двумя различными оценками чрезвычайно просты.
Выводы
LLM-as-a-Judge — это простая идея, обладающая большой практической силой. Если ваша модель грубая, задача сложная, а у вас нет размеченного набора данных, LLM может помочь вам оценить результаты, понять ошибки и ускорить итерации.
Вот что мы построили:
- Четкая роль и личность судьи
- Несколько примеров , чтобы направлять его поведение
- Цепочка рассуждений для обеспечения прозрачности
- Пакетная оценка для экономии времени и средств
- Структурированный вывод с помощью Pydantic для использования в производстве
Результатом является гибкий механизм оценки, который можно использовать повторно в разных задачах с небольшими изменениями. Он не заменяет человеческую оценку, но обеспечивает надежную отправную точку задолго до того, как вы сможете собрать необходимые данные.
Прежде чем отправиться в путь
Ещё раз спасибо за уделённое время. Это очень много значит ❤️
Меня зовут Пьеро Паялунга, и я вот этот парень:
Я родом из Италии, имею докторскую степень Университета Цинциннати и работаю специалистом по анализу данных в The Trade Desk в Нью-Йорке. Я пишу об искусственном интеллекте, машинном обучении и меняющейся роли специалистов по анализу данных как здесь, на TDS, так и на LinkedIn. Если вам понравилась статья и вы хотите узнать больше о машинном обучении и следить за моими исследованиями, вы можете:
А. Подписывайтесь на меня в Linkedin , где я публикую все свои истории.
B. Подпишитесь на меня на GitHub , где вы можете увидеть весь мой код.
C. Если у вас есть вопросы, отправьте мне письмо по адресу piero.paialunga@hotmail.
Источник: towardsdatascience.com
