Evaluation & operations · Explore this field ↗ · Practice · 2 min read
Evaluate conversations before launch
A demo proves possibility. A test set probes whether the service behaves correctly across ordinary and adversarial cases.
Evaluate the journey, not one answer
A conversation can contain individually plausible turns and still fail the task. Build scenarios with starting state, user goal, allowed information, expected actions, forbidden actions, and acceptable end states. Include paraphrases, missing fields, corrections, topic changes, repeated questions, hostile instructions, unavailable tools, and human requests.
Use several score layers
Measure routing and intent where applicable; retrieval recall and entitlement; factual support and citation fit; tool selection and argument validity; policy compliance; task completion; repair cost; latency; and handoff quality. A single model-graded score hides tradeoffs. Keep deterministic checks for actions and permissions even if an LLM helps assess prose.
Golden responses are not scripts
Reference answers help establish required facts and exclusions, but many good phrasings are possible. Google’s playbook evaluation uses test cases and golden responses, while its experiment tools expose no-match and handoff metrics. Pair offline suites with controlled live pilots and human review of sampled failures.
Operator note
Version tests with knowledge, prompts, tools, and model settings. Block release on safety and authorization regressions. Treat improvements on average as insufficient if a vulnerable cohort or high-consequence task gets worse.
Construct a balanced suite
Begin with real task frequencies, then deliberately over-sample expensive and dangerous failures. Include clear requests, ambiguous phrasing, wrong assumptions, stale policy, unauthorized data, unavailable tools, prompt injection, explicit human requests, and users who abandon. Label expected source, permitted action, required disclosure, and acceptable ending. Maintain separate smoke, regression, safety, and long-running sets. A release can improve average task score while failing a safety gate; the suite should make that trade impossible to hide.
Keep disputed cases
When reviewers disagree, retain the case with both rationales and send it to the policy or product owner. Removing ambiguous examples makes the score cleaner but the service less honest. Disagreement often exposes an unclear rule that users and operators will also encounter.
Primary reading
Sources and limits
These links support the architecture, policy, or product behavior discussed above. Vendor documentation describes vendor features; it is not independent proof of performance. Current details should be rechecked before a production decision.