Can AI Tell When Evidence Is Not Enough?

Enas Amin — Sun, 11 Oct 2026 11:16:11 +0000

What I Benchmarked

Can a language model distinguish between an answer supported by available evidence and one that requires an unsupported assumption?

This is the central question behind Evidence Sufficiency Evaluation, a benchmark I built to investigate how models respond when evidence is incomplete, changes in a relevant way, contains unresolved conflicts, or appears misleadingly relevant.

The motivation is simple: producing a plausible answer is not the same as producing a justified answer. A model should respond to the evidence it receives rather than confidently filling gaps with assumptions.

My benchmark contains 72 test cases designed to examine this behavior through controlled minimal pairs and adversarial controls.

Explore the benchmark:

https://www.kaggle.com/benchmarks/enasamin99/evidence-sufficiency-evaluation

How I Benchmarked

The evaluation contains two complementary groups of test cases.

1. Minimal Pairs: 60 Cases

The benchmark includes 30 minimal pairs across six categories.

Within each pair, the question remains fixed while a relevant fact changes. This design tests whether a model responds appropriately to the change in evidence rather than relying on superficial patterns or producing the same answer regardless of the information provided.

The key question is not simply whether an individual answer is correct. It is whether the model's answer tracks the relevant evidence.

2. Adversarial Controls: 12 Cases

The remaining 12 cases cover three challenging situations:

Unresolved conflicts: the available evidence does not settle a contradiction.
Unsupported presuppositions: a question assumes something that has not been established.
Near-match distractors: information looks relevant but does not adequately support the requested conclusion.

These cases examine whether a model recognizes the limits of the available information instead of accepting a plausible but unsupported conclusion.

Scoring Method

The benchmark uses expected labels, strict label parsing, and case-level correctness. The score reflects the proportion of test cases for which the model produces the expected label.

This approach makes the results straightforward to compare, but it has a limitation: a model may fail because it does not follow the required response format, even if its reasoning is defensible. Conversely, a correct label does not prove that the model arrived at it through sound reasoning.

For that reason, I interpret the score as performance on this particular evaluation protocol rather than a complete measure of reasoning ability.

Models Tested

My model evaluations included:

Gemini 2.5 Flash
Claude Haiku 5.5
Gemini 3.7 Flash

The public benchmark view currently displays a result for Gemini 3.7 Flash. The other model results are not currently visible alongside it in that view, so I do not present an unverified ranking or claim that one model outperformed all the others.

A fair comparison requires completed, accessible evaluations under comparable conditions.

Findings

The current public leaderboard displays a score of 1.00 for Gemini 3.7 Flash.

This is an encouraging result on the displayed evaluation set. However, a perfect score on 72 fixed cases does not establish that a model will perform perfectly on unseen examples, nor does it prove that the model is generally superior to other models.

The most important contribution of this experiment is the evaluation design itself: it makes evidence sensitivity an explicit target rather than assuming that ordinary question-answering accuracy captures it.

The minimal pairs provide a controlled way to examine responses to relevant changes in evidence. The adversarial controls examine situations in which the model may need to reject an unsupported premise or recognize unresolved information.

The next step is to analyze individual cases and compare completed model evaluations to determine which categories produce the most errors and whether those errors follow systematic patterns.

What I Learned

This project reinforced three lessons about evaluating language models.

First, accuracy is not the whole story. A model may produce the expected answer on a particular case without demonstrating robust evidence-sensitive reasoning.

Second, controlled examples are useful. Minimal pairs help isolate the effect of a relevant fact, making it easier to investigate whether the model's answer responds to the information that matters.

Third, evaluation claims must match the available evidence. A visible score can support a statement about that particular result, but broader claims require more comparisons, repeated testing, and analysis of errors.

These lessons motivate further work on evaluation sets that measure not only whether a model answers correctly, but also whether its answers are justified by the information available to it.

Limitations and Future Work

This benchmark is a finite test set, not a comprehensive measure of intelligence or reasoning.

Its results may depend on prompt wording, model versions, inference settings, and label-parsing rules. Aggregate scores can also hide differences between categories and individual failure patterns.

Future work should focus on:

Reporting separate scores for minimal pairs and adversarial controls.
Examining individual errors and disagreements.
Repeating evaluations to assess stability.
Expanding the benchmark with new cases that reduce the risk of overfitting to familiar patterns.
Comparing accuracy, latency, and inference cost using verified measurements.

These improvements would help establish whether high performance generalizes beyond the current test cases.

My Benchmark

Evidence Sufficiency Evaluation is available here:

https://www.kaggle.com/benchmarks/enasamin99/evidence-sufficiency-evaluation

The benchmark is intended to support transparent experimentation on whether model responses track the evidence provided, especially when a relevant fact changes or the available information does not justify a confident conclusion.

I welcome independent evaluations, additional models, and feedback on how to improve the test design.

kagglechallenge #devchallenge

DEV Community: Enas Amin