EliconStart a project →
← ALL WORK

CASE 11

10 weeks

Semantic Search over Compliance Docs

Audit questions drafted in minutes, with receipts.

  • Python
  • FastAPI
  • pgvector
  • Hybrid search
  • Postgres
Sector
Regulated financial services
Team
4 compliance officers
Corpus
Regulatory texts + internal policy, mostly PDF
Engagement
Fixed scope, 10 weeks
Output
Cited answer drafts, retained as audit trail

A regulated financial services firm answered audits with Cmd-F across PDFs, producing inconsistent answers depending on which officer did the searching. We built hybrid semantic search over every regulatory and internal policy document, with a drafting interface where the citation trail is the deliverable.

THE PROBLEM

What was going wrong.

Compliance officers answered audits by searching PDFs with Cmd-F. Every audit was a week of copy-paste, and answers were inconsistent between officers.

Regulatory texts, internal policies and prior audit responses lived in three separate shares with no common search. Officers relied on memory of where a control was documented.

Two officers answering the same question cited different sources — sometimes a superseded policy version — which auditors noticed and which turned a routine question into a finding.

Prior audit responses were the most valuable asset in the building and the least accessible, buried in email threads and named things like final_v3_FINAL.docx.

CONSTRAINTS WE WORKED UNDER

  • ·Exact-match matters as much as meaning — regulation identifiers and control codes are keyword queries, and pure vector search fails them.
  • ·Superseded policy versions must remain retrievable but must never be cited as current.
  • ·The system drafts; a human always signs. No answer leaves without an officer's approval.
  • ·Everything runs inside their environment with full access logging.

WHAT WE DID

The short version.

  1. 01

    OCR + semantic chunking pipeline for every regulatory document and internal policy.

  2. 02

    Hybrid search (BM25 + dense vectors) so keyword-exact queries and meaning-based queries both work.

  3. 03

    Draft-an-answer UI where the officer picks the question and gets a cited draft to edit.

  4. 04

    Every draft stored with citations so the audit trail is the answer itself.

ARCHITECTURE

How it's built.

01

Ingestion & versioning

OCR where needed, section-aware chunking, and an explicit version graph per document. Every chunk knows whether it belongs to the current or a superseded version, and superseded content is retrievable only when the query asks for history.

02

Hybrid retrieval

BM25 and dense vectors over the same chunks, fused with reciprocal rank fusion and reranked. Control codes and regulation identifiers hit exactly; 'what do we do about vendor risk' hits semantically. Neither mode alone was adequate in testing.

03

Drafting interface

The officer selects an audit question, the system proposes an answer assembled from retrieved passages with citations attached to each assertion, and the officer edits in place. Edits are tracked separately from generated text.

04

Answer library

Approved answers are stored with their citations and become retrievable themselves, so the next audit starts from the last one instead of from the corpus. This turned out to be the highest-value component.

05

Access & logging

SSO, per-document access rules mirroring their share permissions, and an append-only log of every query, retrieval and approval for the auditors' benefit as much as their own.

KEY DECISIONS

What we chose, and what it cost.

Hybrid retrieval from the start rather than vectors first

WHY

The first evaluation made it obvious: dense-only retrieval failed on control codes, and BM25-only failed on paraphrased policy questions. Every real query set contained both.

TRADE-OFF

More moving parts and a fusion step to tune. Measured on their own question set, it was not close.

Version graph instead of a current-only index

WHY

Auditors ask what the policy was in 2022. Deleting history to keep the index clean would have removed answers they are legally required to produce.

TRADE-OFF

Ingestion complexity and a retrieval filter that must never be forgotten — so it is enforced at the query layer, not left to the caller.

Draft-and-approve rather than auto-answer

WHY

Compliance answers carry personal accountability. Officers were never going to sign something they had not shaped, and building for auto-answer would have produced a tool nobody used.

TRADE-OFF

Less automation on paper. In practice the drafting step is where the week of work disappeared.

THE HARD PARTS

What nearly broke it.

PDFs with two-column layouts and tables

Naive text extraction interleaved columns and destroyed tables, producing chunks that read as nonsense. Layout-aware extraction with table handling was three days of unglamorous work that improved answer quality more than any retrieval tuning afterwards.

Superseded policy leaking into answers

Early on, a draft cited a policy replaced in 2023. That single incident set the design rule: version filtering enforced at the query layer, with historical retrieval requiring an explicit intent from the officer.

Consistency between officers

The answer library was originally a nice-to-have. Once officers started drafting from previously approved answers, inter-officer consistency stopped being a training problem and became a default.

HOW IT RAN

The timeline.

  1. 01

    Corpus & query audit

    Weeks 1–2

    Inventoried documents, measured extraction quality, and collected a real question set from the last three audits to evaluate against.

  2. 02

    Ingestion & versioning

    Weeks 3–5

    Layout-aware extraction, OCR, section-aware chunking, and the document version graph.

  3. 03

    Hybrid retrieval & tuning

    Weeks 6–8

    BM25 and dense indexes, fusion and reranking, tuned against the audit question set until the correct source ranked first consistently.

  4. 04

    Drafting UI & answer library

    Weeks 9–10

    Draft-and-approve workflow, citation rendering, the approved-answer library, then rollout across a live audit.

OUTCOME

What changed.

Days → hours

Time to produce an audit response

Consistent

Two officers, same question, same citations

Full history

Superseded versions retrievable, never citable as current

Every draft

Stored with its citation trail as audit evidence

Audit responses that used to take days now take hours, and two officers generating the same answer produce the same citations.

The answer library compounds. Each audit leaves the corpus better than it found it, which means the fourth audit is meaningfully cheaper than the first.

The unexpected outcome was gap detection: questions where retrieval found nothing turned out to mark genuine documentation gaps, which the team now works through deliberately.

STACK

What it's made of.

BACKEND

  • Python
  • FastAPI
  • Postgres

RETRIEVAL

  • pgvector
  • BM25
  • Reciprocal rank fusion
  • Reranking

INGESTION

  • Layout-aware extraction
  • OCR
  • Version graph
  • Section chunking

GOVERNANCE

  • SSO
  • Access logging
  • Approval workflow

HANDOVER

What they kept.

  • Ingestion and versioning runbook covering new regulations and policy updates.
  • The audit question evaluation set, maintained so retrieval quality stays measurable.
  • Officer training on drafting, history queries and the approval trail.