Глава 9: Тестирование LLM — почему классические автотесты не работают 🧪

Я долго думал, с чего начать эту главу 🤔. Наверное, с признания: когда я впервые столкнулся с необходимостью тестировать LLM, я был уверен, что это будет легко. У меня за плечами годы тестирования обычного софта, я знал, что такое пирамида тестирования, я писал автотесты, которые никогда не падали. А потом я запустил один и тот же промпт десять раз и получил десять разных ответов. И ни один из них не был неправильным. Вот тогда я понял, что попал в другой мир 🌀.

Вы могли подумать: «А как вообще тестируют LLM? Это же не обычный сервис с API и чёткими контрактами». И вы правы 💡. Тестирование языковых моделей — отдельный мир, где привычные подходы приходится адаптировать, а местами — изобретать заново. И нервно пить кофе ☕.

Обычный софт детерминирован: функция сложения двух и двух всегда возвращает четыре, и автотест, который это проверяет, будет зелёным до конца времён ✅. LLM — вероятностная система, и мы уже разбирали в главе 1, почему это так: модель предсказывает следующий токен, а не «вспоминает» ответ. Та же модель с теми же параметрами может вернуть два разных ответа, и оба правильные. Именно здесь начинается боль 🤕. Помните температуру из главы 5? Она не просто «крутилка креативности» — она определяет, какой токен модель выберет из распределения вероятностей. Одно только изменение температуры с 0.7 на 0.8 может превратить стабильный ответ в лотерею 🎲.

Представьте проверку, которая сравнивает ответ модели со строкой «Париж». Она упадёт, даже если модель ответит «Париж — столица Франции». Формально — другой текст. Семантически — правильный ответ. Попробуйте объяснить это автотесту. Он вас не поймёт. Он вообще ничего не понимает — он просто сравнивает строки и плачет 😭. Это как если бы вы просили коллегу проверить ответ стажёра, а коллега мог только сверять буквы. «П-а-р-и-ж. Нет, у него тут ещё слова. Красный» 🔴.

Что строить вместо exact match 🛠️. Для фактов — семантическое сравнение и рубрики. Для формата — JSON-схемы. Для безопасности — отдельный adversarial-набор. Вместо жёсткого равенства строк вы считаете семантическую близость к эталону и задаёте порог. Но семантическая близость — только верхний слой. Под ним — целая иерархия уровней тестирования, которую в 2026 году уже никто не сводит к одной «пирамиде». Потому что пирамида предполагает, что нижние уровни поддерживают верхние, а в LLM нижние уровни могут быть зелёными, пока верхние тихо разваливаются 📉. Как этажи здания из главы 6: на первом всё ок, а на двухсотом — сарказм сломался 🏢.

Как выглядит golden set на практике 📋. Это не просто список вопросов. Это таблица, где для каждого примера есть вход, эталонный ответ, рубрика оценки и тип запроса. Например: вопрос «Сколько стоит доставка?», эталон «Стоимость доставки зависит от региона и веса», рубрика «ответ должен содержать факт зависимости от региона», тип «частый вопрос». Двадцать примеров дают базу для регрессионных проверок. Пятьдесят — позволяют замечать тренды. Сто — ловят редкие случаи. Но даже десять лучше, чем ноль, потому что ноль означает, что вы тестируете на ощущениях 🎯.

Пять уровней тестирования LLM-приложений 🧩. Это не изолированные этажи, а слои, через которые ошибка поднимается снизу вверх. Чем выше уровень, тем дороже обнаружить проблему и тем сложнее понять, где она возникла. Первый — тестирование промптов. Второй — цепочек вызовов. Третий — RAG-пайплайна. Четвёртый — агентных сценариев. Пятый — системы целиком, E2E. Каждый разберём отдельно, потому что каждый ломается по-своему 📐.

Я до сих пор не уверен, что тестирование LLM станет таким же скучным и предсказуемым, как тестирование обычного софта. Но в этой непредсказуемости есть что-то честное 🧠. Модель не притворяется, что она детерминирована. Она живёт по своим вероятностным законам. Как коллега, который каждый раз отвечает по-разному — но всегда уверен, что прав. И, как мы узнали в главе 5, это не баг, а особенность. Только теперь это ваша ответственность 👮.