1. 引言
在 Agent 开发中，知识库的构建与加载是决定智能体回答质量的关键环节。单一知识源往往难以覆盖复杂场景：知识图谱擅长表达结构化关系，向量库擅长语义相似度检索，Wiki 库则擅长提供规范化的文档知识。这三类知识库本质上构成了多模态知识融合的底座——它们分别以「关系结构」「语义向量」「规范文本」三种模态承载知识，Agent 需要将它们统一加载、协同调度，才能获得更全面的认知能力。本文将从三类知识库的定位、加载方式、结合策略与工程实践四个层面展开，并结合中医辨证论治场景给出可落地的多模态知识融合方案，帮助你在 Agent 开发中构建更强大的知识底座。## 2. 三类知识库的定位与特点
在深入实践之前，先明确三类知识库各自的定位与适用场景。
2.1 知识图谱（Knowledge Graph）
知识图谱以「实体—关系—实体」三元组为核心，将知识组织成可遍历、可推理的图结构。它擅长表达结构化、强关联的知识，例如人物关系、产品依赖、组织架构、证候与脏腑的从属关系等。图谱的价值在于可解释性——每一次查询都能给出明确的推理路径，这是其他两类知识库难以替代的。
- 优点：查询精确、可推理、支持多跳关系查询。
- 缺点：构建成本高，覆盖范围有限，难以表达非结构化文本。
2.2 向量库（Vector Database）
向量库将文本切块后通过 Embedding 模型转为高维向量，支持语义相似度检索。它不依赖关键词精确匹配，而是通过向量距离度量语义相近程度，因此特别适合处理大规模非结构化文档、口语化表达与开放性问题。向量库的检索是模糊的、启发式的，能覆盖图谱难以表达的语义空间，但代价是结果可能存在噪声、缺乏可解释性。
- 优点：检索灵活、支持模糊语义匹配、扩展性好。
- 缺点：缺乏精确关系表达，检索结果可能存在噪声。
2.3 Wiki 库（Wiki / 文档库）
Wiki 库以结构化文档（如 Confluence、Notion、内部 Wiki）为基础，提供经过整理、审核与版本管理的规范知识。它承载的是组织沉淀下来的权威结论——制度、手册、药典、诊疗规范等。Wiki 库的价值在于可信与可追溯，回答可以明确引用来源，降低模型幻觉风险；但检索依赖关键词或语义匹配，实时性较弱，且需要持续的人工维护。
- 优点：内容权威、结构清晰、便于人工维护。
- 缺点：检索依赖关键词或语义匹配，实时性较弱。
下表从数据模型、查询方式、适用场景、构建成本、局限性五个维度对三类知识库进行横向对比：
| 维度 | 知识图谱 | 向量库 | Wiki 库 |
|---|---|---|---|
| 数据模型 | 实体—关系—实体三元组 | 高维语义向量 | 结构化文档 / 页面 |
| 查询方式 | Cypher / Gremlin 精确查询 | 语义相似度检索 | 关键词 / 语义匹配 |
| 适用场景 | 强关联、可推理的结构化知识 | 大规模非结构化语义检索 | 规范化、权威的文档知识 |
| 构建成本 | 高（需建模、抽取、对齐） | 中（需切块、Embedding、索引） | 中（需整理、审核、维护） |
| 局限性 | 覆盖有限，难以表达非结构化文本 | 缺乏精确关系，结果有噪声 | 实时性较弱，依赖人工维护 |
典型使用场景小结：知识图谱适合关系密集型场景，如人物关系、产品依赖、组织架构等需要多跳推理的问题，其优势在于精确与可解释；向量库适合语义模糊、开放性强的场景，如大规模文档的相似内容召回、FAQ 匹配、口语化主诉的语义匹配，其优势在于灵活与覆盖面广；Wiki 库适合规范权威的场景，如内部制度、操作手册、药典、产品文档等需要引用可信来源的问题，其优势在于可信与可追溯。实际 Agent 开发中，三者并非互斥，而是分别覆盖「精确关系—模糊语义—规范文本」三段知识谱系，需要按问题类型协同调度，才能获得既准确又可解释、既全面又可信的回答。
3. 三类知识库的加载方式
3.1 知识图谱的加载
知识图谱通常以图数据库（如 Neo4j、JanusGraph）存储，加载方式包括：
- 通过 Cypher / Gremlin 查询语言直接访问；
- 使用图谱 API 封装查询逻辑；
- 将图谱导出为 JSON / RDF 格式后由 Agent 解析。
fromneo4jimportGraphDatabase driver=GraphDatabase.driver("bolt://localhost:7687",auth=("neo4j","password"))defquery_graph(query):withdriver.session()assession:result=session.run(query)return[record.data()forrecordinresult]# 示例：查询某实体的关联关系relations=query_graph("MATCH (a:Entity)-[r]->(b:Entity) WHERE a.name = 'LangChain' RETURN a, r, b")3.2 向量库的加载
向量库的加载流程通常包括：文本切块 → Embedding 向量化 → 写入向量数据库。
fromlangchain_community.vectorstoresimportChromafromlangchain_openaiimportOpenAIEmbeddings# 文本切块fromlangchain_text_splittersimportRecursiveCharacterTextSplitter text_splitter=RecursiveCharacterTextSplitter(chunk_size=500,chunk_overlap=50)chunks=text_splitter.split_text(document_text)# 向量化并写入embeddings=OpenAIEmbeddings()vectorstore=Chroma.from_texts(chunks,embeddings,persist_directory="./chroma_db")3.3 Wiki 库的加载
Wiki 库的加载通常通过 API 或爬虫获取文档内容，再按需进行解析与索引。
importrequestsfrombs4importBeautifulSoupdefload_wiki_page(url):resp=requests.get(url)soup=BeautifulSoup(resp.text,"html.parser")returnsoup.get_text()# 示例：加载 Confluence 页面content=load_wiki_page("https://wiki.example.com/pages/viewpage.action?pageId=12345")4. 三类知识库的结合策略
单一知识库往往无法满足复杂 Agent 场景，需要将三类知识库有机结合。常见的结合模式如下：
4.1 分层路由模式
先通过意图识别决定走哪条知识路径：
- 结构化查询类问题 → 知识图谱；
- 语义模糊、开放性问题 → 向量库；
- 规范文档类问题 → Wiki 库。
defroute_query(query):ifis_structured_query(query):return"graph"elifis_semantic_query(query):return"vector"else:return"wiki"4.2 融合检索模式
将三类知识库的检索结果合并，经过重排序后统一送入 LLM 生成答案。
defhybrid_retrieve(query):graph_results=query_graph(f"MATCH (n) WHERE n.name CONTAINS '{query}' RETURN n")vector_results=vectorstore.similarity_search(query,k=5)wiki_results=wiki_search(query)returnmerge_and_rerank(graph_results,vector_results,wiki_results)4.3 图谱增强向量检索
利用知识图谱中的实体关系对向量检索结果进行过滤或扩展，提升召回精度。
defgraph_enhanced_search(query):entities=extract_entities(query)related=query_graph(f"MATCH (n)-[r]->(m) WHERE n.name IN{entities}RETURN m.name")expanded_query=query+" "+" ".join(related)returnvectorstore.similarity_search(expanded_query,k=5)下表从适用场景、查询延迟、召回精度、实现复杂度、典型应用五个维度对三种结合模式进行横向对比：
| 维度 | 分层路由模式 | 融合检索模式 | 图谱增强向量检索 |
|---|---|---|---|
| 适用场景 | 问题类型边界清晰、可明确归类 | 问题复杂、需要多源知识互补 | 以语义检索为主、需图谱关系提升精度 |
| 查询延迟 | 低（只走一条路径） | 高（需并行检索三类知识库并重排） | 中（需先图谱查询再向量检索） |
| 召回精度 | 中（依赖意图识别准确率） | 高（多源融合、互为补充） | 较高（图谱关系过滤/扩展噪声） |
| 实现复杂度 | 低（仅需路由逻辑） | 高（需融合、重排、权重调优） | 中（需实体抽取与图谱联动） |
| 典型应用 | 客服分流、FAQ 分类问答 | 复杂业务咨询、跨域综合问答 | 医疗辅助诊断、专业领域语义检索 |
如何选择结合模式：当问题类型边界清晰、对响应速度要求高时，优先选择分层路由模式，用意图识别快速分流到单一知识源，实现低延迟；当问题复杂、单一知识源难以覆盖、需要多源知识互补时，选择融合检索模式，通过并行检索与重排序获得更全面的答案，但需接受更高的延迟与实现成本；当业务以语义检索为主、又希望借助图谱关系提升精度时，选择图谱增强向量检索，用实体关系过滤或扩展向量召回结果，兼顾召回率与准确率。实际工程中三种模式并非互斥，可结合业务场景分层组合使用——例如先路由分流，再对复杂问题走融合检索，对专业领域问题叠加图谱增强，从而在延迟、精度与成本之间取得平衡。
5. 工程实践：构建多知识库 Agent
下面以一个实际案例演示如何将三类知识库整合进 Agent 开发流程。
5.1 系统架构
5.2 核心实现
classMultiKnowledgeAgent:def__init__(self,graph_driver,vectorstore,wiki_index):self.graph=graph_driver self.vectorstore=vectorstore self.wiki=wiki_indexdefretrieve(self,query):# 并行检索三类知识库graph_res=self._query_graph(query)vector_res=self.vectorstore.similarity_search(query,k=5)wiki_res=self._search_wiki(query)# 融合与重排序combined=self._merge_results(graph_res,vector_res,wiki_res)returncombineddefanswer(self,query):context=self.retrieve(query)prompt=f"基于以下知识回答用户问题：\n\n{context}\n\n问题：{query}"returnllm.invoke(prompt)5.3 实践要点
- 缓存策略：对高频查询结果做缓存，降低知识库访问压力；
- 异步加载：三类知识库的加载可并行执行，减少响应延迟；
- 质量评估：定期评估检索准确率，调整切块大小与重排序权重；
- 降级方案：某类知识库不可用时，自动降级到其他知识源。
5.4 中医实践场景：辨证论治 Agent
下面以「中医辨证论治」为例，演示三类知识库在真实业务中的分工与协同。中医知识天然具备多模态特征：证候关系适合图谱表达，方剂与医案适合向量检索，药典与诊疗规范适合 Wiki 承载。
什么时候检索什么、为什么
| 用户问题类型 | 检索哪类知识库 | 为什么 |
|---|---|---|
| 「肝郁气滞会导致哪些症状？」 | 知识图谱 | 证候—症状—脏腑之间存在强关联，需要多跳推理，图谱能精确返回「肝郁 → 胁痛、情志抑郁、脉弦」等关系链 |
| 「我最近失眠、口苦、舌红，可能是什么证？」 | 向量库 | 症状描述模糊、口语化，需要语义相似度匹配历史医案与证候描述，图谱难以覆盖这种非结构化表达 |
| 「某味药材的性味归经、用法用量、禁忌是什么？」 | Wiki 库 | 药典、诊疗规范是权威审核过的文档，需要引用可信来源，避免模型幻觉 |
| 「这个方剂与患者体质是否匹配？」 | 图谱 + 向量库 | 先由图谱推理患者体质与方剂主治的证候关系，再由向量库召回相似医案佐证，双重校验 |
路由与融合设计
deftcm_route(query):# 1. 先做实体识别：判断问题是否涉及证候/脏腑/药材等结构化实体entities=extract_tcm_entities(query)# 如 {"证候": "肝郁气滞", "症状": ["胁痛", "失眠"]}# 2. 结构化关系类问题 → 知识图谱ifentities.get("证候")and"症状"inquery:returnquery_graph("MATCH (z:证候)-[:表现为]->(s:症状) ""WHERE z.name = $name RETURN s.name",{"name":entities["证候"]})# 3. 模糊症状描述 → 向量库（语义匹配医案）ifentities.get("症状")andnotentities.get("证候"):returnvectorstore.similarity_search(query,k=5)# 4. 药典/规范类问题 → Wiki 库ifentities.get("药材")or"禁忌"inqueryor"用量"inquery:returnwiki_search(query)# 5. 复杂辨证 → 图谱推理 + 向量召回融合returnhybrid_tcm_retrieve(query)为什么这样设计
- 图谱管「关系」：中医辨证的核心是证候与症状、脏腑、方剂之间的因果与从属关系，这类问题用图谱查询最精确、可解释，能给出「为什么是这个证」的推理路径；
- 向量管「语义」：患者主诉往往口语化、不完整（如「睡不好、老上火」），图谱无法覆盖，向量库能通过语义相似度召回最接近的医案与证候描述；
- Wiki 管「规范」：药材性味、剂量、禁忌属于必须严格引用的权威知识，交给 Wiki 库可追溯来源，降低用药风险；
- 融合兜底：复杂辨证时单一知识源都不够，需要图谱给出关系骨架、向量库补充相似案例、Wiki 提供规范佐证，三者融合后再交给 LLM 生成辨证结论与建议。
实践要点补充
- 证候图谱需持续维护：中医证候关系复杂且存在流派差异，图谱构建需结合权威教材与临床专家审核；
- 医案向量化注意隐私：患者医案涉及隐私，向量化前需脱敏，检索结果仅返回证候特征而非原始病历；
- 用药安全优先：涉及剂量、禁忌、配伍时强制走 Wiki 库并标注来源，图谱与向量结果仅作参考，最终需人工复核。
6. 总结
在 Agent 开发中，知识图谱、向量库与 Wiki 库各有优势，合理组合能够显著提升智能体的知识覆盖与回答质量。从多模态知识融合的视角看，这三类知识库分别承载了关系模态、语义模态与文本模态的知识：图谱管关系、向量管语义、Wiki 管规范。Agent 通过分层路由或融合检索将三者有机结合，本质上是在做跨模态的知识对齐与协同推理。实践中建议从小规模场景起步，逐步优化检索策略与融合权重，最终构建出稳定可靠的多模态知识融合 Agent 系统。
7. 参考资料
本文在撰写过程中参考了以下关键资源，供读者进一步查阅与深入学习：
- Neo4j 官方文档（https://neo4j.com/docs/）：系统介绍了图数据库的数据模型、Cypher 查询语言与图谱构建方法，是本文「3.1 知识图谱的加载」与「4.3 图谱增强向量检索」中图谱查询与关系推理实现的核心依据。
- Chroma 向量数据库文档（https://docs.trychroma.com/）：详细说明了向量库的安装、文本切块、Embedding 与相似度检索流程，对应本文「3.2 向量库的加载」中的向量化与写入实现。
- LangChain 知识库集成指南（https://python.langchain.com/docs/integrations/）：覆盖了向量存储、文本切分器、图数据库连接等知识库组件的集成方式，是本文「3. 三类知识库的加载方式」与「5.2 核心实现」中 MultiKnowledgeAgent 代码示例的技术参考。
- 《中医诊断学》（朱文锋主编，人民卫生出版社）：系统阐述了辨证论治的证候体系与脏腑、症状之间的对应关系，是本文「5.4 中医实践场景」中证候图谱构建与「什么时候检索什么、为什么」表格的权威依据。
- 《方剂学》（邓中甲主编，中国中医药出版社）：提供了方剂主治证候、配伍规律与用药禁忌的规范知识，对应本文中医场景中「方剂与患者体质匹配」的图谱推理与 Wiki 库规范引用部分。
- 中医医案相关研究论文（如《基于知识图谱的中医辨证论治辅助决策研究》等）：展示了知识图谱与向量检索在中医临床辅助决策中的落地实践，为本文「图谱增强向量检索」在医疗辅助诊断场景的应用提供了参考。
