Evaluating LLMs in Finance: Document Reasoning, Agentic Workflows, and Hallucination Control

Why Finance Is the Real Test for Large Language Models

Models that perform well on general-purpose benchmarks often struggle when deployed in financial scenarios. Financial tasks have three distinctive characteristics:

• Complex document formats: Earnings reports, announcements, research reports, and prospectuses frequently contain multi-level tables, footnotes, and appendices, with dense terminology and inconsistent reporting standards across documents.
• Long reasoning chains: A seemingly simple question like “How much did the company’s operating margin change year over year?” requires locating the right document, extracting fields, unit conversion, cross-period comparison, and ratio calculation — all linked in sequence.
• High cost of errors: A fabricated number or a misattributed reporting period can directly propagate into investment decisions and compliance workflows.

As a result, evaluating whether a model is suitable for financial business cannot rely on general-purpose leaderboards alone. The evaluation framework should be built around the actual structure of financial tasks. In industry practice, evaluation typically focuses on three dimensions: retrieval and numerical reasoning on real documents, end-to-end workflow support, and adversarial hallucination stress testing.

Dimension 1: Retrieval and Multi-Step Numerical Reasoning on Real Documents

The mainstream approach to measuring a model’s financial understanding is to build question-answering benchmarks from real financial documents, focusing on three sub-capabilities:

1. Retrieval and localization: Accurately locating relevant passages and table entries within long documents or multi-document collections.
2. Cross-document verification: Identifying reporting-standard differences for the same metric across different documents and reporting periods, and performing cross-validation.
3. Multi-step numerical reasoning: Completing chained operations such as unit conversion, exchange-rate translation, year-over-year and quarter-over-quarter comparisons, and ratio calculations.

A well-designed evaluation set of this type should satisfy several criteria: documents come from real business scenarios rather than synthetic generation; answers depend on cross-document verification rather than single-point lookup; every answer can be traced back to source evidence; and scoring considers both the final answer and whether the intermediate evidence holds up.

Based on general patterns from public benchmarks, models are approaching usable performance on pure retrieval tasks, but multi-step numerical reasoning remains the primary source of errors. The core improvement of newer model generations over their predecessors is often not “more memorized knowledge” but “more complete reasoning chains and more stable computation.” This suggests that evaluation should focus on chain completeness rather than single-point accuracy.

Dimension 2: End-to-End Investment Workflow Support

Real business operations are rarely single-turn Q&A; they are long-chain workflows. When evaluating workflow support capabilities, typical tasks include: initial screening, financial metric calculation, peer comparison, profitability analysis, and ultimately conclusion and report generation. Key evaluation points include:

• Task decomposition: Whether the model can break a vague business objective into an ordered sequence of subtasks.
• Tool-call correctness: Whether parameters and timing are correct when invoking external tools such as retrieval, computation, and table processing.
• Intermediate result propagation: Whether outputs from one step are consumed correctly downstream, and whether errors compound over multiple steps.
• Final output quality: Whether conclusions are evidence-backed and whether the format meets business requirements.

An important observation is that workflow benchmark scores are typically significantly lower than single-task scores. This is expected — the gap exposes weaknesses in task decomposition and context management. For enterprises, the most valuable approach is to build internal evaluation sets based on their own business SOPs, so that evaluation results map directly to production readiness.

Dimension 3: Hallucination Stress Testing

The harm of hallucination is amplified in financial scenarios: numbers look plausible, sources cannot be traced, and errors flow directly into decision-making. Effective stress testing typically includes the following adversarial designs:

• Unanswerable questions: Data that does not exist anywhere in the provided documents, testing whether the model fabricates information.
• Time-period misalignment: Inducing the model to treat previous-period data as current-period data.
• False-premise questions: Questions that embed incorrect facts, testing whether the model acquiesces to false premises.
• Ambiguous-boundary questions: Questions with unclear reporting standards, testing whether the model proactively seeks clarification rather than forcing an answer.

The core metric should be error rate (including fabrication, misalignment, and misattribution) rather than accuracy alone. Industry experience shows that targeted anti-hallucination optimization can reduce error rates by several times, but cannot eliminate them entirely. High-risk steps must therefore retain a human review mechanism.

Root Causes of Hallucination and Engineering Mitigations

Hallucination stems from four main sources: parametric knowledge that is frozen and lags behind real data; noise and contradictions in training corpora; error accumulation during autoregressive decoding; and the model’s lack of explicit modeling of “I don’t know.” Corresponding engineering mitigations include:

• Retrieval-augmented generation with citation tracing: Ensuring every number can be traced back to the source passage — no evidence, no output.
• Externalized numerical computation: Having the model generate computation steps or invoke a code interpreter instead of performing multi-step arithmetic internally.
• Structured output constraints: Using schema definitions to constrain fields and types, reducing room for free-form generation.
• Self-consistency and self-verification: Multiple-sampling with voting, or verifying each assertion in the answer against the evidence.
• Confidence calibration and refusal mechanisms: Proactively refusing or requesting clarification for low-confidence questions rather than forcing an answer.

The following is an example flow for citation consistency validation:

def validate_answer(answer: str, evidence: list[str]) -> dict:
    """Validate citation consistency of a model answer to reduce hallucination risk"""
    report = {"claims": [], "unverifiable": [], "conflicts": []}
    for claim in extract_numeric_claims(answer):        # 1. Extract numeric claims
        span = locate_supporting_span(claim, evidence)  # 2. Trace back to source evidence
        if span is None:
            report["unverifiable"].append(claim)        # 3a. No source found, flag
        elif not numeric_consistent(claim, span):
            report["conflicts"].append(claim)           # 3b. Numeric conflict, flag
        else:
            report["claims"].append(claim)
    return report

Enterprise Adoption Path

A three-phase approach is recommended: start with document Q&A (validating retrieval and citation tracing), then expand to workflow automation (validating task decomposition and tool calling), and finally consider decision support (with human review in place). Evaluation should also be treated as a continuous asset: bad cases discovered in production flow back into the evaluation set, forming a regression-testing loop.

For infrastructure, enterprises can leverage established LLM service platforms to accelerate deployment. One-stop platforms such as Baidu AI Cloud typically provide common capabilities including model serving, document parsing, vector retrieval, logging, and monitoring and alerting. These allow teams to focus their effort on evaluation-set construction and business-process adaptation — the areas that create real differentiation.

Conclusion

Finance is the proving ground for LLM reliability. The value of evaluation is not to score and rank models, but to translate abstract requirements like “retrieval, verification, reasoning, and hallucination resistance” into measurable, regression-ready, iterable engineering metrics. Only by letting evaluation drive iteration, constraining outputs through citation tracing, and maintaining human review for high-risk steps can LLMs become truly usable and trustworthy in high-stakes financial scenarios.