大多工程师构建 RAG 系统时，第一步往往扎进 embedding 模型的选型里。这个次序，其实是本末倒置的。
观察到许多团队在 text-embedding-ada-002 与 bge-m3 之间犹豫不决，进行了多轮基准测试。结果发现系统实际效果欠佳？问题症结其实并非 embedding，而是 chunking。这个现象，颇具代表性。
那个将两周时间耗费在 embedding 选型上的工程师
去年有位朋友负责内部知识库 RAG 项目，产品要求是“用户提问必须都能回应”。他直接把头两周全压在这件事上：
- 对 OpenAI、Cohere、BGE、Jina 四家 embedding 做了对比测评
- 搭建了评估脚本，精细计算 top-k 召回率
- 向量库换了三套：从 Pinecone 到 Qdrant 再到 pgvector
最终 top-3 召回率达到 78%，他自认为已足够。
结果怎样？上线两周后，“答非所问”的用户反馈接连不断。排查日志发现，命中的 chunk 语义虽相关，却来自文档中的孤立段落——由于缺少上下文，模型根本无法输出有价值信息。
问题根源并非 embedding 不准，而是 chunk 切得过碎，上下文被完全割裂。
Embedding 选型：边际收益正持续下滑
这其实是一个经常被忽略的现状：主流 embedding 模型在通用文本任务上的性能差距已经非常有限。
2025 年 MTEB 榜单前十名，top-3 召回率差距普遍低于 3%。然而，一个糟糕的 chunking 策略，就能让这项指标直接暴跌 20%。
换言之，花两周时间做 embedding 选型，可能只有 +3% 的收益；而花两天优化 chunking 策略，却可能带来 +20% 的提升。
并非 embedding 不重要，只是优先级确实搞错了。
真正的三大瓶颈
1. Chunking 策略
固定长度切分是最常见的起步方式，也是最先触及的天花板。
实战中效果更稳定的几种策略：
- 句子级 + 滑动窗口：保留上下文连贯性，适用于叙述型文档
- 按语义分段：借助小模型识别段落边界，适合结构化报告
- 父子 chunk：检索阶段使用小 chunk，提交给 LLM 时附带父 chunk，兼顾精准度与上下文完整性
不存在普适方案。关键是要有评估集来量化不同策略的效果差异，而不是凭感觉盲目更换。
2. 评估闭环
这通常是大多数 RAG 项目中最容易被忽视的环节。
缺乏评估集，无异于用眼睛观测一个黑箱。调整了 chunking 是好是坏？改动了检索策略是否产生回归？你完全无法判断。
一个最小可行的评估闭环：
- 从真实用户问题中抽取 50-100 个代表性案例
- 由人工标注每个问题的“理想 chunk”（即 ground truth）
- 每次改动后运行一次，对比 Recall@3 与 MRR 指标
工具层面，RAGAS 框架能半自动化这一流程，值得尝试。
3. 检索质量：单靠向量检索远远不够
纯向量检索存在一个经典失效场景：精确词匹配。
用户搜索“Claude Sonnet 4.6 的 context window 是多少”，向量检索很可能优先返回语义接近的“Claude 3.5 context window”。这正是问题的关键。
混合检索（BM25 + 向量）在类似场景下表现得更稳定。pgvector 0.7 及以上版本已支持混合检索，实现成本不高，但效果提升显著。
一套值得参考的迭代顺序
- 先采用固定 chunking 搭配任一主流 embedding 跑通流程，别在这两步上耗费太久
- 建立最小评估集，为自己提供衡量标准
- 优化 chunking 策略，借助评估集量化每次调整
- 引入混合检索
- 根据需求添加 reranker（可选，收益取决于具体场景）
- 此时再考虑更换 embedding 模型是否仍有额外价值
RAG 系统达到理想效果，80% 依赖于数据处理与检索质量，仅 20% 取决于模型选择。从这个角度看，优化方向就变得清晰多了。
