RAG检索增强生成专题

简述RAG的定义及核心工作流程+局限性

RAG 是检索增强生成，本质是让大模型在回答前先从外部知识库中检索相关资料，再把检索到的内容作为上下文交给大模型生成答案。它不改变模型参数，主要解决大模型知识过时、缺少企业私有知识以及幻觉较高的问题。

标准流程一般是：先对企业文档做采集、清洗和结构化解析，然后按语义或固定长度切分成 Chunk，调用 Embedding 模型生成向量并写入向量库；用户提问时，对 Query 做改写或向量化，通过向量检索、关键词检索或混合检索召回 TopK 文档片段，再通过 Rerank 精排，最后把高相关上下文、用户问题和约束规则拼成 Prompt，调用大模型生成答案，并返回引用来源。

它的局限也很明显。RAG 的效果强依赖知识库质量、切分策略、Embedding 模型、召回和重排质量；如果文档解析错、召回错或上下文不足，大模型仍然会答错。它也不能彻底消除幻觉，对跨文档复杂推理、表格图片解析、权限控制、实时更新、长上下文成本和延迟都有工程挑战。所以企业落地时，RAG 不是简单接一个向量库，而是一整套知识治理、检索、生成、评估和监控体系。

RAG中Rerank的含义及其实现方式

Rerank（重排序 / 精排）是 RAG 检索链路中多路粗召回后的精细化打分筛选模块；粗召回（向量检索、BM25 等）仅做粗粒度相似度匹配，存在大量低相关、噪声片段，Rerank 通过更强语义模型对 Query-Chunk 配对精准打分，重新排序并截断 Top 高相关片段，压缩送入 LLM 的上下文、提升答案准确度、减少幻觉。

工业界主流分三类实现：交叉编码器 Cross-Encoder 重排、LLM 轻量重排、规则 / 统计简单重排；线上落地以 Cross-Encoder 为主流，LLM 重排用于高精准低并发场景。

交叉编码器 Cross-Encoder 重排

原理：输入拼接 [CLS] Query [SEP] Chunk [SEP]，单模型直接输出两者相关性分数，双向交互编码 Query 与文档全部 token，语义匹配精度远高于 Embedding 双塔模型

优缺点

  • 优点：打分精度最高，对歧义、长语义、专业术语匹配效果强
  • 缺点：无法提前预计算向量，每条候选都要单独前向推理，耗时、算力开销高于 Embedding 召回

落地选型轻量模型：bge-reranker、ms-marco tiny、e5-rerank 小参数量版本适配线上并发

工程优化：限制重排候选池数量（一般粗召回取 Top20~Top50 再送入 Rerank，不做全量重排控时延）

LLM重排

实现思路：构造 Prompt 让 LLM 输出 Query 和 Chunk 的相关性分值 / 等级，示例指令：“判断下面文档片段和用户问题的相关程度，输出 0-10 分数，只返回数字”

细分两种用法：

1）打分式：批量输入候选片段，输出相关性分数排序；

2）选择式：让 LLM 直接筛选保留有用片段，剔除噪声

优缺点

  • 优点：理解复杂逻辑、多意图、长上下文能力远超 Cross-Encoder；可同时完成过滤 + 摘要预处理
  • 缺点：推理成本极高、延迟大，不适合高 QPS 线上业务，多用于离线知识库评测、低并发问答后台

简易规则 / 统计重排

实现方式：基于 BM25 分数、向量相似度、文档元数据（更新时间、文档权重、关键词命中次数）加权混合打分重排，无深度学习模型

适用场景：算力受限边缘端、小型轻量化 RAG Demo、并发极高且精度要求一般的业务

缺陷：无法处理深层语义歧义，精度最低，仅作为辅助兜底，不能单独替代 Cross-Encoder

混合检索的定义及在大模型应用中的核心作用

混合检索（Hybrid Retrieval）指同时结合稠密向量检索（语义检索）与稀疏关键词检索（BM25/TF-IDF） 两路召回，合并、去重后统一输出候选文本块的检索方案；部分场景会附加全文检索、图检索、元数据过滤构成多源混合召回。

核心作用：互补单一检索短板，同时提升检索召回率与精准度，解决纯向量检索丢失专有名词、纯关键词检索不懂语义同义替换的问题，从上游减少噪声，降低后续 Rerank 与 LLM 幻觉压力，是工业级 RAG 标准检索底座

两路核心组件拆分

  • 稀疏检索（BM25 为主）：基于词频、词位置、倒排索引，匹配字面关键词、专业术语、编号、专有名词
  • 稠密向量检索（Dense Embedding）：基于 Embedding 语义向量，匹配同义词、转述、上下文语义相似内容

核心作用：

  1. 互补缺陷，覆盖两类检索盲区

    • 弥补稠密向量短板：行业黑话、产品 ID、合同编号、冷僻专业词汇仅靠语义向量极易漏召回，BM25 可精准命中字面匹配内容
    • 弥补 BM25 短板：用户转述提问、同义词替换、模糊语义查询（如 “报销流程” 同义 “费用申报步骤”）关键词无法匹配，向量检索捕获深层语义

  2. 提升整体召回率，避免关键信息遗漏

    单一检索容易丢失关键参考材料，混合两路可最大化捞取潜在相关片段，防止 LLM 因缺少素材编造内容（幻觉）

  3. 降低下游 Rerank、LLM 计算开销

    两路召回互补后，候选池中有效信息占比更高，无关噪声减少；同等候选条数下，送入 Rerank 的无效文本更少，减少精排推理耗时、节约 LLM 上下文窗口

详解RAG的完整工作流程

工业级落地完整 RAG 分为两大阶段：离线知识库构建流水线、在线问答推理流水线，共 7 个标准核心步骤；

全链路包含文档解析→清洗分块→向量化入库→用户 Query 处理→多路混合召回→Rerank 精排过滤→Prompt 组装 + LLM 生成，高阶生产环境会额外增加元数据过滤、文档权限拦截、结果溯源校验、缓存、监控告警模块。整套链路实现外部私有数据可控注入大模型，解决知识滞后、私有数据不可见、模型幻觉问题。

1. 什么是 RAG？详细描述一个完整 RAG 系统的详细工作流程？ | 小林面试笔记

RAG应用中，优化检索精度的数据清洗与预处理方式

RAG 检索精度低的上游根源大多是文档原始噪声、碎片化语义、无效冗余文本污染 Embedding 表征与倒排索引；数据清洗 + 预处理分为文档级清洗、段落降噪、Chunk 粒度语义优化、元数据标准化、Query 侧预处理五大类工业标准手段，通过剔除干扰信息、规整文本语义、统一表征空间，从源头提升混合召回、Rerank 匹配效果，减少无关召回，是低成本高收益的检索精度优化方案。

在 RAG，即检索增强生成应用中，检索精度很大程度取决于知识库构建质量。数据清洗和预处理的目标不是简单“把文本弄干净”，而是把原始文档处理成语义完整、噪声较低、边界清晰、元数据充分、便于召回和排序的知识单元。RAG 的核心思路是让大语言模型在生成前引用外部知识源，而不是只依赖模型自身参数中的知识，因此外部知识库的质量会直接影响最终回答质量。

我一般会把预处理拆成几个阶段：第一是文档解析，要把 PDF、网页、Markdown、Word、数据库记录等不同来源转成统一的文本和结构表示；第二是噪声清洗，去掉页眉页脚、导航栏、版权声明、重复模板、乱码、无意义空白等内容；第三是结构化切分，按照标题、段落、表格、代码块、问答对等语义边界切成 chunk，而不是机械按固定字符数硬切；第四是元数据增强，给每个 chunk 绑定来源、标题路径、更新时间、版本、权限、业务标签等信息，便于过滤和溯源。

从工程实践上看，优化检索精度通常要结合检索方式一起做。如果是向量检索，要关注 chunk 是否语义完整、是否包含必要上下文；如果是关键词检索或混合检索，要保留关键术语、实体名、编号、条款号、产品名等精确匹配信息。切分策略也没有放之四海而皆准的最优解，应该通过评测集观察 Top-K 召回率、命中 chunk 质量、答案引用准确性，再调整 chunk 大小、重叠比例、元数据过滤和重排序策略。

查询扩展的定义以及在RAG中的应用价值

查询扩展是指在用户原始问题基础上，补充同义词、简称全称、业务术语、实体别名、相关关键词或等价问法，让检索系统更容易召回相关文档。它发生在 RAG 的召回前，核心目标是提升召回率，减少因为用户问法和知识库写法不一致导致的漏召回。

比如用户问“报销流程”，文档中可能写的是“费用报销审批规范”；用户问“模型延迟高”，知识库中可能写的是“推理耗时、首 Token 延迟、吞吐下降”。如果只用原始 Query，可能召回不到；通过查询扩展，可以生成多个相关表达，再用于 BM25、向量检索或混合检索。

工程上常见做法有两类：一类是基于规则和业务词典的扩展，优点是可控、稳定，适合产品名、系统名、简称、术语映射；另一类是基于 LLM 的 Query Rewrite 或 Multi-Query，适合口语化问题和复杂语义表达。实际落地通常会结合意图识别、多路召回、Rerank 和元数据过滤，避免扩展过宽带来噪声。

它的价值主要体现在提升 Recall@K、降低无答案率、增强对简称、别名、口语化表达和领域术语的适配能力。但查询扩展不是越多越好，需要控制扩展数量、权重和业务范围，并通过 Recall@K、MRR、NDCG、答案准确率和误召回率持续评估。

自查询的含义以及在RAG中的必要性

利用大模型的自然语言理解能力，对用户原始问题进行解析，提取出”核心查询意图””过滤条件””上下文约束”等元信息，再将这些元信息转化为结构化的检索指令（如向量检索+属性过滤的组合指令），最终精准召回目标文档。

例：原始问题为“2024年发布的关于RAG自查询的中文技术博客”

传统检索做法：提取关键词”2024年””RAG””自查询””中文””技术博客”，执行关键词/向量匹配

自查询做法：

  1. 核心查询意图：RAG自查询相关内容
  2. 过滤条件：2024年发布、中文、技术博客类型 生成结构化检索指令：”向量检索（RAG自查询） + 属性过滤（发布时间=2024，语言=中文，文档类型=技术博客）”

为什么RAG中需要自查询？

  1. 传统检索的痛点
  • 无法理解”隐含约束”：用户问题中未明确提及但关键的条件（如”最近半年的资料””医疗领域的案例”），传统检索无法捕捉；
  • 无法区分”核心意图”与”辅助条件”：容易因辅助条件的关键词干扰，导致核心意图检索偏差（如用户问”北京地区的AI大模型政策”，传统检索可能过度聚焦”北京”而忽略”AI大模型政策”这个核心）；
  • 结构化信息利用不足：若文档包含属性标签（如发布时间、领域、文档类型），传统检索无法将这些属性与语义检索结合；
  • 对模糊问题处理乏力：用户问题表述不清晰（如”如何解决RAG的检索问题？”），传统检索只能宽泛匹配，而自查询可先解析核心矛盾（是”检索速度””检索精度”还是”召回率”问题）。
  1. 自查询的核心作用
  • 提升检索精准度：通过解析隐含约束和核心意图，过滤无关文档，减少”伪相关”结果；
  • 适配复杂查询场景：支持多条件组合查询（领域、时间、类型等），满足用户精细化需求；
  • 降低用户表达成本：用户无需刻意组织关键词，可自然表述需求（如”我想找去年的Python教程，要入门级的”），自查询会自动提取关键条件；
  • 衔接结构化与非结构化检索：将文档的结构化属性（如标签、元数据）与非结构化语义内容结合，让检索更灵活。

提示压缩的定义以及在RAG中的应用意义

提示压缩是对检索出的文档内容做精简处理，提取核心信息、过滤无关文本，让最终喂给大模型的内容既保留关键信息，又不撑爆上下文窗口。

比如检索到一篇 10 页的技术白皮书，压缩后只保留跟用户问题相关的 2 个核心章节和关键数据，那些无关段落直接砍掉。

为什么需要提示压缩？RAG 的生成效果全靠喂给模型的文档质量，检索出来的文档通常有三个问题：

  1. 上下文窗口有限。GPT-4 Turbo 是 128k tokens，Claude 是 200k tokens，听着很大，但实际业务里检索 10 篇文档轻松就超了。压缩能把关键信息浓缩进有限的 token 里。
  2. 无关内容稀释重点。用户问”如何优化代码”，文档里 80% 是算法原理、只有 20% 是优化技巧，不压缩的话模型容易被原理部分带跑偏，甚至产生幻觉。
  3. 省钱省时间。调用商业大模型按 token 计费，GPT-4 每 1000 tokens 要 0.03 美元，多塞 5000 个无关 token 就是白花 0.15 美元。推理速度也会变慢，每多 1000 tokens 大概慢 200ms。

压缩会不会把关键信息也压没了？怎么保证压缩质量？

  1. 把用户问题作为压缩的锚点，跟问题相关性高的内容优先保留
  2. 设置压缩率上限，别压得太狠，保留 30%-50% 是比较安全的区间
  3. 用 NER 提取关键实体，人名、日期、数字这些硬性信息强制保留
  4. 上线前用测试集跑一遍，对比压缩前后的回答质量

RAG调优后效果评估的方法及实际应用中的评估标准

RAG 调优后的效果评估围绕三个维度：检索质量、生成质量、系统性能。

检索质量：

  • Precision@k：前 k 个结果里相关文档占多少，比如前 5 个结果有 3 个相关，Precision@5 就是 60%
  • Recall@k：前 k 个结果覆盖了多少相关文档，知识库有 10 个相关文档，检索出 4 个，Recall@5 就是 40%
  • MRR：第一个相关结果排第几，排名越靠前越好
  • NDCG：综合考虑相关性等级和排名位置，区分”高度相关”和”沾点边”的文档

生成质量：

  • 忠实度：答案是不是基于检索内容生成的
  • 答案相关性：回答有没有解决用户的问题
  • 可信度：生成的内容有没有幻觉，有没有瞎编

系统性能评估：

延迟、吞吐量、错误率

RAG中分块的定义及分块的必要性

分块（Chunking） 是将长文档切分成较小语义单元的过程。定义：把一篇完整的文档切割成若干个独立的小块，每个chunk单独进行向量化存储。

为什么要分块？

  1. 模型输入限制
    • LLM有上下文长度限制（如128K token），无法一次处理整本手册
    • 检索时只能返回部分内容
  2. 检索精度
    • 用户问”如何排查OceanStor故障”，如果返回整本手册没有意义
    • 分块后能精确返回”故障排查”相关的小节
  3. 相似度匹配质量
    • 语义相近的短文本比长文档更容易准确匹配
    • 噪声更少，embedding更精准
  4. 计算成本
    • 向量化和检索的计算量随文本长度指数增长
    • 短chunk成本更低、速度更快

RAG中常见分块策略及各自差异

  1. 固定大小分片：这是最原始也是最简单的文本分段方法。它将文本分割成指定数量的字符块，而不管其内容或结构是怎么样的。
  2. 递归分片：主要方式就是可以指定一些列分隔符，通过这些分隔符可以用来分割文档。例如：”\n\n” - 双换行符、”\n” - 换行
  3. 基于文档分块：利用文档固有结构（如标题、章节、列表、表格）进行切分，每个结构单元作为一个块。它通过与文档的逻辑部分对齐来保持结构完整性。例如markdown文件
  4. 语义分块：借助自然语言处理（NLP）技术，通过理解文本的语义边界（如主题转换、逻辑段落）进行智能分割
  5. 智能分块：直接借助大模型来进行分割，而不是NLP模型

解读RAG中的Embedding技术

Embedding 就是把文本、图像、音频这些人能理解的信息，转换成一串数字向量，让计算机能够理解和计算。

这串向量就像文本的”数字指纹”，捕捉了语义信息。”猫”和”狗”的向量会很接近，因为它们都是动物；”开心”和”悲伤”的向量会远离，因为它们是反义词。语义相近的对象在向量空间中彼此邻近，语义相异的对象则相距较远。

相似度比较：

  1. 余弦相似度

最常用的语义相似度查询方法，主要就是看两个向量的夹角是否接近。夹角越小，向量越“同方向“，则语义越相似。

余弦值范围：[−1，1]，1 表示两个向量方向完全一致（语义高度相似），0 表示两个向量正交（没有语义相关性），-1 表示方向完全相反（语义相反）。向量长度不影响结果，只关心方向，特别适合文本语义匹配。

  1. 欧几里得距离

就像测量空间中两点之间的直线距离。距离越小，则相似度越高，主要应用于具有几何意义的场景，如图像相似度分析

  1. 点积

可以理解成“两个向量在同一方向上的重叠程度”。如果两个向量都又长又指向差不多的方向，那么点积就会很大；如果它们方向相反，点积会变成负数；如果它们垂直，则点积为0。

点积是最简单、最高效的一种相似度计算方法，直接计算两个向量的内积。值越大，表示两个向量越相似，tansformer的注意力机制就是使用的点积来计算权重。

RAG中常见的Embedding Model嵌入模型

  • bge-m3：1024维，开源，推理速度快，中英文能力表现较好
  • GTE 系列：优势是中文效果不错，和阿里生态结合更顺优势是中文效果不错，和阿里生态结合更顺
  • M3E 系列：早期中文 RAG 项目常用，轻量、部署简单

不同嵌入模型输出的向量维度不一样，这对 RAG 系统有什么影响？

  • 向量维度越高，语义表达能力越强，但存储成本线性增长，比如 1536 维比 512 维多占 3 倍空间。
  • 检索时计算相似度的开销也会增加，百万级文档量下差距明显。
  • 另外高维向量更容易出现维度灾难，距离区分度下降。实际项目里 512 到 1024 维通常是性价比最高的选择。

RAG中Embedding Model的选型因素及方法

选择 Embedding Model 核心看 7 个因素，可以概括为”准、快、专、广、大、活、省”：

  • 准，语义准确性。模型能不能精准捕捉文本语义，长句理解、上下文关联、同义词区分这些能力直接影响向量相似度计算的可靠性
  • 快，模型效率。推理速度能不能满足业务实时性要求，QPS 高的场景不能用太大的模型，显存占用也得适配硬件资源
  • 专，领域适配。是不是针对垂直领域做过预训练或微调，金融模型懂”PE 估值”是市盈率，通用模型可能理解成体育器材
  • 广，多语言支持。是否支持业务所需语言，跨语言对齐能力怎么样，中英混合文本能不能正确嵌入
  • 大，数据规模匹配。模型参数量和训练数据规模要匹配语料复杂度，小数据用大模型容易过拟合，大数据用小模型会出现语义坍缩
  • 活，开放性与生态。是否开源、社区是否活跃、能不能定制化微调，API 调用是否灵活
  • 省，成本。计算成本包括训练推理的硬件投入，使用成本包括第三方 API 的 token 费用和商用授权费

RAG索引流程中文档的解析方式

RAG工程中提示词工程的设计技巧与实践心得

简述Advanced RAG的核心内涵

Advanced RAG可以分为检索前优化、检索中优化、检索后优化

检索前优化：

  • 滑动窗口分块解决的是传统固定分块的问题。以前切文档要么 chunk 太大召回一堆无关内容，要么太小上下文断裂。滑动窗口的做法是设定一个窗口大小比如 500 字，步长比如 100 字，每次滑动切一块，相邻块之间有 400 字重叠。处理长篇法律合同这类文档效果特别好，条款之间的逻辑不会被切断。
  • 元数据过滤能大幅提升检索针对性。给每个文档打上时间、领域、来源、版本这些标签，查询时先用元数据做一轮过滤。比如企业知识库里有 2020 年和 2024 年的技术文档，用户问”最新方案”，直接按时间过滤掉旧文档，不让它们参与向量检索，召回质量立马上去。
  • 分层索引是大规模知识库的标配。一级索引按领域/类别分，二级索引按关键词/实体分，三级索引才是向量检索。用户查询先走粗粒度索引缩小范围到几千条，再走向量检索找最相关的几十条，比直接在百万级文档里做向量检索快 10 倍以上。
  • 查询重写让模型能理解用户真正想问什么。用户输入”那个电池技术咋回事”，重写模型输出”特斯拉 4680 电池技术原理”。常用的方案是接一个小参数的 LLM 做 query rewriter，成本低延迟小。
  • 查询扩展和重写不一样，它是在原查询基础上补充相关词。用户问”糖尿病治疗”，扩展成”糖尿病治疗 + 2024 最新疗法 + 药物副作用 + 并发症预防”，多路召回再合并去重，覆盖面更广。

检索中优化：

  • 混合检索是目前工业界最主流的方案，把 BM25 关键词检索和向量语义检索结合起来。BM25 擅长精确匹配专有名词、产品型号这类内容，向量检索擅长理解语义相似性。两路检索结果用 RRF 算法融合，取长补短。Elasticsearch 8.x 版本原生支持混合检索，Milvus 2.3 也加了 BM25 能力。
  • 动态嵌入根据用户画像、对话历史调整向量表示。电商场景里用户反复问笔记本电脑，动态嵌入会强化”性能””价格”这些维度；学术场景里同样的查询会强化”论文””实验”维度。实现方式一般是在 Embedding 模型输入时拼接 context 信息。
  • 递归块合并解决的是分块后上下文不完整的问题。检索到”药物治疗”这个 chunk 后，系统自动把它的父节点”疾病治疗方案”、兄弟节点”手术治疗””康复护理”也拉进来，形成完整的知识图谱式上下文。LlamaIndex 的 RecursiveRetriever 就是干这个的。

检索后优化：

  • Reranker 重排序是效果提升最明显的一环。初筛召回 100 条，用 Cross-Encoder 模型打分后取 Top-10 喂给 LLM。Cross-Encoder 比 Bi-Encoder 准但慢，所以只用在少量候选上。业界常用的模型有 Cohere Rerank、BGE-Reranker、bce-reranker-base 这些。
  • 提示压缩的必要性在于 LLM 上下文窗口有限，召回内容太长要么截断要么超 token 限制。压缩的做法是用小模型提取摘要，或者用 LLMLingua 这类工具做 token 级压缩，把 4000 token 的内容压到 1000 token，信息损失可控。
  • 内容过滤直接关系到回答的可靠性。金融场景过滤超过 1 年的市场分析、医疗场景过滤没有权威来源的内容、技术场景过滤已废弃的 API 文档。过滤规则可以是基于元数据的硬规则，也可以是基于模型的软规则。

简述Module RAG的核心定义

Modular RAG 就是把传统 RAG 系统拆成一堆松耦合、可重组的功能模块，每个模块各干各的事，由一个统一的编排器负责调度和路由，这样整体系统更灵活、可插拔、好维护。

优势：替换或升级单个组件不影响整体、模块化测试迭代效率高、方便接入新型检索或多模态能力

核心模块拆解：

  • Indexing 索引模块：对文档做分块优化，比如拆成小句、合并大段保留上下文，还会构建知识图谱，让知识存储更有序，检索起来更快
  • Pre-Retrieval 检索前处理：通过查询转换把口语化的提问转成精准指令，再做查询扩展补充相关关键词，让检索目标更清晰
  • Retrieval 检索模块：采用混合检索策略，向量搜索 + 关键词匹配一起上，可以从句子、文档块、结构化数据等不同粒度召回内容
  • Post-Retrieval 检索后处理：对召回结果做重排序，把最相关的内容筛出来，同时压缩掉冗余信息，提升输入质量
  • Generation 生成模块：用大模型生成回答，并通过外部知识验证准确性，避免幻觉

向量数据库的核心原理简述

向量数据库是专门用来存储和检索高维向量的数据库，核心能力是相似性搜索。把文本、图片、音频这些非结构化数据通过 embedding 模型转成多维向量，存进去之后可以根据语义相似度快速找出最相关的内容。

在大模型应用开发中，向量数据库主要解决三个核心问题：

  • 给大模型补上”长期记忆”。GPT-4 的上下文窗口最多 128K token，塞不下一个公司几万份文档。向量数据库可以把这些文档切片、embedding、存储，用户提问时先检索出最相关的 5-10 个片段，再喂给大模型生成答案，这就是 RAG 的核心链路。
  • 突破知识时效性的限制。大模型的知识截止到训练时间点，不知道昨天发布的新闻。向量数据库可以实时更新知识库，检索时拿到的永远是最新内容。
  • 降低推理成本。不用把所有背景知识都塞进 prompt 里，只检索最相关的内容，token 消耗能省一个数量级。10 万条文档全塞进去要几百万 token，检索后可能就 2000 token。

向量数据库中HNSW、LSH、PQ的含义

8. 什么是向量数据库？有没有做过向量数据库的对比选型？ | 小林面试笔记

  • HNSW

HNSW 全称 Hierarchical Navigable Small World，分层可导航小世界图。把所有向量组织成多层图结构，查询时从上层稀疏图贪心跳转，逐层下探到底层密集图，快速定位近似最邻近点。Milvus、Qdrant 默认都用这个

  • LSH

LSH 全称 Locality-Sensitive Hashing，局部敏感哈希。设计一组特殊的哈希函数，让相似向量大概率落入同一个桶。查询时只搜目标桶和相邻桶，检索范围能缩小到原来的千分之一。

  • PQ

PQ 全称 Product Quantization，乘积量化。把高维向量切成若干子块，每块用聚类中心的编号代替原始值。128 维向量拆成 8 段，每段 1 字节编码，存储空间直接压缩 64 倍。

技术 核心目的 适用场景 优势 代价
HNSW 高精度快速搜索 十亿级数据实时检索 精度高、速度快 内存占用高
LSH 极速粗筛 去重、过滤重复内容 速度极快 精度损失
PQ 压缩存储+加速计算 移动端、内存受限场景 内存大幅降低 轻微精度损失

RAG系统召回结果与用户query意图不匹配的改进方向

  • 问题改写
  • 多路召回
  • rerank
  • chunk切分
  • 上下文截断
  • prompt提示词约束

如何处理 RAG 检索不到相关文档的情况？

  • 诚实告知。当相似度最高的文档都低于阈值，说明知识库中确实没有相关信息。这时候应该明确告诉用户”抱歉，我在知识库中没有找到相关信息”。不要让模型凭空编造答案，这会导致幻觉问题。诚实虽然不够智能，但至少不会误导用户。
  • 查询改写重试。用户的问法可能不够准确或完整，导致检索失败。可以用 AI 改写查询，换个角度或补充信息后重新检索。比如用户问”它怎么用”，改写成”该产品的使用方法”，可能就能检索到了。通常可以尝试 1-2 次改写，避免无限重试。
  • 降低阈值扩大范围。如果设置阈值 0.7 没找到，可以降到 0.6 或 0.5 再试一次，可能能找到弱相关的文档。虽然不是完美匹配，但总比完全没有信息好。当然要在 Prompt 中说明”找到的可能只是部分相关的信息”。
  • 提供替代方案。告诉用户”没找到相关信息，但您可以尝试……”，给出一些建议的搜索词或相关主题。或者提供人工服务入口，让用户联系客服。这种主动引导比简单说”不知道”用户体验更好。

多知识库RAG中，查询效率与准确性的平衡及幻觉抑制方法

方案：先路由、再召回、后校验

  1. 统一嵌入模型，所有知识库必须用同一个向量模型生成 embedding，比如 bge-large-zh 或者 text-embedding-3-large。不同模型生成的向量语义空间不一样，混着用相似度计算直接失真。
  2. 知识库路由，用户 query 进来先判断属于哪个领域，动态选择 1-2 个相关的子知识库去查，不用全库扫一遍。我们用一个轻量级的意图分类模型做这事，准确率能到 95% 以上，漏判的情况兜底走全库召回。
  3. 分阶段召回，先粗召回拉出 top 20 候选，再用 rerank 模型精排。粗召回靠向量检索速度快，rerank 用 CrossEncoder 或者 bge-reranker 这类模型，准确率高但慢，只跑 20 条也能接受。
  4. 减少幻觉，生成前在 prompt 里加约束，明确告诉模型”只能基于提供的内容回答，不确定就说不知道”。生成后再跑一轮校验，检查答案里提到的实体是不是真的在知识库里出现过。

RAG系统幻觉的实用解决方法

  1. Prompt 约束：在系统提示词中明确要求”只基于提供的文档回答”、”如果文档中没有相关信息，明确说不知道，不要编造”、”必须能在文档中找到依据”。这些强约束能让模型更谨慎，遇到不确定的信息不会强行生成。
  2. 提高检索质量：如果检索到的文档本身就不相关或质量不高，模型也容易产生幻觉。通过优化检索策略、使用重排序、设置合理的相似度阈值，确保给模型的都是高质量参考资料。检索是源头，源头质量好，幻觉自然少。
  3. 要求标注来源：在 Prompt 中要求模型标明每条信息的出处，如”根据文档2，……”。这种要求会让模型更注重文档依据，不太敢随意发挥。而且标注来源方便人工核查，能快速发现幻觉内容。
  4. 降低 temperature 参数：temperature 控制生成的随机性，值越低输出越确定。对于 RAG 这种事实性任务，建议设置 temperature=0 或接近 0，让模型选择最可能的输出，减少创造性发挥。虽然可能显得机械，但准确性更重要。
  5. 验证机制：生成答案后，用另一个模型验证答案是否跟文档一致。或者设计规则检查，如答案中的数字、日期、人名是否在文档中出现。发现不一致的可以标记为”待核实”或重新生成。

RAG中信息来源标注与引用的实现方式

  • 元数据保存：在向量化文档时，要保存文档的来源信息。包括文件名、URL、页码、章节、作者、日期等。这些元数据跟向量一起存储，检索时会连同文档内容一起返回。
  • Prompt 引导：在构造 Prompt 时要明确要求模型标注来源。比如”请在使用文档信息时，用 [文档1] 这样的方式标注”或”请在答案末尾列出参考来源”。还要在 Prompt 中把文档编号或标题清楚地标出来，方便模型引用。
  • 前端展示：要把引用转换成用户友好的形式。可以在答案中高亮引用标记，点击后显示原文。可以在答案下方列出所有引用的文档，提供查看全文的链接。可以用脚注或气泡的方式展示引用。好的展示方式让用户方便核查又不影响阅读。

RAG中利用元数据过滤提升检索精度的方法

在RAG系统中，元数据过滤是提高检索精度的关键技术之一。通过合理利用文档的元数据信息，系统能够更精准地定位相关信息，从而提升最终生成内容的质量。

元数据的核心价值：

元数据过滤通过在语义搜索前或过程中加入结构化条件筛选，显著提升检索相关性：

  • 缩小搜索范围：预先排除明显不相关的文档
  • 提升上下文相关性：确保检索结果与查询场景高度匹配
  • 减少噪声干扰：过滤掉虽语义相似但上下文不符的内容
  • 增强领域特异性：针对专业领域问题检索专业文档

常见元数据分类

  1. 时间元数据
    • 应用：针对时效性问题（如”最新政策”）过滤旧文档
    • 示例：设置时间范围条件，仅检索最近6个月的文档
  2. 来源/权威性元数据
    • 应用：提高可信度（如”官方文件”、”学术论文”）
    • 示例：医疗咨询时优先检索医学期刊而非普通博客
  3. 主题/分类元数据
    • 应用：确保领域一致性
    • 示例：财务问题仅检索财务部门批准的文档
  4. 文档类型元数据
    • 应用：匹配特定格式需求
    • 示例：用户查询”操作手册”时优先检索手册类文档而非研究报告

RAG项目中Milvus、Pinecone、Chroma向量数据库的选型思路

  • Chroma 是最适合
    • 入门和小型项目的选择，轻量级的，可以嵌入式运行，不需要单独部署服务
    • 适合学习 RAG、做原型验证、个人项目。
    • 数据量在十万级以下用 Chroma 很合适。
    • 缺点是性能和扩展性有限，不适合生产环境的大规模应用。
  • Pinecone
    • 托管式云服务，开箱即用，不需要自己运维。
    • 性能好、稳定性高，支持分布式，能处理亿级数据。
    • 特别适合不想自己搭建基础设施的团队，或者初创公司想快速上线产品。
    • 缺点是付费的，而且数据存在第三方，有些企业可能不接受。
  • Milvus
    • 是开源的专业向量数据库，功能强大，支持分布式部署，能处理十亿级甚至更大规模的数据。
    • 适合对性能要求高、数据量大、需要私有化部署的项目。
    • 缺点是需要自己部署和运维，对技术团队有一定要求。