Удерживать курс навигация по оценке заявок, основанных на LLM

Направлять путь оценки заявок, основанных на LLM, в сфере навигации

Почему важна оценка приложений LLM и как начать

Введение

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

1. Разница между оценкой LLM по сравнению с оценкой приложения на основе LLM
2. Важность оценки приложения LLM
3. Трудности оценки приложения LLM
4. Началоa. Сбор данных и создание набора тестовb. Измерение производительности
5. Рамочная система оценки приложения LLM

На примере вымышленного примера FirstAidMatey, помощника по первой помощи для пиратов, мы будем путешествовать по морям приемов оценки, сложностей и стратегий. Заключительными будут ключевые выводы и идеи. Итак, поехали в этот просветительский путь вместе!

Оценка LLM по сравнению с оценкой приложения на основе LLM

Оценка отдельных больших языковых моделей (LLM), таких как GPT-4 от OpenAI, PaLM 2 от Google и Claude от Anthropic, обычно выполняется с помощью тестов, таких как MMLU. Однако в этом блоге нас интересует оценка приложений на основе LLM. Это приложения, которые работают на базе LLM и содержат другие компоненты, такие как система оркестрации, управляющая последовательностью вызовов LLM. Часто для предоставления контекста LLM и предотвращения галлюцинаций используется Retrieval Augmented Generation (RAG). Вкратце, RAG требует встраивания контекстных документов в векторное хранилище, из которого можно извлекать соответствующие фрагменты и передавать их LLM. В отличие от LLM, приложение на основе LLM (или LLM app) разработано для выполнения одной или нескольких конкретных задач с высокой эффективностью. Поиск правильной настройки часто требует некоторого экспериментирования и итеративного улучшения. RAG, например, может быть реализовано разными способами. Рассмотренная в этом блоге система оценки поможет вам найти наилучшую настройку для вашего случая использования.

FirstAidMatey – это приложение на основе LLM, которое помогает пиратам с вопросами вроде “Моя рука застряла в веревке и опухла, что мне делать, приятель?”. В самой простой форме оркестратор состоит из одной подсказки, которая передает вопрос пользователя LLM и просит его дать полезные ответы. Он также может указать LLM отвечать на пиратском жаргоне для оптимального понимания. Как расширение, можно добавить векторное хранилище с встроенной документацией по первой помощи. На основе вопроса пользователя можно извлечь соответствующую документацию и включить ее в подсказку, чтобы LLM мог предоставить более точные ответы.

• Мета и исследователи из GeorgiaTech выпустили новый набор данных и связанные модели искусственного интеллекта, чтобы ускорить исследования по прямому захвату воздуха для борьбы с изменением климата.
• Ключевой старт в MLOps исследование его неотъемлемых компонентов
• Использование плагинов Polars для повышения скорости в 14 раз с помощью Rust

Важность оценки приложения LLM

Прежде чем мы перейдем к тому, как это делать, давайте посмотрим, почему вам следует создать систему для оценки вашего приложения на основе LLM. Основные цели следующие:

• Последовательность: Обеспечить стабильные и надежные результаты работы приложения LLM во всех ситуациях и обнаруживать регрессии при их возникновении. Например, когда вы улучшаете производительность вашего приложения LLM в конкретной ситуации, вы хотите быть предупреждены, если это приведет к ухудшению производительности в другой ситуации. При использовании патентных моделей, таких как GPT-4 от OpenAI, вы также подвержены их графику обновлений. Поскольку выходят новые версии, ваша текущая версия со временем может устареть. Исследования показывают, что переход на новую версию GPT не всегда лучше. Поэтому важно уметь оценить, как это новая версия влияет на производительность вашего приложения LLM.
• Идеи: Понять, где хорошо выполняется приложение LLM, и где есть место для улучшений.
• Тестирование: Создание производительностных стандартов для приложения LLM, измерение результатов экспериментов и уверенное выпуск новых версий.

В результате вы достигнете следующих результатов:

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

Проблемы оценки приложения LLM

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

• Отсутствие размеченных данных: В отличие от традиционных приложений машинного обучения, приложения на основе LLM не требуют размеченных данных для начала работы. LLM может выполнять множество задач (таких как классификация текста, суммирование, генерация и другие) сразу, без необходимости показывать конкретные примеры. Это замечательно, потому что нам не нужно ждать данных и меток, но в то же время это означает, что у нас нет данных, чтобы проверить, насколько хорошо работает приложение.
• Несколько верных ответов: В приложении LLM на один и тот же ввод может быть несколько правильных ответов. Например, чат-бот может давать разные ответы с похожим значением, или код может быть сгенерирован с одинаковым функционалом, но разной структурой.

Для решения этих проблем необходимо определить соответствующие данные и показатели. Мы сделаем это в следующем разделе.

Начинаем

Сбор данных и создание тестового набора

Для оценки приложения на основе LLM мы используем тестовый набор, состоящий из тестовых случаев с определенными входными данными и целями. Что они содержат зависит от цели приложения. Например, приложение для генерации кода ожидает вербальных инструкций в качестве ввода и возвращает код в ответ. Во время оценки, входные данные будут передаваться в приложение LLM, а сгенерированный вывод можно сравнить с целевым значением. Вот несколько тестовых случаев для FirstAidMatey:

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

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

Измерение качества оценки

Имея набор тестовых случаев, мы теперь можем передать входные данные в приложение LLM и сравнить сгенерированные ответы с целями. Поскольку для каждого ввода нет одного правильного ответа, мы не можем буквально сравнивать ответ с эталонным. Ответ может быть сформулирован иначе, но иметь то же самое значение, что и эталонный. Однако мы можем оценить несколько свойств ответа как прокси-метрику для качества ответа. Релевантные свойства для тестирования зависят от приложения и доступных данных. Вот список свойств ответов FirstAidMatey и способов превращения их в метрику:

• Фактическая согласованность: Используйте LLM для оценки того, является ли сгенерированный ответ фактически согласованным с эталонным ответом.
• Пиратство: Используйте LLM, чтобы оценить, написан ли ответ на пиратском языке.
• Семантическая схожесть: Вычислите косинусную схожесть между векторами сгенерированного и эталонного ответов. Заметьте, что это гораздо более дешево, чем Фактическая согласованность, но может быть менее коррелировано с правильными ответами.
• Многословность: Разделите длину сгенерированного ответа на длину эталонного ответа. Чем выше многословность, тем более разговорчиво ведет себя приложение LLM, что может не являться его намерением.
• Задержка: Измеряйте время, необходимое приложению LLM для генерации ответа. Это позволяет вам найти компромисс между более точными, но медленными конфигурациями.

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

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

Возможно, вы спросите: «Если LLM не может дать правильный ответ, как мы можем ему доверять в оценке этого же ответа? Не будет ли это приводить к предвзятости в пользу его собственного вывода?» Действительно, это звучит контринтуитивно, но основная идея состоит в том, что оценка проще, чем генерация. Рассмотрим аналогию создания и оценки картины. При создании картины вам нужно одновременно учесть несколько свойств, таких как композиция, цвет, перспектива, свет и тень, текстура, задуманное послание и т.д. Оценка же картины позволяет сосредоточиться на одном свойстве за один раз; проще судить о готовом произведении, чем создавать его с нуля. Та же идея применима к LLM: генерация правильного ответа может быть сложной, но критическая оценка существующего ответа более проста. Оценка становится еще более возможной, если имеется эталонный ответ, например, для свойства Фактическая согласованность.

Описание фреймворка оценки приложения LLM

Давайте свяжем все вместе в этом заключительном разделе. Ниже показан обзор фреймворка оценки и иллюстрирована важная обратная связь:

1. LLM приложение, свойства и тестовые случаи передаются Оценщику, который проходит по всем тестовым случаям и передает входные данные тестов через LLM приложение. Полученные результаты затем оцениваются путем прохода по свойствам и сбора результатов в виде метрик.
2. Оценочные результаты сохраняются для дальнейшего анализа. Помимо метрик, также важно отслеживать конфигурацию LLM приложения (то есть используемый LLM и параметры, используемые компоненты RAG и параметры, системные подсказки и т.д.), чтобы можно было легко отличить наиболее перспективные эксперименты и получить идеи для дальнейшего улучшения приложения. Вы можете сохранить результаты оценки и конфигурацию LLM приложения в вашей собственной базе данных или использовать инструменты, такие как MLflow, которые предоставляют непосредственный доступ к удобному пользовательскому интерфейсу.
3. Когда вы удовлетворены производительностью, вы можете выпустить новую версию вашего приложения, либо для внутренних, либо для внешних пользователей.
4. На начальных этапах проекта это будут разработчики, которые тестируют и собирают отзывы. Позднее отзывы могут быть собраны у конечных пользователей, либо напрямую (утверждения/отказы, и письменные отзывы), либо косвенно (обороты ввода-вывода, продолжительность сессий, принятые предложения кода и т.д.).
5. Расширьте набор тестов путем анализа поступающих отзывов и добавления тестовых случаев для ситуаций, которые недостаточно представлены и не обрабатываются хорошо текущей моделью.
6. Видите тенденции в поступающих отзывах и превращайте их в улучшения приложения LLM. В зависимости от ситуации, вы можете улучшить оркестратор (например, создать цепочку отдельных вызовов LLM вместо одного запроса), процесс извлечения (например, улучшить векторные представления) или саму LLM (например, изменить модель, параметры или даже провести микронастройку).

Для наглядности шагов 1 и 2, рекомендуется ознакомиться с этим Jupyter notebook. В ноутбуке иллюстрируются концепции, объясненные в этой статье блога. Вы сможете увидеть, как определяются свойства, тестовые случаи и версии LLM приложений, а также как они отправляются на оценку. Помимо печати результатов оценки, они также регистрируются в панели управления MLflow для дальнейшего анализа. Обязательно загляните туда, это сделает обсуждаемые темы еще более конкретными.

Заключение

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

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

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

Примечание автора: Вдохновение к этому блог посту я черпал из своего опыта в качестве архитектора решений в Radix. Radix – бельгийская компания по искусственному интеллекту, специализирующаяся на разработке инновационных решений машинного обучения и приложений для различных отраслей. Если вас интересуют приложения на основе LLM, я приглашаю вас посетить сайт radix.ai или связаться со мной лично через LinkedIn.

Если не указано иное, все изображения принадлежат автору.