Use offline evaluation to decide whether a release is ready
Offline evaluation is best treated as a qualification gate, not a complete prediction of production behavior. Before a release, it should reveal regressions, known safety failures, and weak boundary conditions through repeatable tests. A useful enterprise test set includes more than polished questions with obvious answers. It should cover abbreviations, typing errors, missing context, conflicting documents, stale content, permission differences, unsupported requests, and attempts to make the system exceed its authority. Historical interactions can contribute valuable examples after access review and de-identification, while engineers and domain experts should add adversarial cases that have not yet appeared in logs.
The evaluation design should mirror the system architecture. For RAG, assess retrieval coverage, ranking, answer grounding, citation accuracy, and refusal behavior separately; a fluent final response can conceal retrieval from the wrong document. For an agent connected to ERP, CRM, LINE, or an internal API, test tool selection, arguments, authorization, confirmation steps, retries, and partial failures. Deterministic checks, model-based judges, and human review can complement one another, but a judge model should be calibrated against expert-labelled examples. Human approval remains appropriate when outputs affect legal, financial, security, or system-of-record decisions.
- Maintain a stable regression suite:Preserve critical workflows and previously observed failures so releases remain comparable.
- Review meaningful slices:Break results down by task, data source, language, permission level, and risk instead of trusting one aggregate score.
- Define failure categories:Distinguish wrong answers, unsupported claims, missing citations, formatting failures, tool misuse, and inappropriate disclosure.
- Make runs reproducible:Record the model, prompt, retrieval configuration, document snapshot, application code, and evaluator version.
Use online evaluation to determine whether the system is useful
A system that passes offline tests will still meet production conditions the dataset did not anticipate: new internal terminology, delayed document updates, multi-turn clarification, unusual API responses, and users adapting their behavior around the assistant. Online evaluation should therefore measure the full task rather than relying only on thumbs-up feedback. Relevant signals include task completion, escalation to a person, repeated query reformulation, citation use, cancelled actions, manual corrections, and downstream validation failures. Each signal needs context. A rapid handoff may indicate poor model performance, but it may also show that a safety control worked exactly as intended.
Online experimentation does not always mean exposing every user to a conventional A/B test. When the system touches payments, customer records, inventory, contracts, or physical equipment, start with shadow execution: let the candidate version process production inputs without displaying responses or committing actions. A later canary can restrict eligible users, records, or tools before broader release. Lower-risk knowledge assistance can move faster, but it still needs traceability across model and prompt versions, retrieved documents, tool calls, latency, errors, and escalation reasons. Without that trace, a team may know that users are dissatisfied but cannot locate whether the cause is the model, source data, integration service, or workflow.
Allocate responsibility according to risk and reversibility
The balance between offline and online evidence should follow the consequence of failure, not the novelty of the model. An assistant that drafts internal text for review can tolerate a faster online learning cycle because a person can inspect the result before use. A system that updates CRM records, creates orders, changes device settings, or communicates directly with customers requires stronger offline scenario coverage, scoped permissions, explicit confirmation, and gradual rollout. Engineers should ask whether an error will be visible, whether the action can be reversed, whether its blast radius can be constrained, and whether the candidate version can be disabled quickly.
Release criteria are most useful when written as an engineering contract. Specify which offline behaviors cannot regress, which safety checks must pass, which production signals will be monitored, what conditions will stop rollout, and which model, prompt, index, or service configuration must be restored during rollback. The criteria may evolve, but changes should be deliberate and recorded. In lower-volume enterprise workflows, a team may not receive enough traffic for a clean statistical conclusion. Task-level traces, expert review, shadow comparisons, and concrete failure analysis are then more informative than treating the absence of reported incidents as evidence of safety.
Connect both modes in one learning loop
Mature teams do not maintain an offline scorecard and an online dashboard as unrelated systems. Production evidence should continuously improve the offline suite. Sample escalations, low-confidence outputs, tool errors, and user corrections; after checking authorization and removing sensitive data, convert representative failures into regression cases. In the other direction, each important offline failure class should have a corresponding production trace field, alert, or review queue. This makes recurrence identifiable after release. Teams must also prevent test answers from leaking into prompts or indexed knowledge, since an apparent score improvement may otherwise reflect memorization rather than better behavior.
Clear ownership keeps the loop operating. Product owners define successful task outcomes, domain experts decide whether an answer is usable, AI and data engineers maintain evaluation sets and model checks, and platform teams provide observability, access control, and dependable rollback. An integration team can help turn these responsibilities into one delivery pipeline: validate every model, document, and interface change offline; observe it under controlled production exposure; and feed new evidence into the next development cycle. The result is not a perfect score, but a system whose risks, behavior, and business value remain inspectable as it changes.