医疗RAG落地：知识治理、检索路径与评测指标

一次看似普通的宠物就诊预约，却因信息模糊、知识断层和系统割裂演变为医疗风险事件。本文从动物医院接诊场景切入，深入拆解RAG在医疗AI产品中的落地路径：如何将个人经验转化为机构知识，如何为三类信息设计不同检索路径，以及为何流程治理比模型选型更优先。

在一家动物医院，前台曾接到一位宠物主人的电话。对方只说：“小猫不正常，想来医院检查一下心脏。”

这句话听起来像一次普通预约。但电话另一端，猫无法描述自己的感受，主人也不一定知道哪些变化值得特别说明；电话这一端，前台没有书面的问询表、急症清单或转诊目录，主要依靠过去接电话积累的经验。医生正在做手术，无法立即沟通，前台于是安排了普通就诊。

猫到院以后，医生判断它的情况已经非常危重，而这家以外科为主的医院又不擅长相应治疗。一次看似普通的预约，突然变成了医疗风险、责任压力和内部争议。

我们不能因此直接判断宠物主人“疏于照顾”。猫可能长期隐藏不适，ACVIM 猫心肌病共识也指出，部分心肌病可能处于亚临床阶段。电话中的一句“不正常”，很难自动变成一份完整病史。

值得产品经理追问的是：如果为动物医院设计一款 AI 产品，它应该怎样把这种模糊描述变成有用信息？把医院资料接入知识库就够了吗？

这里会用到 RAG。RAG（Retrieval-Augmented Generation，检索增强生成）简单来说，就是让 AI 在回答前，先从指定的医院制度、患者资料或外部医学证据中寻找依据，再根据检索结果生成回答。

但 RAG 不是把文件放进向量数据库，再接一个聊天框。动物医院做 RAG，应该先厘清 AI 介入哪段流程、谁为结果负责，再把个人经验整理成经过审核的机构知识，随后为医院制度、患者病历和外部医学证据设计不同的检索路径，最后用真实失败案例评测效果。只有普通 RAG 持续无法解决稳定的多跳问题时，才需要考虑 GraphRAG。

一、一次危重猫接诊，暴露的不是搜索问题

如果只看表面，这家医院似乎缺一个更方便的搜索框。前台需要知道怎样问，医生需要在休息时调取病历，把文件统一放进知识库，看起来就能解决问题。

但把接诊过程拆开以后，会看到三个不同的断点。

第一个是输入断点。宠物主人使用的是生活语言，而不是病历语言。“不正常”“没精神”“想查一下心脏”都缺少足够信息。AI 可以帮助整理这些表达，却不能假装原始信息已经完整，更不能从一句话直接推导出诊断。

第二个是知识断点。医院没有经过审核的来电问询协议、危险信号清单和接诊能力目录。前台知道什么，主要取决于做了多久、遇到过什么情况，以及记住了哪位医生的要求。经验可能有价值，但它仍然是个人经验，不是已经确认、可以统一执行的机构知识。如果此时直接做 RAG，系统检索到的只会是未经审核、可能彼此冲突的说法。

第三个是系统断点。宠物档案、挂号和就诊记录保存在传统 SaaS 中，DR 影像位于另一套院内系统，血液和尿液检验报告的纸质版则放在档案室。前台既要在 SaaS 里查询，也可能要根据主人的需求去档案室翻找。医生在家无法远程登录时，只能给医院打电话，请在院员工代为调取。

这个问题不只是“检索精度不够”，而是信息采集、知识责任和系统连接同时断裂。RAG 能从已有资料中找内容，却不能替医院决定哪些问题必须问、什么情况应该升级、医院能够接什么病例，以及谁为规则负责。

《动物诊疗机构管理办法》规定，动物诊疗活动不得超出许可证核定的范围。对产品而言，更稳妥的做法是建立本院可核验的能力目录，而不是根据“动物医院”“全科”等名称推断它能处理什么病例。

这也是医疗 AI 产品容易踩的第一个坑：把一个流程和治理问题，误判成一个模型问题。

二、先确定 AI 介入哪段流程

如果第一版产品只是在前台接电话时弹出几条问题，它只能缓解一个局部动作。更重要的是，AI 能否改变信息如何进入流程、怎样流向下一个角色，以及处理结果能否沉淀回来。

对这个场景，我更愿意把产品定义为“单院内部 AI 临床运营助手”，而不是“前台问诊机器人”。第一版只验证一条完整链路：

宠主来电 → AI 转写并整理描述 → 按审核协议动态追问 → 匹配患者身份 → 检索本院能力和必要历史 → 提示风险 → 转交护士或医生 → 生成接诊摘要 → 就诊后更新记录

在这条链路中，AI 首先保留宠物主人的原话，再把已知信息和缺失信息分开。例如，系统可以识别出“宠物种类已知，但当前状态、变化时间和需要升级判断的信息不足”，然后从医院已经批准的问询协议中选择下一步问题。它不能自行编写一套医学问询，也不能用模型常识补上主人没有说过的症状。

如果问询触发了医院预先定义的危险条件，或者始终无法取得足够信息，系统不继续给出“是否可以预约”的确定答案，而是优先转给护士或医生。转交时，医护人员看到的不是一句“主人说猫不舒服”，而是一份结构化摘要：主人原话是什么、已经问了什么、哪些信息仍然缺失、为什么升级，以及是否存在既往记录。

如果是复诊患者，系统可以在确认患者身份后调取有限的历史资料；如果是新患者，则只使用本院流程和接诊能力，不能假装存在个体病史。医生接手以后作出的判断和修改，也应该回到记录中，成为下一轮评测和知识更新的依据。

这里需要把四种能力分开：

• LLM负责理解口语、整理信息、改写检索问题和生成交接摘要；
• RAG负责从经过许可的范围中找出医院制度、患者资料或外部证据；
• 规则系统负责危险条件、必问项、权限和升级路径；
• 医护人员负责临床判断、处理冲突和承担最终诊疗责任。

Heidi Health 的公开资料提供了一个可参考的工作流。其产品说明显示，Heidi 可以转录会诊、按模板生成记录，并把检查结果、转诊信等资料作为上下文；患者资料说明则明确把 EHR 作为患者记录的系统真源。这个案例能帮助我们理解医疗 AI 怎样组织上下文和审核，但不能据此推断 Heidi 使用了某种特定 RAG，更不能直接说它采用了 GraphRAG。

比起猜测一款产品的底层架构，先把自己的工作流和责任边界画清楚，更有产品价值。

三、做 RAG 前，先让医院知识变得可用

通用 RAG 文章常从数据清洗、分块、嵌入模型和向量数据库讲起。但在动物医院，优先级还要再往前移一步：哪些内容有资格成为系统知识？

AAHA 分享的电话分流案例提供了一种可参考的做法：先收集团队最常遇到的来电问题，结合医生意见建立分流算法，再培训并测试员工。它不是国内强制规范，但这个流程思路放进 AI 产品仍然成立：前台经验可以成为知识素材，在兽医审核前却不能直接成为系统给出的正式依据。

一套最小治理流程可以这样建立：先整理高频来电、严重漏判、过度升级和资料找不到的案例；由执业兽医审核追问项、危险条件和升级要求；由护士验证这些步骤在忙碌场景下是否可执行；再由负责人确认本院接诊范围、设备能力和无法接诊时的处理原则。规则发布后，还要记录版本、审核人、生效时间和复审时间。

如果把这套治理逻辑画出来，一条知识在进入系统前，至少要过四道门：它从哪里来、适用于谁、谁批准，以及出错时怎么办。

在医疗场景里，“版本、审核人、适用范围”往往比 chunk size 更早决定系统是否可靠。一段文字即使语义相关，也可能已经过期；一份外部指南即使权威，也不能证明本院具备相应接诊能力；一条老员工经验即使多次有效，也不等于已经成为所有员工都可执行的制度。

数据治理还包括患者身份和个人信息。《动物诊疗机构管理办法》将诊疗中形成的文字、图表、影像等纳入病历，也明确电子病历与纸质病历具有同等效力。这说明统一索引多种载体具有现实价值，但“可以索引”不等于“可以无边界复制”。宠物主人的姓名、电话等仍属于自然人个人信息。依据《个人信息保护法》，产品需要明确处理目的、控制最小访问范围，并设计访问记录、保存与删除机制；具体落地仍需结合实际业务做合规审查。

因此，动物医院 RAG 的第一张架构图不该只有“文档—Embedding—向量库—LLM”，还应该画出“知识来源—责任人—审核状态—权限—检索路径—人工升级”。前一张图解释技术怎样运行，后一张图才解释医院为什么能够信任它。

四、三类知识，需要三条检索路径

完成知识治理以后，才进入 RAG 选型。此时最重要的选择不是使用哪一个向量数据库，而是不要把机构知识、患者资料和外部医学证据混成一个索引、一个权限和一种回答逻辑。

1. 机构知识：关键词和语义检索一起用

本院制度和能力目录包含两类表达。一类是设备名、科室名、药名、医生和固定术语，关键词匹配更容易准确命中；另一类是宠物主人的口语，比如“想查一下心脏”或“今天和平时不一样”，需要语义检索帮助理解表达变体。

因此，第一版可以采用关键词检索与向量检索结合的混合方式。检索前先用物种、使用角色、风险等级、版本和生效状态做元数据过滤，再对候选结果重排，最后只把最相关、仍有效的少量内容交给 LLM。查询改写可以使用，但必须同时保留主人原话，防止改写过程中把“不确定”变成确定症状。

至于嵌入微调、复杂的查询扩展或底层参数优化，都应该等基础评测集建立以后再决定。没有评测基线时，很难证明复杂方案究竟解决了什么。

2. 患者资料：先确认身份，再按时间线检索

病历检索最大的风险不只是“没找到”，还有“找到了另一只宠物的资料”。同名宠物、主人联系方式变化、多人共同照顾一只宠物，都可能使模糊匹配出错。因此，患者 RAG 必须先确定患者身份和访问权限，再进入搜索。患者 ID、主人信息、就诊日期和资料类型等结构化字段，应当优先于向量相似度。

对已经确认身份的患者，可以先按时间线调取挂号、就诊、用药和检查索引，再用语义检索补充寻找散落在病历文本中的描述。纸质检验报告经过 OCR 后，需要保存原件位置、识别版本和人工复核状态。DR 系统在第一版也不必直接做“多模态影像诊断”：先索引检查日期、报告文本和原始影像链接，让医生能够快速回到真源，通常更可控。

这条路径的首要指标不是回答是否流畅，而是患者错配率、关键资料 Recall@K、调取时间和来源可追溯性。患者身份不确定时，系统应当停止，而不是选择一个“最相似”的结果。

3. 外部医学证据：独立索引，并限制在医护端

外部指南、共识、药物资料和同行评审文献可以帮助医生核验治疗、禁忌和诊断信息，但它们与本院政策不是一回事。外部证据回答“专业资料怎么说”，机构知识回答“本院怎么做、能不能做”。如果两者混在一个索引中，LLM 很容易把通用建议写成本院承诺。

因此，外部医学知识应使用独立索引、独立权限和更严格的来源策略。回答需要显示文献或指南版本，并把引用放在对应陈述附近；找不到足够证据、来源冲突或超出知识范围时，要明确拒答或请求医生核验。

把一次来电放在起点，会更容易看清三类知识为什么要走不同的检索路径：

模型选择也应该服从所在步骤，而不是照着“最强模型排行榜”购买。来电阶段更看重中文口语理解、低延迟和稳定的结构化输出；医生查看外部证据时，更看重长文本整合、引用对齐、冲突识别和拒答能力。两条链路未必需要同一个模型。更大的上下文窗口也不能替代准确的患者、时间和资料类型过滤。

同样，如果系统的问题来自患者 ID 错配、知识过期或根本没有 SOP，微调 LLM 也不会修复这些基础缺陷。第一版应先通过提示、工具、检索和规则建立可测基线，再决定是否需要更复杂的模型方案。

五、什么时候才需要 GraphRAG？

GraphRAG 的吸引力很容易理解。医疗知识存在大量关系：疾病与症状、药物与禁忌、患者与多次就诊、检查与治疗之间都不是孤立文本。既然关系复杂，图检索听起来似乎天然更适合医疗。

但“领域知识复杂”和“当前问题需要图”不是同一件事。

微软 GraphRAG 官方资料把查询分为 Local、Global、DRIFT 等方式。其中，全局搜索会在系统生成的社区报告上进行搜索，适合回答需要理解整个数据集的综合性问题，但资源消耗也更高。当前 MVP 的主要问题——“本院能否接诊”“这只宠物过去做过什么检查”“哪一版问询规则有效”——都有清晰的机构、患者和时间过滤条件。结构化查询、混合检索和重排序更容易实现，也更容易定位错误。

GraphRAG 还会增加一种新的风险：图本身可能错。实体抽取错误、两只同名宠物被合并、药物与禁忌关系版本过期，都可能让系统获得一种“结构化但错误”的确定感。在高风险场景里，架构越复杂，越需要证明每一层带来的收益。

因此，GraphRAG 至少应该通过四道门再进入方案：

• 医院已经收集到稳定、重复出现的多跳真实问题；
• 普通混合 RAG 在这些问题上持续失败；
• 实体和关系的构建质量可以被人工抽查和量化；
• 准确性提升足以抵消成本、延迟和维护负担。

未来确实可能出现适合图的场景，例如跨多年追踪“药物—症状—检验异常—治疗调整”的关系，跨大量脱敏病例分析术后并发症模式，或者在医护端连接疾病、物种、药物禁忌与指南版本。但这些能力需要由真实问题来证明，不能因为场景属于“医疗”，就默认第一版必须采用 GraphRAG。

六、怎么判断这套 RAG 可以进入真实接诊流程？

技术方案最终要回到指标。医疗 RAG 不能只有一个总体“准确率”，因为平均数很容易掩盖真正危险的错误。

例如，普通来电远多于真正紧急的来电时，一个系统即使几乎都判断为“普通”，总体准确率仍可能看起来不错，但它恰好漏掉了产品最不能漏掉的少数情况。因此，严重病例漏判率必须单列，不能被平均数稀释。

一套可执行的评测可以分成三层。

第一层是检索：看 Recall@K、Precision@K、首个正确结果出现的位置，以及患者错配率。Recall 高但 Precision 很低，意味着关键资料可能找到了，却被大量噪声包围；Precision 高但 Recall 低，则可能只找到一小部分看似准确的资料，遗漏真正决定判断的内容。

第二层是生成和证据：看答案正确性、忠实度、引用正确率与引用覆盖率。答案正确性判断最终内容是否正确；忠实度判断每个陈述是否真的来自检索上下文；引用正确率判断链接是否支持旁边的说法；拒答正确率则衡量资料不足或冲突时，模型有没有停下来。

第三层是实际工作流：看危险病例召回率、漏判率、过度升级率、必问信息完整率、从来电到医护接手的时间、重复询问次数和医护修改率。MVP 阶段可以优先保证危险病例召回，允许多升级一些模糊来电，再由护士二次确认提高精度。但这不意味着“越多升级越好”，否则产品只是把原来的医生瓶颈换成护士瓶颈。

评测集也不能只由模型自动生成。更合适的材料来自真实失败：脱敏后的历史来电、曾经漏判的严重情况、不必要升级、患者资料找错或找不到，以及医护对 AI 摘要的修改记录。由兽医标注风险结果、必须问到的信息和所需证据；存在争议的案例可以保留分歧，不必强行制造唯一标准答案。

上线过程可以分四步：先离线回放历史案例；再进入影子模式，让系统给出提示但不影响真实决定；随后在限定人员和时段中试点；最后才依据持续监测扩大范围。RAGAS等自动评测方法适合做版本回归，但不能替代兽医对高风险漏判、证据支持和真实流程的审核。

这一点也得到当前研究的提醒。2026 年 JMIR 对 157 项医疗 RAG 和 GraphRAG 研究的综述发现，只有 29.9% 的研究独立评估了检索层，14% 做了细粒度证据验证，28.7% 报告了正式安全评估。一个系统在离线问答中表现不错，不等于它已经证明可以进入真实医疗工作流。

结语：先让技术知道什么时候应该停下来

AI 无法让猫开口，也不应该替医生作出诊断。它能够改变的，是不再让一句“小猫不正常”停留在前台个人经验里：通过经过审核的追问协议收集信息，通过机构知识判断本院能力，通过患者限定检索补充历史，再把风险和缺失项交给能够负责的人。

动物医院做 RAG 的第一步，不是选择 GraphRAG，也不是换一个更大的 LLM，而是先回答四个问题：什么知识有效，适用于谁，谁审核，错了交给谁。

接下来的顺序才是技术：先建立失败案例集和知识管理表，再做混合检索与重排序基线，分开评估检索、生成和医疗安全；最后，如果真实的多跳问题仍然无法解决，再让 GraphRAG 进入同一套评测做对照。

医疗垂直产品的专业性，不来自采用了多少技术，而来自它是否知道什么时候不应该继续回答。

参考资料：

• ACVIM 猫心肌病分类、诊断与管理共识
• AAHA：动物医院电话分流的培训与算法案例
• Heidi Health：产品与工作方式
• Heidi Health：患者资料与 EHR 关系
• 微软 GraphRAG 查询方式概览
• JMIR：医疗 RAG 与 GraphRAG 评测方法综述
• RAGAS：RAG 分层自动评测框架
• 农业农村部《动物诊疗机构管理办法》
• 《中华人民共和国个人信息保护法》

本文由 @Molly 原创发布于人人都是产品经理。未经作者许可，禁止转载

题图来自Unsplash，基于CC0协议