大多数工程师搭 RAG 系统，第一步就去研究选哪个 embedding 模型。这其实是反的。
我见过不止一个团队，在 text-embedding-ada-002 和 bge-m3 之间来回横跳，跑了无数次 benchmark，最后发现系统效果不好------问题压根不在 embedding，在 chunking。
那个把两周时间烧在 embedding 选型上的工程师
去年有个朋友在做内部知识库 RAG，产品要求"用户问什么都能答"。他把前两周全用在了这件事上：
- 跑了 OpenAI、Cohere、BGE、Jina 四家 embedding 的对比
- 搭了评测脚本，统计 top-k 召回率
- 换了三次向量数据库（Pinecone → Qdrant → pgvector）
最终 top-3 召回率到了 78%，他觉得差不多了。
上线两周后，用户反馈"答非所问"的 ticket 不断涌入。他去翻 log，发现命中的 chunk 虽然语义相关，但内容是文档的某个孤立段落------没有上下文，模型根本无法给出有用的回答。
问题不是 embedding 不准，是 chunk 切得太碎，上下文完全割断了。
Embedding 选型的收益边际在递减
这是一个经常被忽视的现实：主流 embedding 模型之间的性能差距，在通用文本任务上已经非常小。
2025 年的 MTEB 榜单前 10 名，top-3 召回率差距普遍在 3% 以内。而一个糟糕的 chunking 策略，能把这个指标直接打掉 20%。
换句话说，你花两周做 embedding 选型，收益可能是 +3%；而花两天优化 chunking 策略，收益可能是 +20%。
这不是说 embedding 不重要，而是优先级错了。
真正的三个瓶颈
1. Chunking 策略
固定长度切分（fixed-size chunking）是最常见的起点，也是最快到达瓶颈的选择。
几个实测中收益更稳定的策略：
- 句子级 + 滑动窗口：保留上下文连续性，适合叙述型文档
- 按语义分段：用小模型做段落边界检测，适合结构化报告
- 父子 chunk：检索时用小 chunk，送给 LLM 时附上父 chunk，兼顾精度和上下文
没有银弹，关键是要有评估集来量化不同策略的差异，而不是凭感觉换。
2. 评估闭环
这是大多数 RAG 项目最缺的一环。
没有评估集，你就是在用眼睛观测一个黑盒。改了 chunking 是更好还是更差？改了 retrieval 策略有没有回归？你不知道。
一个最小可行的评估闭环：
- 从真实用户问题中抽取 50-100 个代表性 case
- 人工标注每个问题的"理想 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 跑通 pipeline，别在这两步卡太久
- 搭最小评估集，给自己一把尺
- 优化 chunking 策略，用评估集量化每次改动
- 加混合检索
- 调 reranker（可选，收益视场景而定）
- 这时候再考虑换 embedding 模型是否有额外收益
RAG 系统的效果，80% 在数据处理和检索质量，20% 在模型选择。