Quartz 4

Data Quality Dashboard — Hybrid (свой EvaluationScore + LangFuse traceId для drill-down)

active
Not verified

4 min read

Status: active — реализовано через BG-1196 в bloodgpt-for-business (апрель 2026), до этого proposed с весны.

Контекст

Для data-quality-dashboard (RFC-022) было три варианта реализации. Выбор определял на годы вперёд: сколько кода поддерживать, насколько глубокая интеграция с собственными сущностями (ParameterV2, mapping tables) возможна, и где живут метрики качества.

Рассматривали

Вариант A — LangFuse-first

Использовать возможности LangFuse максимально: scores на каждом этапе пайплайна, metadata с деталями трансформаций, Custom Dashboards для визуализации, Annotation Queues для review, Corrections для исправлений.

Плюсы: почти нет нового кода, уже интегрирован, Score Analytics из коробки, тренды и correlation, Annotation Queues как готовый workflow.

Минусы: нет связи с собственной БД (нельзя сделать «remap на ParameterV2» через справочник); агрегация для дашборда («средний score за неделю по 500 тестам») медленная; LangFuse Corrections — относительно новая фича.

Вариант B — Hybrid (LangFuse + свой UI/store)

LangFuse держит trace и observations; своя БД хранит judge-результаты для быстрой агрегации и UI-рендеринга. Свой админ-UI для специфичных действий (org-фильтрация, per-criterion pass rate, drill-down с переходом в LangFuse).

Плюсы: гибкость; полная интеграция с собственными данными; быстрая агрегация для дашбордов; per-test Quality column в таблице тестов; per-org feature flag для постепенного rollout.

Минусы: больше кода; своё UI требует поддержки; два места для метрик (но drill-down один раз).

Вариант C — Полностью своя система

Таблица data_quality_events для всех событий, свой дашборд (React + API), свой workflow для коррекций.

Плюсы: полный контроль; offline работа; любые интеграции.

Минусы: много работы; дублирование того, что уже есть в LangFuse (traces, scores, queues); долгая поддержка.

Выбрали

Вариант B (Hybrid). Прыгнули мимо первоначально рекомендованной фазы «A на 2-4 недели → решить» — сразу пошли в Hybrid. Аргументация из сессии 920d5967 (Mar 30-31):

  • LangFuse built-in evaluators требуют ручной настройки 11 judges в UI — для проектируемой системы это «больше ручной работы», чем код. Цитата Ильдара: «первый вариант для меня сложнее, потому что надо будет руками делать».
  • YAML-критерии в git дают версионирование и review через PR; в LangFuse UI они были бы непрозрачные.
  • Артёму нужен дашборд из Prisma (быстрая агрегация по 500 тестам), не drill-down per-trace.
  • Cron вместо event-driven trigger — ноль правок в существующем коде (без inngest.send() после pipeline-завершения).

Drill-down per-test всё равно идёт в LangFuse через langfuseTraceId / langfuseObservationId в EvaluationScore — это часть hybrid-схемы.

Реализация (BG-1196, апрель 2026)

  • Prisma модель EvaluationScore — bloodTestId, promptName, langfuseTraceId, langfuseObservationId, score, passed, reason, judgeModel, threshold, criteriaVersion, trigger. Unique по (bloodTestId, promptName, langfuseObservationId).
  • Inngest cron evaluation-judge (apps/analysis-worker/...), "0 * * * *". Fair quota между орг’ами, batch по 10, _skipped sentinel с 24h retry, маппинг observation prefix → criteria name.
  • 5 YAML критериев в packages/evaluation/src/criteria/: single_parameter_analysis, test_overview, followup_generation, panel_overview, trend_analysis.
  • WorkOS feature flag LLM_JUDGE — per-organization rollout, не все орг’и сразу.
  • packages/evaluation/ — judge package: loadCriteria, judge, buildEvaluationPrompt. Logprobs обязательны (text-parsing fallback убран явно).
  • apps/b2b-platform — Generation Quality block в org-monitoring-dashboard, Quality Score card в admin-monitoring-dashboard, per-test Quality column в dashboard/[id]/tests.
  • apps/evaluation — отдельный CLI/web сервер для batch-прогонов off-line (sqlite, comparator, analyzer).

Покрыт только Analysis-слой. Recognition / Normalization остались на старом мониторинге (Slack-каналы, LangFuse traces, прямые SQL-запросы).

Прошёл через 4 раунда code review (commits address PR review / address second / third / fourth review round).

Следствия

  • Большая часть инвестиции в DQD — собственный код в bloodgpt-for-business репо, не конфиги в LangFuse. Это плюс для версионирования и review (PR-based), минус для скорости итераций над дашбордом (нужен деплой).
  • Per-org feature flag LLM_JUDGE даёт безопасный rollout, но создаёт две версии org-monitoring-dashboard (с Generation Quality / без) — нужно поддерживать обе.
  • Drill-down через langfuseTraceId сохраняет зависимость от LangFuse — если он умрёт или проект мигрирует, ссылки сломаются.
  • Standalone Dictionary admin UI (loinc-harmonization-service) — отдельный путь; объединение с DQD пока не планируется конкретно.
  • Сильная зависимость от observation-имён (analyze-parameter, test-overview, …) делает migration на FHIR single-pass уязвимой — OBSERVATION_TO_CRITERIA маппинг нужно будет пересматривать.

Открытые вопросы

  • Перенести оставшиеся 6 YAML-критериев из eval-репо Никиты (5 из 11 портированы)
  • Критерии для включения LLM_JUDGE для new орг’ов — пока feature flag по интуиции
  • Закрытие feedback loop: editable-overview → возврат в EvaluationScore как «judge был прав / неправ»
  • Расширение judge на Recognition / Normalization или оставить эти слои на текущем мониторинге
  • Совместимость с FHIR single-pass: новые observation-имена сломают маппинг
  • Объединение standalone Dictionary admin UI (loinc-harmonization-service) с org-monitoring-dashboard

Связано

Источники

Источники: 1.

Сноски

  1. Сессия ildar/920d5967, 2026-03-26 — (Mar 30-31. ↩

Graph View

Backlinks