Faster Enterprise Knowledge: What Our 34% GraphRAG Improvement Means
We made FabrCore's GraphRAG ingestion faster. Processing our three-document policy corpus took 16.9 seconds instead of 25.5 seconds—about 34% less waiting—with the same number of AI calls. In a separate repeat-processing test, fuller caching reduced rebuild time by about 94%.
- Policy-batch ingestion: 25.5 → 16.9 seconds. Two documents progressed together under the same shared AI request limit. Both settings made seven model calls, and all 163 embedded chunks remained available.
- Cached repeat rebuilds: 8.457 → 0.542 seconds. Adding taxonomy and combined-response caching to the existing result and embedding caches eliminated new language-model and embedding calls on fully cached repeats.
- The slower experiment stayed disabled. We rejected an optional extraction format that added processing time without meeting the factual checks.
These are separate measured improvements: the half-second result applies to reusable, previously processed content. Together, they show two practical opportunities—finish document batches sooner and avoid spending AI calls on work that can safely be reused.
GraphRAG combines document search with a graph of entities and relationships. For a business reader, that graph might connect a policy to its publisher, a department to its responsibilities, or an organization to the rules it follows. Those connections can help an application explain relevant information. They are also places where a small mistake can change the meaning.
This is the business companion to our engineering account of AI-assisted GraphRAG tuning. These are exploratory measurements from public documents, not a forecast for every company's workload.
What makes this a substantial knowledge platform
FabrCore combines meaning-based document search with a graph of named entities and typed connections. It also provides domains and categories to organize knowledge, document versions and contribution tracking to maintain it, and scoped search to limit retrieval to the knowledge boundaries supplied by the application.
That combination gives developers several ways to assemble useful evidence: find a passage, find an entity, follow its relationships, or combine those approaches. Administration and measurement interfaces make the underlying knowledge inspectable. The implementation uses SQL Server's graph and vector capabilities and can run behind a website, in a background process, or through an AI agent.
The advanced part is the combination of retrieval, relationships, maintenance, and visibility. Its business value depends on whether those capabilities answer the organization's real questions accurately.
Four business use cases for enterprise GraphRAG
These are candidate applications of the architecture. Our public-document evaluations do not establish results for customer deployments in these areas.
1. Policy and responsibility discovery
The question: “Who owns this responsibility, and where is it defined?” A policy knowledge assistant could connect departments, responsibilities, and source policies while retrieving the relevant wording. The intended benefit is less time reconciling scattered guidance. Evaluation must preserve the actor, exceptions, and distinction between mandatory and recommended actions; our experiments showed why those details need explicit checks.
2. Supplier and contract knowledge
The question: “Which suppliers support this service, and which agreements describe their commitments?” Connecting vendors, services, agreements, and internal owners could help procurement and operations assemble a review. Dates, amendments, conflicting terms, and access boundaries would need dedicated testing before users relied on the result. This is a knowledge-discovery aid, not a validated contract interpretation product.
3. Technical support and operational handoffs
The question: “Which systems depend on this component, and where are their runbooks?” A graph can represent documented dependencies while vector search finds relevant troubleshooting passages. That could help support staff gather context for an investigation. The test is whether the correct dependency direction, system version, and owning team survive extraction; a missing edge must never be treated as proof that no dependency exists.
4. Project onboarding and institutional knowledge
The question: “Why was this decision made, who owns it now, and what documents explain it?” Linking projects, teams, decisions, and their source material could give a new employee a more navigable starting point. Useful evaluations would check superseded decisions, current ownership, and retrieval from only the employee's allowed scopes.
Across these scenarios, faster ingestion shortens the wait before new material becomes available. Reuse can avoid paying to process identical content again. Neither benefit replaces checking whether the connections are correct.
What became faster
In one controlled comparison, processing two documents concurrently reduced ingestion time from about 25.5 to 16.9 seconds for a three-document policy corpus. The limit on simultaneous AI requests stayed the same. We made better use of capacity already available to the pipeline.
That is approximately 34% less waiting for that batch. It does not imply a 34% reduction in AI spending: the runs still made seven model calls. Speed, cost, and capacity need separate measurements.
Repeated work offered another opportunity. In a separate experiment, rebuilding previously processed content with fully reusable results took about half a second and made no new language-model or embedding calls. That depended on the content and relevant context being reusable. A newly uploaded document does not automatically receive the same benefit.
What a successful search can hide
Our retrieval checks repeatedly found the right document. Yet the graph could omit a responsibility, reverse a relationship, or confuse a publisher with an author. Finding the policy and correctly representing it are different tests.
Consider “agencies must use open formats” and “agencies should prioritize non-proprietary formats.” Making both mandatory alters the source. Dropping the recommendation loses useful information. Neither problem is solved by a polished answer or a green search test.
We tested selected facts against the stored graph, including the actor, relationship direction, and requirement wording. Business teams can help define these evaluations: which assertions would matter if an employee relied on them?
Why we rejected a promising improvement
We tried giving each relationship a separate field for whether an action was required, recommended, permitted, or prohibited. The data survived storage correctly. But the model sometimes produced contradictory combinations, triggering more processing.
Average ingestion increased from 28.8 to 46.4 seconds in that comparison, and some required facts still failed our checks. We left the option disabled. More elaborate AI output does not automatically mean a better product. An improvement needs to earn its place through measured results.
What to ask before an enterprise rollout
- What does “ready” mean? Searchable text, extracted relationships, and a fully checked graph may become available at different times.
- Which facts must survive? Choose responsibilities, exceptions, ownership relationships, and policy distinctions users need.
- What happens when content changes? Cached work saves money only when document and context changes correctly invalidate it.
- What happens on a bad response? Retries consume time and tokens. Does the system repair a small failure or repeat the entire job?
- Were the tests representative? A few public documents cannot establish accuracy, security, throughput, or cost for a whole enterprise.
We finished this round with a faster ingestion approach: 34% less policy-batch time, plus a separate caching result showing 94% less repeat-rebuild time. Quality and load evaluations continue from that improved baseline. Some policy facts still need better extraction, and the slower optional experiment remains disabled.
AI can accelerate the work of proving value
An AI coding assistant helped inspect the implementation, build evaluation tools, run comparisons, and document failures as well as successes. That shortened the path from a question to evidence. It also made it easier to preserve a decision: a feature can exist in the code and still be the wrong default.
For a business sponsor, that is the encouraging part. Faster development can support more careful evaluation when the team uses the saved effort to test meaningful outcomes. The goal is a system whose speed, cost, and factual limits are understood well enough to make a responsible rollout decision.
Figures come from September 5–7, 2026 evaluations. Most variants had two observations; the engineering article explains the corpora, differing comparison dates, and an incomplete control run that was replaced. No production return-on-investment claim is implied.