Metamorphic Testing for LLM Prompts

You cannot assert that a model’s answer is right, because you do not have the right answer. You can assert that two answers stand in the relationship they must stand in. That substitution is thirty years old, it has a name and a literature, and it is the most transferable idea in this whole cluster.

The oracle problem, stated properly

A test oracle is whatever tells you a result is correct. For sort the oracle is easy. For a compiler, a numerical solver, a search engine or a language model it is often unavailable: computing the expected output would mean reimplementing the system, and the whole reason you called it is that you cannot. Software testing calls this the oracle problem, and it is not an AI-era phenomenon.

Metamorphic testing is the standard answer. It was introduced by Chen, Cheung and Yiu in 1998 in Hong Kong University of Science and Technology technical report HKUST-CS98-01, Metamorphic testing: a new approach for generating next test cases. Segura, Fraser, Sánchez and Ruiz-Cortés surveyed the field in IEEE Transactions on Software Engineering in 2016, and Chen and colleagues published Metamorphic Testing: A Review of Challenges and Opportunities in ACM Computing Surveys in 2018. It has been applied to compilers, search engines, machine translation and, more recently, to language models directly — Hyun, Guo and Babar’s METAL framework, presented at ICST 2024, is built entirely on defining metamorphic relations as the evaluation metric.

What a metamorphic relation is

A metamorphic relation is a necessary property linking multiple inputs and their outputs. The canonical illustration is trigonometric: you may not know what sin(x) should be, but you know sin(x) == sin(180 - x) in degrees, so you can run the function twice and check the relation without ever knowing the value. The test has three parts: a source input, a transformation that produces a follow-up input, and a relation the two outputs must satisfy.

The natural-language version of this taxonomy already exists. Ribeiro, Wu, Guestrin and Singh’s CheckList, the ACL 2020 best paper, names three test types: minimum functionality tests, invariance tests where a change should not alter the prediction, and directional expectation tests where a change should alter it in a known direction. The last two are metamorphic relations under a different name, and the naming is worth borrowing because it keeps the two kinds separate in your head.

Relations that transfer to prompts

Invariance relations — the output must not change:

• Paraphrase the question, keeping the meaning. The extracted decision must be identical. This is the workhorse, and implementing it properly is more subtle than it looks.
• Reorder independent items — the order of retrieved documents, the order of keys in a JSON input, the order of options in a list. Order sensitivity here is a real and well-documented failure, and asserting invariance is how you find yours.
• Substitute an irrelevant entity. Change the customer’s name, the city, the account id. If the decision moves, either the model is keying on something it should not or your prompt has a leak.
• Add semantically null content: extra whitespace, a polite preamble, a signature block. Cheap to generate mechanically, and a surprisingly good detector of prompt fragility.

Directional relations — the output must change, and the direction is known even though the value is not:

• Negate the decisive fact. “The parcel arrived” becomes “the parcel never arrived”; the decision must flip. Negation is the relation that catches the model skimming, and it is the one an embedding-similarity check cannot see.
• Add a disqualifying fact. The decision may stay where it is or move toward decline; it must never move toward approve. Note the shape: a one-sided assertion is testable where an equality is not.
• Remove the field the answer depended on. The output must become the “insufficient information” branch. If it produces the same confident answer without the evidence, you have found a hallucination with a reproducible trigger.
• Strengthen the evidence for the existing conclusion. Any confidence or score field must not decrease. Monotonicity is assertable when exact values are not, and it is the most under-used relation on this list.

The transformation is the weak point

The relation is only as trustworthy as the transformation is faithful. If your paraphraser quietly changes the meaning, the model’s different answer is correct and your test reports a bug that is not there. False failures are more expensive than missed bugs in a suite that people have to triage, so this is the part to be conservative about.

The strong preference is for mechanical transformations: reordering, whitespace, field renaming, entity substitution from a fixed table, changing a locale field. These are provably meaning-preserving because you can read the code that makes them, they cost nothing, and they compose with a generator. Where you need genuine paraphrase, generate the variants once — by hand or with a model — have a human check them, and commit the result as a fixed file. A paraphrase produced live inside the test makes the transformation non-deterministic, which means a failure is no longer attributable to anything.

Where the technique stops working

Metamorphic testing tells you two outputs are inconsistent. It does not tell you which of them is wrong, and it cannot tell you that both are wrong in the same way. A model that confidently declines every request satisfies almost every invariance relation on this page. So these tests catch instability and fragility, not systematic error, and they need a labelled set alongside them to catch the latter — the two techniques cover different blind spots and neither substitutes for the other.

The second limit is relation strength. A relation that is too weak passes on a broken system: “the output is still valid JSON after I add whitespace” is technically metamorphic and worthless. The useful relations are the ones where you can articulate what a violation would mean for a user, and if you cannot, the relation is decoration.

The third is cost. Every relation doubles the calls, since each source input needs its follow-up. Directional relations that require three or four variants multiply further. Pick the relations by expected yield rather than by how many you can think of, and be explicit that a metamorphic suite is a per-run bill, not a fixed one.