Skip to content

Enhancement: Eval history observability with repo SHA provenance and judge drift markers #4

Description

@coston

Summary

Implement eval-history observability for multi-model comparisons so historical trends remain useful while clearly signaling comparability caveats.

Problem

Current comparison outputs are useful per run, but decision-makers need reliable trend visibility over time. With LLM-as-judge, score changes can come from model-under-test changes or judge/eval regime changes, which can make historical interpretation ambiguous.

Proposed enhancement (v1)

Capture and report score, cost, and duration over time with run provenance and event markers.

1) Persist run provenance metadata

Add these fields to persisted run artifacts (JSON and CSV):

  • run_at (ISO timestamp)
  • repo (owner/repo)
  • git_sha (commit evaluated)
  • judge_provider
  • judge_model
  • judge_version (when available)
  • judge_prompt_hash
  • eval_hash (or per-eval spec hash)
  • comparison_fingerprint (stable hash of judge+prompt+eval config)

2) Capture decision metrics

For each model/eval run, persist:

  • quality score (existing pass-rate metrics)
  • total/normalized cost (if available from provider/runtime)
  • total duration / wall-clock time

3) Historical trend reporting

Add/extend report generation to show time-series trends per model/eval with two modes:

  • Strict comparable: same comparison_fingerprint
  • All runs: includes all historical runs with caveat labeling

4) Regime-change markers

In trend outputs (charts/tables), show vertical event markers when any of these change:

  • judge model/version
  • judge prompt hash
  • eval hash/spec

These markers should behave like release/event bars so jumps are interpretable.

Why

  • Preserves all historical data (no loss of context)
  • Improves reproducibility with repo+SHA provenance
  • Makes drift explicit rather than hidden
  • Supports practical model decisions using quality + cost + speed together

Acceptance criteria

  • JSON/CSV artifacts include provenance metadata fields listed above
  • repo and git_sha are captured for every run
  • score, cost, and duration are persisted for each model/eval run
  • report supports strict-comparable and all-runs modes
  • regime-change markers appear when judge/prompt/eval fingerprints change
  • each trend point can be traced back to run timestamp, repo SHA, and judge config

Non-goals (v1)

  • statistical normalization across different judge versions
  • mandatory human re-judging workflow
  • full BI/dashboard stack

References

  • docs/eval-comparison.md
  • Feedback: preserve historical numbers, record judge/date/SHA, and mark major judge/prompt changes as vertical bars.

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions