SEC Filing AI: Naive RAG vs Structured RAG vs Navigation

Three Ways to Build an AI Agent Over SEC Filings: Naive RAG vs Structured RAG vs Navigation-Based Agents

Table of contents

• Summary
• SEC filing agent guide series
• Why SEC Filings Are Hard for AI Agents
• Naive RAG Over SEC Filings
• Structured RAG Over SEC Filings
• Navigation-Based Agents Over SEC Filings
• Side-by-Side Comparison
• Practical Recommendation
• FAQ

---

Summary

Short answer: For SEC filings, naive RAG is useful for prototypes, structured RAG is a better production baseline, and navigation-based agents are best for high-quality filing analysis because they preserve the filing map and let the agent read specific sections before answering.

Why it matters: SEC filings are structured disclosure documents, not generic text blobs. The architecture determines whether an AI system sees the right section, table, filing period, and citation source.

Practical takeaway: Use search as a supporting tool, but give serious SEC filing agents a table of contents, stable node references, targeted read tools, and citation requirements.

There are three common ways to implement an AI agent over SEC filings:

1. Naive RAG — split filings into fixed-size chunks, embed them, and search by vector similarity.
2. Structured RAG — parse the filing structure first, create logical chunks, embed those chunks, and retrieve by similarity.
3. Navigation-Based Agent — parse the filing into a table of contents, let the agent inspect the filing structure, then read only the relevant sections or nodes.

The short version: naive RAG is easy but unreliable, structured RAG is better but still retrieval-limited, and navigation-based agents are usually the best fit for SEC filings because filings are not just text blobs — they are structured disclosure documents.

SEC filings such as 10-Ks, 10-Qs, 20-Fs, 8-Ks, and 6-Ks have sections, sub-sections, tables, notes, risk factors, management discussion, exhibits, and repeated legal language. Treating them as a flat pile of chunks ignores the very structure that makes them useful.

For financial AI agents, the goal is not only to find text. The goal is to answer questions with the right filing context, cite the exact source, and avoid missing material disclosures.

---

SEC filing agent guide series

This article is the architecture pillar for a five-part series on building citation-backed SEC filing agents:

1. This article — naive RAG vs structured RAG vs navigation-based agents: why filing structure matters and which retrieval architecture fits SEC disclosures.
2. How to parse SEC 10-K and 10-Q filings into sections — turn flat EDGAR HTML into titled nodes agents can read and cite.
3. How to build an SEC filing agent without naive RAG — navigation-first workflow, MCP tools, and production architecture.
4. Best SEC EDGAR MCP servers for AI agents — compare EdgarTools, edgar.tools, and AlphaCreek by use case.
5. SEC EDGAR MCP benchmark — hosted MCP citation comparison (July 2026, reproducible on GitHub).

---

Who This Article Is For

This article is for product teams, developers, financial data platforms, and AI builders deciding how to let users ask questions over SEC filings. It is especially relevant if the product must answer from 10-Ks, 10-Qs, 20-Fs, 8-Ks, or 6-Ks with citations instead of loose summaries.

It is not investment advice. The article is about retrieval architecture, document structure, and citation quality for financial research software.

---

Methodology and Sources

This comparison is based on AlphaCreek's work building filing-aware retrieval and MCP tools for SEC filing navigation. The examples focus on common failure modes we see when filings are flattened into chunks: missing table context, losing section headings, retrieving oversized sections, and citing passages without enough filing context.

The article also relies on public SEC filing conventions: forms such as 10-K, 10-Q, 20-F, 8-K, and 6-K are structured disclosure documents with recurring sections, tables, exhibits, notes, and management commentary. For background, see the SEC's Forms List and EDGAR filing access.

---

Why SEC Filings Are Hard for AI Agents

SEC filings look like normal documents, but they are not normal documents.

A 10-K or 10-Q contains several different types of information:

• Business descriptions
• Risk factors
• Management’s Discussion and Analysis, or MD&A
• Financial statements
• Notes to financial statements
• Segment disclosures
• Liquidity and capital resources
• Legal proceedings
• Controls and procedures
• Exhibits
• Tables
• Repeated boilerplate language
• Cross-references between sections

A good AI agent over SEC filings needs to understand not only what the text says, but also where the text appears in the filing.

For example, take the sentence: “margin increased due to efficiency improvements.” What this sentence means—and how it should be interpreted—depends heavily on where it appears in an SEC filing.

• If it appears in Item 1: Business, it may be describing operational capabilities or how the company manages costs as part of its broader business model.
• In Item 1A: Risk Factors, the same sentence could signal that margins depend on sustaining those efficiencies, or warn that cost-cutting gains may not recur.
• When found in Item 7: MD&A (Management’s Discussion and Analysis), it’s likely management’s explanation for financial results, giving insight into what drove profitability for that year or quarter.

The context within the filing changes the sentence’s purpose and reliability as evidence. Without knowing where the information comes from, an AI agent may misrepresent or misunderstand its significance.

That is why architecture matters. The retrieval system determines what the agent sees, what it misses, and how trustworthy the final answer is.

---

Approach 1: Naive RAG Over SEC Filings

What Is Naive RAG?

Naive RAG is the simplest way to build an AI agent over SEC filings.

The implementation usually looks like this:

1. Download the SEC filing.
2. Extract the text.
3. Split the text into fixed-size chunks, for example 500, 1,000, or 2,000 tokens.
4. Generate embeddings for each chunk (by semantic similarity).
5. Store the embeddings in a vector database.
6. When the user asks a question, embed the question — and, for better recall, one or more alternate query embeddings (rephrasings, sub-questions, or filing-style terms the disclosure might use).
7. Retrieve the most similar chunks across those searches, then merge or rerank.
8. Send those chunks to the LLM.
9. Ask the LLM to generate an answer.

This is the default RAG architecture many teams start with.

It treats an SEC filing as a long text file and ignores the filing’s internal structure.

---

Example

User asks:

What drove gross margin change in the latest 10-K?

A naive RAG system searches by similarity — often with several query embeddings, not only the user’s exact wording.

It may retrieve chunks that contain relevant phrases such as:

• “gross margin”
• “efficiency improvements”
• “cost of revenue”
• “basis points”

But fixed-size chunking does not respect filing boundaries. A 1,000-token window can split the disclosure in the middle:

• One chunk may start mid-table — dollar amounts and percentages without column headers or the row label “Gross margin.”
• Another may end halfway through Item 7: MD&A, carrying the sentence “margin increased due to efficiency improvements” but not the section heading or the paragraph that explains whether the gain was structural or one-time.
• A third may splice the end of a segment discussion with the start of liquidity commentary, so “margin” appears next to unrelated cash-flow language.

The retriever finds semantically similar text. The LLM does not get the full section, the complete table, or a reliable source location.

That matters because margin explanations in SEC filings usually sit beside specific headings, full tables, and year-over-year comparisons. When chunks are cropped in the middle, the agent may treat a partial sentence as the full story — or miss the table that actually contains the answer.

---

The Core Problem With Naive RAG

The core problem is that naive RAG treats SEC filings as unstructured text.

But SEC filings are structured disclosure documents.

A random 1,000-token chunk may contain the end of one section, the beginning of another section, part of a table, and no clear heading. That may be acceptable for casual search, but it is not enough for reliable financial analysis.

Naive RAG can find text that sounds relevant. It cannot reliably understand where that text belongs.

---

Pros of Naive RAG

Pro	Explanation
Fast to implement	Uses standard text extraction, embeddings, and vector search.
Easy to understand	Simple pipeline: chunk, embed, retrieve, answer.
Good for prototypes	Useful for demos, MVPs, and testing whether users want to chat with filings.
Predictable token planning	Fixed-size chunks make storage and retrieval costs easier to estimate.

---

Cons of Naive RAG

Con	Explanation
Loses filing structure	The system does not know whether text came from MD&A, risk factors, notes, or tables.
Cuts context in the middle	Fixed-size chunks can separate headings, tables, and explanations from the relevant text.
Weak citations	A retrieved chunk may not be a complete or reliable source.
Poor for serious analysis	Comparisons, source-sensitive claims, and investor-facing workflows need more structure.

---

Approach 2: Structured RAG Over SEC Filings

What Is Structured RAG?

Structured RAG improves on naive RAG by parsing the SEC filing before chunking it. For how to recover issuer sub-headings and build an LLM-ready section tree from EDGAR HTML, see how to parse SEC 10-K and 10-Q filings into sections.

Instead of splitting the document blindly by token count, structured RAG tries to preserve the logical structure of the filing.

The implementation usually looks like this:

1. Download the SEC filing.
2. Parse the HTML or filing document.
3. Detect major sections such as Item 1, Item 1A, Item 7, and Item 8.
4. Split the filing into logical chunks based on headings, sections, tables, or disclosure blocks.
5. Attach metadata to each chunk, such as ticker, form type, filing date, section, item name, and source location.
6. Generate embeddings for each logical chunk.
7. Store the chunks and embeddings in a vector database.
8. Retrieve the most relevant chunks — the same multi-query embedding pattern as naive RAG, plus metadata filters or hybrid search when useful.
9. Send the retrieved chunks to the LLM with source information.

Structured RAG still uses embeddings and similarity search, but the chunks are more meaningful and retrieval can be narrowed by section.

---

Example

User asks:

What is the revenue breakdown by segment?

A structured RAG system parses the filing into logical sections and attaches metadata. That is an improvement over naive RAG — but the agent still receives whatever vector search ranks highest, usually five or ten chunks.

The query matches narrative language well. It matches tables poorly.

A segment revenue table may contain mostly numbers, short row labels like “Data Center” and “Gaming,” and very little prose. Vector similarity may rank that table below text-heavy MD&A paragraphs that mention “segment” or “revenue” in passing.

The retriever returns commentary chunks. It may never return the table that actually answers the question.

User asks:

What drove gross margin change in the latest 10-K?

Structured RAG preserves section boundaries, so chunks follow real filing structure — but they are no longer uniform in size.

One chunk may be a short risk-factor bullet. Another may be all of Item 7: MD&A — a long section with narrative, tables, and cross-references in a single logical block.

With fixed top-k retrieval, the agent may receive one or two oversized sections that consume most of the context window. The LLM spends tokens on boilerplate, repeated explanations, and unrelated subsections — while still missing the specific paragraph or table that matters.

---

The Core Problem With Structured RAG

Structured RAG fixes arbitrary token splitting, but not the limits of similarity search and fixed top-k retrieval.

The agent is still mostly passive. It receives whatever the retriever returns — and in whatever sizes the parser produced. That works for narrow, text-heavy questions with obvious semantic matches. It is weaker when the answer lives in a table, when one retrieved chunk is an entire MD&A section, or when the question requires exploration across the filing.

Metadata filters help narrow the search space. They do not replace the need to inspect the filing map and read the right section or table.

Many useful SEC filing questions are investigation questions, not simple lookups. Structured RAG alone cannot reliably answer them by hoping the top similar chunks contain the answer.

That leads to the third approach.

---

Pros of Structured RAG

Pro	Explanation
Preserves logical context	Chunks align with sections, headings, tables, or disclosure blocks.
Better retrieval quality	Metadata and section-aware chunks usually beat arbitrary token windows.
Better citations	Sources can point to coherent filing sections instead of random chunks.
Familiar architecture	Still uses embeddings, vector databases, filters, and hybrid search.

---

Cons of Structured RAG

Con	Explanation
SEC parsing is hard	Messy HTML, tables, exhibits, and inconsistent headings make reliable parsing difficult.
Still retrieval-limited	The agent only sees a fixed top-k set from similarity search.
Weak for numerical data	Table-heavy disclosures with little prose may not match the query well.
Can pollute context	Large section-sized chunks can crowd out the exact paragraph or table needed.

---

Approach 3: Navigation-Based Agent Over SEC Filings

What Is a Navigation-Based Agent?

A navigation-based agent treats an SEC filing as a document map, not a bag of chunks.

Instead of immediately searching a vector database, the system gives the agent tools to navigate the filing.

The implementation usually looks like this:

1. Parse the filing while preserving structure.
2. Build a table of contents, or TOC, for the filing.
3. Assign stable references to each TOC element or node.
4. Let the agent inspect the filing TOC first.
5. The agent decides which sections are relevant.
6. The agent reads specific nodes, sections, or paragraphs using references.
7. The agent answers using the content it intentionally selected.
8. The answer cites exact filing passages or node-level sources.

This architecture is closer to how a human analyst reads filings.

A human does not randomly search chunks first. A human opens the filing, scans the table of contents, identifies the relevant section, reads that section, then cites the source.

A navigation-based agent does the same thing.

---

Example

User asks:

What are the most important margin-related disclosures in the latest 10-K?

A navigation-based agent may follow this workflow:

1. Select the latest 10-K.

2. Inspect the filing table of contents.

3. Identify relevant sections:

   • Item 7: MD&A
   • Results of Operations
   • Gross margin
   • Cost of revenue
   • Segment profitability
   • Notes to financial statements

4. Read those nodes.

5. Decide whether additional sections are needed.

6. Produce an answer with citations to the exact nodes or paragraphs.

The agent is not limited to whatever vector similarity happens to retrieve.

It can reason about where margin discussion should appear.

---

AlphaCreek Example: Filing Navigation With MCP Tools

In AlphaCreek's SEC filing workflow, the agent does not start by embedding the user's question and hoping the right chunk ranks highly. It first selects the filing period, inspects the filing table of contents, and reads targeted filing nodes.

A typical tool sequence looks like this:

1. list_filings identifies the relevant company filing and reporting period.
2. get_filing_toc returns the filing's table of contents with stable node identifiers.
3. read_node_content reads one or more selected nodes, including the source citation URL for each node.
4. The agent answers only after reading the sections or tables it intentionally selected.

That workflow gives the model a visible reasoning path: which filing it selected, which sections it inspected, which nodes it read, and which source URLs support the final answer. For SEC filings, that audit trail is often more important than retrieving a semantically similar paragraph. For a full implementation walkthrough, see how to build an SEC filing agent without naive RAG. To compare hosted MCP servers that expose this workflow, see best SEC EDGAR MCP servers for AI agents and our SEC EDGAR MCP benchmark.

---

Pros of Navigation-Based Agents

Pro	Explanation
Preserves filing structure	The agent sees a document map, not a flat text dump.
Better reasoning path	It can inspect the TOC, choose relevant sections, then read.
Strong citations	Answers can cite exact nodes, paragraphs, or filing sections.
Better for broad questions	The agent can explore multiple sections instead of relying on top-k chunks.

---

Cons of Navigation-Based Agents

Con	Explanation
Harder to implement	Requires parsing, TOC generation, node references, tools, and guardrails.
Depends on a reliable map	A bad TOC or parser can send the agent to the wrong place.
Slower than one search	Multi-step reading can take longer than a single vector retrieval call.
Wrong fit for simple search	Overkill for demos, keyword lookup, or ultra-low-latency search.

---

The Core Advantage of Navigation-Based Agents

The biggest advantage is that the agent can decide where to look before reading.

That sounds simple, but it changes the whole retrieval model.

Naive RAG says:

“Here are the chunks that look similar. Answer from them.”

Structured RAG says:

“Here are better, section-aware chunks that look similar. Answer from them.”

Navigation-based agents say:

“Here is the filing map. Decide where the answer should be, read those sections, then answer with citations.”

That is a much better fit for SEC filings.

SEC filings already have structure. The AI system should use it.

---

Side-by-Side Comparison

Dimension	Naive RAG	Structured RAG	Navigation-Based Agent
Best fit	Prototypes and demos	Production search baseline	Reliable filing analysis
Structure preserved	No	Partially	Yes
Retrieval model	Similar chunks	Section-aware chunks	Agent chooses where to read
Main failure mode	Loses context	Still retrieval-limited	More complex and slower
Citation quality	Weak	Better	Strong
Table handling	Often poor	Better, but still uneven	Strong when tables are addressable nodes
Implementation complexity	Low	Medium	High
Best secondary capability	Keyword/vector search	Metadata filters and hybrid search	Search plus filing-map navigation

---

Which Approach Should You Choose?

Choose Naive RAG if you are prototyping

Use naive RAG when you need to move fast and prove that users want to chat with filings.

It is not the best long-term architecture, but it is a reasonable first step.

Best for:

• MVPs
• Demos
• Internal experiments
• Low-risk filing Q&A
• Testing product demand

Avoid it for:

• Investor-facing tools
• Compliance-sensitive answers
• Professional financial research
• Anything requiring precise citations

---

Choose Structured RAG if you need better retrieval but want a familiar architecture

Structured RAG is a strong middle ground.

It keeps the familiar vector search architecture but improves the quality of the chunks and citations.

Best for:

• Search over SEC filings
• Section-aware Q&A
• Retrieval APIs
• Filing summarization
• Products that need citations but not full agentic navigation

Avoid relying only on structured RAG when:

• The answer lives mainly in tables or numerical data
• Retrieved sections vary wildly in size and may pollute the context window
• Questions require broad exploration
• Missing information is unacceptable
• The answer depends on multiple distant filing sections
• The agent needs to compare filings section by section

---

Choose Navigation-Based Agents if you need high-quality SEC filing analysis

Navigation-based agents are best when users expect analyst-grade answers.

This approach is especially useful when the agent must:

• Inspect a filing before answering
• Read the right section intentionally
• Cite precise filing passages
• Compare sections across filings
• Avoid missing important disclosures
• Explain the reasoning path through the filing

This is the most filing-native architecture.

It is also the closest to how a real analyst works.

---

The Best Architecture May Be Hybrid

Navigation-based agents do not have to replace search. In many production systems, the strongest architecture combines a filing map with search tools:

1. Use navigation when the question has an obvious filing location, such as MD&A, Risk Factors, segment disclosures, or notes to financial statements.
2. Use keyword, vector, or hybrid search when the agent needs discovery across many filings, companies, or uncommon disclosure language.
3. Use node-level reads before finalizing the answer so citations point to exact filing passages instead of vague retrieval chunks.

The key design choice is sequence. Search can help the agent discover candidates, but the final answer should come from intentionally selected filing sections, tables, or nodes.

---

Practical Recommendation

For most serious SEC filing AI products, the recommendation is:

1. Do not stop at naive RAG.
2. Build or use a filing parser that preserves SEC document structure.
3. Generate a reliable table of contents for each filing.
4. Give the agent tools to inspect the TOC and read specific nodes.
5. Add search as a secondary capability, not the only retrieval mechanism.
6. Require source citations for material claims.
7. Make the agent’s reading path auditable.

Naive RAG is fine for a demo.

Structured RAG is a good production baseline.

Navigation-based agents are the better long-term architecture for high-quality SEC filing analysis.

The reason is simple: SEC filings are structured documents, so AI agents should navigate them as structured documents.

---

Sources and Further Reading

• SEC: Forms List
• SEC: EDGAR filing search
• AlphaCreek: Build with AlphaCreek MCP
• Series: Parse SEC 10-K filings into sections · Build an SEC filing agent without naive RAG · Best SEC EDGAR MCP servers · SEC EDGAR MCP benchmark

---

FAQ

What is the easiest way to build an AI agent over SEC filings?

The easiest way is naive RAG: extract filing text, split it into fixed-size chunks, embed the chunks, store them in a vector database, and retrieve by similarity. This is fast to build but often unreliable for serious SEC filing analysis.

Why does naive RAG perform poorly on SEC filings?

Naive RAG performs poorly because it ignores filing structure. SEC filings have sections like Risk Factors, MD&A, financial statements, and notes. Fixed-size chunks can cut across these sections and remove the context needed for accurate answers.

Is structured RAG better than naive RAG for SEC filings?

Yes. Structured RAG is usually better because it preserves logical sections, headings, metadata, and source references. It gives the LLM more complete and meaningful context than arbitrary chunks.

What is the weakness of structured RAG?

Structured RAG still relies on fixed top-k similarity search. Table-heavy disclosures with little prose — for example, a segment revenue breakdown — may never rank high enough to be retrieved. It also produces logical chunks of vastly different sizes, so fixed top-k retrieval can fill the context window with one oversized section while the exact passage is still missing.

What is a navigation-based SEC filing agent?

A navigation-based SEC filing agent uses a table of contents and node references to inspect and read specific filing sections. Instead of relying only on vector search, the agent first understands the filing structure, then chooses where to read.

Why are navigation-based agents better for SEC filings?

Navigation-based agents are better because they match the structure of the source material. SEC filings are organized documents, not random text. An agent that can inspect the filing map, read relevant sections, and cite exact passages is more reliable than one that only retrieves similar chunks.

Do navigation-based agents replace vector search?

Not always. The best systems can combine both. Navigation is better for structure and reasoning, while vector or keyword search can help with discovery across large document sets.

What is the best architecture for citation-backed SEC filing analysis?

The best architecture is usually a navigation-based agent with structured filing parsing, a table of contents, node-level reads, and precise citation URLs. This allows the agent to answer from exact filing passages instead of vague chunks.

---

Final Takeaway

Building an AI agent over SEC filings is not just a retrieval problem. It is a document-structure problem.

If you flatten a 10-K into random chunks, the agent loses the filing’s natural map.

If you preserve sections, the agent gets better context.

If you let the agent navigate the filing before reading, the system becomes much closer to how a real analyst works.

That is the main architectural lesson:

For SEC filings, the best AI agents do not just retrieve. They navigate, read, and cite.