Sarvam AI 讲解如何为企业 Agent 构建知识编织层

1. Home
2. /
3. Blog

How we built the knowledge fabric for enterprise agents

Research

Oct 21, 2026·10 min read

Making messy, fragmented data agent queryable

Enterprise AI systems often have access to the information they need to answer a query, but that information is scattered across documents and systems, without a consistent structure that connects the facts and makes them easy to query. Take, for example, an experienced relationship manager at a bank who can quickly recommend a suitable loan or credit card because they already have a mental model of how the products, eligibility rules and exceptions fit together. An agent given all the relevant product documents still has to work out those connections from the handful of passages retrieved for each question, and much of that work starts again with each new query.

So when we tackled this problem at Sarvam, we set out to build a knowledge fabric that reads an organisation's documents and data in whatever form they come in, works out how the information connects across sources and turns it into a structured layer that agents can navigate, query and cite. Because this work happens once and is reused across questions, agents become more accurate and cheaper to run at scale.

Over the last few months, we have refined the fabric with clients and have tested it across multiple public benchmarks. On Harvey's LAB benchmark, with GLM 5.3 as the agent model, answers met 84.2% of expert rubric criteria, up from 55.1% with agentic RAG, while average task cost fell from 0.28, outperforming Harvey's own harness reported at 79.1% for GPT-5.6 Sol and 71.7% for Opus 4.8. On Sierra's tau-knowledge banking benchmark, the fabric matched baseline accuracy with 64% fewer tokens, with GLM 5.2 running both setups.

In this post, we go deeper into the architecture behind the knowledge fabric, why we designed it the way we did and what we learned from building and testing it in practice.

Why RAG has been failing enterprises

Most enterprise AI systems today are built on traditional retrieval-augmented generation (RAG) where documents are split into small chunks and indexed for search. When a question arrives, the system retrieves the most relevant chunks and passes them to the model as context. Better embeddings, chunking strategies, and rerankers can improve retrieval quality, but traditional RAG fails because it treats documents as flat, isolated text snippets rather than understanding the underlying structure that connects them. This creates two fundamental problems:

1. Lost context: Individual document chunks often lack crucial parent information, such as the exact product, department, or legal condition they belong to. Because standard RAG doesn't map the underlying structure, these isolated snippets look clear on their own, leading the agent to make wrong assumptions and confidently give false answers.
2. Completeness: If you ask an agent a broad question, like listing every option that meets a specific rule, vector search only returns the top few results. Without a structural map of the entire dataset, the agent has to run search after search across multiple files, never knowing if it found all the answers or when it can safely stop.

Our approach

We wanted agents to work more like the relationship manager, starting each question with the context already in place and decided to design the knowledge fabric to ingest the documents once, and keep its learning in two layers.

The first layer is a knowledge tree, which organises any corpus so that an agent can navigate it, without needing a model of the domain. The second is a domain ontology, which models the entities in a domain and the relationships between them. In our financial products example, the tree would let an agent find and read each product’s terms and conditions, and the ontology would let it filter every card by its features such as forex markup, lounge access and annual fees in a single query.

Improving search with knowledge trees

Anyone who has ever used a coding agent has seen how well it can work through a large codebase with the use of filesystem primitives allowing it to access directories, read files, run search and retrieval and improve its understanding of the code. We bring these primitives to an organisation’s data with a knowledge tree.

Building a knowledge tree starts with parsing where we convert every file into markdown using Sarvam Vision 2.1 for scanned pages, complex layouts, tables and Indic scripts. Each long document then becomes a folder with a short index alongside it. For a 200-page annual report, the index is a single page listing the title, a summary and each section with its page range, allowing the agent to read the index first, pick the section it needs and open only those pages.

We serve the tree over MCP, so any agent can list folders, read indexes, search the corpus, open page ranges and inspect tables. Every citation points back to the passage, image or table row on the source page.

To measure the value the tree adds, we compared the tree with flat hybrid retrieval on four public benchmarks, using GLM 5.2 over the same parsed documents in both cases. One agent could only search passages, while the other could also read indexes, move through the document hierarchy and open tables.

Scroll

Scroll

The gains were largest when an answer needed evidence from several documents or from a table, suggesting that the tree helped the agent reach that material. However, it did not solve completeness. The agent still had to work out which documents described the same thing and whether it had found every relevant record, which is the problem the second layer addresses.

A domain ontology that agents can query like a database

Some questions are closer to database queries than searches: finding every card with zero forex markup and lounge access requires filtering across the bank’s cards, which an agent can only do reliably if each card’s features are already recorded in a form it can query. The second layer, the domain ontology, provides this structure. It defines the kinds of things a domain contains, the properties each one has and how they relate, and records what every document says in those terms.

We used Harvey's LAB firm-knowledge benchmark that places an agent inside a simulated law firm with 9,288 files covering 266 matters for 46 clients, and gives it 250 requests of the kind a partner might make, to test the knowledge fabric.

One request asks: "Pull all our Capital Markets offerings that were done on a firm-commitment basis, along with the executed underwriting agreements."

Answering it means finding every capital-markets offering, checking how each one was underwritten and working out which documents are executed under underwriting agreements. Those facts are scattered across transaction documents, agreements and matters, so search can find examples but does not guarantee a complete list.

For LAB we defined five entity types: clients, matters, transactions, documents and agreements, where a transaction carries properties such as its kind, status, value and underwriting basis recorded in a document, and relationships connect different entities.

With the ontology in place, the agent answered the capital-markets request in three steps:

1. Listed all 22 capital-markets offerings.
2. Filtered for firm-commitment offerings and joined them to their executed agreements, leaving 14 that qualified.
3. Opened the supporting passages and cited each result.

Results on Harvey LAB

We ran this benchmark in three configurations: agentic RAG over a flat chunk index, the knowledge tree, and the ontology with the knowledge tree still available.

Scroll

Scroll

The knowledge tree improved the criteria pass rate over agentic RAG but that exploration was expensive and used more than twice as many tokens. The ontology improved the criteria pass rate further while bringing token use below the RAG baseline, because filtering and joining happened in the database instead of through repeated reading and reasoning. The ontology-based setup also returned an answer for every task and required less than a quarter of the tool calls used by the tree alone, with the performance gap widening on larger tasks.

Results on tau-knowledge

We tested the knowledge fabric on Sierra's tau-knowledge benchmark which puts an agent on the support desk of a simulated bank, with 698 documents covering product terms, fees, eligibility rules and internal procedures. Each task needs information from 18.6 documents on average, and the 97 tasks are scored all or nothing, so a single missed fee or eligibility condition fails the whole task.

Across the full benchmark, we integrated the knowledge fabric into Sierra's harness and compared it with Sierra's default retrieval setup, which gives the agent BM25, embedding search and a shell. We ran both in our own environment with GLM 5.2 as the agent model. The agent using the knowledge fabric completed 39 tasks, compared with 38 for the baseline, while using 64% fewer tokens.

Knowledge Fabric in the real world

The knowledge tree is already in production in Sarvam cowork, where anyone can create a knowledge base, upload files and attach it to their agents, and the tree is built in the background with no setup. The ontology depends on the domain, so we build it with enterprise clients, one domain at a time.

• Each deployment starts with discovering which tasks people need help with and gathering the documents and systems behind them
• Agents then draft the domain model, and the client's domain experts review and correct it
• Documents are compiled into the fabric, while live databases stay in their source systems and continue to enforce access controls

The ontology usually lives in a relational database, but when a domain's questions keep hopping across many relationships, we move it to a graph database, which handles those queries better. We can deploy the fabric inside a customer’s own environment, including small air-gapped setups that use smaller models. As new document types arrive, we update the ontology incrementally and rerun evaluations before each update goes live.

Final thoughts

The biggest lesson from this work is how much an agent's results depend on the substrate it works over. The knowledge fabric gives the agent a more intelligent substrate, where that structure is already in place, much as the relationship manager we started with already knows how the bank's products fit together. Building that substrate once, ahead of time, makes agents more accurate and cheaper to run.

We are excited about what this makes possible: agents that start every task already understanding how an organisation's knowledge fits together and are continuously working to make compilation more accurate and efficient. We are continuing to improve the accuracy and efficiency of compilation by refining the harness that builds the fabric and testing different models at each step.

The next step is memory. The fabric should become more useful as more agents share it, and what one agent learns, whether a correction, a decision or a user's preference, should be available to the rest. We are designing a persistent, shared memory for agents, built on similar primitives. We will be sharing more of what we learn along the way.

References

• Harvey, LAB: Law Firm Knowledge. The firm-knowledge tasks behind our ontology results: a simulated law firm with 9,288 files and 250 partner-style requests, graded against expert-written rubrics. The corpus, tasks and grader are on GitHub.
• Sierra, tau-knowledge. A customer-support benchmark over a simulated bank's product terms, fees and procedures, where each task is scored all or nothing.
• BrowseComp-Plus. Deep-research questions over a fixed corpus of about 100,000 documents, so retrieval setups can be compared on the same data.
• BRIGHT-Pro. Retrieval questions where finding the right documents takes reasoning beyond keyword or semantic overlap.
• FinanceBench. Questions over public company filings with verified answers.
• OfficeQA Pro. Questions over US Treasury bulletins, many of which depend on values in tables.
• Zhang, Khattab and Kraska, Recursive Language Models. A model that calls itself recursively over a long context held in a code environment, so it can read far more than fits in one prompt.
• Moonshot AI, Kimi K2.5. A model trained to split a task across up to 100 parallel sub-agents, with strong results on BrowseComp.