案例
RAG 检索系统评估
基于 BGE embedding 和 FAISS 向量检索的门店招牌类目匹配系统，含评估指标（Recall@5/MRR/NDCG@5）、标注数据集和对比实验。
Case Index
背景、角色、约束、决策、过程和结果按案例结构展开，便于快速判断交付边界。
图文说明
评估报告
README 内的完整评估报告，含实验设置、4 组对比实验结果表、失败案例分析、调优方向。详见 github.com/GAO-SHIQING/rag-evaluation。
背景
在 ComfyUI 节点中实现的门店招牌向量匹配系统缺乏可量化的质量评估。招聘方面对 RAG 经历时，第一个问题就是「你怎么评估检索质量」——需要从「能检索」推进到「质量可量化、可调优」。
角色
从 ComfyUI-QING 提取核心检索逻辑为独立 Python 项目，搭建评估框架、标注 30 条 query 数据集、设计 4 组对比实验并撰写评估报告。
约束
- 核心算法需与 ComfyUI-QING 向量匹配节点保持一致，不能重写。
- 评估需覆盖多种 query 类型：精确匹配、语义模糊、短 query、跨领域。
- 实验必须可复现——一条命令从零构建索引到跑完评估。
关键决策
- 选用方案 A（门店招牌案例检索），与简历 P1 经历直接对齐，数据和领域知识现成。
- 手写评估指标（30 行 Python）而非引入 pytrec_eval，减少依赖、更好控制输出。
- 实验发现：在当前 405 类目规模下，BGE 单向量编码（Recall@5=0.69）优于多路查询融合（0.62）——规则碎片化反而损伤语义完整性。这个反直觉发现本身就是有说服力的工程判断。
- 通过 ModelScope 分发模型权重，降低国内网络下复现门槛。
过程
- 从 ComfyUI-QING 提取 4 个核心模块（embedding / indexer / retriever / query_parser），去掉 ComfyUI 运行时依赖。
- 搭建 FAISS IndexFlatIP 向量索引（405 分类目 × 768 维 BGE embedding）。
- 手工标注 30 条 query × relevance judgments，覆盖精确匹配、语义相似、歧义、短 query、跨领域 5 种类型。
- 实现 Recall@5、MRR、NDCG@5 三个评估指标和 CLI 评估命令。
- 运行单向量 Baseline 和 3 组查询融合权重配置的对比实验，分析失败 case 并给出调优方向。
结果
- 单向量 Baseline: Recall@5=0.6889, MRR=0.8236, NDCG@5=0.7510。
- 精确匹配型 query（如「火锅店」「理发店」）全部命中，Recall=1.0。
- 抽象语义型 query（如「温暖的店铺外观」）和短 query（如「吃饭的地方」）是主要失败来源。
- 识别出查询融合在通用场景下的退化原因（碎片化、权重稀释、stop_markers 过度过滤），并给出 reranker / LLM query 改写 / 混合检索三个下一步方向。