Open Action Contract Lab

Can Correct Data Prevent Hallucinations?

Working article · November 7, 2026

Reliable data can improve a model. On its own, it cannot guarantee correct answers.

Filtered data, training, and evaluation are distinct stages
Conceptual illustration, not measured results.

The short answer

The idea has a sound core: training examples differ in quality, and a strong teacher can help teach a smaller model. Knowledge distillation is a real approach. The DeepSeek-R1 model card describes smaller models trained on examples produced by a larger model. That establishes a precedent, not a result achieved by our project. [3]

But "all the information is correct, so every answer will be correct" skips several steps. A model is not a database that returns only verified sentences. It learns an approximation from examples, encounters unseen questions and constructs new answers. True examples matter for reliability, but they do not guarantee every possible generalization.

Why true examples are not enough

First, truth is not complete coverage. A dataset can contain a thousand correct birth dates and still say nothing about the next person's birthday. If the examples contain no pattern from which that answer can be inferred, removing falsehoods will not create the missing fact.

Second, learning can be imperfect. Even with correct labels, the chosen model, number of examples, training method or representational capacity may be unsuitable. Accurate data and an accurate learned function are different things.

Third, a statement that is true in one context can be false in another. Date, units, person, place and the question's assumptions are part of correctness. An answer that used to be true may no longer be current.

Fourth, a system must learn when not to answer. "Why Language Models Hallucinate" analyzes how errors can arise even with error-free training data, under its mathematical assumptions. It also argues that evaluations which reward guessing and penalize abstention encourage confident wrong answers. This is not a theorem that every system must lie: the paper notes that a system which always says "I don't know" can avoid errors at the cost of low usefulness. [1]

The small experiment we ran

To test part of the idea rather than leave it entirely theoretical, we trained two small classifiers on the same synthetic task: does a proposed amount exceed an authorized spending cap? Each example contains two numbers, and the correct answer is computed exactly. This is not natural language or a language model. It uses no personal data, paid API or real financial action.

We generated unique numeric pairs: 2,000 for training and 4,000 different pairs for testing. One logistic-regression classifier received correct labels. The other received the same examples, with exactly 200 labels deliberately flipped. This is artificial 10% label noise, not a measurement of teacher quality. Features, algorithm, 2,500 training steps and random seed were held constant.

Clean training labels
29 errors / 4,000; 99.275% accuracy
10% incorrect training labels
97 errors / 4,000; 97.575% accuracy
Unseen numeric scale
Both models: 202 errors / 404
Exact arithmetic baseline
Zero errors across all test sets

Clean labels helped in this run, but did not eliminate errors. On the held-out set, the clean model wrongly allowed 13 over-cap amounts and wrongly flagged 16 valid amounts. On the specific unseen-scale test, both models fell to 50% accuracy.

When do several teachers help?

If three teachers were each correct with probability 0.9, their errors were independent and we chose the majority answer to a binary question, the probability of a correct majority would be:

0.9³ + 3 × 0.9² × 0.1 = 0.972

That is 97.2%, conditional on those assumptions. It is not an observed accuracy for Gemini, OpenAI or DeepSeek.

The problem is dependence. Three models may fail on the same topic in the same way. If all three always agree, majority voting does not improve 90% to 97.2%; it remains 90%. Agreement can be a useful filter, but it is not a certificate of truth. Open-ended questions also require a definition of what counts as the same answer and what counts as correct.

Teachers therefore produce candidate examples. An external verifier, when available, decides whether to accept them. Code can be checked with tests; arithmetic with exact calculation; factual claims with suitable dated sources. Ambiguous questions may need human review or an "unknown" label. Not every problem offers an equally reliable verifier.

Why not train only on model answers?

The Nature paper on model collapse demonstrates a risk from repeated, indiscriminate training on model-generated data: rare parts of a distribution can disappear across generations. This warns against blind recycling. It does not establish that all synthetic data is harmful or that every distillation attempt fails. Anchor data, diversity, independent evaluation sources and ways to detect failures remain important. [2]

Aggressively removing everything difficult to verify can also create a clean but narrow dataset. A model may learn easy examples well and fail on precisely the unfamiliar cases we care about. Quality therefore requires coverage as well as cleanliness.

From an interesting idea to a trustworthy test

The next step is not to increase the volume of messages to teachers. It is to choose a useful task with checkable ground truth. Around Action Contract Lab, one possible research task is matching a user's request to a proposed action, including equivalent wording, changed permissions and missing information. That is harder than comparing two numbers. This experiment has not solved it.

Before training, separate evaluation examples by scenario family and source, rather than merely shuffling similar phrasings. Record who generated each example, how it was checked and what use is permitted. Compare a simple rule, a baseline model and a model trained on filtered labels. Measure false allows, false blocks, abstention and coverage separately. Test new scales, languages and phrasings too.

If an improvement does not survive beyond the training examples, report the failure rather than an impressive number without context. A serious reusable package should contain weights, inference and training code, a data description, usage terms, versions and evaluation results. Someone else should be able to reproduce the result and understand when not to use the model.

A short execution note

Sending messages to teachers creates data; it does not train the student's weights or replace compute. The environment checked for this experiment had two CPUs and no available GPU. The experiment therefore ran in NumPy, without CUDA or payment.

Free access does not always permit the same uses. OpenAI and Gemini terms restrict developing competing models. DeepSeek expressly permits training and distillation from outputs, but also restricts automated collection. No chatbot scraping or requests for training-data generation were performed. These details affect execution, not the validity of the research question. [4–6]

Conclusion

The stronger version of the idea is not "only truth in training, zero errors in answers." It is "verified examples, good coverage, the ability to abstain and incentives to be correct rather than merely to answer." Cleaner data can be part of the solution. To build a model others can trust, we must establish where it helps, when it is insufficient and how it improves on a simpler check.

Sources and experimental record

[1] Why Language Models Hallucinate

[2] AI models collapse when trained on recursively generated data

[3] DeepSeek-R1: model card and distillation

[4] DeepSeek Terms of Use

[5] OpenAI Europe Terms of Use

[6] Gemini API Additional Terms

Sources 1–3 are research papers and an author-published model card, not independent validation of this project's results. Sources 4–6 are service terms checked on November 7, 2026. Local experimental results come from experiment.py, results.json and weights.npz in a local experiment package; that package is not included in this article publication. They are not results from an external paper.

Explore the work

Hugging Face · LinkedIn · GitHub