A tie is a result, not a failed test

An evaluation that ends with two candidates scoring within noise of each other often gets treated as a failure of the evaluation, and the usual response is to keep adding examples until a gap appears. That instinct inverts the logic. If a difference is not visible on a set drawn from the work you actually do, then on that work there is no difference worth paying for.

What a tie licenses

A genuine tie moves the decision onto the other axes, which are usually easier to measure and harder to argue about: cost per request, latency at your input lengths, output stability across reruns, how the system behaves when the input is malformed, and what happens operationally when a version changes underneath you. Deciding on those grounds is not a consolation prize; it is a better-founded decision than one made on a quality gap too small to detect.

Before you accept the tie

Check that the set is capable of showing a difference at all. If every candidate scores near the ceiling, the examples are too easy and the test has no resolution left - replace the easiest third with harder cases drawn from real failures. Check too that the judgement rule is tight enough to separate a good answer from an adequate one. A tie under a coarse rule and a tie under a sharp one are different findings.