The capability where enterprise AI most often quietly fails.
Not the model. Retrieval. An agent that cannot find the right passage produces a confident, well-written, wrong answer — and the failure is invisible until a customer or a regulator finds it. This page is about the parameters you can actually control, what each one does to the result, and how to tell which of the three failure modes you are looking at.
Four asset types
Knowledge bases, question-answer libraries, academic libraries and data sources
Chunking you control
Semantic, fixed-length, heading-hierarchy, table-aware — with per-file settings and human review
Retrieval tuning
Hybrid retrieval, adjustable weights, rerank, thresholds, tag filtering, graph multi-hop
Answer traceable
Citations back to source, retrieval results shown by rank with scores
Four kinds of asset, and the ingestion state machine you can watch.
Enterprises do not have a "knowledge base". They have policies, a FAQ that lives in a spreadsheet, academic papers, and a database table — and each of those behaves differently under chunking. Treating them as four asset types rather than one upload button is the first real decision.
Knowledge base
Documents, chunked and retrieved semantically. The default asset for policy, product and operational material.
Question-answer library
Curated question-and-answer pairs, retrieved directly. Highest precision available, and the right asset wherever the question set is genuinely known — because a direct pair match beats a semantic guess.
Academic library
Scholarly material with retrieval helpers built for citation-bearing answers, where the source matters as much as the content.
Data source
Structured tables queried directly rather than chunked. The right home for anything with a schema — and a way to stop your analyst's spreadsheet from being answered by semantic similarity.
What can go in
Documents (PDF, Word, Excel, presentations, plain text, Markdown), web pages by URL with the body extracted automatically, database tables with both structure and data, and cloud documents from your enterprise collaboration platform. External knowledge bases and enterprise knowledge engines can also be connected; where a knowledge engine is involved, a project is mapped to a single workspace, and this mapping is available on the private deployment only.
The ingestion state machine
Every file moves through visible states — pending segmentation → segmentation preview → parsing → vectorisation → imported. This is unglamorous and it is the single most useful operational feature in the whole knowledge module, because it answers the two questions that generate every support ticket: is my document in yet, and what did you actually do with it.
Segmentation configuration is set per file, not per knowledge base. For most corpora that is a feature. For a knowledge base mixing a fifty-page regulation with two-page bulletins, it is the difference between good answers and mediocre ones.
The state machine as an operational control
Three questions we ask you to answer before anyone complains about answer quality:
Who watches the queue?
A batch that fails at parsing looks identical to a batch that was never uploaded, unless someone owns the state.
What did the segmentation preview look like?
The preview is where you discover that a scanned document produced empty segments, or a table was shredded — before the answers go wrong.
Which embedding configuration?
Changing the embedding model invalidates the whole corpus. It is a re-ingestion event, so it belongs on a change calendar.
Knowledge and context in numbers
Documents, structured data, conversations, and live operational state
Every one of them changes an answer
We name all three rather than promising none exist
Enterprise-wide — so you have to narrow it on purpose
Four kinds of asset, and why they are not interchangeable
Retrieval treats these as one undifferentiated pile of text. That single decision is the cause of most "the AI got it wrong" incidents we are called in to fix.
The granularity you can adjust is the proof of the expertise.
Anybody can claim strong retrieval. Claiming that you can set a minimum character count for table preservation, and that you set it differently for a tariff schedule than for a training manual — that is a claim only someone who has tuned a real corpus can make. This is the table we use when we configure a knowledge base.
| Control | Options | What it changes in the result |
|---|---|---|
| Segmentation mode | Semantic chunking | Splits on semantic completeness rather than a character count. Preferred default for prose — policy, guidance, reports. |
| Fixed-length chunking | Splits on character count. Predictable and cheap; useful for uniformly structured material where semantics are already flat. | |
| Heading-hierarchy chunking | Follows the document's own structure. The right choice for anything with real sections — manuals, specifications, contracts. | |
| Segment length & overlap | Both configurable | Longer segments preserve table and clause structure but dilute similarity precision; overlap prevents a fact straddling a boundary from being lost. Table-dense documents generally want a longer segment and a proportionally larger overlap than narrative text. |
| Header/footer removal | Toggle | Repeated page furniture pollutes every segment and distorts similarity. On for anything paginated. |
| Complex table recognition | Toggle plus a minimum retained character count | Keeps a table together instead of letting a row become its own segment. This single setting is the difference between answering tariff and pricing questions correctly and answering them confidently and wrongly. |
| QA extraction | Model-generated question-answer pairs as the segment unit | Builds a QA library from your prose. Excellent for FAQ-shaped content; unnecessary effort for material that is already written as Q&A. |
| Manual segmentation & review | Segment by hand, review segment by segment | Puts a business expert into the loop at the exact point where domain judgement is irreplaceable. Slow, and the highest-return hour in the whole knowledge pipeline. |
How we approach it in practice. We start with the highest-frequency real questions from your support and service logs, not with the document library. We take a few hundred of them, and let them tell us what the segmentation should look like. A knowledge base tuned to the questions people actually ask beats a knowledge base tuned to the shape of the folder it was uploaded from — and the tuning is measured, not asserted.
Six controls, and every one of them changes an answer
This is the granularity you can adjust. It is also the proof of the expertise — anyone can turn on retrieval; making retrieval return the right thing requires knowing why it did not.
| Control | What you set | What it changes | Set it wrong and |
|---|---|---|---|
| Chunk size | How far a retrieved passage spans | Whether a retrieved passage answers the question or merely sits near it | The agent gets half a rule and invents the other half |
| Overlap | How much adjacent context is carried | Whether cross-references survive retrieval | It cites a clause whose exception lives in the next chunk |
| Hierarchy | Whether parent-child structure is preserved | Whether the agent sees the section or the whole document | It quotes a heading as if it were a requirement |
| Metadata filter | Which document classes are eligible | Whether an agent can see a draft, a superseded version, or another region's policy | It quotes a document that was withdrawn in March |
| Freshness window | How recent a document must be | Whether an answer reflects a policy that has since changed | It is confidently out of date |
| Rerank depth | How many candidates are re-scored | Whether the best passage wins or merely a plausible one | The right document is retrieved at rank 40 |
Every knob below changes an answer. That is the point.
Retrieval is not a switch, it is a parameter surface. The teams who get good answers are the ones that tuned it against a question set and could explain why each value is what it is. The teams who got lucky will not keep it.
Hybrid retrieval combines four sources: vector retrieval for meaning, full-text retrieval for exact terms, question-answer pair retrieval, and external knowledge sources. Pure vector search loses the precise term — a part number, a statute reference, a person's surname — that a human would have keyed on. Pure keyword search cannot answer a paraphrased question. Most enterprise corpora need both, and the mix is a configuration decision.
Semantic versus keyword weight is adjustable, and the correct value depends on the corpus. Contract review and compliance work generally want semantic weight pushed high, because the query and the document express the same idea in different words. Manuals and reference documentation usually want keyword weight pushed higher, because users quote the exact term they are looking at. Tuning this without looking at retrieved chunks is guessing.
Top-K bounds how many segments are returned. Too few and the answer lacks context; too many and the strongest irrelevant segment can outrank the correct one after assembly. Small values of K — in the low single digits — suit precise question-answering. Larger values suit synthesis questions that genuinely need several passages.
Query rewriting for multi-turn. Where a question depends on the conversation so far, it is rewritten against the history before retrieval. This measurably improves accuracy on the second, third and fourth question of a session. It is off by default because it adds latency and token cost — which is the correct default, since on a large estate those costs are paid on every request to fix a minority of them.
Intelligent retrieval
When enabled, a model rewrites the recall keywords semantically before the search runs, and returns a leading model-generated summary of what it found. Useful where users describe a problem rather than naming the thing they need.
| Retrieval type | Strongest on |
|---|---|
| Vector / semantic | Paraphrase, concept, "how do I" phrasing |
| Full-text / keyword | Identifiers, names, numbers, exact terminology |
| QA pair | Curated questions already answered correctly |
| External source | Material living in another system of record |
Enabling more than one is the norm. The interesting question is not which to use, but in what proportion.
Reranking is the single largest quality improvement available to a RAG system, and it is the one most often skipped. The problem it solves: the first retrieval pass is optimised for speed and recall, so it returns a generous set of candidate segments. What actually matters is their order, and first-pass similarity is a poor proxy for that. Reranking inserts a more expensive, more accurate ordering step between recall and generation.
Two strategies are available: a semantic reranking model, which is fast and consistent, and large-model reranking, which reasons about relevance directly and handles nuance better at higher cost and latency. For most enterprise corpora the semantic model is the right default, and large-model reranking earns its cost on genuinely ambiguous questions.
Four parameters govern the stage, and all four must be set together:
- Initial candidate count. How many segments the first pass returns. Too small and the correct answer was never a candidate.
- Number entering reranking. How many of those are re-ordered. Lower is faster and cheaper; set it too low and you re-rank almost nothing.
- Ranking score threshold. Segments scoring below it are dropped. This is the main control over how much weak context reaches the generator.
- Final segments returned. How many survive into the answer. Small values produce focused answers; large values invite the generator to blend an irrelevant passage in.
Inspect the retrieval, not just the answer
Retrieval results can be displayed by rank, with each recalled segment and its score visible. This is the most underrated diagnostic in the entire platform, because it separates two failures that look identical from the outside: the right passage was never retrieved, versus it was retrieved and buried.
One implies a chunking or recall problem. The other implies a reranking or threshold problem. They have completely different fixes, and without seeing the ranked list you are guessing which one you have.
A working practice. Take twenty questions where the answer was wrong. For each, look at the ranked segments. Most organisations find that the majority are ranking problems, not chunking problems — which is fortunate, because ranking parameters can be changed in an afternoon and a re-ingested corpus cannot.
Similarity and confidence thresholds
Results below a configured similarity or confidence threshold are not returned — or are routed to a human. This is the mechanism that lets an agent say "I don't know" instead of producing a plausible answer from weak evidence, and for compliance, financial and safety-adjacent use cases it is the most important parameter on the page.
The trade-off is explicit: a high threshold produces more honest refusals and more escalations. A low threshold produces more answers and more of them wrong. There is no setting that avoids the choice, which is why we make it per agent rather than globally.
Tag filtering and graded answering
Knowledge base tags can filter the retrieval scope, which enables graded or domain-partitioned answering — an employee in one business unit retrieves only from the sources approved for them. In practice this is how organisations implement differentiated answers from a single platform: the tag is derived from who is asking, not from the question.
Knowledge graph enhancement and multi-hop
Graph-enhanced retrieval supports multi-hop question answering — where the answer requires following a relationship chain rather than retrieving one passage. "Which of our suppliers also supply our competitor's subsidiary in this region" is not a retrieval problem at all; it is a graph traversal problem.
This is where the cost curve bends. Graph enrichment is meaningful engineering, and the questions that need it are usually the ones with real business value — related-party exposure, dependency chains, ownership structures.
Multiple knowledge bases on one agent
Several knowledge bases can be mounted on a single agent, with retrieval priority and trigger rules configured between them. Where a single base reaches its scale limit, the practice is to split by domain and mount separately, so each keeps its own permission model and its own tuning.
Mounting several bases without configuring priority is a common cause of an agent confidently citing the wrong policy — two versions of the same rule exist in different bases, and the higher-priority one is stale.
Bring your worst twenty questions. We will diagnose them together.
This is a free half-day and it is the fastest way to find out whether you have a knowledge problem or a reasoning problem — which have completely different fixes.
Bring your worst twenty questions
The ones where the answer exists somewhere but nobody can find it. Not the easy ones.
We trace each one
Through ingestion, chunking, embedding, retrieval, rerank and generation — and identify the exact stage it failed at.
You get a failure distribution
How many fail at retrieval, how many at ranking, how many at reasoning. Most estates find the majority are in one stage.
You get the fixes in order of cost
Granularity changes first because they are cheap and reversible. Rebuilding the corpus is a last resort, not a first move.
You get the regression test
Those twenty questions become a permanent test set, so the next ingestion change cannot silently break them again.
The default is enterprise-wide visibility. You have to narrow it on purpose.
Access control on a knowledge base defaults to visible across the whole enterprise. That is convenient, and it is the setting that produces a security finding in your first penetration test. Narrowing it is a deliberate act — which is why we do it for you during deployment.
Knowledge bases can be scoped to specified departments, or to a whitelist of departments and roles. Separately, knowledge bases, plugins, models and agents are authorised independently, at a granularity fine enough to support departmental data isolation — which is what makes it possible to let a team query a dataset without letting the organisation query the other team's.
Provenance is configurable per retrieval node: whether source text is shown or hidden, and whether the answer carries the document link back to the original. For a customer-facing assistant, citation is not a nicety — it is the difference between "here is our answer" and "here is our answer and here is the clause it came from, from the version in force on the date you asked".
The knowledge update mechanism, stated precisely. Newly uploaded documents are parsed and vectorised automatically and become effective within roughly ten minutes. An edit to an existing document does not re-vectorise automatically — it must be triggered manually.
This is the most important operational detail on the page. It means a superseded policy sitting in production is indistinguishable from a current one until someone remembers to trigger it. Any organisation whose content changes on a cycle — pricing, regulation, product specifications, clinical guidance — needs a named owner and a re-vectorisation trigger in the same procedure as the document approval. We put that in the operating runbook at deployment; it does not manage itself.
Answering "how do we know this is current?"
A question every regulated deployment has to be able to answer, usually to an auditor. The chain has to hold end to end.
Source of record
One authoritative system owns each policy, and the knowledge base is fed from it rather than maintained separately.
Approval, not upload
Content reaches the knowledge base through the same approval as everything else. Upload is not publication.
Trigger on change
A named owner re-vectorises after an edit. Automated where the source system can notify; manual with a schedule where it cannot.
Scope the blast radius
Permissions and tags configured so an edited document cannot be answered by a user who should not see the new version.
Cite the version
Answers return the source, so a disputed answer can be traced to the exact document behind it.
Three ways retrieval-augmented generation fails.
Every bad answer comes from one of these three places. They present identically to a user — a confident, fluent, wrong response — and they have completely different remedies. Diagnosing which one you have is most of the work.
Chunking destroyed the meaning
The information needed to answer exists in the corpus, but it was split away from the question it belonged to. A condition and its exception in different segments. A table row separated from its header. A clause that only means something with the paragraph above it.
Symptoms: the answer is right for every piece it retrieved, and still wrong overall. It works on one question and fails on the obvious follow-up. Specificity is high, completeness is missing.
Fix: segmentation mode, segment length, overlap, table preservation, and manual review of the affected documents. This one requires re-ingestion — which is why we check segmentation before touching anything else.
Retrieved correctly, ranked wrongly
The right passage was in the candidate set and got ranked below a plausible irrelevant one. Nothing was missing from the corpus; the ordering presented it as irrelevant.
Symptoms: you can see the answer in the retrieved segments when you inspect the list by rank. It appears at positions four, seven, nine — not at one. Improving with a bigger Top-K suggests ordering, not coverage.
Fix: reranking — initial candidate count, rerank depth, score threshold, final segment count — plus semantic versus keyword weighting and the confidence threshold. All changeable without re-ingesting anything.
Generated away from the context
Retrieval was correct and ranking was correct, and the answer still departed from what the passages said — filling gaps from the model's prior knowledge, blending in a plausible general fact, or answering a neighbouring question that was not asked.
Symptoms: introducing specifics that appear nowhere in the corpus. Confidently answering when the passages were only tangentially relevant. Answering differently depending on how the question is phrased.
Fix: prompt discipline — a prohibition field for out-of-scope questions and a constraint to answer only from retrieved context — plus raising the confidence threshold so weak context is refused rather than stretched. Evaluation catches this class that the other two are invisible to.
The order we diagnose in matters. Check failure one first, because it is the only one that requires re-ingestion and the only one that everything else cannot fix. Then check failure two, because it is the cheapest to correct and the most common. Failure three is real and it is a prompting and evaluation problem — but by the time you have eliminated the first two, most organisations find that failure three has largely disappeared, because most "generation problems" were retrieval problems all along.
Three ways retrieval-augmented generation fails
We are not going to tell you these cannot happen. We will tell you which of the three you have, because the fix is different in each case and most vendors only ever address the third.
Retrieval misses
The correct document was retrieved but not the correct passage within it. Symptom: the agent is vague where it should be specific. Cause: granularity, not the model.
Retrieval returns the wrong version
A superseded policy outranks the current one because nothing encoded the effective date. Symptom: the agent contradicts your current policy while quoting your own document.
Retrieval succeeds, reasoning fails
The right text was in front of the agent and it still concluded wrongly, often because the rule requires arithmetic or a multi-step dependency. Cause: task design, not knowledge.
Three things we will not claim about knowledge management
These come from reading the documentation rather than from the marketing page, and each one has a compensating control that we implement with you.
No productised knowledge expiry
There is no documented TTL, no automatic document retirement at end of validity, and no knowledge versioning mechanism. We will not describe knowledge as self-expiring, because it is not. What we build instead: document lifecycle as an operating procedure — a named owner per knowledge base, a review cadence, approval-aligned re-ingestion, and staging in a non-production environment before promotion. This is a process control and we scope and price it as one, because it requires people, not configuration.
Scanned-document OCR needs verifying per version
The vendor's own community material contradicts itself — one note describes editable text formats only, another describes automatic OCR recognition of scans. Rather than pick the more convenient reading, we test your actual sample documents during a technical workshop — your scans, at your resolution, in your language — and let the result decide whether OCR is a capability you can rely on. Where it falls short, we will tell you whether an external OCR step in front of ingestion is worth it.
Scale limits we quote only in writing
Per-base document and storage ceilings, and per-agent throughput figures, appear in community material but are not confirmed in formal documentation. If your design depends on a specific scale — and in most enterprises it does — we will get you a sourced figure from the vendor or we will size the deployment so it does not depend on one. We will not put an unverified number in a slide deck and let you design against it.
And one property of this platform that is a feature. A knowledge base is visible across the enterprise by default. That default is the right starting point for genuinely public material and the wrong one for almost everything else. Converge it deliberately at deployment: department scoping or a department-and-role whitelist per base, tag filtering for differentiated answering, and separate authorisation for knowledge bases, plugins, models and agents. Anything left enterprise-wide after review should be a decision someone made, not one they inherited.
Three things we will not claim about knowledge management
Context engineering does not fix a knowledge base that nobody maintains. It will not resolve a contradiction between two of your own policies — that is an organisational decision we can surface but not make. And it does not make an undocumented process discoverable, because it is genuinely not written down anywhere.
Five questions that settle whether you need this
Five yes-or-no answers. If you cannot answer the first three, the capability is not your bottleneck yet.
- Can you name the specific workflow this serves — not the department?
- Can you name the person accountable when it is wrong?
- Can you show me historical cases where a human did this task, so we can build an evaluation set?
- Can you tell me what this capability explicitly will not do?
- Can you tell me what it costs per task, and how you would reduce that cost?
What the first ninety days look like
The same shape on every capability. The content differs; the checkpoints do not.
| By day 30 | By day 60 | By day 90 |
|---|---|---|
| Baseline captured on your metric | Workflow running with a named approver | Metric moved, against the baseline you did not choose |
| Scope boundary documented — including what it may not do | Evaluation harness re-running on every change | Decision log reviewed by your risk function |
| Historical cases assembled for testing | Training delivered, completion in the LMS | Next workflow scoped from what we learned |
| Data lineage for every source the agent reads | Cost per task measured and modelled | Evidence pack complete and accepted |
What this page answers
Every topic below is covered in the sections above, and each links to the page that goes deeper on it.
Bring your worst twenty questions. We will diagnose them together.
Real questions with known-correct answers from your own service logs, run against your own corpus. You will leave knowing which of the three failure modes you have, what it would cost to fix, and what the tuned configuration looks like.