При создании запросов для реальных приложений возникает ключевой компромисс: баланс между краткостью и эффективностью. При прочих равных условиях краткий запрос быстрее, дешевле и проще в обслуживании, чем длинный. Это особенно актуально в веб-средах, где важны задержка и ограничения по токенам. Однако, если ваш запрос слишком минималистичен, модели может не хватать контекста, инструкций или примеров для получения высококачественных результатов.
Разработка, основанная на оценке (EDD), позволяет систематически отслеживать и оптимизировать этот компромисс. Она предлагает повторяемый, проверяемый процесс улучшения результатов небольшими и уверенными шагами, выявления регрессий и согласования поведения модели с ожиданиями пользователей и продукта с течением времени.
Рассматривайте это как разработку через тестирование (TDD) , адаптированную к неопределенности, присущей искусственному интеллекту. В отличие от детерминированных модульных тестов, оценки ИИ нельзя жестко запрограммировать, поскольку результаты, как корректные, так и некорректные, могут принимать неожиданные формы.
EDD также поддерживает ваши усилия по исследованию. Подобно тому, как написание тестов помогает прояснить поведение функции, определение критериев оценки и анализ результатов модели заставляют вас сталкиваться с неясностью и постепенно добавлять больше деталей и структуры к открытым или незнакомым задачам.
Определите проблему.
Вы можете сформулировать свою задачу в виде контракта API, указав тип входных данных, формат выходных данных и любые дополнительные ограничения. Например:
- Тип ввода: черновик записи в блоге
- Формат вывода: массив JSON с тремя заголовками постов.
- Ограничения: менее 128 символов, дружелюбный тон.
Затем соберите примеры входных данных. Для обеспечения разнообразия данных включите как идеальные примеры, так и реальные, неструктурированные входные данные. Подумайте о вариациях и крайних случаях, таких как сообщения с эмодзи, вложенная структура и большое количество фрагментов кода.
Инициализация базового уровня
Напишите свою первую подсказку. Вы можете начать с нулевого задания и включить в него:
- Четкая инструкция
- Формат вывода
- Заполнитель для входной переменной
При оценке и оптимизации вы увеличиваете сложность и взаимодействуете с другими компонентами и передовыми методами управления. Прежде всего, нам необходимо создать систему оценки, чтобы направить усилия по оптимизации в нужное русло.
Создайте свою систему оценки
В TDD вы начинаете писать тесты, как только узнаете требования. В генеративном ИИ нет определённых результатов для тестирования, поэтому вам нужно приложить больше усилий к созданию цикла оценки.
Для эффективной оценки вам, вероятно, потребуется несколько измерительных инструментов.
Определите критерии оценки.
Метрики оценки могут быть детерминированными. Например, вы можете проверить, возвращает ли модель корректный JSON или выводит правильное количество элементов.
Однако значительную часть времени следует посвятить выявлению и уточнению субъективных или качественных показателей, таких как ясность, полезность, тон или креативность. Вы можете начать с общих целей, но быстро столкнуться с более тонкими вопросами.
Например, предположим, что ваш генератор заголовков слишком часто использует определенные фразы или шаблоны, что приводит к повторяющимся, шаблонным результатам. В этом случае вам следует определить новые метрики, чтобы стимулировать разнообразие и избегать чрезмерного использования структур или ключевых слов. Со временем ваши основные метрики стабилизируются, и вы сможете отслеживать улучшения.
В этом процессе могут помочь эксперты, которые понимают, что значит хорошая работа в предметной области вашего приложения, и могут выявлять скрытые причины сбоев. Например, если вы разрабатываете помощника для написания текстов, сотрудничайте с контент-менеджером или редактором, чтобы ваша оценка соответствовала их взглядам.
Выберите судей.
Различные критерии оценки требуют разных экспертов:
- Проверки на основе кода хорошо подходят для детерминированных или основанных на правилах результатов. Например, вы можете сканировать заголовки на наличие слов, которые хотите исключить, проверять количество символов или валидировать структуру JSON. Они быстрые, воспроизводимые и идеально подходят для элементов пользовательского интерфейса с фиксированным результатом, таких как кнопки или поля форм.
- Обратная связь от пользователей необходима для оценки более субъективных качеств, включая тон, ясность или полезность. Особенно на ранних этапах самостоятельный анализ результатов работы модели (или с помощью экспертов в данной области) позволяет быстро вносить изменения. Однако такой подход плохо масштабируется. После запуска приложения можно также собирать внутриигровые сигналы, такие как оценка в виде звезд, но они, как правило, содержат много шума и не обладают необходимой для точной оптимизации детализацией.
- Использование модели LLM в качестве судьи предлагает масштабируемый способ оценки субъективных критериев с помощью другой модели ИИ для выставления оценок или критики результатов. Это быстрее, чем проверка человеком, но не лишено недостатков: при наивной реализации это может увековечить и даже усилить предвзятость и пробелы в знаниях модели.
Приоритет отдается качеству, а не количеству. В классическом машинном обучении и прогнозном ИИ распространенной практикой является краудсорсинговая аннотация данных. В генеративном ИИ аннотаторам, использующим краудсорсинг, часто не хватает контекста предметной области. Высококачественная, контекстно-ориентированная оценка важнее масштаба.
Оцените и оптимизируйте.
Чем быстрее вы сможете тестировать и дорабатывать свои запросы, тем быстрее вы получите результат, соответствующий ожиданиям пользователей. Вам необходимо выработать привычку к непрерывной оптимизации. Попробуйте улучшить, оцените результат и попробуйте что-то другое.
После запуска в производство продолжайте наблюдать и оценивать поведение пользователей и вашей системы искусственного интеллекта. Затем проанализируйте и преобразуйте эти данные в шаги по оптимизации.
Автоматизируйте процесс оценки.
Для снижения трения в процессе оптимизации вам необходима операционная инфраструктура, которая автоматизирует оценку, отслеживает изменения и связывает разработку с производством. Это обычно называют LLMOps. Хотя существуют платформы, которые могут помочь с автоматизацией, вам следует разработать оптимальный рабочий процесс, прежде чем принимать решение о приобретении стороннего решения.
Вот некоторые ключевые компоненты, которые следует учитывать:
- Версионирование : храните подсказки, метрики оценки и входные данные для тестов в системе контроля версий. Рассматривайте их как код, чтобы обеспечить воспроизводимость и четкую историю изменений.
- Автоматизированная пакетная оценка : используйте рабочие процессы (например, GitHub Actions) для запуска оценки при каждом обновлении запроса и создания отчетов о сравнении.
- CI/CD для запросов : контроль развертывания с автоматическими проверками, такими как детерминированные тесты, оценки LLM в качестве эксперта или ограничительные условия, и слияние блоков при снижении качества.
- Ведение журналов и мониторинг производственной среды : фиксация входных и выходных данных, ошибок, задержек и использования токенов. Мониторинг отклонений, неожиданных закономерностей или всплесков сбоев.
- Сбор обратной связи : сбор сигналов от пользователей (лайки, предложения по изменению, отказ от использования) и преобразование повторяющихся проблем в новые тестовые примеры.
- Отслеживание экспериментов : отслеживание версий подсказок, конфигураций моделей и результатов оценки.
Вносите небольшие, целенаправленные изменения итеративно.
Как правило, доработка подсказки начинается с улучшения её формулировки. Это может означать уточнение инструкций, разъяснение сути вопроса или устранение двусмысленностей.
Будьте осторожны, чтобы не переобучить модель. Распространенная ошибка — добавление слишком узких правил для исправления проблем модели. Например, если ваш генератор заголовков постоянно выдает заголовки, начинающиеся с «The Definitive Guide» , может возникнуть соблазн явно запретить эту фразу. Вместо этого, абстрагируйте проблему и скорректируйте инструкцию более высокого уровня. Это может означать, что вы делаете акцент на оригинальности, разнообразии или определенном стиле редактирования, чтобы модель изучала базовые предпочтения, а не единичное исключение.
Другой путь — экспериментирование с различными методами подсказок и их сочетание. Выбирая тот или иной метод, задайте себе вопрос: лучше ли решать эту задачу с помощью аналогии (метод «нескольких попыток»), пошагового рассуждения (метод «цепочки мыслей») или итеративного уточнения (метод саморефлексии)?
Когда ваша система будет запущена в производство, ваш механизм EDD не должен замедляться. Наоборот, он должен ускориться. Если ваша система обрабатывает и регистрирует пользовательский ввод, это должно стать вашим самым ценным источником информации. Добавьте повторяющиеся шаблоны в свой набор инструментов оценки и постоянно выявляйте и внедряйте следующие оптимальные шаги по оптимизации.
Ваши выводы
Разработка подсказок, основанная на оценке, предоставляет структурированный способ преодоления неопределенности, связанной с ИИ. Четко определив проблему, создав индивидуальную систему оценки и внося небольшие целенаправленные улучшения, вы формируете цикл обратной связи, который постоянно улучшает результаты работы модели.
Ресурсы
Вот несколько рекомендуемых материалов для чтения, если вы хотите использовать систему LLM в качестве судьи:
- Сравните возможности LLM с возможностями суммирования .
- Ознакомьтесь с руководством Хамеля Хусейна по использованию степени магистра права в качестве судьи .
- Ознакомьтесь с работой: «Обзор практики получения степени магистра права в качестве судьи» .
Если вас интересует дальнейшее улучшение ваших подсказок, почитайте подробнее о разработке с учетом контекста . Лучше всего этим займется инженер по машинному обучению.
Проверьте свое понимание
Какова основная цель разработки, основанной на оценке?
Зачем использовать более крупные модели для оценки системы на стороне клиента?
В чём потенциальный недостаток использования магистра права в качестве судьи при оценке?
Какой компонент входит в состав рекомендуемого автоматизированного конвейера оценки?
При выборе судей для вашей системы оценки, в чем заключается основное ограничение использования отзывов людей?