Summary: On October 29, 2026, Cohere published a walkthrough of a financial research assistant built with Cohere models on Amazon SageMaker AI, with Claude on Amazon Bedrock writing citation-backed answers. The interesting part is not the demo — it’s the series of tradeoff decisions about how to index pages, when to rerank, and how to keep every claim checkable. If you’re building retrieval over dense documents, the design notes are worth your time.
Why filings break naive RAG
The post opens with a problem any analyst recognizes: the number you need rarely sits in body text. It lives in a table, a footnote, or a chart, and naive PDF-to-text conversion destroys the row and column relationships that give it meaning. Multi-column pages come out scrambled, and charts vanish entirely.
Two more constraints shape the design. An unverifiable answer is useless — nobody puts “the CET1 ratio was 11.9%” in a memo without a filing and a page to point at. And cost compounds: a team indexing thousands of filings embeds every page once, but embeds every question and runs every downstream model on every query.
Two embedding tiers, one index
The core architectural decision: index with Embed Pro, which is tuned for retrieval quality, but answer with Embed Fast, which is tuned for latency. The two tiers share one embedding space, so a question embedded with Fast compares directly against pages embedded with Pro. You get quality where it’s cheap (once per page, offline) and speed where it’s expensive (thousands of times a day, while someone waits).
I’ve argued before that this split is really a pricing decision — one index, two embedding models changes how you cost retrieval, not just how you run it. Cohere’s build makes the same move concrete with vector sizing: 1,024 dimensions stored as int8 takes 1 KB per page versus 8 KB for 2,048-dimension float32, roughly 1 GB versus 8 GB per million pages.
The caveat they flag matters: the query side must match the index’s size and format, and changing either later means re-embedding everything. Settle it early.
Text for search, images for proof
For annual reports — digital documents with decent text layers — they embed page text only, then recover what text loses at answer time by letting Claude view the page image when writing the response. The reasoning: text is cheap to embed and Rerank needs text anyway, so pay the image cost only where a figure is actually being quoted.
They’re explicit about when you’d choose differently. Scans, slides, investor presentations, or faxed exhibits justify embedding the image, or a fused text-and-image vector. That routing judgment — matching the embedding input to what the document actually is — does more for retrieval quality than any leaderboard position.
Rerank as a visible, optional stage
Rerank Pro reorders the candidate pages, and Context Focus marks which passages on each page answer the question. Only those passages (plus the page image) go to the answer model, cutting input tokens while keeping the evidence visible.
The demo treats reranking as a toggle, not a default: the search view shows results with and without Rerank side by side. For financial work they picked the accuracy tier over the fast one on the logic that finding the right page matters more than shaving milliseconds — but the stage is switchable per deployment.
Other choices worth stealing
- Multilingual by embedding space, not translation. Questions in 100+ languages match documents in any other language directly, with no translation step to build, pay for, or mistrust.
- Selective parsing. Cohere Parse handles only low-text and table-heavy pages, once each, rather than parsing everything.
- Typed citations. Every claim cites its page and where on the page the fact came from — table, chart, body text, footnote, or figure — with a one-click page image. That’s the difference between an answer and evidence.
The whole thing deploys via CloudFormation into your own AWS account, so you can experiment with the tradeoffs rather than read about them. The honest limitation: the post is a reference design, and the language coverage, parse routing, and vector sizing all need validation on your own corpus — a reminder that retrieval benchmarks only get you so far before your documents start arguing back.