Will it answer right, keep the wrong people out, and cost what you were quoted?
Every one of those is usually a leap of faith — a demo run on someone else's documents, a permission rule buried in a prompt nobody can audit, a bill that only makes sense after launch. We settle all three before you build anything: a benchmark scored on your own files, access enforced in the query itself rather than asked for nicely, and a cost per document you see up front.
You're probably here for one of four reasons.
Maybe you need an assistant that answers from your documents. Maybe it's one bot for three audiences who shouldn't all see the same things. Maybe it's a backlog of scanned paperwork nobody wants to key in by hand. Maybe it's a support agent that can actually check your systems, not just your manual. Whichever one is yours, it reads from the same governed index, follows the same access rules, and is scored the same way below — so starting with one doesn't lock you out of adding the others later.
RAG agents
Answer from your documents, cite the passage, and decline when the grounding is not there.
Q&A agents
Multi-turn, entitlement-aware, embedded where the user already is — web, app, chat or your product.
Support & connector agents
Read the ticket, find the answer, check the system of record, and propose the write.
Extraction agents
Turn a scanned pile into typed records with fields, confidence scores and a human loop.
See yourself in one of these?
Names withheld at the customers' request — the numbers are exactly as they came out of live engagements, not a case study written for this page.
One assistant, three audiences
They needed a public assistant on their website, a second one inside their customer portal, and a third for staff. The obvious plan was to build three. We built one and let each person's login decide what it can see.
A million documents, priced before we started
Decades of scanned mail, tax forms, bills and contracts, heading for a million documents a year. Before writing a pipeline we benchmarked nine AI models on their real files and told them what each one would cost.
Answers where the team already works
Their knowledge lived in a company wiki nobody searched. Rather than build another portal, we indexed the wiki and put the assistant inside the chat tool the team has open all day.
You already have public, customer and internal audiences. Now they share one brain — without sharing what each one can see.
Building three separate bots is the safe-looking choice, and it's also where the same policy quietly drifts apart across three codebases. We route every question — from whichever audiences you have, however many that is — through one index, and decide what this specific caller may see at the moment they ask. Not from a system prompt. From an identity check that runs before the model is ever called, and is tested on every release before it ships.
It says "I don't know"
A grounding sufficiency check runs before generation. Below threshold, the platform returns a defined no-information response and never calls the generation model — which removes the opportunity to synthesise rather than merely discouraging it.
Source and section, every time
Answers return citation objects with document title, section label and expandable detail. Section labels come from chunk metadata assigned at ingest, so a citation names a specific location rather than a 200-page file.
Thumbs down goes somewhere
Feedback carries the turn id, the rating and the sources retrieved at the time of the answer — so it routes to the owner of the document that produced it, not to a general inbox.
$0.13 – $0.28 per multi-turn session
Held there by splitting the work, not by weakening the answer. A small model handles turn-by-turn context gathering and intent; the larger model is reserved for retrieval synthesis where accuracy actually pays.
| Volume | Sessions / month | Est. AI cost / month |
|---|---|---|
| Early | 1,000 | ~$200 |
| Growth | 10,000 | ~$2,000 |
| Scale | 50,000 | ~$10,000 |
Assumes ~$0.20 per 10–15 turn session. Your figure comes out of a benchmark on your own content, not this table.
Inside your tenant, on your models
For regulated buyers the whole pipeline — ingestion, artifacts, vector store and inference — runs inside your existing compliant cloud tenant. Nothing leaves the boundary.
- Azure Foundry, AWS Bedrock, GCP or self-hosted open weights
- HIPAA-aligned deployment with BAA where required
- Automated PHI and sensitive-content screen at ingest, before embedding
- Model layer stays swappable — no rewrite when you change providers
- Prompt-injection defences, rate limiting, no user uploads into chat
Chunked the way each document is read
One window size for every document is a decision too, and usually the wrong one. Each class in your corpus gets its own strategy, set once at ingest — not tuned per query.
| Document class | Strategy | Window |
|---|---|---|
| Policies & manuals | Semantic | ~700 tok |
| Spec sheets | Layout aware | per table |
| Contracts | Clause split | per clause |
| Support tickets | Whole record | 1 per ticket |
| Call transcripts | Speaker turn | ~400 tok |
Built in, not bolted on
Six things a retrieval layer has to get right, not six products you have to stitch together yourself.
From a scanned pile to records you can trust — with the confidence score to prove it
If you've tried extraction before and watched accuracy fall off a cliff on certain document types, this is usually why: reading a document is three steps, not one. Work out what kind of document it is. Pull the fields that matter for that kind. Then decide whether you believe the result. Most projects fail at step one, because nobody ever wrote down what the document types actually are — and no model can classify a category that was never properly defined.
It tells you which types are broken
On a real 8-type benchmark, three types failed across all nine models — one at 0%. Those were not model problems. They were undefined boundaries between look-alike categories. Naming that in week two is worth more than a better model.
The archive comes too
Multi-page TIFF out of a legacy DMS, converted, re-filed under the new naming convention, validated on a pilot set before the full run. A migration task, run as a migration task — not an R&D problem dressed up as one.
Extraction is not the finish line
A typed record is only useful if something happens to it. Extracted transactions map into the ledger, validate against the daily bank feed, post automatically when they are unambiguous and land in a review queue when they are not.
The answer is in the manual. The context is in the CRM. The action is in a third system.
A support agent that can only read documents is a search box. The useful version knows which product this customer owns, what they have already reported, and what it is allowed to do about it. That means it needs your documents and your systems in the same place, under the same rules.
Where the context lives
Wiki, SharePoint, Drive, OneDrive, chat spaces, web, ticketing exports, warehouses, CRM, and direct database or REST connections. New sources are configuration, not a project.
Scheduled and incremental
Full and incremental sync on a schedule, with per-file status — indexed, failed, skipped, queued — so you always know what the agent can and cannot answer on today.
MCP, brokered once
Agents reach systems through one governed door instead of N bespoke integrations nobody can audit. Permissions are defined once and enforced across every agent.
Where people already are
Web widget, REST API, your own product via embed, or inside the chat tool your team has open all day — 1:1 and in group channels.
Why did your last two AI pilots give two different numbers for the same question?
Usually it's not a data problem. It's two definitions of "active customer" living in two different tools, and nobody ever wrote down which one wins. A database answers "what is the total?" A graph answers "how does this connect to that, and what follows from it?" The difference between the two pictures below is the difference between an agent that can look things up and an agent you can actually trust with a decision.
Definitions stop the arguments
Two teams asking the same question and getting different numbers is usually not a data problem. It is two definitions of the same word. Write it down once and every agent inherits it.
It accrues from ordinary work
Nobody funds a graph project. But every dashboard someone builds requires deciding what "active customer" means and which system is right. Capture that decision and you have the graph as a by-product.
The next agent is cheaper
The first agent pays to work out who your entities are. The second one inherits it. That is the only reliable test of whether you have an architecture or just a collection of pilots.
You don't have to take our word for which model is best — trust the benchmark run on your documents.
Every vendor picks one AI model and calls it a platform decision — usually the one that's cheapest for them to run, not most accurate on your files. We run your documents through nine models at once, mark the results against answers you supply, and show accuracy and cost per document side by side. Then you choose: for accuracy, for cost, or for a sensible point in between.
Upload your documents
A batch of real files from every type you handle. Not a curated sample.
Run every model at once
Each document is classified and extracted by all selected models in parallel, on the same parse.
Score against ground truth
Classification accuracy, field-level extraction accuracy, and cost per document per model.
Lock in the chain
One model, or a split — classify with one, extract with another. Per document type if it pays.
| Model | Tier | Classify | Extract | $ / doc | @ 1M docs | Where it earns its place |
|---|---|---|---|---|---|---|
| Gemini 3.7 Flash | Budget | 95.2% | 56.2% | $0.0102 | $10,183 | Top classifier |
| Gemini 2.5 Flash ★ | Budget | 93.7% | 61.5% | $0.0026 | $2,567 | Best value — recommended default |
| Qwen3.6 27B | Budget | 90.5% | 62.1% | $0.0178 | $17,788 | Strong on both, priced high |
| Claude Haiku 4.5 | Mid | 88.9% | 74.2% | $0.0083 | $8,332 | Best extractor by a distance |
| Kimi K2.6 | Premium | 86.5% | 60.4% | $0.0193 | $19,276 | Strong classifier, premium price |
| Gemma 4 31B | Budget | 83.3% | 51.5% | $0.0073 | $7,323 | Solid mid-field classifier |
| Grok 4.5 | Mid | 77.8% | 54.6% | $0.0115 | $11,548 | Holds up on high page counts |
| Llama 4 Scout | Budget | 73.7% | 39.5% | $0.0023 | $2,347 | Cheap, thin on extraction |
| Phi-4 32B | Budget | 57.1% | 39.1% | $0.0006 | $585 | Pre-screening only |
Model cost only — classify plus extract. Parsing is separate and identical across models. Your numbers will differ; that is the point of running it on your documents.
Split the chain when the split pays
No single model was best at both jobs. Classification and extraction are different tasks, so we route them separately and price the combination.
The same idea, applied to a Q&A agent
Routing is not only for document pipelines. Inside a conversational agent, five functions run on five different models — and only one of them needs to be large.
| Function | Model class | Why |
|---|---|---|
| Embeddings | Embedding model | One-time cost per document at ingest plus a small per-query cost. Re-embedding only on change. |
| Query rewriting | Smallest available | Reference resolution and terminology normalisation on a short input. A bigger model adds latency and cost, not quality. |
| Reranking | Dedicated reranker | The highest-leverage spend in the pipeline, and the reason the generation step can stay small. |
| Answer generation | Mid-tier by default | Escalated only when evaluation shows a quality gap that retrieval improvements do not close. |
| Image description | Vision, at ingest only | Never at query time — so media handling is a bounded one-time cost per document, not a recurring one per question. |
The model is not your bill. Pages are.
If you've already been quoted "per-model" pricing and it didn't explain what you were actually spending, here's why: at scale, simply reading the pages — scanning and text recognition — is about 84% of the cost, and it's identical no matter which AI model you pick. Teams spend months tuning the other 16%. The biggest saving available to you is sending fewer pages, not switching models.
| Avg pages / doc | Parse | Model | Total / doc | @ 1M docs |
|---|---|---|---|---|
| 1 page | $0.009 | $0.002 | $0.011 | $10.4K |
| 3 pages | $0.027 | $0.005 | $0.032 | $31.2K |
| 5 pages | $0.046 | $0.009 | $0.054 | $52K |
| 10 pages | $0.091 | $0.018 | $0.108 | $103.9K |
| 20 pages | $0.182 | $0.035 | $0.217 | $217K |
| 40 pages | $0.364 | $0.070 | $0.433 | $433K |
Send fewer pages
Page selection before parsing. On a 40-page insurance policy, the fields you want live on four pages. Route the rest to storage, not to OCR.
Route by document type
Cost per type varies by an order of magnitude, driven almost entirely by length. Cheap, short, high-accuracy types can go to production while the expensive ones are still being tuned.
Match the model to the step
A pre-screen model at $0.0006 a document can triage before an accurate model is invoked. Precision where it pays, cheapness everywhere else.
An accuracy number from someone else's documents tells you nothing about yours.
Ask any vendor for their accuracy number and you'll get one — usually from a benchmark you never saw, on documents that aren't yours. In the first weeks here, we sit with your experts and build an answer key from real questions with known-correct answers on your own files. Everything after that is scored against it, before launch and every week afterwards — so the number you get is one you watched us earn.
| Dimension | How it is measured | What it protects you from |
|---|---|---|
| Retrieval accuracy | Golden question set per tier, scored on whether the correct passage appears in the retained top results. Recall@k and mean reciprocal rank. | An answer that reads well because the model wrote around a missing source. |
| Answer groundedness | Automated claim-level attribution — every factual claim traced to a retrieved passage — with human spot review on a sample. | Fluent text that cites a real document and still says something the document does not. |
| Hallucination rate | Adversarial and out-of-scope question sets, measuring how often the platform answers when it should have declined. | Confidence in the absence of evidence. |
| Entitlement correctness | Per-tier automated test on every release. Pass or fail, not a score. | The failure that ends the programme rather than degrading it. |
| Classification accuracy | Per document type against labelled ground truth, per model, with the confusion pairs named. | Averages that hide one type failing completely. |
| Extraction accuracy | Field level, per type — not document level. A record that is 90% right may still be unusable. | Rounded-up numbers that fall apart in production. |
| Cost per unit | Per document and per conversation, tracked against the target you set, broken into parse and model. | A pilot that works and a bill that cannot scale. |
| Latency | End to end, median and 95th percentile. | An accurate agent nobody waits for. |
Audit and golden set
What exists, who may see it, which version is authoritative, and the question set everything will be scored against.
Benchmark and pilot
Models run against your corpus, chains costed, one agent live for one team on one workflow.
Scored and scoped
Accuracy against the golden set, cost against your target, and a named list of what is not working yet and why.
How does any of this actually work?
The technique underneath every assistant on this page is called RAG — retrieval-augmented generation. The name is ugly. The idea is simple: before the AI answers, go and fetch the relevant pages from your own documents, and make it answer from those. It stops the model inventing things, and it lets it cite where the answer came from.
Five kinds of RAG, and when each one is worth it
They build on each other. Start at the top only if your content is simple and your risk is low. Most real businesses end up somewhere between three and five.
Simple RAG
Find the passages that look most like the question, and answer from them. Quick to stand up and genuinely useful on a small, clean, public set of documents.
The catch: it has no idea which document is current, who is allowed to read it, or that two of them contradict each other. Fine for a product FAQ. Not fine for a policy library.
Hybrid RAG
Run two searches. One for meaning, one for the exact words — part numbers, error codes, clause references, the things meaning-search blurs. Then re-order the results by how recent and how authoritative each source is.
Worth it when: your documents have versions, revisions and things that get superseded. Which is to say, almost always.
Highest similarity, lowest rank — authority and recency decided, not the vector.
Graph RAG
Some answers are not in any one paragraph. "Which customers are affected by this recall" means hopping from a part, to the products containing it, to the orders, to the accounts. A graph stores those connections so the agent can follow them.
Worth it when: your questions span several documents and systems, and the connection between them is the answer.
The clause and the record, in one table — contract language cited alongside the CRM data it explains.
Agentic RAG
Instead of one search, the agent breaks the question into steps, decides what to look up and which system to call, checks whether what it found is actually enough, and tries a different angle when it is not.
Worth it when: the question needs several lookups or an action — resolving a ticket, reconciling a record, preparing a case. Slower and dearer per question, so reserve it for work that earns it.
Multimodal RAG
Most real knowledge is not plain text. It is a wiring diagram, a dosage table, a scanned form, a recorded call. We read all of it at ingest — describing images, keeping tables intact, transcribing audio and video — so the answer can hand back the actual diagram, not a paragraph about it.
Worth it when: your procedures live in pictures and tables. Because it happens once when the document arrives rather than every time someone asks, the cost is bounded and predictable.
Bring documents. We will tell you what they cost and how accurate we can be.
Ninety minutes, your systems, no deck. You leave with a benchmark on your own files: accuracy per model, cost per document, the types that are ready for production, and the ones that need a schema before they are worth another run.
Will it answer right, keep the wrong people out, and cost what you were quoted?
Every one of those is usually a leap of faith — a demo run on someone else's documents, a permission rule buried in a prompt nobody can audit, a bill that only makes sense after launch. We settle all three before you build anything: a benchmark scored on your own files, access enforced in the query itself rather than asked for nicely, and a cost per document you see up front.
You're probably here for one of four reasons.
Maybe you need an assistant that answers from your documents. Maybe it's one bot for three audiences who shouldn't all see the same things. Maybe it's a backlog of scanned paperwork nobody wants to key in by hand. Maybe it's a support agent that can actually check your systems, not just your manual. Whichever one is yours, it reads from the same governed index, follows the same access rules, and is scored the same way below — so starting with one doesn't lock you out of adding the others later.
RAG agents
Answer from your documents, cite the passage, and decline when the grounding is not there.
Q&A agents
Multi-turn, entitlement-aware, embedded where the user already is — web, app, chat or your product.
Support & connector agents
Read the ticket, find the answer, check the system of record, and propose the write.
Extraction agents
Turn a scanned pile into typed records with fields, confidence scores and a human loop.
See yourself in one of these?
Names withheld at the customers' request — the numbers are exactly as they came out of live engagements, not a case study written for this page.
One assistant, three audiences
They needed a public assistant on their website, a second one inside their customer portal, and a third for staff. The obvious plan was to build three. We built one and let each person's login decide what it can see.
A million documents, priced before we started
Decades of scanned mail, tax forms, bills and contracts, heading for a million documents a year. Before writing a pipeline we benchmarked nine AI models on their real files and told them what each one would cost.
Answers where the team already works
Their knowledge lived in a company wiki nobody searched. Rather than build another portal, we indexed the wiki and put the assistant inside the chat tool the team has open all day.
You already have public, customer and internal audiences. Now they share one brain — without sharing what each one can see.
Building three separate bots is the safe-looking choice, and it's also where the same policy quietly drifts apart across three codebases. We route every question — from whichever audiences you have, however many that is — through one index, and decide what this specific caller may see at the moment they ask. Not from a system prompt. From an identity check that runs before the model is ever called, and is tested on every release before it ships.
It says "I don't know"
A grounding sufficiency check runs before generation. Below threshold, the platform returns a defined no-information response and never calls the generation model — which removes the opportunity to synthesise rather than merely discouraging it.
Source and section, every time
Answers return citation objects with document title, section label and expandable detail. Section labels come from chunk metadata assigned at ingest, so a citation names a specific location rather than a 200-page file.
Thumbs down goes somewhere
Feedback carries the turn id, the rating and the sources retrieved at the time of the answer — so it routes to the owner of the document that produced it, not to a general inbox.
$0.13 – $0.28 per multi-turn session
Held there by splitting the work, not by weakening the answer. A small model handles turn-by-turn context gathering and intent; the larger model is reserved for retrieval synthesis where accuracy actually pays.
| Volume | Sessions / month | Est. AI cost / month |
|---|---|---|
| Early | 1,000 | ~$200 |
| Growth | 10,000 | ~$2,000 |
| Scale | 50,000 | ~$10,000 |
Assumes ~$0.20 per 10–15 turn session. Your figure comes out of a benchmark on your own content, not this table.
Inside your tenant, on your models
For regulated buyers the whole pipeline — ingestion, artifacts, vector store and inference — runs inside your existing compliant cloud tenant. Nothing leaves the boundary.
- Azure Foundry, AWS Bedrock, GCP or self-hosted open weights
- HIPAA-aligned deployment with BAA where required
- Automated PHI and sensitive-content screen at ingest, before embedding
- Model layer stays swappable — no rewrite when you change providers
- Prompt-injection defences, rate limiting, no user uploads into chat
Chunked the way each document is read
One window size for every document is a decision too, and usually the wrong one. Each class in your corpus gets its own strategy, set once at ingest — not tuned per query.
| Document class | Strategy | Window |
|---|---|---|
| Policies & manuals | Semantic | ~700 tok |
| Spec sheets | Layout aware | per table |
| Contracts | Clause split | per clause |
| Support tickets | Whole record | 1 per ticket |
| Call transcripts | Speaker turn | ~400 tok |
Built in, not bolted on
Six things a retrieval layer has to get right, not six products you have to stitch together yourself.
From a scanned pile to records you can trust — with the confidence score to prove it
If you've tried extraction before and watched accuracy fall off a cliff on certain document types, this is usually why: reading a document is three steps, not one. Work out what kind of document it is. Pull the fields that matter for that kind. Then decide whether you believe the result. Most projects fail at step one, because nobody ever wrote down what the document types actually are — and no model can classify a category that was never properly defined.
It tells you which types are broken
On a real 8-type benchmark, three types failed across all nine models — one at 0%. Those were not model problems. They were undefined boundaries between look-alike categories. Naming that in week two is worth more than a better model.
The archive comes too
Multi-page TIFF out of a legacy DMS, converted, re-filed under the new naming convention, validated on a pilot set before the full run. A migration task, run as a migration task — not an R&D problem dressed up as one.
Extraction is not the finish line
A typed record is only useful if something happens to it. Extracted transactions map into the ledger, validate against the daily bank feed, post automatically when they are unambiguous and land in a review queue when they are not.
The answer is in the manual. The context is in the CRM. The action is in a third system.
A support agent that can only read documents is a search box. The useful version knows which product this customer owns, what they have already reported, and what it is allowed to do about it. That means it needs your documents and your systems in the same place, under the same rules.
Where the context lives
Wiki, SharePoint, Drive, OneDrive, chat spaces, web, ticketing exports, warehouses, CRM, and direct database or REST connections. New sources are configuration, not a project.
Scheduled and incremental
Full and incremental sync on a schedule, with per-file status — indexed, failed, skipped, queued — so you always know what the agent can and cannot answer on today.
MCP, brokered once
Agents reach systems through one governed door instead of N bespoke integrations nobody can audit. Permissions are defined once and enforced across every agent.
Where people already are
Web widget, REST API, your own product via embed, or inside the chat tool your team has open all day — 1:1 and in group channels.
Why did your last two AI pilots give two different numbers for the same question?
Usually it's not a data problem. It's two definitions of "active customer" living in two different tools, and nobody ever wrote down which one wins. A database answers "what is the total?" A graph answers "how does this connect to that, and what follows from it?" The difference between the two pictures below is the difference between an agent that can look things up and an agent you can actually trust with a decision.
Definitions stop the arguments
Two teams asking the same question and getting different numbers is usually not a data problem. It is two definitions of the same word. Write it down once and every agent inherits it.
It accrues from ordinary work
Nobody funds a graph project. But every dashboard someone builds requires deciding what "active customer" means and which system is right. Capture that decision and you have the graph as a by-product.
The next agent is cheaper
The first agent pays to work out who your entities are. The second one inherits it. That is the only reliable test of whether you have an architecture or just a collection of pilots.
You don't have to take our word for which model is best — trust the benchmark run on your documents.
Every vendor picks one AI model and calls it a platform decision — usually the one that's cheapest for them to run, not most accurate on your files. We run your documents through nine models at once, mark the results against answers you supply, and show accuracy and cost per document side by side. Then you choose: for accuracy, for cost, or for a sensible point in between.
Upload your documents
A batch of real files from every type you handle. Not a curated sample.
Run every model at once
Each document is classified and extracted by all selected models in parallel, on the same parse.
Score against ground truth
Classification accuracy, field-level extraction accuracy, and cost per document per model.
Lock in the chain
One model, or a split — classify with one, extract with another. Per document type if it pays.
| Model | Tier | Classify | Extract | $ / doc | @ 1M docs | Where it earns its place |
|---|---|---|---|---|---|---|
| Gemini 3.7 Flash | Budget | 95.2% | 56.2% | $0.0102 | $10,183 | Top classifier |
| Gemini 2.5 Flash ★ | Budget | 93.7% | 61.5% | $0.0026 | $2,567 | Best value — recommended default |
| Qwen3.6 27B | Budget | 90.5% | 62.1% | $0.0178 | $17,788 | Strong on both, priced high |
| Claude Haiku 4.5 | Mid | 88.9% | 74.2% | $0.0083 | $8,332 | Best extractor by a distance |
| Kimi K2.6 | Premium | 86.5% | 60.4% | $0.0193 | $19,276 | Strong classifier, premium price |
| Gemma 4 31B | Budget | 83.3% | 51.5% | $0.0073 | $7,323 | Solid mid-field classifier |
| Grok 4.5 | Mid | 77.8% | 54.6% | $0.0115 | $11,548 | Holds up on high page counts |
| Llama 4 Scout | Budget | 73.7% | 39.5% | $0.0023 | $2,347 | Cheap, thin on extraction |
| Phi-4 32B | Budget | 57.1% | 39.1% | $0.0006 | $585 | Pre-screening only |
Model cost only — classify plus extract. Parsing is separate and identical across models. Your numbers will differ; that is the point of running it on your documents.
Split the chain when the split pays
No single model was best at both jobs. Classification and extraction are different tasks, so we route them separately and price the combination.
The same idea, applied to a Q&A agent
Routing is not only for document pipelines. Inside a conversational agent, five functions run on five different models — and only one of them needs to be large.
| Function | Model class | Why |
|---|---|---|
| Embeddings | Embedding model | One-time cost per document at ingest plus a small per-query cost. Re-embedding only on change. |
| Query rewriting | Smallest available | Reference resolution and terminology normalisation on a short input. A bigger model adds latency and cost, not quality. |
| Reranking | Dedicated reranker | The highest-leverage spend in the pipeline, and the reason the generation step can stay small. |
| Answer generation | Mid-tier by default | Escalated only when evaluation shows a quality gap that retrieval improvements do not close. |
| Image description | Vision, at ingest only | Never at query time — so media handling is a bounded one-time cost per document, not a recurring one per question. |
The model is not your bill. Pages are.
If you've already been quoted "per-model" pricing and it didn't explain what you were actually spending, here's why: at scale, simply reading the pages — scanning and text recognition — is about 84% of the cost, and it's identical no matter which AI model you pick. Teams spend months tuning the other 16%. The biggest saving available to you is sending fewer pages, not switching models.
| Avg pages / doc | Parse | Model | Total / doc | @ 1M docs |
|---|---|---|---|---|
| 1 page | $0.009 | $0.002 | $0.011 | $10.4K |
| 3 pages | $0.027 | $0.005 | $0.032 | $31.2K |
| 5 pages | $0.046 | $0.009 | $0.054 | $52K |
| 10 pages | $0.091 | $0.018 | $0.108 | $103.9K |
| 20 pages | $0.182 | $0.035 | $0.217 | $217K |
| 40 pages | $0.364 | $0.070 | $0.433 | $433K |
Send fewer pages
Page selection before parsing. On a 40-page insurance policy, the fields you want live on four pages. Route the rest to storage, not to OCR.
Route by document type
Cost per type varies by an order of magnitude, driven almost entirely by length. Cheap, short, high-accuracy types can go to production while the expensive ones are still being tuned.
Match the model to the step
A pre-screen model at $0.0006 a document can triage before an accurate model is invoked. Precision where it pays, cheapness everywhere else.
An accuracy number from someone else's documents tells you nothing about yours.
Ask any vendor for their accuracy number and you'll get one — usually from a benchmark you never saw, on documents that aren't yours. In the first weeks here, we sit with your experts and build an answer key from real questions with known-correct answers on your own files. Everything after that is scored against it, before launch and every week afterwards — so the number you get is one you watched us earn.
| Dimension | How it is measured | What it protects you from |
|---|---|---|
| Retrieval accuracy | Golden question set per tier, scored on whether the correct passage appears in the retained top results. Recall@k and mean reciprocal rank. | An answer that reads well because the model wrote around a missing source. |
| Answer groundedness | Automated claim-level attribution — every factual claim traced to a retrieved passage — with human spot review on a sample. | Fluent text that cites a real document and still says something the document does not. |
| Hallucination rate | Adversarial and out-of-scope question sets, measuring how often the platform answers when it should have declined. | Confidence in the absence of evidence. |
| Entitlement correctness | Per-tier automated test on every release. Pass or fail, not a score. | The failure that ends the programme rather than degrading it. |
| Classification accuracy | Per document type against labelled ground truth, per model, with the confusion pairs named. | Averages that hide one type failing completely. |
| Extraction accuracy | Field level, per type — not document level. A record that is 90% right may still be unusable. | Rounded-up numbers that fall apart in production. |
| Cost per unit | Per document and per conversation, tracked against the target you set, broken into parse and model. | A pilot that works and a bill that cannot scale. |
| Latency | End to end, median and 95th percentile. | An accurate agent nobody waits for. |
Audit and golden set
What exists, who may see it, which version is authoritative, and the question set everything will be scored against.
Benchmark and pilot
Models run against your corpus, chains costed, one agent live for one team on one workflow.
Scored and scoped
Accuracy against the golden set, cost against your target, and a named list of what is not working yet and why.
How does any of this actually work?
The technique underneath every assistant on this page is called RAG — retrieval-augmented generation. The name is ugly. The idea is simple: before the AI answers, go and fetch the relevant pages from your own documents, and make it answer from those. It stops the model inventing things, and it lets it cite where the answer came from.
Five kinds of RAG, and when each one is worth it
They build on each other. Start at the top only if your content is simple and your risk is low. Most real businesses end up somewhere between three and five.
Simple RAG
Find the passages that look most like the question, and answer from them. Quick to stand up and genuinely useful on a small, clean, public set of documents.
The catch: it has no idea which document is current, who is allowed to read it, or that two of them contradict each other. Fine for a product FAQ. Not fine for a policy library.
Hybrid RAG
Run two searches. One for meaning, one for the exact words — part numbers, error codes, clause references, the things meaning-search blurs. Then re-order the results by how recent and how authoritative each source is.
Worth it when: your documents have versions, revisions and things that get superseded. Which is to say, almost always.
Highest similarity, lowest rank — authority and recency decided, not the vector.
Graph RAG
Some answers are not in any one paragraph. "Which customers are affected by this recall" means hopping from a part, to the products containing it, to the orders, to the accounts. A graph stores those connections so the agent can follow them.
Worth it when: your questions span several documents and systems, and the connection between them is the answer.
The clause and the record, in one table — contract language cited alongside the CRM data it explains.
Agentic RAG
Instead of one search, the agent breaks the question into steps, decides what to look up and which system to call, checks whether what it found is actually enough, and tries a different angle when it is not.
Worth it when: the question needs several lookups or an action — resolving a ticket, reconciling a record, preparing a case. Slower and dearer per question, so reserve it for work that earns it.
Multimodal RAG
Most real knowledge is not plain text. It is a wiring diagram, a dosage table, a scanned form, a recorded call. We read all of it at ingest — describing images, keeping tables intact, transcribing audio and video — so the answer can hand back the actual diagram, not a paragraph about it.
Worth it when: your procedures live in pictures and tables. Because it happens once when the document arrives rather than every time someone asks, the cost is bounded and predictable.
Bring documents. We will tell you what they cost and how accurate we can be.
Ninety minutes, your systems, no deck. You leave with a benchmark on your own files: accuracy per model, cost per document, the types that are ready for production, and the ones that need a schema before they are worth another run.