2026年10月21日·10分钟阅读
让杂乱、碎片化的数据可供智能体查询
企业AI系统通常能够获取回答查询所需的信息，但这些信息分散在各类文档和系统中，缺乏一种一致的结构来连接事实并使其易于查询。以银行为例，一位经验丰富的客户关系经理能够迅速推荐合适的贷款或信用卡，因为他们已经在头脑中建立了产品、资格规则和例外情况如何相互关联的模型。而一个智能体即使获得了所有相关的产品文档，仍然必须从每个问题检索到的少量段落中推断出这些关联，而且每提出一个新查询，其中大部分工作都要重新开始。
因此，当我们在Sarvam着手解决这个问题时，我们开始构建一个 知识织物 ，它能够读取组织以各种形式呈现的文档和数据，梳理出信息在不同来源之间如何相互关联，并将其转化为一个结构化层，供智能体导航、查询和引用。由于这项工作只需完成一次，并可在不同问题之间复用，智能体因此变得更加准确，在大规模运行时的成本也更低。
过去几个月里，我们与客户一起对知识织物进行了改进，并在多个公开基准上进行了测试。在Harvey的 LAB基准以GLM 5.3作为智能体模型时，答案满足了84.2%的专家评分标准，高于使用智能体式RAG时的55.1%，同时平均任务成本从0.64美元降至0.28美元，优于Harvey自家测试框架所报告的GPT-5.6 Sol的79.1%和Opus 4.8的71.7%。在Sierra的 tau-knowledge 银行基准上，该知识织物在token用量减少64%的情况下达到了与基线相当的准确率，两套设置均运行GLM 5.2。
在本文中，我们将深入探讨知识织物背后的架构、我们为何如此设计，以及我们在实践中构建和测试它时学到了什么。
为什么RAG在企业中一直失败
如今，大多数企业AI系统都建立在传统的检索增强生成（RAG）之上，即把文档切分成小块并建立索引以供搜索。当问题到来时，系统检索出最相关的片段，并将其作为上下文传给模型。更好的嵌入、分块策略和重排序器可以提升检索质量，但传统RAG仍然会失败，因为它把文档当作扁平、孤立的文本片段来处理，而不是理解连接这些片段的底层结构。这带来了两个根本性问题：
- 上下文丢失： 单个文档块往往缺少关键的父级信息，例如它所属的确切产品、部门或法律条件。由于标准RAG不会映射底层结构，这些孤立的片段单独看起来清晰明了，导致智能体做出错误假设，并自信地给出错误答案。
- 完整性： 如果你向智能体提出一个宽泛的问题，比如列出满足特定规则的 每一个 选项，向量搜索只会返回排名最靠前的几个结果。如果没有整个数据集的结构化映射，智能体就不得不在多个文件中一次又一次地执行搜索，始终无法知道是否找到了所有答案，也不知道何时可以安全地停止。
我们的方法
我们希望智能体更像客户关系经理那样工作，每个问题开始时上下文已经就位，因此我们决定将知识织物设计为一次性摄取文档，并把其学习成果保留在两个层次中。
第一层是知识树，它对任意语料进行组织，使智能体能够在其间导航，而无需领域模型。第二层是领域本体，它对领域中的实体及其相互关系进行建模。在我们的金融产品示例中，知识树让智能体能够找到并阅读每个产品的条款与条件，而本体则让它能在单次查询中按外汇加价、贵宾厅使用权和年费等特征筛选每一张卡。
用知识树改进搜索
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.
| Benchmark | Hybrid retrieval | Knowledge-tree navigation |
|---|---|---|
| BrowseComp-Plus, 830 deep-research questions | 75.5% | 91.3% |
| BRIGHT-Pro, 739 reasoning-heavy questions | 84.3% | 90.4% |
| FinanceBench, 150 questions over company filings | 82.1% | 88.7% |
| OfficeQA Pro, 133 questions over Treasury bulletins | 33.8% | 51.6% |
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:
- Listed all 22 capital-markets offerings.
- Filtered for firm-commitment offerings and joined them to their executed agreements, leaving 14 that qualified.
- 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.
| Agentic RAG | Knowledge tree | Ontology | |
|---|---|---|---|
| Rubric criteria met | 55.1% | 74.4% | 84.2% |
| Tasks fully solved | 72 | 92 | 109 |
| Tasks left unanswered | 9 | 7 | 0 |
| Tool calls per task | 36.5 | 59.2 | 14.2 |
| Tokens per task | 1.80M | 3.79M | 0.86M |
| Time per task | 30.0 min | 30.8 min | 8.6 min |
| Cost per task | $0.64 | $1.18 | $0.28 |
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.
Curious what else we're building? Explore our APIs and start creating.
Curious what else we're building?
Explore our APIs and start creating.
Get Started