✅派聪明 RAG知识库检索模块设计方案

# FAISS简介与权限过滤方案## 一、FAISS 是什么？ 是的，FAISS 是由 Meta（Facebook）开源的**专用向量相似度检索库**，专注于高维向量的快速 TopK检索，支持向量压缩、GPU 加速等特性。但它本质是一个**纯计算引擎**，不具备数据管理能力——没有内置的权限体系、过滤查询、事务等功能，这一点与 Elasticsearch 不同。 ## 二、如何在 FAISS检索时附加权限过滤？ 由于 FAISS 本身不支持在检索时直接做复杂条件过滤，常见方案有以下几种： **1. 先检索后过滤** - 先用 FAISS检索 topK * N（扩大候选集），再根据向量 ID 反查元数据（如 MySQL中的权限标签），过滤掉无权限的结果，截取最终 topK-优点：实现简单；缺点：可能需要放大候选集才能凑够结果**2. 双引擎协同（派聪明采用的架构）** - **Elasticsearch**负责全文检索、文档元数据存储和**权限过滤条件**（如基于组织标签、层级权限的 filter） - **FAISS** 只做纯向量相似度计算-检索流程：ES 先按权限过滤出“有权限的文档集合”，FAISS 在该范围内做向量检索（或两边结果做交集），最后合并排序**3. ID映射 + 分索引** - 按权限标签/部门预先构建多个 FAISS索引，用户查询时只检索其有权访问的索引## 三、小结在派聪明的架构中，权限过滤仍由 Elasticsearch 和 MySQL 元数据体系承担，FAISS专注于向量计算，通过“职责分离 + 双引擎协同”的方式，既获得了 FAISS 的性能优势（毫秒级响应、QPS 提升5~10倍），又保留了完整的权限控制能力。

# 从用户输入到系统给出回答的全流程基于第一阶段架构（Elasticsearch混合检索），完整流程如下： ##1. 参数接收与校验系统接收用户输入的查询文本（query）、返回结果数量（topK，默认10）等检索参数，并对其进行合法性校验，确保格式正确、数据合理。 ##2.查询向量化将用户的查询文本交给豆包提供的向量化 API，把自然语言转换成可用于语义检索的向量表示（与文档入库时使用的同一模型版本），作为后续语义匹配的基础。 ##3.构建混合检索查询系统构建一个 Elasticsearch查询语句，同时包含两部分： - **关键词检索**：借助 IK 分词器对查询分词，对 text_content 字段做全文匹配； - **向量检索**：基于 dense_vector 字段，通过脚本打分计算查询向量与文档向量之间的相似度。 两者按内部权重融合，可在单次请求中完成精准排序，减少网络延迟。 ##4.权限过滤查询中加入权限过滤条件，确保用户只能访问有权内容，规则包括： 1. 用户可访问自己上传的文档； 2. 用户可访问被标记为公开的文档； 3. 文档被打上特定权限标签（如部门、层级标签，父标签自动包含子标签，DEFAULT标签全局可访问）时，拥有该标签的用户可访问。 ##5.检索执行与打分带权限条件的完整查询发送给 Elasticsearch，系统综合文本相关性、语义相似度与权限匹配度对结果打分排序。 ##6. 结果组装与返回根据 topK 参数挑选排名靠前的文档，从 MySQL（file_upload、document_vectors 表）获取元数据（标题、作者、上传时间等），从 MinIO 关联原始文档，格式化后打包成 JSON响应返回，包含 file_md5、chunk_id、text_content、score、file_name等字段。 简言之：**输入校验 →查询向量化（豆包API）→混合检索（关键词+向量）→权限过滤 → 打分排序 → 取topK →补充元数据 → 格式化返回**。

这是我从文章中选择的一段文本："结合语义检索和关键词检索结果" 什么是结合语义检索和关键词检索结果 当前模型还在开发当中，请右上角下拉框切换到其他模型

这是我从文章中选择的一段文本："我们会根据 topK 参数，挑选出排名靠前的若干个文档" 派聪明项目中的topK参数是多少 当前模型还在开发当中，请右上角下拉框切换到其他模型

请围绕下面这段划线内容回复："集成FAISS" 现在项目使用faiss 当前模型还在开发当中，请右上角下拉框切换到其他模型

，用户上传得文档是否需要审核! 当前模型还在开发当中，请右上角下拉框切换到其他模型

根据提供的参考资料，为您解答如下： **1.豆包 API 在项目哪里用到？** 在项目整体的检索流程中，豆包 API 用于**查询文本的向量化处理**。当系统接收到用户的查询请求和参数并通过校验后，会把用户的自然语言查询文本交给豆包 API，将其转换为可用于语义匹配的向量表示。 *（注：参考资料中未具体说明在代码的哪一个文件或目录中调用了该 API，仅说明了它在系统业务流程中的作用位置。）* **2. Elasticsearch 是什么？** 在“派聪明”这个 RAG 项目中，Elasticsearch（简称 ES）是作为**底层统一检索引擎**来使用的。它的主要作用包括： * **存储向量数据**：直接存储由豆包 API等生成的文本向量数据。 * **全文检索（关键词搜索）**：利用 ES 强大的文本索引能力，配合 IK 分词器，实现对中文内容的高效分词和关键词匹配。 * **向量检索（语义搜索）**：利用 ES 对 `dense_vector` 类型的支持，计算用户查询向量与文档向量之间的相似度来进行排序。 * **混合检索**：在单次请求中，将上述的“全文检索”与“向量检索”结合起来，综合打分排序返回高质量的搜索结果。

根据参考资料，派聪明的混合检索采用的是**单次请求内的并行融合方式**，而非分阶段串行执行。 具体来说，系统会构建**一个单一的 Elasticsearch 查询语句**，该查询**同时包含**： 1. **向量检索**：基于豆包 API 生成的向量，计算语义相似度（使用 `dense_vector` 类型 + 脚本打分） 2. **全文检索（关键词检索）**：借助 IK 分词器对 `text_content` 字段进行文本匹配（底层即 BM25 算法） 这两路检索**并行执行**，通过**内部权重**灵活调节两种检索方式对最终排序结果的影响，最终按综合得分返回 TopK 结果。 参考资料中明确提到： > **"在一次查询请求中，既能进行关键词匹配（全文检索），又能做语义相似度计算（向量检索）。通过设置内部权重，我们可以灵活地调节两种检索方式对最终结果的影响...同时，由于是单次请求发往 Elasticsearch，不仅减少了网络延迟，也降低了整体的系统复杂度。"** 所以结论是：**两路并行、单次请求、权重融合**，而非先向量检索再执行 BM25 的串行方式。