Retrieval is not extraction

2026-Q4

Two jobs get collapsed into “AI on our documents.” Retrieval: given a question, find the right passage in a pile (manuals, policies, old tickets). Extraction: given a file, fill fields someone already named (invoice total, requirement ID, counterparty). Same OCR output can feed both. The pipeline, the metric, and the UI are not the same. If you dump every page into a vector store and ask for the IBAN, you will get a confident wrong number.

Retrieval

You need this when the user does not know which file to open. Chunk after you have text (see OCR and layout), embed locally unless the corpus is allowed to leave (nomic / BGE / EmbeddingGemma are the small ones we actually run), retrieve a handful of passages, then let a model write an answer with those passages in the prompt. Success is “the reviewer found the right SOP,” or citation hit-rate on a holdout of real questions. Failure is a fluent summary of the wrong policy.

Chat-with-SharePoint is this job wearing a product costume. It still needs a question set from the people who search today, not “show me the chatbot.” If they cannot list twenty questions they already ask, you are still in exploration.

Extraction

You need this when the file is already in hand and the schema is known. Layout or a form model, then fields, then a review queue. Success is exact match (or a written fuzzy rule) on the holdout. A chat UI is the wrong surface: the reviewer wants the page image, the proposed value, and accept/edit. Mixing retrieval into this (“search the pack then guess the IDs”) is how missed requirements show up in an audit.

Classification sits in front of both: SAP export, scan, email PDF. Route before you embed or extract. A regex on a single invoice layout is still allowed to win; that is a successful PoC, not a failed AI project. Related: How we score a 4-8 week PoC.