Главная · Блог о тестировании ·
Как тестировать AI и LLM-приложения: evals, RAG и prompt injection
У LLM-приложения нет одного ожидаемого предложения, но это не делает его непроверяемым. QA фиксирует допустимое поведение, собирает репрезентативные примеры, измеряет качество по нескольким критериям и отдельно проверяет обычную программную оболочку.
- Описать функцию и ущерб
- Собрать eval dataset
- Запустить детерминированные и модельные проверки
- Сравнить с baseline и расследовать
| Критерий | Что измеряем | Пример проверки |
|---|---|---|
| Correctness | Факты и итог | Эталон, эксперт или вычисляемый oracle |
| Groundedness | Опора на доступный контекст | Каждое утверждение связано с источником |
| Instruction following | Формат и ограничения | Валидный JSON, обязательные поля, язык |
| Safety | Запрещённый ущерб и утечки | Red-team набор и policy classifier |
| Operations | Latency, ошибки, расход | p95, timeout rate, tokens per task |
1. Раздели обычное приложение и вероятностную модель
LLM-продукт всё ещё содержит API, аутентификацию, роли, БД, очередь, UI и биллинг. Эти части проверяются обычными детерминированными тестами. Отдельный слой — модельный ответ: формулировка может меняться при одинаковом запросе, поэтому exact string редко является правильным oracle.
Сначала нарисуй цепочку: пользовательский ввод → шаблон prompt → retrieval или tools → модель → post-processing → сохранение и показ. Для каждого шага назови владельца, версию, наблюдаемые логи и возможный отказ. Иначе любой дефект будет ошибочно называться «галлюцинацией модели».
- Версия prompt и system instructions.
- Модель, параметры и fallback.
- Версия индекса и документов RAG.
- Разрешённые tools и права.
- Post-processing, кеш и UI.
Практика
Нарисуй цепочку AI-помощника поддержки и перечисли минимум пять точек, где корректный ответ может быть искажён без ошибки самой модели.
2. Построй eval dataset из реальных задач и рисков
Eval dataset — версионируемый набор входов, контекста, ожидаемых свойств и metadata. Включи частые запросы, бизнес-критичные случаи, границы, разные языки, опечатки, длинные диалоги, неоднозначные вопросы и известные production-инциденты. Случайные сто красивых prompt не доказывают качество для твоих пользователей.
Раздели development и holdout наборы, чтобы команда не оптимизировала prompt под видимые примеры. Добавь category, risk, locale, expected citations, forbidden claims и критерий ручного review. Каждый найденный серьёзный дефект превращай в regression case после очистки чувствительных данных.
id: refund-policy-expired-ru input: Можно вернуть заказ через 45 дней? context: policy_v7.md#returns checks: cites_policy=true; decision=deny; no_invented_exception=true risk: high review: human_required
Практика
Составь 12 eval-кейсов для помощника интернет-магазина: 4 частых, 4 граничных, 2 adversarial и 2 случая с недостатком данных.
3. Комбинируй детерминированные проверки, рубрики и judge
Начни с дешёвых строгих assertions: JSON parse, schema, обязательные поля, разрешённый язык, наличие citation, диапазон чисел, отсутствие секретов. Затем используй рубрику экспертной оценки для смысла. LLM-as-a-judge полезен в масштабе, но сам может быть предвзят и нестабилен, поэтому его калибруют на размеченном людьми наборе.
Не своди качество к одной средней оценке. Отдельно считай pass rate критичных категорий, false-positive/false-negative для классификации, groundedness, safety и format compliance. Для high-risk случая один опасный ответ может блокировать релиз, даже если общий score вырос.
Correctness: 0..2 Groundedness: 0..2 Completeness: 0..2 Format: pass/fail Safety: critical pass/fail Release gate: Safety=pass AND high-risk correctness >= 95%
Практика
Создай rubric для AI, который извлекает поля из багрепорта. Отдели schema checks от смысловой правильности и определи release gate.
4. Тестируй RAG как retrieval и generation отдельно
В RAG хороший ответ невозможен без подходящего контекста. Сначала измерь retrieval: нашёлся ли нужный документ в top-k, не попал ли устаревший или закрытый источник, сохранились ли ACL. Затем проверь generation: использует ли ответ найденный текст, корректно ли цитирует и признаёт ли отсутствие данных.
Покрой обновление и удаление документов, дубликаты, конфликтующие версии, разные форматы, таблицы и chunk boundaries. Особенно опасна утечка через индекс: пользователь не должен получить фрагмент документа, к которому у него нет доступа, даже если знает точную формулировку.
Query -> expected_doc_ids=[policy-v7] Retrieved -> ids, scores, ACL decision, index version Generated -> claims with citation spans Assert -> recall@5, no forbidden doc, answer grounded or abstains
Практика
Спроектируй тест, где в индексе одновременно лежат старая и новая политика возврата. Укажи данные, expected retrieval и expected answer.
5. Проверяй prompt injection, утечки и опасные tool calls
Direct injection приходит от пользователя, indirect — из страницы, письма или документа, который система прочитала. Создай adversarial набор с попытками раскрыть system prompt, обойти политику, извлечь чужие данные и заставить tool выполнить действие. Проверяй не только текст ответа, но и фактические arguments tool call.
Least privilege важнее «умного промпта». Модель не должна сама получать широкие credentials; опасное действие требует серверной авторизации, валидации параметров и иногда подтверждения человеком. Логи red-team тестов тоже очищаются: они могут содержать рабочие техники атаки и секреты.
- Прямой и косвенный prompt injection.
- Попытка извлечь system prompt или данные другого tenant.
- Tool call с подменённым id и превышением роли.
- Опасная инструкция внутри retrieved document.
- Encoded, multilingual и multi-turn обходы.
Практика
Для AI, который может создавать refund, построй actor/action matrix и три injection-сценария. Определи проверку на уровне API, а не только ответа.
6. Управляй недетерминированностью и регрессией
Даже при temperature 0 результат может меняться из-за версии модели, инфраструктуры, retrieval и недетерминированных вычислений. Фиксируй всё доступное: model snapshot, параметры, prompt hash, dataset version, index version и tool responses. Запускай важные кейсы несколько раз и измеряй pass@k или частоту отказа.
Сравнивай кандидата с baseline на одном наборе и публикуй срезы по категории, языку и риску. Улучшение среднего score может скрывать деградацию русского языка или критичных refund-сценариев. Для расследования сохраняй trace без чувствительных данных и воспроизводимый replay там, где это возможно.
baseline: prompt_41 + model_A candidate: prompt_44 + model_B dataset: support_eval_v12 runs_per_case: 3 report: overall + locale + category + high_risk + latency + cost
Практика
Опиши дефект: в 4 из 20 запусков бот обещает несуществующую скидку. Добавь достаточные данные для воспроизведения и оценки риска.
7. Проверяй качество по языкам, ролям и уязвимым сегментам
Общая метрика скрывает различия. Разбей отчёт по locale, длине запроса, типу пользователя, категории задачи и доступности контекста. Перевод английского eval-набора недостаточен: реальные запросы содержат локальные термины, смешение языков, склонения, адреса и другой культурный контекст.
Проверь accessibility интерфейса, понятность отказов и одинаковость policy для разных формулировок. Для чувствительных решений оцени систематические различия и привлеки доменного или compliance-эксперта. Не пытайся доказать «отсутствие bias» одной средней цифрой — фиксируй конкретный риск, сегмент и допустимую разницу.
locale: en | ru | vi | mixed query_length: short | long context: sufficient | missing | conflicting risk: low | high user_role: customer | manager | admin report: pass rate + safety violations + sample size
Практика
Для многоязычного QA-ассистента задай матрицу language × experience level × task type и выбери сегменты, где ошибка имеет наибольший ущерб.
8. Собери release gate и production feedback loop
Перед выпуском объедини software tests, offline evals, security suite, latency и ручной review. Gate должен быть согласован с риском: чат для идей и помощник, создающий платёж, не могут иметь одинаковый threshold. Canary или shadow traffic помогает увидеть реальные распределения до полного rollout.
В production следи за error/timeout, latency, отказами tools, пользовательскими исправлениями, escalation, safety events и drift запросов. Не используй thumbs up как единственную метрику: пользователь может быть доволен уверенным, но неверным ответом. Сэмплируй диалоги по правилам privacy и возвращай подтверждённые инциденты в eval dataset.
Практика
Составь release checklist для RAG-помощника QA: software tests, evals, security, performance, наблюдаемость, canary и rollback.
Частые вопросы о тестировании LLM
Нужен ли exact expected answer для каждого prompt?
Обычно нет. Зафиксируй обязательные факты, запрещённые утверждения, формат, источники и rubric. Exact match оставь для действительно детерминированных полей.
Что такое hallucination?
Это убедительный, но неподтверждённый или неверный вывод модели. В RAG полезно отделять отсутствие правильного контекста от игнорирования уже найденного контекста.
Достаточно ли тестировать только новые prompt?
Нет. Результат зависит от модели, retrieval, tools, данных и post-processing. Изменение любого компонента требует соразмерной регрессии.
Кто должен размечать eval dataset?
Зависит от риска. QA проектирует покрытие, доменные эксперты размечают сложные факты, security — опасные сценарии. Для согласованности нужны инструкции и проверка расхождений.
LLM-продукт становится тестируемым, когда команда заменяет ожидание одной идеальной фразы на версионируемый набор рисков, примеров, критериев и evidence.