Ask your documents, not the model's memory
By now you have grounded answers by pasting numbers into the prompt. That works for a small P&L - it falls apart when the source is a 200-page 10-K, a 40-page credit agreement, or a folder of policies. This session is the grown-up version of grounding: upload the whole document, let the tool find the relevant passages, and get an answer that quotes and cites the source. It is the same rail-one, rail-two discipline you already know, scaled to real filings.
RAG in one picture 6 min live
Retrieval-Augmented Generation is a plain idea with a clumsy name. Instead of asking the model what it remembers, you first retrieve the passages of your own document that match the question, then ask the model to answer using only those passages - and to cite them. It solves the "know my 10-K" problem without the model guessing.
LiveWhy retrieval beats "I read the whole thing"3 min▶
You could paste a whole filing into a long-context model and sometimes get away with it. RAG is better for finance because it changes what the model answers from, and it leaves a trail you can audit.
- Grounded, not remembered. The answer is built from passages pulled out of your file, so it reflects that document - not a half-remembered version of a similar one from training.
- Cited, so checkable. A good RAG tool tells you which section or page it used. That citation is the thing you verify - it turns "trust me" into "here, look".
- It scales. One 10-K, a stack of contracts, or a whole policy library - retrieval finds the needle so you do not read the haystack. The mechanics are the same at any size.
Finance uses 6 min live
Once you can ask a document a grounded question, a surprising slice of finance work turns into a query. The pattern is always the same: point the tool at the source, ask a precise question, and demand a citation. The variety is only in the document.
LiveWhere document Q&A earns its keep3 min▶
| Use case | The grounded question you ask |
|---|---|
| 10-K / annual-report Q&A | "What is the revenue recognition policy? Cite the section." |
| Contract & covenant extraction | "List every financial covenant and its threshold, with the clause." |
| Policy-stack search | "What is our approval limit for capital spend? Quote the policy." |
| Invoice / PO field extraction | "Pull vendor, PO number, net terms, and total from this document." |
Notice the tools you would reach for: an enterprise chat with file upload, a "Projects" workspace where you load reference documents once and ask across them, or a vendor's document-Q&A feature built into a contract or filings tool. All the same idea underneath.
Self-studyConsumer vs enterprise, for documents2 min read▶
Rail one does not relax just because you are uploading a file instead of pasting text - it gets sharper. A document upload is often more sensitive than a pasted line.
- Public filings (a company's own 10-K, a published annual report) are fine anywhere - they are already public.
- Your contracts, unpublished policies, and internal financials go only into an enterprise or local tool that does not train on your data. A signed credit agreement is confidential; treat it that way.
- Client documents may carry PII and contractual confidentiality on top. Enterprise or local only, and check you are even allowed to process them this way.
The limits 5 min live
RAG is a huge upgrade over ungrounded chat, but it is not magic and it is not proof. It can retrieve the wrong passage, or miss the right one entirely, and it reads tables and figures badly. The document is the source of truth - the model's summary is a helpful draft you must check against it.
LiveThree ways RAG quietly misleads you3 min▶
- Retrieval can miss. If the relevant passage was not retrieved, the model answers from what it did get - which can be incomplete or the wrong section. A confident answer does not prove the right passage was found.
- Tables and figures parse poorly. A number sitting in a multi-column table, a footnote, or an image can be misread or dropped. Financial data lives in exactly these structures, so treat any figure from a table as unverified until you look.
- The citation is the check, so use it. Always open the cited passage and confirm it actually says what the answer claims. A citation that does not support the claim is the single most common RAG failure - and the easiest to catch.
The covenant that was almost misread. An analyst asked a doc-Q&A tool for a leverage covenant threshold. The tool returned a clean "4.0x" with a citation - but the cited clause was the definition of leverage, and the actual threshold, in a table two pages later, was 3.5x stepping down to 3.0x. The number looked authoritative. Opening the citation caught it in seconds. The document was the source of truth; the summary was not.
Interrogate a public 10-K - and check every citation ★ 13 min · everyone builds
Upload a real, public filing and ask it three targeted questions. The skill you practise is not asking - it is checking: for each answer, you open the cited passage and confirm it says what the model claims.
Grab a public 10-K or annual report - a company you follow, downloaded from its investor-relations site or the SEC. It is public, so any enterprise chat with file upload is fine (rail one).
Upload it and set the ground rule up front: answer only from this document, quote the passage, cite the section or page, and say "not in the document" if it is not there.
Ask three targeted questions: (1) the revenue recognition policy, (2) the largest risk factor management flags, (3) the segment or geographic revenue breakdown.
Now the real work: for each answer, open the cited section in the filing and read it. Does the passage actually support the claim? Note any answer where the citation is vague or does not match.
Stress the segment question - it usually lives in a table. See whether the numbers it pulled tie exactly to the table in the document. This is where RAG is weakest, and where your check matters most.
Extract a clean table of fields from a document ★ 8 min · build your own
The other half of document work is extraction: turning prose into a structured list you can act on. Same grounding discipline, different output - and the same duty to spot-check.
Pick a document with structured terms - a public contract template, a published bond prospectus, or a synthetic agreement you write yourself. Keep it safe for the tool tier you are using.
Ask for a clean, structured extraction of specific fields - not a summary. Name the exact fields you want so the output is consistent and comparable.
Require a citation per field, so each extracted value points back to the clause it came from. A field with no citation is a field you have not verified.
Spot-check accuracy: pick three fields at random, open the cited clauses, and confirm the value is exact. Dates, amounts, and thresholds are where extraction slips most.
From a folder of PDFs to a covenant tracker. A controllership team had 30 loan agreements and no single view of the covenants. A doc-Q&A extraction like this built a first-draft tracker in an afternoon - thresholds, test dates, definitions, each with a clause citation. The draft was 80% right; the team's spot-checks fixed the rest and, crucially, knew where to look because every field carried its source. The AI did the reading; the humans owned the tracker.
Try it yourself - this week ◐ 30-45 min total
- Finish both demos if you did not complete them live. The citation-checking step is the one that matters - do not skip it.
- Take one document you actually work with (public, or synthetic if it is confidential and you lack an enterprise tool) and ask it three questions you usually answer by hand. Time how long the verified answer takes versus reading the whole thing.
- Find one answer where the citation did not fully support the claim, or a table number that did not tie. Keep it - it is your evidence for why the check is mandatory.
- Build a small extraction into a table for a document type you handle often (contracts, invoices, filings). Note which fields the tool got wrong so you know where to always look.
- Optional: skim learn-rag-with-phoebe part 1 if you want to understand why retrieval missed on any question that went wrong.
Official sources covered
This session teaches document Q&A as a finance tool, reusing the retrieval framing from the sibling course and enterprise doc-Q&A documentation. The under-the-hood mechanics stay with the dedicated RAG course - said honestly. This session covers:
Three questions before you go 🎯 ◐ 90 seconds
1 · In one line, what does RAG actually do?
Retrieval-Augmented Generation retrieves matching passages from your own document first, then grounds the answer in them - no memorising, no fine-tuning required.
2 · Why do citations matter so much in a finance document-Q&A workflow?
A citation is the check. It lets you open the exact passage and confirm the answer is supported - turning a plausible summary into a sourced, checkable one.
3 · The tool returns a clean segment-revenue figure with a citation. What should you do before using it?
Tables and figures are where RAG is weakest. A citation is not proof - open the source table and tie the number yourself before it goes anywhere.