Проверка качества ответов LLM

Убедительно ≠ правильно

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

Метрики и критерии по типу артефакта QA

Практический scorecard для ревью набора тест-кейсов

Оценочная карта (Scorecard) — чек-лист «да/нет» по критериям для быстрого ревью черновика; отличается от рубрики 0–2, где каждый критерий оценивается баллом. Определение — в Приложении A.

Используйте как напоминание при ревью LLM‑черновика:

Пример: оцениваем тест-кейс по scorecard

Исходный тест-кейс (сгенерированный LLM):

Оценка по scorecard:

• Привязан к требованию? Нет — нет ссылки на номер требования. → Исправление: добавить «Требование: AUTH-01».
• Предусловия однозначны? Нет — «пользователь существует» расплывчато (роль? верификация?). → Исправление: «Существует активный пользователь с ролью customer, email: test@example.com, пароль: Test1234!».
• Шаги воспроизводимы? Нет — «ввести данные» без конкретики. → Исправление: явно указать email и пароль из предусловий.
• Ожидаемый результат измерим? Нет — «входит в систему» неконкретно. → Исправление: «Отображается страница /dashboard с приветствием "Добро пожаловать, Test User"».
• Нет дублей? Допустим, после сверки с реестром — да.
• Нет несуществующих элементов? Допустим, шаги реалистичны — да.

Итог до правок: мало пунктов из шести — статус ❌ Переделать. После правок при полном прохождении критериев — ✅ Принят; по совокупности таких кейсов дальше имеет смысл считать индекс пригодности (IP) — см. ниже в этой главе.

Как наращивать golden dataset (практический минимум)

Golden dataset — набор пар «вход (контекст + промпт) → эталонный или явно одобренный вывод», на котором вы проверяете регрессии качества после смены модели или правок промпта.

1. Начните с 5–10 реальных задач, где вы уже делали эталон вручную (тест-кейсы, баг-репорт, разбор требований).
2. Для каждого примера зафиксируйте: контекст, полный промпт (RTCCO), эталонный вывод, критерии «что обязательно должно быть в ответе».
3. Прогоняйте новую версию промпта / модели → сравнивайте с эталоном → записывайте проход / частичный проход / провал по критериям.
4. Пополняйте набор при появлении новых типов задач; раз в квартал выбрасывайте устаревшие эталоны.

Типовые паттерны деградации качества

Индекс пригодности (IP) для быстрой числовой оценки партии

Для черновиков одного типа (например тест-кейсов) удобно считать долю принятых без существенных правок:

IP = (кейсов или артефактов принято как готовые или с точечными правками) / (всего в партии) × 100%

• IP > 80% — как правило, промпт и контекст в хорошей зоне.
• IP 50–80% — есть систематические дыры: усиливайте ограничения, примеры, формат.
• IP < 50% — возвращайтесь к постановке задачи (RTCCO, декомпозиция, объём контекста, смена модели).

Как оценивать качество ответа LLM по рубрике

Почему «на глаз» — плохой способ проверки

LLM хорошо умеют формулировать правдоподобные и уверенные ответы.
Из-за этого человек легко принимает удобный текст за корректный артефакт, особенно если он красиво оформлен и структурирован.
Для тестировщика это опасно, потому что неверный, но «убедительный» результат быстро попадает в тест-кейсы, документацию, отчёты и черновики автотестов.

Поэтому хороший ответ нужно проверять не по ощущению, а по рубрике.

Базовый чек-лист оценки артефакта

Единый набор из шести критериев (вместо отдельных «пяти вопросов» и дублирующей рубрики):

Мини-рубрика 0–2

Пример заполненной рубрики

Задача: черновик одного тест-кейса «Оплата картой — успешный сценарий» по AC-3.1 из ТЗ.

Фрагмент ответа модели:

1. Открыть приложение. 2. Добавить товар. 3. Оплатить картой. 4. Убедиться, что заказ создан.

Сумма: 8 баллов — частично полезный черновик: доработать промпт (формат, негативы, ссылка на AC) или дописать шаги вручную.

Как читать «1 = частично»: для конкретности это «шаги в целом понятны, но без данных для воспроизведения»; для трассируемости — «есть намёк на требование, но нет явной ссылки на пункт ТЗ».

Golden dataset и eval-подход

Если один и тот же промпт используется повторно, оформите набор из блока «Как наращивать golden dataset» как регрессионный контроль: eval pipeline — тот же промпт по эталонным примерам, сравнение с критериями, фиксация проход/провал.

Типовой набор для QA может включать:

• 10–30 типовых требований;
• примеры баг-репортов;
• короткие фрагменты логов;
• запросы на генерацию тестовых данных;
• эталонные требования к формату ответа.

Дальше вы можете:

1. Запустить один и тот же промпт по набору кейсов.
2. Сравнить результаты разных моделей.
3. Проверить прохождение минимальных quality gates (контрольных точек качества: согласованный порог, ниже которого результат не принимается без доработки).
4. Отслеживать деградацию после изменения промпта или модели.

Схема eval-подхода

Когда стоит автоматизировать оценку

Автоматизация eval особенно полезна, если:

• промпт используется всей командой;
• вы сравниваете несколько моделей;
• есть CI/CD для Prompt Ops;
• важна стабильность результата после обновлений;
• вы хотите заранее ловить регрессии качества.

Ключевые критерии верификации

Использование LLM в тестировании создает новую задачу: как проверить качество и достоверность ответа, сгенерированного машиной? Принцип "Garbage In, Garbage Out" остаётся первостепенным техническим риском.

1. Сверка с первоисточником. Самый надёжный способ. Если модель сгенерировала тест-кейсы, каждый шаг должен быть привязан к конкретному пункту в требованиях.
2. Использование чек-листа качества. Стандарт для всех LLM-артефактов:
   • Полнота и охват (Completeness & Coverage)
   • Непротиворечивость (Consistency)
   • Корректность (Correctness)
   • Соответствие стандартам (Compliance)
   • Практическая применимость (Practicality)
3. Использование инструментов оценки. Microsoft предлагает библиотеки Microsoft.Extensions.AI.Evaluation, Azure AI Content Safety (Groundedness detection).
4. Внедрение самоконтроля в промпт.

   Перед окончанием, оцени свою уверенность в корректности этого ответа (Высокая/Средняя/Низкая) и перечисли все допущения, которые были сделаны при создании ответа.

Чек-лист для проверки LLM-артефактов

Быстрая версия (да/нет): пройдитесь по базовому чек-листу из шести критериев или по scorecard для тест-кейсов.

Версия с весами (единый порядок критериев):

Процесс верификации

Промпт для самопроверки

Роль: Ты — senior QA-инженер, выполняющий ревью тестовой документации

Задача: Проведи ревью предоставленных тест-кейсов на соответствие требованиям и выяви проблемы

Контекст:
Требования: [Вставьте требования]
Тест-кейсы: [Вставьте сгенерированные тест-кейсы]

Чек-лист:
1. Полнота покрытия AC (каждый AC имеет минимум 1 тест)
2. Наличие негативных сценариев (минимум 30% от общего числа)
3. Наличие граничных значений для числовых/строковых полей
4. Конкретность шагов (не "ввести данные", а "ввести 'test@email.com'")
5. Отсутствие дублирования сценариев
6. Трассировка к AC
7. Корректность приоритетов

Формат вывода:
Таблица: | Критерий | Статус | Комментарий | Рекомендация |
Общий вердикт: Ready / Needs Revision

Роль: Ты — senior QA-инженер, выполняющий ревью тестовой документации Задача: Проведи ревью предоставленных тест-кейсов на соответствие требованиям и выяви проблемы Контекст: Требования: [Вставьте требования], Тест-кейсы: [Вставьте сгенерированные тест-кейсы] Чек-лист: 1. Полнота покрытия AC, 2. Наличие негативных сценариев (мин 30%), 3. Граничные значения, 4. Конкретность шагов, 5. Отсутствие дублирования, 6. Трассировка к AC, 7. Корректность приоритетов. Формат вывода: Таблица: | Критерий | Статус | Комментарий | Рекомендация |. Общий вердикт: Ready / Needs Revision.

Автоматизация оценки

import json
def validate_llm_output(output_string, schema):
    try:
        data = json.loads(output_string)
        # Проверка по схеме...
        return {"valid": True, "score": 100}
    except json.JSONDecodeError as e:
        return {"valid": False, "error": str(e), "score": 0}

Для текстовых артефактов (мета-оценка):

Ты — QA-автоматизатор. Оцени качество тест-кейса по критериям: Наличие всех обязательных полей, Конкретность шагов, Проверяемость результата. Выведи оценку (Да/Нет/Частично) и рекомендацию.

Уровни осведомлённости о промпт-инженерии в QA

Definition of Done (DoD) — список критериев, при выполнении которых задача в команде считается завершённой. Правила приёмки LLM-артефактов в DoD разбираются в главе 11; командный реестр промптов — в главе 12.