Proposal: an optional reliability mode that improves answers, verifies factual claims, and abstains when evidence is insufficient

[mlpbcn]

Hi,

I use local language models as a general daily assistant, and DeerFlow 2.0 is one of the closest projects I have found to the kind of application I would like to use long term.

The feature I care about most is not simply generating longer answers or using more tools. I would like an optional reliability mode whose purpose is to produce a better final answer than the base model would normally give on its own, while reducing unsupported claims and refusing to guess when the available evidence is not enough.

I am not asking for a promise of zero hallucinations. I am asking for a mode with a clear process and measurable guarantees about what happens before a factual answer is shown to the user.

What I mean by improving the model's answer

For simple questions, DeerFlow should be able to use the model directly when extra processing would add no value.

For factual, current, complex or high-risk questions, the reliability mode could use a more careful pipeline:

1. Understand the question and identify which parts need verification.
2. Decide whether web search, local documents, code execution, calculation, memory or another tool would improve the answer.
3. Gather targeted evidence from appropriate sources.
4. Produce an initial answer.
5. Extract the important factual claims from that answer.
6. Check whether each important claim is actually supported.
7. Detect contradictions, outdated information and missing context.
8. Critique and repair the answer before showing it to the user.
9. Abstain, or answer only partially, when the evidence is insufficient.

The goal should be to improve accuracy, completeness, reasoning, relevance and usefulness, not just to add citations to an answer the model had already decided to give.

Sub-agent output, retrieved memories and model-generated summaries should not automatically be treated as facts. They should be validated in the same way as any other source.

Evidence and abstention

The final result could have an internal status such as:

• Verified
• Partially verified
• Conflicting evidence
• Insufficient evidence
• Tool or verification failure

If the important claims cannot be supported, DeerFlow should say that it does not have enough evidence instead of filling the gaps with a plausible-sounding answer.

A partial answer should still be possible when only part of the question can be verified.

The system should also avoid excessive abstention. The objective is not to refuse difficult questions, but to distinguish clearly between:

• supported facts;
• reasonable but uncertain conclusions;
• hypotheses;
• and information that cannot currently be verified.

Source quality

Not all search results should have the same weight.

The mode should prefer primary and authoritative sources when they exist, consider publication dates for time-sensitive questions, detect when a source does not actually support the claim being made, and surface meaningful disagreement between reliable sources.

Citation validation alone is not enough. A citation may exist and still fail to support the sentence attached to it.

Independent verification

Whenever possible, the final verification should be separated from the agent that produced the answer.

A second model or verifier could review the result, but the entire decision should not depend only on another language model saying that the answer looks correct.

Deterministic checks could also verify things such as:

• whether cited evidence really exists;
• whether URLs and document references came from actual tool results;
• whether dates and versions match the question;
• whether calculations or code tests passed;
• whether the final answer contradicts retrieved evidence;
• whether the verifier or a required tool failed.

If a mandatory reliability component fails, the system should fail safely rather than silently return an unchecked answer.

The evaluator-driven work proposed for /goal in #3834 looks related to this idea, but I would like to see the principle applied to normal factual answers as well, not only to deciding whether a long-running goal has been completed.

Web UI

It would be useful if the Web UI showed a simple reliability summary without exposing private chain-of-thought.

For example:

• whether external verification was needed;
• which sources or tool results supported the answer;
• whether the answer was repaired after verification;
• which claims remain uncertain;
• why DeerFlow abstained or answered only partially.

This would make it easier to trust the process without filling the chat with internal reasoning.

Local models

This mode should work with local models through OpenAI-compatible endpoints and should not require a commercial cloud model.

It should also be configurable because local hardware and models vary. Possible presets could be:

• Fast: minimal verification
• Balanced: verify claims when needed
• Strict: require evidence for important factual claims

The user should be able to choose different models for the main answer, retrieval, verification or repair, but using one local model for all stages should remain possible.

Measuring whether it works

I think this feature should be evaluated by comparing the same base model in two conditions:

1. the model used directly;
2. the model used through DeerFlow reliability mode.

Useful measurements would include:

• factual accuracy;
• unsupported claim rate;
• citation correctness;
• completeness;
• contradiction rate;
• correct abstention;
• unnecessary abstention;
• latency and token cost.

This comparison matters because an agent harness should not only add features. It should preserve or improve the quality of the underlying model instead of occasionally making a good direct answer worse through unnecessary orchestration.

For me, a careful answer that explains what is known and what is uncertain is more useful than a confident answer that may be invented.

Would this kind of optional reliability and answer-improvement mode fit the direction planned for DeerFlow?