Online Evals в 2026: feedback loop на реальном трафике, а не только офлайн-датасет

Короткая версия

У online eval в production обычно есть пять основных сигналов:

1. User feedback
2. Automated trace scoring
3. Outcome metrics
4. Canary / shadow comparisons
5. Escalations и corrections

Что online eval должен уметь

• привязать feedback к trace_id или run_id;
• разделить feedback по шагам, а не только по whole response;
• отбирать плохие кейсы в offline dataset;
• сравнивать версии prompt/model на real traffic slices;
• не блокировать UX тяжёлой синхронной оценкой.

Пользователь поставил thumbs down RAG-ответу. Что полезнее всего сохранить вместе с этим сигналом?

1. Online eval начинается там, где offline заканчивается

Офлайн eval хорош для:

• известных задач;
• regression gates;
• controlled comparison;
• pre-release safety.

Но у него есть слепые зоны:

• новые запросы из длинного хвоста;
• неожиданные user intents;
• UI-driven failures;
• distribution shift после marketing launch;
• деградация на конкретных сегментах трафика.

Именно здесь online eval даёт signal, которого нет в статическом dataset.

2. Какие сигналы реально работают

User feedback

Самый очевидный слой:

• thumbs up/down;
• rating;
• free-text complaint;
• corrected answer.

Но сырой feedback сам по себе не очень полезен. Он становится ценным, когда привязан к trace и структуре workflow.

Automated trace scoring

LLM-as-judge и rubric scoring можно запускать не только офлайн, но и на sampled production traces:

• factuality;
• groundedness;
• tool correctness;
• policy compliance;
• formatting success.

Outcome metrics

Иногда лучший eval-сигнал - не текстовая оценка, а бизнес-исход:

• task completion;
• escalation avoided;
• conversion;
• edit-before-send rate;
• accepted suggestion rate.

Corrections

Если пользователь исправил ответ, это часто сигнал сильнее, чем thumbs down. Correction показывает не только dissatisfaction, но и более желаемый target.

3. Canary и shadow traffic

Хороший online eval не означает "катим на всех и потом смотрим".

Практически полезны два режима:

Canary

Новая версия идёт на маленькую долю реальных пользователей.

Подходит, когда:

• есть явный release candidate;
• нужен controlled rollout;
• возможен быстрый rollback.

Shadow

Новая версия получает копию запроса, но не показывает ответ пользователю.

Подходит, когда:

• система high-stakes;
• change слишком рискованный;
• нужен hidden comparison с текущим production.

Shadow особенно полезен для routing, tool selection и agent traces, где ошибка может быть дорогой ещё до того, как ответ увидит пользователь.

4. Feedback должен жить на trace level

Современный online eval почти всегда строится вокруг trace-linked данных:

• trace_id;
• run_id;
• prompt version;
• selected route;
• retrieved context;
• tool spans;
• output schema status;
• user decision.

Это важно, потому что один плохой answer может быть вызван разными причинами:

• retrieval miss;
• routing error;
• tool timeout;
• weak final synthesis;
• guardrail over-refusal.

Без trace link вы не узнаете, какой слой виноват.

5. Что не стоит мерить только средним баллом

Один общий online score почти всегда скрывает главное. Лучше разбивать сигнал по осям:

• by route;
• by task type;
• by risk bucket;
• by prompt version;
• by tool family;
• by customer segment.

Иначе средний показатель будет нормальным, даже если у вас quietly ломается один дорогой сценарий.

6. Как production feedback превращается в offline dataset

Лучший online eval создаёт не только дашборд, но и pipeline пополнения test set.

Практический цикл:

1. trace получает bad signal;
2. кейс и его артефакты сохраняются;
3. человек при необходимости добавляет rubric или expected answer;
4. кейс попадает в offline regression set;
5. следующие релизы уже обязаны его не ломать.

Именно так online eval перестаёт быть просто мониторингом и становится системой постоянного улучшения.

7. Что чаще всего ломают команды

Feedback без контекста

Есть минус, но нет trace, route и retrieved docs.

Слишком медленные graders

Оценка блокирует user flow вместо асинхронного фонового контура.

Bias на vocal users

Сигнал идёт только от небольшой группы очень активных пользователей.

Нет sampling strategy

Команда либо оценивает всё подряд и тратит бюджет, либо почти ничего не оценивает на hard slices.

Нет human review для ambiguous cases

Автогрейдер начинает незаметно drift-ить от product reality.

8. Какие метрики особенно полезны

Минимальный online eval dashboard обычно включает:

• user thumbs rate;
• correction rate;
• sampled trace judge-score;
• accepted suggestion rate;
• escalation rate;
• route-specific quality deltas;
• bad-case ingestion rate в offline dataset.

Отдельно полезно считать time-to-learn: сколько проходит от появления нового failure mode до его попадания в regression suite.

Минимальная схема online eval события

{
  "trace_id": "tr_1182",
  "run_id": "run_9003",
  "route": "balanced_rag",
  "prompt_version": "answer_v17",
  "feedback": {
    "thumbs": -1,
    "comment": "Сослался не на тот документ"
  },
  "artifacts": {
    "retrieved_doc_ids": ["doc_91", "doc_12"],
    "tool_spans": ["retrieve", "rerank", "answer"]
  },
  "outcome": {
    "accepted": false,
    "escalated": true
  }
}

Простой ingestion loop

def handle_feedback(event):
    store_feedback(event)

    if event["feedback"]["thumbs"] < 0 or event["outcome"]["escalated"]:
        queue_for_review(
            trace_id=event["trace_id"],
            prompt_version=event["prompt_version"],
            route=event["route"],
        )

Практический совет: собирайте feedback не только на whole answer, но и на дочерние шаги вроде retrieval, tool use и final synthesis. Иначе multi-step системы остаются "чёрным ящиком" даже при хорошем объёме сигналов.