0.3、AI Agent 知识库、召回、Recall、Embedding等 相关的概念

1、关键词

• 召回（Recall）
• 向量检索（Vector Retrieval）、全文检索（Full-text Retrieval）、混合检索（Hybrid Retrieval）
• Score（得分）
• RAG（检索增强生成 Retrieval-Augmented Generation ）
• 知识库
• Rerank （重排序）

2、召回等概念

在 AI 应用平台（比如 Dify）中，​​召回（Recall）、向量检索（Vector Retrieval）、全文检索（Full-text Retrieval）、混合检索（Hybrid Retrieval）​​ 都是用于从知识库或文档库中查找与用户问题相关内容的不同策略。它们各有特点，适用于不同的场景。
Score（得分）通常是检索系统返回的每个文档与用户查询之间的“相关性分数”

2.1、​​召回（Recall）

简单说：召回 = 找出可能相关的文档；向量/全文是实现召回的技术方法。

• 定义​​：在信息检索领域，“召回”是一个通用术语，指的是从大量数据中找出​​潜在相关​​的内容，即尽可能不漏掉相关的条目。它并不特指某一种技术，而是目标。

• 在 Dify 的上下文中，“召回”通常指的是通过某种方式（可能是向量、全文、或两者结合）从知识库中找出与用户问题相关的​​候选文档集合​​，供后续的 RAG（检索增强生成 Retrieval-Augmented Generation ）模型进一步处理。

2.2、​向量检索和全文检索都可以是召回的手段之一​​

2.2.1. ​​全文检索（Full-text Retrieval / Keyword Search）​​

快速、直接、对关键词明确有效,无法理解语义，易受表述影响

• 原理​​：
  基于传统的关键词匹配，比如使用 Elasticsearch、MySQL 全文索引等工具，通过分析用户输入的关键词，在文档中查找包含这些词的文本。
• ​​优点​​：
  对于结构化良好、关键词明确的查询效果不错。
  检索速度快，对硬件要求相对较低。
• 缺点​​：
  无法理解语义，只能做字面匹配。比如“AI 助手”和“人工智能助理”可能因为用词不同而匹配不到。容易受同义词、近义词、表述方式影响。​​
• 适用场景​​：
  适合对精确关键词有强需求的场景，或者作为辅助检索手段。

2.2.2. ​​向量检索（Vector Retrieval / Semantic Search）​​​​

理解意图，匹配更智能,对短/模糊查询可能不准，开销略大

• 原理​​：
  将文档和用户问题都通过嵌入模型（Embedding Model，如 BGE、text-embedding-3 等）转换成高维向量，然后通过计算向量之间的相似度（比如余弦相似度）来进行检索，找出语义上最相关的文档。​​
• 优点​​：
  能理解语义，即使表述不同但含义相近的内容也能匹配到，比如“大语言模型”和“LLM”。
  更贴近人类理解，适合复杂、模糊的查询。​​
• 缺点​​：
  对短查询、非常模糊的问题可能效果不佳。
  计算成本相对较高，需要向量数据库支持（如 Milvus、Pinecone、Redis、Weaviate 等）。
• ​​适用场景​​：
  适合语义搜索、问答系统、知识库助理等需要“理解意图”的场景。

2.2.3、混合检索（Hybrid Retrieval）​​

兼顾语义与关键词，效果好,一般用于生产级 RAG、多样化查询

• ​​原理​​：
  将​​向量检索​​和​​全文检索​​的结果进行合并（比如加权、排序融合），综合两者的优势，既考虑语义相似性，也考虑关键词匹配，从而提高召回的准确性和召回率。​​
• 优点​​：
  结合了语义理解和关键词精准匹配的优势，效果通常更好。
  能适应更多样的用户查询方式。
• ​​缺点​​：
  实现复杂度更高，需要对不同检索结果进行合理的融合与排序。​​
• 适用场景​​：
  推荐用于生产环境中的知识库问答，尤其是用户查询方式多样、知识表达形式不一的场景。

2.3、Score

• Score 是什么
  Score（得分）是检索系统返回的每个匹配文档与用户查询之间的相关性强弱的数值。​​
  它表示：这个文档和用户的问题有多相关？
  ​​值越高，通常代表相关性越强。​​
  不同的检索方式，计算 score 的方法和范围可能不同。

• 不同检索方式中的 Score

场景	是否有 Score	Score 代表什么	用途
向量检索	✅ 有	语义相似度（如余弦相似度）	判断文档与问题的语义相关性
全文检索	✅ 有	关键词匹配强度（如 BM25）	判断文档与问题的关键词相关性
混合检索	✅ 有	多维度综合得分	兼顾语义与关键词，选出最优文档
普通数据库查询（无相关性排序）	❌ 通常没有	-	仅按条件筛选，不涉及“相关度”

3、召回在 RAG 系统中的典型环节

在一个典型的 ​​RAG（检索增强生成）流程​​ 中，整个过程可以分为几个核心步骤，其中 ​​召回通常处于最前端，但也可能贯穿多个阶段。​

3.1、标准的RAG 流程

在下面的流程中，“召回”是第 2 步，也是最关键的环节之一。
没有召回，就没有上下文；召回质量差，LLM 回答可能就不准确。

RAG 标准流程（简化版）：
​​（1）用户提问（User Query）​​
​​（2）召回（Retrieval）：从知识库中找出相关文档​​

• 使用向量检索 / 全文检索 / 混合检索
• 目标：找出潜在相关的知识片段

（3）文档预处理（可选）​​

• 对召回的文档进行清洗、截断、格式化

​​（4）提示词构造（Prompt Construction）​​

• 将用户问题 + 召回的文档组合成 LLM 的输入 prompt

（5）LLM 生成回答（Generation）​​

• 基于问题和召回内容，生成答案

​​（6）返回答案给用户​

3.2、召回具体在哪些实际环节中使用

• ​【核心环节】RAG 系统中的知识检索（第 2 步）​​

这是召回最常见的使用位置。
​​目的​​：从知识库（可能是向量数据库、ES、数据库等）中，根据用户问题，找出若干篇相关的文档或文本片段。
​​技术方式​​：向量检索（语义召回）\全文检索（关键词召回）\混合检索（两者结合）
​​输出​​：一组文档（如 top 3 ~ top 5），以及对应的 score。
​​谁来做​​：Dify、LangChain、LlamaIndex、或者是你自己搭建的检索模块。

• 【扩展环节】多路召回（Multi-path Recall）​​

在一些复杂的 RAG 系统中，为了提高召回的全面性和准确性，会采用 ​​多路召回策略​​，即：
同时使用 ​​多种召回方式​​，比如：
向量语义召回一路
关键词全文召回一路
基于元数据 / 分类 / 标签的召回一路
然后对这些不同召回路径的结果进行 ​​合并、去重、加权排序​​，最终形成一份综合的候选文档列表。

• 【进阶环节】两阶段召回（Two-stage Retrieval）​​

先召回来一堆，再从中精选
有些系统为了在效率和精度之间做平衡，会采用 ​​两阶段召回架构​​：
第一阶段（粗召回 / Candidate Generation）：
快速、范围广，比如基于关键词、倒排索引、分类标签，先找出 ​​潜在相关的文档集合（可能比较多）​​。
第二阶段（精召回 / Re-Ranking）：
在第一阶段结果的基础上，使用更精准的方法（如向量语义检索、语义相似度模型）对候选集进行​​排序和筛选​​，只保留最相关的少量文档。

• 【隐式环节】用户画像 / 上下文增强召回​

这类召回不一定来自“知识库”，但本质上也是“找出相关信息”的过程，属于广义的召回
在一些高级应用中，“召回”还可能涉及：
​​根据用户身份、历史行为、偏好，召回个性化的内容；​​
​​结合对话历史，召回之前相关的上下文信息；​​
​​跨文档、跨会话的关联召回。

3.3、在 Dify 平台中的“召回”环节

在 ​​Dify 知识库问答流程​​ 中，召回环节大致体现在：
​​（1）用户输入问题​​​​
（2）Dify 调用你配置的知识库模块，执行检索（即召回）​​

• 使用你选择的检索方式：向量 / 全文 / 混合
• 从向量库（如 Redis、Milvus、Qdrant、Weaviate）或 Elasticsearch 中查找相关内容

​​（3）返回 Top N 个相关文档及其 score​​
​​（4）将这些文档与用户问题一起，构造 Prompt，送入 LLM 生成答案​​

在 Dify 中，​​“召回”主要发生在知识库检索阶段，是你配置的向量/全文/混合检索策略实际发挥作用的地方。​​

在 Dify 的知识库修改配置

选择检索方式
调整检索参数（比如 top K、score 阈值）
查看召回文档和得分情况
优化召回效果，从而提升整体回答质量

4、知识库、特定大模型、向量化和召回的关系

​​知识库构建是基础​​：做好文档上传、分块、元数据、索引等，是召回可用的前提。
​​向量化是向量检索的核心​​：选择合适的 Embedding 模型（如 BGE 系列），不是所有大模型都支持或擅长向量化。
​​大模型是回答生成的核心​​：召回后需要大模型来理解上下文并生成答案，因此大模型的能力直接影响最终效果。召回之后，可以借助 支持 Rerank 的大模型进行排序优化。
​​不是所有大模型“全能”​​：有的擅长生成、有的擅长理解、有的擅长 Embedding，根据场景选对模型很重要。

4.1、知识库的构建

召回（Recall）的前提是必须先有知识库，且知识库需要经过合理构建与索引，否则无法执行召回操作

知识库构建是召回的​​必要前置条件​​，包括：

​​文档上传与存储​​：比如 PDF、TXT、Word 等文件导入到知识库。
​​内容分块（Chunking）​​：将长文档切分成适当大小的文本块（Chunks），便于检索和上下文管理。
​​元数据配置（可选）​​：比如给文档打标签、设置分类，辅助后续筛选和召回。
​​索引构建​​：
如果使用​​全文检索（如 Elasticsearch）​​，需要构建倒排索引。
如果使用​​向量检索（如 Milvus、Qdrant、Redis）​​，需要先进行​​向量化（Embedding）​​，再构建向量索引。

4.2、知识库的构建和向量化（语义）检索

以 Dify 为例，当你选择“向量检索”时，系统会使用你指定的 Embedding 模型，对知识库内容进行向量化处理并构建索引。

4.2.1、向量化（Embedding）是什么？​

将一段文本（比如一个文档块）通过 Embedding 模型，转换成一个高维向量（比如 384 维、768 维、1024 维等）。
相似内容的文本，其向量在空间上也比较接近，从而可以通过向量相似度（如余弦相似度）进行语义检索。

4.2.2、谁来做向量化？

通常由专门的 ​​Embedding 模型（嵌入模型）​​来完成，这些模型属于大模型生态的一部分，但职责单一：​​将文本转为向量。​​
常见的 Embedding 模型包括：

BAAI/bge-small、bge-base、bge-large（中文友好，效果优秀）
text-embedding-3-small / text-embedding-3-large（OpenAI）
sentence-transformers 系列（如 all-MiniLM-L6-v2）
腾讯混元 Embedding、阿里云 Embedding、智谱 Embedding 等

4.2.3、知识库构建那个时机设计向量化

在知识库构建时，​​文档内容分块完成后需要进行向量化​​，​​即在将文本块存入向量数据库前，通过 Embedding 模型将其转换为向量表示，以便后续进行语义检索

4.2.4、不是所有的大模型都内置或支持直接输出高质量的文本向量

Embedding 模型，​​本质上也是大模型的一种（通常是轻量级的大模型，专门用于 embedding 任务）​​。但注意，​​不是所有通用大模型（如 GPT、混元大语言模型、文心一言等）都内置或支持直接输出高质量的文本向量。​​大部分 ​​大语言模型（LLM，如 GPT-3.5/4、Hunyuan、ChatGLM）主要用于生成或理解，而不是向量化。​

4.2.5、向量数据库

常见的向量数据库有 Milvus、Qdrant、Weaviate、Redis（带向量插件）、Pinecone、Vespa、FAISS（本地轻量级）等。
Dify 默认支持多种向量数据库，通常可配置使用 Qdrant、Milvus 或 Redis Vector 等，具体默认选项依部署环境和版本而定，一般推荐 Qdrant 或 Milvus。

4.3、召回过程可以借助支持Rerank(重排序)大模型优化排序

召回过程本身不需要 Rerank 模型的支持，Rerank 是召回后用于对文档排序优化的可选步骤。只有在追求更高精度、召回内容较多或质量不一时，才建议配置 Rerank 模型来进一步提升效果

4.3.1、Rerank 是召回的辅助措施

知识库的构建完成时召回的前置条件。
召回（Retrieval）过程本身，通常不依赖 Rerank 模型。Rerank 模型是“召回之后、用于对结果排序优化”的可选模块，用于进一步提升召回内容的相关性，但不是召回的必需环节。
常见 Rerank 模型：bge-reranker、cohere-rerank、cross-encoder-stsb等。
它属于​​排序模型（Ranking Model / Cross-Encoder）​​，不是 Embedding 模型。

4.3.2、实践

​​如果追求简单可用，只用向量检索（加 Embedding 模型）做召回，不配置 Rerank，系统也能正常运行。​​
​​如果你希望回答更精准、尤其是知识库内容较多或杂时，建议开启 Rerank 并配置一个优质的 Rerank 模型（如 bge-reranker）。​​
​​在 Dify 中，Rerank 是可选配置，通常在 Agent / 应用配置 → 知识库检索设置中启用，并选择一个 Rerank 模型。​

5、召回后处理

5.1、召回后处理

步骤	后处理内容	是否必须	说明
1	控制召回数量（Top K）	✅ 推荐配置	限制返回文档条数，比如 3~5 条
2	（可选）Rerank 精排	✅ 推荐开启	对召回内容二次打分，挑出最相关的
3	过滤低质量/无效内容	✅ 通常自动完成	去掉空内容、低分内容
4	格式化与拼接	✅ Dify 自动完成	拼接用户问题 + 文档，构造 LLM 输入上下文
5	截断与窗口适配	✅ Dify 自动处理	保证总长度不超过 LLM 上下文限制
6	零召回 / 无命中处理	✅ 建议配置兜底	没有召回内容时，决定如何回复或流转
7	多工具逻辑编排（Agent）	✅ 可自定义	比如先查知识库，不行再调用其他工具或直接回答

5.2、召回后的结果一定给LLM吗？

这是常规流程，召回内容需要 LLM 做二次加工处理，但不是必须的。
以 Dify 为例。召回后“通常”会接着调用 LLM（尤其是默认应用或标准问答场景），用于生成答案；但在 Agent 智能代理的多工具编排模式下，召回后不一定会直接流向 LLM，而是可以作为其中一个步骤，后续由 Agent 判断是否调用 LLM 或其他工具。​​
在绝大多数情况下，Dify 会自动处理好召回内容与用户问题的整合与参数传递，开发者通常无需手动拼接。它会将召回的文档与用户问题，按照预设格式组合成 LLM 或工具所需的输入（即上下文），这是一项内置的自动化能力。​

6、思维拆解工具

思维拆解工具-一键直达