Глава 10: Тестирование промптов и цепочек вызовов 🔗🧩

Есть старая шутка среди QA-инженеров: баг всегда находится не в том месте, где вы его ищете 🐞. В LLM эта шутка перестаёт быть шуткой и становится законом природы 📜. Первые два уровня тестирования — самые коварные, потому что ломаются они тихо 🤫. Ничего не падает, API отвечает, дашборды зелёные ✅. А качество при этом уезжает куда-то в сторону 🚗, и вы узнаёте об этом через неделю от недовольного пользователя 😠. Как деплой в пятницу: ничего не упало, все разошлись, а в понедельник — инциденты на весь спринт 🎲.

Первый уровень — тестирование промптов (Prompt / Unit) 🧪. Здесь тестируется отдельный промпт: системное сообщение, шаблон, few-shot примеры, параметры генерации ⚙️. LLM-приложение ломается на этом уровне тихо и почти незаметно 🤫. После обновления модели промпт, который работал идеально, начинает давать более размытые ответы, терять формат, игнорировать часть инструкций или менять тон 🌫️. Ничего не падает, API отвечает, но качество уезжает 🚂. Это регрессия промптов: раньше модель отвечала «Париж», теперь — «Париж — столица Франции, но также стоит учитывать…» 🇫🇷, и автотест на точное совпадение уже красный 🔴. На этом уровне нужны быстрые проверки на эталонных примерах, версионирование промптов и понимание, что даже смена модели с одной версии на другую может сломать поведение 🧪. Да, та самая смена, которую вы сделали «просто чтобы попробовать» 😅. Помните алгоритмы выборки из главы 5? Смена модели — это как смена температуры, только провайдер сменил её за вас 🌡️.

Второй уровень — тестирование цепочек вызовов (Chain / Integration) 🔗. Здесь проверяется последовательность вызовов. Один промпт — это легко 🍰, а цепочка из пяти — уже квест 🗺️. Модель может потерять контекст между шагами, суммаризация искажает смысл, routing выбирает не тот путь, накапливаются мелкие ошибки 🧠. Классический провал: на первом шаге модель неверно поняла запрос, на втором это замаскировалось 🎭, на третьем превратилось в другой вывод, а на пятом вы получили уверенный, красивый и абсолютно неправильный ответ 💄. Без трассировки найти место поломки почти невозможно — вы будете смотреть на финальный ответ и гадать, где именно всё пошло не так 🕵️. Обычно на первом шаге. Но узнаете вы об этом только на последнем 🤦‍♂️.

Нужны логи каждого шага, проверка промежуточных результатов и тесты на целостность всей цепочки, а не только на финальный ответ 🧾. И да, это дороже, чем один вызов, но дешевле, чем разбираться с последствиями 💸. Я помню, как мы неделю искали причину странных ответов, а оказалось, что на втором шаге суммаризатор терял отрицание 🚫. Модель честно пересказывала «клиент не подтвердил заказ» как «клиент подтвердил заказ». И это было не один раз, а в тридцати процентах случаев 📉. Трассировка показала это за минуту ⏱️. Без неё — ещё месяц 📅. Это как KV-кэш из главы 4: без закладки — всё с начала 🔄. Только тут логи, а не контекст 📑.

Что писать в лог каждого шага 📝. Вход, выход, использованную модель, температуру, количество токенов, время выполнения ⏱️. Это минимум. Хорошо бы ещё добавить номер шага в цепочке и идентификатор сессии, чтобы можно было собрать всю цепочку по одному запросу 🧩. Если шаг использует retrieval — какие документы были найдены и с какими оценками. Если шаг вызывает инструмент — какие аргументы переданы и что вернулось 🛠️. Без этого трассировка превращается в археологию 🏺.

Минимальный процесс, с которого можно начать завтра 🚀. Начните с двадцати-пятидесяти эталонных примеров 📋. Версионируйте промпты и модели 🏷️. Запускайте каждый тест несколько раз и задавайте порог, например 90% 🔁. Держите ночной прогон полного датасета 🌙. Отслеживайте тренд качества, а не только pass/fail 📊. И оставляйте место для ручной выборки спорных случаев 👀.

Немного юмора 😄. Тестирование промптов — как проверка рецепта: меняете ингредиент — блюдо другое 🥣. Только в LLM вы не знаете какой, потому что провайдер обновил модель ночью 🌙. Цепочка — конвейер: первый режет, второй жарит, третий солит 🔪. Третий перепутал соль с сахаром — узнаете, когда клиент попробует 😋. Все станции зелёные ✅.