AMZ
用户中心
FBA 与物流

向量数据库入门：Embedding、Chunk、Hybrid Search、Rerank到底是什么

别把它当技术黑话，它决定的是你的知识库能不能在正确时间找到正确资料

公众号文章库2026/7/717 分钟阅读

别把它当技术黑话，它决定的是你的知识库能不能在正确时间找到正确资料

**摘要：**向量检索小白课

**关键词：**向量数据库、Embedding、Chunk、Hybrid Search、Rerank、RAG检索调优

封面：向量数据库入门：Embedding、Chunk、Hybrid Search、Rerank到底是什么

本文是「AI知识库完整教程」第 12 课。

知识库答不准，很多时候不是模型问题，而是检索问题

跨境团队做 AI 知识库时，最常见的抱怨是：资料明明上传了，机器人为什么还答错？

比如客服问“便携榨汁杯漏水怎么处理”，知识库里确实有售后 SOP、产品说明书、Review 摘录、客服话术、保修政策。但机器人找出来的却是“清洗注意事项”，或者把旧款产品的规则拿来回答新款产品。

这类问题不能只怪大模型。RAG 的核心链路是先检索，再生成。如果检索阶段拿错资料，后面的模型再会写，也只是在错误上下文上写得更顺。

所以这篇讲的不是抽象技术词，而是知识库质量的四个关键旋钮：Chunk、Embedding、Hybrid Search、Rerank。你不一定要自己写向量数据库代码，但你必须知道它们如何影响业务答案。

先看完整链路：资料不是直接进模型

一个典型 RAG 知识库，不是把 PDF 直接塞给模型。它通常会经历七步。

第一，文档入库。比如 SOP、产品说明书、广告搜索词报告、Review 摘录、客服话术。第二，切片，也就是把长文档拆成 chunks。第三，生成 embedding，把每个 chunk 变成向量。第四，把向量和元数据存进向量数据库或检索系统。

第五，用户提问时，也把问题变成向量。第六，系统用向量搜索、关键词搜索或混合搜索找候选 chunks。第七，用 rerank 或规则再排一次顺序，把最可能相关的内容交给 LLM 生成回答。

这条链路里任何一步出错，最后都会表现成“AI 胡说”。资料切错了，会丢上下文；embedding 不适合，会语义匹配偏；关键词没用好，会漏掉 SKU 和型号；rerank 没做好，会把最重要资料排到后面。

  • 入库：决定资料是否干净、有效、可追溯。
  • Chunk：决定系统能不能在合适粒度找到资料。
  • Embedding：决定系统能不能按语义找到相近内容。
  • Hybrid Search：决定语义和关键词能不能一起发挥作用。
  • Rerank：决定候选资料的最终顺序是否可靠。

Chunk：不是随便切小，而是保留业务上下文

LangChain 文档说明，text splitters 会把大型文档拆成能单独检索、且能放进模型上下文窗口的小 chunks。它还推荐通用文本使用递归切分，优先尽量保留段落、句子和词的完整性。

对业务资料来说，Chunk 的核心不是小，而是完整。一个 chunk 太大，检索命中后会带入很多噪音；一个 chunk 太小，模型可能看不到它属于哪个产品、站点、版本和场景。

比如一句“不得用于 3 岁以下儿童”如果被切出来但没有产品名、类目、站点和安全说明上下文，客服机器人可能把它错误套用到其他产品。再比如“客户需要提供照片”如果脱离了“破损到货”场景，客服可能不知道什么时候要求照片。

跨境知识库的切片原则是：一个 chunk 能回答一个完整业务问题，同时带上标题、适用范围和关键约束。

  • SOP 类资料：按场景切，例如破损、退货、迟发、保修。
  • 产品说明：按功能、材质、尺寸、配件、安全限制切。
  • 广告复盘：按时间窗口、广告活动、搜索词组、动作建议切。
  • 评论分析：按痛点类别、样本来源、产品版本切。
  • 每个 chunk 要带标题、站点、SKU/产品线、版本和更新时间。

Embedding：把文字变成可比较的数字

OpenAI 文档说明，embedding 是一组浮点数向量，两个向量之间的距离可以表示相关性，常用于搜索、聚类、推荐和分类。

用业务语言讲，Embedding 就是把一段话变成系统能比较的坐标。用户问“杯子会不会漏”，资料里写的是“lid seal may loosen after dishwasher cleaning”，字面并不一样，但语义相关。向量搜索让系统有机会把这两段内容匹配起来。

这也是为什么知识库不能只靠关键词搜索。买家不会按你的 SOP 原文提问，客服也不会总是使用标准术语。Embedding 让系统按意思找资料。

但 Embedding 不是万能。它擅长语义相似，不擅长保证型号、ASIN、日期、政策编号这种精确匹配。如果你问“B0ABC123 的新款盖子是否兼容旧款”，纯语义搜索可能找到“盖子兼容说明”，但未必命中特定 ASIN 或版本。

  • 适合语义：用户痛点、客服口语、评论表达、文章主题。
  • 不适合单独承担：SKU、ASIN、法规编号、日期、版本、订单规则。
  • 运营含义：Embedding 解决“意思相近”，不是解决“业务边界”。

向量数据库：像一张语义地图，但地图也会找错路

Pinecone 文档说明，semantic search 会在 dense vector index 中搜索与 query 在意义和上下文上最相似的记录，也叫 similarity search 或 nearest neighbor search。

你可以把向量数据库理解成一张语义地图。每段资料都有一个坐标，用户问题也有一个坐标，系统去找离问题最近的资料点。

这比传统关键词搜索更灵活，但也有风险。离得近不等于业务上一定正确。比如“退款”“退货”“破损补偿”“保修”在语义空间里可能很近，但它们对应的处理流程、权限和话术完全不同。

所以向量数据库一定要配合 metadata。站点、产品线、版本、文档类型、状态、有效日期这些字段，能帮助系统先筛掉不该参与回答的资料。

  • market：避免 US、DE、JP 规则混用。
  • sku_family：避免旧款和新款资料混用。
  • doc_type：区分 SOP、产品事实、评论、广告复盘、平台规则。
  • status：只让当前有效资料参与回答。
  • effective_date：避免旧活动、旧价格、旧政策被引用。

Hybrid Search：语义和关键词都要用

Weaviate 文档说明，hybrid search 会结合 vector search 和关键词 BM25 搜索，并通过融合方法产生最终排序。Dify 文档也把 Hybrid Search 定义为同时执行全文搜索和向量搜索，再进行重排来选择最佳匹配结果。

这对跨境业务非常重要。因为你的资料里既有自然语言，也有大量精确词：SKU、ASIN、站点、型号、材质、法规编号、广告活动名、搜索词、竞品品牌、版本号。

纯向量搜索适合理解“用户说法不同但意思接近”。纯关键词搜索适合命中“B0XXX”“FDA”“stainless steel 304”“ACOS”“exact match”这种精确词。Hybrid Search 的价值，是让两类信号同时参与。

比如用户问“B0ABC123 的刀头能不能洗碗机洗”，向量搜索能理解它和“清洗注意事项”相关，关键词搜索能锁定 B0ABC123 和 dishwasher。两者结合，才更可能找到正确 chunk。

  • 评论、客服口语多：语义权重可以高一些。
  • SKU、型号、法规、站点多：关键词权重要保留。
  • 广告搜索词复盘：关键词和语义都重要，优先测试混合搜索。
  • 产品资料问答：用 metadata 先过滤产品线，再做混合搜索。

Rerank：第一轮找候选，第二轮排顺序

第一次检索通常会返回一批候选 chunks。问题是，候选里有相关资料，但最相关的不一定排第一。

Pinecone 文档说明，rerank 会根据 query 对候选文档重新排序。Dify 的 Knowledge Retrieval 文档也把知识库级设置和节点级设置比作两层连续过滤器：知识库设置决定初始结果池，节点设置进一步 rerank 或缩小结果池。

用业务语言讲，Rerank 就像二审。第一轮先把可能相关的资料捞上来，第二轮再判断哪个最应该给模型看。

Rerank 特别适合资料多、问题复杂、相似文档很多的场景。比如售后 SOP 里同时有破损、迟发、退货、换货、保修，向量搜索可能都觉得相关，Rerank 能把真正匹配用户问题的条目排到前面。

  • 适合用 Rerank：候选资料多、相似文档多、误召回多。
  • 不必一开始就用：资料量很小、问题很简单、成本敏感。
  • 需要注意：Rerank 会增加成本和延迟，要用测试问题判断值不值。
  • 关键指标：正确资料是否进入前 3，错误资料是否被压下去。

TopK 和 Score Threshold：别只用默认值

TopK 决定系统返回多少个候选 chunks。Score Threshold 决定低于相似度阈值的结果是否被过滤。Dify 文档也提示 TopK 和 Score 配置与 Rerank 阶段有关，实际使用要结合 rerank 设置理解。

TopK 太低，容易漏掉关键资料。比如一个客服问题需要同时看产品事实、售后 SOP 和话术模板，只返回 1 个 chunk 可能不够。TopK 太高，又容易把不相关资料一起塞给模型，增加幻觉风险。

Score Threshold 太低，机器人会在资料不够相关时硬答。太高，可能很多问题都答不出来。

商业知识库不要盲信默认值。你要用真实业务问题测试：标准问题能不能命中，换一种说法能不能命中，缺资料问题会不会拒答，冲突资料会不会提示人工确认。

  • 客服 SOP：先测试 TopK 3 到 5，观察是否需要多来源组合。
  • 产品参数问答：阈值可以更保守，避免错引用。
  • 广告复盘：TopK 可略高，因为常需要多个搜索词和活动证据。
  • 合规问题：阈值不达标就拒答或转人工，不要强行回答。

亚马逊场景：一个广告复盘知识库怎么调

假设你要做一个 Sponsored Products 广告复盘知识库。资料包括 Search term report 摘要、广告活动结构、Listing 版本、转化记录、竞品观察和运营复盘。

Amazon Ads 官方说明 Search term report 可以查看客户搜索词或与商品最佳匹配的搜索词。这个资料很有价值，但它不是自然语言文章，而是大量关键词、广告活动、SKU、匹配类型和指标。只用语义搜索，很容易漏掉精确搜索词；只用关键词搜索，又很难把相近意图的词归到一起。

正确做法是：先按时间窗口和广告活动切 chunk，再用 metadata 标注 market、campaign、ad_group、sku、match_type、date_range、action。检索时先按站点和 SKU 过滤，再用 Hybrid Search 同时匹配关键词和语义。

如果问题是“为什么 6 月便携榨汁杯 broad campaign ACOS 上升”，系统应该找到 6 月 broad campaign 搜索词变化、Listing 改版记录、竞品价格变化和上一轮否词动作，而不是只找一段泛泛的广告优化 SOP。

  • Chunk：按活动、时间窗口、问题类型切。
  • Embedding：帮助识别相似搜索意图。
  • 关键词搜索：命中具体 search term、campaign、SKU。
  • Metadata：先过滤市场、SKU、时间和广告类型。
  • Rerank：把最能解释问题的证据排到前面。

客服场景：为什么同一个问题会召回错误 SOP

再看客服知识库。用户问“瓶盖裂了能不能换”。如果系统召回的是“瓶身破损退货 SOP”，看起来相关，但处理动作可能不同。

这类问题通常来自三种原因。第一，chunk 切得太粗，把破损、裂痕、漏水、配件丢失放在同一个长文档里。第二，metadata 缺失，没有区分配件问题、主体问题、物流破损和使用后损坏。第三，TopK 或 rerank 设置不合理，正确 chunk 被排在后面。

解决方法不是让模型“更认真”。你要重切文档，把“配件裂损”“主体破损”“物流破损”“使用后损坏”拆开；给每个 chunk 加 problem_type；准备测试问题验证每类问题能否命中正确 SOP。

当检索不准时，先查召回结果，再改知识库。不要上来就换模型。

一套可执行的检索质量测试表

知识库调优不能靠感觉，要靠测试题。最少准备 50 个真实问题，按场景覆盖。

每个问题都记录：用户问题、预期命中文档、实际召回 chunks、是否进入前 3、是否引用正确、是否应该拒答、最终回答是否可执行。

测试题要包含五类：标准表达、口语表达、精确词表达、缺资料表达、冲突资料表达。只有标准问题测过，没有意义。真实客服和运营不会按你的文档标题提问。

管理者看这张表，就能判断到底是资料问题、切片问题、embedding 问题、关键词问题、rerank 问题，还是提示词问题。

  • 标准表达：和 SOP 标题接近的问题。
  • 口语表达：客服或运营日常说法。
  • 精确词表达：带 SKU、ASIN、型号、站点、活动名。
  • 缺资料表达：知识库里没有答案的问题。
  • 冲突表达：旧版本和新版本可能冲突的问题。

不要误读：参数不能替代资料治理

Embedding、Hybrid Search、Rerank 都很重要，但它们不能把烂资料变成好知识库。

如果文档版本混乱，metadata 缺失，旧 SOP 没归档，评论样本没有来源，广告报告没有时间窗口，再高级的向量数据库也只能在混乱里找相对像的内容。

也不要迷信更贵的 embedding 模型。模型更强不等于业务更准。知识库准不准，取决于资料质量、切片、元数据、检索策略、测试集和人工复核共同作用。

真正成熟的做法，是把每次错误回答都回溯到链路：是没有资料，资料切错，向量没召回，关键词没命中，rerank 排错，还是提示词没限制住。

  • 没有测试集，不要谈调优。
  • 没有 metadata，不要谈精确业务检索。
  • 没有版本管理，不要让旧资料参与回答。
  • 没有人工确认边界，不要让机器人回答合规和承诺问题。

7 天 SOP：把一个知识库的检索质量跑起来

第 1 天，选一个场景，不超过一个产品线或一个业务流程。

第 2 天，整理 30 到 100 份高质量资料，删除旧版本和无来源内容。

第 3 天，重切 chunk，确保每个 chunk 能回答一个完整业务问题，并保留标题和适用范围。

第 4 天，补 metadata：market、sku_family、doc_type、version、status、effective_date、owner。

第 5 天，分别测试 Vector Search、Full-Text Search、Hybrid Search，记录每种方式的召回结果。

第 6 天，启用或关闭 Rerank 做对照测试，看正确资料是否更稳定进入前 3。

第 7 天，整理 50 个测试问题表，把错误归类为资料、切片、元数据、检索、rerank 或提示词问题，并安排下一轮修正。

可以直接复制的检索诊断提示词

请帮我检查一个 AI 知识库的检索质量。

业务场景：【客服SOP / 产品资料问答 / 广告复盘 / Listing改版 / 新人培训】
资料类型：【SOP、产品说明、评论、Q&A、广告搜索词、规则文档】
当前问题：【例如答非所问、召回旧资料、漏掉SKU、回答太泛、无资料也硬答】

请按以下结构输出：
1. 可能是资料问题、Chunk 问题、Embedding 问题、关键词问题、Rerank 问题还是提示词问题；
2. 建议的 Chunk 切分方式；
3. 必须补充的 metadata 字段；
4. 是否建议使用 Hybrid Search，以及语义和关键词各自适合什么；
5. 是否建议启用 Rerank，应该观察什么指标；
6. TopK 和 Score Threshold 的测试建议；
7. 设计 20 个测试问题，覆盖标准表达、口语表达、精确词、缺资料、冲突资料；
8. 输出一份明天可以执行的修正 SOP。

明天可以照着做的清单

  • 先看召回结果，再判断是不是模型问题。
  • Chunk 要能回答完整业务问题，不要只追求小。
  • 每个 chunk 都带标题、站点、SKU/产品线、版本、更新时间。
  • Embedding 解决语义相近，不能单独保证 SKU、ASIN、日期和版本准确。
  • 业务资料里有大量专有词时，优先测试 Hybrid Search。
  • 相似资料多、误召回多时，再考虑 Rerank。
  • TopK 太低会漏资料，太高会引入噪音。
  • Score Threshold 要用缺资料问题测试，避免机器人硬答。
  • 至少准备 50 个真实测试问题。
  • 把错误归类到资料、切片、元数据、检索、Rerank、提示词，再逐项修。

结论

向量数据库不是玄学。对跨境卖家来说，它的价值不是技术名词，而是让 AI 在海量 SOP、产品资料、广告报告和客服话术里，更稳定地找到该看的那几段资料。资料治理是地基，检索调优是路径，模型生成只是最后一步。

资料来源