Embedding 检索的三件小事：切块、元数据和召回观察

Embedding 检索看起来很简单：文本转向量，向量入库，问题再转向量，取相似结果。但 RAG 质量经常卡在更朴素的地方：切块太碎、元数据太少、召回结果不可观察。

OpenAI embeddings 文档说明 embedding 可用于搜索、聚类、推荐等语义任务；LlamaIndex 文档也围绕节点、索引和检索组织 RAG 数据流程。[emb-001][emb-002]

切块不是越小越好

chunk 太大，召回上下文会混入噪声；chunk 太小，答案需要的信息可能被拆散。一个实用原则是让 chunk 对应“可独立引用的一小段知识”。

可以从文章结构切起：

文章 -> h2 小节 -> h3 小节 -> 段落窗口

好的 chunk 应该让读者点开来源后，能在附近找到完整上下文。

元数据决定可解释性

每个 chunk 至少应该保存：

• 文章 slug。
• 标题。
• heading 路径。
• 发布时间或更新时间。
• 标签和分类。
• 原文位置。

概念结构如下：

{
  "chunk_id": "post-slug#heading-2#003",
  "text": "被检索的正文片段",
  "metadata": {
    "slug": "post-slug",
    "heading": "评估流程",
    "tags": ["RAG", "Evaluation"]
  }
}

召回要能被检查

Pinecone 的搜索和重排资料提醒我们，初始召回和后续排序是两个不同阶段。[emb-003] 如果你只看最终回答，就不知道问题出在召回、排序还是生成。

建议在开发环境展示：

1. 用户 query。
2. topK chunk 标题。
3. 相似度或排序分。
4. 是否进入最终上下文。
5. 最终答案引用了哪些 chunk。

综合这些来源可以推断：向量检索不是一个黑盒组件，而是一条需要调试界面的数据管线。可观测性越早做，后面调 RAG 越轻松。

参考资料

1. [emb-001] OpenAI Developers, “Embeddings”, https://developers.openai.com/api/docs/guides/embeddings
2. [emb-002] LlamaIndex Docs, “Indexing”, https://docs.llamaindex.ai/en/stable/module_guides/indexing/
3. [emb-003] Pinecone Docs, “Rerank results”, https://docs.pinecone.io/guides/search/rerank-results