AI / LLM
LLM-evals: тест с множественным выбором
Шесть вопросов, пронизывающих весь юнит. Каждый отражает решение, которое ты принимаешь, выкатывая реальную LLM-фичу, — не определение для пересказа, а компромисс, который надо взвесить, когда набор зелёный и нужно решить, веришь ли ты ему на самом деле.
Убедись, что умеешь связать дизайн golden set, выбор скорера, калибровку judge и разделение offline/online — и распознать, когда проходящий eval всё равно тебе лжёт.
Провайдер за ночь молча подменил снапшот твоей модели. Репозиторий не менялся, CI зелёный, качество упало на 15%. Какой слой структурно способен это поймать и почему?
Ты собрал golden set из чистых примеров, которые использовал при разработке фичи. Набор показывает 96%, но пользователи натыкаются на сбои. В чём ошибка дизайна?
Твоя фича возвращает JSON-объект с обязательным enum-полем `status` плюс свободный текст `rationale`. Какая стратегия скоринга верна?
LLM-as-judge выдаёт идентичный вердикт на десяти повторных прогонах одного кейса. Коллега называет его «откалиброванным». Он прав?
В попарном сравнении LLM-as-judge перестановка того, какой ответ идёт первым, иногда переворачивает вердикт. Что это и как смягчить?
В чём точный механизм regression gate и какая senior-дисциплина заставляет его со временем ужесточаться, а не гнить?
Сквозная линия юнита — один пайплайн: golden set из реального трафика (покрытие важнее количества), скоринг самым дешёвым честным методом — программный там, где у вывода есть структура, откалиброванный judge только для open-ended качества, — затем offline-гейт в CI и online-семплинг для дрейфа. Зелёный набор лжёт двумя способами: датасет, который больше не совпадает с живым распределением, и judge, который ты не валидировал против людей. Consistency — это не accuracy; position, self-preference и verbosity bias реальны; а дисциплина, держащая гейт честным, — превращать каждый продакшн-сбой в golden-кейс в тот же день.