AI Evaluation, Tracing, Drift, Latency, and Cost

AI quality is a versioned measurement system, not a demo judgment. Store representative questions, expected evidence, allowed/refused behavior, tenant policy, evaluator versions, and human labels. Trace ingestion, retrieval, reranking, generation, validation, and tools separately. Release gates balance relevance, groundedness, authorization, safety, latency, availability, and cost while monitoring drift after deployment.

What will you be able to do?

• Model datasets, cases, runs, candidates, answers, judgments, and traces.
• Separate retrieval from generation metrics.
• Establish regression gates and human-review calibration.
• Detect data/model/policy drift and enforce latency/cost budgets.

Prerequisites and mental model

Evaluation has layers:

1. ingestion correctness and freshness;
2. retrieval recall/ranking and authorization;
3. answer support, completeness, refusal, and citation;
4. tool correctness and policy;
5. operational latency, error, and cost.

A single “quality score” hides failure causes.

What should PostgreSQL store?

Store immutable dataset versions, case IDs, tenant/policy fixtures, expected source/version IDs, run configuration, prompt/model/embedding/chunker/retrieval versions, candidate ranks/scores, output references, evaluator/human judgments, trace IDs, stage timings, tokens/cost units, and terminal errors. Restrict sensitive content and retain only what the evaluation purpose requires.

Metrics may include recall@k, MRR/NDCG where appropriate, no-answer/refusal correctness, grounded claim rate, citation precision/recall, unauthorized candidate/answer rate (target zero), tool success/denial correctness, p50/p95 latency, cost per successful task, and failure rate.

Automated model judges can scale review but have bias and drift. Version judge prompts/models, blind/randomize comparisons, calibrate against human labels, and never let a judge replace deterministic security tests.

Why is this AI-native?

Evaluation data belongs beside operational lineage so a regression can be traced to source, chunker, index, filter, prompt, model, or policy. PostgreSQL constraints and joins make configuration completeness and cross-run comparison auditable.

Prove it worked

Create a fixed dataset containing exact, semantic, stale, unauthorized, ambiguous, adversarial, and no-answer cases. Run a baseline and candidate. A release passes only if zero authorization regressions occur and declared quality/latency/cost thresholds hold with reviewed variance. Replay a production trace without exposing tenant content.

Production judgment

• Production feedback is biased; sample intentionally.
• Metric movement may reflect corpus or traffic shift, not model change.
• Store monetary units and provider pricing version explicitly.
• High-cardinality traces and content retention create cost/privacy risk.
• Canary/shadow rollout and fast rollback complement offline tests.

Common mistakes

• Demo questions only: dataset not representative → stratify real intents and failures.
• Answer score hides retrieval miss: layers combined → evaluate candidates and answer separately.
• Judge score treated objective: no calibration → compare with humans and deterministic checks.

AI Pair-Programmer Prompt

Hands-on exercise

Create a 30-case release rubric for SignalDesk RAG with at least five authorization/adversarial and five no-answer cases.

Acceptance criterion: the rubric separates layers, versions all inputs, uses zero-tolerance security gates, and defines candidate-versus-baseline rollout.

Knowledge check

1. Why separate retrieval and answer evaluation?
2. Can good average quality offset one cross-tenant leak?
3. Why version model judges?

---

Answers

1. An answer can fail because evidence was not retrieved or because generation misused good evidence.
2. No; authorization is a hard gate.
3. Their behavior changes with model/prompt and requires calibration/reproducibility.

Completion checklist

• Dataset and configurations are immutable/versioned.
• Layered metrics locate failure.
• Security gates are deterministic and zero tolerance.
• Latency, cost, drift, canary, and rollback are operationalized.

Primary references

• PostgreSQL table partitioning
• PostgreSQL monitoring
• pgvector monitoring guidance