AgentRAG + GraphRAG 双框架，让个性化治疗方案准确率高达 100%
该论文展示了AI+临床指南深度结合的可能性，通过和Graph-RAG两种方法，基本解决了通用 LLM 对专业领域指南不够熟悉及“幻觉”输出的问题。在乳腺癌治疗上，这些方法能自动生成可追溯的诊疗方案，并减轻医生必须频繁翻阅更新资料的负担，为真实世界的临床应用提供了非常有价值的探索。
·
AgentRAG + GraphRAG 双框架，让个性化治疗方案准确率高达 100%
论文大纲
├── Abstract【论文概述】
│ ├── 阐述全球癌症负担不断上升【背景问题】
│ ├── 强调NCCN指南在癌症治疗中的地位【指南重要性】
│ ├── 指出整合大量临床与研究数据的挑战【问题难点】
│ └── 提出基于NCCN的AI辅助决策工具【研究目标】
├── 1. Introduction【研究背景与意义】
│ ├── 全球癌症发病率与死亡率持续增长【宏观背景】
│ ├── 个性化治疗需求对医生提出更高数据处理要求【临床痛点】
│ ├── NCCN指南以流程图形式呈现多肿瘤诊疗路径【指南特点】
│ └── 指南更新频繁导致临床医师难以及时追踪【问题描述】
├── 1.1. Related Work【相关研究综述】
│ ├── AI与NLP在肿瘤学决策支持领域的发展【技术背景】
│ ├── 大模型（LLMs）在医学文本理解与生成中的潜力【新兴应用】
│ └── 大模型的局限：可能出现幻觉、信息更新不及时【问题与挑战】
├── 2. Methodology【研究方法】
│ ├── 2.1. Data Preprocessing【数据预处理】
│ │ └── 将NCCN指南PDF转为JSON以保留关键信息【数据结构化】
│ ├── 2.2. Agentic-RAG【基于检索增强生成的方案一】
│ │ ├── Title Selection【从NCCN标题中定位相关主题】
│ │ ├── JSON Retrieval【检索对应页面的JSON数据】
│ │ ├── Treatment Recommendation Generation【生成结构化治疗建议】
│ │ └── Insufficiency Check【检查并迭代完善推荐方案】
│ └── 2.3. Graph-RAG【图结构化的方案二】
│ ├── 从文本拆分到医疗实体与关系【实体抽取】
│ ├── 构建图并根据图社区进行信息总结【知识图谱】
│ └── 最终基于图查询产出治疗推荐【图检索生成】
├── 3. Experimental Setup【实验设置】
│ ├── 3.1. Patient Descriptions and Query Variations【患者描述与问题类型】
│ │ └── 针对16种场景、4类提问方式进行测试【多样性评估】
│ └── 3.2. Evaluation Criteria【评估指标】
│ ├── 是否遗漏正确治疗【缺失判断】
│ ├── 是否产生不必要或错误治疗【准确性判断】
│ └── 是否遵循NCCN推荐顺序【流程合规性】
├── 4. Results and Discussion【结果与讨论】
│ ├── 4.1. System Performance【系统性能比较】
│ │ ├── Agentic-RAG：100%遵循NCCN，无错误与遗漏【高准确性】
│ │ ├── Graph-RAG：95.8%遵循率，偶有遗漏【结构化优势】
│ │ └── ChatGPT-4：91.6%遵循率，缺少部分细节【通用模型表现】
│ └── 4.2. Key Findings【主要发现】
│ ├── 三种系统均无“幻觉”治疗【安全性评估】
│ ├── Agentic-RAG可提供详尽出处【可追溯性】
│ ├── Graph-RAG基于知识图谱的引用关系【可视化结构】
│ └── ChatGPT-4缺乏精确文献定位【透明度不足】
├── 5. Conclusion【结论】
│ ├── 两种RAG方法显著提升治疗建议的准确度与透明度【研究贡献】
│ ├── 强调与临床医生协作的重要性【实践价值】
│ └── 实际部署中需考虑持续更新与模型迭代【应用拓展】
└── 5.1. Clinical Impact and Future Directions【临床影响与展望】
├── 将系统融入临床工作流程以减轻医师负担【临床整合】
├── 扩展至更多癌种及多维度患者数据【推广与适应性】
└── 建立与电子病历系统（EHR）的对接及合规管理【落地实施】
核心方法：
├── 2. Methodology【研究核心方法】
│ ├── [输入] NCCN指南PDF与患者描述【原始数据来源】
│ │ └── [处理] 通过Data Preprocessing阶段将PDF转换为JSON【数据结构化】
│ │ ├── 使用OCR或PDF解析工具【技术手段】
│ │ └── 将表格、流程图等可视化信息分割成JSON对象【细粒度拆分】
│ └── [输出] 结构化NCCN数据（JSON格式）与待诊断的患者信息【预处理结果】
│
│ ├── 2.2. Agentic-RAG【方法一：检索增强生成】
│ │ ├── 2.2.1 Title Selection【标题选择】
│ │ │ ├── [输入] 患者描述与问题【上下文】
│ │ │ ├── [处理] 使用GPT-4或等LLM根据患者描述匹配NCCN相关标题【语言模型推理】
│ │ │ └── [输出] 最相关的标题列表（如“手术方案”、“化疗方案”等）【结果筛选】
│ │ ├── 2.2.2 JSON Retrieval【JSON检索】
│ │ │ ├── [输入] 选出的标题列表【匹配条件】
│ │ │ ├── [处理] 基于索引或数据库，检索对应的JSON片段【文本检索技术】
│ │ │ └── [输出] 与标题相对应的NCCN内容JSON【检索结果】
│ │ ├── 2.2.3 Treatment Recommendation Generation【生成治疗建议】
│ │ │ ├── [输入] 与标题匹配的JSON数据【临床文本】
│ │ │ ├── [处理] 第二次LLM调用：编写Prompt生成结构化治疗方案【语言模型生成】
│ │ │ └── [输出] 初步的治疗推荐，包括用药、手术、放化疗等【初步方案】
│ │ └── 2.2.4 Insufficiency Check【检查与迭代完善】
│ │ ├── [输入] 初步治疗推荐【待验证方案】
│ │ ├── [处理] 第三次LLM调用：根据预定义医学要点检查推荐内容是否完整【模型审查】
│ │ └── [输出] 若发现遗漏或不充分，则迭代完善；若充分则输出最终方案【最终方案】
│
│ └── 2.3. Graph-RAG【方法二：基于图结构化】
│ ├── (1) NCCN JSONs to Text Chunks【文本拆分】
│ │ ├── [输入] 结构化的NCCN JSON【数据来源】
│ │ ├── [处理] 根据逻辑段落或主题，将JSON转换为可供LLM处理的文本片段【文本分块技术】
│ │ └── [输出] 若干文本块【细粒度输入】
│ ├── (2) Text Chunks to Medical Entities and Relationships【实体与关系抽取】
│ │ ├── [输入] 文本片段【待处理内容】
│ │ ├── [处理] 利用NER（命名实体识别）及关系抽取模型，标注治疗手段、适应症等【信息抽取】
│ │ └── [输出] 医学实体与它们之间的临床关系列表【结构化信息】
│ ├── (3) Medical Entities and Relationships to Graph Element Summaries【图节点总结】
│ │ ├── [输入] 实体及关系【抽取结果】
│ │ ├── [处理] 将这些实体和关系映射为知识图谱的节点与边，并进一步调用LLM进行摘要【图构建 + 摘要】
│ │ └── [输出] 每个图节点的简要说明【图元素概要】
│ ├── (4) Element Summaries to Graph Communities【图社区划分】
│ │ ├── [输入] 节点概要与关系网络【知识图谱】
│ │ ├── [处理] 根据病理类型、治疗阶段等进行子图或社区划分【图算法或聚类方法】
│ │ └── [输出] 各子图对应的分组或社区【社区结构】
│ ├── (5) Graph Communities to Community Summaries【社区总结】
│ │ ├── [输入] 社区划分后的子图【图社区】
│ │ ├── [处理] 继续调用LLM或其他文本摘要方法，概括每个子图中关键治疗信息【分组总结】
│ │ └── [输出] 不同病情、不同阶段的关键治疗要点【图社区总结】
│ └── (6) Final Treatment Recommendation Generation【生成最终推荐】
│ ├── [输入] 用户查询（如患者描述）与社区总结【信息源】
│ ├── [处理] 通过查询映射到相应的图社区，并综合关键要点生成治疗方案【图查询 + 生成】
│ └── [输出] 针对患者情况的个性化治疗推荐【最终方案】
│
└── [整体衔接]
├── 数据预处理为两种RAG方案提供JSON及文本片段【数据源头】
├── Agentic-RAG与Graph-RAG均使用LLM完成信息抽取与生成【语言模型支撑】
└── 最终输出个性化且可追溯的NCCN治疗建议【临床应用价值】
核心方法：
┌───────────────────────┐
│ 输入： │
│ 1) NCCN原始PDF / JSON │
│ 2) 患者描述 & 查询问题 │
└───────────────────────┘
│
┌─────────────────────────────────────────────────────────────────────┐
│ 【并行或可独立采用】 │
│ 【Agentic-RAG 流程】 【Graph-RAG 流程】
│ (LLM V1, etc.)
│
┌────────────▼────────────┐ ┌───────────────────────────────┐
│ [2.2.1] Title Selection │ │ [2.3] Step 1: NCCN JSONs → │
│ 使用GPT-4对患者描述和 │【标题选取】 │ Text Chunks │
│ 问题进行语义分析，找到 │───────────────────────────▶【NCCN文本切分】 │
│ 最相关的临床标题 │ │ 把JSON转成分块的文本，方便 │
└────────────▲────────────┘ │ 后续的实体和关系抽取 │
│【XXX】（根据标题） └───────────┬─────────────────────┘
┌────────────▼────────────┐ │【XXX】（文本分块后传递）
│ [2.2.2] JSON Retrieval │ │
│ 根据选出的标题，从NCCN │【内容检索】 ▼
│ 的JSON数据集中检索对应 │────────────────────────────────────────┌───────────────────────────────┐
│ 页面内容 │ │ [2.3] Step 2: Text Chunks → │
└────────────▲────────────┘ │ Medical Entities │
│【XXX】（检索到的JSON） │ & Relationships │
┌────────────▼────────────┐ │【实体与关系抽取】 │
│ [2.2.3] Treatment │【生成治疗推荐】 │ 使用NLP方法(如NER、关系抽取)│
│ Recommendation │────────────────────────────────────────┤ 对文本中的医疗实体(病症、药物│
│ Generation │ │ 治疗方式等)及它们的关系进行识│
│ 第二次LLM调用(如GPT-4) │ │ 别与构建 │
│ 生成结构化的治疗方案 │ └───────────┬─────────────────────┘
└────────────▲────────────┘ │【XXX】（得到实体及关系）
│【XXX】（治疗方案草稿） │
┌────────────▼────────────┐ ┌───────────────────────────────┐
│ [2.2.4] Insufficiency │ │ [2.3] Step 3: Medical Entities │
│ Check │【不足检查】 │ & Relationships → Graph │
│ 第三次LLM调用，对生成的 │────────────────────────────────────────▶│ Element Summaries │
│ 治疗方案进行检查：是否 │ │【图元摘要】 │
│ 还有缺失或不一致 │ │ 将实体和关系组织成图结构里的 │
└────────────▲────────────┘ │ 元素信息，并提炼摘要 │
│【XXX】（若不足则返回修正） └───────────┬─────────────────────┘
│ │【XXX】（图元素信息）
│ ▼
│ ┌────────────────────────────────────┐
│ │ [2.3] Step 4: Element Summaries → │
┌────────────▼─────────────────────────────────┐ │ Graph Communities │
│ 最终输出: 「Agentic-RAG 产出的个性化治疗方案」│ │【图社区构建】 │
└───────────────────────────────────────────────┘ │ 根据相似或关联的图元素，将其划分为 │
│ 不同社区(子图) │
└───────────┬─────────────────────────┘
│【XXX】（社区划分结果）
▼
┌────────────────────────────────────┐
│ [2.3] Step 5: Graph Communities → │
│ Community Summaries │
│【社区摘要】 │
│ 进一步对每个社区进行总结与凝练， │
│ 准备好可直接用于回答的关键信息 │
└───────────┬─────────────────────────┘
│【XXX】（社区合并后的信息）
▼
┌────────────────────────────────────┐
│ [2.3] Step 6: Final Treatment │
│ Recommendation Generation │
│【最终生成治疗推荐】 │
│ 将社区摘要和用户的具体问题结合， │
│ 调用LLM或规则来输出最终推荐 │
└───────────┬─────────────────────────┘
│
▼
┌────────────────────────────────────────────────┐
│ 最终输出: 「Graph-RAG 产出的个性化治疗方案」 │
└────────────────────────────────────────────────┘
1. WHY——为什么提出这项研究？
在肿瘤学尤其是乳腺癌临床中，治疗方案需要紧密跟随不断更新的NCCN（National Comprehensive Cancer Network）指南，而这些指南内容庞大、更新频率高。
医生常面临以下挑战：
- 信息繁杂、难以及时掌握：NCCN 指南包含大量的诊疗流程、表格、药物组合，且版本更新频繁，临床医生难以全面、及时地查询和整合。
- 个体化医疗需求高：乳腺癌患者的肿瘤类型、分期、基因检测结果等情况差异大，制定专属的治疗方案需要综合多重信息，人工查询时容易遗漏或出错。
- 治疗决策压力大：少数错误或不准确的治疗策略可能显著影响患者预后，甚至带来严重后果。
为此，论文提出了一个基于人工智能的工具，能够自动检索、匹配并生成个性化的 NCCN 乳腺癌治疗建议，以减轻医生负担、提高诊疗效率和准确率。
1.2 类比理解：正反示例
-
正例（正向场景）
一位肿瘤科医生在门诊中接诊到一名 HER2 阳性、早期乳腺癌患者，需要综合考虑患者既往病史、最新 NCCN 指南以及患者病理分型来制定多学科治疗方案。此时，通过Agentic-RAG 或 Graph-RAG 这样高度结构化的智能工具，医生可以在系统中输入患者关键信息，并迅速获得与 NCCN 指南高度匹配、且结合病人个体化因素的方案（例如是否推荐新辅助治疗、哪些药物组合最适合等）。
因为系统在背后做了完整的检索和多轮检查，医生能确信推荐的治疗策略符合最新标准。
-
反例（错误或反向场景）
假如没有参考最新指南，或者只是凭医生个人记忆和过去经验来制定方案，可能出现治疗方案滞后（与新标准不符）、药物不适配（使用了过时或并不适用该分型的药物），甚至对高危因素处理不当。这种情况下，患者的治疗效果可能受到负面影响。 -
方法: 两个主要系统 Agentic-RAG 和 Graph-RAG，采用检索增强（Retrieval-Augmented）和图结构分析的思路。
-
数据显示：
- Agentic-RAG 达到 100% 的 NCCN 指南符合率，无幻觉、无错误，主要得益于多轮 LLM 调用和最终的“Insufficiency Check”。
- Graph-RAG 约为 95.8% 的符合率，比 ChatGPT-4（约 94%）还要高；仅出现一次遗漏（错过了某治疗选项），无幻觉。
- ChatGPT-4 作为基线，虽表现不俗，但因没有结构化检索机制，会出现遗漏或不够精确的问题。
2.5 关联：和前人的工作有什么关系？
- 与传统临床决策支持（CDSS）: 早先已有一些基于规则或简单检索的决策支持系统，但其更新和推理能力有限，无法实时匹配患者多样化的病历信息，也常缺少对最新 NCCN 更新的灵活整合。
- 与通用大模型: ChatGPT-4 等大型模型可以生成医疗相关回答，但如果直接应用于临床决策，可能因缺少针对性数据和内置防“幻觉”机制而导致不准确或遗漏。
- 创新点: 本文将 NCCN 流程图、表格等半结构化信息转成 JSON，再用 Retrieval-Augmented 技术或图结构化技术来保证方案推荐的准确性和可追溯性。
3. WHAT——核心发现或论点是什么？
- 核心观点: 通过结构化的检索与生成框架(Agentic-RAG 或 Graph-RAG)，可以有效规避通用 LLM 容易出现的虚构内容或指南不更新的问题，为乳腺癌患者提供可靠且可追溯的个性化治疗建议。
- 主要发现:
- Agentic-RAG 在多轮审查机制下，能够100%贴合 NCCN 指南；
- Graph-RAG 也能高质量输出治疗方案，并以图结构进行关系管理；
- 相比之下，单纯依赖 ChatGPT-4 容易出现遗漏或无引用的情况。
4. HOW——研究的具体实现与创新
4.1 前人研究的局限性
- 很多基于规则的CDSS（临床决策支持系统）或简单检索系统无法跟上 NCCN 频繁更新；
- 通用大语言模型缺少医学领域的强化机制，也缺少数据可溯源能力；
- 现有方法常常要人工对照文本或不包含可行的自动化检查环节，导致遗漏及不一致性。
4.2 创新点 / 新视角
-
Agentic-RAG:
- 多轮 LLM 调用(标题选取→检索→生成→检查)，确保对 NCCN 内容的精准引用；
- “Insufficiency Check” 阶段可识别输出中是否遗漏必须的治疗选项，保证完整度。
-
Graph-RAG:
- 将JSON格式的 NCCN 指南拆分成文本块，再用实体识别、关系抽取构建图结构；
- 对相似或相关联的诊疗节点进行社区划分，提取出可复用的知识子图，再生成个性化推荐。
4.3 关键数据支持
- 使用 16个临床场景（不同乳腺癌类型、分期、治疗史）进行测试，每种场景下包含4种问法； 共计产生了 64 条查询数据
- 论文团队将 NCCN 指南中涉及乳腺癌的关键信息（尤其是流程图、诊疗路径、推荐用药等）转化为 JSON 数据格式，最大程度保留了原文献的准确内容，并由人工或专家进行复核，确保所用数据真实、完整。
- Agentic-RAG 达到100% NCCN 准确率（并且提供了相应的原文出处页码引用），Graph-RAG 达到约95.8%（偶尔会因为图谱维度覆盖不全而遗漏个别治疗），而 ChatGPT-4 在94%左右；
- 零虚构内容 (hallucination) 使该系统更具临床可行性。
4.4 可能的反驳及应对
- 反驳: “AI 会不会仅仅贴合指南而忽略患者个体化因素？”
- 应对: 研究中已设计多种患者场景，让系统在充分检索指南的基础上融合患者病史与诊断分型，避免“一刀切”；同时仍需医生进行最后把关。
- 反驳: “LLM 或图模型都可能在极端场景下表现不佳。”
- 应对: 论文承认在非常罕见或复杂并发症情况下，需要更多高质量数据和临床专家校验。但对多数常见亚型可显著减轻医生负担。
5. HOW GOOD——研究的理论贡献和实践意义
-
理论贡献:
- 提出了一种适用于医学规范性文档（如 NCCN）与 LLM 结合的通用框架；
- 将多轮检索生成或图结构语义分析引入癌症治疗决策支持，为智能临床辅助提供了新思路。
-
实践意义:
- 对临床工作：可提高医疗机构遵循最新 NCCN 指南的效率与准确性，降低医生人工对照的压力；
- 对医疗 AI 产品：为将 LLM 嵌入医院信息化系统提供了可行路径，兼顾合规性与可追溯性；
- 对患者：有望获得更个性化、更科学的治疗方案。
6. 🔄 总结归纳
6.1 总结收获
- 该论文展示了AI+临床指南深度结合的可能性，通过Agentic-RAG和Graph-RAG两种方法，基本解决了通用 LLM 对专业领域指南不够熟悉及“幻觉”输出的问题。
- 在乳腺癌治疗上，这些方法能自动生成可追溯的诊疗方案，并减轻医生必须频繁翻阅更新资料的负担，为真实世界的临床应用提供了非常有价值的探索。
6.2 提出探索问题
- 问题1: 若将此系统扩展到更广泛的癌种或其他疾病领域，是否依旧能保持高准确度和可扩展性？
- 问题2: 在真实的临床环境里，医生通常有各种个体化考量，比如患者经济状况、药物耐受性等；这些是否也能被自动化地纳入智能生成中？
- 问题3: 有没有可能引入更多实时数据（如患者生物标志物动态变化）来让推荐更“自适应”？在技术上还需做哪些改进？
整体而言，本论文的核心在于提供一种融合检索增强和图分析的解决方案，自动化地生成并验证个性化的乳腺癌治疗方案，从而大幅提高对最新 NCCN 指南的可及性和合规度。对医疗 AI 从业者和肿瘤科临床人员都具有相当的参考价值。
解法拆解
最终评价表明：
- Agentic-RAG 在对NCCN标准的“完整性”和“准确性”上表现最好（100%准确率），且无幻觉(hallucination)与无错误推荐。
- Graph-RAG 次之（约95.8%），仅有一次错误推荐。
- ChatGPT-4 作为基线，出现了漏掉治疗方案以及不够完整等问题（约91.6%的准确率）。
解法（总） = 子解法1 + 子解法2 + 子解法3
-
子解法1：数据预处理（Data Preprocessing）
- 之所以用数据预处理子解法，是因为：NCCN指南多以PDF、图表、流转流程的形式存在，必须转化为可供检索和结构化的格式（JSON）才能被后续的RAG模型有效利用。
- 具体做法：
- 将NCCN指南PDF中的文字、表格、流程图等，转换为JSON格式；
- 每个JSON对象/文档记录对应一页或一段NCCN信息；
- 便于后续使用LLM来做基于文本检索（如语义匹配和索引）的工作。
-
子解法2：Agentic-RAG 方法
- 之所以用Agentic-RAG子解法，是因为：需要在生成治疗方案时做到“多轮自动检查”、“自动检索”、“逐步完善”，以确保不遗漏任何重要治疗选项，并且要对照NCCN最新标准避免幻觉。
- 该子解法又可进一步拆解为 4 个更具体的子步骤：
- (2.1) 标题/主题选择（Title Selection）
- 之所以用标题选择子解法，是因为：需要先确定对患者病情最相关的NCCN子章节、标题或者主题页面，然后再缩小检索范围，提升准确率。
- (2.2) JSON检索（JSON Retrieval）
- 之所以用JSON检索子解法，是因为：在上一步确定了最相关的NCCN章节或主题后，需要到JSON数据中去精准定位对应的关键信息（如治疗原则、分期、分子分型等）。
- (2.3) 治疗方案初步生成（Treatment Recommendation Generation）
- 之所以用初步生成子解法，是因为：在获取到相关NCCN内容后，需要LLM根据患者信息与检索到的内容“组合”出一个初步的治疗推荐方案。
- (2.4) 不足/遗漏检查（Insufficiency Check）
- 之所以用不足检查子解法，是因为：LLM 生成的内容可能有所遗漏或不够完整，需要另一次LLM调用对“已生成方案”做对照检查，如果有遗漏则迭代补充，直至完整为止。
- (2.1) 标题/主题选择（Title Selection）
-
子解法3：Graph-RAG 方法
- 之所以用Graph-RAG子解法，是因为：在一些场景下，适合先对医疗文本进行实体识别与关系提取，构建“图数据库”，再基于图数据库做更直观、更可控的查询，以降低遗漏。
- 该子解法又可拆分为 5 个更具体的子步骤：
- (3.1) NCCN JSON 转文本片段（NCCN JSONs to Text Chunks）
- 从JSON中抽出可读文本分段，便于下一步分析。
- (3.2) 文本片段转医学实体与关系（Text Chunks to Medical Entities and Relationships）
- 通过实体识别和关系抽取，得到诸如“药物—适应证”、“癌症分期—治疗策略”等结构化信息。
- (3.3) 医学实体和关系转图要素（Medical Entities and Relationships to Graph Element Summaries）
- 将抽取到的实体与关系映射到图数据库的节点和边（Graph Node/Edge），形成半结构化、可检索的知识图谱。
- (3.4) 图要素聚合到社区（Element Summaries to Graph Communities）
- 有时需要先对分散的关系进行“社区检测”或聚合，最终把相关性强的实体放在同一个“社区”中，便于后续获取。
- (3.5) 社区信息生成最终治疗推荐（Final Treatment Recommendation Generation）
- 最终基于患者的检索条件，从图社区中提炼关键信息，再结合LLM辅助生成文本化的治疗方案。
- (3.1) NCCN JSON 转文本片段（NCCN JSONs to Text Chunks）
举个例子：若有一位乳腺癌患者，分期为I期，HER2阳性，需要辅助治疗方案。
- Agentic-RAG 的流程可能会先识别该患者“乳腺癌I期、HER2阳性”→检索到NCCN指南中相应标题（辅助治疗章节）→ 抓取JSON→ 生成治疗方案→ 做不足检查，发现缺少针对HER2阳性患者的靶向治疗说明，再次补充。
- Graph-RAG 的流程则先把所有NCCN的文本转换成实体（如“HER2阳性”“辅助治疗”）及关系，然后在知识图谱里查找与“乳腺癌I期、HER2阳性”相关的节点边，再拼接成推荐方案。
2. 这些子解法是什么样的逻辑链？以决策树形式列出来
下面用一个简化的“决策树”来表示整个解法的逻辑关系。请注意，因Agentic-RAG与Graph-RAG是两种不同方案，它们并行存在，故在顶层分为两条主干：
┌───>【(2) Agentic-RAG 子解法】
│ │
│ ├──> (2.1) 标题/主题选择
│ ├──> (2.2) JSON检索
【数据预处理子解法(1)】───┤ ├──> (2.3) 初步生成治疗方案
│ └──> (2.4) 不足检查与迭代
│
└───>【(3) Graph-RAG 子解法】
│
├──> (3.1) JSON -> 文本片段
├──> (3.2) 文本 -> 实体与关系
├──> (3.3) 实体关系 -> 图要素
├──> (3.4) 图要素 -> 社区汇总
└──> (3.5) 生成最终治疗推荐
说明：
- 首先所有方法都依赖**“(1)数据预处理”**。
- 之后**“(2) Agentic-RAG”和“(3) Graph-RAG”**是两种并行可选的方案，用来从NCCN的结构化或半结构化信息中得出最终推荐。
3. 分析是否有隐性方法（不是书本上的方法，而是解法中的关键步骤）
对比文中描述和常见的“RAG”技术流程，发现以下可能的“隐性方法”或“关键步骤”，并不属于标准教科书中常规列举的“检索+生成”二段式，而是作者根据需求强化或定制的步骤：
-
LLM多次调用迭代
- 在Agentic-RAG中，存在一个“第三次LLM调用”做**“Insufficiency Check（不足检查）”**的操作，这并不是标准RAG流程中的常规步骤。
- 定义关键方法：多次LLM迭代检查
- 方法本质：先由LLM生成初步方案，再使用另一个或同一个LLM对方案做检查并提出可能的遗漏或冲突，然后循环修正，直到满足要求。
- 隐性特征：强调了“方案是否与NCCN一致”、“有无缺失治疗选项”等专业评估，远比一般RAG只做一次生成更加精细。
-
图社区（Graph Communities）聚合
- Graph-RAG中，作者提到将实体和关系转换成“社区”（Community），再对社区进行汇总。这种社区检测或聚合常见于图算法，但并非所有知识图谱应用中都会强调这一环节。
- 定义关键方法：图社区聚合
- 方法本质：先识别出图中的相互关联节点集合，再做自动化或半自动化的聚类，提升检索/推荐效率和准确度。
- 隐性特征：这一过程会根据治疗阶段、分子特征等对节点进行分组，得到更有临床意义的结构。
因此，这两步（“多次LLM迭代检查”与“社区聚合”）可以算作隐含在文本之中，但对最终结果质量影响巨大的“关键方法”。
4. 分析是否有隐性特征（特征不在问题、条件中，而是解法的中间步骤）
在本解法中，确实存在一些**“隐性特征”**，即在题目原始需求中并未明确提出，但在实现过程中默认假设或体现出来的要点。例如：
-
Prompt Engineering / 提示词工程
- 无论是Agentic-RAG还是Graph-RAG，都多次调用LLM；作者显然对每次调用都设计了特定的系统提示与约束，例如“请将输出限定在NCCN页面XX-XX”、“如遇不足时请输出哪部分不足”等。但这些提示策略在文中以“proprietary prompts”或“specifically designed prompts”等方式被简单提及，并没有详细展开。
- 这属于一种“隐性特征”，即系统有效的前提是设计了良好的Prompt模板，但并未在问题描述中显式说明。
-
对NCCN最新版本的依赖
- 系统高度依赖NCCN指南的版本正确与完整性；文中并未明确说明如何处理指南版本冲突，或者旧版和新版之间的差异；
- 这意味着在真正的临床应用中，还有一个“定期更新JSON数据库”的隐性步骤。
- 这可视作一个隐性特征（动态版本管理）：若不持续更新，系统可能最终与最新NCCN标准出现偏差。
-
评估标准（评价指标）中对“无幻觉”与“正确率”的权重设置
- 文中提到了衡量维度（漏掉的治疗、错误的治疗、幻觉等），但在实现流程中，很可能对LLM的回答做了自定义的评分阈值或策略（比如判断“是否出现NCCN里未收录的治疗方案”），这些逻辑判断也可能散落在实现代码中，属于隐性策略的一部分。
综上，这些“隐性特征”或“隐性方法”并未在常见的“检索增强生成（RAG）”示例中完全体现，但在文中却发挥了重要作用。
5. 方法可能存在哪些潜在的局限性
根据文中描述和常见的临床决策支持场景，我们可以总结以下潜在局限性：
-
对NCCN数据依赖度高
- 如果NCCN的PDF被转换时出现错误、或JSON结构不完善，会直接导致最终推荐方案不准确或不完整。
- 若NCCN指南更新不及时，系统可能产生过时方案。
-
隐性Prompt工程的挑战
- 该方法高度依赖LLM多次调用和提示工程。提示词（prompts）的质量、上下文设置、迭代逻辑等都会影响最终结果；一旦Prompt不合适，依旧可能出现遗漏、错误或不稳定的答案。
-
图方法对复杂情况的兼容性
- Graph-RAG依赖对实体与关系的准确抽取以及正确的社区聚合。一旦分词、实体识别或关系抽取有偏差，就可能在图中缺失关键节点或连错边，导致检索不到正确的推荐方案。
-
难以处理极度复杂或罕见病例
- 尽管系统对于常规流程能给出方案，但对于非常罕见或需要高度个性化处理的病例（比如合并多种癌症、极其罕见的突变），系统可能无法在NCCN的通用指南中检索到足够信息，也缺乏深度学习的特征支持，导致无法生成完善建议。
-
潜在的法律/伦理合规风险
- 在临床应用场景下，若AI提供了不正确或不适宜的治疗建议，责任归属仍然需要医疗机构严格评估；因此在实际部署时，还需要在医师决策环节加一道“人工审查”。
为什么 AgentRAG 比 GraphRAG 好？
1. 两种方法的核心差异
-
Agentic-RAG
- 多轮 LLM 调用 + “Insufficiency Check”
- 整个流程采用“标题定位→检索相关 JSON→生成治疗方案→不足检查与迭代完善”四步，尤其是最后的“Insufficiency Check”由 LLM 自动对方案进行二次或多次审查，检查是否遗漏了必要的治疗手段（例如针对不同分期或分子特征所必须考虑的诊断和治疗流程）。
- 这就像在每次生成后，再进行一次“质控”或“复核”，使得可能的漏诊和错误被及时捕捉并纠正。
- 高度依赖最新指南的“文本检索+语言模型”结合
- Agentic-RAG 从 NCCN JSON 中抓取的内容是最直接、最贴近原始指南结构的文本，经过多轮提示词（Prompt）引导，可以确保对最新内容的引用。
- 如果初次生成方案有任何不准确或不完整，第二次或第三次调用会继续迭代补足。最终只要原始指南中存在相关信息，就不会被遗漏。
- 目标清晰且上下文闭环
- 在每次调用 LLM 时，Prompt 中都明确指定了所需信息、校验逻辑和输出格式，这种“具备 Agentic 控制流”的思路可以有效降低“幻觉”和“遗漏”。
- 多轮 LLM 调用 + “Insufficiency Check”
-
Graph-RAG
- 依赖知识图谱的完整性和准确性
- Graph-RAG 将 NCCN 中的知识拆分为“实体 + 关系”再构建图结构。若前期的实体抽取或关系抽取有微小偏差（例如某个治疗环节被解析到错误的节点、遗漏了某个边），就可能导致最终检索路径出现“断点”，从而在推荐时漏掉相关治疗。
- 社区划分（Graph Communities）也可能因算法聚类或阈值设计而存在边缘情况，导致重要信息被划到别的子图，或是子图间的交互关系未被完整利用。
- 缺少“多轮审查”的最后一关
- 虽然 Graph-RAG 在构建图的过程中可能有一定的摘要或合并，但最终并没有一个像 Agentic-RAG 那样“逐条对照 NCCN 标准、若有遗漏则再次检索生成”的专门环节。
- 一旦知识图谱层面出现某些信息连接不够紧密，或提取规则未涵盖某些不常见的治疗路径，就可能造成误差。
- 对多样化患者描述的适配能力略逊
- Graph-RAG 先把大段文本变成实体+关系，然后再按照图中的“社区”去汇总信息。对于非常多样化的患者描述（如既往病史、合并症、特殊基因突变）等，若在图构建阶段未被精细标注或未连接到对应的治疗方案节点，就容易出现遗漏。
- 依赖知识图谱的完整性和准确性
2. 关键原因：Agentic-RAG 的多轮迭代检查机制
从论文中的实验结果看，Agentic-RAG 能保证 100% 准确率，最突出的因素就是**“Insufficiency Check” 阶段**：
-
多轮 Prompt 递进式生成
- 第一次生成方案后，系统会让 LLM 自行核对“是否有不符合 NCCN 指南的地方”“是否遗忘了必需的步骤或药物”，并要求给出改进意见。
- 如果发现在 HER2 阳性患者中漏写了相应的靶向治疗，那么系统就会自动补充。
- 如此反复数轮，直至结果被“判定为完整、无错误”。这相当于构建了一个自动化的“质量把关人”角色。
-
针对患者场景的逐条校验
- 比如分期、激素受体状态、HER2 状态等，如果有任何一个状态对应的指南推荐被落下了，最终检查就会报错，触发二次生成。
- 这一过程本质上是“用 LLM 来纠错 LLM”——只要检索到的信息存在于 NCCN 指南里，就能在多轮迭代中补回来。
-
检索内容与回答内容强绑定
- Agentic-RAG 在生成时就会嵌入检索到的 JSON 内容，大模型在“回答”时更多是对 JSON 内容的“整合与解释”而非自由发挥，大幅降低了“幻觉”并提高了针对性。
- 加上多轮检查更进一步保证了信息全面性。
3. Graph-RAG 的潜在薄弱环节
与 Agentic-RAG 相比，Graph-RAG 的确具备结构化、可视化的优势，但在某些环节会导致精确度略有损失：
-
实体及关系抽取的复杂度
- NCCN 指南里不仅有文字叙述，还有表格、流程分支、脚注、图示等。这些异质化信息在自动化实体和关系抽取时更容易出现差错或遗漏。
- 如果把“分期”和“具体治疗选项”之间的关系抽取不完整，或者对“适应症”的拆分不够细致，就会在图中失去节点或缺少关键边。
-
社区划分的参数/阈值
- Graph-RAG 提出的“社区检测”是一种常见图算法手段，但不同的阈值或相似度判定，会把某些节点错误地分配到别的社区、或把单一节点“孤立”出来。这样就可能导致在后续的检索或合并阶段，“社区摘要”中出现不完整。
- 如果某个疗法本该在“HER2+早期乳腺癌”社区，却由于算法阈值导致被分到另一个子图，那么在面向该患者场景时，就会漏掉它。
-
缺乏最后一轮全面审查
- Graph-RAG 的设计理念更多是“把有用信息放进图里，然后通过图查询找回关键节点”，缺少一个像 Agentic-RAG 那样的“对照 NCCN 全局再校准”的环节；
- 如果在图搜索时，没有捕获到一个对应的节点（可能是抽取时遗漏），就不会再触发自动纠正流程，导致最终方案里出现 5% 左右的遗漏或不够完整。
4. 结论：为什么 Agentic-RAG 能做到“无遗漏”？
综合来看，Agentic-RAG 之所以能实现 100% 个性化准确度，主要得益于两个关键设计：
-
强检索 + 强约束
- 先行基于标题主题检索到最相关的 JSON 片段，确保大模型回答不离开 NCCN 的根源内容。
- 大模型的“生成”空间被严格“锁”在相应的指南文本之内，不存在跳到不相关内容的可能。
-
多轮“Agentic”自我纠错/质控
- 大模型在输出前有一个“自查”流程，可以把遗漏的部分重新捞回来。
- 这个“自查”流程在通用 RAG 里并不是“标配”，需要专门设计多次 Prompt 调用和循环机制，才能让 LLM 反复自检、补充与修正。
而 Graph-RAG 更注重知识图谱的可视化关系和整体复用，但因为构建图谱时的抽取环节更复杂、以及缺乏末端多轮核对，导致在极少数场景可能漏掉某些分支或细节，从而止步于 95.8% 的一致率。
5. 如何看待两者在临床落地中的取舍
-
Agentic-RAG
- 对最新指南的完全覆盖性和多轮审查特别适合对精度要求极高、容错率极低的任务，尤其是在乳腺癌、肺癌等“标准化诊疗路径”很明确的领域。
- 但实现上需要反复调用 LLM，Prompt 设计和维护成本较高。每一轮检索、生成、审查都需要考虑高效和可控性。
-
Graph-RAG
- 优点是可对知识图谱进行可视化管理，在针对“同类问题”或“同类患者场景”时，可以快速查询并“跨图谱”挖掘更多关联（例如与并发症的关系）。
- 在团队使用多种数据库或需要与更丰富医疗数据打通时，Graph 结构往往更适合做大规模的知识管理。
- 但短板在于图构建质量和社区划分算法上，只要存在微小的抽取或聚类误差，就可能在最终推荐时埋下“遗漏”隐患。另外，缺少类似 Agentic-RAG 那样的最后一道“全量复查”机制。
6. 小结
- Agentic-RAG 完成 100% 个性化治疗的核心原因是：
- 紧密依赖最新 NCCN 文本，且在标题检索→JSON提取→方案生成→不足检查 这一整套流程中，任何遗漏都可以在多轮循环审查中被“捞回”。
- 生成环节和检查环节都基于 LLM 的强大推理能力，但 Prompt 明确地把 NCCN 指南当成唯一可信来源，并对“遗漏检查”有专门设计。
- Graph-RAG 则以图结构管理知识，易于可视化和后续拓展，却相对欠缺“自我纠错”环节，一旦在实体抽取、关系链接或社区划分中出现疏漏，就可能导致最终推荐有轻微遗漏，无法像 Agentic-RAG 那样在最后关头“回头再查漏补缺”。
因此，Agentic-RAG 在准确率层面的优势非常明显，尤其适合对治疗方案零容忍度错误的场景；
Graph-RAG 则在知识管理和可视化整合方面有长处，适合更复杂、更广泛的多病种知识网络。
但如果要向 100% 逼近，仍需要在“图谱构建流程”和“末端多轮核查”上进行更完善的设计。
如果俩者都能提供解释性证据，那岂不是只需要Agentic-RAG，不需要Graph-RAG？
如果 Agentic-RAG 能达到几乎完美的准确率，而且也能追溯到原始文献/JSON 内容，那么为什么还要保留一个在准确率上略逊一筹的 Graph-RAG 呢？
1. 二者在“解释性”背后的差异
- Agentic-RAG 的“可追溯”更像是“回到原始文本”:
- 系统告诉你“这句建议来自 NCCN 指南第 X 页 / JSON 节点”，并在多轮检索生成中保留引用信息。
- 解释性更偏向“我来自哪一段原文，全文是怎样的”。
- Graph-RAG 的解释性基于“知识图谱”关系:
- 系统不仅能告诉你“用了哪些原始文本”，还可以显示在知识图中不同实体和关系是如何连接、分层、聚合的。
- 解释性更偏向“从图结构看，HER2 阳性节点与这些药物节点之间的关系是如何形成，为什么它们同时出现在推荐方案里”。
简而言之，二者都能提供“可追溯、可解释”的依据，但 Graph-RAG 能给出的是更“结构化的因果/语义关系”，而 Agentic-RAG 更偏向“把文本证据拿给你看”。
对一些需要“可视化地理解知识点之间关联”的场合，图方法会更有用。
2. Graph-RAG 的其他价值：知识管理与可扩展
-
适合更大规模、多病种或跨学科的知识库
- 乳腺癌是一个相对明晰、流程化的病种，Agentic-RAG 确实可以在这一场景里做得很出色（准确率达 100%）。
- 但如果要在更大范围内整合多种癌症、并且引入其他医学指南、科研论文、真实世界证据等，知识量就会急剧膨胀。
- 图结构在管理和检索海量、多元异质数据时，更直观且可扩展：我们可以不断把新文献解析成节点和边，做社区合并或拆分，而不必只依赖“标题-JSON”的检索路径。
-
可进行复杂、多跳查询与推理
- 在某些临床问题中，需要跨好几个实体和关系才能到达结论，比如“患者先做过 X 手术，术后有 Y 病理结果，因此在内分泌治疗环节又需要额外考虑 Z 药物”。
- 如果这些关联都已经在图谱中建立好，一次图查询就能快速找出多跳路径上的相关节点，还可对整条推理路径进行可视化跟踪。
- Agentic-RAG 也能做复杂推理，但多轮检索 + 生成的流程会随问题复杂度增加而变冗长；图检索对于关联项较多的场景往往更高效。
-
能与医院信息系统、科研数据库对接
- 许多医院或科研机构在做数据治理时，都在使用各种“知识图谱”或“图数据库”来管理临床、基因组、实验室检测等信息。
- Graph-RAG 无缝对接这样的底层数据库：把 NCCN 指南的知识结构融入医院已有的图数据库中，通过统一的查询接口就可获取既包含指南条目、也包含患者自身病历、基因数据等更丰富的信息。
3. Graph-RAG 在某些场景下更“健壮”
-
面向频繁更新的场景
- NCCN 指南本身更新频繁，如果每次更新都要对文本进行 OCR / JSON 转化后，再在 Prompt 里写出“标题检索”逻辑，背后仍需要一定的维护工作。
- Graph-RAG 如果通过自动的实体/关系抽取流水线，将新版本的指南文本“增量”地合并到知识图，可以形成持续更新的图数据库。而且旧版本和新版本节点也能并存，方便对比和回溯。
-
适用于跨指南、多源数据融合
- 很多临床决策并不只基于 NCCN 一份指南，还可能参照 ESMO 指南、ASCO 指南，以及本地临床路径、真实世界研究数据等。
- 这些来源的格式、结构可能五花八门；只要能抽取出实体和关系，就可整合到同一张“巨图”里。
- 将来做多中心研究时，需要把不同版本或不同组织的指南“放在一起”比对、冲突消解，图结构往往更灵活，也更适合做自动化的“关系对齐”。
4. 最终定位：二者互补，Agentic-RAG 侧重“指南落地”，Graph-RAG 侧重“知识融合”
-
Agentic-RAG
- 优势：
- 高精度地紧贴当前版本的 NCCN 指南，自动检索并多轮校验，很适合对特定病种的临床应用，要求“零容忍”错误的场景。
- 流程简单直接，医生也能快速理解其来源：就是从最新的 NCCN PDF/JSON 里查的。
- 局限：
- 如果要扩展到更多病种、更多文献，Prompt 设计与检索流程会更复杂，性能和维护成本都会增加。
- 不擅长做跨多个数据库或多文献整合下的复杂查询。
- 优势：
-
Graph-RAG
- 优势：
- 可视化：对指南内容和其他多源数据进行统一管理，便于医生、数据分析员等用图结构去探索新的关联或做科研分析。
- 可扩展：随着指南或其他医学知识的增加，图数据库可以不断演化，做个性化知识的增量更新。
- 适合一对多或多对多的复杂问题：尤其是跨多个指南、多个学科的信息汇总与推理。
- 局限：
- 需要做实体与关系抽取，这本身存在一定的技术挑战和“抽取精度”瓶颈；一旦漏掉某些节点，就可能影响最终答案的完整性。
- 如果未设置专门的多轮审查机制，对特定病种的推荐准确率难以达到 “Agentic-RAG” 那样的 100%。
- 优势：
“为什么还要 Graph-RAG？”——核心答案：
- 知识图谱天生适合多源知识管理和可视化
- 对接大规模异构数据、支撑跨学科复杂分析时，Graph-RAG 更具优势。
- Agentic-RAG 与 Graph-RAG 并不互斥
- 在特定病种、单一指南的“方案生成”场景，Agentic-RAG 可能是最简单、最直接、最精准的选择。
- 但在实际临床或研究中，一旦场景变得复杂，需要兼容多种数据来源、做更多层次的逻辑推理或溯源时，Graph-RAG 架构能更好地进行扩展和可视化管理。
- Graph-RAG 还能为其他应用提供多跳搜索与关联分析
- 不仅能回答“给定病种如何治疗”，还可以更灵活地回答“这个患者在做完手术后，如果出现某些并发症，接下来各选项利弊如何”之类的多步查询。
所以，是否只用 Agentic-RAG，要看具体需求：
- 如果目标只是“让医生快速获得最新 NCCN 推荐的个性化治疗”，Agentic-RAG 确实够用了；
- 如果目标是“将 NCCN 指南与更多多源医学知识、真实世界数据整合到同一平台，再进行深入挖掘或高级推理”，那么 Graph-RAG 的知识图谱方法就不可或缺。
Agent 垂直技术社区，欢迎活跃、内容共建。
更多推荐
54
0- 0
已为社区贡献70条内容
所有评论(0)