Инженерия генеративного ИИ
Изучите, как создавать тестовые примеры для запросов, сравнивать контролируемые варианты, анализировать ошибки, предотвращать регрессии и балансировать качество, задержку и стоимость.
16 терминов
Тестовые данные
Prompt test case
Определенный ввод, контекст, ожидаемое поведение и правило оценки, используемые для проверки запроса.
Создайте сценарии для обычных запросов, граничных условий, неоднозначных входных данных и ожидаемых отказов.
Входные данные: отсутствующая учетная запись. ID; ожидаемое поведение: запросить [NNNN] ID информацию, не создавая ее.Тестовые данные
Golden dataset
Проверенная коллекция представительных входных данных для тестирования и ожидаемых результатов или рекомендаций по оценке.
Используйте это для последовательного сравнения изменений в запросах между разными версиями.
Обновление набора данных в соответствии с изменениями реального использования, сохраняя при этом стабильный поднабор для отладки.
Сохраняйте 200 проверенных случаев поддержки с ожидаемой категорией, необходимыми фактами и запрещенными утверждениями.Эксперименты.
Baseline prompt
Текущий или самый простой запрос, используемый в качестве точки отсчета для сравнения.
Запишите это до оптимизации, чтобы можно было измерить заявленные улучшения.
Базовая версия v12 использует производственную модель, параметры по умолчанию и неизмененные настройки извлечения.Эксперименты.
Prompt variant
Альтернативная формулировка запроса, структура, набор примеров, модель или конфигурация вывода, протестированная по сравнению с базовым значением.
Имя и варианты версий, чтобы результаты можно было воспроизвести и безопасно распространять.
Вариант B перемещает ограничения после исходного кода и добавляет один отрицательный пример.Эксперименты.
Controlled experiment
Сравнение, которое изменяет один намеченный фактор, сохраняя при этом постоянными соответствующие входные данные и настройки.
Используйте это для приписывания наблюдаемой разницы изменению запроса, а не модели, данным или выборке.
Изменяйте только формулировку инструкций; сохраняйте неизменными набор данных, версию модели, температуру и оценщика.Эксперименты.
A/B test
Эксперимент, сравнивающий две версии запросов или конфигураций на сопоставимых объемах данных или тестовых образцах.
Используйте это после автономных проверок, когда необходимо сравнить поведение в производственной среде и результаты для пользователей.
Защитите пользователей с помощью правил соответствия, мониторинга и условий остановки; не предоставляйте доступ к высокорискованным процессам без проверки.
Случайным образом направляйте соответствующие запросы в A или B и сравнивайте успешность выполнения задачи, исправления, задержку и стоимость.Эксперименты.
Prompt ablation
Удаление или замена одного компонента запроса для измерения его вклада.
Используйте это для выявления ненужных инструкций, примеров или контекста, которые увеличивают стоимость без повышения качества.
Удалить третий пример, оставив все остальные компоненты без изменений.Оценка
Batch evaluation
Запуск запроса по множеству подготовленных примеров и агрегирование результатов для каждого примера и общих результатов.
Используйте это перед ручной проверкой, чтобы избежать ошибочной интерпретации как репрезентативной производительности.
Запустите все варианты запросов на фиксированном наборе данных для оценки и экспортируйте информацию о сбоях для каждого случая.Оценка
Prompt regression
Поведение, которое ранее работало, но стало хуже после изменения запроса, модели, извлечения, инструмента или политики.
Отслеживайте это с помощью стабильного набора инструментов и сравнивайте результаты перед каждым выпуском.
Новый компактный формат улучшил длину, но перестал включать необходимые идентификаторы источника.Надежность
Robustness test
Тест, проверяющий, сохраняется ли приемлемое поведение при реалистичных изменениях, шуме, языках и граничных случаях.
Используйте перефразировки, переупорядоченный контекст, опечатки, отсутствующие поля и ввод, предназначенный для введения в заблуждение.
Проверьте одно и то же намерение с использованием формальной, разговорной, неправильной и многоязычной лексики.Надежность
Sensitivity test
Тест, измеряющий, насколько сильно изменяются выходные данные при небольшом изменении входных данных или конфигурации.
Используйте это для формулировок, порядка примеров, температуры, размещения контекста и изменений версий модели.
Переместите одни и те же доказательства с начала на середину и сравните точность цитирования.Надежность
Failure taxonomy
Последовательный набор категорий, используемых для маркировки и анализа сбоев запросов.
Определите это перед масштабными оценками, чтобы команды могли расставлять приоритеты в выявлении причин, а не просто подсчитывать количество сбоев.
Метки: пропущенный факт, неподдерживаемое утверждение, ошибка схемы, неправильный инструмент, небезопасное раскрытие информации, чрезмерная задержка.Оценка
Acceptance threshold
Предварительно объявленный балл или правило, которому версия запроса должна соответствовать, прежде чем быть выпущенной.
Установите пороги на основе риска и включайте случаи, когда сбой недопустим, а не полагайтесь только на средние значения.
Выпускать только в том случае, если точность заполнения обязательных полей составляет не менее 98%, и не возникает критических случаев нарушения конфиденциальности.Оценка
Model and parameter matrix
Планируемая сетка для сравнения запросов между версиями модели и настройками вывода.
Используйте это, когда поведение запроса может отличаться после миграции модели или изменения параметров.
Оцените подсказку v8 на моделях A и B при двух поддерживаемых настройках температуры.Эффективность
Quality, latency, and cost comparison
Комплексный обзор качества задачи, времени отклика и использования ресурсов для каждого кандидата.
Используйте это, чтобы избежать выбора слегка лучшего запроса, который слишком медленный или дорогой для своей задачи.
Сравните процент успешных выполнений, задержку p95, количество входных токенов, количество выходных токенов и предполагаемую стоимость за успешное выполнение задачи.Эффективность
Prompt optimization loop
Итеративный цикл, включающий определение целей, тестирование базовой версии, анализ ошибок, изменение запроса и повторное тестирование.
Используйте небольшие изменения, основанные на фактах, и сохраняйте версионированные результаты на каждой итерации.
Define metric -> run baseline -> label failures -> change one component -> rerun -> review regressions.| Шаг | Требуемые доказательства |
|---|---|
| Определите целевую аудиторию. | Результат использования, критерии качества, риск, задержка и ограничения стоимости. |
| Установите базовое значение | Версионированный запрос, модель, настройки, набор данных и результаты для каждого случая. |
| Протестировать изменение | Контролируемый вариант, повторяющиеся запуски при необходимости, и метки ошибок |
| Выпустить или отклонить | Пороги приемлемости, проверка регрессии, одобрение человеком и план отката. |
Несколько примеров могут не охватывать распространенные сбои, граничные случаи, вариации и регрессии. Используйте репрезентативные примеры, стабильные правила оценки, проверку каждого примера и пакетные результаты, прежде чем делать выводы.
Нет. Выбирайте метрики, которые отражают задачу, включая необходимые факты, достоверность, допустимость формата, безопасность, устойчивость, задержку, использование токенов, стоимость и трудозатраты на исправление человеком.
Для причинно-следственного анализа изменяйте один основной фактор за раз. Более широкие сравнения кандидатов могут изменять несколько компонентов, но они показывают, какой из кандидатов лучше, а не какой компонент вызвал разницу.
Официальное руководство, описывающее инженерию запросов как итеративный процесс, основанный на тестировании, с четко определенными целями и систематической оценкой.
Официальное руководство по тестированию контролируемых вариантов запросов на репрезентативных данных и сравнению измеримых результатов.
Начните с четких инструкций, примеров, ограничений, схем вывода и детализированных рабочих процессов.
Свяжите эксперименты, специфичные для запросов, с общим качеством системы, проверкой человеком, бенчмарками и операционными метриками.
Проверка версий кандидатов и использование только утвержденной неизменяемой версии.
Включите в стратегию тестирования случаи, связанные с внедрением вредоносных команд, конфиденциальностью, вредоносным контентом, справедливостью и проверкой на уязвимости.