Deep Dive: Production Model Evaluation Framework

Amazon-Style Framing

This was not just an "evaluation script" or a dashboard. It was a release safety system for ML and LLM changes. The purpose was to make sure that any prompt update, model upgrade, retriever change, classifier retrain, or guardrail update could be tested, compared, promoted, or rolled back using a repeatable engineering workflow.

The framework in the source document already defines a 4-layer progression:

1. Golden dataset evaluation for offline regression testing
2. Shadow mode for production-parallel comparison with no user impact
3. Canary rollout for controlled exposure to real users
4. Continuous monitoring for long-term drift, incidents, and rollback

This deep dive expands that framework into a full implementation story: architecture, pipelines, storage, algorithms, math, statistical reasoning, and the engineering decisions that made the framework effective.

1. What problem this framework solved

Without a structured evaluation system, model releases fail in predictable ways:

• Prompt regressions change tone, structure, or formatting unexpectedly.
• Model upgrades may increase hallucinations, verbosity, latency, or cost.
• Retriever changes can lower grounding quality even when generation looks fluent.
• Classifier retrains can misroute traffic to the wrong downstream workflow.
• Guardrail updates can over-block safe responses or miss unsafe ones.
• Infra changes can hurt TTFT, tail latency, or throttling behavior.

A single offline metric is not enough to catch all of this. That is why the original framework uses multiple layers rather than a one-time evaluation gate. The source makes this explicit: no change should reach 100% traffic without passing all required layers for that change type. fileciteturn0file0L1-L38

2. The full system architecture

2.1 Core principle

Treat evaluation as a productized platform capability, not a notebook-based ML task.

That means the evaluation system should have:

• versioned datasets
• automated scoring
• reproducible pipelines
• release policies
• storage for raw + aggregate results
• dashboards and alerting
• auditability
• rollback hooks

2.2 High-level architecture

                  +----------------------------+
                  |  Developer / DS Change     |
                  |  - prompt                  |
                  |  - model version           |
                  |  - retriever config        |
                  |  - classifier weights      |
                  |  - guardrail policy        |
                  +-------------+--------------+
                                |
                                v
                  +----------------------------+
                  |  CI / Release Orchestrator  |
                  |  decides required layers    |
                  +------+------+---------------+
                         |      |
          Offline PR Gate|      |Deployment Path
                         |      |
                         v      v
              +---------------------+      +----------------------+
              | Golden Dataset Eval |      | Shadow Mode Service  |
              | full pipeline replay|      | prod vs candidate    |
              +----------+----------+      +----------+-----------+
                         |                            |
                         v                            v
              +---------------------+      +----------------------+
              | Metric Computation  |      | Diff + Slice Reports |
              +----------+----------+      +----------+-----------+
                         |                            |
                         +-------------+--------------+
                                       |
                                       v
                            +-----------------------+
                            | Canary Controller      |
                            | 1% -> 10% -> 50%      |
                            +----------+------------+
                                       |
                                       v
                            +-----------------------+
                            | Continuous Monitoring  |
                            | dashboards + alerts    |
                            +----------+------------+
                                       |
                                       v
                            +-----------------------+
                            | Auto Rollback /       |
                            | Incident Workflow     |
                            +-----------------------+

2.3 Major services

A. Evaluation Orchestrator

This service decides:

• what changed
• which layers are mandatory
• what baseline to compare against
• which thresholds apply
• whether to block, promote, or rollback

This should be separate from the online inference service because release governance changes frequently, while inference should stay lean and stable.

B. Dataset Service

Stores golden datasets, adversarial sets, multi-turn scenarios, and metadata.

C. Replay Runner

Executes evaluation queries through the full application pipeline, not just the LLM call.

D. Metric Engine

Calculates classification, retrieval, generation, latency, cost, and constraint metrics.

E. Shadow Comparator

Runs candidate and production versions in parallel and computes diffs.

F. Canary Controller

Applies rollout policy and statistical checks.

G. Monitoring and Alerting Layer

Publishes operational and quality signals to dashboards and paging systems.

3. Why the full-pipeline approach mattered

One of the most important engineering decisions was to evaluate the entire pipeline, not only model output quality.

The source document already reflects this through gates like:

• intent accuracy
• BERTScore
• guardrail pass rate
• format compliance
• response length
• prohibited element checks
• per-class F1

Those are system-level metrics, not only generator metrics. fileciteturn0file0L96-L129

A real production LLM system usually has these steps:

User Query
  -> pre-processing / normalization
  -> intent classification or routing
  -> feature lookup or user context lookup
  -> retrieval / search
  -> prompt assembly
  -> LLM generation
  -> post-processing / structured formatting
  -> guardrails / validation / policy filters
  -> frontend rendering

If you only score the generated text, you miss:

• misrouting to the wrong intent flow
• incorrect retrieved documents
• malformed output schema
• missing product validation
• guardrail regressions
• latency regressions from retrieval or prompt bloat

This full-pipeline decision is one of the main reasons the framework became useful in practice.

4. Layer 1: Golden dataset evaluation

4.1 What the golden dataset is

The source document defines a curated dataset of 500+ examples spanning recommendation, product questions, FAQ, order tracking, multi-turn, adversarial, returns, and chitchat. fileciteturn0file0L52-L90

That dataset should be treated as a versioned test suite.

Each example should include:

• query text
• optional conversation history
• user context
• expected intent
• reference answer or rubric
• required elements
• prohibited elements
• tags for slicing
• retrieval expectation if applicable

4.2 Data schema

Example internal schema:

{
  "query_id": "GD-042",
  "dataset_version": "2026-Q1-v3",
  "query": "What dark fantasy manga would you recommend for someone who loved Berserk?",
  "conversation_history": [],
  "expected_intent": "recommendation",
  "reference_response": "...",
  "required_elements": ["2+ recommendations", "reasoning"],
  "prohibited_elements": ["fabricated titles", "competitor mention"],
  "retrieval_gold_doc_ids": ["doc_101", "doc_448"],
  "tags": ["recommendation", "genre-specific", "dark-fantasy"]
}

4.3 How the dataset should be built

The source describes five major stages:

1. production sample seed
2. edge-case augmentation from errors and escalations
3. adversarial additions from security
4. multi-turn additions from anonymized logs
5. quarterly refresh to retire stale examples and add recent failures fileciteturn0file0L91-L95

That process matters because a static dataset becomes misleading. A live product changes:

• policies change
• products disappear
• user behavior shifts
• new failure modes emerge

A golden dataset is not only a benchmark. It is a memory of prior failures.

4.4 Offline execution workflow

Step by step:

1. A pull request or model artifact is created.
2. The CI pipeline resolves the candidate version and baseline version.
3. The replay runner loads the current golden dataset version.
4. Each example runs through the full pipeline.
5. Raw outputs are logged.
6. Metric engine computes all scores.
7. Slice-level and global reports are generated.
8. Gates are applied.
9. PR is blocked or marked evaluation-passed.

The source already notes a runtime of about 25 minutes for 500 queries, which is practical enough for CI gating. fileciteturn0file0L126-L129

4.5 Math behind the golden-dataset metrics

A. Intent accuracy

If there are N labeled examples and C are classified correctly:

Accuracy = C / N

If 455 out of 500 are correct:

Accuracy = 455 / 500 = 0.91 = 91%

B. Precision, Recall, and F1 per class

For each class, for example recommendation:

Precision = TP / (TP + FP)
Recall    = TP / (TP + FN)
F1        = 2 * Precision * Recall / (Precision + Recall)

Why this mattered:

• overall accuracy can look strong
• a single high-value class can still be bad
• per-class F1 surfaces uneven failure patterns

That is exactly why the framework used per-class F1 thresholds. fileciteturn0file0L118-L124

C. BERTScore

BERTScore compares semantic similarity using contextual embeddings rather than exact word overlap.

Simplified intuition:

1. tokenize candidate and reference
2. embed each token using a contextual model
3. for each candidate token, find the most similar reference token using cosine similarity
4. aggregate similarities into precision / recall / F1-like scores

Cosine similarity between embedding vectors u and v:

cos(u, v) = (u · v) / (||u|| ||v||)

This is why BERTScore handles paraphrases better than BLEU. The original framework explicitly notes BERTScore correlated far better with online success than BLEU. fileciteturn0file0L324-L338

D. ROUGE-L

ROUGE-L uses Longest Common Subsequence to capture structural similarity.

If LCS(candidate, reference) is the longest common subsequence length:

Recall_L  = LCS / len(reference)
Precision_L = LCS / len(candidate)
F1_L = 2 * Recall_L * Precision_L / (Recall_L + Precision_L)

Why keep it at all?

• not as a primary helpfulness metric
• useful for detecting structural drift
• useful when a response format is expected to remain stable

E. Format compliance

If 492 of 500 outputs are parseable and conform to schema:

Format compliance = 492 / 500 = 98.4%

F. Guardrail pass rate

If 485 outputs pass safety, factuality, or product constraints:

Guardrail pass rate = 485 / 500 = 97%

G. Response length stability

Let L_new be the average candidate token count and L_base be the baseline average.

Length delta % = ((L_new - L_base) / L_base) * 100

If baseline is 120 tokens and candidate is 195:

Delta = ((195 - 120) / 120) * 100 = 62.5%

That matches the kind of response inflation issue described in shadow mode. fileciteturn0file0L155-L160

4.6 Why offline evaluation alone is not enough

Offline datasets cannot fully represent:

• unseen user distributions
• long-tail conversational phrasing
• live traffic patterns
• seasonal behavior
• cost and latency under real load

So offline gating is necessary, but not sufficient.

5. Layer 2: Shadow mode

5.1 What shadow mode does

The source describes shadow mode as running both old and new versions on the same real requests, while only serving the old version to users. fileciteturn0file0L130-L170

This is the safest way to compare production behavior without user exposure.

5.2 Engineering implementation

Step by step:

1. Real request arrives.
2. Request is sent to the production pipeline.
3. The same request is asynchronously duplicated to the candidate pipeline.
4. Production response goes to user.
5. Candidate response is stored only.
6. Diff service compares: - text quality - routing - retrieval evidence - latency - cost - guardrail outcome
7. Reports are aggregated by intent, locale, traffic slice, and failure type.

5.3 Why async fan-out matters

Do not put shadow inference inline on the critical path.

Why:

• doubles latency risk if inline
• raises blast radius if candidate times out
• complicates user-facing error handling

Instead:

• send to candidate asynchronously
• preserve request ID for joining outputs later
• allow late-arriving candidate logs

5.4 Shadow mode math and comparison

A. Metric delta

For any rate metric:

Delta = Metric_candidate - Metric_baseline

If guardrail pass rate moves from 98.0% to 97.2%:

Delta = 97.2% - 98.0% = -0.8%

B. Relative change

Relative change % = ((candidate - baseline) / baseline) * 100

If average tokens move from 120 to 195:

Relative change % = ((195 - 120) / 120) * 100 = 62.5%

C. Distribution comparison

Average alone can hide issues. Compare:

• p50 length
• p90 length
• p99 latency
• histogram shape

Example:

• mean may rise only 10%
• but p95 may double because of a small tail of very long responses

D. Routing-difference matrix

If baseline and candidate assign different intents, create a confusion-style matrix:

                 Candidate
              Rec  ProdQ  FAQ
Baseline Rec    820   70   10
Baseline ProdQ   25  910   15
Baseline FAQ      8   12  730

This directly shows which routes are drifting.

5.5 Why shadow mode improved quality

The source gives three excellent examples:

• emoji drift
• response length inflation
• intent classifier regression fileciteturn0file0L150-L160

Those examples show something important: many severe regressions are not catastrophic enough to fail in offline tests, but are still bad enough to hurt brand, latency, cost, or downstream behavior in production.

That is exactly what shadow mode is designed to catch.

5.6 Shadow mode cost decision

The source notes shadow mode can double inference cost for the test period and justifies that cost against the much larger risk of a bad full rollout. fileciteturn0file0L161-L170

This is a classic engineering trade-off:

• short-term infra spend
• versus long-term user trust, agent cost, and incident cost

6. Layer 3: Canary deployment

6.1 Purpose

Canary introduces controlled real-user exposure after shadow mode passes. The source uses a staged rollout with 1%, 10%, 50%, then 100%. fileciteturn0file0L172-L212

6.2 End-to-end rollout steps

1. Candidate is registered as a canary target.
2. Traffic splitter sends 1% of requests to candidate.
3. Baseline gets the remaining 99%.
4. Real-time metrics are computed separately.
5. Comparator checks hard thresholds.
6. Statistical checks determine whether differences are meaningful.
7. If safe, rollout increases.
8. If unsafe, auto-rollback executes.

6.3 Canary metrics

The source lists the major production metrics:

• escalation rate
• thumbs-down rate
• error rate
• P99 latency
• guardrail block rate fileciteturn0file0L184-L190

These are smart choices because they combine:

• UX quality
• reliability
• safety
• system performance

6.4 Math for rate monitoring

If there are n requests and x escalations:

Escalation rate = x / n

If candidate has 700 escalations out of 5,000 requests:

Rate = 700 / 5000 = 14%

If baseline is 12%, absolute increase is:

14% - 12% = 2%

6.5 Statistical significance for canary

The source already explains that 1% traffic can still provide enough data for some metrics if enough time passes. fileciteturn0file0L191-L201

A practical way to test a rate difference is a two-proportion z-test.

Let:

• p1 = x1 / n1 be baseline rate
• p2 = x2 / n2 be canary rate
• pooled rate p = (x1 + x2) / (n1 + n2)

Standard error:

SE = sqrt( p(1-p) * (1/n1 + 1/n2) )

z-score:

z = (p2 - p1) / SE

If |z| > 1.96, the difference is significant at roughly 95% confidence.

Example

Baseline: - n1 = 495000 - x1 = 59400 - p1 = 0.12

Canary: - n2 = 5000 - x2 = 700 - p2 = 0.14

Pooled:

p = (59400 + 700) / 500000 = 0.1202

Standard error:

SE ≈ sqrt(0.1202 * 0.8798 * (1/495000 + 1/5000))
   ≈ sqrt(0.1057 * 0.000202)
   ≈ sqrt(0.00002135)
   ≈ 0.00462

z-score:

z = (0.14 - 0.12) / 0.00462 ≈ 4.33

That is statistically significant, so the canary should not be promoted.

6.6 Why auto-rollback is critical

If rollback is manual only, then:

• on-call has to notice the issue
• triage takes time
• more users are impacted

The source explicitly includes automatic rollback triggers for error, TTFT, validation, and throttling. fileciteturn0file0L247-L252

This is what turns an evaluation framework into a production safety mechanism.

7. Layer 4: Continuous monitoring

7.1 Why monitoring is separate from rollout

A successful canary only proves safety under one window of traffic. It does not prove:

• long-term stability
• seasonality robustness
• changing query distribution
• model drift
• embedding drift
• slow cost inflation

That is why the source includes real-time, daily, and weekly layers of monitoring. fileciteturn0file0L214-L246

7.2 Monitoring hierarchy

Real-time metrics

Best for: - latency - errors - throttling - validation failures

Daily async metrics

Best for: - hallucination scoring - cost per session - thumbs trends - response length distribution

Weekly evaluation

Best for: - intent accuracy sample checks - RAG Recall@3 - BERTScore regression - confusion analysis - human audit

7.3 Drift detection math

A. KL divergence for intent distribution shift

If P is last week’s intent distribution and Q is this week’s distribution:

KL(P || Q) = Σ P(i) * log( P(i) / Q(i) )

Why it helps:

• if users suddenly ask different types of questions
• your observed quality shifts may be due to input drift, not only model regression

The source uses KL divergence thresholds for intent shift. fileciteturn0file0L236-L241

B. Confidence trend monitoring

If the average classifier softmax confidence falls from 0.89 to 0.80, it can indicate:

• data distribution shift
• class boundary confusion
• labeling mismatch
• degraded input quality

C. Embedding drift

The source mentions cosine similarity distribution shift for embeddings. fileciteturn0file0L236-L241

One practical method:

• compute embeddings for a fixed probe set each week
• compare new embedding vectors to historical baseline vectors
• monitor mean cosine similarity or nearest-neighbor stability

If the similarity distribution shifts strongly, retriever behavior may drift even if nothing obvious changed in generation.

8. Human evaluation workflows

8.1 Why humans are still necessary

Automatic metrics do not fully capture:

• subtle helpfulness
• misleading phrasing
• tone mismatch
• partial hallucinations
• nuanced policy issues

That is why the framework includes weekly audits and quarterly deep dives. fileciteturn0file0L254-L289

8.2 Weekly stratified audit

The source wisely uses stratified sampling rather than uniform random sampling. fileciteturn0file0L256-L274

That matters because random sampling often under-represents:

• high-impact intents
• rare failure types
• thumbs-down cases
• blocked outputs
• multi-turn coherence problems

8.3 Cohen’s kappa

The source reports inter-rater agreement with Cohen’s κ. fileciteturn0file0L274-L289

Formula:

κ = (Po - Pe) / (1 - Pe)

Where: - Po = observed agreement - Pe = expected agreement by chance

Example:

If two raters agree on 84% of items, and chance agreement would be 27%:

κ = (0.84 - 0.27) / (1 - 0.27) = 0.57 / 0.73 ≈ 0.78

That aligns with the source’s weekly audit agreement level.

Why it matters:

• proves labels are reliable enough to use
• avoids training or evaluating on noisy judgments

8.4 Human audit as a quality-improvement engine

Human review should not end as a dashboard number. It should feed:

• prompt improvements
• classifier retraining data
• retriever failure analysis
• guardrail tuning
• dataset refresh

This closes the loop from production behavior -> labeled failure -> training/eval improvement.

9. Retrieval evaluation and why it mattered so much

The source makes one of the most important findings: RAG Recall@3 correlated strongly with user satisfaction and often mattered more than intent accuracy. fileciteturn0file0L324-L347

That is a major engineering and ML insight.

9.1 What Recall@k means

If there is a set of gold relevant documents for a query and the retriever returns top-k documents:

Recall@k = relevant_docs_found_in_top_k / total_relevant_docs

If a query has 2 gold relevant documents and top-3 retrieval returns 1 of them:

Recall@3 = 1 / 2 = 0.5

If at least one correct grounding document is needed for answer quality, this metric becomes extremely important.

9.2 Precision@k

Precision@k = relevant_docs_found_in_top_k / k

If top-3 results contain 2 relevant docs:

Precision@3 = 2 / 3 ≈ 0.667

9.3 MRR (Mean Reciprocal Rank)

If the first relevant document appears at rank r:

Reciprocal Rank = 1 / r
MRR = average over queries

If relevant docs appear first for many queries, MRR is high.

9.4 Why retrieval often dominates generation quality

An LLM can only ground well if the context is strong.

Poor retrieval leads to:

• fluent but incorrect answers
• missing product facts
• weak recommendation relevance
• more hallucination guardrail hits

So improving model quality often means improving:

• chunking strategy
• metadata filters
• reranking
• embedding choice
• hybrid retrieval
• freshness handling

This is exactly the type of finding that shifts investment from “bigger model” to “better retrieval system.”

10. Offline-online correlation analysis

10.1 Why this was one of the smartest parts of the framework

The source measured correlations between offline metrics and online outcomes, and found that BERTScore and Recall@3 mattered much more than BLEU. fileciteturn0file0L324-L347

This is crucial because teams often optimize whatever metric is easiest to compute, not whatever predicts user success.

10.2 Pearson correlation intuition

If you measure an offline metric across releases and the corresponding online outcome across the same releases, Pearson correlation can quantify the relationship.

For variables X and Y:

r = cov(X, Y) / (σX * σY)

Where: - r = +1 means perfect positive correlation - r = -1 means perfect negative correlation - r = 0 means no linear correlation

If offline intent accuracy rises while escalation rate falls, that yields a negative correlation, which is good because better offline score means fewer escalations.

The source reports examples like: - intent accuracy vs escalation rate: negative correlation - Recall@3 vs thumbs-up: positive correlation - BERTScore vs resolution rate: positive correlation - BLEU vs thumbs-up: weak correlation fileciteturn0file0L324-L338

10.3 Why this made the framework possible

This analysis answered a foundational question:

Which offline metrics should we trust enough to gate releases?

Without that step, thresholds are mostly guesswork.

This was one of the biggest enabling factors behind the framework’s credibility.

11. Engineering choices that improved model quality

11.1 Living golden dataset

Why it helped:

• captured recent failure modes
• removed stale cases
• kept tests predictive of real traffic

This is directly supported by the source’s quarterly refresh process. fileciteturn0file0L91-L95

11.2 Per-slice analysis

Do not rely only on global averages.

Slice by: - intent - locale - user segment - query complexity - adversarial vs normal - multi-turn vs single-turn

This exposed weak pockets that overall averages hide.

11.3 Semantic metrics over lexical metrics

BERTScore outperformed BLEU for LLM quality prediction. That changed what the team optimized for. fileciteturn0file0L324-L347

11.4 Shadow mode before user exposure

This caught style, latency, cost, and routing drift without affecting customers. fileciteturn0file0L150-L170

11.5 Auto rollback on hard constraints

This reduced MTTR and limited blast radius. The source’s rollback triggers show strong production maturity. fileciteturn0file0L247-L252

11.6 Human audits feeding back into retraining

The labeling flow described in the source supports classifier retraining with disagreement handling and adjudication. fileciteturn0file0L290-L309

That turns evaluation from passive measurement into active improvement.

12. What actually made this evaluation framework possible

This is the most important deep-dive question.

The framework became possible because several enablers existed together.

12.1 Reproducibility

Every evaluation run needed reproducible inputs:

• versioned prompts
• versioned models
• versioned retriever config
• versioned datasets
• versioned guardrail rules

Without reproducibility, comparisons are not trustworthy.

12.2 Observability

The system had to capture:

• request IDs
• latency breakdowns
• retrieved docs
• classifier outputs
• model responses
• guardrail reasons
• cost/tokens

Without observability, you can detect regressions but not explain them.

12.3 Storage architecture

A practical pattern:

• raw evaluation records in S3
• aggregate metrics in Redshift / Athena / DynamoDB depending on access pattern
• dashboards in CloudWatch / QuickSight

Why raw logs matter:

• root cause analysis
• slice-level debugging
• replay and auditing
• post-incident review

12.4 CI/CD integration

The framework had to be wired into the release path.

If evaluation is optional, teams skip it under schedule pressure.

So the real enabling decision was making evaluation part of:

• PR checks
• deployment approval
• promotion logic
• rollback logic

12.5 Cross-functional process

The source implicitly shows collaboration between:

• engineering
• data science
• security
• human labelers / reviewers

This kind of framework cannot be built by one isolated role. It needs:

• DS for metrics and labeling
• engineering for automation and rollout safety
• product for UX impact metrics
• security for adversarial coverage

12.6 Cost awareness

Shadow mode is expensive, human review is expensive, and full evaluation takes time.

The framework became viable because the team could justify cost with clear ROI, which the source documents directly. fileciteturn0file0L361-L370

12.7 Mature failure culture

This kind of platform is possible when failures are treated as data, not embarrassment.

Every thumbs-down, escalation, misroute, or hallucination becomes:

• a dataset candidate
• a retraining candidate
• a shadow comparison case
• a guardrail tuning case

That mindset is what turns evaluation from a checklist into a learning system.

13. Step-by-step implementation plan

Phase 1: MVP

Build: - small golden dataset - replay runner - basic metrics - PR blocking

Goal: - stop obvious regressions before merge

Phase 2: Better offline signals

Add: - per-slice metrics - BERTScore - retrieval metrics - prohibited element validators - latency/cost reporting

Goal: - make offline evaluation more predictive

Phase 3: Shadow mode

Build: - async request duplication - dual-run logging - diff reporting - slice-based comparison dashboards

Goal: - safely compare candidate against production

Phase 4: Canary + rollback

Build: - traffic splitting - stage promotion policy - significance checks - auto rollback

Goal: - protect users during release

Phase 5: Continuous monitoring + audits

Build: - drift detection - weekly evaluation jobs - human audit sampling - quarterly deep-dive workflow

Goal: - sustain quality, not just ship quality

14. Interview-ready summary

A strong Amazon-style summary would be:

I built the model evaluation framework as a production release gate, not just a metrics report. The system used four layers: offline golden-dataset regression, shadow mode on real traffic, canary rollout with statistical checks, and continuous monitoring with rollback triggers. The key engineering decision was to evaluate the full application path — routing, retrieval, generation, validation, and formatting — because many regressions happen outside the base model. On the ML side, the biggest quality gains came from using a living golden dataset, semantic metrics like BERTScore, retrieval metrics like Recall@3, confusion-driven classifier retraining, and human audits that fed back into labeling and dataset refresh. The framework became possible because we had reproducibility, observability, CI/CD enforcement, and strong offline-online correlation analysis.

15. Final takeaway

What made the framework powerful was not any single metric.

It was the combination of:

• reproducible datasets
• full-pipeline evaluation
• multi-stage release safety
• statistical reasoning
• semantic and retrieval-aware metrics
• human review loops
• continuous monitoring and rollback
• feedback from production failures back into training and evaluation

That is what transformed evaluation from an ML experiment into an engineering system that materially improved model quality, reliability, and release confidence.