上一周我们团队在药企客户现场做 RAG 系统验收。同一个知识库、同一批测试问题、同一条模型链路内部自动化评测跑出来的多选题命中率是 95 分业务方换了一套更严格的评分规则复核成绩掉到 85 分。会议室里的气氛一下就紧张了。这个差距不是测评口径的小分歧而是 RAG 验收里最典型、也最容易被忽视的陷阱——只看一种指标等于只检查了系统的一半。这篇东西写给正在做 RAG 项目、尤其是做医疗健康、制药、法规类知识库的朋友。我会把我们踩过的坑、复盘出的评测方法论、以及落地可用的工具链全部摊开讲。核心就一句话RAG 验收别只看一种指标尤其是别被一个高分指标哄住。1. 先还原现场同一套系统怎么测出两个分1.1 项目背景药企知识库问答的验收现场客户是一家制药企业内部积累了大量的 SOP 文件、质量标准、药监部门公开指南、稳定性试验报告、不良反应案例库。他们要做的 RAG 系统是让员工用自然语言提问系统自动检索相关资料并生成带引用的回答。典型问题包括某口服固体制剂压片工序的片重差异检测频次要求是什么某成分在制剂中的含量限度是多少某设备清洁验证的接受标准在哪个文件里定义过。这类问题的共同特点是答案不能编不能模糊引用错一个数字就是质量事故。系统架构上用的是业界常见的技术栈开源 Embedding 模型做向量化、向量数据库做检索、通用大模型做生成。这套链路本身没什么特别真正出问题的是验收环节的两个评分口径。内部自动化评测跑出来的 95 分是多选题命中率预先准备一批问题每个问题附带一个包含若干要点的标准答案列表系统生成的回答只要命中其中任意要点就得分。业务方拿来的严格评分则完全不是一回事他们要的是这回答是否完整、是否正确、是否引用了正确来源、是否按合规格式输出。同一个系统、同一条链路、同一批问题分数差了整整 10 分。这个 10 分不是误差是两个评分体系在测量不同性质的东西。下面我逐个拆开看。1.2 95 分的真相什么是多选题命中率多选题命中率这个指标的设计逻辑很直观把标准答案拆成若干独立要点模型生成的回答中包含哪个要点就记为一次命中最后算命中率。比如某问题的标准答案包含三个要点首件检测、生产过程中每两小时抽检一次、记录在批生产记录中。模型只要回答里出现了每两小时抽检一次这道题就得分了哪怕它漏掉了另外两个要点。更麻烦的是模型多答不扣分。生成模型天然倾向于把想到的信息都写进回答里——多说几个点总能蹭中一两个。于是系统只要能做到检索到包含要点的那篇文档再让模型把文档内容转述出来一部分命中率就很容易走高。说白了这是召回率友好型指标它奖励提到不检查说对。我再举个例子你就明白有多离谱。有个问题问某中间体储存条件标准要点是密封、避光、2~8℃。模型回答了一大段提到了避光2~8℃还额外加了一句可在常温下短期存放。这句是错的但因为命中了两个要点宽松评分照样给满分。严格评分里这句错误陈述直接触发事实性错误惩罚加上缺少密封条件这个完整性问题分数掉一大截。所以 95 分只能证明一件事系统在绝大多数时候能把包含正确答案的片段抓到并复述出来。它没法证明回答的边界是干净的、逻辑是自洽的、出处是准确的。在多选题里这些都不重要在药企的知识问答场景里全都重要。1.3 85 分的构成严格评分到底在查什么业务方的严格评分规则是我们这次项目里最有价值的输入。他们把它分成四个维度每个维度单独打分再按权重加权完整性维度看标准答案里的每个要点是否都被覆盖缺一个扣对应比例的分。正确性维度看有没有事实性错误包括数字、单位、步骤、对象名称写错一旦发现错误陈述就直接扣掉该要点全部分值。依据性维度看回答是否能定位回源文档的具体位置要求系统输出的引用要与回答内容强相关引用错误和没有引用都算缺陷。格式合规性维度看是否按业务要求的格式输出比如是否明确区分了基于文档的结论和推测性内容。同一道题在这套规则下的命运完全不同。以刚才的例来说模型答出了时间频次但漏了首件检测完整性扣 1/3加了一句错误陈述正确性扣分引用位置指向一整份验证报告而非具体章节依据性扣分。四维加权下来单题得分在及格线附近徘徊。业务方把所有测试问题按这个逻辑过了一遍得到的总分就是 85。顺便说一句85 分在整条严格的评测体系里其实不算低但它和 95 分的差距是实质性的一个每 20 次回答里可能有 1~2 次存在事实性遗漏或错误另一个把同样的缺陷隐蔽在宽松评判盲区里。对药企场景来说放大到每天几千次查询这个概率对应着不可接受的质量事故风险。1.4 两个分数之间的 10 分去哪了复盘这几百条测试样本后我们把 10 分的差距做了归类。大约 70% 的扣分来自正确性维度模型多说了不该说的话、写错了单位或条件、把流程步骤顺序搞反了。大约 20% 来自完整性漏掉了关键要点。剩下 10% 来自依据性和格式规范性。这个比例是药企语料的典型特征。通用领域的 RAG 评测里完整性往往是最大的丢分项药企这类规范密集的领域正确性才是命门。模型错得最频繁的地方不在于有没有找到资料而在于生成阶段对资料细节的转述不够忠实——这就是我们常说的幻觉准确说是部分幻觉。数据看清楚了问题的性质也就清楚了95 分和 85 分的差异不是评测噪声是 RAG 系统生成阶段的质量短板在更严苛的标尺下现了原形。如果验收时只看 95 分这个短板会被完全掩盖。2. 拆开 RAG 评估指标哪些分靠得住哪些分在放水2.1 RAG 评估的三层结构要搞清楚哪些指标能信得先把 RAG 系统的评估拆成三层。检索层的指标衡量的是能不能把相关文档找回来常见的有 RecallK、命中率、MRR平均倒数排名。生成层的指标衡量的是生成内容是否对题、是否答全典型代表是 Answer Relevance 和 Completeness。忠实层的指标衡量的是生成内容是否有源可依、有没有幻觉例如 Faithfulness、幻觉率。用个生活化的比方检索层是图书管理员有没有找对书架生成层是你能不能把书里的内容转述清楚忠实层是转述时有没有自己加戏。三个环节层层递进任何一个出问题都会让最终回答质量塌方。很多团队做 RAG 评测时只盯检索层指标觉得检索命中率高系统就靠谱。你看完前面那个现场就应该明白检索层指标完全无法覆盖生成层的错误。我们的系统检索命中率不低但 70% 的扣分发生在生成阶段。检索层指标是整个评测金字塔的基座但它离业务效果还隔着两跳。2.2 检索好不等于回答好这里有一个很多人没意识到的细节检索召回和最终回答质量之间没有强线性关系。检索召回率达到 95%但相关文档排在几十条无关文档之后LLM 上下文窗口有限被大量噪声内容稀释生成质量照样会崩。反过来检索召回率只有 80%但如果那 80% 里恰好包含了最关键的文档且顺序排得靠前生成效果反而很好。所以当你看到某个 RAG 项目汇报检索召回率 98%的时候先别急着高兴。你要追问的是召回回来的文档排在第几位Top3 命中率是多少这些文档是否真的被模型拿来作为回答依据这些信息比一个孤零零的召回率有说服力得多。RAG 评测领域有一组常用组合RecallK 加 MRR 加上下文相关性。RecallK 看命中是否在 TopK 里MRR 看命中的位置是不是靠前上下文相关性看检索回来的内容在语义上是否与问题匹配。这三个指标一起看才能判断检索链路的基本盘。2.3 命中即得分带来的评分膨胀回到多选题命中率的膨胀问题。它的机制主要有两个第一个是不区分正确答案和额外错误答案把两者看成独立事件只要前者出现就算赢后者完全不影响判分。第二个是它本质上只做二分类判断——包含或不包含不评估回答的边界质量。我把这种指标叫做放水指标不是因为设计它的人存心放水而是它的设计目标本来就是快速粗筛用极低的判断成本筛掉明显不合格的样本。问题在于很多团队把它当成了验收主指标用粗筛的尺子做终检。这就好比体检时只看身高体重不出报告就宣布这个人健康——身高体重当然有意义但离医学意义上的健康差得远。在多选题的评分逻辑里多答是最占便宜的。模型只要在回答末尾追加几句泛泛而谈的周边信息不扣分不说还有可能蹭中额外要点。所以我后来跟客户强调多选题命中率只能作为上线前的冒烟测试指标连初筛都算不上更当不了验收依据。2.4 严格评分的设计逻辑完整性、正确性、依据性、合规性严格评分为什么能暴露 95 分的泡沫因为它把答案切成了多个独立维度每个维度都有明确的扣分触发条件。完整性维度惩罚信息缺失正确性维度惩罚说错话依据性维度惩罚出处不实合规性维度惩罚输出失范。这四个维度里正确性对药企场景最重要也最容易拉开差距。我给出一个可复用的扣分规则供参考答案中每一个事实性错误数字、单位、条件、步骤顺序、对象名称扣 10 分如果错误涉及安全性内容剂量、禁忌、储存条件按一票否决处理整题 0 分。完整性维度按要点数量平均分配分值缺一个要点扣对应分值。依据性维度如果引用来源与关键结论不匹配扣该结论一半的分。格式合规性一般占 5~10 分属于约束性得分。这套规则不是拍脑袋定的它和药企文档审核的逻辑一脉相承。GMP/GxP 环境下的文件审核最看重的是关键信息不允许遗漏、不允许错误、不允许无源头。把业务流程里的审核标准翻译成 LLM 打分层级让机器评分的口径和人工审核口径对齐这才是严格评分能获得业务方认可的根本原因。2.5 用数据看 10 分差在哪里我在项目复盘里留了一张表把两种评测方式在 100 道测试题上的结果做了交叉分析。多选题命中率在 95 分以上的题里大约 12% 在严格评分下被判定为存在事实性错误。这个 12% 是最让人后背发凉的数字如果按宽松口径这些题完美通过业务真实使用时这批回答可能已经在误导操作了。错误类型分布上画蛇添足类错误占比最高。模型在转述原文时加入了自己的补充判断这些判断单看似乎合理但对照源文档根本站不住脚。其次是张冠李戴类错误把 A 工序的要求套到 B 工序上因为文档里两者位置临近模型在生成时混了上下文。再次是数值漂移类错误原本是2~8℃模型生成时写成2~8°C不影响但把2~8写成2~80就是事故了——这类错误在宽松评分下极难暴露因为字数相近且关键词命中。这三类错误在英文文献里通常归入unsupported claim和faithfulness violation。中文社区讨论 RAG 瓶颈时常说幻觉问题实质上就是这些现象的组合。3. 药企语料的特殊性为什么最容易暴露这类差异3.1 术语密集与同义改写陷阱你拿通用领域的评测集去测一套 RAG 系统通常不会像药企语料这样高清地暴露指标问题。药企语料的第一个特点是术语密集且同义表达极其混乱。一个化合物可能有化学名、通用名、商品名、缩写四种写法同一种原料在质量标准、SOP、验证报告中可能以完全不同的名称出现。Embedding 模型对同义词的处理能力有限。问扑热息痛检索不到含对乙酰氨基酚的文档是 RAG 药企落地里的经典翻车现场。两种评测方式的差异在这里被放大了多选题命中率只关心回答中是否出现标准答案要点模型完全可能从检索到的不相关文档里编出一个看似合理的回答然后命中要点严格评分会检查引用来源一旦发现引用的文档里根本没有扑热息痛字样判定无源引用扣分没商量。所以药企 RAG 做评估的时候必须专门构建一组同义改写测试集。同一道业务问题换三五种说法去提问看系统是否还能稳定检索到正确文档、生成正确回答。这个测试集在通用领域评估里是加分项在药企语料里得当成必选项。3.2 答案空间是离散的不是连续的药企知识库不是意见型知识库。通用问答里如何提高团队协作效率可以有千万种合理答案药企的标准操作类问题则有唯一正确答案。这个本质区别让 RAG 的生成阶段面临完全不同的挑战模型需要在离散的答案空间里精确命中某一个确定值而不是在连续空间里给出一个合理近似。要求越高宽松指标的水分越明显。多选题评分里近似答案也能命中因为要点描述是语义级匹配严格评分里近似答案就是错误答案因为数字、条件、步骤都必须是确定值。剂量、浓度、储存温度、检验限度错一个数字就是错误答案这两套评分体系下产生的差距还能小得了吗。这也是为什么我建议药企 RAG 的自动化评测里一定要配置数值一致性检查把标准答案里的所有数值提取出来与模型生成答案里的数值逐一对比不一致即判错。这个检查可以做得很机械但效果极好因为它精准击中了离散答案空间里最容易出错的地方。3.3 长文档切分两难拆太碎丢上下文拆太粗丢精度药企文档的另一大特点是又长又厚。几十页的验证报告、质量标准、稳定性试验方案是常态。做 RAG 时第一步就是切分文档这里藏着一个经典的两难切太碎前后文被切断答案是找到了但缺前提切太粗向量化之后一个块里塞下太多内容语义被大量无关内容稀释检索精度直线下降。我见过最典型的失败案例某质量标准文档里有一个表格规定了各检验项的限度表格前面是本品应符合如下规定。如果切分把表格和这句前置条件切到不同块里检索时可能只看表格不看前置模型生成时完全不知道为什么限定这些项目。这类问题在宽松评分里几乎测不出来——要点都在只是关系断了严格评分查依据性一眼就能发现引用位置和回答内容不匹配。文档切分没有万能参数药企场景里我建议优先做结构感知切分按章节、条款、表格边界切分而不是按固定 token 数硬切。这块的实操细节后面专门讲。3.4 法规类内容不容推理发挥药企知识库里有大量接近法规性质的内容质量标准的制定依据、验证策略的适用场景、放行标准的接受限度。这些内容的共同特点是逻辑链条非常严谨因为 A 所以 B的关系必须保持完整。模型在生成时最危险的倾向是进行合理补全——看到文档里说了 A就顺手推理出 B但 B 在文档里根本没有出现过。严格评分体系对这类行为是零容忍的因为合规场景不需要模型展示推理能力只需要忠实转述。所以我建议药企 RAG 的忠实度评估要包含一个专门的维度是否包含源文档中不存在的结论性陈述。在实际标注时可以这么操作把回答中每一个结论性句子与源文档逐句比对找不到支撑就标记为幻觉超过一定比例直接整题判负。这个维度的存在会大幅压低宽松指标下的乐观分数。前面提到 95 分变 85 分的案例里至少有一半的扣分来自这类无依据推理。换句话说药企语料会把 RAG 的幻觉问题放大到业务不可接受的程度而宽松指标会把幻觉完全隐掉。4. 药企 RAG 验收的正确姿势评估集、指标体系与流程4.1 评估集先于系统构建如果你正在启动一个 RAG 项目我的第一个建议是不要在文档全部灌进去之后才开始想评估。评估集应该和知识库梳理同步做甚至更早。没有一套可靠的评估集后面的调优全是盲人摸象。评估集构建的方法是从真实业务数据里采样而不是从大模型里生成。药企场景里真实问题来源包括员工实际发出的问询记录、质量部门的常见疑问清单、培训考核题、审计常用的核查问题。把这些原始问题收集起来按类型分层事实型问题某数值是多少、流程型问题某操作分几步、比较型问题A 和 B 有什么区别、多跳推理型问题需要跨多个文档才能回答的问题、边界型问题文档里根本没有答案的问题。每个问题务必要配标准答案标准答案包含两个部分一是必备要点列表二是判分规则。判分规则要写明哪些错误属于一票否决、哪些属于部分扣分。评估集的大小建议不少于 200 题如果场景复杂度高500 题以上更好。我见过只用 30 题做验收的系统统计波动大到根本没有参考意义。特别注意加一些无答案问题进评估集。RAG 系统应当在没有对应文档时明确回答资料中未找到相关信息而不是硬编一个答案。这个能力在很多放松指标的评测里完全测不出来。4.2 指标体系至少三套并行RAG 验收的完整指标体系我认为至少要有三套并行。第一套是检索侧指标RecallK、MRR、上下文相关性用于判断知识库检索模块是否健康。第二套是生成侧指标Answer Relevance、Completeness、格式遵从度用于判断模型是否对题、答全、守规矩。第三套是忠实侧指标Faithfulness、幻觉率、引用规范性用于判断内容是否可信、有源。三套指标缺一不可。只盯检索侧等于只测了图书管理员只盯生成侧等于只测了转述能力只盯忠实侧又容易忽略系统根本没找到关键资料的情况。在药企场景里我建议在上述指标之外再加一个业务侧指标可执行性评分。让业务方的专家人工评审机器生成的答案判断如果我按这个答案去执行是否安全、是否会造成质量问题。这个指标才是业务真正关心的终极效果前三个技术侧指标都只是它的代理变量。4.3 评分标准先于评测定义有了评估集和指标体系还不够最容易被忽视的是评分标准本身。我踩过的最大的坑是自动化评测脚本跑出分数之后团队内部对某个回答到底该得几分产生分歧于是来回改打分逻辑最后分数越改越好看评测结果失去了任何参考价值。正确的做法是在评测之前把评分标准写成一份可执行的文档。每个维度给出明确的判定规则附上正面例子和反面例子各三个。药企场景我强烈建议设置两条红线规则出现事实性数字错误直接判 0 分答非所问直接判 0 分。这两条红线能有效防止模型在不确定时东拉西扯也能防止评测脚本把明显错误回答的高分给遮过去。评分标准和裁判模型的关系也要提前定清楚。如果使用 LLM-as-Judge 方式裁判模型用的提示词本身也需要测试和校准。一个可行的校准方法是先人工给 50 条回答打分再用这 50 条作为校准集去调整裁判提示词直到自动化打分和人工打分的一致性达到 90% 以上再放量跑。4.4 回归测试机制RAG 系统是一个持续迭代的工程系统。换了 Embedding 模型、调了 chunk 大小、改了向量库参数、更新了文档切分策略任何一个动作都可能影响最终效果。如果没有一套固定不变的回归测试你根本不知道改版到底是变好了还是变坏了。回归测试的核心是同一套评估集、同一个评分标准、同一个打分模型。每次改动后跑同一套流程记录总分和分维度分最好还能记录到单个问题级别的得分矩阵。得分矩阵的价值在于你能看到哪些类型的问题在持续失分从而判断问题出在检索还是生成是数据问题还是模型问题。我们团队的实际做法是每次改动后跑一遍完整评估集把结果存成带版本号的 JSON 文件再写一个对比脚本自动输出本次改动导致的分数变化明细。明细里如果出现某类问题分数大幅下降就算总分持平也要警觉因为局部劣化可能意味着文档覆盖出现了新的漏洞。这套流水线看着笨但回头分析问题时极其好用。4.5 自动化评测和人工抽检互补自动化评测的优点是全覆盖、可重复、成本低缺点是判断深度有限。LLM-as-Judge 可以检查要点的有无、引用的虚实但它很难判断回答的语气是否适合给一线操作工看也很难发现一些微妙的业务风险。这些判断最终还是得靠人。我建议药企 RAG 项目采用自动化全面扫描人工分层抽检的组合模式。自动化评测在每次迭代时全量跑人工抽检按每周 50 条的节奏做抽检样本按问题类型分层抽取不搞随机抽样。人工抽检的目的不是复测自动化结果而是发现自动化看不到的问题回答是否专业、是否有误导性表述、是否会引起歧义。人工抽检的结论要反馈到评估集和评分标准里。如果三个人工抽检员指出的问题属于同一类说明评估集里缺少这类样本或者评分标准没有覆盖这个维度。补充进去评估体系才能一步步逼近真实业务需求。5. 落地工具与常见坑从本地 RAG 到排查速查表5.1 用大模型当裁判LLM-as-Judge 怎么用才靠谱药企 RAG 的评测要想规模化自动化打分是绕不开的。当前最主流的做法是 LLM-as-Judge让一个大模型根据评分标准给系统生成的结果打分。这个方法本身有效但有几个坑必须避开。第一个坑是裁判模型和回答模型不要同源。让生成回答的模型给自己打分通常会因为模型自身的偏好而产生系统性偏移——它容易对自己生成的内容更宽容。所以在评测链路里要配置一个独立的裁判模型而不是直接用线上回答模型来打分。第二个坑是裁判提示词必须包含明确的判定依据。你可以在提示词里给出标准答案、文档片段和生成回答然后要求裁判先输出判断理由再输出分数。禁止裁判依据外部知识判断必须依据给定文档来判断。这样打出来的分数才具备可回溯性。第三个坑是场景特殊性。药企评测里数值错误是高频扣分点单靠裁判模型自然语言理解可能出现漏判。我们在实践中给严格的数值错误判定加了一层规则校验先把标准答案里的数值和单位抽出来与生成回答里的数值逐一比对不一致就判错再把这个规则校验结果作为输入传给裁判模型整合。5.2 本地 RAG 与评估环境怎么搭药企数据往往不能出本地评估环境也得跟着本地化。我常用的组合是Ollama 拉起本地生成模型和本地 Embedding 模型向量库用 Chroma 或 FAISS文本解析和切分用开源文档解析库。这套组合可以完全离线运行不依赖任何云端 API。搭建本地 RAG 的最简化流程是第一步用文档解析库把源文件清洗成纯文本按结构切分成块第二步调用本地 Embedding 模型把每个块向量化写入向量库第三步用本地大模型接收检索结果并生成回答。整个过程中要注意两个选择Embedding 模型维度要和向量库配置一致chunk 大小要和业务文档结构匹配。评估环境同样可以全部本地化。写一个评测脚本从评估集里逐条读取问题调用 RAG 系统的接口拿到回答再用裁判模型按评分标准打分。这样一个全本地评测流水线搭建起来大概两三天的工作量却能支撑后续所有迭代决策。Ollama 加简易本地知识库这套方案对零基础的朋友尤其友好不需要自己编译模型一个安装包搞定模型加载向量库的默认配置也够用。真正要花心思的不是工具而是数据文档解析得干不干净、切分策略合不合理、评估集建得靠不靠谱——这些才是项目成败的分水岭。5.3 文本拆解chunking的工具与策略热搜里很多人问有没有本地的 RAG 文本拆解工具。工具反而是最容易解决的Unstructured、LlamaIndex 的节点解析器、LangChain 的文本切分器都支持本地运行。难的是拆解策略。固定长度切分是最简单的方案按字符数或 token 数硬切实现成本低但切出来大量语义断裂的块。结构感知切分更适合药企文档优先按标题层级识别章节边界再按段落、表格、列表边界切最大程度保证语义完整。语义切分是更进阶的方案借助模型判断文本语义变化点来切效果最好但计算成本高。药企文档还有一种高频情况的特殊处理表格。质量标准和检验报告里大量信息藏在表格里直接按文本切分会把表格撕碎。我们在实践中会先把表格转换成结构化文本或 Markdown 格式再切分某些关键表格甚至可以单独作为独立的检索单元查询时单独建立索引。另外推荐一个性价比极高的思路父子切分。文档按粗粒度切成大块用于上下文补全同时按细粒度切成小块用于向量检索。检索命中小块后回填所在的大块作为 LLM 生成时的上下文。这个方案在处理长文档时很管用等于拿到了两者的优点。5.4 知识库形态取舍向量库、知识图谱、结构化数据库药企 RAG 项目进行到中期一定会遇到一个灵魂拷问只用向量库够不够要不要上知识图谱或结构化数据库。我给的直接答案是早期全部用向量库打底遇到两类问题再考虑其他形态。第一类是多跳关系问题。比如A 产品的某个辅料是否与 B 产品的稳定剂存在配伍禁忌这种问题需要把多个文档中的实体抽取出来建立关联纯向量检索很难在单个检索过程中串起多条关系链。这时知识图谱或 ontology 能帮上忙但要清醒地认识到图谱的构建和维护成本极高——药企文档更新频繁图谱的实体抽取和关系更新都要持续投入。不要因为看到图谱的概念时髦就盲目上你的业务问题如果八成可以通过文档检索解决那图谱只是锦上添花。第二类是标准化数据查询。批号对应的生产日期、某限度的具体数值、某设备的校验周期这类可枚举的数据放进结构化数据库更合适查询准确且响应稳定。RAG 生成面对结构化数据往往吃力不讨好模型擅长的是从非结构化文档里提取和转述而不是做数据库运算。另一种常见疑问是 RAG 知识库能不能存图片。答案是看场景如果用户的查询依赖图片内容比如仪器图谱、色谱图需要多模态 Embedding 才能支持如果图片只是文档里的插图存不存向量都不会显著影响问答质量。药企场景里图谱类数据的处理通常是专业的仪器软件在做不太会走 RAG 这条链路所以这个方向值得做但不是优先级最高的点。5.5 常见问题排查速查表最后把这次项目里遇到的典型问题整理成一张速查表后续遇到同款症状可以直接对照排查。症状可能原因处置建议检索不到正确文档Embedding 模型对领域术语不敏感换用领域适配的 Embedding 模型扩充同义词典检索命中但排位靠后chunk 过大导致语义稀释改为结构感知切分或启用父子切分答案包含文档中没有的内容生成阶段幻觉加事实校验层提高忠实度指标权重约束模型只依据给定文档作答引用位置与内容不匹配检索块与生成依据不一致检查上下文拼接逻辑保证所有引用取自实际传入的上下文切片宽松指标高分但严格评分低评估指标单一、缺乏忠实度校验上多维度评估体系和 LLM-as-Judge 裁判自动化评分与人工判断差异大裁判提示词缺少案例校准用人工标注集校准裁判模型提示词加入红线扣分规则同义提问效果差异明显知识库没有做同义词归一构建同义词表在 Embedding 入库前做归一化改写长文档关键信息断裂固定长度切分切断语义换用结构感知切分表格单独处理这个表看起来简单但每条背后都对应过真实的线上踩坑经历。特别是第一行和第四行药企项目里出现的频率非常高值得重点排查。我做完这个项目最大的体会是RAG 系统本身是能被工程手段不断逼近业务要求的但评测体系没搭对后面所有优化都是在打转。这次 95 分和 85 分的差异反而帮客户把验收口径定清楚了——后续每一次迭代都有一套可靠的裁判系统在把关。如果你正在做一个 RAG 项目我会建议你先花两周时间把评估集和评分口径做扎实再开始调模型。这个初期投入比换更大的模型、调更多的参数都值。