Case studyEnterprise2025
Cut processing resources 75% with an enterprise AI assistant
The constraint was never a lack of information. It was retrieval.
- 75%reduction in processing resources
- 25%faster review times, in production
- Context
- A large support organization ran on a corporate knowledge base that had grown too fragmented to search quickly.
- What I built
- A custom AI assistant combining retrieval-augmented generation with a knowledge graph, grounded directly in that knowledge base.
- Headline result
- 75% reduction in processing resources and 25% faster review times, in production today.
Specification
- Role
- Design, build, rollout
- Timeline
- 2025
- Stack
- Enterprise RAG, knowledge graph, LLM orchestration
- Status
- In production
The problem
A support team at enterprise scale needs answers from a corporate knowledge base that had grown faster than anyone could organize it. Policy documents, install requirements, and program-specific rules lived across separate systems, and finding the right answer to a customer or quote question meant searching several places by hand. That search time compounded across every ticket and every quote review.
The constraint was not a lack of information, it was retrieval. Agents already had access to the facts they needed, they simply could not get to them fast enough, and the team could not afford to slow down onboarding or accuracy while fixing that. Any solution had to plug into how the team already worked, not replace it.
The approach
I chose retrieval-augmented generation over a fully fine-tuned model because the knowledge base was never static. Policies and install requirements changed often, and a fine-tuned model would have gone stale within a few update cycles. Retrieval let the assistant read from the current source documents directly, so updating the knowledge base updated the answers without a retrain.
I layered a knowledge graph on top of plain vector search because agent questions were often relational rather than purely semantic. A question about which install requirement applies to a specific program needs the assistant to understand how entities connect, not just which passages sound similar. Vector search alone kept surfacing passages that were topically close but structurally wrong, so the graph encodes those relationships explicitly.
I kept the answers scoped strictly to the knowledge base rather than letting the assistant draw on general model knowledge. In a support and quoting context, a plausible-sounding but wrong answer is worse than no answer, so I traded conversational flexibility for grounding every response in a traceable source. When retrieval came back empty, the assistant said so instead of filling the gap, which mattered more for trust than any single correct response did.
I rolled it out in stages rather than all at once. Starting with a smaller group surfaced real usage patterns and the gaps in the knowledge base itself, and let me close those gaps before the assistant touched every quote review across the full team.
- 01
Agent question
Asked in the same window the agent is already working in.
- 02
Graph, then passages
The graph resolves which entities are actually related before vector search picks the passages.
- 03
Grounded answer
Every response traces to a current source document, never to model memory.
- 04
Or nothing
When retrieval comes back empty the assistant says so rather than filling the gap.
A plausible-sounding but wrong answer is worse than no answer.
The outcome
The assistant cut processing resources by 75% and made review times 25% faster once it reached the full team. Those gains came less from any single clever technique and more from removing the manual search step entirely. Agents got a grounded answer in the window they were already working in, instead of switching between systems.
It remains in production today, used daily by the team it was built for, which has mattered more than the rollout numbers. A tool that gets adopted once and abandoned saves nobody anything. This one kept getting used because the graph made it accurate enough to trust on the questions that actually came up. Durability, not the first-week spike, is the number I watch on internal tools.
What I would do differently
Invest earlier in retrieval evaluation tooling instead of relying mainly on agent feedback to catch gaps in the knowledge base. Formalize who owned keeping source documents current sooner, since that turned out to matter as much as the retrieval architecture itself.
Some specifics are abstracted for confidentiality. I am glad to go deeper in conversation.