AI-evals в продакшене на маркетплейсе

Маркетплейс хочет считать price index. Для этого нужно сопоставить свои товары с товарами конкурентов на разных площадках. Один из ключевых сигналов для матчинга — категория товара. Категории у всех маркетплейсов разные, миллионы пар матчей, ручное сопоставление — десятки человеко-лет.

Команда выбирает LLM-классификатор. Промпт «вот категория с маркетплейса A, вот 20 кандидатов с маркетплейса B, какие ближе по смыслу». Собирают golden set — 1000 размеченных пар. Считают accuracy: 85%. Принимают решение раскатывать.

Через два месяца после раскатки price index в продакшене показывает странности. Цифры расходятся с ручной проверкой на репрезентативной подвыборке. Кто-то считает заново: фактическая точность в продакшене — около 73%. Что произошло, и почему 85% оказалось не настоящим 85%.

Эта статья — про три самых частых методологических провала в AI-evaluation на маркетплейсе. У каждого есть конкретный механизм, конкретное решение, и интерактивный симулятор где можно покрутить параметры самому. Все три встречаются часто, все три остаются незамеченными в стандартных отчётах «accuracy: X%».

Угроза 1: гетерогенность распределения

Когда команда собирает golden set, она почти всегда собирает его непропорционально. Электронику легко размечать — чёткие бренды, модельные ряды, спецификации. Fashion и food сложнее: размеры, цвета, варианты, составы. Long tail (нишевые категории) сложнее всего и часто пропускается потому что эталонов мало.

В итоге golden set смещён к простым сегментам. Если в продакшене распределение 30% электроника / 40% fashion / 20% food / 10% long tail, а в golden set оно 50% / 30% / 15% / 5% — overall accuracy на golden и в продакшене будут разными числами, даже если модель ведёт себя стабильно.

Численно: при precision 95% на электронике, 76% на fashion, 65% на food, 50% на long tail и golden distribution 50/30/15/5 — overall в golden получается 84%. На продакшен-распределении 30/40/20/10 — 71%. Это 13 п.п. разрыва, который не виден в стандартной отчётности «overall = 84%».

Решение — stratified evaluation. Не одна цифра, а precision на каждом сегменте отдельно плюс production-weighted overall: точность по каждому сегменту, умноженная на долю этого сегмента в продакшене. Это честное число — то, что увидят в проде после раскатки.

В пайплайне это четыре шага: (1) измерить продакшен-распределение до сборки golden set; (2) собрать golden стратифицированно под продакшен; (3) считать precision per segment с CI; (4) давать в отчёте как per-segment числа, так и production-weighted overall. Naive overall оставлять для сравнения — разрыв между naive и weighted сам по себе диагностика: больше 5 п.п. означает что golden set нерепрезентативен.

→ Покрутить параметры (доли в golden vs продакшен, precision per segment, sample size for CI): Category Matching Eval

Угроза 2: стохастичность модели

A/B-тест двух LLM выглядит как обычный A/B: 50/50 трафика, ждём sample size для значимого эффекта, считаем разницу, принимаем решение. Стандартный power analysis говорит N для заданного MDE.

Проблема: в LLM treatment не детерминирован. При temperature больше нуля одна и та же модель на одинаковом запросе даёт разные ответы. CSAT по диалогу зависит не только от того какая модель ответила, но и от того как именно она ответила в этот раз. Это дополнительная variance, которой нет в обычной формуле sample size.

Численно: если variance модели добавляет 30% к общей дисперсии — N вырастает в 1.4 раза. При 50% — в два раза. Это в формуле напрямую: N пропорционально σ². Игнорировать stochasticity модели — значит планировать в 2-4 раза меньше выборки чем нужно, не различить модели с реальным эффектом, и сделать вывод «эквивалентны».

Решение — компонентная декомпозиция variance в sample size расчёте. Variance общая = variance между диалогами + variance модели. Базовая формула N = 2·(z_α + z_β)²·σ²/Δ² становится N = 2·(z_α + z_β)²·σ²_total/Δ², где σ²_total включает стохастичность.

В пайплайне это три шага: (1) до запуска теста — оценить долю дисперсии модели на небольшой калибровочной выборке, прогнав одинаковые запросы 5-10 раз и посмотрев разброс ответов; (2) применить поправку к sample size; (3) если N после поправки выходит за разумные пределы — пересмотреть MDE или вернуться к offline-оценке на golden set.

→ Покрутить параметры (размер эффекта, доля дисперсии модели, мощность): LLM A/B Test Simulator

Угроза 3: bias в LLM-as-judge

Третий типичный сценарий: команда хочет сравнить две LLM через pairwise-судейство. Вместо тысячи человеческих оценок — показать пары ответов GPT-4 в роли судьи, попросить выбрать лучший. Дёшево, быстро, масштабируемо.

Документированная проблема: LLM-судьи имеют позиционный bias. По работам Zheng et al. 2023 (MT-Bench) и Li et al. (AlpacaFarm) — GPT-4-class судьи систематически предпочитают первый показанный ответ на 15-25 п.п., независимо от качества. Это не случайный шум, это систематическое смещение.

Конкретно: если в эксперименте всегда «модель A первой, модель B второй», и позиционный bias 20 п.п. в сторону первого, то истинный win rate B 50% измерится как 30%. Это не «подкоп под результат» — модель просто не лучше. Это смещение оценки, которое отправляет команду откатить B как «хуже на 20 п.п.», хотя она эквивалентна.

Решение — mirror judging. Каждую пару показывать дважды: один раз (A, B), второй раз (B, A). B засчитывается только если выиграл в обоих порядках. Если выиграл в одном и проиграл в другом — это tie (значит судья выбирал по позиции, а не по содержанию). Стоимость удваивается — 2× API-вызовов. Позиционный bias устраняется полностью.

В пайплайне это два шага: (1) логировать обе оценки с явной меткой порядка; (2) считать mirror win rate как «B победил тогда и только тогда когда выиграл оба ордера». Tie rate сам по себе диагностика: высокий tie rate означает модели близки или judge слабый. Низкий tie rate после mirror — modeli действительно расходятся.

→ Покрутить параметры (true win rate, bias strength, strategy): LLM-as-Judge Position Bias

Что общего у этих трёх

Три ошибки выглядят разными — gold-set distribution, model stochasticity, позиционный bias судьи. Но у них одна структурная природа: разрыв между тем что мы измеряем и тем что есть в продакшене.

• Gold-set distribution: измеряем на распределении эталонов, производит на другом распределении.
• Model stochasticity: измеряем однократно, в продакшене работает многократно.
• Позиционный bias судьи: измеряем фиксированным порядком, продакшен агностичен к порядку.

В каждом случае «overall accuracy» или «win rate» — это проекция на удобную для измерения, но не релевантную для продакшена схему. Корректное решение в каждом случае — сделать измерение репрезентативным относительно продакшена: production-weighted overall, variance-corrected sample size, mirror judgment.

Главное правило AI-evaluation на маркетплейсе: никогда не доверяй cumulative число без разбора того, как оно получено. Один-два уточняющих вопроса аналитика часто ловят 10-20 п.п. systematic bias, который не виден в отдельном отчёте «accuracy: X%».

Чеклист для команды

Семь правил, которые закрывают большую часть проблем на этапе планирования eval, до того как решение о раскатке уже принято:

1. Измерить продакшен-распределение до сборки golden set. Категории-фильтры на page views в течение недели, агрегация. Это первый шаг, часто пропускается.
2. Стратифицированный golden set под продакшен. Не равными долями, не пропорционально удобству разметки — под реальное продакшен-распределение.
3. Никогда не репортить только overall accuracy. Per-segment precision + CI как primary, production-weighted overall как honest summary, naive overall как diagnostic.
4. Для A/B на LLM — оценить долю дисперсии модели до расчёта sample size. Калибровочная выборка 50-100 запросов с повторами, измерить разброс.
5. Для pairwise-судейства — всегда mirror. Каждую пару судить в обоих порядках. Tie как honest output, не как ошибка.
6. Для высокоставочных решений — выборочная человеческая проверка на подвыборке после автоматизированной оценки. Mirror устраняет позиционный bias, но не другие LLM-judge biases (self-preference, length, style). 50 случайных пар, человек как ground truth.
7. Повторная оценка каждые 3-6 месяцев. Продакшен-распределение меняется (новые категории, переименования, перестройки), и «хорошая» оценка через полгода может быть устаревшей.

Это не academic точность — это базовая гигиена. Команда которая делает все семь шагов получает eval, на который можно полагаться при решениях о раскатке. Команда которая делает один-два — получает 85% в отчёте и сюрприз через два месяца.