企业官网建设流程全解析

去年做医疗垂直场景的RAG项目时，我把版本号定到了21.7，这个数字不是随便起的——从第一版能用但经常答非所问的检索问答，到后面医生愿意在病历辅助场景里点开引用链接核对原文，前后改了21个小版本。回头看，医疗领域的RAG跟通用域RAG完全不是一回事，通用域里"差不多能用"的方案，放到医疗场景直接暴露出各种问题：分段切碎了诊断标准、检索召回了语义相似但医学上完全无关的内容、重排模型把FAQ答案排在指南原文前面。这篇就完整复盘一下我在这个项目里从知识分段、混合检索、重排到溯源的全链路调优过程，讲清楚每一步为什么这么改、踩过什么坑、实测数据变化如何。

这篇文章适合正在做医疗、法律、金融等专业领域RAG的工程师，也适合刚接触RAG、想理解"文档进去之后到底经过哪些环节才能得到一个可用的答案"的学习者。我会把参数、方案、取舍理由都摊开讲。

1. 医疗RAG为什么不能直接套通用方案：先理解这个场景的约束

很多人第一次做医疗RAG时，会直接拿LangChain或者LlamaIndex的默认配置跑通一个Demo，然后发现效果一言难尽。这不是代码写得不对，而是通用RAG的设计假设在医疗场景下根本不成立。

1.1 通用RAG的三个隐含假设，在医疗里全部失效

• 隐含假设一：用户查询和文档内容是"语义相似"就能匹配。通用域里"怎么让咖啡不苦"和"手冲咖啡萃取过度的表现"确实语义相关，能检索到。但医疗场景里，"胸痛"和"心肌梗死"的语义相似度未必比"胸痛"和"带状疱疹"高，因为医学概念之间存在大量"表面相似、实质无关"和"表面不同、实质强相关"的情况。"阿司匹林"和"华法林"在向量空间里的距离，取决于它们在语料里共现的频率，而不取决于它们的药理相互作用关系。这就导致纯向量检索在医疗场景经常出现"召回了一堆看起来相关、实际上没用"的片段。

• 隐含假设二：文档是相对均匀的自然语言文本。通用RAG的知识库大多是博客、文章、报告，句子结构接近。医疗文档完全不同：诊疗指南里有大量"推荐级别A，证据等级I"这种结构化标签；药品说明书里有表格、剂量区间、禁忌症列表；临床路径里有决策树。这些内容如果按照通用分段器一刀切，后果非常严重——可能把"推荐剂量为每次10mg"和"每日不超过3次"切到两个chunk里，检索时只召回前者，AI就会给出一个片面、甚至危险的答案。

• 隐含假设三：答案错了没有物理伤害。通用域里答错一道菜谱，用户最多觉得难吃。医疗场景里，如果面向患者端的问答把用药频次答错，或者没有召回"禁忌症"段落，直接推荐了某类药物，这已经不只是体验问题。所以医疗RAG在系统设计上就要求"宁可不说，不可说错"——检索结果不足时，应当拒绝回答，而不是硬生成一个看起来通顺的答案。

1.2 医疗知识库的权威性分层，决定了召回策略必须区别对待

同样一句话"降糖药应该饭前吃还是饭后吃"，来源不同，可信度完全不同。我在项目里把知识来源分了四档：

这个分层在检索阶段就要起作用，不能等到重排才处理。因为纯语义检索会公平对待所有文档，而医疗场景必须让指南原文在排序上天然占优。具体做法是在chunk的元数据里写入authority_level字段，混合检索后的融合分数里赋予权重系数。这一点贯穿整个链路，后面几节都会提到。

1.3 查询结构的特殊性：短查询背后是长长的上下文

医生的真实查询通常很短，比如"这个病人能用这个药吗"——但完整的问题是："65岁男性，糖尿病肾病3期，eGFR 45，目前用二甲双胍，新诊断心力衰竭，能用SGLT2抑制剂吗？"通用RAG无法处理这种隐含的多约束条件。所以医疗RAG项目一般会加一层query理解模块，先做命名实体识别和约束条件抽取，把短查询扩展成多个检索子查询。实测下来，加入query扩展后，检索的Recall@20从0.61涨到0.78，涨幅非常可观。这部分不是本次调优的核心，但它是后面所有检索工作的基础，值得先提一句。

2. 知识分段：医疗文本的边界到底在哪里

知识分段是RAG里最容易被低估的一环。很多人觉得分段就是"按字数切一切"，但医疗场景里，分段直接决定了AI能拿到多少有效上下文，也决定了检索命中的精确性。

2.1 为什么固定chunk_size在医疗场景不靠谱

我一开始用的是通用方案：固定chunk_size=512，overlap=50。结果跑了一批测试问题，发现两个典型问题：一是把指南里的"推荐意见"和它的"证据说明"切开，导致AI只知道结论、不知道理由；二是表格被拦腰截断，"用药频次"和"用药剂量"分开，检索"每天吃几次"时，召回的是剂量段落，答案错得离谱。

后来我把策略调整为"结构优先、语义兜底"。先解析文档的结构骨架，再决定从哪里切、切多长。医疗文档通常有清晰的层级结构，PDF转Markdown之后，标题级别的层次就是天然的分段边界。指南里的"一、二、三"通常是独立章节，章节下的"（一）（二）"是语义单元，再往下是具体条目。

以实际项目里的一份高血压诊疗指南为例，它的结构是：

• 1级标题：治疗原则
• 2级标题：降压药物选择
• 3级标题：联合用药方案
• 段落内包含：药物名称、剂量范围、证据等级标签

我设定的分段规则是：以2级或3级标题为边界，不跨标题切分；如果标题下的内容太长（超过模型上下文可接受的范围），再在段落边界处按语义单元切分，同时保留证据等级标签。这样每个chunk几乎都是完整语义块。

2.2 医学文本的"语义边界"识别：三类特殊块必须整块保留

除了标题层级，医疗文档里还有三类特殊内容，分段时必须特殊处理，甚至需要让它们成为独立的chunk类型：

表格块。药品说明书里的用法用量表、相互作用表、儿童剂量折算表，这类内容是问答的高频命中区。解析时先把表格转为Markdown表格，然后通过表头和表体拼接，生成一段完整描述。比如"剂量单位"和"肾功能不全调整"必须在同一个chunk里。我在解析层单独识别表格区域，给它们打上content_type=table的标签，并生成一个语义化的表格摘要文本，比如"【表】老年高血压患者初始降压药物剂量推荐"。

临床试验/统计结果块。指南里经常出现"某研究结果显示，干预组较对照组心血管事件风险降低19%（HR 0.81，95%CI 0.72-0.91）"。这类句子必须与它的上下文（研究对象、用药方案、随访时间）放在一起，不能拆开。前后拆开的后果是检索到"风险降低19%"这个结论，却没有研究对象，AI回答时就会张冠李戴。

禁忌症与注意事项块。这个名字看起来像模块，其实在很多指南里，禁忌症是以列表形式散落在各个段落中。我在预处理时做了一次规则扫描，把"下列患者禁用""不应用于""需慎用"等句式出现的位置标注出来，确保以这些句子为中心的上下文被完整保留。医疗问答里，禁忌症召回的重要性高于有效性内容的召回，因为漏掉禁忌症导致的误答，后果严重得多。

2.3 切分参数实测：我给21.7版本最终定的取值

在结构优先的前提下，参数仍然不是固定的。我统计了项目里所有文档的段落长度分布，最终把参数定成这样：

这个配置跑下来，chunk总数比固定512切分少了约18%，但每个chunk的语义密度明显提高。一个直观的验证方法是：随机抽300个chunk让医生标注"这个片段是否完整表达一个可引用的医学结论"，完整率从固定切分的62%提升到91%。

关于分段还有一个容易被忽略的细节：药品别名和术语缩写需要在分段后做索引扩展。比如说明书里写"卡托普利"，医生提问时可能写"开博通"（商品名），或者"ACEI类药物"。我在分段后的后处理步骤里，对每个chunk生成一份扩展关键词表，挂在chunk的metadata上，检索阶段这些关键词会参与BM25字段加权。后面混合检索部分会详细讲。

3. 混合检索：关键词、向量和结构化约束怎么融合

经典的RAG教程通常会告诉你用embedding做相似度检索就够了，但对于医疗场景，只做向量检索等于只看语义不看关键字，结果就是专业检索完全跑偏。我在21.7版本里最终使用了三路召回：BM25关键词召回、向量召回、结构化字段召回，再用RRF做融合排序。

3.1 为什么单靠向量召回在医疗场景不够用

向量召回擅长语义匹配，但医疗领域有大量必须精确匹配的信息：药品商品名、检查项目缩写、ICD编码、指南编号。"阿司匹林肠溶片"和"拜阿司匹灵"在向量空间里可能很近，但"COPD"和"慢性阻塞性肺疾病"这种缩写与全称的关系、或者说"ACS"到底是"急性冠脉综合征"还是"血管紧张素转换酶抑制剂"的缩写（实际ACEI才是），向量模型经常搞混。

更关键的是，医疗文档里很多信息的区分依赖的是精确词而不是语义。比如一个副作用是"肝功能异常"，另一个是"肾功能异常"，语义词只有"肝"和"肾"的区别，embedding对这两个中文汉字的区分能力是有限的，向量检索会把很多"异常"内容一起召回来。而BM25可以精确命中"肝功能"这个词，保证这类召回不丢。

3.2 三路召回的具体设计

第一路：BM25关键词召回。我对输入查询做了分词和术语增强，比如"高血压"扩展为["高血压", "hypertension", "血压升高", "降压"]，药品名扩展为通用名+商品名。BM25在每个术语字段上检索，取Top 50。

第二路：向量召回。使用中文医疗预训练embedding模型，对查询和chunk都做向量化，取Top 50。

第三路：结构化字段召回。这是很多人忽略的一路。我在分段阶段就把chunk的元数据抽出来，包括：

• 所属疾病领域（心血管、呼吸、内分泌等）
• 来源类型（指南、说明书、教材、科普）
• 适用人群（成人、儿童、孕妇、老年人）
• 权威等级（L1-L4）

查询进来之后，先做一次实体识别和意图判断，把它映射到这几个维度上。比如问题里带"儿童"，直接过滤掉含"成人"标签的chunk；问题里提到某药，把来源类型限定为"药品说明书"并把权威等级L1/L2优先。这路召回的候选集很小，但精度极高，通常一次只返回10-20个，却能把前面两路可能漏掉的关键信息拉回来。

3.3 融合排序：RRF的实现细节与参数

三路召回的结果如何合并？我测试过两种方案：加权分数融合和RRF（倒数排名融合）。

加权分数融合在做之前必须解决"分数归一化"的问题。BM25的分数范围从几到几十，向量cosine相似度范围是-1到1，直接把两个分数相加是不科学的。我早期这么做过一次，结果向量召回的分数几乎被BM25分数淹没，效果等于只有BM25一路。后来改用RRF，不用管各路的分数分布，只按排名融合。

def rrf_fusion(rankings, k=60): """ rankings: list of dict, {chunk_id: rank} k: RRF平滑常数，医疗场景实测60比较稳 """ scores = {} for chunk_rankings in rankings: for chunk_id, rank in chunk_rankings.items(): scores[chunk_id] = scores.get(chunk_id, 0) + 1.0 / (k + rank) return sorted(scores.items(), key=lambda x: x[1], reverse=True)

RRF的关键参数是k。k越小，排名靠前的结果优势越大；k越大，各路结果越平均。通用场景常用k=60，但医疗场景我测试了k=45、60、80三档，最终用的是60。原因是医疗场景三路召回的精度差异比较大，结构化召回虽然precision高但recall低，k=60能让它进入融合序列却不会因为它一路霸榜。具体可以在自己的数据上扫一遍k，看融合后的Recall@20和MRR曲线选最优。

还有一个小细节：RRF本身不区分三路的可靠性，但医疗场景里结构化召回和BM25召回的高权威chunk，权重应该更高。我的做法是在RRF基础上叠加一个权威等级加权项：融合分数乘以系数，L1=1.2，L2=1.1，L3=1.0，L4=0.8。这个加权必须在RRF之后做，否则会破坏各路内部的排名逻辑。

3.4 混合检索的权限卡控

医疗知识库里经常混有不同密级的内容，比如院内感染数据、科室内部用药规范、尚未发表的临床试验方案。权限这件事必须在检索阶段就卡住，而不是生成阶段才做，否则权限外内容一旦进入候选集，虽然最终生成时可能不会被引用，但存在泄露风险。

我的实现是在查询进入检索前，先解析当前用户所属的科室和权限角色，生成一个过滤器，直接写入结构化字段召回的过滤条件里；同时BM25和向量召回的结果在融合前也会经过同一套权限过滤器，把无权限的chunk直接剔除。这套逻辑合到RRF融合之前，保证后面所有环节都看不到无权限内容。虽然有些内容相关性很高，但权限不到的查询坚决不许看到候选片段。

4. 重排模型：候选集之后的精准筛选

混合检索返回的Top 50候选集，直接交给大模型生成答案会出现两个问题：一是相关片段可能埋在无关片段后面，导致大模型"淹没在长上下文中"；二是医疗场景要求高精度，Top 50里可能只有3-5个是真正可引用的，其余的是"看起来相关、实际上不相关"。重排模型的价值，就是在候选集里做一次精筛。

4.1 Cross-Encoder为什么是医疗场景的必选项

Bi-Encoder（即双塔模型）把query和passage分别编码成向量后算相似度，速度快，但交互信息不足。Cross-Encoder把query和passage拼接在一起输入模型，做全交互的注意力计算，精度明显更高。通用场景里，很多人为了性能选择Bi-Encoder，但在医疗场景，精度优先级高于性能，Cross-Encoder是必须的。在一次内部评测中，Bi-Encoder重排后的Top 5准确率约为74%，Cross-Encoder的Top 5准确率约为89%，差距足以影响答案质量。

4.2 重排模型的选型对比：通用模型 vs 医疗微调模型

可供选择的重排模型主要有几类：

关于通义2b和4b重排模型的差距，我在项目里实际对比过。用400条医疗查询-文档对作为评测集，2b模型的NDCG@10是0.782，4b是0.831。差距是实质性的，但2b的推理速度大约是4b的2.3倍。如果你的线上请求量不高（比如每天几千次），4b更划算；如果是高并发接口，可以先上2b做初排，再用4b对Top 10做精排，这样兼顾速度与精度。不过需要说明的是，具体差距比例跟数据分布有关，建议拿自己的bad case集来评测，不要只看公开benchmark。

4.3 重排后的拒绝阈值：宁可没有答案，不可给错误答案

重排模型输出的分数并不是标准的概率值，不同模型的分数分布差异很大，不能直接用一个绝对阈值判断"这个片段是否相关"。我的做法是：在评测集上统计每个候选片段的相关性标注（相关/不相关），画出重排分数分布，然后取一个能覆盖95%相关样本的最低分数作为阈值。

这个阈值降到0.35（不同模型范围不同，这里以我用的模型举例）以下时，直接返回"未找到可靠内容"，而不是硬塞给大模型生成。实测中加入拒绝策略后，端到端回答的准确率从76%提升到84%，虽然回答覆盖率下降了（有些问题答不了了），但医疗场景中"答错"的代价远高于"不答"。

4.4 同源去重与权威叠加

重排之后还有一个常见问题：同一个知识点在Top 10里可能出现多条几乎相同的内容，比如三份文档都写了"该药禁用于孕妇"，模型在生成时会被重复信息淹没，还可能因为某份低权威文档的措辞不同而引入表达偏差。我在重排之后加了一步同源去重：先对chunk做归一化（去掉空格、统一数字格式），然后计算编辑距离或者直接比较前若干字符，重复度超过阈值的只保留权威等级最高的那条。

这个步骤能让Top 10里有效独立的证据点从平均3个提升到5个以上，大模型生成答案时能基于更多维度的证据，而不是反复看到同一句话的不同表述。

5. 溯源实现：医疗RAG的信任基础设施

医疗场景有一个其他领域很少强调的硬性需求：AI给出的每个结论，都必须能对应到知识库里的原始出处，且这个出处要精确到段落级别，方便医生或患者直接核对。我在项目初期忽略了这点，结果AI在回答时偶尔会"一本正经地胡说八道"，而系统根本没有提供让用户验证的路径。后来我重做了溯源能力，思路值得展开说说。

5.1 溯源的最小单位：段落级+原文指纹

很多人做溯源时，只会在答案后面附上一个"来源：某某指南"，这个粒度对医疗场景完全不够。医生需要的是"这一段话出自指南的第几章第几节，原文长什么样"。

我的实现方案是：在知识分段阶段，每个chunk都分配一个全局唯一ID，同时记录它的文档ID、章节路径、原始文本哈希值。文本哈希是防止源文档被修改后索引不同步的关键。源文档更新后，旧chunk的哈希与最新文档对不上，系统会自动标记失效，避免用过期内容回答新问题。

在生成阶段，当大模型引用某个chunk时，我把chunk ID一起交给溯源模块，由溯源模块渲染出完整的引用卡片，包括文档标题、版本号、章节路径、原文片段。这样用户看到的不是一句"来源：某某指南"，而是一个可以直接点开核对的可信引用。

5.2 文档版本追踪：同一份指南的新旧版本问题

医疗指南和药品说明书会定期更新，一个典型的情况是：某指南2023版推荐A方案，2024版调整为B方案。如果知识库没有版本管理，检索时新旧版本内容同时被召回，AI可能给出互相矛盾的答案，而你根本不知道它引用的是哪个版本。

我在文档入库时强制记录版本号，并设置版本生效时间。新版入库时，如果主题相同，会把旧版锁定为不可作为默认检索来源，仅保留在历史归档中。查询默认只搜生效版本。如果医生有特殊需求要查阅历史版本，需要显式传入版本参数。这套机制直接解决了"更新后答案漂移"的问题。

5.3 溯源与权限的联动审计

前面提到权限在检索阶段就要卡控，在溯源阶段，权限控制同样不能松懈。我的做法是：溯源模块输出的引用卡片必须携带权限标签和访问日志记录。系统记录的是"哪个角色在什么时间访问了哪一段原文"，这是纯技术实现层面的审计能力，不做任何多余延伸。在实践中，这个能力帮我们发现了不少权限配置错误，比如某个低权限角色竟然能检索到L1文档的内部批注版本。

5.4 溯源对端到端回答质量的反哺

溯源不只是给用户看的，它还能反向帮助排查RAG链路的问题。我在每次端到端问答时都会记录"最终生成引用了哪些chunk、这些chunk来自哪一路召回、重排分数是多少"。一旦出现bad case（用户反馈回答有误），我第一件事就是看引用的chunk列表，定位是哪个环节出了问题：如果引用的chunk本身是错的，问题在检索或重排；如果chunk对但AI没有按chunk内容回答，问题在生成阶段。这样排错效率提升非常明显。后面章节我会给一个具体的排查案例。

6. 全链路评测与调优实战：数据说话

前面讲了每一环怎么做优化，但真正要落地一个医疗RAG项目，必须有一整套评测方法和调优闭环。我分享一下我自己搭的这套评测体系和一次典型的调优过程。

6.1 评测集构建：从真实问诊场景中脱敏生成

评测集是RAG调优的地基。通用公开数据集（如CMRC、CMedQA）可以作为参考，但它和实际业务场景的分布一定有偏差。我在项目里构建了一套评测集，包含600对问答，来源是脱敏后的真实咨询记录和医生人工构造的医学考试题。每对问答标注了：

• 标准答案
• 支持答案的文档ID与chunk ID（用于验证引用正确性）
• 问题类型（适应证、禁忌症、用法用量、相互作用、不良反应）

评测指标分为三块：检索指标（Recall@k、MRR、NDCG）、生成指标（答案忠实度、引用正确率）、业务指标（回答覆盖率、拒绝率、用户反馈满意度）。检索指标是过程指标，生成指标和业务指标才是最终要优化到位的。有时候Recall@k涨了，但答案质量没变，说明问题出在生成阶段或重排阶段，这样的信号很有价值。

6.2 一次典型调优：从召回错乱到准确率提升

以"肾功能不全患者能否使用某药"这类问题为例，我详细介绍一次完整的调优流程。

初始版本（21.1）表现：MRR@10是0.58，端到端答案准确率只有69%。Bad case分析显示，检索结果里混入了大量"成人剂量""肝功能不全"等相似但错误的chunk，原因是分段时把"禁忌症"和"剂量调整"切到了相邻段落，混合检索的语义召回把同文档的邻近chunk一股脑捞了出来。

第一次调整：优化分段策略，把禁忌症与剂量调整作为独立语义块整块保留，颗粒度调细。效果：MRR@10提升至0.66，但答案准确率只涨到73%。此时发现检索问题已经不是主要矛盾，Top 10里明明有正确答案，重排却没把它排在前面。

第二次调整：替换重排模型，将最初用的通用Bi-Encoder重排换成医疗微调的Cross-Encoder，并加入阈值过滤。效果：Top 5准确率从81%提升到89%，端到端答案准确率提升至82%。

第三次调整：优化溯源和拒绝策略，对于重排分数低于阈值的问题直接拒绝回答，而不是强行生成。效果：答案准确率提升至86%，回答覆盖率从95%降到89%，但这7个百分点的覆盖率换来了准确率的实质性提升，业务方接受这个取舍。

从21.1到21.7，整体MRR@10从0.58提升至0.72，端到端答案准确率从69%提升至86%。整个过程最关键的认知是：不要指望一个环节的魔法改动解决所有问题，RAG是全链路的事，每个环节的bug都在蚕食最终效果。

6.3 线上监控：bad case回流闭环

RAG系统上线后，评测并没有结束。我在系统里加了简单的用户反馈按钮——"答案有帮助"和"答案不准确"。所有被点"不准确"的case，每天自动进入待分析队列。我每周会抽一批做bad case归因分析：

• 属于检索问题：标记，补充评测集，调整分段策略或检索参数
• 属于重排问题：标记，检查是否需要更新重排阈值或补充重排训练数据
• 属于生成问题：标记，调整prompt或答案约束
• 属于知识库问题：标记，缺文档了或文档过期了，安排知识库更新

这个闭环是我在这个项目里收获最大的部分。它让系统从一个"上线就完事"的工程，变成了一个"越用越准"的知识服务。

6.4 一些值得分享的细节经验

最后分享几个零散但实用的细节，都是踩过坑才总结出来的：

• 医疗文档解析时，PDF转Markdown不要直接用通用解析库，很多指南是双栏排版，通用解析会把左右两栏混在一起，需要先检测版面再按栏读取。
• 药品剂量区间里的"mg/kg"和"ml"这类单位，在分段时最好作为独立token保护起来，否则会被中文分词器切成奇怪的片段。
• 混合检索里BM25对英文和数字的索引要做大小写归一和半全角归一，否则"ACEI"和"acei"会被当成两个词。
• 大模型生成时，prompt里一定要强调"只能基于引用内容回答，引用中提到不确定的内容时明确说不确定"。这一点在医疗场景中比任何RAG技术细节都重要。

写在最后

从21.1到21.7，这个项目的核心变化不在某一项技术指标上，而是理解了医疗RAG的本质：它不是一个检索系统，不是一个生成系统，而是一个证据系统。检索、分段、重排、溯源，所有环节都在为一个目标服务——让AI给出的每个结论都经得起核对。回头看，最值得投入时间的其实是两件事：一是知识分段和元数据建设，这是后面所有效果的底座；二是评测集和bad case闭环，它决定了调优方向是清晰还是靠猜。

如果接下来要在医疗RAG上继续扩展，我会关注两块：一是把知识图谱引入进来，补足纯文本检索对医学实体关系的表达能力；二是多轮问诊场景的query改写，因为真实医疗咨询很少是一问一答就结束的。希望这篇实践解析对正在做同类项目的朋友有帮助，也欢迎一起交流踩坑经验。