16. 在什么场景下，你会选择使用图数据库来增强传统的向量检索？
我的判断是，当业务问题涉及多个实体之间的关联推理的时候，就需要考虑引入图数据库来增强。
向量检索有一个根本的局限，它只能做单跳检索，找和问题直接相关的文档，没办法沿着实体之间的关系链做推理。比如你问公司 A 的投资方和公司 B 有什么交集，单纯向量检索就很难处理了，因为答案不在某一段文档里，而是藏在多个节点之间的关系上。
这时候图数据库就能发挥作用，沿着关系边一跳一跳地把关联信息收集回来。我接触过的典型场景有企业关系分析、医疗知识图谱、代码依赖关系查询、供应链溯源这些。
向量检索能做什么，做不到什么
先从向量检索的工作原理说起。向量检索做的事情是：把用户的问题转成一个向量，然后在知识库里找「向量最接近」的文档片段，把它们拼到 prompt 里给 LLM 用
这套逻辑在很多场景下效果很好，比如「什么是 Transformer」「Python 的 GIL 是什么」这类问题，答案往往就在某一段文档里，向量检索一跳就找到了。
但是，向量检索有一个根本限制：它是「单跳」的，也就是每次只能找和问题直接相关的内容，没办法沿着实体之间的关系链往下追。
你可能会想，那我多检索几次不就行了？
遗憾的是，不行。
原因很简单：多检索几次的前提是你知道「下一步该搜什么」，但向量检索根本没有「关系」这个概念，它不知道实体 A 和实体 B 之间有一条边，更不知道该沿着哪条边继续走。就像你在一个陌生城市里问路，别人只告诉你「附近有家店」，但不会告诉你「从这家店出发往东走 200 米还有一家」，你没法靠反复问「附近有什么」来拼出一条完整的路线。
来看几个向量检索真的答不上来的问题。
「小米的主要竞争对手的 CEO 是谁」，这个问题需要先找到「小米的竞争对手是谁」，再拿着这些名字去找「谁是他们的 CEO」，两步之间有实体跳转，向量检索每次只能走一步，第二跳就断了。
「治 A 疾病的药和治 B 疾病的药有没有药物相互作用」，答案藏在「药物 -> 作用靶点 -> 相互作用」这条多节点路径上，没有一篇文档会把这个结论直接写出来。
「这个函数直接和间接依赖的所有第三方库有哪些安全漏洞」，需要沿代码依赖链一层层展开,每一跳都是新的查询。
这些问题的共同特征是：答案不在某一个文档里，而是藏在多个节点之间的「关系」上，要沿着边一跳一跳地走才能拼出完整答案。理解了这个局限，图数据库存在的意义就很好懂了。
图数据库是干什么的，为什么能解决这个问题
向量检索做不到多跳遍历，这个能力缺口恰恰是图数据库的强项。图数据库专门用来存「实体和关系」，它把世界表示成一张网：每个节点是一个实体（比如公司、人、疾病、药物），每条边是一种关系（比如「投资」「竞争」「治疗」「副作用」）。有了这张网之后，就可以做「图遍历」：从一个节点出发，沿着关系边一跳一跳地走，把路径上所有相关节点的信息都收集回来。这正好补了向量检索的短板。
很多人以为图数据库是向量检索的「升级版」，上了图就可以替代向量检索了，其实不是这样。图数据库也有自己的局限：传统的图查询语言（比如 Cypher）擅长的是精确关系查询，「从 A 出发沿着这条边走到 B」，对「语义相似」这种模糊匹配不擅长（现代图数据库如 Neo4j 虽然也在加向量索引能力，但那本质上是把向量检索嫁接进图里，不是图遍历本身在做）。
比如用户问「手机充电慢怎么办」，这种问题没有明确的实体关系可以遍历，图数据库帮不上忙，但向量检索可以从知识库里找到语义相近的故障排查文档。所以实际系统里，这两种技术是互补的，不是替代关系。
向量检索 + 图数据库的组合用法
既然两者是互补的，那具体怎么搭配使用呢？
两者组合起来的工作流是这样的：向量检索先作为「入口」，用户问「小米的竞争对手 CEO 是谁」，先用向量检索找到和「小米」相关的文档片段，从中识别出关键实体，定位到「小米」这个节点。
接下来，图数据库接力做「关系遍历」，拿到入口实体之后，在图里沿着关系边一路走：「小米」-> 竞争关系 ->「OPPO、vivo、荣耀」-> CEO 关系 -> 对应人名，把沿途经过的节点信息都收集回来。
最终，把向量检索结果和图遍历结果合并，一起塞给 LLM 生成回答。
打个比方，向量检索像是「导航定位」，帮你找到出发点在哪；图遍历像是「沿着路线一站一站走」，帮你把沿途经过的所有站点信息都收集起来。前者解决「在哪」的问题，后者解决「能到哪」的问题，合在一起才能给出完整答案。
这样，LLM 拿到的上下文既有语义相关的文档片段，也有沿关系链追出来的关联信息，两者互补，回答就完整了。
哪些场景真的需要图数据库
理解了两者的组合方式，接下来的问题就很实际了：什么场景下值得花精力引入图数据库？不是所有 RAG 系统都需要上图数据库，它主要在以下几类场景有价值。
企业关系分析是最典型的场景。金融、投资领域的知识库里，企业之间的股权关系、人员之间的任职关系错综复杂。如果只用纯向量检索，问「X 基金投资的公司里有哪些跟 Y 集团存在竞争」，基本答不上来，因为这个关系链不会在某篇文档里直接写出来。但在图里，这一趟遍历几秒钟就出来了。
医疗知识图谱也是图数据库的强项。疾病、症状、药物、基因之间有大量关联，如果只用向量检索，「某个基因突变会导致哪些疾病，这些疾病又有哪些共同的治疗方案」这种沿着多层关系链追溯的问题根本无从下手，因为没有一篇文档会把这条完整的链路写在一起。图遍历反而很自然。
代码知识库同样适合。函数调用关系、模块依赖关系可以建成图，「这个接口被哪些上游服务直接和间接调用」在图里走一遍就出来了。靠文本检索的话，你得一个个文件翻，几乎不可能做到。供应链溯源也类似，原材料 -> 供应商 -> 成品 -> 分销商，这种层级关系天然适合图结构存储和查询，追溯某批次产品的所有上下游环节，图遍历是最自然的解法。
什么时候不值得上图数据库
看了上面的场景，你可能会觉得图数据库这么好用，是不是所有 RAG 都该上一个？
别急，图数据库的代价不小：你需要用 LLM 做「实体抽取」和「关系抽取」来把非结构化文档转成图结构，这个过程成本高、容易出错，而且后续维护图结构比维护向量库复杂得多。
如果用户的问题大多数是「找某个概念的解释」「某个功能怎么用」，向量检索加上 Rerank 已经够用了，强行上图数据库是过度设计。
判断要不要用图数据库的简单原则：问题里是否同时出现多个具体实体名，并且在问这些实体之间「有什么关系」或「通过关系能找到什么」 。如果是，就值得考虑图增强；如果问题主要是找某段描述性的内容，向量检索就够了。
17. 如何规避 RAG 系统中大模型的幻觉？
我遇到过的 RAG 幻觉主要有两类。第一类是检索没有召回到相关内容，LLM 没有可用的上下文，靠自身知识在编造答案。第二类是检索内容召回了但 LLM 没有严格遵循，在文档内容的基础上加了自己的推断。我用来规避幻觉的策略主要有四个方向：第一是 Prompt 强约束，明确告知 LLM 只能根据提供的资料回答，资料里没有的就说不知道；第二是检索质量门控，Rerank 分数低于阈值就直接拒答，不让 LLM 在低质量上下文上硬撑；第三是生成后引用核查，每个关键的声明都要在 chunk 里找到来源依据；第四是结构化输出强制溯源，让 LLM 输出 JSON，每条结论必须附上来源编号。其中 Prompt 强约束加检索质量门控是我觉得成本最低、收效最快的组合，生产系统上线前这两个必须做。
幻觉是什么，为什么 RAG 里会有幻觉？
先说「幻觉」这个词是什么意思。LLM 的幻觉，就是模型一本正经地说了一件压根不存在的事。它不是在撒谎，它只是在「预测下一个词」，当它没有可靠依据时，就会拼凑出一个「听起来合理」的答案，但内容可能是错的。
你可能会想：RAG 不是已经把知识库的内容塞进 prompt 了吗，LLM 为什么还会编造？很多人以为做了 RAG 就不会有幻觉了，这是一个非常常见的误区。问题是，塞进去不等于 LLM 一定会「老老实实照着说」。LLM 有自己的「知识储备」（来自预训练），当 prompt 里的资料和它平时「学到的」不一致，或者 prompt 里根本就没召回到相关内容，它就可能绕开资料、自己发挥。
所以 RAG 里的幻觉有两个完全不同的来源，要分开理解：
第一种：检索层没找到，LLM 靠「猜」回答。
这是最根本的问题。RAG 的前提是「检索到了相关内容再生成」，但如果检索这一步失败了，向量没找到相关的 chunk，prompt 里就是空的或者全是不相关的内容，LLM 会怎么做？它不会说「我不知道」，它会用自己训练时见过的知识编一个看起来像答案的东西。这个答案可能和你知识库里的内容完全相反，而且 LLM 说得很自信，用户根本看不出来。
举个具体例子：你的知识库里记录的退款政策是「7 天无理由退款」，但某次检索没召回到这个 chunk，LLM 用自己的「知识」给出了「30 天退款」的答案，用户按这个信息去操作，结果退款失败，这就是检索层幻觉造成的实际损失。
第二种：检索到了，但 LLM 没有严格照着说。
那检索到了就安全了吗？也不是。这种幻觉更隐蔽，也更常见。相关的 chunk 确实被召回了，塞进 prompt 里了，但 LLM 在生成答案时「超发挥」了，它把资料里的内容作为基础，然后加了自己的推断、补充了原文没有的细节、甚至把两段不相关的信息混在一起拼出一个「更完整」的答案。读者很难分辨哪句话来自文档、哪句是 LLM 加的。
这两种幻觉的根源不同，解法也不一样。下面四个方案，是从「成本最低」到「机制最严格」依次递进的思路。
方案一：用 Prompt 告诉 LLM「只准照着资料说」
这是成本最低、最容易上手的方案，效果也立竿见影。很多人搭 RAG 时只是把 chunk 塞进 prompt，然后问「请回答这个问题」，并没有明确约束 LLM 的行为。LLM 就会觉得「这些资料只是参考，我可以结合自己的知识一起回答」，幻觉就这样产生了。
修复方法很简单：在 system prompt 里明确立规矩，只能用资料里的内容、资料里没有就说不知道、不准推断和补充。这几条规则，每一条都有它的道理：
回答规则：
- 只能使用【参考资料】中的信息来回答，不得引入资料之外的知识
- 如果参考资料中没有足够信息，必须明确回答：「根据现有资料，无法回答该问题」
- 回答时标注信息来源（来自哪条参考资料）
- 不要推断、不要猜测、不要补充资料中没有明确说明的内容
第一条的作用是让 LLM「知道自己的边界」，明确告诉它，你只是个传话人，不是百科全书，只能照资料说话。第二条给了 LLM 一个「合法的逃生出口」，当资料里没有答案时，说「不知道」比编一个看起来合理的答案要好得多，这条规则允许 LLM 优雅地认怂。第三条让 LLM 在回答时主动对照原文，相当于给它加了一个自检动作，哪句话来自哪条资料必须说清楚。
这个方案能压制「生成层幻觉」，但对「检索层幻觉」帮助有限，如果 prompt 里根本就没有相关内容，再强的约束也顶不住 LLM 瞎编。所以还需要下面这个方案配合。
方案二：检索质量差时，直接拒绝回答
方案一解决了「LLM 超发挥」的问题，但如果检索这一步就失败了，prompt 里全是无关内容，光靠 Prompt 约束是拦不住的。那怎么办？与其让 LLM 在低质量的上下文里强行生成一个「可能是错的答案」，不如直接告诉用户「知识库里没有这个信息」。前者让用户误以为答案是对的，后者虽然看起来不那么智能，但至少不会给用户错误信息。
怎么判断检索质量够不够好？用 Rerank 模型打分。整个流程很直接：检索召回 top-K 个候选 chunk，Rerank 模型对每个候选打一个 0 到 1 的相关度分数，然后看最高分的值。如果最高分低于阈值，说明这次检索根本没找到有用的内容，直接返回「知识库无相关信息，建议联系人工」，不让 LLM 强行回答；如果最高分达标，就把所有达标的 chunk 筛出来喂给 LLM。
这个阈值到底设多少？没有通用数字，得按你自己的业务数据调。调法是拿一批「已知答案在知识库里」和「已知答案不在知识库里」的测试集跑一遍，看 Rerank 分数分布，找那个能把两类分开的切点。一般经验值在 0.3 到 0.6 之间：对精度要求高（金融、医疗）偏高，对召回率宽松（闲聊型问答）偏低。先从中间值开始，根据线上误判的样例往上或往下调。
你可能会觉得，「拒答」这个行为会让系统显得很笨。但反过来想：用户问了一个知识库覆盖不到的问题，最好的答案就是「我不知道，请联系人工」，而不是 LLM 编一个听起来合理但实际错误的回答。答错比不答更危险。
结合方案一和方案二，就能同时压制两类幻觉：方案二负责「检索质量差时不让 LLM 胡说」，方案一负责「检索质量还行但 LLM 容易超发挥时把它框住」。这两个是 RAG 系统上线前的基础配置，成本也最低。
方案三：答案生成后，逐条核查有没有「凭空捏造」
前两个方案都是在「生成之前」做防控，那万一还是漏了呢？这个方案就是在「生成之后」做校验。思路是：LLM 生成完答案，再用另一个 LLM（或者同一个 LLM）回头检查，答案里的每一条关键信息，在 chunk 里有没有对应的依据。没有依据的内容，标注「无法核实」或者直接删掉。实现方式是发起「第二次 LLM 调用」，把原始答案和 chunk 一起送给 LLM，让它充当编辑角色，逐条核查每个声明有没有来源支撑。就像文章写完还要请编辑审阅一遍，方案一是事前约束作者的行为，方案三是事后审稿。
这个方案的代价是多一次 LLM 调用，响应延迟会增加，成本也会翻倍。所以一般只在对准确性要求极高的场景使用，比如医疗问诊、法律咨询，答错了代价很大的地方。普通的企业知识库问答，方案一 + 方案二组合通常已经够用。
方案四：强制 LLM 输出时带上来源编号
如果说方案三是在内容层面做校验，那方案四就是在格式层面做约束，和方案一的「Prompt 约束」配合使用效果更好。让 LLM 输出结构化的 JSON，每个结论都必须填写来自哪条参考资料的编号。这样一来，用户看到答案的同时就能看到来源，系统也可以自动验证每条结论的来源 ID 是不是真实存在。LLM 输出的格式大致是这样：
{
"answer": "完整回答",
"statements": [
{"claim": "具体结论1", "source_ids": [1, 2]},
{"claim": "具体结论2", "source_ids": [3]}
],
"confidence": "high/medium/low"
}这个方案为什么有效？
原因有两个：一是 LLM 在构建 JSON 时必须主动想「这条结论我从哪条资料里找到的」，这个过程本身就会减少瞎编的概率，就好比你让学生写论文必须标注参考文献，他自然就不敢随便编了；二是系统拿到 JSON 后可以做程序化验证，source_ids 里的编号如果对应的 chunk 和 claim 明显不相关，就可以自动过滤掉这条结论。
四个方案怎么组合？
从易到难，按场景递进来看：普通的企业知识库和客服问答，方案一加方案二是必须做的基础配置，成本极低，幻觉问题能解决大半；对可信度要求高的场景，比如金融分析、法律文档，再加上方案四，让每条答案都带上来源编号，用户可以自己去原文核实；对准确性要求极高、容错率极低的场景，比如医疗问诊、合规审核，答错了代价很大，这时候四个方案全上，在延迟和成本上付出代价，换取最高级别的准确性保证。
说到底，规避幻觉没有一劳永逸的银弹。最重要的认知是：检索质量是幻觉的最大来源，检索到了正确的内容，Prompt 再稍微约束一下，幻觉就已经少很多了；如果检索这一步就烂，再多的生成层约束也填不了这个坑。所以治幻觉，先治检索。
18. 怎么量化你的 RAG 效果？
我评估 RAG 效果是分两层来看的。
检索层看该召回的有没有召回到，我用 Hit@K 和 MRR 来衡量。生成层看答案对不对、有没有幻觉、和问题相不相关，我主要用 RAGAs 框架，里面的 Faithfulness、Answer Relevancy 和 Context Recall 这三个指标是最核心的。
我的建议是一定要在自己的业务数据上跑，不能只看通用排行榜，那个不能代表你的场景。
另外线上指标，就是用户的点踩率、追问率、转人工率这些，才是最终的衡量标准，离线指标只是辅助。
什么是 RAG 评估？
RAG 评估，就是用一套可量化的指标体系，持续测量 RAG 系统「回答得好不好」，并且能把「好不好」这个笼统的感受，拆解成具体是哪个环节出了问题。
你可能会问，为什么非得强调「持续」？
因为 RAG 系统不是搭完就一劳永逸的。知识库在更新，用户的提问方式在变化，Embedding 模型可能要换，Chunking 策略可能要调，每一次改动都可能让效果变好或者变坏。没有评估体系，你就是在盲飞，不知道自己的优化到底有没有用，甚至不知道改完之后系统是变好了还是变差了。
为什么需要 RAG 评估？
很多团队早期不做系统性评估，靠「人工抽查几条觉得还行」就上线了。
这种方式的问题很明显。
首先，靠感觉调优没有方向。改了 Chunking 策略、换了 Embedding 模型，系统效果有没有提升？抽查几条根本说明不了问题，样本太少，结论不可靠。
其次，出了问题不知道该查哪里。用户反馈「AI 回答错了」，你不知道是检索没召回到正确内容，还是召回了但 LLM 编造了额外信息，还是 Prompt 设计有问题。没有分层指标，排查就靠猜。
再者，优化后无法验证收益。你花了时间调优，但到底优了多少？没有数字说话，技术决策缺乏说服力，也无法判断下一步该在哪里继续投入。
RAG 评估的本质，是把「这套系统好不好用」这个主观感受，转化成一组可以追踪、可以对比、可以指导决策的客观数字。
为什么 RAG 评估很难
说完为什么需要，你可能会想：评估嘛，不就是对答案吗，有什么难的？事实上，RAG 评估比想象中难做得多。
普通分类任务评估很简单，有标准答案对比就行。RAG 的评估难在几个地方：答案是自然语言，没有唯一标准答案；出了问题不知道是检索层的锅还是生成层的锅；人工标注成本高，难以大规模持续做。
正确的做法是把评估拆成两层，分别衡量检索质量和生成质量，定位问题更精准。先看检索层。
第一层：检索层评估
不管 LLM 生成什么，先单独评估检索有没有把正确的 chunk 召回来。需要准备一批「问题 + 对应的正确 chunk ID」的测评数据（可以从历史问答里标注，也可以让领域专家整理）。
这一层主要有两个指标。
Hit@K 的直觉是：我把 Top-K 的检索结果摆在你面前，你要找的那个在里面吗？如果在，这次就算命中（Hit）。Hit@5 就是说，把前 5 个结果给你，能不能命中，最终统计命中率。
这个指标回答的是「找到没」的问题，不关心找到的是第几名。一般 Hit@5 低于 0.7 就说明检索层有问题，需要考虑换 Embedding 模型或者优化 Chunking 策略；高于 0.8 说明检索层 OK，如果答案还不好，问题在生成层。
MRR （Mean Reciprocal Rank，平均倒数排名）更进一步，关心的是「你要找的东西排在第几名」。计算公式也很直观，就是对每个问题算 1 / 排名，然后对所有问题求平均。所以第一名找到得 1 分，第二名找到得 0.5 分，第三名得 0.33 分，第五名得 0.2 分，排名越靠后得分越低。MRR 越高，说明正确内容排名越靠前，用户越早看到它。这个指标回答的是「多快找到的」。MRR 低于 0.5 通常说明 Rerank 效果不够好，正确内容召回了但没排到前面。
很多人容易混淆这两个指标，觉得差不多。简单来说：Hit@K 是「找到没」，MRR 是「多快找到的」 。Hit@5 等于 0.9，说明 90% 的问题都能在前 5 个结果里找到相关内容；但 MRR 只有 0.3，说明相关内容虽然找到了，但排得很靠后，可能第 4、第 5 才出现。配合起来用能精确定位检索层的问题出在哪一步。
第二层：生成层评估（RAGAs 框架）
检索层评估回答了「找没找到」的问题，但找到之后 LLM 有没有好好利用这些内容？这就需要生成层评估。RAGAs（Retrieval Augmented Generation Assessment）是目前使用很广泛的 RAG 端到端评估框架，它的核心思路叫做「LLM-as-a-Judge」，意思是用 LLM 来当裁判，自动给答案打分，不需要人工标注每一条，大幅降低评估成本。
它有四个核心指标，分别是 Faithfulness、Answer Relevancy、Context Recall 和 Context Precision，每个都有直观的理解方式，下面挨个讲。
Faithfulness（忠实度）：答案里说的每件事，在检索到的 chunk 里有没有出处？这个指标衡量的是幻觉程度。你可以把它理解为「LLM 裁判」在逐句问：「这句话你从哪条资料里找到的依据？」没有依据的句子越多，分越低。目标值是 > 0.8。
Answer Relevancy（答案相关性）：答案有没有回答用户问的那个问题？注意这个指标和 Faithfulness 是两回事，很多人会把它们搞混。Faithfulness 是问「说的是不是真的」，Answer Relevancy 是问「说的是不是用户想要的」。一个答案可以字字有据、但完全跑题，Faithfulness 高、Answer Relevancy 低。
打个比方，你问「北京天气怎么样」，AI 回答了一篇关于北京历史的资料，内容全是对的，但和天气没有半毛钱关系，这就是 Faithfulness 高、Answer Relevancy 低。目标值是 > 0.8。
Context Recall（上下文召回率）：要回答这个问题，所需要的信息有多少比例在检索结果里覆盖到了？这个指标需要有「标准答案」作为参照，衡量的是检索层有没有「漏掉该找到的内容」。目标值是 > 0.7。
Context Precision（上下文精确率）：这个指标和 Context Recall 配对出现，衡量的是检索结果里「有用的内容」排名是否靠前。也就是说，如果你召回了 10 个 chunk，相关的那几个有没有被排在前面，而不是混在无关内容的后面。它同样需要 ground_truth 作为参照计算。Context Recall 关注「该找的有没有找全」，Context Precision 关注「找到的里面相关的是不是排在前面」，两个配合能完整刻画检索质量。
需要注意的是，RAGAs 本质上是「LLM-as-a-Judge」，每次评估都要调用 LLM 来打分。如果测试集有几千条，全量跑一遍的 token 消耗和时间成本相当可观。工程上通常有两种缓解方式：一是对核心测试集抽样评估，只跑最有代表性的 200～500 条；二是把评判者模型从 GPT-4o 降级到 GPT-4o-mini，成本降低 10 倍，精度损失在可接受范围内。
通过指标定位问题
有了这些指标，怎么用它们来定位问题？不同指标低说明不同的问题，指导优化方向。
Context Recall 低，你可以把它理解为「检索结果里缺少了答好这道题必要的信息」，说明检索层没召回到正确内容，优化方向是换更强的 Embedding 模型、调整 Chunking 策略、或者加多路召回来补充覆盖面。
Context Precision 低，说明检索召回了太多噪音，相关内容是找到了，但不相关的内容也混进来了，把 LLM 的注意力稀释掉了，优化方向是加强 Rerank 模型、调低最终送给 LLM 的 chunk 数量。
Faithfulness 低，说明 LLM 在编造，幻觉问题多，你回答里说的东西在参考资料里找不到依据，优化方向是加强 Prompt 约束、引入引用核查、或者做检索质量门控，防止低质量上下文进入生成阶段。
Answer Relevancy 低，说明答案跑题了，没有聚焦在用户问的问题上，通常是 Prompt 的指令不够明确，告诉 LLM「请严格回答问题本身，不要展开无关内容」往往就能改善。
线上指标：最终衡量标准
上面说的都是离线指标，但离线指标再好，最终还是要看线上用户的反应。毕竟离线跑得再漂亮，用户不满意也是白搭。
几个实用的线上指标，每一个都能反映 RAG 系统的某个方面。
踩率（thumbs_down_rate）是最直接的信号，用户主动点踩，说明这次回答让他不满意，是最真实的负反馈。
追问率（followup_rate）反映的是「答非所问」的程度，用户紧接着说「你没回答我的问题」或者追问同一个问题，通常意味着上一次回答没用。
转人工率（escalation_rate）衡量的是「RAG 放弃回答」的频率，这个比例太高说明知识库覆盖不足；但如果这个比例因为加了质量门控而上升，不一定是坏事，宁可转人工也不要给用户错误答案。
空回答率（answer_empty_rate）就是系统主动说「我不知道」的比例，过高说明知识库亟需扩充。
会话解决率（session_resolution_rate）是最综合的指标，衡量「一次对话能不能解决用户的问题」，是最贴近用户体验的衡量维度。
离线评估（Hit@K + RAGAs）用来快速迭代和定位问题，线上指标（踩率、转人工率）是最终验收标准。两者结合，形成「离线测评 -> 上线 -> 线上观测 -> 发现问题 -> 离线复现 -> 修复 -> 再上线」的完整评估闭环。
这里还要提醒一点：离线指标好不代表线上一定好，反过来也一样。常见的情况是离线测试集不能完整代表真实用户分布，或者离线指标优化过头反而损害了线上体验（比如为了 Faithfulness 把 Prompt 收得太死，结果模型回答过于保守、用户觉得不好用）。所以两者要定期交叉对照，发现偏差时往往是测试集需要更新或者指标权重需要调整。
检索层用 Hit@K 和 MRR 衡量召回质量，生成层用 RAGAs 框架的 Faithfulness、Answer Relevancy、Context Recall 来衡量答案质量，线上再用点踩率、转人工率等业务指标做最终验收。
通过不同指标的组合，可以精确定位问题是出在检索层还是生成层，让优化有方向、有数据支撑，而不是凭感觉瞎调。