Notifications
Clear all
Topic starter
19/08/2026 3:37 pm
TL;DR: LLM evals work best when treated as ordinary tests in CI, because non-determinism, cost, latency, and LLM-as-judge scoring make hard gates and trend signals do different jobs, according to Arize. The implication is that agent and application governance now depends on versioned, repeatable checks, not ad hoc prompts or one-off reviews.
NHIMG editorial — based on content published by Arize: Evals in CI: How to write your LLM evals as tests with Arize Phoenix
Questions worth separating out
Q: How should security teams test AI agents that can call tools and APIs?
A: They should test the agent's actual execution paths, not just its text responses.
Q: Why do LLM evals need different controls from ordinary software tests?
A: Because LLM outputs are not fully deterministic, a single passing run cannot prove the behaviour is stable.
Q: What do teams get wrong when they treat evals as one-off checks?
A: They usually over-focus on the prompt or output and ignore the evaluation design itself.
Practitioner guidance
- Define hard invariants for agent behaviour Identify the smallest set of outcomes that must never fail, such as refusal rules, tool access boundaries, or required output formats, and make those release-blocking assertions in CI.
- Separate trend metrics from build gates Record helpfulness, latency, and groundedness as monitored signals, then set pass-rate or threshold criteria so CI fails only when a critical boundary is crossed.
- Version eval cases alongside application code Store scenarios, expected behaviour, and judge criteria in the repository so teams can diff changes, reproduce failures, and tie behaviour drift to specific commits.
What's in the full article
Arize's full article covers the implementation detail this post intentionally leaves for the source:
- pytest and Vitest/Jest examples that show how to structure evals as executable tests
- Phoenix logging patterns for traces, outputs, annotations, and experiment tracking
- Acceptance-criteria examples for suite-level quality thresholds and latency gating
- A full support-bot walkthrough showing invariants versus scored signals in practice
👉 Read Arize's guide to writing LLM evals as CI tests in Phoenix →
LLM evals in CI: what should security teams test first?
Explore further
19/08/2026 4:17 pm
LLM evals are becoming the missing control layer for AI governance. The article shows that ordinary test frameworks can carry evaluation logic, which is useful because most organisations still lack a repeatable way to prove that agent behaviour stays inside policy. For identity and governance teams, the real issue is not the test runner itself but whether the underlying decision system is measurable, versioned, and auditable. That is where AI RMF governance expectations meet operational control, and it is where teams should treat eval design as a governance function, not a developer preference.
A question worth separating out:
Q: How do you know if agent evaluation is actually working?
A: It is working when it explains failures well enough to change the system, not just when it outputs a score. Good evaluation should point to the layer that failed, produce a reproducible trace, and feed confirmed failures into regression tests. If the score does not change engineering decisions, it is not yet operational.
👉 Read our full editorial: LLM evals in CI expose the control gap in agent governance
