企业官网建设流程全解析

上一周我们团队在药企客户现场做 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 系统的评估拆成三层。检索层的指标衡量的是"能不能把相关文档找回来"，常见的有 Recall@K、命中率、MRR（平均倒数排名）。生成层的指标衡量的是"生成内容是否对题、是否答全"，典型代表是 Answer Relevance 和 Completeness。忠实层的指标衡量的是"生成内容是否有源可依、有没有幻觉"，例如 Faithfulness、幻觉率。

用个生活化的比方：检索层是图书管理员有没有找对书架，生成层是你能不能把书里的内容转述清楚，忠实层是转述时有没有自己加戏。三个环节层层递进，任何一个出问题都会让最终回答质量塌方。

很多团队做 RAG 评测时只盯检索层指标，觉得"检索命中率高系统就靠谱"。你看完前面那个现场就应该明白，检索层指标完全无法覆盖生成层的错误。我们的系统检索命中率不低，但 70% 的扣分发生在生成阶段。检索层指标是整个评测金字塔的基座，但它离业务效果还隔着两跳。

2.2 检索好不等于回答好

这里有一个很多人没意识到的细节：检索召回和最终回答质量之间没有强线性关系。检索召回率达到 95%，但相关文档排在几十条无关文档之后，LLM 上下文窗口有限，被大量噪声内容稀释，生成质量照样会崩。反过来，检索召回率只有 80%，但如果那 80% 里恰好包含了最关键的文档，且顺序排得靠前，生成效果反而很好。

所以当你看到某个 RAG 项目汇报"检索召回率 98%"的时候，先别急着高兴。你要追问的是：召回回来的文档排在第几位？Top3 命中率是多少？这些文档是否真的被模型拿来作为回答依据？这些信息比一个孤零零的召回率有说服力得多。

RAG 评测领域有一组常用组合：Recall@K 加 MRR 加上下文相关性。Recall@K 看命中是否在 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 验收的完整指标体系，我认为至少要有三套并行。第一套是检索侧指标：Recall@K、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 常见问题排查速查表

最后把这次项目里遇到的典型问题整理成一张速查表，后续遇到同款症状可以直接对照排查。

这个表看起来简单，但每条背后都对应过真实的线上踩坑经历。特别是第一行和第四行，药企项目里出现的频率非常高，值得重点排查。我做完这个项目最大的体会是：RAG 系统本身是能被工程手段不断逼近业务要求的，但评测体系没搭对，后面所有优化都是在打转。这次 95 分和 85 分的差异，反而帮客户把验收口径定清楚了——后续每一次迭代都有一套可靠的裁判系统在把关。如果你正在做一个 RAG 项目，我会建议你先花两周时间把评估集和评分口径做扎实，再开始调模型。这个初期投入比换更大的模型、调更多的参数都值。