多数人搭 RAG，起步时就做错了

搭建 RAG 系统时，多数工程师第一步便开始研究该选哪个 embedding 模型，其实这个顺序恰好反了。

我见过不止一个团队，在 text-embedding-ada-002 和 bge-m3 跑了无数次 benchmark，又在不同选择之间来回横跳，到头来系统效果仍不好。真正的问题出在 chunking，压根不是 embedding。

embedding 选型耗掉了那名工程师的两周时间

去年有位朋友负责内部知识库 RAG，产品提出了“用户问什么都能答”的要求。他在前两周只做了这件事：

• 跑了 OpenAI、Cohere、BGE、Jina 四家 embedding 的对比
• 搭建评测脚本并统计 top-k 召回率
• 向量数据库三次变更的顺序是（Pinecone → Qdrant → pgvector）

最终 top-3 召回率达到 78%，他认为已经基本够用。

上线两周后，用户关于“答非所问”的 ticket 接连出现。他检查 log 后发现，命中的 chunk 虽然语义相关，却只是文档中的孤立段落；由于缺乏上下文，模型根本给不出有用答案。

上下文会完全割断，是因为 chunk 切得太碎，而非 embedding 不准。

边际收益会随着 Embedding 选型继续推进而递减

一个常被忽略的现实是：在通用文本任务中，主流 embedding 模型之间的性能差距已经很小。

糟糕的 chunking 策略会直接打掉 20% 的指标；相比之下，2025 年 MTEB 榜单前 10 名之间，top-3 召回率普遍只相差 3% 以内。

优化 chunking 策略只花两天，收益可能有 +20%；embedding 选型即使投入两周，可能也只有 +3%。

需要调整的是优先级，并非否定 embedding 的重要性。

真正存在的三个瓶颈

1. Chunking 策略

最常见的起步选择是固定长度切分（fixed-size chunking），但它也会最快触及瓶颈。

实测中，下面几种策略的收益更加稳定：

• 叙述型文档适合句子级 + 滑动窗口，因为上下文连续性能够得到保留
• 结构化报告适合按语义分段，段落边界由小模型检测
• 父子 chunk：小 chunk 负责检索，父 chunk 则在送给 LLM 时一并附上，从而兼顾上下文和精度

不存在通用银弹，重点是借助评估集量化各类策略的差异，而非凭感觉不断更换。

2. 评估闭环

多数 RAG 项目最缺少的正是这一环。

缺少评估集，就等于只凭肉眼观察一个黑盒。调整 chunking 后究竟变好还是变差？改变 retrieval 策略是否产生回归？这些都无法判断。

最小可行评估闭环可以这样建立：

1. 准备 50-100 个代表性 case，来源应是真实用户问题
2. 每个问题对应的"理想 chunk"（ground truth）由人工完成标注
3. 改动一次就运行一次，再用 Recall@3 和 MRR 对比结果

在工具层面，RAGAS 框架能够将这套流程半自动化，可以尝试。

3. 检索质量：不要只依赖向量检索

精确词匹配是纯向量检索的一个经典失效场景。

向量检索可能先把语义接近的"Claude 3.5 context window"排出来，即使用户实际搜的是"Claude Sonnet 4.6 的 context window 是多少"。

这类场景更适合表现稳定的混合检索（BM25 + 向量）。混合检索已被 pgvector 0.7+ 支持，既有显著的效果提升，实现成本也不高。

一套可供参考的迭代次序

1. 不要在前两步耗费太久：选任意主流 embedding，配合固定 chunking，先让 pipeline 完整跑通
2. 建立最小评估集，为效果衡量准备一把尺
3. 借助评估集量化每次变化，逐步优化 chunking 策略
4. 加入混合检索
5. reranker 的调节属于可选项，收益会随场景变化
6. 到这一步，再判断更换 embedding 模型能否带来额外收益

RAG 系统效果的 80% 来自数据处理与检索质量，模型选择只占 20%。