Хватит проверять нейросети нейросетями: почему мы вынесли контроль качества LLM в жесткий код
Уверенный ответ LLM больше не означает, что ваш AI-продукт работает качественно.
На выходе с актуальными моделями сегодня очень легко получить связный, красивый и убедительный текст. Но эта связность ничего не говорит о достоверности, логике и полноте результата. При проектировании пайплайна сервиса UX-аудита в TONSA я упёрся в классическую проблему LLM Ops: как системно проверить результат работы модели, не отправляя его на ещё один круг к другой, такой же галлюцинирующей модели?
Внутри нашего продукта работает сложный агентный pipeline:
- Система собирает данные со страниц и анализирует паттерны интерфейса.
- Выявляет неочевидные UX-барьеры.
- Готовит конкретные рекомендации и складывает их в продуктовый бэклог.
На каждом из этих этапов нейросеть может ошибиться: забыть учесть найденный барьер, нарушить структуру JSON или выдать логическое противоречие.
Иллюзия контроля LLM-as-a-judge
Стандартный ответ рынка на такие проблемы — внедрить схему LLM-as-a-judge (когда одна нейросеть проверяет результаты другой). Проблема в том, что такая проверка всё равно остаётся вероятностной. Вы пытаетесь контролировать хаос с помощью другого хаоса.
Поэтому для контроля полноты и согласованности мы полностью отказались от ИИ-судей в пользу отдельного детерминированного eval-слоя на чистом Python.
Как устроен детерминированный контур
Вместо того чтобы спрашивать у модели: «А точно ли ты всё учла?», мы прогоняем финальный результат через жесткие, повторяемые правила кода. Этот eval-слой вообще не использует LLM и не зависит от «уверенности» её формулировок.
Да, детерминированный код не оценит, насколько изящна гипотеза. И не должен. Его задача другая: ловить системные дефекты, которые можно четко описать логическим правилом.
Например, в нашем Full-режиме сейчас работает 12 таких жестких критериев проверок. Вот как это выглядит на практике:
- Проблема полноты (классика): Модель зафиксировала UX-барьер, но в финальном списке рекомендаций для него не оказалось ни одного целевого действия. Чтобы поймать эту ошибку, не нужен дорогой и медленный LLM-судья. Достаточно написать простое правило сравнения массивов данных на Python.
- Логические противоречия: Если оценка драйвера принятия решения (score) выше 75 баллов, но при этом модель нашла в интерфейсе «критический» барьер — это математическое противоречие. Наш скрипт перехватывает это и автоматически применяет фикс (auto-fix) для JSON-контракта еще до того, как он уйдет на фронтенд.
- Структурная целостность: Код жестко проверяет наличие обязательных полей (например, массива возражений или A/B гипотез) и при необходимости достраивает структуру.
Главный инсайт
Не каждую проблему качества ИИ-продукта стоит решать еще одной нейронкой. Если часть проверки можно алгоритмизировать и описать правилами — ее нужно выносить из вероятностного контура в детерминированный код. Это делает систему дешевле, быстрее и в десятки раз надежнее.
Вопрос к тем, кто уже внедрил LLM в свои продукты: как вы решаете проблему контроля качества генерации в проде? Как эффективно строите оборону против галлюцинаций (да, да и Fable 5 не прочь тупануть).