A retrieval system over financial data has two jobs that pull in different directions. One is to return an exact number: revenue for Q3, the closing position on a given date, a covered ratio to two decimals. The other is to find the passage in a 200-page filing that explains a one-off charge or a change in revenue recognition. A single store does neither well. Ask a vector index for a precise figure and it will hand you something that reads plausible and is off by a rounding or a period. Ask a warehouse to surface the footnote behind a restatement and it has nowhere to look.
So we build both, and we decide up front which questions each store owns.
Warehouse for figures, vector store for prose
The warehouse holds the structured, numeric truth. Reported financials, time series, positions, anything you would expect to query exactly. When the question is “what was the figure,” the answer comes from a SQL query against typed columns, not from a language model reconstructing a number from text. That keeps arithmetic out of the model’s hands.
The vector store holds the document side: filing narrative, footnotes, management commentary, the text that explains why a number moved. When the question is semantic, “what did they say about supply constraints,” that is where it gets answered.
The interesting work sits between them. Most real questions are mixed. A user asks for a figure and the reasoning behind it. The right pattern is to route the numeric part to the warehouse, the explanatory part to the vector store, and stitch the two responses together so the figure is authoritative and the prose is cited. Getting that routing right matters more than the choice of model.
Chunking that keeps a filing intelligible
Naive chunking destroys financial documents. Split a 10-K every 500 tokens and you cut tables in half, orphan footnotes from the line items they qualify, and strip away which fiscal period a paragraph describes. Retrieval then returns a fragment that is locally fluent and globally wrong.
Our data chunking for filings follows the structure of the document, not a token count:
- Keep each table whole, with its header rows and units attached, so a retrieved table is still readable on its own.
- Bind footnotes to the line item or statement they annotate, rather than letting them float as standalone text.
- Carry the reporting period into every chunk, so a passage about “the quarter” resolves to a specific quarter-end and cannot be confused with another year.
A chunk should be a self-contained unit of meaning. If a person could not read it in isolation and know what company, period, and statement it belongs to, neither can a retriever.
Point-in-time metadata on every chunk
Every chunk carries metadata, and two fields are non-negotiable. The first is point-in-time data: as-of and knowledge dates, so the system answers as the world looked on the requested date and cannot leak a later restatement into an earlier answer. Filings get amended; a figure that was reported and a figure that was later corrected are different facts, and the store has to hold both with the date each became known.
The second is source: document, section, page, and the extraction run that produced the chunk. That gives every answer an audit trail back to a primary document. In finance an answer you cannot trace is an answer you cannot use, and the metadata is what makes lineage cheap instead of a forensic exercise after the fact.
Keeping the two stores reconciled
The split solves the retrieval problem and creates a maintenance one. The warehouse and the vector store now describe overlapping facts, and they can drift. A restated figure lands in the warehouse while the vector store still holds the original filing text. Entity resolution treats two tickers as one company in one store and not the other. Left alone, the system starts contradicting itself.
So reconciliation is a standing job, not a one-off. We run checks that compare the numbers a user would retrieve from the documents against the same numbers in the warehouse, flag divergence, and tie both back to the same point-in-time view. When a filing is amended, both stores update together or the inconsistency gets raised.
Retrieval-ready financial data is mostly this: the right store for each kind of question, chunks that survive being read alone, dates and sources on everything, and a reconciliation process that keeps the two halves honest. The model on top is the part you can swap out. This is the part you have to get right first.