AI QA — это не отдельная магическая профессия, а развитие классического QA в сторону систем, где результат может быть вероятностным, контекстозависимым и чувствительным к данным, prompt-ам и конфигурации модели. Здесь особенно важно сохранять инженерную строгость и не подменять тестирование “субъективным ощущением, что ответ вроде нормальный”.
Чем AI QA отличается от классического QA
- →Ответ модели может быть не детерминированным: один и тот же запрос не всегда даёт одинаковый результат.
- →Качество зависит не только от кода, но и от данных, prompt-ов, retrieval-слоя, guardrails и конфигурации модели.
- →Нужно оценивать не только корректность, но и безопасность, устойчивость, стоимость и деградацию поведения.
- →Часть проверок строится как evaluation, а не как бинарный pass/fail в привычном виде.
Какой фундамент нужен до входа в AI QA
- →Сильная база в классическом QA: риски, тест-дизайн, требования, API, системное мышление.
- →Понимание HTTP/API, логирования, данных и интеграций, потому что большинство AI-продуктов строится вокруг сервисного контура.
- →Навык формулировать критерии качества там, где нет идеальной бинарности.
- →Базовое понимание LLM, embeddings, RAG, prompt engineering и ограничений моделей.
Что тестировать в AI-системах
- →Correctness и relevance: насколько ответ соответствует задаче и контексту.
- →Safety: токсичность, leakage, jailbreak, небезопасные рекомендации, нарушение политики.
- →Robustness: как система ведёт себя на шумных, неполных, adversarial и edge-case запросах.
- →Latency и cost: качество не должно достигаться ценой неприемлемой скорости и расходов.
- →Observability: можно ли понять, почему система дала конкретный ответ и где произошёл сбой.
Какие артефакты полезны в AI QA
- →Evaluation dataset с ожидаемыми критериями качества, а не только набор красивых демо-запросов.
- →Матрица рисков по safety, privacy, hallucinations и бизнес-критичным ошибкам.
- →Лог изменений prompt-ов, моделей и retrieval-конфигурации.
- →Набор golden scenarios для smoke и regression после каждого изменения цепочки.
Частые ошибки
- →Оценивать систему только на handful of happy prompts и считать это доказательством качества.
- →Не разделять проверки модели, orchestration-логики и внешних данных.
- →Игнорировать стоимость и задержку, концентрируясь только на “умности” ответа.
- →Полагаться на субъективные впечатления вместо согласованных критериев оценки.