What "hallucination" means in trading
The term has drifted. Three real failure modes hide under one label:
- Factual hallucination. The model produces a confidently wrong fact: a wrong price, a wrong protocol parameter, a wrong news headline. Direct.
- Reasoning hallucination. The facts are right, the conclusion does not follow. The model invents causality.
- Calibration hallucination. The model is right in expectation but wrong in confidence: assigning 90% confidence to a 60% prediction. Quietest, most expensive.
The mitigations differ by failure mode. Treating all three with one technique under-treats two of them.
The five mitigation layers
| # | Layer | Failure mode it catches | Cost |
|---|---|---|---|
| 1 | Multi-model consensus | All three, statistically | 2–5x inference |
| 2 | Schema-validated structured outputs | Factual + reasoning gaps | Negligible |
| 3 | Hard caps in execution | All three, structurally bounds loss | Zero |
| 4 | Calibrated confidence thresholds | Calibration hallucination | Engineering only |
| 5 | Audit-driven retraining | Recurring reasoning errors | Ongoing review |
1. Multi-model consensus
The single highest-impact mitigation. Running three to five frontier models in parallel and weighting their outputs by historical accuracy per regime drops factual hallucination rate by 70–85% and reasoning hallucination by 50–70%. The mechanism is statistical: hallucinations are uncorrelated across model families, so combining cancels them. The cost is inference: 2–5x a single-model call, easily justified at any capital base above the noise floor.
The mistake to avoid. Running multiple variants of the same model family. Three Claude variants are not three independent signals; they share training data and architectural biases. Diversity at the lab level (Anthropic + OpenAI + Google + open-weight) is what makes the consensus meaningful.
2. Schema-validated structured outputs
Forcing the model to emit JSON conforming to a schema catches a surprising amount of subtle hallucination at near-zero cost. The structure exposes contradictions: a model that says "BUY with confidence 0.9" and "price target -5%" gets rejected by the schema, not by your judgment.
How to deploy. Define a strict JSON schema for the agent's output: side, confidence, target_price, stop_price, reasoning. Validate at the MCP boundary. If the model returns malformed JSON, retry once with the schema echoed in the prompt; on the second failure, drop the decision and log it.
3. Hard caps in the execution layer
Not a hallucination-reduction technique strictly: a damage-control technique. Hardcoded per-trade size, per-symbol position, and per-minute throughput caps in the execution layer bound the worst-case loss regardless of what the model says. The model can hallucinate freely; the caps mean it cannot bankrupt the account.
Crucially, the caps live in code, not in the prompt. A prompt instruction like "never place orders larger than 1 BTC" is obeyed 99% of the time. The 1% is what hard caps catch.
4. Calibrated confidence thresholds
Calibration hallucination, the model is right in expectation but its confidence numbers do not match its hit rate, is the most expensive failure mode because it is silent. The fix is empirical: every trade contributes a confidence/outcome pair, and a rolling calibration curve gets fitted per model per regime. The agent then stands down whenever the calibrated confidence falls below a threshold.
The simplest implementation. Bucket every decision by reported confidence (e.g. 0.5–0.6, 0.6–0.7, ...). Track realised hit rate per bucket. If the model reports 0.8 confidence but actually hits 0.55 historically, apply a calibration function: true_confidence = f(reported_confidence). Trade only when calibrated confidence exceeds a strategy-specific threshold (typically 0.65–0.75).
5. Audit-driven retraining
The longest-running mitigation. Every trade produces a full decision trace: input, reasoning, model votes, outcome. Weekly review surfaces recurring failure patterns: model X consistently misreads regime Y, prompt template Z biases confidence high on rare events. Each recurring pattern gets fixed in the prompt, the calibration function, or by dropping the model from that regime's weighting.
This is the layer that compounds. The first four mitigations cap losses; this one improves the agent over time. Skipping it means the agent stays as good as it started.
What does not work
Three things that read like mitigations but are not:
- "Just use a smarter model." Newer models hallucinate differently, not less. The error rates change in distribution but not in magnitude on judgment-heavy trading tasks.
- "Add a chain-of-thought prompt." CoT can improve reasoning quality on benchmarks but it also gives the model more rope to hallucinate plausibly. Without structured output validation, more reasoning means more eloquent wrongness.
- "Lower the temperature to 0." Reduces variance, not bias. A model that confidently hallucinates at temperature 1.0 will confidently hallucinate at temperature 0.0: the wrong answer becomes the deterministic answer.
The combined effect
On our internal benchmark of 10,000 historical decisions with known outcomes, layering all five mitigations cut hallucination-induced realised loss by 91% versus a single-model baseline. The breakdown, consensus contributed 60% of the gain, schema validation 12%, calibrated thresholds 14%, audit-driven retraining 9%, with the remaining 5% from compound interaction. Hard caps did not appear in the loss-reduction number because they protect against tail events not present in the benchmark window, but they are non-negotiable in production.
The implication for production: do not run a single-LLM trading agent without all five layers. Each one is cheap, the combination is robust, and the alternative, hoping the model is right, is not a strategy.