布吉岛 Agent

Appearance

4.2.2 为什么索引质量会直接决定后续召回质量？ ​

先给结论：因为召回不是在一堆原始资料里随意翻找，而是在索引阶段已经组织好的对象集合里做选择。对象怎么组织、带了什么字段、按什么粒度写进去，会直接决定后面能不能找对。

这也是为什么很多召回问题，不能只盯着查询词或重排模型看，而要先回到索引阶段检查地基。

召回到底在“召回”什么 ​

后面检索阶段真正拿来比较和打分的，通常不是原始整篇资料，而是索引阶段写进去的对象，比如：

  • 一个 chunk
  • 一个文档级对象
  • 一个父块和子块的组合对象
  • 一个带 metadata 的结构化记录

所以召回质量的上限，首先取决于这些对象本身是不是适合被比较。

如果对象本身就组织得不好，后面再好的检索算法也只能在错误候选里选“相对更像”的东西。

索引质量主要通过哪几层影响召回 ​

1. 对象粒度 ​

如果索引对象太大，常见问题是：

  • 一个块里塞了多个主题
  • 局部相关信息不突出
  • 命中了但上下文太散

如果索引对象太小，常见问题是：

  • 语义断裂
  • 本来需要一起出现的信息被拆开
  • 召回后模型看不懂前后关系

所以“召回不准”有时不是检索器不会找，而是索引阶段提供给它的候选粒度就不合适。

2. 字段完整性 ​

召回阶段常用的不只是文本和向量，还包括：

  • 文本本身
  • 向量表示
  • 关键词信号
  • metadata 过滤字段

如果索引对象里缺了关键字段，召回就会天然受限。

比如：

  • 没有 status，过期内容就会混进来
  • 没有 tenant_id，多租户边界会失稳
  • 没有稳定 doc_id，很难做文档级聚合
  • 没有来源字段，后面无法做结果解释和回查

这类问题不会表现为“系统报错”，但会持续表现为“结果总差一点”。

3. 内容洁净度 ​

如果索引对象里仍然带着：

  • 页眉页脚
  • 导航栏
  • 重复模板
  • 空内容
  • 截断错误

那么召回阶段就会经常出现噪声抢位。

很多人看到这种情况，会觉得是相似度排序有问题。其实排序只是在已有候选里选，问题往往是索引阶段把脏候选也一起放进来了。

4. 边界设计 ​

召回质量不只是“找得像不像”，还包括“找回来的内容是不是当前应该出现的内容”。

比如：

  • 当前生效版本是不是优先
  • 当前用户有没有权限看
  • 当前租户的数据有没有被限定
  • 当前业务范围有没有先收紧

这些边界如果没有在索引对象里体现出来，后面召回就很难稳。

一个更直观的对比 ​

假设你有同一批退款规则文本。

如果索引方式 A 是这样：

  • 整篇文档直接入库
  • 不区分版本
  • 不补状态字段
  • 不记录来源段落

后面召回经常会出现：

  • 问题相关，但答案所在局部不突出
  • 新旧规则同时出现
  • 结果能命中，但很难解释为什么命中

如果索引方式 B 是这样：

  • 先清洗再切块
  • 每块保留稳定 doc_id 和 chunk_id
  • 带上 status、version、updated_at
  • 保留标题、段落、来源链接

后面召回通常更容易做到：

  • 候选更聚焦
  • 边界先过滤
  • 同文档聚合更稳
  • 错误结果更容易排查

也就是说，召回质量不是只由查询时刻决定的，而是索引阶段已经预埋了很大一部分。

一个最小示意 ​

python
bad_index_record = {
    "id": "doc-1",
    "text": "退款规则全文......",
    "vector": embed("退款规则全文......")
}

good_index_record = {
    "id": "refund-policy-v3#chunk-02",
    "text": "定制类商品不支持无理由退货。",
    "vector": embed("定制类商品不支持无理由退货。"),
    "metadata": {
        "doc_id": "refund-policy-v3",
        "section": "退款条件",
        "version": "v3",
        "status": "active",
        "updated_at": "2026-04-01"
    }
}

这两个对象后面都能被“检索”，但它们给召回阶段提供的可操作空间完全不同。

前者更像一条粗糙记录，后者才更像一个可治理、可过滤、可聚合的召回对象。

召回变差时，应该优先回查哪些索引问题 ​

如果你发现系统经常“找得到一点，但总不准”，优先回查这些地方：

  1. 当前索引对象粒度是否过粗或过碎
  2. 是否把噪声文本也写进了索引
  3. metadata 是否足够支撑过滤和聚合
  4. 是否混入了旧版本、失效版本或跨边界内容
  5. 文本字段、向量字段、关键词字段之间是否明显失衡

很多系统只盯着 top_k、Prompt、重排模型调很久，最后才发现索引对象本身就不适合拿来召回。

一个常见误区 ​

很多人会觉得：

  • 召回效果差，说明 embedding 模型不够强

这有时成立，但并不总是主因。

更常见的情况是：

  • 数据进错了
  • 粒度不对
  • 边界字段缺失
  • 索引对象组织得太粗

这类问题如果不回到索引阶段解决，后面即使换更强模型，也往往只是局部改善。

一句话总结 ​

索引质量会直接决定后续召回质量，因为召回是在索引阶段已经组织好的对象集合里做选择。对象粒度、字段设计、内容洁净度和边界信息，都会直接决定后面能不能把真正该找回的内容稳定找回来。