Глава 10 — Ведущие фреймворки оценки

Десятый пост поглавного разбора LLM Primer III: Enhancing Enterprise AI with RAG. О том, как Триада получает инструментарий — восемь фреймворков в двух жанрах — и одно честное признание о той части оценки, которую ни один из них пока не решает.

Почему существует эта глава

Триада из Главы 9 сказала, что измерять. О том, как эти измерения реально гонять в продакшене, она ничего не сказала. Метрики — это концепции. Их реализации — это промпты для судьи, логика декомпозиции утверждений, выбор эмбеддингов под сходство, стратегии сэмплирования под цену, дашборды, алерты и петли человеческого ревью. Ни одна команда не строит всё это с нуля.

Фреймворки разделились по узнаваемой оси. С одной стороны — библиотеки, идущие от метрик: RAGAS, TruLens, DeepEval, считающие Триаду по задокументированной воспроизводимой методике. С другой — платформы наблюдаемости: Braintrust, LangSmith, Phoenix, Galileo, Opik, идущие от продакшен-трассировок и интегрирующие оценку как одну фичу в большем рабочем процессе. Выбор между ними — не столько сравнение фич, сколько вопрос о том, что команде нужно, чтобы система делала на следующий день после релиза.

10.1 Библиотеки от метрик — RAGAS, TruLens, DeepEval

RAGAS — это самое близкое в поле к референсной реализации Триады. Консервативный набор метрик, задокументированные промпты, каждый вызов LLM на виду. Пайплайн Faithfulness — двухстадийная цепочка: разложить ответ на утверждения, проверить каждое против контекста — и промежуточный список утверждений возвращается в результате, так что инженер может указать пальцем на конкретное утверждение, которое фреймворк счёл неподкреплённым. Для исследований, регулируемых индустрий или любой команды, которой нужно защищать свою методику, RAGAS — дефолт. Цена — он ощущается академичным. Считает метрики; дашборд не поставляет.

TruLens сидит между библиотекой метрик и платформой наблюдаемости. Его акцент — инструментирование: фреймворк обёртывает приложение на уровне функций, ловя каждый поисковый вызов и каждый ответ модели в структурированный Trace, и затем гоняет Триаду против трассировок. Метрики Триады выставлены как feedback-функции — маленькие компонуемые единицы, легко написать свои. TruLens — правильный выбор, когда потребности команды в оценке выходят за стандартный набор, или когда процесс центрирован на разборе отдельных отказов, а не на агрегированных дашбордах.

DeepEval занимает третью позицию: оценка как pytest. Тест-кейсы пишутся и гоняются pytest-подобным CLI; падения блокируют PR; набор метрик — самый широкий из трёх, включая bias, toxicity и проверки галлюцинаций наряду с Триадой. Компромисс — широта приходит с неровной строгостью. Выберите метрику из меню, не читая её реализацию, и можете в итоге сообщать числа, означающие не то, что вы думаете. Правильная дисциплина — выбрать малый набор, прочесть промпты, откалиброваться против ручных меток и считать остальное вдохновением.

10.2 Платформы наблюдаемости — Braintrust, LangSmith, Phoenix, Galileo, Opik

Библиотеки от метрик отвечают на «как мне посчитать Триаду». Платформы наблюдаемости отвечают на «как мне гонять RAG-систему в продакшене». Они исходят из того, что команда будет писать промпты, сравнивать версии моделей, забирать трассировки и смотреть дашборды в обозримом будущем. Оценка — одна фича; версионирование промптов, исследование трассировок, A/B-тестирование и алерты — равноценные части ценности.

Braintrust ведёт с разработческого опыта: эксперимент — версионированная запись поведения модели на датасете, с side-by-side diff'ами оценок в UI, которым действительно приятно пользоваться. LangSmith — естественный выбор для команд, уже глубоко в LangChain; ожидает быть в центре инструментирования приложения и вознаграждает за это глубиной. Phoenix от Arize — open-source опция, выделяющаяся анализом дрейфа и кластеризации эмбеддингов, который остальные недоигрывают; жизнеспособен для команд, которые не могут отправлять трассировки в SaaS. Galileo — enterprise-ориентированная платформа с проприетарной оценкой Correctness и on-prem развёртыванием для регулируемых индустрий. Opik от Comet — самый свежий участник, open-source-first как Phoenix, отшлифованный как Braintrust, с дополнительным преимуществом объединения LLM- и классической ML-наблюдаемости под одной платформой.

Выбор между пятью — это меньше про фичи, чем про организационное соответствие. LangChain-команда тянется к LangSmith. Greenfield продуктовая команда — к Braintrust. Open-source-first команда — к Phoenix. Регулируемое предприятие — к Galileo. Comet-команда — к Opik. Качество метрик у всех пяти сравнимо в широком смысле — все реализуют Триаду, все используют LLM-as-Judge, все несут те же фундаментальные ограничения, которые назвала Глава 9. Различия — процесс, а не измерение.

10.3 Evaluation Gap и паттерн трёх петель

Вот неудобный факт, который тур по фреймворкам только что обошёл. Почти каждый инструмент выше оценивает на слое инференса: при условии, что поиск уже произошёл, уважила ли модель чанки, подошёл ли ответ к вопросу, были ли чанки по теме. Ни один из них в глубоком смысле не говорит, нашёл ли поиск правильные чанки в первую очередь. Выход ретривера — это вход инференса, а метрики инференса меряют выход, но не вход. Если поиск систематически пропускает важный документ, Faithfulness остаётся высокой (модель уважила то, что ей дали), Answer Relevance остаётся высокой (ответ подошёл к форме вопроса), а пользователи получают неверный ответ.

Это и есть Evaluation Gap. Структурная причина в том, что оценка инференс-слоя — reference-free, тогда как строгая оценка слоя контекста должна знать, какие чанки были правильными — а это требует либо размеченного набора, либо синтетического. Обходные пути — генерация синтетических вопросов, needle-in-a-haystack пробы, прокси downstream-impact, аудит query-conditioned retrieval, retrieval-against-self — все полезны и все неполны. Честное резюме: оценка слоя контекста — открытый фронтир, и командам стоит ожидать, что часть собственной инженерии придётся вложить непосредственно в качество поиска. Фреймворки помогают с петлёй инференса; петлю поиска они в основном оставляют команде.

Паттерн, к которому сходятся зрелые команды, — это три петли, а не одна. Внутренняя петля: библиотека от метрик (обычно RAGAS или DeepEval) гоняет Триаду на фиксированном регрессионном наборе при каждом значимом изменении, быстро и детерминированно, нацелена на ловлю регрессий. Внешняя петля: платформа наблюдаемости держит хранилище продакшен-трассировок, онлайн-вычисление метрик против сэмплированного трафика, дашборды и алерты — нацелена на дрейф, который регрессионный набор пропустит. Медленная петля: небольшая функция человеческого ревью калибрует LLM-судей, проверяет помеченные трассировки и поддерживает регрессионный набор по мере развития продукта. Команда только с внутренней петлёй выкатывает дрейфующий продакшен. Команда только с внешней видит дрейф, но не может его отладить. Команда с обеими, но без человеческого ревью, доверяет судьям, которые тихо съезжают. Все три необходимы, а ценность фреймворков — насколько они делают каждую из них дешёвой.

Что подготавливает глава 10

Между Триадой из Главы 9 и фреймворками из Главы 10 у команды есть всё, чтобы измерять RAG-систему: словарь, честный учёт того, что словарь упускает, и небольшой набор инструментов, превращающих измерения в дашборды. Система будет читаема. Но измерение — это лишь половина продакшен-истории. Система, которую измеряют, но не сопровождают, всё равно деградирует, потому что меняются документы, пользователи и сами модели. Знать, что качество упало, не то же, что уметь его восстановить.

Дальше — Глава 11: Непрерывные обновления и оптимизация пайплайна. CDC и инкрементальная индексация, семантическое кеширование и тиринг моделей и четырёхстадийная петля обратной связи, превращающая продакшен-телеметрию в систему, которая реально становится лучше, чем дольше работает.