多数人搭 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% 以内。

也就是说，用两周选择 embedding，可能只能获得 +3% 的收益；投入两天改进 chunking 策略，收益却可能达到 +20%。

这并不意味着 embedding 不重要，真正的问题是优先级安排错误。

三个真正的瓶颈

1. Chunking 策略

最快触及瓶颈的选择，恰恰也是最常用的起点：固定长度切分（fixed-size chunking）。

以下策略在实测中带来的收益更加稳定：

• 叙述型文档：采用句子级 + 滑动窗口，令上下文保持连续
• 结构化报告：让小模型检测段落边界，按语义完成分段
• 父子 chunk：以小 chunk 执行检索，交给 LLM 时附带父 chunk，从而兼顾上下文和精度

不存在银弹，关键在于利用评估集量化各种策略的差异，而不是凭主观感受更换。

2. 评估闭环

多数 RAG 项目最为欠缺的，正是这一环节。

缺少评估集，就等于仅凭眼睛观察黑盒。调整 chunking 后究竟变好还是变差？修改 retrieval 策略是否引发回归？这些都无法得知。

最小可行评估闭环包括：

1. 抽取 50-100 个代表性 case，来源应是真实用户问题
2. 每个问题对应的"理想 chunk"（ground truth）由人工标注
3. Recall@3 和 MRR 的对比，需要在每次改动后跑一次

在工具层面，RAGAS 框架能够让这个流程实现半自动化，值得尝试。

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

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

向量检索面对用户的问题"Claude Sonnet 4.6 的 context window 是多少"，很可能先把"Claude 3.5 context window"排在前面，因为二者语义相近。

在这类场景里，更稳的是混合检索（BM25 + 向量）。混合检索已经得到pgvector 0.7+支持，效果提升明显，实现成本也不高。

一个值得参考的迭代次序

1. pipeline 应先以固定 chunking + 任意主流 embedding 跑通，这两步无需停留过久
2. 建立最小评估集，为自己准备一把尺
3. 每次改动都用评估集量化，以此推动 chunking 策略优化
4. 加入混合检索
5. reranker 的调试（收益随场景而异，可选）
6. 到这个阶段，再判断更换 embedding 模型能否带来额外收益

RAG 系统效果的 80% 取决于数据处理和检索质量，模型选择只占 20%。