Practical guide · · By Raz Dagan
How to build a held-out evaluation set for an LLM-to-code replacement
Turn recorded production examples into a reviewable held-out set that tests supported cases, boundaries and fallback behavior before code replaces an LLM call.
Start with the behavior you intend to preserve
An evaluation set is useful only when it represents a specific transformation. Write the input contract, expected output shape and downstream use before selecting examples. A support classifier, a field normalizer and a summarizer may all receive text, but they require different evidence and failure rules.
ModelGate can propose deterministic code from recorded examples, and its generated implementation is reviewed and evaluated before you choose to use it. The code runs inside your application. ModelGate does not execute Python ports, and a generated port should not be treated as verified merely because another language passed an evaluation.
Separate construction examples from held-out examples
Use one group of examples to understand the task and construct the candidate. Keep another group unseen until the behavior is fixed. If the same edge case is used to write a branch and then counted as proof that the branch works, the result measures recall of that case rather than general behavior.
Record why each held-out case exists without exposing unnecessary customer content. A short identifier, sanitized input, expected output and rule being tested are usually more useful than a dump of full prompts. Preserve permission and retention boundaries when production records are involved.
Cover ordinary cases and boundaries
Begin with common supported inputs, then add boundaries: missing optional fields, empty strings, unusual but valid values, maximum expected lengths and explicit unsupported versions. Do not manufacture an impressive count by duplicating nearly identical examples. Each case should test a meaningful rule.
For a fictional ticket router, one case might test a recognized category, one an unknown category, one a missing customer tier and one text that contains a category word in a quoted message. Label fictional examples as such and do not report their result as customer performance.
Define comparison rules before running the candidate
Exact string equality may be right for a normalized code and wrong for a structured explanation. Compare the fields that downstream code actually consumes, including types, required keys and allowed absence. Decide whether ordering, whitespace or casing matters before seeing the candidate's output.
Include invalid output and exceptions as explicit failures. Agreement with the previous model is not automatically correctness; the earlier output may be wrong. Where possible, anchor expected results in product rules or human-reviewed examples and keep disagreements visible for review.
Test fallback behavior as part of the set
A candidate should be evaluated on what it refuses as well as what it handles. Add unsupported inputs and verify the application takes the intended fallback or rejection path. A function that silently returns an empty success for every unknown input can look stable while losing information.
Measure supported-case accuracy separately from coverage. A candidate can be correct on a narrow supported subset and still send most traffic to the provider. Track the fallback reason with bounded metadata rather than storing raw customer text in a metric.
Freeze the set for a release decision
Version the candidate, evaluation set and acceptance rule together. Run them in a repeatable environment and preserve failures. If you change code after inspecting a held-out failure, that example has influenced construction; move the release decision to a fresh held-out slice.
Use the report to decide whether to review, revise or stop. Do not turn a match percentage into a savings claim without measuring real eligible traffic and fallbacks. ModelGate's documentation and demo can help assess the workflow, while your team remains responsible for the task contract, code review, deployment and monitoring.
Explore the workflow
Read the code-replacement requirements, GitHub workflow and gateway comparison before deciding.