企业官网建设流程全解析

1. 实测结果：宽松评分95分，严格评分85分

1.1 测试集是怎么搭出来的

帮一家制药企业做RAG知识库验收，是我最近最有感触的一个项目。客户内部已经积累了一套相当完整的产品知识体系，包括药品说明书、注册批件、培训材料、一线客服问答记录，甚至还有一部分老旧的PDF扫描件。我们要做的事情很朴素：把这些散落的资料整理成一个能让业务人员快速查询的问答系统，也就是目前最常见的检索增强生成RAG架构。项目前期的技术链路搭建其实不算难，embedding模型、向量库、rerank、prompt模板都很快跑通了，真正麻烦的恰恰是“验收”这两个字——怎么向客户证明这个系统的回答是可靠的，而不是碰巧像那么回事。

我们建了一套300道题的评估集。题目不是研发拍脑袋编出来的，而是让药企的医学信息专员、客服负责人、注册事务同事各自从真实咨询记录里挑问题。整理之后，其中120道是多选题，180道是问答题；按业务场景又可以分成用药相关信息、常规产品知识、内部流程和政策三类。这样设计的初衷很明确：既要测选择题式的精确匹配，也要测开放式问题的归纳能力；既要有高风险的安全类问题，也要有低风险的流程类问题。第一轮评估的时候，我们用的是比较常见的宽松规则：多选题只要模型给出的选项里包含标准答案中任意一个正确选项，并且没有明显错误表述，就判对；问答题只要关键词基本覆盖、语义方向正确，也判对。跑下来综合正确率是95分，其中多选题部分也是95分，问答部分94分。我一度觉得这个项目差不多可以收尾了。

但客户那边的医学顾问和法务不认可这个分数。他们的理由很直接：药企场景里“包含部分正确”不等于“安全可用”。一个答案即使写了85%的正确信息，剩下15%如果被业务人员直接采纳，也可能引发后续风险。于是我们重新定了一套严格口径：多选题必须是选项集合与标准答案完全一致才得分，多选、漏选、错选一律不得分；问答题要求所有关键点完整命中、不允许出现与标准答案冲突或扩大的表述、必须给出正确的引用来源。换成这套规则重跑一遍，综合得分直接掉到85分。单看多选题的话更难看，直接掉到81分。

1.2 两种评分的判定规则到底差在哪

为了讲清楚这10分差在哪里，我们把两套规则整理成了对照：

这张表后面藏着真实的语义判断差异。举一个我们实际遇到的多选题例子，题干问某药品的禁忌人群，标准答案是“孕妇、哺乳期女性、儿童、肝肾功能严重不全者”四个选项。模型给出的选项漏掉了“儿童”，但把其他三个都选对了。宽松口径下，因为“包含了正确的三个”，得分；严格口径下，漏选一个就是不得分。还有一类更隐蔽的情况：模型选了一个“范围扩大”的选项，比如把“部分肝病患者”表述成“所有肝病患者”。在宽松规则下，关键词“肝病”命中，给分；严格规则下，这是典型的知识性错误，必须判错。

1.3 95分和85分分别代表什么能力

95分和85分的差距，本质上是“这个问题看起来回答得对不对”和“这个问题真正能不能直接用于业务”之间的差距。宽松评分衡量的是RAG系统的“相关性”，严格评分衡量的是“可靠性”和“安全性”。当一个答案包含正确信息但不完整时，宽松口径会奖励它，严格口径会惩罚它。药企业务对这种差异极度敏感，因为文档里的一句话可能直接影响一线人员的判断。

我后来跟团队复盘时打了个比方：宽松评分像是让阅卷老师确认“考生没有交白卷，写的内容沾边”，严格评分像是让审稿人确认“每一条结论都有出处，且没有过度宣称”。RAG系统在demo阶段很容易达到前者，但真正要投入业务使用，后者才是硬门槛。这也是为什么我强烈建议，任何RAG项目验收都不要只看一种指标，尤其不要只看一个“综合准确率”。那个数字太光滑了，光滑到可能掩盖系统最致命的短板。

2. 药企真实语料为什么比通用测试集更考验RAG

2.1 文档结构里的坑：分块把表格和条款切碎了

做药企语料RAG，最容易踩的第一个坑就是文档分块。药企的原始语料和网上随便抓取的通用网页不一样，里面大量内容是结构化程度极高的表格、条目、多级条款。比如药品说明书里的“不良反应”通常是按发生率分层排列的列表；“用法用量”经常是一个完整表格，包含不同剂型、不同年龄段的差异。如果按固定字符数硬切，比如512个token一刀切，一张表格会被拦腰砍成两段，后面的检索召回时可能只拿到半张表，模型基于这半张表生成答案，自然会漏掉后半部分信息。

我们后来把分块策略调整成“结构优先”：先用规则识别文档里的标题、表格边界和列表层级，尽量让每个chunk对齐一个完整的语义块；表格行只要不跨页就整块保留；对于特别长的表格，单独做“表格chunk”，不和其他正文混在一起。这个改动看起来只是工程细节，但对问答题的召回率影响非常明显。严格评分下，原来的错误里有一类典型表现是“结论对了但漏了限定条件”，比如回答“每日三次”却没说“仅限成人”，这就是表格被切掉一列造成的。

2.2 事实型查询别硬塞给RAG：RAG和KG的分工

还有一个容易被忽略的问题：不是所有问题都适合用RAG回答。药企业务里大量问题属于“事实查询”，例如某个药品的批准文号是什么、某药是否在医保目录里、某个规格的包装数量是多少。这类问题本质上是查一条结构化记录，而不是从文本里归纳一段话。RAG从文档里检索再生成，反而会引入不必要的“自由发挥”空间。与之相对，知识图谱或结构化接口能给出精确字段，答案稳定且可溯源。

我们在验收时特意把测试集按问题类型拆成了两类：一类是文本归纳题，比如“说明书里列了哪些不良反应”，适合RAG；另一类是事实查询题，比如“某药最新的注册批件号是什么”。最终我们是通过外挂一个知识图谱接口来回答事实查询，RAG只负责把图谱返回的结果包装成自然语言。这样混合架构上线以后，严格评分里事实类题目的得分几乎拉满，整体分数才真正有了提升空间。如果一开始就强行把所有问题都塞给一个纯向量库RAG，95到85的落差可能还会更大。很多团队在规划RAG项目时，会默认“把文档扔进向量库就完事了”，但药企这类强结构化领域，RAG和知识库本身的边界必须先划清楚。

2.3 评测题目来源：业务人员出题和研发出题是两回事

评测集的质量直接决定“95分”和“85分”哪一个更接近真实水平。我发现，如果题目由研发人员自己构造，很容易无意识地避开模型的弱点。研发会下意识选择那些“在文档里能直接找到、没有歧义”的句子当标准答案，这样评测出来的分数自然偏高。而一线业务人员出题时，脑子里想的全是真实用户会怎么问，随口就是“这个药和那个药能不能一起吃”“感冒了还能不能打这个针”，这些口语化、跨文档组合的问题恰恰是RAG最容易失分的。

所以RAG评估集一定要由业务方主导出题，研发只负责去重、规范格式、补充标准答案。像这次300道题的集子，就是从药企各部门真实咨询记录里抽出来的，里面不乏相似药品的干扰项。评测得分也因此变得更“难看”，但也更可信。如果测试集本身是“温室花朵”，那么95分根本说明不了问题，反而会放纵系统带病上线。

3. 多选题为什么是严格评分下的重灾区

3.1 选项集合匹配对RAG是硬约束

这次实测里，最值得单独拿出来说的题型是多选题。宽松口径下多选部分95分，严格口径下直接掉到81分，跌幅明显大于问答题的94到87。原因在于，多选题的计分方式对“完全一致”的要求极度苛刻。宽松口径下“包含任一正确选项就给分”，几乎是个人都能拿高分，因为模型只要对一个选项就行；严格口径下则要求“集合完全一致”，漏选算错，多选也算错，错选更算错。这相当于把评估尺子从“相关性”直接换成了“精确匹配”，容错率瞬间归零。

模型在做多选题时倾向于“贪多”，因为生成式模型在不确定时会倾向多覆盖一些可能选项。这种策略在宽松评分下不会受伤，反正选对了就拿分；但在严格评分下，多选一个错误选项和漏选一个正确选项都是同样的结果——整题零分。于是，那些在问答题里可能只算“轻微瑕疵”的问题，在多选题里会被放大成“整题错误”。这也是为什么多选题分数降幅最大，它不是模型能力断崖式下降，而是评分口径放大了容错率的差异。

3.2 相似选项和兄弟药品是RAG的无形陷阱

药企语料里最防不胜防的干扰，来自相似药品和相似适应症。我们测试集里专门设计了一批“同品类产品对比”题，效果立竿见影。比如某个多选题目，四个候选选项里有两个描述来自同一家企业的兄弟产品说明书，文本结构、用词、句式几乎一模一样，只有适应症范围不同。模型在检索阶段会同时召回两份说明书，如果没有额外的实体对齐逻辑，它很可能把两个产品的信息混到同一个答案里。

这种错误在宽松评分下非常容易被放过，因为错误选项里混着正确关键词；但严格评分下，多选一个“看着很像”的选项，整道题就废了。我们后来在检索阶段加了一步药品名实体过滤：先从问题中识别出明确的药品名称，只保留包含该名称的chunk参与生成。这一步看似简单，却让多选类题目的严格得分一下提升了6个百分点。换句话说，RAG在做多选题时，很多时候不是“不懂”，而是“被相似信息带偏了”，必须在链路层面把干扰源先屏蔽掉。

3.3 多选题的自动评分怎么定才不容易扯皮

多选自动评分的prompt设计，比问答题更需要结构化。我们最初给LLM裁判的指令太简单，就是一句“请判断模型答案是否正确”，结果裁判频繁出现“觉得方向对就给分”的问题。后来改成分三步：第一步让裁判先列出模型给出的选项符号；第二步列出标准答案选项符号；第三步再比较两个集合是否完全相等。只有当集合完全相等时，才输出“正确”。这个结构的目的是强迫裁判不再做语义联想，只做集合比对。

这里还有一个细节值得提醒：不同LLM裁判对同一个多选题的判定可能不一致，尤其是当选项文字有细微差异时。所以多选评分不要依赖单个模型，最好用两条独立的大模型链路分别评分，不一致时再让人工介入。药企这种场景里，多选题判分口径必须清楚到“选项集合完全相同”这种机械化程度，否则95分和85分之间的争论会一直存在。

4. 别只盯准确率：RAG验收应该看一整张指标表

4.1 准确率之外，最该关注的是忠实度和引用正确率

很多人验收RAG只看一个准确率，85分就觉得系统不行，95分就觉得系统成了。实际上，准确率只是一个汇总结果，它掩盖了错误类型。药企场景里，我更推荐至少同时跟踪四个指标：答案准确率、忠实度（Faithfulness）、引用正确率、检索召回率。

忠实度简单说，就是“答案里的每一句话，是不是都能在检索到的上下文里找到依据”。RAG最大的风险在于，生成模型可能基于检索片段进行“合理发挥”，加一句原文里根本没有的细节。如果只按答案与标准答案比对，这种发挥有时会撞对，有时会撞错；但忠实度能直接把它标出来。引用正确率则专门看模型给出的引用来源是不是真的能支撑那句话。我们在严格评分阶段遇到过这种情况：模型答对了结论，但引用了一份同一药品另一版本的说明书，结论碰巧一致，严格规则下引用错误仍然判错，这是对的，因为下游业务人员需要靠引用去复核。

4.2 单一指标为什么会骗人

只看一个合计准确率，还会掩盖另一种极端：系统可能用“回避式回答”刷高分数。比如模型检测到检索结果置信度不高时，干脆回答“文档中未找到相关信息”，在大多数语义近似评分里，这会被判定为“未回答”，扣分；但如果你用某些“可辩护拒绝”策略打分，这种回答反而会拿到忠实度满分，因为每个字都有依据。单一指标无法区分“答非所问但依据充分”和“答得非常完整但引用错了”。这就是为什么必须把指标表拉出来一起看。

我们用一个比较简单的多指标汇总方法：每个测试题目记录五个字段，分别是严格正确性、宽松正确性、忠实度评分、引用来源ID、检索是否命中正确文档。最后统计时按题分桶，先看“检索是否命中正确文档”，再看“忠实度是否达标”，最后才是“答案是否准确”。这个顺序其实就是RAG全链路的排查顺序：检索都没召回正确文档，生成再漂亮也没用；召回对了但生成不忠实，就得调生成策略；都达标了仍然答错，才需要考虑是不是模型知识冲突或评分规则本身有歧义。

4.3 阈值指标别统一用一把尺子

网上很多RAG教程会建议一个统一的相似度阈值，比如向量检索分数低于0.7就不返回结果。实际上，在药企项目里阈值必须按场景风险和文档置信度来设。我们当时把问题分成了三档：安全性问题，比如禁忌、不良反应、禁忌人群，相似度阈值必须拉高，检索不到高分片段时直接拒绝回答，而不是给一个模糊答案；常规产品知识，比如剂型、储存条件，阈值适中；内部流程类问题，比如培训、报销流程，阈值可以更低一些。评估的及格线也完全不一样。核心安全类题目要求在严格口径下接近满分，常规产品信息可以接受90%，流程类问题85%就算过关。分数不是越高越好，关键看它对应什么风险等级。

5. 85分背后的错误长什么样：一次bad-case复盘

5.1 错误归类：四类问题的分布

严格评分的85分意味着15%的题目错了，这个比例并不低。我们把这些错题全部捞出来，按链路节点分成了四类：检索环节没召回到正确文档、上下文分块导致信息残缺、生成环节出现与原文不一致的“幻觉”、以及评分规则本身存在歧义。从数量上看，信息残缺和生成幻觉占了大多数。信息残缺的典型表现是：模型把检索到的半张表格当成完整信息，漏掉尾行；生成幻觉的典型表现是：模型为了把句子补完整，自己“脑补”了一个发生率或措辞。这两类问题在宽松评分下都可能被放过，因为“主关键词都出现了”；在严格评分下就会原形毕露。

我们的错题分布大概是：信息残缺38%，生成幻觉30%，检索未被正确召回17%，评分歧义15%。这个占比提醒我们，RAG的优化不能只盯model层，也不能只盯检索层，而是要先通过bad-case把真正的瓶颈分层出来。如果一上来就盲目换embedding模型，可能只解决了17%的问题，另外38%的信息残缺依然存在。

5.2 多选干扰项：看着对，其实错

我再详细拆一个典型案例。测试集里有一题，给四个候选选项，标准答案是A和D。模型给出的答案是A、C、D。为什么模型选了C？因为C描述的内容确实出现在检索到的文档片段里，但它属于“其他药品的适应症”。模型把相似文档里的句子张冠李戴到目标药品上。宽松评分下，因为A和D都选中了，这道题判对。严格评分下，多选了C，整题不得分。

这种错误是RAG在“相似语料”场景下最典型的翻车点。药企的产品线有不少相似适应症、相似成分的药品，说明书模板也高度相近，向量检索很容易把两份说明书的片段同时召回。如果生成阶段没有指定“必须依据主问题锁定的药品ID来过滤候选chunk”，模型就可能把兄弟产品的信息拼进答案。后来我们在检索阶段加入了一个药品名实体对齐过滤步骤，先用规则识别问题中的药品名，只保留包含该药品名的chunk，再进入生成。这个改动让多选类题目的严格得分直接提升了6个百分点。

5.3 从错误反推系统瓶颈：用trace日志定位环节

做bad-case复盘，最忌讳的就是只看答案对不对，不看链路中间发生了什么。我们在每次评估时都会记录完整的trace：最终答案、模型实际读取的chunk列表、每个chunk的相似度得分、生成时的完整prompt。每个严格判错的题目，我都会先把trace调出来，确认三件事：检索结果里有没有正确答案对应的chunk？有的话，它排在第几位？生成时模型到底参考了哪几个chunk？如果参考的是错误chunk，是检索排错还是之后rerank没把相关文档排上去？这样一层层往下问，85分的错题才能变成真正有用的改进素材。

比如我们通过trace发现，有将近一半的“引用错误”问题，其实是检索时把“药品说明书中老年人群用法”和“儿童人群用法”两个chunk同时召回了，模型选了后者作为主要依据。这表面上是生成问题，实际上是检索排序的缺陷。后来我们给关键字段增加了rerank权重，对问题中的“老年人”与chunk中的“老年患者”这类同义表达做二次打分，引用错误明显减少。这种定位方式，比拿到一堆分数后盲目调参要高效得多。

6. 验收前先定三件事：口径、风险分级、人工抽检

6.1 评分口径必须让业务方签字确认

这次95到85的“事故”，最初的分歧就在于双方对“对”的定义不一致。我们以为“覆盖了主要点”就是正确，业务方认为“必须可用于业务审核”才叫正确。这个教训说明：RAG验收开始之前，评分标准不能只由技术团队内部定，而是要拉着医学信息、法务、客服一线坐在一起，把“正确”两个字写成可操作的细则，并且让业务负责人签字确认。多选怎么算对，问答题允许什么程度的措辞调整，引用是不是强制要求，这些都要落到纸面上。

我们后来拟了一份评分细则，大概五六页。里面甚至规定了术语写法，比如“适应证”和“适应症”哪个是官方用法，“禁用”和“不推荐”在什么场景下可以互换。这种细节如果不在验收前确认，事后就会变成无穷无尽的扯皮。尤其是RAG这种自动生成式系统，同一个问题换个问法，答案就会变化，如果没有明确口径，任何分数都缺乏公信力。

6.2 按风险等级分层设分数线，而不是一刀切

药企RAG不可能所有题目都要求100分，因为有一些低风险场景，比如“内部报销流程”，答对85%已经足够；但涉及安全的问题，任何一个错误都是不可接受的。我们按问题类型划了三档评测子集：安全性问题、产品常规信息、内部流程政策。安全性问题单独跑严格评分，必须接近满分才能进下一步；产品常规信息允许有少量可修正的瑕疵；内部流程政策只要不误导员工就算通过。不同档位对应的测试题数也可以不同，安全类多设一些多选和判断题，因为这类题型最容易出现“多选一个错误项”的隐患。

有条件的话，建议把这三档做成三个独立的评测集，分别计算分数，而不是混在一个“综合准确率”里。只有分档之后，你才知道85分到底是因为安全类题目掉链子，还是流程类问题拉低了平均值。否则，一个“平均85”很容易让研发误以为系统整体还可以，实际上高风险部分可能已经不及格了。

6.3 LLM裁判也会误判，人工抽检不能省

自动评分虽然快，但LLM裁判本身有偏差。我们这次严格评分的85分里，人工复核后发现有两三道题其实是被裁判“误杀”的。比如有一道问答题，标准答案没有写引用来源，严格规则要求必须引用，裁判就判了错；但实际上这道题本来就属于“无法引用结构化字段”的事实查询，不应该套用同一套引用规则。这种情况在自动评估里很常见。所以建议自动评估之后，至少抽10%到20%的样本做人工复核，特别是那些“边界模糊”的样本。把人工复核结果再反哺到评分prompt里，评估系统本身也在迭代。

人工抽检不是走形式。抽检时重点关注两类题：一类是严格评分判错的边界题，需要确认是系统错还是裁判错；另一类是分数变化最大的题目类别，比如多选和问答题的分差，它们往往藏着系统能力变化的信号。抽检完成后，把判例更新到评分标准里，下一次评估会稳定很多。

7. 沉淀下来的几个实操细节

第一，多选题的自动评分prompt不要只给一句“判断是否与标准答案一致”，要分三步走：先让LLM列举模型选的选项，再列举标准答案选项，最后逐个比较选项集合。这样能减少裁判漏判多选选项的情况。如果想让分数更贴近业务，就直接用“集合完全一致”作为得分条件，别给“包含”留余地。

第二，问答题打分层级评分。第一步判断答案里有没有“原文中不存在的陈述”，有就直接标记为忠实度不达标；第二步逐个核对关键点是否完整；第三步再判断引用来源是否可支撑。把这三个分数拆开记录，后续调优时能清楚知道是“检索没召回”还是“生成乱发挥”还是“引用对不上”。我推荐把这三步做成一个结构化的评分模板，每个题目都输出JSON结构的评分明细。

第三，测试集一定要版本化。第一次评测完，把300道题、标准答案、评分规则、trace日志全部存档。之后每改一次分块策略、调一次prompt、换一次模型，都必须跑同一套基线集做回归。否则你无法判断分数提升到底来自哪个改动，也可能把已有能力改坏而不自知。我们后来把基线集版本号直接写进CI流程，RAG配置变更必须触发回归，这一步对长期项目尤其重要。

第四，也是我最想强调的一点：分数只是验收的入口，不是出口。95分和85分的差距，并不代表“差10分”这个绝对值，而代表评测尺度是否匹配业务风险。做药企RAG，宁可要一个严格口径下“看着难看”的85分，再花时间把错题一个个消掉，也不要一个宽松口径下“虚胖”的95分，上线后让业务人员在真实场景里去踩坑。我个人的工作习惯是，接手任何RAG项目时，第一件事就是和客户确认：你们打算用什么标尺来衡量“答对了”？如果对方只会说“差不多就行”，那我就会主动要求把评分口径收紧，先让系统在严格规则下把分数跑出来，再一步步放宽到业务可接受的程度。这种工作方式在药企项目里尤其管用，因为它逼着团队在验收前就把“什么是对的”这个问题彻底想清楚。