1. 项目缘起与整体设计思路中药知识体系有个很麻烦的特点概念之间关系极其密集而且很多关系是“多对多”的。比如一味黄芪它同时涉及补气、固表、利水、托毒等多个功效维度每个功效又关联到不同的方剂、证候、药材配伍。传统的关键词检索在这种网状结构里基本是“查一个漏一片”而纯向量检索又容易在专业术语上翻车——你搜“四君子汤”它可能给你返回一堆“四君子”相关的文学内容。我这次选LightRAG来搭中药知识图谱核心原因就一个它把图结构检索和向量检索揉在了一起而且轻量。相比微软的 GraphRAGLightRAG 不需要对全量文档做社区摘要索引成本低了一个数量级增量更新也友好得多。对于中药这种需要频繁追加新药材、新方剂的场景这一点非常关键。整体设计思路分三层数据层把中药数据整理成“实体-关系-实体”的三元组格式同时保留原始文本块用于向量检索。索引层LightRAG 同时构建图索引实体关系网络和向量索引文本块嵌入两者通过实体名称做桥接。检索层LightRAG 提供六种检索模式从纯本地检索到混合全局检索覆盖不同粒度的查询需求。为什么不用 Neo4j 直接手搓我试过。Neo4j 构建知识图谱确实直观Cypher 查询也灵活但问题在于你得自己写实体抽取、关系抽取、向量化、检索排序的全套流水线。LightRAG 把这些都封装好了你只需要喂文本它自动抽实体、建图、做嵌入。对于我这种想快速验证检索效果、而不是花两周写 ETL 的人来说LightRAG 的性价比高太多。当然Neo4j 也不是没用。我最终的方案是LightRAG 做检索层Neo4j 做可视化层。LightRAG 抽出来的实体关系导出成 CSV再导入 Neo4j 做图谱展示和人工校验。这样既享受了 LightRAG 的自动化又保留了 Neo4j 的直观性。2. 中药数据准备与知识图谱构建实操2.1 数据来源与清洗策略中药数据我主要从三个渠道获取《中药学》教材电子版、国家药典公开数据、经典方剂数据库。原始数据大概 2000 多味药材、800 多个方剂但直接喂给 LightRAG 效果很差因为原始文本里大量重复、格式混乱、还有不少 OCR 错误。清洗分四步走去重与合并同一味药在不同来源里的描述合并成一条保留最完整的版本。分段处理每味药按“性味归经”“功效主治”“用法用量”“配伍禁忌”切成独立文本块每块 200-500 字。为什么是这个长度LightRAG 的实体抽取对文本块长度敏感太短抽不出关系太长会引入噪声。我实测下来 300 字左右最稳。术语标准化把“炙黄芪”“蜜黄芪”统一成“黄芪炙”把“川穹”纠正为“川芎”。这一步不做后面实体对齐会疯掉。敏感内容过滤涉及野生动物保护品种的药材描述直接剔除只保留人工种植替代品的信息。清洗完的数据大概 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_funcopenai_complete_if_cache, llm_model_nameqwen2.5-14b-instruct, llm_model_max_token_size4096, embedding_funcEmbeddingFunc( embedding_dim1024, max_token_size8192, funclambda texts: bge_m3_embed(texts) ), chunk_token_size300, chunk_overlap_token_size50, )chunk_token_size设 300 是我反复调出来的。设 500 的时候实体抽取会把“黄芪”和“甘草”的关系误判成“黄芪包含甘草”设 200 又太碎一个完整的方剂组成被切成三段关系抽不全。2.3 知识图谱构建过程与参数调优数据灌进去之后LightRAG 会自动做三件事实体抽取、关系抽取、图索引构建。这个过程是增量的你可以随时追加新数据。with open(./tcm_cleaned.txt, r, encodingutf-8) as f: rag.insert(f.read())但直接 insert 有个问题实体消歧。比如“人参”和“红参”LightRAG 会当成两个独立实体但实际上红参是人参的炮制品。我的处理办法是在文本里显式写清楚“红参为人参的蒸制加工品”。这样 LLM 在抽取时就会自动建立“红参-炮制自-人参”的关系。另一个关键参数是entity_extract_max_gleaning默认是 1。我调到 2让 LLM 对每个文本块做两轮实体抽取。第一轮抽显式关系第二轮抽隐式关系。实测下来中药方剂里的“君臣佐使”配伍关系单轮抽取经常漏掉两轮能补回来不少。构建完成后working_dir下会生成几个关键文件文件名内容用途graph_chunk_entity_relation.graphml实体关系图可导入 Neo4j 或 Gephi 可视化vdb_entities.json实体向量库本地检索模式用vdb_chunks.json文本块向量库全局检索模式用kv_store_full_docs.json原始文档溯源用我一般会把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 最复杂的模式它同时跑图检索LocalGlobal和向量检索Naive然后把三路结果用 RRF 算法融合。测“含有十八反配伍的方剂有哪些”这个问题需要同时匹配“十八反”这个关系约束和具体方剂名称。Mix 模式召回率 96%精确率 88%是所有模式里最高的。但 Mix 模式有个致命问题它会把 Naive 检索的噪声也带进来。我测“人参的禁忌”时Mix 返回的结果里混进了一条“人参可用于急救”的文本块因为向量相似度高但语义完全相反。所以 Mix 模式的结果必须加一层 LLM 重排序让 LLM 判断每条结果和 query 的相关性。3.6 Bypass 模式绕过检索直接问 LLMBypass 模式不走检索直接把 query 扔给 LLM。我一开始觉得这个模式没用后来发现它在常识性问题上反而最稳。测“中药煎煮的一般步骤”Bypass 模式返回的答案比检索模式更完整、更流畅。因为煎煮步骤是通用知识LLM 预训练时已经学得很好了检索反而会引入特定教材的偏差。但 Bypass 模式绝对不能用于专业查询。我测“附子理中丸的组成”Bypass 模式把“附子”换成了“制附子”还漏了“干姜”。这种错误在中药场景里是致命的。3.7 六种模式效能对比总表模式召回率精确率平均延迟适用场景中药场景推荐度Naive72%60%0.8s单一属性查询低Local89%82%1.2s实体关系查询高Global91%78%1.5s主题归纳查询中高Hybrid94%86%2.8s综合查询最高Mix96%88%3.5s复杂约束查询高需重排序BypassN/AN/A0.5s通用常识查询低仅限常识4. 常见问题与排查技巧实录4.1 实体抽取不全怎么办最常见的问题明明文本里写了“黄芪配当归补气生血”但图里就是没有“黄芪-配伍-当归”这条边。排查思路分三步检查文本块长度。如果这个句子所在的文本块超过 500 字LLM 的注意力会被稀释。解决办法是把长文本块切短或者把关键关系句单独提出来做增强。检查entity_extract_max_gleaning参数。默认 1 轮抽取确实会漏调到 2 或 3。但别超过 3否则 LLM 会开始编造关系。检查实体名称是否一致。如果文本里一会儿写“黄芪”一会儿写“绵黄芪”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, encodingutf-8) as f: f.write(entity_id,entity_type,description\n) for node, attrs in graph.nodes(dataTrue): f.write(f{node},{attrs.get(entity_type,)},{attrs.get(description,)}\n) # 导出边 with open(edges.csv, w, encodingutf-8) as f: f.write(source,target,relation,weight\n) for u, v, attrs in graph.edges(dataTrue): 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先把数据洗干净。