QontoFAQ，重新定义 RAG 检索

截至 2026 年 9 月 22 日，Qonto 团队开源了 QontoFAQ 基准及配套代码，试图重新回答一个被 RAG 系统长期模糊处理的问题：检索器找到的文档，究竟是不是真的能回答用户的问题？

QontoFAQ 是一个面向真实产品问答场景的信息检索评测基准，核心目标是评估嵌入模型能否把用户问题匹配到“足以回答问题”的产品文档，而不只是找出文本表面相似的内容。

这件事看起来不像又一个向量检索排行榜，但它击中了当前 RAG 评测里最容易被忽略的盲区：传统指标往往擅长判断“答案文档有没有排进 Top-K”，却不一定能判断“排在前面的文档能不能解决用户的问题”。

RAG 最大的问题，不是不会生成，而是找错了依据

RAG 是一种先检索外部知识、再让大模型基于检索结果生成答案的架构。它把大模型的回答能力和企业知识库、产品文档或内部数据库连接起来，但最终答案的上限通常取决于检索阶段能否找到正确证据。

在客服、金融、SaaS 帮助中心等场景里，“语义相似”与“能够回答”经常是两回事。

例如，用户问：“我的账户为什么还没有完成验证？”知识库里可能同时存在以下几篇文章：

• 如何提交身份验证材料；
• 身份验证通常需要多长时间；
• 验证失败后的重新提交流程；
• 企业账户和个人账户的审核差异；
• 某些国家或地区的额外合规要求。

这些文档可能都包含“验证”“账户”“审核”等高频词，也可能在向量空间中距离很近。但真正能回答当前问题的，可能只有“验证状态与处理时间”那一篇。如果检索器把“如何提交材料”排在第一位，后面的生成模型即使语言组织能力再强，也很难凭空补出正确答案。

这正是 QontoFAQ 的切入点：评测重点不应只是文档与问题“像不像”，而应是文档对问题“有没有用”。

传统 Recall@K，为什么会把问题说得过于简单

Recall@K 是一种衡量正确文档是否出现在前 K 个检索结果中的指标。它回答的是“正确文档有没有被召回”，但没有充分回答“正确文档是否排在更有用的位置”。

在很多检索基准里，只要标注文档出现在 Top-10，系统就能拿到不错的召回成绩。但对真实产品问答来说，Top-10 并不等于可用：上下文窗口有限，排序靠后的文档很可能根本不会进入最终提示词；即使进入，也可能被更多相似但无关的内容稀释。

更麻烦的是，传统数据集中的问题和答案往往经过人工整理，表达方式比较规整。真实用户却会使用口语化、含糊甚至带有上下文缺失的问法，例如“这个费用能不能退”“为什么还没到账”“公司账户也一样吗”。模型在这种问题上的表现，不能完全由标准问答数据集推断出来。

QontoFAQ 的价值在于，它把评测目标拉回到了产品支持的真实任务：找到能够解释规则、限制条件或操作步骤的文档，而不是找一段看起来最接近的文字。

QontoFAQ 的核心变化：从“文档相关”转向“问题可回答”

QontoFAQ 提出了一种更贴近文档实际用途的相关性评测思路。它不再简单地把文档划分为“相关”与“不相关”，而是试图区分文档对当前问题的实际回答价值。

这类设计的重要性在于，产品文档之间往往存在多个层次的相关性：

1. 主题相关：文档讨论的是同一个产品或功能。
2. 语义相关：文档中的词语和用户问题比较接近。
3. 问题相关：文档确实覆盖了用户想了解的具体情况。
4. 决策相关：文档包含用户下一步行动所需的规则、条件或例外。

传统向量检索通常能够较好地处理前两层，但真实问答真正需要的是第三层和第四层。

举例来说，“如何关闭账户”和“关闭账户后还能恢复吗”都属于账户生命周期主题，语义上也高度接近。但前一个问题需要操作步骤，后一个问题需要解释关闭后的状态和恢复条件。两者共享大量词汇，却对应不同的答案文档。

从这个角度看，QontoFAQ 评测的不是单纯的语言相似度，而是嵌入模型是否理解了产品问题背后的任务意图。

它主要用来评估什么

QontoFAQ 目前主要面向信息检索和嵌入模型评测，而不是完整的端到端 RAG 生成评测。换句话说，它首先关心“检索器找得对不对”，再把生成模型是否忠实、是否完整等问题留给后续评测体系。

嵌入模型是把文本转换成向量、用于计算语义距离的模型。在 RAG 中，它通常负责把用户问题和知识库文档映射到同一个向量空间，再根据距离或相似度返回候选结果。

如果嵌入模型只捕捉到了词面相似性，就可能出现以下问题：

• 把“退款多久到账”匹配到“如何申请退款”；
• 把“企业账户是否支持某功能”匹配到“个人账户功能说明”；
• 把“为什么交易失败”匹配到“如何发起交易”；
• 把当前版本规则匹配到旧版本帮助文档；
• 把解释限制条件的页面排在泛化介绍页面之后。

QontoFAQ 通过产品 FAQ 场景构建测试数据，并使用新的相关性衡量方式，试图让这些差异在排名结果中更明显地体现出来。

QontoFAQ 与传统检索指标的区别

QontoFAQ 并不是要彻底取代 Recall@K、MRR 或 NDCG，而是希望补上这些指标对“文档是否真正能解决问题”刻画不足的部分。

| 指标或方法 | 主要回答的问题 | 优点 | 局限 | |---|---|---|---| | Recall@K | 正确文档是否进入前 K 个结果 | 简单直观，适合衡量召回覆盖 | 不关注正确文档的具体位置和回答价值 | | MRR | 第一个正确结果排得有多靠前 | 能反映首个命中文档的排名 | 通常把相关性简化成二元判断 | | NDCG | 多个相关结果的排序质量如何 | 能处理分级相关性 | 标注成本和指标解释复杂度更高 | | 余弦相似度 | 两段文本在向量空间中有多接近 | 计算成本低，适合大规模召回 | 相似不等于可回答 | | QontoFAQ 思路 | 文档能否真正回答产品问题 | 更贴近真实 FAQ 和客服场景 | 依赖高质量问题、文档和相关性标注 |

QontoFAQ 最值得关注的地方，是它把“相关性”从一个过于粗糙的二元标签，推进到更接近业务目标的判断：这篇文档对当前问题到底有多大帮助。

这种改变会直接影响模型排名。一个只提供背景介绍的页面，可能与问题非常相似，但它未必应该排在包含明确条件和操作结果的 FAQ 前面。

为什么产品问答比通用检索更难

产品问答的难点在于，正确答案往往依赖限定条件，而不是一个孤立事实。

用户问“这项功能支持吗”，答案可能取决于套餐、国家、账户类型、权限角色、发布日期或产品版本。用户问“能不能退款”，答案可能还要结合交易状态、申请时间和特殊条款。

这意味着产品检索至少存在五类容易被忽视的错误：

• 召回失败：真正包含规则的文档没有进入候选集。
• 排序失败：正确文档被主题相似但信息不足的文档压到后面。
• 切分失败：文档被切成多个片段，条件和例外被拆开。
• 版本失败：旧规则和新规则同时存在，系统命中了过期内容。
• 多跳失败：问题需要组合账户、交易和政策等多个来源，系统只找到了其中一部分。

这些问题并不能靠更强的生成模型自动修复。如果召回阶段拿到的是“如何申请退款”，生成模型很可能会基于这段内容给出一份流畅的申请指南，但仍然回答不了“我的这笔交易是否符合退款条件”。

因此，检索评测必须在生成模型介入之前单独进行。否则，最终答案看起来是否通顺，会掩盖检索阶段究竟错在哪里。

对嵌入模型选型有什么实际意义

QontoFAQ 对开发者最直接的帮助，是让嵌入模型选型不再停留在通用排行榜上。

很多团队会根据公开的语义相似度、通用检索或问答榜单选择嵌入模型，但这些榜单不一定代表模型在自己的知识库里表现最好。一个在通用百科数据上成绩不错的模型，未必理解企业帮助中心里的套餐差异、权限边界和流程状态。

更合理的做法是，把自己的真实产品问题拿出来做小规模黄金测试集，再比较不同嵌入模型在以下场景的结果：

• 高频简单问题；
• 同义改写问题；
• 口语化和不完整问题；
• 带有产品版本的问题；
• 需要识别例外条款的问题；
• 需要跨文档组合证据的问题；
• 应该拒答或请求补充信息的问题。

QontoFAQ 提供的不是一个“选完模型就结束”的答案，而是一种更值得复用的评测方法：让检索模型为真实任务负责，而不是让通用分数替它背书。

但它还不能替代完整的 RAG 评测

QontoFAQ 解决的是检索相关性问题，不等于解决了整个 RAG 系统的可靠性问题。

一个系统可能检索到了正确文档，却在生成阶段犯错。例如，文档说“部分套餐支持国际转账”，模型回答成“所有套餐都支持”；文档同时写了新旧两套规则，模型把它们拼成一条不存在的政策；文档明确要求满足三个条件，模型只提到了其中一个。

完整的 RAG 评测至少应拆成四层：

1. 检索命中：必要文档是否被召回。
2. 排序质量：最有用的证据是否排在前面。
3. 上下文覆盖：检索结果是否覆盖回答所需的全部事实。
4. 生成忠实度：最终回答是否严格受证据支持。

其中，忠实度是指回答中的事实、条件和结论都能在检索到的证据中找到依据。它与“答案读起来像不像正确答案”不是一回事。

对于生产系统，还应增加版本命中率、引用完整性、拒答能力和敏感信息隔离等指标。一个只报告总体准确率的 RAG 评测，很容易用大量简单问题掩盖少数高风险错误。

开发者应该怎样使用这类基准

开发者可以把 QontoFAQ 当作检索回归测试的参考模板，而不是只把它当成一个排行榜。

第一步是建立自己的真实问题集。问题应来自客服工单、搜索日志、销售支持和用户访谈，而不是全部由模型自动生成。每个问题最好同时标注：必要证据、可接受替代证据、过期文档和不应使用的文档。

第二步是固定知识库版本。文档内容、切分策略、元数据和过滤规则都要记录下来，否则一次模型对比可能实际比较的是两套不同知识库。

第三步是分别测试召回器和重排器。嵌入模型负责大规模初筛，重排器负责在较小候选集里进一步判断相关性。两者混在一起只看最终答案，很难定位到底是召回不足还是排序错误。

第四步是按问题类型拆分结果。简单问题的 95% 命中率，并不能证明系统能处理政策边界问题。至少应分别报告普通 FAQ、复杂条件、跨文档问题、版本问题和拒答问题的表现。

第五步是把评测放进发布流程。只要更换嵌入模型、文档切分方案、重排器、元数据过滤逻辑或生成模型，就应重新运行检索回归测试。

QontoFAQ 真正重要的地方

QontoFAQ 真正重要的地方，不在于它又增加了一个榜单，而在于它提醒行业重新定义“检索成功”。

在演示环境里，检索结果看起来相关、模型回答足够流畅，系统就容易被认为表现良好。但在真实产品问答中，用户需要的不是一段主题相近的文字，而是能解释当前情境、适用条件和下一步动作的证据。

这也是 RAG 从实验走向生产必须经历的一次指标升级：从“有没有找到相关文本”，升级到“有没有找到足以支持正确决策的信息”。

截至目前，QontoFAQ 更像是一个针对产品 FAQ 检索的开放式起点，而不是完整的 RAG 标准答案。它的意义在于把评测目标拉近真实业务，把嵌入模型的比较从通用语义相似度拉回到产品问题能否被解决。

对于正在搭建知识库问答、客服助手或企业搜索系统的团队来说，这个方向比继续追逐一个孤立的向量相似度分数更有价值。因为用户最终不会问“你的 Recall@10 是多少”，他们只会问一句：为什么你引用了这篇文档，却还是没有回答我的问题？

参考来源

• QontoFAQ：相关讨论与项目介绍（Reddit）：QontoFAQ 的公开讨论入口，介绍了项目动机和评测方向。
• Qonto FAQ Benchmark GitHub 仓库：项目配套代码与基准实现，适合查看数据、评测流程和复现实验。
• RAG 评测完整指南（知乎）：补充介绍 Recall、MRR、MAP、上下文相关性和生成质量等常见指标。
• 金融领域大模型检索增强评估基准（中国人民大学相关页面）：展示了准确性、完整性、幻觉、利用率和数值准确性等 RAG 评估维度。