1. 项目概述当《三国演义》遇上知识增强生成KAG这个项目本质上是在探索如何将古典文学《三国演义》作为知识源构建一套完整的知识增强生成KAG技术栈。不同于简单的RAG检索增强生成KAG更强调结构化知识知识图谱与非结构化知识向量检索的协同工作。我们选择《三国演义》作为实验对象有几个原因首先它的人物关系网络复杂但边界清晰其次事件时间线明确最重要的是作为公共版权作品不存在数据合规问题。整个流程可以拆解为四个关键阶段首先用LLM从文本中抽取结构化知识人物、事件、关系然后存入Neo4j图数据库构建知识图谱接着设计召回评测机制验证知识检索效果最终实现基于图谱的问答闭环。这个过程中最有趣的部分在于——如何让LLM理解温酒斩华雄这样的典故不仅是一个事件节点还关联着关羽的武力值、曹操的识人眼光等隐含属性。2. 核心组件与技术选型2.1 知识抽取LLM作为信息萃取器我们测试了Qwen-72B和Llama3-70B两个大模型在三国知识抽取上的表现。实际操作中发现几个关键点实体识别需要自定义实体类型体系。除了常规的人物、地点、时间我们还定义了计谋如火烧赤壁、兵器如青龙偃月刀等特殊类型。以下是示例promptdef build_ner_prompt(text): return f从以下《三国演义》文本中提取实体 文本{text} 要求 1. 识别类型包括人物、组织、地点、时间、计谋、兵器 2. 输出JSON格式包含entity、type、start_pos、end_pos 示例输出 {{entities: [{{entity: 诸葛亮, type: 人物, start_pos: 15, end_pos: 18}}]}}关系抽取采用两阶段策略。先用简单prompt识别可能存在关系的句子再用详细prompt解析具体关系。实测发现对三英战吕布这类事件需要显式定义关系类型如交战包含参与者、结果、时间等属性。2.2 知识存储Neo4j图数据库设计Neo4j的图模型设计直接影响后续检索效率。我们的schema经过三次迭代初始版本简单的人物-关系-人物三元组优化版本引入事件节点作为关系载体如赤壁之战作为中心节点连接参战方、时间、地点等最终版本添加元数据节点如史料来源每个节点携带置信度分数LLM抽取时生成部署建议对于中小规模知识图谱100万节点Neo4j Community版足够重要配置调整dbms.memory.heap.initial_size4G dbms.memory.heap.max_size8G dbms.memory.pagecache.size2G2.3 召回评测不只是准确率设计了三层评估体系基础召回检查查询是否能找到相关节点如关羽的武器应召回青龙偃月刀路径推理测试多跳查询能力如孙权的妹妹的丈夫是谁时效验证对有时间演进的知识验证版本管理如吕布先后效忠的不同势力评测时发现一个有趣现象简单查询上纯向量检索通过embedding的准确率比图谱查询高15%但在需要逻辑推理的复杂查询上图谱方案领先40%以上。3. 完整实现流程3.1 知识抽取实操数据预处理使用OpenCC将繁体原文转为简体按章回分割文本每章作为一个处理单元对特殊表述添加注释如玄德标注为刘备批量抽取脚本from llama_cpp import Llama import json llm Llama(model_pathqwen-72b-q4_0.gguf) def extract_knowledge(text): prompt build_ner_prompt(text) output llm.create_completion(prompt, max_tokens2000) try: return json.loads(output[choices][0][text]) except: print(f解析失败: {output}) return {entities: []}后处理技巧实体归一化如云长→关羽冲突解决当不同章回抽取结果矛盾时取出现频次高的版本人工校验高频实体前20%的高频实体100%复核3.2 Neo4j数据导入使用APOC库实现高效批量导入CALL apoc.periodic.iterate( UNWIND $entities AS e RETURN e, MERGE (n:Entity {name: e.name}) SET n apoc.map.clean(e, [name], []), {batchSize:1000, params:{entities:$entities}})实测数据原始文本约64万字抽取实体12,487个关系9,832条导入耗时8分23秒MacBook Pro M1 Max3.3 问答系统实现采用混合检索架构用户问题同时发送给向量检索引擎和图数据库结果融合策略简单事实类优先采用图谱结果开放性问题结合向量检索结果生成示例API端点app.post(/query) def handle_query(question: str): # 向量检索路径 vector_results vector_search(question) # 图谱查询路径 cypher question_to_cypher(question) graph_results neo4j_query(cypher) # 结果融合 blended blend_results(vector_results, graph_results) # 生成最终回复 return llm_generate(blended)4. 避坑指南与性能优化4.1 常见问题排查LLM抽取不一致现象同一实体在不同段落被识别为不同类型解决添加前后文窗口提取实体时附带前后3句话Neo4j查询超时现象复杂查询如5跳以上响应慢优化MATCH path(a)-[*1..3]-(b) // 限制跳数 WHERE a.name 曹操 WITH path, [n IN nodes(path) WHERE n.confidence 0.7] AS high_conf_nodes RETURN path ORDER BY size(high_conf_nodes) DESC LIMIT 10混合检索冲突现象向量检索和图谱结果矛盾策略设置优先级规则如时间属性以图谱为准4.2 性能优化记录索引优化为所有实体名称创建全文索引关系类型单独索引CREATE INDEX entity_name IF NOT EXISTS FOR (n:Entity) ON (n.name)缓存策略高频查询结果缓存5分钟实体embedding预计算存储批量操作使用UNWIND代替单条INSERTAPOC的periodic.iterate控制批次大小5. 效果验证与业务价值我们设计了三个测试维度基础事实问答如赵云的字是什么准确率92.3%响应时间平均380ms关系推理如谁同时担任过曹操和刘备的谋士准确率87.1%需要2-3跳查询事件分析如分析赤壁之战中各方的得失生成质量人工评分4.2/5关键优势能关联到后续的三气周瑜事件与传统方法对比指标纯LLM问答向量检索RAG本方案(KAG)事实准确率68%82%91%推理能力随机有限强可解释性差中等高长尾查询表现不稳定一般优秀这个方案特别适合需要严谨知识推理的场景比如教育领域的智能辅导系统金融领域的投研知识分析法律条文关联查询我在实现过程中最深刻的体会是知识图谱不是简单的数据存储而是认知框架的数字化。当看到系统能自动推断出诸葛亮与司马懿的较量本质上是后勤体系的比拼时确实感受到了知识结构化带来的质变。
