Retrieval Quality Starts With Preprocessing

Financial institutions are required to keep electronic archives for anywhere from ten to thirty years. When a regulator or an internal audit comes calling, they don't ask for a summary. They ask you to produce the exact record from seven years ago, or from well over a decade back. Miss that record and you don't have a search problem. You have a compliance gap, and in a regulated shop a gap is a risk event with a price tag attached.

The frustrating part is that most of these organizations already hold the documents. They're just undiscoverable. A file named scan_2021_04_final_v3.pdf says almost nothing about whether it contains the board resolution you need, the counterparty's amended clause, or the stamp that proves execution. Filename search was built for a world where humans named things descriptively and kept doing it. Finance doesn't live in that world, and the mismatch is now structural rather than occasional.

The numbers behind the mess

A few survey figures are worth keeping in your pocket when you argue for budget.

IDC estimates global data at roughly 149 to 180 zettabytes in 2024, climbing toward about 394 zettabytes by 2028, with 80 to 90 percent of it unstructured. That bucket is scans, contracts, emails, statements — material that never fits neatly into a database column and therefore never gets the indexing attention it deserves.

A 2025 Smallpdf survey of 1,005 US employees found finance workers spend about 6.1 hours a week simply relocating files they had already seen. That was the worst of any industry in the survey. A separate 2025 Kaspersky survey of 1,066 people found 57 percent couldn't find important files, only 30 percent organize their files regularly, and 26 percent keep a "junk folder" they dump things into. None of that is a narrow tooling failure. It's a finding failure, and a finding failure inside a retention-bound archive is exactly the kind of thing that surfaces during an audit as a deficiency.

Why filename search fails in finance

Filenames are lossy handles. They compress a rich document into a short string that someone typed under time pressure, often conforming to a scheme nobody fully remembers. In finance the same document type recurs constantly — loan agreements, KYC packets, board minutes, audit confirmations — but the content inside them diverges wildly: different parties, clauses, riders, redlines, jurisdictions, effective dates. The filename captures none of that distinction.

Filename search also assumes the naming scheme survived contact with reality. It usually hasn't. A share gets migrated, a team renames a folder, a merger drops two taxonomies on top of each other, and now Q3_report_final exists in eleven places with different contents. You fall back to searching by memory of where you last saw something, which doesn't scale past one person's brain and vanishes when that person leaves.

Compliance questions are rarely about a file. They're about a fact: "Did counterparty X sign the amended version before the rate change?" That fact lives in a sentence inside a page inside a PDF scan. Filename search can't reach it. Keyword search gets closer but collapses on synonyms, scanned images with no text layer, and the natural variation of how people phrase the same obligation.

Here's a concrete shape of the failure. Suppose a 2019 credit agreement was amended twice, and the second amendment moved a covenant from page 14 to a rider at the end. The filename says credit_agreement_2019_amend2. A keyword search for "covenant" returns the original page 14, now stale, ahead of the rider that actually governs. The human needs to know the amendment structure to even form the right query. Filename and keyword search both push that burden onto the searcher, and in a 30-year archive the searcher has no chance of holding the structure in their head.

What semantic retrieval actually does

Semantic retrieval changes the unit of search from the filename to the content's meaning. You turn documents into dense vector representations — embeddings — where texts with similar meaning sit close together in a high-dimensional space. A query like "did we amend the credit agreement after the downgrade" can match a paragraph that never uses the word "amend" but says "the parties hereto agree to modify the facility."

This is the core idea behind retrieval-augmented generation. Instead of asking a model to answer from its training memory, you retrieve the relevant passages first and ground the answer in them. For finance, grounding isn't optional — you want every answer traceable back to a source record, not to a plausible hallucination that sounds authoritative.

A practical note on the encoders themselves: off-the-shelf general-purpose models do a credible job, but finance has its own vocabulary — ISDA, netting opinions, MAC clauses, specific regulatory citations — where generic models blur distinctions. Domain-adapted or fine-tuned encoders tend to separate near-duplicate legal language from meaningfully different language more reliably. You don't need a bespoke model on day one, but if retrieval quality plateaus, the encoder is a likelier culprit than the vector database.

The trap is that teams bolt a vector database straight onto a pile of raw PDFs and call it a system. It sort of works, then it gets expensive, noisy, and occasionally wrong in ways that matter. The durable win is almost always in front of the retrieval, in how you prepare the documents, not in the vector store itself. More on this approach lives on our products page at https://www.uglypear.com/en/products/.

Preprocessing: parse, desensitize, compress, structure

An underrated step in any financial RAG pipeline is what you do before a document is ever embedded. Four stages carry most of the value.

Parse. Finance lives in scans, faxes, multi-column statements, and tables that break naive extractors. You need layout-aware parsing that recovers reading order, tables, and — critically — stamps and seals. A stamp is frequently the legally operative part of a document, so losing it during ingestion is a silent failure you won't notice until an audit asks for it. Good parsers also preserve the relationship between a footnote and the clause it qualifies, which matters when a retrieved fragment has to stand on its own.

Desensitize. Before anything gets indexed or handed to a model, mask or tokenize the personal and sensitive fields. This isn't only privacy compliance; it's what lets you run retrieval and generation on infrastructure that doesn't need to be a vault for raw PII. Doing desensitization as an ingestion stage, rather than as an afterthought at query time, means the embeddings themselves never carry the sensitive values, which shrinks your exposure surface considerably.

On technique: you have options ranging from simple redaction to format-preserving tokenization (replace a tax ID with a reversible surrogate that keeps the same shape so downstream logic still works) to k-anonymity style generalizations for analytics. The right choice depends on whether you need reversibility and who holds the key. Decide this at ingestion, not per query.

Compress. Large scans and high-resolution images are brutal on token budgets. Document compression that shrinks a large scan or image down to roughly 20 to 40 percent of its original footprint — a 60 to 80 percent reduction — while keeping the stamps legible changes the economics of the pipeline. You embed and store a fraction of the tokens, the retrieval step carries less noise, and the downstream model reads less junk per query. Compression here is a cost and accuracy lever, not a cosmetic one.

Structure. Turn the parsed content into chunks with metadata — document type, party, date, jurisdiction, version. Good chunking, with sensible overlap and table preservation, is what stops retrieval from returning a fragment that's technically adjacent but semantically useless. That metadata is also what makes fragment-level authorization possible, which we'll cover next.

Chunking strategies and their tradeoffs

Chunking deserves its own mention because it's where most retrieval quality is quietly won or lost. Too large, and a chunk blends three unrelated topics so the embedding represents none of them well. Too small, and you shred a clause across boundaries so the retrieved fragment is incomplete.

A few patterns hold up. Fixed-size with overlap is the easy default but ignores document structure. Recursive splitting on natural boundaries respects meaning better. Hierarchy-aware chunking keeps a parent pointer so you can return a clause with its enclosing section context. Table-aware chunking treats a table as an atomic unit so a query about a specific row doesn't return a disconnected cell. None of these are exotic; they're just disciplined, and they matter more than people expect when the documents are as structurally messy as financial ones tend to be.

Why compression pays off twice

People hear "compress" and think "smaller files to store." In a RAG pipeline the larger payoff is on the token side. Every token you embed is a token you store, search across, and later re-read at query time. A contract scan that is mostly whitespace and a high-DPI stamp can dominate your index with low-information tokens. Squashing that footprint while keeping the operative content means the retrieval step spends its attention budget on signal rather than paper texture.

Less noise also means fewer false-positive matches. When your index is padded with decorative tokens, a query can surface a visually similar but irrelevant page. Compression that preserves meaning over decoration keeps the top results honest, which is the difference between a system people trust and one they quietly route around.

Fragment-level authorization

Permission can now drop to the fragment level. Not "who can open this folder," but "which roles can see which sentences."

In practice, authorization is enforced at retrieval time. When a user queries, the system checks, per fragment, whether that identity is permitted to see it, and returns only the authorized slices. A junior analyst might retrieve the payment terms of a contract but not the counterparty's internal credit commentary embedded in the same document. The permission lives with the content, not with a file boundary drawn years ago for an entirely different reason.

This matters because real financial documents are messy composites. One PDF can contain public terms, confidential pricing, and privileged legal notes. Legacy access models force you to either over-share the whole file or lock it entirely. Fragment-level control lets the document stay whole while the view adapts to the reader.

A worked scenario makes it concrete. A credit agreement PDF contains the executed terms (shareable with the relationship team), the pricing grid (restricted to treasury), and a side note from counsel about litigation risk (privileged, visible only to legal). Under folder-level permissions, legal either blocks the whole file or everyone sees the privileged note. Under fragment-level authorization, a treasury user querying "what's our current margin" gets the pricing grid and terms but not the counsel note; legal gets all three. The same source document serves three views without three copies.

A few operational details make this trustworthy rather than frightening. The system should connect directly to your existing databases and authorization sources without copying the data out, so you aren't standing up a parallel copy that drifts from reality. Updates should be incremental — you don't reindex the world to add one amended clause. And you want snapshot rollback plus anti-misdelete, so a bad batch or an accidental purge doesn't become unrecoverable. Those are the boring features that decide whether a compliance team will trust the system at 2 a.m. before an audit.

Hybrid retrieval, re-ranking, offline eval

If you take only three industry-standard methods from this post, take these.

Hybrid retrieval. Don't choose between keyword and vector — use both. Lexical search, the BM25-style family, is excellent at exact terms: account numbers, legal entity identifiers, clause references. Dense vectors catch meaning and paraphrase. Fusing them covers each other's blind spots, and the fusion step is cheap relative to the recall it buys. A common pattern is to run both, take the union of top candidates, and merge scores with a simple weighted combination before re-ranking.

Re-ranking. The first retrieval pass optimizes for recall — get the candidates. A cross-encoder re-ranker then reorders the top results by true relevance, reading the query and each candidate together rather than comparing independent vectors. This two-stage pattern is the gap between "it found something" and "it found the right thing." In compliance work the second matters more than the first, because a confident wrong answer is worse than a slow correct one.

Offline evaluation. Build a labeled set of questions with known correct source passages, and measure recall at k and answer faithfulness on every change. Treat your retrieval pipeline like production software, because it is. If you can't reproduce last month's evaluation numbers, you can't ship a change with confidence. Offline eval is how you keep a governance system governable, and it's the piece most proofs-of-concept skip and most production incidents later expose. Budget for it from the start. The engineering angle is discussed further at https://www.uglypear.com/en/blog/.

Keeping the data where it belongs

For regulated finance, the documents usually can't leave the intranet. That one requirement removes a large category of convenient hosted options and forces a few deliberate decisions.

On-premise deployment means the parser, the embedding step, the vector store, and the retrieval service all run inside your boundary. The data stays in your intranet; only the query and the authorized answer cross the wire to the user's client. This is different from a private cloud tenant, where the data may still transit outside your direct control. The distinction matters to auditors.

Running retrieval in-house has tradeoffs you should plan for. You own the latency budget: embedding a query is cheap, but hybrid search across a multi-million-document index with a re-ranker in the loop needs sensible indexing — partitioning by year or entity, precomputed candidate sets — to stay interactive. You also own uptime and the snapshot-and-rollback discipline discussed earlier. The payoff is that you never explain to an examiner why a counterparty's records showed up in someone else's environment.

A quieter benefit of keeping everything local: your evaluation set, your desensitization rules, and your authorization sources all live in the same trust boundary. The "is this answer actually allowed to be shown" check happens next to the data it governs, rather than across a network boundary where policy and enforcement tend to drift apart. For a system whose entire job is defensible answers, that proximity is worth more than it looks like on a diagram.

A framework for choosing an approach

When teams ask how to think about this, I steer them away from vendor feature lists and toward a small evaluation framework they can map any option onto.

The point isn't that one column always wins. It's that you should be able to answer each row for whatever you're evaluating, and the answers should match your risk posture. A regulated entity with a ten-year retention horizon has different row answers than a small team that keeps records for two. Use the table to pressure-test claims, not to crown a winner.

Pulling it together

The reason filename search fails in finance isn't that search engines are weak. It's that the actual unit of work — a fact buried in a decades-spanning archive of scans and composites — was never addressable by a filename in the first place.

Semantic retrieval fixes the matching. A preprocessing pipeline that parses, desensitizes, compresses, and structures fixes the cost and the noise. Fragment-level authorization fixes the access model that legacy folders never could. Hybrid retrieval, re-ranking, and offline evaluation are the methods that keep the whole thing honest enough to defend in front of an examiner.

The unglamorous advice is to spend more effort on ingestion than on the vector database. The databases are largely commodities now. The parse-desensitize-compress-structure stage is where finance-specific value — and most of the risk — actually lives. It's also where stamp preservation and desensitization either hold up or quietly fail.

If you're scoping this, the architecture above stands on its own regardless of which implementation you choose. For an example of the category, including compression that preserves stamps and fragment-level authorization built in, see https://www.uglypear.com/en/products/.

Try it now

Ready to put these ideas to work on your own archive? Explore the platform and see how preprocessing-first retrieval fits a regulated environment:

• https://www.uglypear.com/en/products/
• https://www.uglypear.com/en/
• https://www.uglypear.com/en/blog/

FAQ

Does the order of preprocessing steps matter, and why parse before compress?
Yes, order matters. You must parse first, because compression operates on the recovered layout and text — if you shrink a scan before extracting its reading order and tables, you risk discarding the very structure that makes a fragment meaningful. Desensitize next so sensitive values never enter the embeddings, then compress to cut the token footprint, then structure with metadata. Reversing parse and compress turns a careful pipeline into guesswork.

How do you evaluate retrieval quality before a system goes live?
With offline evaluation. Build a labeled set of questions paired with the known correct source passages, then measure recall at k and answer faithfulness on every pipeline change. Treat the retrieval stack like production software: if you can't reproduce last month's numbers, you can't ship a change with confidence. Most proofs-of-concept skip this and most production incidents later expose it.

Why run both keyword and vector search instead of picking one?
Neither alone is enough. Lexical search (BM25-style) is strong on exact terms — account numbers, entity identifiers, clause references — while dense vectors catch meaning and paraphrase. Hybrid retrieval fuses the two so each covers the other's blind spot, and a cross-encoder re-ranker then reorders the merged candidates by true relevance. The fusion is cheap relative to the recall it buys.

Can permissions really go below the file level in practice?
They can, and in finance they often must. Fragment-level authorization enforces access per sentence at retrieval time, so a treasury user sees pricing and terms but not a privileged counsel note in the same PDF. The permission lives with the content, not with a folder boundary drawn years ago. It lets one source document serve several roles without several copies.