Long-Context Financial Question Answering: SEC Filings & RAG 2026

SEC filings are the text most AI-in-finance systems read. In the filings we sampled from EDGAR on 2026-10-19 (data), 10-K main documents ran from about 23K to 273K tokens with a median of 91K, 10-Qs from 21K to 189K (median 35K), and an 8-K form about 1.0K before its exhibits; banks and insurers sit at the long end. Eight distinct tasks sit on top of that corpus: extraction, summarization, peer comparison, document Q and A, classification, tone-shift detection, forecast-feature generation, and disclosure-change detection. Each has its own sweet spot in the model-by-pattern-by-cost matrix. There is no single best model and no single best pattern. This guide is the map: what each task actually demands, which model tier and prompting pattern fits, and which supporting tools and articles cover the precision, cost, and evaluation concerns that cut across every workload.

The filings workload, sized honestly

SEC filings form the largest public text corpus an AI-in-finance engineer will ever touch: EDGAR processes about 4,700 filings a day and takes on about 40,000 new filers a year.¹ In the EDGAR sample above, a 10-K main document runs about 23K to 273K tokens at 4 characters a token (median 91K), before exhibits; the exact count depends on the model's tokenizer.²

Token counts matter because they set the economic floor. At catalog list prices as of 2026-10-09, reading a typical 100,000-token large-cap 10-K costs from $0.010 on Claude Haiku 5.5 to $1.00 on GPT-6 Astra, before any output.³

Pricing has moved several times in 2026 already, so treat any specific dollar figure as valid only for the date it was checked; the table is rebuilt from the current model catalog.

The workload naturally separates into eight tasks. They share a corpus and share infrastructure, but they do not share a sweet spot. Treating them as a single "read filings with LLM" problem is the most common architectural mistake in finance AI stacks.

The eight tasks

Task A: Structured extraction

Structured extraction pulls specific fields out of filings into typed records: revenue by segment, auditor name, going-concern language flag, number of board members, a named risk factor's presence, cash-flow sub-items. The output is a JSON object matching a fixed schema.

Latency matters here because extraction usually runs as a batch over thousands of filings and the wall-clock sets how fresh downstream tables stay. Accuracy sensitivity is high for numeric fields and moderate for categorical ones. The sweet spot is a Haiku or Sonnet tier model with structured-output mode on, paired with a deterministic validator that rejects outputs failing JSON schema or unit checks. Long context is wasted: extraction rarely needs more than the single filing section the field lives in, so chunk-then-route sends a few thousand tokens where whole-document prompting sends the whole filing, about 50x fewer input tokens per filing.

For numeric fields the model should return both the value and the span it was extracted from. Span-anchored extractions are the only kind a downstream system can audit.

Extraction throughput on a budget-tier model is bounded more by your API rate limits than by model inference time. Cost is easy to bound with chunk routing: if each quarterly filing sends about 2,000 tokens of relevant sections and gets a 300-token structured record back, a weekly pass over the 500 largest US issuers' filings costs about $0.17 on Claude Haiku 5.5 and $1.43 on GPT-5.4 Mini, roughly 8x more, which rarely buys measurably better numeric extractions when the prompt is well-constructed and the validator is deterministic. Cross-checking a small random sample against a second model tier works as a drift detector; the second tier does not need to be the primary extractor.

Task B: Summarization

Summarization produces a human-readable digest: an executive summary of a 10-K, a compressed Item 1A, a one-paragraph take on a proxy statement. Unlike extraction, the output is prose and its quality is judged qualitatively.

The dominant cost driver is the input, not the output, because the system prompt and filing body are long while the summary is short. Prompt caching collapses this: Anthropic keeps a cached prompt prefix for five minutes after its last read and bills cache reads at 2.5 percent to 10 percent of the input rate on the current Claude lineup.³ A one-time system prompt of 6,000 tokens, read against 200 filings in a batch window, costs 1 write plus 199 cached reads rather than 200 full writes. Haiku and Sonnet tiers are the common picks. Opus is only justified when the summary feeds a regulated deliverable.

Summarization quality degrades in predictable ways. Generic prompts produce generic summaries; summaries that reference specific dollar figures, segment names, and named risks are the ones a reader can act on. A prompt that requires the model to cite at least three numeric anchors and at least two named risk factors produces outputs that a research analyst actually reads rather than skims. The same prompt applied to an 8-K, where the whole filing is often under 1,000 tokens, wastes structure; short filings deserve a different summarization prompt that emphasizes classification of the event type over narrative compression.

Task C: Peer comparison

Peer comparison takes five to fifteen filings for a synthetic peer set and asks for synthesis: which issuers called out supply-chain risk, which changed revenue-recognition language, which lengthened their going-concern paragraph. This is the task that most visibly rewards longer context.

Three patterns work, in rising order of cost. First, pre-summarize each filing into a 500-token brief and concatenate briefs into the comparison prompt. Second, retrieve the relevant sections per question (risk factors only, MD and An only) and concatenate at section granularity. Third, place full filings in a 200K or 1M context window and ask directly. For 5 filings at catalog prices, pattern one costs about $0.022 per comparison on Claude Sonnet 5.5 and pattern three about $2.06 on Claude Opus 5.5, before the cost of writing the briefs. Measure the accuracy difference between one and three on your own peer sets before paying for three. A mid-tier model (currently GPT-5.4 Mini or Gemini 3.8 Flash) handles one and two cleanly; a premium model (Gemini 4 Argon or Gemini 3.1 Pro Preview) is reserved for three when cross-document reasoning demands it.

Peer-comparison prompts fail most often at the aggregation step rather than the per-document step. A common failure mode is the model answering four of five comparative questions from the first filing in context and degrading as the context position grows, the position effect Liu et al. measured in Lost in the Middle. Mitigation is structural: require a per-issuer table as intermediate output, with one row per filing, before the cross-issuer synthesis. The table forces the model to touch every document and makes downstream validation trivial. Pattern one's pre-summarization step does this implicitly; pattern three needs the discipline imposed explicitly.

Task D: Document Q and A

Q and An is single-user, interactive, and latency-bound. A research analyst types "what did the issuer say about data-center capex guidance," and the system retrieves and answers in under five seconds.

Two architectures dominate. For a single filing, direct prompting with a mid-tier model and the filing in context is simplest and accurate. For a corpus (an issuer's last eight years, or a sector's quarterly filings), retrieval-augmented generation is required: a vector index over chunked filings, top-k retrieval, and a mid-tier model assembling the answer. Chunk size and overlap dominate RAG quality; the SEC Filing Chunk Optimizer surfaces the tradeoff explicitly for 10-K, 10-Q, and 8-K structures.

A sensible default chunk configuration for SEC filings is 800 to 1,200 tokens per chunk with 150 to 200 tokens of overlap, segmented on section boundaries where possible; test yours in the SEC Filing Chunk Optimizer. Risk-factor sections deserve smaller chunks (400 to 600 tokens) because individual risks are short and retrieval should land on the specific risk, not a cluster of three. Financial-statement tables are the hardest case: naive chunking destroys row-column alignment. A production stack extracts tables separately into a structured store and retrieves them by metadata rather than by text similarity. Retrieving tables by structure rather than by text similarity substantially outperforms naive text-similarity chunking on exact-match numeric questions, which is exactly what the hybrid table-plus-text finance QA benchmarks were built to measure.⁴

Task E: Classification

Classification assigns a taxonomy label: risk-factor category (cybersecurity, supply chain, regulatory, FX), sentiment band on an earnings call paragraph, disclosure-material flag. The output space is small and fixed.

Classification is the task where fine-tuning most often earns its keep, because the label set is small and fixed. A budget-tier or open-weights model fine-tuned on a few thousand labelled examples can take over a taxonomy a mid-tier model handles few-shot; the saving per call is the gap between the tiers' input rates (8x between Claude Haiku 5.5 and GPT-5.4 Mini), and the cost is curating the labels. Start few-shot, and fine-tune when volume makes the label work pay. How to cut LLM token cost in a finance agent covers the cost levers.

Task F: Tone-shift detection across earnings calls

Tone-shift detection compares consecutive earnings-call transcripts for the same issuer and flags directional changes: optimism about a product line that softened, a hedge that tightened, a category that stopped being mentioned. This is structured sentiment, not summarization.

The pattern is a two-pass structured output. Pass one extracts a feature vector per transcript: topic presence, sentiment polarity per topic, hedging density, forward-looking statement count. Pass two computes the delta between consecutive vectors. Sonnet-tier handles pass one; the delta is a deterministic computation, not an LLM task. The guide to summarizing earnings calls with an LLM walks the pipeline.

Task G: Forecast-feature generation

Forecast-feature generation converts filings into inputs for downstream forecasting models: a numeric score for capex intensity, a binary flag for pending litigation, a categorical label for business-model stage. The feature vector feeds an econometric model, not a human.

Precision is critical because downstream models amplify feature noise. This is the one task where a premium-tier model (currently Gemini 4 Argon or Gemini 3.1 Pro Preview) earns its price per token: errors at this stage propagate multiplicatively. The pattern is extraction plus transformation, with schema validation at both the LLM boundary and the numeric-unit boundary. Span anchoring is mandatory; features without provenance cannot be debugged when a downstream model behaves unexpectedly.

Task H: Disclosure-change detection

Disclosure-change detection compares a new filing to the issuer's prior filing of the same type and flags material additions, removals, or rewrites. Compliance and legal teams use this to surface disclosures that merit review.

The first pass is not an LLM task: it is a diff over normalized text. The LLM's job is to classify each non-trivial diff as material or boilerplate, and to summarize material changes. This keeps token cost linear in the diff size, not the filing size. Sonnet-tier suffices; the downstream consumer is a human, so a false positive is cheap and a false negative is expensive. Threshold the model toward recall.

Normalization before the diff is the underappreciated step. Boilerplate variations (auditor signature blocks, date stamps, page numbers, whitespace) generate noise diffs that swamp signal. A pre-diff pipeline that strips these patterns, normalizes number formats, and sentence-tokenizes the output leaves the model only the passages that changed in substance, which also improves classification accuracy because the model is no longer being asked to distinguish formatting from substance.

Master selection table

The eight tasks summarized against five axes:

Costs are per document at catalog list prices as of 2026-10-09, for the token profile in the third column, across the Claude models in the band; the other vendors' read prices are in the table above. They are before caching: cache reads bill at 2.5 percent to 10 percent of the input rate on the current Claude lineup, so a task that reuses a long system prompt across documents costs less.

Cross-cutting concern 1: precision and unit handling

LLMs hallucinate numbers in predictable ways. A 10-K that reports revenue of $8,234 million can be surfaced by a careless extraction as $8.234 billion or, worse, as $8,234. Numeric precision failures are the single highest-severity bug class in finance AI. The fix is not prompting harder; it is span-anchored extraction plus deterministic numeric source grounding at the boundary. A well-engineered pipeline rejects any numeric field whose rendered span cannot be re-parsed to match the model's output. The numeric precision in LLM filings piece covers the validator shapes that catch these failures before they reach downstream tables.

Unit handling is a separate failure surface. SEC filings report numbers "in thousands" and "in millions" in footnote conventions that the model must carry through accurately. A typical validator keeps an explicit unit field on every numeric extraction and cross-checks it against the filing's Item 8 footer conventions. The Structured Schema Validator for Finance codifies this pattern for the most common filing types.

Cross-cutting concern 2: cost management and caching

Filings workloads are input-heavy: thousands of tokens in, tens to hundreds out. This shape is exactly what prompt caching was designed for. On the current Claude lineup a five-minute cache write costs 25 percent more than uncached input and a cache read 2.5 percent to 10 percent of it,³ so a cached prefix pays for itself on its first reuse. For any task B through H above, batch windows of 20 to 200 filings against a stable system prompt should always be cached. How to set up prompt caching for finance works through the setup; the Financial Document Token Estimator gives per-filing token counts so budgets are not guessed. Batch submissions are a second lever: Anthropic's Message Batches API and OpenAI's Batch API both cut prices by 50 percent for jobs that may take up to 24 hours.

The two levers combine. Anthropic states that the prompt-caching and batch discounts stack, but cache hits inside a batch are best-effort because batch requests run concurrently, so budget a batch at the batch rate and treat cache hits as upside. A common configuration sends real-time and near-real-time workloads through the cached synchronous path and sends nightly reconciliation workloads through the batch path. The Token Cost Optimizer models both paths side by side so the right lane is selected per workload rather than by habit.

Cross-cutting concern 3: evaluating reliability

Without an evaluation harness, model-upgrade decisions are guesses. The minimum viable harness for a filings workload is 50 to 200 human-labeled records per task, scored on exact match for numeric extractions, span overlap for text extractions, and rubric scoring for summarization and Q and A. Version every prompt; regress every harness run against the prior prompt version before shipping. Financial QA LLM benchmarks covers the published scoring rules and the label schema to copy for your own harness.

Architecture selection: fine-tuning, RAG, or long context

The three patterns are not substitutes; they solve different problems.

Fine-tuning pays back when the task has stable inputs, a small output space, and high volume. Classification is the clearest case. It does not help when the knowledge base is dynamic: a model fine-tuned on 2024 filings does not know what a 2026 filing says.

RAG pays back when the corpus is large, queries are diverse, and the knowledge base updates continuously. Document Q and An against a multi-year corpus is the canonical case. RAG quality is dominated by chunking and retrieval, not by the generator model; cheap retrieval with a mid-tier generator usually beats expensive retrieval with a top-tier generator.

Long context pays back when cross-document reasoning matters and the document count per query is small. Peer comparison against ten filings is the canonical case. Long context is expensive per query and rewards aggressive caching of anything reused across queries.

Most production filings stacks combine all three: fine-tuned classifiers for high-volume tagging, RAG for analyst-facing Q and A, long context for peer-comparison deliverables, with extraction and summarization layered across them. How to cut LLM token cost in a finance agent prices the RAG-versus-fine-tuning fork.

The decision reduces to three axes per task:

Long-context financial question answering benchmarks for SEC filings

If you need a named benchmark to validate a filings QA pipeline, the one that directly measures long-context QA over full SEC filings is DocFinQA: it extends FinQA's short passages to entire filings (average ~123,000 words, often 100K-plus tokens), which is the realistic setting for whole-10-K prompting. The others below trade document length for either evidence breadth or hybrid table-text reasoning, so the right benchmark depends on which task from the eight above you are evaluating.

Only DocFinQA and FinanceBench operate on full-document contexts; FinQA and TAT-QA are short-context numeric and hybrid-table benchmarks, so a model scoring well on them has not been tested on the position-bias and retrieval problems that dominate whole-filing work. Financial QA LLM Benchmarks 2026 collects sourced accuracy numbers across the broader benchmark set, and the evaluation harness methodology for finance LLMs covers how to wire any of these into a regression harness without contamination.

What this pillar connects to

This piece is the map. Each of the cross-cutting concerns and each of the eight tasks has a dedicated companion that goes deeper than this guide can. The Trading System Blueprinter lays out the full trading stack; this pillar drills into the filings layer specifically.

Connects to

• Numeric Precision in LLM Filing Extraction - the validator patterns that catch unit and precision errors.
• Trading System Blueprinter - the broader trading stack, as a starter architecture.
• Financial QA LLM Benchmarks 2026 - the published benchmarks and the harness shape that prevents silent regression.
• Financial Document Token Estimator - per-filing token counts for Anthropic, OpenAI, and Google tokenizers.
• SEC Filing Chunk Optimizer - chunking strategies tuned to 10-K, 10-Q, and 8-K structures.
• Structured Schema Validator for Finance - JSON-schema plus unit validation for extraction outputs.
• Hallucination Detector - span-anchored fact-checking for extracted numerics.
• Token-Cost Optimizer - cost calibration across model tiers and caching strategies.

References

• Google DeepMind. (2025). "Gemini 2.5 Technical Report." https://deepmind.google/technologies/gemini/. Covers the 1M-token context window and long-document benchmarks relevant to whole-filing prompting.
• Lewis, P., Perez, E., Piktus, A., et al. (2020). "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks." Advances in Neural Information Processing Systems 33. The RAG paper; still the clearest statement of when retrieval beats larger context. arXiv:2005.11401
• Anthropic. "Message Batches API." https://docs.anthropic.com/en/docs/build-with-claude/batch-processing. OpenAI. "Batch API." https://platform.openai.com/docs/guides/batch. Both vendors document the 50 percent batch discount referenced in the cost section.

Footnotes

1. U.S. Securities and Exchange Commission. "About EDGAR" (about 4,700 filings processed per day; about 40,000 new filers a year). https://www.sec.gov/submit-filings/about-edgar. Accessed 2026-10-19. ↩

2. Anthropic. "Models and Context Windows." https://docs.anthropic.com/en/docs/about-claude/models. OpenAI. "Models Reference." https://platform.openai.com/docs/models. Tokenizer specifications for Claude and the o200k_base encoding used by GPT-5. ↩

3. Anthropic. "Prompt Caching." https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching. Model pricing from the AI Dev Hub model catalog (https://aidevhub.io/api/models.json), current lineup verified against each vendor's pricing page as of 2026-10-09; all dollar figures are subject to change. ↩ ↩² ↩³

4. Zhu, F., Lei, W., Huang, Y., Wang, C., Zhang, S., Lv, J., Feng, F., and Chua, T.-S. (2021). "TAT-QA: A Question Answering Benchmark on a Hybrid of Tabular and Textual Content in Finance." ACL 2021. https://aclanthology.org/2021.acl-long.254/. A hybrid table-plus-text QA benchmark over real financial reports (16,552 questions, 2,757 hybrid contexts) — the dataset class against which table-aware retrieval is evaluated. ↩ ↩²

5. Reddy, V., et al. (2024). "DocFinQA: A Long-Context Financial Reasoning Dataset." ACL 2024 (short). https://aclanthology.org/2024.acl-short.42/. Extends FinQA's 7,437 questions to full-document SEC-filing contexts (average ~123K words), the closest published match to whole-filing long-context QA. ↩

6. Islam, P., et al. (2023). "FinanceBench: A New Benchmark for Financial Question Answering." https://arxiv.org/abs/2311.11944. 10,231 question-answer-evidence triplets over public filings (mostly 10-K) for 40 US-listed issuers; an open-book QA benchmark. ↩

7. Chen, Z., et al. (2021). "FinQA: A Dataset of Numerical Reasoning over Financial Data." EMNLP 2021. https://aclanthology.org/2021.emnlp-main.300/. 8,281 expert-written QA pairs with annotated reasoning programs over S&P 500 earnings-report passages; a short-context numeric-reasoning benchmark. ↩

Frequently asked questions

How much does it cost to read a large-cap 10-K with an LLM?

At catalog list prices as of 2026-10-09, the input side of a typical 100,000-token 10-K costs $0.010 on Claude Haiku 5.5, $0.010 on GPT-6 Luna, $0.030 on Gemini 3.5 Flash-Lite, $0.075 on GPT-5.4 Mini, $0.075 on Gemini 3.8 Flash, $0.20 on Claude Sonnet 5.5, $0.20 on GPT-6.1 Sol, $0.20 on Gemini 4 Argon, $0.20 on Gemini 3.1 Pro Preview, $0.40 on Claude Opus 5.5, $0.50 on GPT-5.5, $1.00 on Claude Fable 5.1, $1.00 on GPT-6 Astra. Cache reads bill at 2.5 percent to 10 percent of the input rate on the current Claude lineup, so reusing one long system prompt across many documents cuts that part of the bill sharply.

When does it make sense to fine-tune a model for classifying SEC filings?

When the label set is small and fixed and the volume is high. A budget-tier or open-weights model fine-tuned on a few thousand labelled examples can replace few-shot prompting on a mid-tier model; the saving per call is the gap in input rates (8x between Claude Haiku 5.5 and GPT-5.4 Mini at catalog prices), and the cost is curating the labels. Start few-shot and fine-tune once volume pays for the label work.

What chunk size works best for RAG over SEC filings?

A sensible default is 800 to 1,200 tokens per chunk with 150 to 200 tokens of overlap, segmented on section boundaries where possible. Risk-factor sections deserve smaller chunks of 400 to 600 tokens, since individual risks are short and retrieval should land on a specific risk rather than a cluster of three.

Why is treating all eight filing tasks as a single 'read filings with LLM' problem a mistake?

The eight tasks do not share a sweet spot in the model-by-pattern-by-cost matrix. Extraction runs best on a budget model with chunk-routing; peer comparison rewards long context and premium-tier reasoning; disclosure-change detection starts with a text diff, not a full-filing read. Treating them as one problem means paying whole-filing, premium-model prices for tasks that need neither.