简介：本文围绕临床问答场景，系统对比"基于临床结构化编码的相似性检索"与"基于文本语义的相似性检索"两种检索增强生成（RAG）范式。读者将了解两者在检索信号、召回精度、适用场景、接入成本等维度的核心差异，并获取面向出院问答等高敏感医疗场景的选型建议与迁移注意事项。
在大语言模型（LLM）驱动的临床问答系统中，检索增强生成（RAG）已成为确保回答事实准确性的主流技术路径。然而，一个长期被忽视的问题是：当系统面对大量出院记录、病历文本时，”应该用什么作为检索信号”这件事本身，就可能成为决定回答质量的关键变量。
传统做法往往将”全文语义相似度”作为唯一或主要的检索入口——给定一个临床问题，系统计算该问题与所有历史病历文本的向量相似度，取出排名靠前的片段送入生成模型。这种做法直观、实现门槛低，但在临床场景中暴露出一个根本缺陷：共同措辞、记录模板、格式化用语会严重干扰检索结果，使得”文本上看起来像”与”病情上真正接近”之间产生错位。
近年来，有研究团队提出一种新思路：先用诊断编码、药物编码、操作编码等结构化信息计算患者间的临床相似性，锁定真正可比的病例；再从这些病例的文本中按问题相关性提取证据片段。这一”两阶段检索”策略将检索增强的逻辑从”找相似文本”转向”找相似患者、再找相关证据”。
本文将围绕这两种范式——方案A：以文本语义相似度为核心的传统RAG检索 与 方案B：以临床结构化编码驱动的两阶段经验检索——展开系统对比，帮助技术负责人和架构师在医疗AI、知识密集型RAG等场景中做出更精准的选型决策。
核心思路：将所有病历文本进行向量化编码（如通过通用或领域预训练的文本编码器），在给定临床问题时，通过向量最近邻搜索（ANN）或类似机制，找出与问题语义最接近的文本片段，作为生成模型的上下文。
解决的问题：快速为LLM提供与问题”话题相关”的参考资料，降低幻觉风险。
典型实现：
# 伪代码示意：传统RAG检索流程def retrieve_by_text_similarity(query, corpus):query_vec = encoder.encode(query)# 对所有文档片段进行向量检索top_k = ann_index.search(query_vec, k=5)return top_k # 返回最相似的文本片段
核心思路：首先利用患者的诊断编码、药物编码、操作编码等结构化信息，计算患者之间的临床可比性（而非文本表面的相似度），筛选出一组”临床相近”的病例；然后在这些病例的文本中，针对具体问题进行细粒度的相关片段检索。
解决的问题：避免模板化文本误导检索，确保参考经验来自病情真正可比的患者。
典型实现：
# 伪代码示意：两阶段检索流程def retrieve_by_clinical_similarity(query, patient_records):# 阶段一：结构化编码匹配，筛选相似患者structured_features = extract_codes(patient_records) # 诊断/药物/操作编码similar_patients = rank_by_structured_similarity(query_codes, structured_features, top_k=10)# 阶段二：在相似患者的文本中检索与问题相关的片段relevant_snippets = []for pid in similar_patients:snippets = fine_grained_search(query, patient_records[pid].text)relevant_snippets.extend(snippets)return relevant_snippets
尽管两者在检索信号和流程设计上存在根本差异，但作为RAG体系下的子方案，它们共享以下基础特征：
| 维度 | 说明 |
|---|---|
| 目标一致 | 都是为LLM生成提供事实性、可追溯的外部知识，降低模型幻觉 |
| 依赖外部知识库 | 都需要预先构建、维护和更新的语料库（病历库、文献库等） |
| 生成环节相同 | 检索到的上下文最终都送入同一类生成模型进行回答合成 |
| 面临通用挑战 | 数据隐私、知识时效性、多源异构数据对齐等问题两者均需面对 |
| 可组合使用 | 在实际系统中，两者并非互斥，可以作为互补层级共存 |
这是两者最本质的区别。
方案A 以文本向量的余弦相似度或其他距离度量作为排序依据。优点是不依赖额外的标注和编码体系，接入快；缺点是对模板化、格式化程度高的文本极度敏感——两份病情完全不同但使用相同模板的出院报告，可能被判定为”高度相似”。
方案B 以诊断编码、药物编码、操作编码等结构化字段的重叠度或加权距离作为患者相似性的衡量标准。这要求语料库具备完善的编码体系（如国际通用的疾病分类编码、药物编码等），但能够有效绕开文本表层的干扰，聚焦于”这个患者得了什么病、用了什么药、做了什么操作”这一临床核心。
技术影响：方案A的检索质量高度依赖编码器的领域适应能力；方案B的检索质量依赖编码体系的覆盖度和编码质量。
| 维度 | 方案A（文本语义RAG） | 方案B（两阶段经验RAG） |
|---|---|---|
| 检索阶段 | 单阶段：问题→文本片段 | 两阶段：问题→相似患者→相关片段 |
| 排序依据 | 文本向量相似度 | 阶段一：编码相似度；阶段二：问题-片段相关性 |
| 系统复杂度 | 较低，单一索引即可 | 较高，需维护结构化索引+文本索引双套体系 |
| 可解释性 | 较弱，难以说明”为什么选这段” | 较强，可追溯到具体患者及其编码特征 |
两阶段设计的代价是系统复杂度和维护成本上升——需要对每份病历进行结构化信息抽取与存储，需要维护两套索引（结构化索引+文本索引），且两阶段之间的衔接逻辑需要精细调优。但收益是：第一阶段的”粗排”保证了病例可比性，第二阶段的”细排”保证了与当前问题的相关性，两者互为补充。
方案A 在”通用概念性问题”上表现尚可，例如”某疾病的常见并发症有哪些”，因为这类问题本身不依赖具体患者的个性化经验。
方案B 在”个性化、情境化问题”上优势明显，例如”这位合并糖尿病和心衰的患者出院后应该如何调整用药”，因为答案高度依赖于与当前患者病情可比的既往经验，而非泛泛的医学知识。
| 维度 | 方案A | 方案B |
|---|---|---|
| 数据预处理 | 文本清洗+分块+向量化 | 文本清洗+分块+向量化 + 结构化编码抽取与对齐 |
| 编码体系依赖 | 无 | 强依赖，需要标准化的诊断/药物/操作编码 |
| 冷启动成本 | 较低，有文本即可 | 较高，需先完成编码映射和质量校验 |
| 持续维护 | 更新文本索引 | 更新文本索引 + 同步更新编码信息 |
两者在数据安全层面面临类似挑战：病历数据属于高敏感信息，检索过程中的数据暴露面、访问控制、审计日志都需要严格设计。但方案B因涉及更细粒度的患者级信息（编码组合可间接标识患者），在数据脱敏和访问控制上需要更精细的策略。例如，在检索阶段就应对患者标识信息进行脱敏处理，避免编码组合本身成为重标识风险。
| 场景 | 推荐方案 | 理由 |
|---|---|---|
| 通用医学科普问答 | 方案A | 不需要患者级个性化经验，文本语义匹配足以覆盖 |
| 出院指导个性化问答 | 方案B | 需要参考相似患者的具体出院安排和用药经验 |
| 诊断辅助（鉴别诊断） | 方案B优先 | 需基于可比病例的症状组合和检查结果进行推理 |
| 快速原型验证/PoC | 方案A | 接入快、改造成本低，适合早期探索 |
| 生产级临床决策支持 | 方案B或A+B混合 | 对准确性和可追溯性要求高，建议两阶段或混合架构 |
如果团队资源有限、数据以自由文本为主且缺乏结构化编码体系：建议从方案A起步，快速验证RAG链路的可行性，后续再逐步引入结构化编码层。
如果业务目标是高敏感的临床决策支持（如出院问答、用药建议）：方案B的两阶段设计更能保证检索到的经验与当前患者真正可比，但需要投入更多工程资源建设编码体系和双索引架构。
如果已有百度智能云等平台提供的医疗知识图谱或结构化数据服务：可借助平台能力降低编码抽取和对齐的门槛，加速方案B的落地。
不建议在无评估基准的情况下直接切换：方案B的优势需要在类似DISCHARGEQA这样的多任务、有迷惑候选项的基准上才能充分体现，盲目切换可能因编码质量不佳而适得其反。
若从方案A迁移到方案B（或引入混合架构），需重点关注以下方面：
“以文本相似性还是以临床相似性作为检索信号”，本质上是在问：RAG系统应该优先匹配”说了什么”还是”得了什么病”。在通用场景下，文本语义匹配是高性价比的默认选择；但在出院问答、个性化用药指导等需要情境化经验的高敏感临床场景中，基于结构化编码的两阶段检索能够提供更可靠的召回信号。
两者并非对立关系，而是互补关系。实际系统设计中，可以将方案B作为高精度的主力检索路径，同时保留方案A作为兜底或快速召回通道，形成”结构化粗排+语义补充”的混合架构。选型的核心判断依据是：业务对”答案必须来自真正可比的患者经验”这一要求的严格程度，以及团队在编码体系建设和双索引运维上的资源投入能力。