Retrieval that knows who is asking, across 5,000 people
A German engine manufacturer with over 5,000 employees cut response time on internal enquiries by 30% and raised first-fix rate by 40%. Pexon built an Azure OpenAI retrieval system with permissions computed dynamically per data node, multilingual and multimodal embeddings, and a deliberately smaller model chosen through prompt engineering.
The engagement at a glance
Written for the head of platform or digital operations at a manufacturer where maintenance documentation has accumulated over decades, across several languages and several permission levels, and where the last knowledge-management project failed on exactly that third point.
| Customer | Leading German engine manufacturer, more than 5,000 employees, EUR 2.1 billion revenue |
|---|---|
| Industry | Diesel, gas, hydrogen and electrified drive systems, industrial and marine propulsion |
| Users | Maintenance and service, more than 5,000 people |
| Cloud | Microsoft Azure |
| Stack | Azure OpenAI, multimodal and multilingual embeddings, dynamic knowledge base, prompt engineering tooling, data protection layer, web application |
| Compliance | GDPR, industrial data protection covering construction and maintenance data |
| Status | Productive, under continuous expansion |
Decades of documentation, several languages, and a permission model nobody wanted to touch
The customer builds complex drive systems across diesel, gas, hydrogen and electrification. Over decades that produced an enormous body of technical documentation: maintenance instructions, construction specifications, service bulletins, compliance documents. It sits across several systems, in several languages, at several permission levels.
Maintenance and service staff lost time daily to the same sequence: find the right data source, then the right document, then the relevant passage. Internal experts absorbed the overflow as repeat questions, and support ran into capacity limits. The measurable symptoms were slow response times on internal enquiries and a first-fix rate low enough that people routinely needed a second attempt or had to wait for a specialist.
The reason previous attempts had stalled was the third dimension. Search across systems is a solved problem, and translation is a solved problem, but a search that must respect who is allowed to see which document is where general-purpose tools stop being usable. An assistant that answers everything to everyone is not deployable in a company where construction data and personnel-adjacent maintenance records sit in the same corpus.
Permissions computed per data node, before generation
The access model is the load-bearing part of this system. Every node in the knowledge base carries a dynamically evaluated entitlement, so the permission decision happens during retrieval and a document the asker has no right to never enters the context window at all.
This is a different thing from the common shortcut, which is to generate an answer and then filter it. Post-generation filtering is not an access control. By that point the model has already read the content, and everything downstream depends on it choosing not to reveal what it saw. That is a promise, not a boundary, and it does not survive contact with an auditor.
Building it this way turns a binary into something usable. The alternative most organisations settle for is all-or-nothing: either the assistant indexes only the documents everyone may read, which strips out most of what is worth asking about, or it indexes everything and cannot be opened beyond a small trusted group. Granular entitlement per node is what let this go to more than 5,000 users instead of a pilot cohort.
Trade-off: Resolving entitlement per node at query time costs latency and a great deal more engineering than indexing a flat corpus. It also means the retrieval layer has to stay synchronised with the source systems' permission changes, which is ongoing work rather than a one-off. The alternative was a narrower index that would have been cheaper to build and would have answered a fraction of the questions people actually have.
A deliberately smaller model, and why that was the right call
The system runs on a smaller and substantially cheaper model rather than the largest available. That was a decision, not a constraint. Accuracy was recovered through prompt engineering and pre-processing, and the resulting model cost is roughly five to ten times lower than a frontier-class equivalent.
The reasoning generalises. In a retrieval system the binding constraint is almost never raw model capability, it is whether the right passage made it into the context window. Money spent on chunking, metadata and retrieval quality buys more accuracy than the same money spent on a larger model, and it keeps buying it as volume grows, because retrieval improvements are a fixed cost while model tokens are a variable one.
Multilingual and multimodal embeddings do the rest of the heavy lifting. A German maintenance question can find an English service bulletin without a separate index per language, which for a manufacturer with international documentation is the difference between one assistant and one per region.
- Entitlement computed per data node at retrieval time, not filtered after generation
- Multilingual embeddings across documentation that grew up in several languages
- Multimodal embeddings, because a share of the answer lives in diagrams
- Continuous knowledge refresh rather than a one-off index at go-live
- Internal GenAI capability built inside the customer's own team alongside delivery
What changed
Response time on internal enquiries fell by 30% and the first-fix rate rose by 40%. The second number is the one worth dwelling on: it means fewer enquiries bounce to a second attempt or escalate to a named expert, which is where the real cost of a bad knowledge system sits. Internal knowledge holders and support both got capacity back.
The system is in daily production use across more than 5,000 people and has continued to expand since go-live. Alongside it, GenAI capability was built inside the customer's own team, so the platform is not dependent on the people who built it remaining on site.
What this case study does not prove
It does not prove that a 30% response-time improvement is available to you. That figure came from a starting position with documentation spread across several systems, several languages and several permission levels, and a first-fix rate low enough to have room in it. A company whose documentation already sits in one well-governed system has less to gain and will see a smaller number, which is the honest reading of every percentage on this page.
It also does not prove that the permission model is portable. Entitlement per data node is the right pattern, but the work is in the specific source systems: how they express permissions, whether those permissions are consistent, and whether anybody has audited them recently. In most companies the uncomfortable discovery of the first fortnight is that the existing entitlements are wrong, and the retrieval system is simply the first thing to look at them closely.
Finally, the smaller-model decision is not a general rule. It held because retrieval quality was the binding constraint. In a workload dominated by multi-step reasoning rather than lookup, the same decision would cost accuracy that no amount of prompt engineering recovers, and the arithmetic reverses.
Before and after
| Dimension | Before | After | Effect |
|---|---|---|---|
| Response time on internal enquiries | Slowed by manual search across systems | 30% faster | Maintenance and service processes stop waiting on retrieval |
| First-fix rate | Repeat attempts or escalation to an expert | 40% higher | Experts and support recover capacity |
| Access model | All-or-nothing indexing | Entitlement per data node, evaluated at query time | Deployable to 5,000+ instead of a pilot group |
| Knowledge freshness | Static index, drifts from source | Continuous refresh | Superseded bulletins stop being quoted as current |
Questions buyers ask about this
How do you stop a RAG chatbot answering from documents the user may not read?
By computing the permission at retrieval time, per data node, rather than filtering after generation. In this system every node in the knowledge base carries a dynamically evaluated entitlement, so a document the asker has no right to never enters the context window. Post-generation filtering is not a control, because by then the model has already seen the content.
Do you need GPT-4 class models for an industrial knowledge assistant?
Not in this case. The system runs on a smaller, cheaper model, and the accuracy was recovered through prompt engineering and pre-processing rather than model size. That was a deliberate decision worth roughly five to ten times in model cost, and it holds because retrieval quality, not raw model capability, was the binding constraint.
How do you handle documentation in several languages?
With multilingual embeddings, so a German maintenance question can find an English service bulletin and vice versa without maintaining separate indexes per language. For a manufacturer whose documentation grew over decades across international sites, this is usually the difference between one assistant and one assistant per region.
What happens when the documentation changes?
The knowledge base refreshes continuously rather than being indexed once at go-live. That matters more than it sounds: a maintenance assistant that quotes a superseded service bulletin is worse than no assistant, because the answer arrives with the same confidence as a correct one.
Is this a pilot or is it actually in production?
In production and used daily, serving more than 5,000 people, with continued expansion after go-live. The distinction matters when you are judging whether an approach is real: a pilot proves a model can answer, production proves the permission model, the refresh cycle and the support burden all hold.
The permission model is where these projects usually die
If your documentation is spread across systems, languages and access levels, the two-week blueprint answers the question that decides the whole project: whether your entitlements can be resolved at retrieval time, and what that costs at your document volume.