GraphRAG实战：图构建与检索如何补足向量检索的语义短板

1. 项目概述：当知识图谱遇上检索增强，我们到底在优化什么？

GraphRAG Analysis, Part 2: Graph Creation and Retrieval vs Vector Database Retrieval——这个标题不是在讲两个技术名词的并列介绍，而是一次实打实的工程决策复盘。我在过去18个月里，带着团队落地了5个不同规模的知识增强问答系统，从金融合规文档库到生物医药研发笔记，从企业内部IT运维知识库到高校科研项目管理平台，反复在“纯向量检索”和“图结构增强检索”之间做权衡、调参、压测、回滚、再上线。今天这篇，就是把Part 1中埋下的伏笔——“为什么图结构能补上向量检索的短板”——真正拆开揉碎，落到图怎么建、边怎么连、节点怎么标、查询怎么走、效果怎么量这些具体动作上。核心关键词GraphRAG、Graph Creation、Graph Retrieval、Vector Database Retrieval，不是学术概念堆砌，而是我每天在Jupyter Notebook里敲的代码、在Neo4j Browser里拖拽的子图、在LangChain日志里盯的top-k召回路径。它适合三类人：正在选型RAG架构的算法工程师，需要向产品/业务方解释“为什么多花30%开发成本做图”的技术负责人，以及刚读完LlamaIndex官方文档但发现“GraphStore”模块示例少得可怜、想摸清底层逻辑的中级开发者。这不是理论推演，是我在生产环境里用27次A/B测试、147个失败的图schema版本、3.2TB原始文本清洗日志换来的操作手册。

2. 图构建与检索的设计逻辑：为什么不能直接把向量数据库里的embedding塞进图里？

2.1 向量检索的“语义漂移”问题，本质是距离度量失焦

先说清楚一个常被忽略的前提：向量数据库（如Pinecone、Weaviate、Qdrant）本身不“理解”语义，它只忠实地执行“余弦相似度计算”。当你把一段关于“美联储加息对新兴市场债券收益率的影响”的长文本切块后生成embedding存进去，向量库能精准返回“最接近这个向量的k个块”，但这个“接近”可能指向完全不同的语义维度。我遇到过真实案例：用户问“苹果公司2023年Q3营收构成”，向量库召回的top-3结果分别是：① 一段描述iPhone 15发布日期的新闻（因“2023”“Q3”“发布”等token高频共现导致向量靠近）；② 一份关于Mac Studio芯片性能的白皮书（因“Apple”“M2 Ultra”“performance”等技术词嵌入空间邻近）；③ 真正的财报摘要片段（排第4）。问题出在哪？不是模型不好，而是向量空间里，“时间+事件+主体”的复合语义被压缩成单点，所有维度权重被强制拉平。就像用一把没有刻度的尺子去量身高、体重、体温——数值越接近，不代表越相关。这正是GraphRAG要破的局：不追求单点最相似，而追求“关系链最可信”。

2.2 图构建的核心目标：把隐性语义关系显性化为可导航的边

Graph Creation绝不是把文档分块后扔进Neo4j就完事。我定义的图构建三原则，是每次项目启动前写在Confluence首页的红线：

1. 节点必须承载可验证的实体或事件 ：禁止创建“概念性节点”如“宏观经济”“技术创新”。取而代之的是“美联储（机构，ID:FED-2023）”“iPhone 15 Pro Max（产品，ID:IPHONE15PM-2023）”“2023年9月20日议息会议（事件，ID:FOMC-20230920）”。每个节点必须有至少一个外部权威源可交叉验证（SEC文件、苹果官网PR、FOMC会议纪要原文页码）。

2. 边必须标注明确的关系类型与强度证据 ：不能只有“RELATED_TO”这种万金油边。我们强制要求每条边带三个字段： type （如 CAUSES_INCREASE_IN , IS_PRODUCT_OF , REPORTED_IN ）、 evidence_span （原文中支撑该关系的具体字符区间，如“原文第124-138字：‘本次加息导致巴西雷亚尔兑美元汇率单日下跌2.3%’”）、 confidence_score （基于规则引擎计算，非模型打分，例如：若evidence_span含明确因果动词+量化数据，则置信度=0.92；若仅含“可能影响”等模糊表述，则=0.35）。

3. 图必须支持双向路径推理 ：这是区别于传统知识图谱的关键。向量库的检索是“单跳”（query→chunk），而GraphRAG的检索是“多跳”（query→entity A→relation R→entity B→supporting_doc）。因此，边的设计必须允许反向遍历。例如， [FED-2023] -[CAUSES_INCREASE_IN]-> [BRLUSD_RATE] 这条边，必须同时支持“加息导致什么变化？”（正向）和“什么导致了雷亚尔贬值？”（反向）两种查询模式。我们在Neo4j中用 RELATIONSHIP_TYPE 属性+ REVERSE_RELATIONSHIP 元数据字段实现，而非简单添加反向边，避免图膨胀。

这套设计让图从“静态存储”变成“动态推理骨架”。当用户问“苹果新品发布对供应链股价的影响”，系统不再盲目匹配“苹果”“发布”“股价”这些词的向量，而是：① 识别出“iPhone 15 Pro Max（产品）”和“立讯精密（供应商）”两个核心实体；② 在图中查找 IS_SUPPLIER_OF 关系路径；③ 沿路径抓取所有 REPORTED_IN 边指向的财经报道节点；④ 对这些报道文本做轻量级向量重排序。整个过程，图负责“找路”，向量负责“辨貌”，各司其职。

2.3 为什么不能把向量库的embedding直接当图节点特征？

很多团队尝试过“偷懒方案”：用向量库的embedding作为图节点的 embedding 属性，以为这样就能融合两者。我亲手踩过这个坑——在医疗问答项目中，把PubMed摘要的sBERT embedding存为节点属性，结果图检索时用 gds.alpha.similarity.cosine 计算节点相似度，召回结果比纯向量库还差。原因有三：

• 粒度错配 ：向量库的embedding是对“文本块”（chunk）的编码，而图节点是对“实体”（entity）的抽象。一个“糖尿病”节点可能关联12篇不同机制研究的论文块，它们的embedding在向量空间里分散在不同区域，强行取平均会抹平关键差异。

• 关系湮灭 ：向量相似度计算时， [糖尿病] 节点和 [胰岛素抵抗] 节点的embedding距离，可能远大于 [糖尿病] 和某篇无关癌症论文块的距离——因为后者在训练语料中高频共现。图的关系边（如 HAS_PATHOLOGICAL_MECHANISM ）本应抑制这种噪声，但embedding特征反而放大了它。

• 更新灾难 ：向量库支持增量更新embedding，但图节点的embedding一旦写入，其与周边节点的关系强度就固定了。当新研究证明“糖尿病与阿尔茨海默病存在共享tau蛋白通路”，你需要新增 SHARED_PATHOLOGICAL_PATHWAY 边，而不是重新计算所有节点embedding——后者会导致整个图的拓扑关系失效。

所以，我们的实践是：图节点 不存储任何embedding ，只存结构化属性（name, type, source_id, confidence）；向量库独立维护文本块embedding；检索时，图负责生成“候选实体集”和“关系路径约束”，向量库在此约束下做精准重排序。二者是松耦合的协同关系，不是紧耦合的特征融合。

3. 图构建全流程实操：从原始文本到可查询图谱的7个硬核步骤

3.1 步骤1：领域实体识别（NER）——不用大模型，用规则+词典的确定性方案

很多人一上来就想用spaCy的en_core_web_trf或Llama-3-70B做NER，结果在金融文档里把“Fed”识别成“Federation”，在医疗报告里把“CRP”（C反应蛋白）当成“Customer Relationship Platform”。我的经验是： 在专业领域，确定性规则永远优于概率性大模型 。我们为每个项目定制三层NER体系：

• 第一层：正则表达式锚定
  针对强格式化文本（财报、监管文件、产品规格书）。例如，美联储文件中利率变动必出现在“Target Range for the Federal Funds Rate is raised/lowered to X–Y percent”句式中。我们写正则 r"Target Range.*?(\d+\.\d+)–(\d+\.\d+)" 直接捕获数值，生成 FED_FUND_RATE 实体，置信度=1.0。这步覆盖62%的高价值实体，零误报。

• 第二层：领域词典+上下文窗口
  构建 financial_entities.csv （含“LIBOR”“SOFR”“TIPS”等217个缩写）和 medical_entities.csv （含“HbA1c”“eGFR”“CKD-MBD”等893个术语）。用 pymatcher 库加载，设置 context_window=5 （匹配前后5个词），过滤掉“SOFR rate”中的“rate”（非实体）和“LIBOR transition”中的“transition”（非实体）。词典匹配的实体， source_type="domain_dictionary" ， confidence=0.95 。

• 第三层：轻量级BiLSTM微调（仅当前两层覆盖<85%时启用）
  数据集仅用1200条人工标注样本（非全量），模型结构极简：Embedding层（GloVe 100d）→ BiLSTM（128 hidden）→ CRF。训练12小时，F1达89.3%，但 只用于识别“长尾实体”如新型药物分子名、未收录的监管条款编号 。绝不让它碰核心实体。

提示：所有NER结果必须输出 start_char , end_char , entity_text , entity_type , confidence 五字段JSONL。这是后续构建 evidence_span 的唯一依据，缺失任一字段，图构建流程自动中断。

3.2 步骤2：关系抽取（RE）——用依存句法树代替大模型生成

关系抽取是图构建的生死线。我们彻底弃用“LLM生成关系三元组”的方案，因为其不可控性太高。例如，让GPT-4分析句子“FDA approved Keytruda for first-line treatment of NSCLC in 2023”，它可能生成 (Keytruda, TREATS, NSCLC) （正确）、 (FDA, APPROVES, Keytruda) （正确）、甚至 (2023, IS_YEAR_OF, FDA_APPROVAL) （无意义）。我们的方案是： 用spaCy的依存解析器定位核心谓词，再用预定义规则映射关系 。

以医疗文本为例，关键关系类型及触发规则：

实操中，我们用spaCy处理句子，获取 doc._.dependency_tree ，遍历所有动词节点，检查其依存子树是否匹配上述路径。匹配成功则提取主语、宾语实体（需已在步骤1中识别），生成带 evidence_span 的关系。整个过程在CPU上单线程处理10万句耗时<8分钟，F1=93.7%，且100%可追溯。

3.3 步骤3：图Schema设计——拒绝“万物皆节点”，用4种节点+5种边封住混乱

一个失控的图Schema是项目死亡的开端。我们强制采用极简主义Schema，经5个项目验证，覆盖98.6%的业务场景：

节点类型（Node Labels） ：

• :Entity ：所有被识别的实体，必有 name 、 type （值域： ORGANIZATION , PRODUCT , DISEASE , DRUG , REGULATION , EVENT ）、 source_id （原文位置）
• :Document ：原始文档块，必有 chunk_id 、 text_preview （前200字符）、 source_file
• :Relation ：关系实例节点（非关系类型），必有 type （如 CAUSES_INCREASE_IN ）、 evidence_span 、 confidence_score
• :Evidence ：支撑证据节点，必有 text_snippet 、 source_document_id 、 relevance_score

关系类型（Relationship Types） ：

• :MENTIONS （ :Document ）→（ :Entity ）：文档块提及某实体
• :HAS_RELATION （ :Entity ）→（ :Relation ）：实体参与某关系
• :SUPPORTS （ :Relation ）→（ :Evidence ）：关系由某证据支撑
• :IS_PART_OF （ :Evidence ）→（ :Document ）：证据来自某文档块
• :LINKED_TO （ :Entity ）→（ :Entity ）：跨文档实体对齐（如“苹果公司”和“Apple Inc.”）

注意： :LINKED_TO 边不带 evidence_span ，因其基于字符串相似度+别名词典生成，置信度恒为0.7，仅用于消歧，不参与检索路径计算。

3.4 步骤4：图入库——Neo4j批量导入的3个性能陷阱

用 neo4j-admin import 导入千万级节点时，90%的失败源于三个配置错误：

1. 内存分配陷阱 ： --nodes 参数指定的CSV文件若含1000万行， neo4j-admin 默认用4GB内存处理，必然OOM。正确做法： --max-memory=16G + --page-cache=8G ，且CSV必须按 id:ID(Entity),name,type,:LABEL 严格排序，否则索引构建失败。

2. 关系ID陷阱 ： :HAS_RELATION 边的 start id 和 end id 必须与 :Entity 节点的 :ID(Entity) 完全一致。我们曾因节点CSV用 id 列而关系CSV用 entity_id 列（值相同但列名不同），导致127万条边导入失败，日志只报“Invalid relationship start node id”，排查耗时6.5小时。解决方案：所有CSV统一用 id:ID(Entity) 命名，关系CSV用 start_id:START_ID(Entity),end_id:END_ID(Entity) 。

3. 索引时机陷阱 ：在导入前建索引（ CREATE INDEX ON :Entity(name) ）会拖慢导入3倍；在导入后建索引，但未运行 CALL db.awaitIndex(":Entity", "name") 就执行查询，返回空结果。标准流程：导入完成→ CREATE INDEX → CALL db.awaitIndex → CALL db.index.fulltext.createNodeIndex （为全文搜索建全文索引）。

我们封装了 graph_import.sh 脚本，内置这三项校验，任何一项失败即退出并打印修复命令。

3.5 步骤5：图检索Query设计——Cypher不是SQL，别用WHERE暴力扫描

Graph Retrieval的性能瓶颈90%出在Cypher写法。新手常写：

MATCH (e:Entity)-[r:HAS_RELATION]->(rel:Relation) 
WHERE e.name CONTAINS "Apple" AND rel.type = "IS_PRODUCT_OF"
RETURN e, r, rel

这会导致全表扫描，1000万节点下超时。正确姿势是 利用索引+路径约束 ：

// 第一步：用全文索引快速定位实体
CALL db.index.fulltext.queryNodes("entityNameIndex", "Apple*") 
YIELD node, score 
WITH node AS e 
// 第二步：限定关系类型，利用:Relation(type)索引
MATCH (e)-[r:HAS_RELATION]->(rel:Relation {type: "IS_PRODUCT_OF"}) 
// 第三步：只取高置信度关系
WHERE rel.confidence_score > 0.85 
// 第四步：沿关系找证据，但限制深度
MATCH (rel)-[s:SUPPORTS]->(ev:Evidence) 
WHERE ev.relevance_score > 0.7 
RETURN e.name AS entity, rel.type AS relation, 
       ev.text_snippet AS evidence, 
       rel.confidence_score AS conf

关键技巧：

• 全文索引 entityNameIndex 在 :Entity(name) 上创建，支持前缀搜索（ Apple* ）；
• :Relation(type) 必须建普通索引，否则 {type: "IS_PRODUCT_OF"} 无法命中；
• WHERE 条件必须放在 MATCH 之后、 RETURN 之前，且优先过滤高基数字段（如 type ）；
• 用 LIMIT 50 控制返回量，图检索结果是“候选集”，不是最终答案。

3.6 步骤6：混合检索编排——LangChain不是银弹，手写Router更稳

LangChain的 GraphRAGRetriever 在复杂查询下易崩溃。我们用Python手写Router，逻辑清晰可控：

def hybrid_retrieve(query: str, top_k: int = 5) -> List[Dict]:
    # Step 1: 图检索获取候选实体和关系路径
    graph_results = neo4j_driver.execute_query(
        "CALL db.index.fulltext.queryNodes('entityNameIndex', $query) YIELD node ...",
        query=f"{query}*"
    )
    
    # Step 2: 提取图中识别的实体名列表
    entities = [r["entity"] for r in graph_results]
    
    # Step 3: 若图检索返回<3个实体，降级为纯向量检索
    if len(entities) < 3:
        return vector_db.similarity_search(query, k=top_k)
    
    # Step 4: 用实体名构造向量库的filter查询
    filter_condition = {"$or": [{"metadata.entity": e} for e in entities]}
    return vector_db.similarity_search(query, k=top_k, filter=filter_condition)

# 实测：金融问答中，图检索平均返回2.3个高置信实体，向量库filter后召回准确率从61%→89%

这个Router的优势：① 图检索失败时无缝降级；② 向量库filter用 metadata.entity 字段（在chunk入库时已注入），避免语义漂移；③ 所有步骤可单独压测，故障点定位秒级。

3.7 步骤7：效果验证——不用Accuracy，用“路径可解释性得分”

评估GraphRAG不能只看BLEU或ROUGE。我们定义 Path Interpretability Score (PIS) ：

• 给100个测试问题，人工标注“黄金路径”（如 [Fed]→[CAUSES_INCREASE_IN]→[BRLUSD_RATE]→[REPORTED_IN]→[Bloomberg_20231005] ）；
• 对每个系统返回的答案，检查其引用的文档是否在黄金路径的 Evidence 节点中；
• 若是，PIS=1.0；若引用文档在路径上但非 Evidence 节点（如直接引用原始PDF），PIS=0.7；若完全无关，PIS=0；
• 最终PIS=所有问题PIS均值。

在生物医学项目中，纯向量库PIS=0.42，GraphRAG PIS=0.89。更重要的是，当PIS<0.8时，我们能直接看到是哪条边的 confidence_score 不足（如 CAUSES_INCREASE_IN 边置信度仅0.41），立刻回溯到NER/RE步骤优化规则——这是纯黑盒评估做不到的。

4. 向量库检索与图检索的硬核对比：参数、耗时、效果的12项实测数据

4.1 测试环境与数据集

所有测试在统一环境运行：

• 硬件 ：AWS c5.4xlarge（16vCPU, 32GB RAM），SSD云盘
• 向量库 ：Qdrant v1.9.0，HNSW索引， ef_construct=128 , m=16
• 图数据库 ：Neo4j 5.21， dbms.memory.heap.initial_size=8g , dbms.memory.heap.max_size=8g
• 数据集 ：金融领域（SEC 10-K年报+彭博新闻，12.7GB原始文本，切块后382万chunks，图谱含412万节点、1890万边）

4.2 核心指标对比表

注意：“提升/代价”列中，“+”表示GraphRAG更高（可能是优势也可能是开销），需结合业务场景判断。例如，金融交易系统可接受+212%延迟换取+42.4pp长尾问题解决率，而实时客服机器人可能选择向量库。

4.3 典型场景深度对比：以“特斯拉电池供应商变更”为例

用户问题 ：“2023年特斯拉4680电池的中国供应商有哪些？”

纯向量库检索过程 ：

• 切词： ["Tesla", "4680", "battery", "China", "supplier", "2023"]
• 向量库召回Top-5：① 特斯拉2022年报（提及其自建工厂）；② 宁德时代2023Q2财报（未提特斯拉）；③ 松下电池技术白皮书（2021年）；④ 亿纬锂能公告（“拟供应圆柱电池”，未提4680）；⑤ 财经媒体对特斯拉上海工厂的报道（未提电池）。
• 结果 ：无直接答案，需人工从5篇文档中拼凑信息。

GraphRAG检索过程 ：

• 图检索： fulltext.query("Tesla 4680 battery*") → 返回节点 Tesla , 4680 , CATL , EVE ；
• 路径查询： MATCH (t:Entity {name:"Tesla"})-[:HAS_PRODUCT]->(p:Entity {name:"4680"})-[:IS_SUPPLIED_BY]->(s:Entity) WHERE s.type="COMPANY" RETURN s.name ；
• 获取 CATL 和 EVE 节点；
• 向量库filter： {"metadata.supplier": ["CATL", "EVE"], "metadata.year": "2023"} ；
• 召回文档：① 宁德时代2023年8月公告（“向特斯拉供应4680电池”）；② 亿纬锂能2023年11月投资者纪要（“4680产线通过特斯拉认证”）。
• 结果 ：精准返回2份证据，附带完整路径 Tesla→HAS_PRODUCT→4680→IS_SUPPLIED_BY→CATL 。

这个案例揭示GraphRAG的本质价值： 它把“大海捞针”变成“按图索骥” 。向量库在文本海洋中游弋，GraphRAG则拿着航海图直奔港口。

4.4 成本效益分析：什么时候该上GraphRAG？

不是所有项目都值得投入GraphRAG。我们用一张决策矩阵帮团队快速判断：

我们落地的5个项目中，3个（金融、医疗、法律）上了GraphRAG，2个（电商商品库、内部Wiki）坚持向量库。后者上线周期缩短60%，维护成本降低75%，证明“合适的技术”比“先进的技术”更重要。

5. 常见问题与避坑指南：那些没写在文档里的血泪教训

5.1 问题1：图谱构建后查询变慢，CPU飙到100%，但Neo4j日志无报错

现象 ：图谱入库完成，首次运行 MATCH (e:Entity) WHERE e.name CONTAINS "Apple" RETURN count(e) 耗时47秒， htop 显示Java进程占满CPU。

排查思路 ：

• 第一步： EXPLAIN 该查询，发现执行计划是 NodeByLabelScan （全表扫描），未用索引；
• 第二步： CALL db.indexes() 确认 :Entity(name) 索引状态为 ONLINE ；
• 第三步： CALL db.propertyKeys() 发现 name 属性在 :Entity 标签下实际存储为 entity_name （因CSV列名写错）。

根因 ：索引建在 name 字段，但数据存入 entity_name ，索引形同虚设。

解决方案 ：

• 用 CALL apoc.refactor.rename.nodeProperty("entity_name", "name") 批量重命名；
• 或重建索引： DROP INDEX ON :Entity(entity_name) → CREATE INDEX ON :Entity(name) ；
• 预防措施 ：在 graph_import.sh 脚本末尾加入校验： cypher-shell -u neo4j -p pwd -f verify_index.cypher ，内容为 SHOW INDEXES YIELD name, labelsOrTypes, properties WHERE labelsOrTypes = ["Entity"] AND "name" IN properties RETURN count(*) ，非1则报错。

实操心得：Neo4j的索引错误不会报错，只会静默失效。每次导入后，必须用 EXPLAIN 跑3个典型查询验证索引命中。

5.2 问题2：图检索返回空结果，但用 MATCH (e:Entity) RETURN e.name LIMIT 10 能看到数据

现象 ： CALL db.index.fulltext.queryNodes("entityNameIndex", "Apple") 返回空，但 MATCH (e:Entity) RETURN e.name LIMIT 10 显示有“Apple Inc.”。

根因 ：全文索引默认 区分大小写 ，且不支持停用词过滤。 "Apple" 查询匹配 "Apple" ，但不匹配 "Apple Inc." （因 Inc. 是停用词被忽略，索引只存 "Apple" ）。

解决方案 ：

• 创建索引时指定选项： CALL db.index.fulltext.createNodeIndex("entityNameIndex", ["Entity"], ["name"], {analyzer: "english", eventually_consistent: true}) ；
• 查询时用通配符： CALL db.index.fulltext.queryNodes("entityNameIndex", "Apple*") ；
• 或改用 apoc.index.search ： CALL apoc.index.search("entityNameIndex", "name:Apple*") 。

避坑技巧 ：全文索引的 analyzer 必须与数据语言匹配。中文用 chinese ，英文用 english ，混用会导致索引失效。我们用 curl -X GET "http://localhost:7474/db/neo4j/config" 查当前配置，确保一致。

5.3 问题3：混合检索中，向量库filter后召回结果数锐减，甚至为0

现象 ：图检索返回 ["CATL", "EVE"] ，但 vector_db.similarity_search(query, filter={"supplier": ["CATL", "EVE"]}) 只返回1个结果，远少于预期。

根因 ：向量库的filter是 后过滤 （post-filtering），即先召回Top-k，再从中筛选满足filter的。若Top-k中本就没有 CATL 相关文档，filter后自然为空。

解决方案 ：

• Qdrant中启用 with_payload=True + score_threshold ，但更可靠的是 预过滤 （pre-filtering）：

  # 不用filter参数，改用scroll API
  results = client.scroll(
      collection_name="docs",
      scroll_filter=models.Filter(
          must=[models.FieldCondition(key="supplier", match=models.MatchAny(any=["CATL", "EVE"]))],
      ),
      limit=100,
      with_payload=True,
      with_vectors=False,
  )
  # 对results做向量相似度重排序
  

• 或在向量库中为 supplier 字段建独立索引（Qdrant的 keyword 索引），加速过滤。

实操心得：向量库的filter功能是双刃剑。高频使用时，务必在 collection_info 中确认 payload_schema 已为关键字段建立索引，否则filter会退化为内存遍历。

5.4 问题4：图谱随时间推移“发霉”，新文档加入后关系质量下降

现象 ：项目运行3个月后，图检索准确率从89%降至72%，人工抽查发现大量 IS_SUPPLIED_BY 边指向已倒闭公司。

根因 ：图谱是静态快照，但现实世界在变。我们未设计图谱生命周期管理。

解决方案 ：实施“图谱保鲜”三机制：

• 时效性标记 ：所有 :Relation 节点加 valid_until: datetime 属性，来源为证据文档的 publish_date + 180 days ；
• 自动衰减 ：每周运行Cypher作业： MATCH (r:Relation) WHERE r.valid_until < datetime() SET r.confidence_score = r.confidence_score * 0.8 ；
• 人工审核队列 ：当 confidence_score < 0.5 且 valid_until < datetime() ，自动推送到审核队列，运营人员确认后 DELETE r 或 SET r.valid_until = datetime() + duration({days:180}) 。

这套机制上线后，图谱准确率稳定在87-91%区间，波动<2pp。

5.5 问题5：团队争论“该用Neo4j还是NebulaGraph”，消耗2周仍未决

现象 ：技术选型会议陷入“Neo4j ACID强一致 vs NebulaGraph分布式扩展”的哲学辩论，无人关注业务需求。

我的裁决 ： 用Neo4j，理由三条 ：

• 我们所有项目图谱规模<5000万节点，Neo4j