LightRAG构建中药知识图谱：六种检索模式效能对比与调优实践

1. 项目缘起与整体设计思路

中药知识体系有个很麻烦的特点：概念之间关系极其密集，而且很多关系是“多对多”的。比如一味黄芪，它同时涉及补气、固表、利水、托毒等多个功效维度，每个功效又关联到不同的方剂、证候、药材配伍。传统的关键词检索在这种网状结构里基本是“查一个漏一片”，而纯向量检索又容易在专业术语上翻车——你搜“四君子汤”，它可能给你返回一堆“四君子”相关的文学内容。

我这次选LightRAG来搭中药知识图谱，核心原因就一个：它把图结构检索和向量检索揉在了一起，而且轻量。相比微软的 GraphRAG，LightRAG 不需要对全量文档做社区摘要，索引成本低了一个数量级，增量更新也友好得多。对于中药这种需要频繁追加新药材、新方剂的场景，这一点非常关键。

整体设计思路分三层：

• 数据层：把中药数据整理成“实体-关系-实体”的三元组格式，同时保留原始文本块用于向量检索。
• 索引层：LightRAG 同时构建图索引（实体关系网络）和向量索引（文本块嵌入），两者通过实体名称做桥接。
• 检索层：LightRAG 提供六种检索模式，从纯本地检索到混合全局检索，覆盖不同粒度的查询需求。

为什么不用 Neo4j 直接手搓？我试过。Neo4j 构建知识图谱确实直观，Cypher 查询也灵活，但问题在于：你得自己写实体抽取、关系抽取、向量化、检索排序的全套流水线。LightRAG 把这些都封装好了，你只需要喂文本，它自动抽实体、建图、做嵌入。对于我这种想快速验证检索效果、而不是花两周写 ETL 的人来说，LightRAG 的性价比高太多。

当然，Neo4j 也不是没用。我最终的方案是：LightRAG 做检索层，Neo4j 做可视化层。LightRAG 抽出来的实体关系导出成 CSV，再导入 Neo4j 做图谱展示和人工校验。这样既享受了 LightRAG 的自动化，又保留了 Neo4j 的直观性。

2. 中药数据准备与知识图谱构建实操

2.1 数据来源与清洗策略

中药数据我主要从三个渠道获取：《中药学》教材电子版、国家药典公开数据、经典方剂数据库。原始数据大概 2000 多味药材、800 多个方剂，但直接喂给 LightRAG 效果很差，因为原始文本里大量重复、格式混乱、还有不少 OCR 错误。

清洗分四步走：

1. 去重与合并：同一味药在不同来源里的描述合并成一条，保留最完整的版本。
2. 分段处理：每味药按“性味归经”“功效主治”“用法用量”“配伍禁忌”切成独立文本块，每块 200-500 字。为什么是这个长度？LightRAG 的实体抽取对文本块长度敏感，太短抽不出关系，太长会引入噪声。我实测下来 300 字左右最稳。
3. 术语标准化：把“炙黄芪”“蜜黄芪”统一成“黄芪（炙）”，把“川穹”纠正为“川芎”。这一步不做，后面实体对齐会疯掉。
4. 敏感内容过滤：涉及野生动物保护品种的药材描述直接剔除，只保留人工种植替代品的信息。

清洗完的数据大概 1200 味药、600 个方剂，文本块总数约 8000 个。这个规模用 LightRAG 跑，单机 16G 内存完全够用。

2.2 LightRAG 环境搭建与配置

安装很简单：

pip install lightrag-hku

但有几个坑我踩过，提前说：

• Python 版本必须 3.10 以上，3.9 会在异步处理时出问题。
• 嵌入模型别用默认的。LightRAG 默认调 OpenAI 的 embedding，但中药术语里有很多生僻字和多音字，OpenAI 的 tokenizer 对中文医学文本并不友好。我换成了BGE-M3，本地跑，中文医学语料上的召回率明显更高。
• LLM 用 Qwen2.5-14B-Instruct，量化到 4bit，单张 3090 就能跑。为什么不用更大的？实体抽取任务对模型规模不敏感，14B 足够，再大只是浪费显存。

配置代码大概长这样：

from lightrag import LightRAG, QueryParam from lightrag.llm import openai_complete_if_cache from lightrag.utils import EmbeddingFunc rag = LightRAG( working_dir="./tcm_kg", llm_model_func=openai_complete_if_cache, llm_model_name="qwen2.5-14b-instruct", llm_model_max_token_size=4096, embedding_func=EmbeddingFunc( embedding_dim=1024, max_token_size=8192, func=lambda texts: bge_m3_embed(texts) ), chunk_token_size=300, chunk_overlap_token_size=50, )

chunk_token_size设 300 是我反复调出来的。设 500 的时候，实体抽取会把“黄芪”和“甘草”的关系误判成“黄芪包含甘草”；设 200 又太碎，一个完整的方剂组成被切成三段，关系抽不全。

2.3 知识图谱构建过程与参数调优

数据灌进去之后，LightRAG 会自动做三件事：实体抽取、关系抽取、图索引构建。这个过程是增量的，你可以随时追加新数据。

with open("./tcm_cleaned.txt", "r", encoding="utf-8") as f: rag.insert(f.read())

但直接 insert 有个问题：实体消歧。比如“人参”和“红参”，LightRAG 会当成两个独立实体，但实际上红参是人参的炮制品。我的处理办法是在文本里显式写清楚：“红参，为人参的蒸制加工品”。这样 LLM 在抽取时就会自动建立“红参-炮制自-人参”的关系。

另一个关键参数是entity_extract_max_gleaning，默认是 1。我调到 2，让 LLM 对每个文本块做两轮实体抽取。第一轮抽显式关系，第二轮抽隐式关系。实测下来，中药方剂里的“君臣佐使”配伍关系，单轮抽取经常漏掉，两轮能补回来不少。

构建完成后，working_dir下会生成几个关键文件：

我一般会把graph_chunk_entity_relation.graphml导出成 CSV，再导入 Neo4j 做可视化校验。Neo4j 的 Cypher 查询用来检查“有没有孤岛实体”“关系方向对不对”非常方便。

3. 六种检索模式的中药场景效能对比

LightRAG 的六种检索模式，我拿中药场景一个个测过。测试集是 50 个问题，覆盖药材查询、方剂分析、证候推理、配伍禁忌四类。评价指标就两个：召回率（该找的有没有找到）和精确率（找出来的对不对）。

3.1 Naive 模式：最像传统检索的基线

Naive 模式就是纯向量检索，把 query 嵌入后去vdb_chunks里找最相似的文本块。优点是快，缺点是完全没有利用图结构。

我拿“黄芪的功效”这个问题测，Naive 返回的前 5 个文本块里，有 3 个是黄芪的，1 个是甘草的，1 个是白术的。为什么混进来？因为黄芪、甘草、白术在补气方剂里经常一起出现，文本块向量很接近。召回率 72%，精确率 60%。

注意：Naive 模式适合“查具体药材的单一属性”，比如“当归的性味是什么”。一旦涉及关系推理，比如“哪些药材和黄芪配伍能增强补气效果”，它就歇菜了。

3.2 Local 模式：实体为中心的局部检索

Local 模式先用 query 去vdb_entities里找相关实体，然后沿着图边扩展一跳邻居。这个模式对“药材-功效-方剂”这种局部关系特别有效。

测“四君子汤的组成和功效”，Local 模式先定位到“四君子汤”实体，然后扩展出“人参”“白术”“茯苓”“甘草”四个药材实体，再扩展出各自的功效实体。召回率 89%，精确率 82%。

但 Local 模式有个坑：如果 query 里的实体名和图中的实体名不完全匹配，就找不到。比如你搜“四君子散”，图里只有“四君子汤”，Local 模式直接返回空。我的解决办法是在 query 预处理阶段做同义词扩展，把“散”“丸”“汤”这些剂型后缀先归一化。

3.3 Global 模式：主题级全局检索

Global 模式走的是另一条路：它不找具体实体，而是找主题社区。LightRAG 在构建索引时会把关系密集的实体聚成社区，Global 模式就是去匹配这些社区。

测“补气类方剂的共同特点”，Global 模式返回的是“补气剂”这个社区下的所有方剂和药材，然后让 LLM 总结共同点。召回率 91%，精确率 78%。精确率低是因为社区边界有时候比较模糊，“补气”和“健脾”两个社区有重叠。

Global 模式适合归纳型问题，比如“活血化瘀类药材有哪些”“解表剂常用配伍规律是什么”。但如果你问“川芎在四物汤里的作用”，Global 模式就太粗了，它会把整个“补血剂”社区都拉出来。

3.4 Hybrid 模式：本地+全局的融合

Hybrid 模式同时跑 Local 和 Global，然后把结果合并排序。这是最稳的模式，没有之一。

测“逍遥散中柴胡的作用”，Hybrid 先通过 Local 定位到“逍遥散”和“柴胡”实体，拿到直接关系；再通过 Global 找到“疏肝解郁”社区，补充上下文。召回率 94%，精确率 86%。

但 Hybrid 的代价是延迟翻倍。Local 模式单次查询约 1.2 秒，Global 约 1.5 秒，Hybrid 要 2.8 秒。如果做交互式查询，这个延迟还能接受；如果做批量处理，就得权衡了。

3.5 Mix 模式：图检索+向量检索的混合

Mix 模式是 LightRAG 最复杂的模式：它同时跑图检索（Local+Global）和向量检索（Naive），然后把三路结果用 RRF 算法融合。

测“含有十八反配伍的方剂有哪些”，这个问题需要同时匹配“十八反”这个关系约束和具体方剂名称。Mix 模式召回率 96%，精确率 88%，是所有模式里最高的。

但 Mix 模式有个致命问题：它会把 Naive 检索的噪声也带进来。我测“人参的禁忌”时，Mix 返回的结果里混进了一条“人参可用于急救”的文本块，因为向量相似度高但语义完全相反。所以 Mix 模式的结果必须加一层 LLM 重排序，让 LLM 判断每条结果和 query 的相关性。

3.6 Bypass 模式：绕过检索直接问 LLM

Bypass 模式不走检索，直接把 query 扔给 LLM。我一开始觉得这个模式没用，后来发现它在常识性问题上反而最稳。

测“中药煎煮的一般步骤”，Bypass 模式返回的答案比检索模式更完整、更流畅。因为煎煮步骤是通用知识，LLM 预训练时已经学得很好了，检索反而会引入特定教材的偏差。

但 Bypass 模式绝对不能用于专业查询。我测“附子理中丸的组成”，Bypass 模式把“附子”换成了“制附子”，还漏了“干姜”。这种错误在中药场景里是致命的。

3.7 六种模式效能对比总表

4. 常见问题与排查技巧实录

4.1 实体抽取不全怎么办

最常见的问题：明明文本里写了“黄芪配当归补气生血”，但图里就是没有“黄芪-配伍-当归”这条边。

排查思路分三步：

1. 检查文本块长度。如果这个句子所在的文本块超过 500 字，LLM 的注意力会被稀释。解决办法是把长文本块切短，或者把关键关系句单独提出来做增强。
2. 检查entity_extract_max_gleaning参数。默认 1 轮抽取确实会漏，调到 2 或 3。但别超过 3，否则 LLM 会开始编造关系。
3. 检查实体名称是否一致。如果文本里一会儿写“黄芪”一会儿写“绵黄芪”，LLM 会当成两个实体。预处理阶段做同义词归一化。

我踩过最坑的一次：文本里写的是“炙甘草”，但图里只有“甘草”。后来在预处理里加了一条规则，把所有“炙XX”“炒XX”“醋XX”都映射到基础药材名，同时保留炮制类型作为属性。

4.2 检索结果相关性差怎么调

有时候检索返回的文本块看起来相关，但实际答非所问。比如搜“麻黄汤的禁忌”，返回了一堆“麻黄汤的组成”。

这个问题多半出在向量模型上。BGE-M3 虽然中文好，但对“禁忌”“组成”“功效”这些查询意图的区分度不够。我的解决办法是在 query 前面加意图前缀：

• 查组成：“方剂组成：麻黄汤”
• 查禁忌：“使用禁忌：麻黄汤”
• 查功效：“功效主治：麻黄汤”

加了前缀之后，精确率从 78% 提到了 89%。这个技巧在 LightRAG 的 issue 区没人提过，是我自己试出来的。

4.3 图谱可视化与人工校验

LightRAG 自带的图可视化很简陋，我一般导出到 Neo4j。导出脚本：

import networkx as nx from lightrag import LightRAG rag = LightRAG(working_dir="./tcm_kg") graph = nx.read_graphml("./tcm_kg/graph_chunk_entity_relation.graphml") # 导出节点 with open("nodes.csv", "w", encoding="utf-8") as f: f.write("entity_id,entity_type,description\n") for node, attrs in graph.nodes(data=True): f.write(f"{node},{attrs.get('entity_type','')},{attrs.get('description','')}\n") # 导出边 with open("edges.csv", "w", encoding="utf-8") as f: f.write("source,target,relation,weight\n") for u, v, attrs in graph.edges(data=True): f.write(f"{u},{v},{attrs.get('relation','')},{attrs.get('weight',1)}\n")

导入 Neo4j 后，我重点检查三类问题：

• 孤岛实体：没有任何关系的实体，多半是抽取错误。
• 关系方向错误：比如“甘草-佐使-麻黄”被抽成了“麻黄-佐使-甘草”。
• 重复实体：同一味药有多个名称变体。

人工校验大概花了 3 天，修正了 200 多条错误关系。这个投入是值得的，因为图谱质量直接决定检索上限。

4.4 增量更新与版本管理

中药数据不是一次性的，新药材、新方剂、新研究不断出来。LightRAG 支持增量 insert，但有个坑：增量插入后，旧的向量索引不会自动更新。

我的做法是每次增量插入后，手动触发一次rag.finalize()，强制重建向量索引。虽然慢一点，但保证一致性。另外，working_dir我按日期分目录，比如./tcm_kg_20250101、./tcm_kg_20250115，方便回滚。

提示：增量更新时，如果新文本块和旧文本块有重叠，LightRAG 会做去重。但去重是基于文本哈希的，如果只是改了几个字，哈希变了，就会产生重复实体。所以增量更新前，最好先做一次全量去重。

5. 检索模式选型与组合策略

六种模式不是互斥的，实际用起来要按查询类型动态路由。我写了一个简单的路由函数：

def route_query(query: str) -> str: # 通用常识问题走 Bypass if any(kw in query for kw in ["煎煮", "服用", "保存", "一般"]): return "bypass" # 单一属性查询走 Naive if any(kw in query for kw in ["性味", "归经", "别名"]): return "naive" # 实体关系查询走 Local if any(kw in query for kw in ["配伍", "组成", "作用"]): return "local" # 主题归纳查询走 Global if any(kw in query for kw in ["哪些", "规律", "特点", "分类"]): return "global" # 复杂约束查询走 Mix if any(kw in query for kw in ["禁忌", "相反", "相畏"]): return "mix" # 默认走 Hybrid return "hybrid"

这个路由规则是我根据 50 个测试问题的表现总结出来的，准确率大概 85%。剩下的 15% 主要是 query 意图模糊，比如“黄芪怎么用”，既可能是问用法用量（Naive），也可能是问配伍应用（Local）。这种我一般走 Hybrid，让它自己融合。

另外，Mix 模式的结果一定要加 LLM 重排序。我的重排序 prompt 很简单：

以下是与问题相关的文本片段，请判断每个片段是否真正回答了问题，只保留直接相关的片段。 问题：{query} 片段：{chunks}

重排序之后，Mix 模式的精确率能从 88% 提到 93%，代价是额外 1 秒延迟。

6. 中药知识图谱的扩展方向

这套东西跑通之后，我试了几个扩展方向，有些效果不错，有些还在踩坑。

方剂推荐：给定一组症状，从图谱里找匹配的方剂。思路是把症状作为 query，走 Global 模式找“证候”社区，再沿着“方剂-主治-证候”边反向找方剂。实测推荐准确率一般，因为症状描述太自由了，LLM 抽取的证候实体和用户输入对不齐。后来加了一层症状标准化映射，才勉强能用。

配伍禁忌检测：这个效果很好。把“十八反”“十九畏”作为硬约束写进图里，然后检查方剂组成里有没有冲突。Mix 模式跑这个任务召回率 96%，基本不会漏。

剂量推理：这个还在实验阶段。中药剂量和体质、年龄、病情都相关，图谱里很难表达这种条件依赖。我试过把剂量作为关系属性存进去，但检索时没法做条件过滤。可能得换一种图模型，比如属性图或者超图。

跨语言检索：LightRAG 本身支持多语言，但中药术语的英文翻译很不统一。我试过用“Astragalus”搜“黄芪”，Local 模式找不到，因为图里只有中文实体。解决办法是在实体属性里加一个alias_en字段，检索时同时匹配中英文。这个还没大规模测，初步看召回率能到 70% 左右。

最后分享一个我在实际调参中体会最深的点：LightRAG 的检索质量，七分靠数据清洗，三分靠参数调优。我一开始花了两周调参数，效果提升不到 5%；后来回头做数据清洗，把实体名称归一化、文本块切分优化，召回率直接涨了 15%。所以如果你刚开始搭，别急着调chunk_token_size和gleaning，先把数据洗干净。