Глава 2. 🍄 Хоббит без карты, но с инвариантом: навигация по метаморфам 🧭

Главный вопрос нового мира: как проверять систему, у которой нет единственного правильного ответа 🤔? Ответ элегантен: если мы не знаем, каким должен быть ответ, мы можем знать, как он должен измениться 🔄. Это и есть метаморфное тестирование — подход, родившийся для задач, где оракула нет, а теперь ставший рабочим инструментом тестирования LLM. Вместо проверки «вход даёт выход X» проверяется связка «вход, изменённый известным образом, даёт выход, изменённый предсказуемо».

Примеры. Просим модель ответить кратко ✂️ — длина обязана уменьшиться, и это проверяется элементарно. Просим перевести на английский 🌍 — язык ответа должен смениться, детектор языка есть в любой библиотеке. Меняем пол персонажа в исходном тексте — упоминания пола в ответе обязаны соответствовать новому значению. Переставляем абзацы входного документа — вывод должен сохраниться. Дублируем вопрос дважды — ответ не должен измениться революционно. Ни в одном случае не нужен эталонный ответ: нужны только инварианты и монотонности. Для инженера с опытом параметризованных тестов это родная территория: метаморфная пара — просто табличный параметр с проверкой отношения, а сами пары накапливаются в библиотеку быстрее, чем эталонные ответы, потому что их не нужно согласовывать с бизнесом. А если скомбинировать несколько отношений, один сценарий порождает десятки вариаций входа — покрытие растёт почти бесплатно 🎁.

Вторая опора — контрактное тестирование, полностью выжившее из классики 💪. Если AI-сервис — это API, отдающий JSON, то схема, обязательность полей, типы, диапазоны и согласованность эндпоинтов проверяются как проверялись всегда. Более того, для LLM контракты стали строже: модель, которой обещали «верни JSON» 📐, обязана вернуть именно валидный JSON, иначе потребитель упадёт. Структура — детерминированная территория, и здесь тестировщик чувствует себя дома, как в родной квартире 🏠, где всю мебель расставил он сам.

Третья опора — специфика RAG-систем 📚, где генерация опирается на поиск по базе знаний. Здесь слой тестирования естественным образом раздваивается. Качество поиска проверяется отдельно 🔍: попадает ли релевантный документ в топ-K выдачи — метрики точности и полноты по контексту. Качество генерации — отдельно: опирается ли ответ на найденные документы и не фантазирует ли. Отдельная категория — кейсы, где нужного документа в базе просто нет: система обязана признать незнание, а не придумать ссылку с убедительной цитатой. И правило гигиены: тестовые запросы пишутся с заведомо известными «правильными» документами, чтобы проверять не красоту текста, а опору на контекст. Отдельно проверяется свежесть: не ссылается ли система на документы, устаревшие год назад, — база знаний гниёт тихо и незаметно 🍂.

Четвёртая опора — агенты, то есть системы, которые планируют шаги, вызывают инструменты и повторяют попытки 🤖. Здесь тест-кейс превращается в сценарий: достиг ли агент цели, вызвал ли правильную функцию с правильными аргументами, что сделал при падении инструмента, не закрутился ли в цикл, уложился ли в лимит шагов и бюджет токенов. Канареечные сценарии 🐤 — короткие типовые задачи — прогоняются на каждый релиз и держат руку на пульсе. Классическая история из практики: агент, поставленный отправлять письма ✉️, при недоступности почты однажды решил вопрос креативно — такие сюжеты лучше ловить тестом, чем извинением перед клиентом.

Общий вывод главы: невозможность эталона — не приговор, а смена жанра 🎭. Там, где раньше был один правильный ответ, теперь наборы инвариантов, контрактов и отношений. Тестировщик перестал быть фотографом 📸, сверяющим портрет с оригиналом, и стал криминалистом 🕵️, который ищет следы и несостыковки. Работа даже интереснее — просто баг-репорт теперь начинается со слов «ожидаемое отношение нарушено», и это надо объяснять менеджеру без пауз, с прямой спиной и без лишних эмоций на лице. Тот, кто освоил такой подход однажды, уже добровольно не вернётся к строковым сравнениям.