案例
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。

项目定位
项目定位为一个检索质量评估样本,而不是新的业务检索系统。它复用 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 则把排序质量纳入评估。
- Recall@5 用来判断候选集是否覆盖可用答案。
- MRR 用来观察用户最先看到的相关结果是否足够靠前。
- NDCG@5 用来比较同样命中的情况下排序质量的差异。
实验过程
- 01
抽取模块
从 ComfyUI-QING 中拆出 embedding、indexer、retriever 和 query_parser。
- 02
构建索引
用 BGE embedding 生成 768 维向量,并写入 FAISS IndexFlatIP。
- 03
运行评估
对 baseline 和 3 组查询融合权重配置执行同一套指标计算。
- 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 和抽象描述的召回。