No engineering background needed, just a sense of what happens between asking a question and getting an answer you can check. Everything below follows one question through that path, start to finish.
The documents have to be read first. Extraction pulls the text, tables, and images out of every file it’s handed, including the messy scanned PDFs.
Each document is split into short so a search can return the exact paragraph that answers you, not a forty-page file.
Every passage becomes an , a list of numbers that captures its meaning, so passages about the same idea end up near each other.
Two searches run at once: one by meaning (), one on the exact text, like an error code (). Running widens the net, so nothing that might be relevant gets left out before reranking gets a look.
E-4021 turns up in six documents; only one tells you how to fix it. re-reads the candidates against your actual question and reorders them accordingly.
The top passages become the answer’s source material. Each claim carries a back to the exact page, so it’s something you can check rather than take on faith.
A couple of those steps are the ones people mix up. Here they are on their own.
An embedding turns a passage into a list of numbers, a kind of coordinate where distance means similarity. “Paid leave,” “vacation,” and “time off” land close together; “operating temperature” sits far away. That’s what lets a search match meaning instead of matching words: a question worded nothing like the document can still find it.
Search works two different ways. Dense, or semantic, search matches by meaning, so “how much vacation do I get” finds a passage about “paid leave accrual” with no words in common. Keyword, or lexical, search matches the literal characters, so a part number or an error code hits exactly, every time. Hybrid search runs both and fuses the results, which is why it’s the safe default, though you can run either one on its own to see what each finds. When a passage is found by both, it’s marked with a dot that’s half teal, half gold.
Retrieval is fast but blunt. It hands back a pile of maybe-relevant passages. Reranking is the second read: a slower, sharper model checks each candidate against your actual question and re-sorts them, pulling the one that truly answers to the top and pushing the near-misses down. It’s the biggest lever on answer quality, and you can switch it on or off per query.
The reading step: pulling clean text out of whatever file you’re handed, including scanned PDFs, tables, and images. You pick the model. Today that’s Mistral OCR, Google Document AI, or LlamaParse.
An embedding model is what turns text into those meaning-vectors. Different models are stronger on different content, from code to finance to law to other languages, so choosing one is a real decision, not a default. You set it per corpus.
A reranker does the second, smarter read. Like embedding models, there’s a catalog to choose from, and the call comes down to how much speed you’re willing to trade for quality.
We carry a broad catalog from the field’s major makers, from Cohere and Voyage to Google and OpenAI, including open models and ones tuned for code, finance, and law. See what each stage runs on →
The answer is buried in unstructured documents, such as contracts, policies, manuals, and reports, and people ask for it in their own words rather than an exact term.
Your data already sits in neat rows and columns a normal database can filter, or when people always search by an exact keyword that plain full-text search handles.
Knowing which case you’re in matters more than reaching for this by default.