案例

RAG 检索系统评估

基于 BGE embedding 和 FAISS 向量检索的门店招牌类目匹配系统,含评估指标(Recall@5/MRR/NDCG@5)、标注数据集和对比实验。

检索规模
405 分类目
使用 BGE embedding 建立 768 维 FAISS IndexFlatIP 向量索引。
标注数据
30 条 query
覆盖精确匹配、语义模糊、短 query、歧义和跨领域类型。
评估指标
Recall@5 / MRR / NDCG@5
手写指标实现,减少依赖并保持实验输出可控。
最佳实验
Recall@5=0.6889
当前数据下单向量 baseline 优于多路查询融合配置。

这个项目把 ComfyUI-QING 中的门店招牌向量匹配能力拆成独立评估项目,核心问题从“能不能检索到结果”推进到“结果质量如何量化、如何复现、失败样本说明了什么”。

实现重点不是换一个更复杂的 RAG 框架,而是围绕现有 BGE embedding、FAISS 索引和门店招牌类目数据建立可跑通的评估闭环。每次实验都能从构建索引开始,输出 Recall@5、MRR、NDCG@5,并把失败 case 回写到后续调优判断里。

图文说明

评估报告

README 内的完整评估报告,含实验设置、4 组对比实验结果表、失败案例分析、调优方向。详见 github.com/sheengoa/rag-evaluation。

RAG 检索系统评估闭环信息图
标注 query、embedding、向量索引、Top-k 检索、指标评估和失败 case 分析组成可复现评估闭环。

项目定位

项目定位为一个检索质量评估样本,而不是新的业务检索系统。它复用 ComfyUI-QING 里的核心向量匹配逻辑,把 embedding、indexer、retriever 和 query_parser 抽出为独立 Python 项目。

问题背景

原始能力来自门店招牌类目匹配节点,但只有可用的检索结果还不足以说明 RAG 经验。招聘或项目复盘时,更关键的问题是如何判断检索质量、如何发现退化,以及为什么某个调优方案有效或无效。

  • 不能重写核心算法,否则评估结果就无法代表 ComfyUI-QING 中的真实能力。
  • 需要覆盖精确匹配、语义模糊、短 query 和跨领域 query 等不同输入。
  • 实验要能一条命令复现,避免报告只停留在手工截图或主观判断。

数据集设计

数据集围绕 30 条 query 手工标注 relevance judgments,规模不大,但每一类输入都能对应明确的失败和命中解释。这样比盲目扩大样本更适合当前作品集阶段。

query
30
覆盖精确、语义相似、歧义、短 query 和跨领域。
类目
405
门店招牌分类目作为向量库候选集合。

评估指标

指标选择围绕 Top-k 检索体验展开。Recall@5 关注相关类目是否进入候选列表,MRR 关注第一个相关结果出现的位置,NDCG@5 则把排序质量纳入评估。

  1. Recall@5 用来判断候选集是否覆盖可用答案。
  2. MRR 用来观察用户最先看到的相关结果是否足够靠前。
  3. NDCG@5 用来比较同样命中的情况下排序质量的差异。

实验过程

  1. 01

    抽取模块

    从 ComfyUI-QING 中拆出 embedding、indexer、retriever 和 query_parser。

  2. 02

    构建索引

    用 BGE embedding 生成 768 维向量,并写入 FAISS IndexFlatIP。

  3. 03

    运行评估

    对 baseline 和 3 组查询融合权重配置执行同一套指标计算。

  4. 04

    分析失败

    按 query 类型查看未命中、低排序和错误匹配样本。

关键发现

最重要的发现是当前 405 类目规模下,单向量 baseline 比多路查询融合更稳定。查询融合把语义拆得更碎,反而稀释了原始 query 的整体意图。

Baseline
Recall@5=0.6889
MRR=0.8236,NDCG@5=0.7510。
Query fusion
Recall@5=0.62
在通用场景中出现碎片化和权重稀释问题。

失败样本

失败主要集中在抽象语义和过短 query。比如“温暖的店铺外观”更像视觉氛围描述,不一定对应稳定类目;“吃饭的地方”则过于泛化,候选类目容易分散。

  • 精确匹配型 query 如“火锅店”“理发店”全部命中。
  • 抽象语义 query 暴露了类目库和视觉描述之间的语义差距。
  • 短 query 对 stop_markers 和查询解析更敏感,容易被过度过滤。

结果与证据

README 保留完整评估报告,包含实验设置、4 组对比实验结果表、失败案例分析和后续调优方向。仓库也保留从零构建索引到跑完评估的命令路径。

反直觉结果比单纯提升指标更有价值:它说明当前数据规模下,保持 query 语义完整性比拆分融合更重要。

复盘与下一步

这个项目把 RAG 经历从“做过向量检索”变成“能解释评估方法和失败原因”。下一步不应先堆更多策略,而是围绕失败样本选择更有针对性的改进。

  • 引入 reranker 对 Top-k 候选做二阶段排序。
  • 尝试 LLM query 改写,但必须保留与 baseline 的同集对比。
  • 评估混合检索是否能改善短 query 和抽象描述的召回。

相关笔记