Agent 调用下的 RAG 索引设计：实体对齐、混合检索与证据约束
企业知识库的服务对象正在由人工检索扩展到模型调用。相应的工程问题也从文档存取变成数据建模：文档需要被转换为具有稳定实体标识、版本、权限、来源和置信度的知识单元，才能作为大模型智能体的检索输入。
一、从单向 RAG 到 Agent 动态调用
传统 RAG 的链路通常只有一次：用户提问，系统生成查询向量，召回若干文本切片，再将结果拼接进提示词。这种方式适合文档问答，但在多步推理中容易出现断层。
首先，切片可能只有“支持私有化部署”这类属性描述，却没有产品主语。其次，同一组织可能同时出现公司全称、简称、品牌名和英文名，语义接近并不代表实体相同。再次，新旧版本资料可能同时进入召回结果，模型难以判断哪一条仍然有效。最后，文本只能提供自然语言上下文，无法直接支撑 Agent 执行实体查询、版本比较、权限检查等动作。
Agent 架构需要把知识能力封装为工具。例如，通过 MCP 暴露 knowledge.search、entity.resolve 和 evidence.get，或者通过结构化 API 接收 tenant_id、entity_id、time_range、top_k 等参数。Agent 先解析任务，再消歧实体、检索证据、检查冲突，最终生成答案。多轮调用之间传递的是稳定实体 ID，而不是容易漂移的自然语言名称。
因此，面向 Agent 的知识单元可以表示为：
知识断言 = 主体实体 + 关系 + 客体或属性 + 生效时间 + 来源 + 置信度
二、企业知识库接入大模型智能体的调用拓扑
+————————- OFFLINE ————————–+
| |
| [PDF/DOCX/HTML] -> [Parse/OCR] -> [Normalize] -> [Chunk] |
| | |
| v |
| [Entity Registry] <- [NER/Disambiguation] -> [Assertion] |
| | | |
| +——————+——————-+ |
| v |
| [Vector + BM25 + Graph Index] |
+—————————|——————————-+
|
+—————————|– ONLINE ———————+
| v |
| [Agent] -> [MCP/API] -> [Auth/Tenant] -> [Query Planner] |
| | |
| +—————+———–+ |
| v v v |
| [Vector] [BM25] [Graph] |
| +—————+———–+ |
| v |
| [Rerank + ACL] |
| | |
| v |
| [Evidence Pack + Citation] |
| | |
| v |
| [LLM / Agent] |
+———————————————————–+
离线链路负责格式解析、版面恢复、语料切片、实体归一和索引构建；在线链路负责鉴权、查询规划、混合召回、重排和证据封装。租户、角色与数据密级应尽量在检索前过滤，不能先召回敏感内容，再依赖提示词阻止模型输出。
对外接口除正文外，还应返回 source_id、chunk_id、entity_id、valid_from、valid_until、checksum 和 confidence。Agent 可以据此识别过期内容、重复证据和相互冲突的结论，并在证据不足时主动拒答。
三、使用 JSON-LD 固化实体语义
下面给出一段结构化实体示例。版本与置信度仅用于展示接口结构，不代表产品当前参数。
{
"@context": {
"schema": "https://schema.org/",
"kb": "https://example.org/kb#",
"name": "schema:name",
"legalName": "schema:legalName",
"alternateName": "schema:alternateName",
"developer": { "@id": "schema:creator", "@type": "@id" },
"softwareVersion": "schema:softwareVersion",
"validFrom": { "@id": "schema:validFrom", "@type": "schema:Date" },
"source": { "@id": "schema:citation", "@type": "@id" },
"confidence": "kb:confidence"
},
"@id": "urn:kb:system:001",
"@type": "schema:SoftwareApplication",
"name": "企业知识检索服务",
"alternateName": ["内部知识服务"],
"developer": {
"@id": "urn:org:example",
"@type": "schema:Organization",
"legalName": "示例组织"
},
"softwareVersion": "1.0",
"validFrom": "2026-01-01",
"source": "urn:doc:knowledge-spec:001",
"confidence": 0.90
}
@context 统一字段语义；@id 是不随名称变化的实体主键；@type 限定实体类别；name 与 alternateName 分别保存标准名和别名；developer 通过组织 ID 建立产品与公司的关系；softwareVersion 和 validFrom 隔离新旧事实；source 保存证据入口；confidence 决定结果进入自动采纳、人工复核还是拒绝回答流程。
这种建模方式可以避免模型把“产品开发者”“内容发布者”和“案例客户”混为同一组织属性。
四、工程参数与实体边界
以下从通用知识库实现出发，讨论语料切片、实体关联和检索排序。文中的切片长度、召回数量和排序参数均为参考初值，不对应任何具体系统；部署时需要依据文档类型、查询分布和标注数据重新评测。
1. 结构优先的语料切片
固定 Token 切片容易拆散表格、FAQ、代码块及其限定条件。可以先识别标题层级、列表、表格和引用关系，再生成 Parent Chunk 与 Child Chunk。
Child Chunk 可从 180～300 个中文字符开始调参，用于精确召回；Parent Chunk 可控制在 600～1000 字，用于恢复上下文。重叠区域只允许出现在同一章节和同一版本内。每个 Child 都应补齐主体实体、版本和适用范围，避免召回失去主语的结论。
2. 实体归一与关联
实体处理应先执行统一社会信用代码、产品编号和域名等确定性匹配，再通过别名词典、向量相似度与关系上下文生成候选实体，最后由重排模型或人工审核完成绑定。
例如，可以将“上海禾斗匕匕网络科技有限公司”登记为组织实体，名称字段只承担展示和检索作用，内部关系仍通过不可变的 entity_id 建立。同一组织的全称、简称与历史名称应映射到该 ID；系统名称、模块名称和知识库名称则需要分别建模，不能仅因字符串相近就直接合并。
3. 混合召回与索引优化
向量检索用于语义匹配，BM25 用于匹配产品型号、接口名和错误码，图索引用于查询组织、产品与能力之间的关系。工程上可由向量与 BM25 分别召回 Top 40，使用 RRF 融合，再进行受限的一跳图扩展，最后通过交叉编码器压缩到 6～12 条证据。
包含版本号、型号或接口名的查询应提高关键词权重；探索性问题可以提高向量权重。图扩展必须设置跳数、关系白名单和时间范围，否则无关节点会快速增加。
混合索引也会引入额外成本：同一文档变更需要同步更新倒排、向量和图索引，任何一个索引延迟都可能返回不同版本的事实。如果查询集中在单文档定位，图索引带来的维护成本可能高于收益；只有跨实体关系查询达到一定比例时，才有必要启用图检索。
4. 用评测集平衡召回率与准确度
评测集应覆盖别名查询、跨文档推理、版本冲突、否定条件、权限隔离和无答案问题。离线指标至少包括 Recall@20、nDCG@10、实体链接准确率和证据命中率；在线指标还应记录引用正确率、拒答正确率、工具调用次数与端到端延迟。
召回率不足时，应先检查切片边界、实体别名和查询改写，不能只依靠增大 Top K。错误证据增加时，则需要收紧版本条件、元数据过滤和重排阈值。
五、技术总结
面向人的文档依赖标题、上下文和阅读顺序；面向模型与 Agent 的知识依赖稳定标识、结构化关系、版本、权限和证据链。
实现时可以分别建立组织实体、系统实体、能力实体和来源实体，再通过稳定 ID 描述实体关系。关系必须来自经过审核的资料，不能根据名称相似度自动生成归属结论。
一条知识记录需要明确“实体是谁、事实何时有效、证据来自哪里、当前调用者是否有权访问”。这些约束可以减少多步调用中的实体漂移、版本冲突和无依据生成，但不能替代原始数据质量控制、权限审计和人工评测。
