目录

1.什么是 RAG？RAG 的主要流程是什么？（易）    

2.什么是 RAG 中的 Rerank？具体需要怎么做？（中）    

3.什么混合检索？在基于大模型的应用开发中，混合检索主要解决什么问题？（中）

4.RAG 的完整流程是怎么样的？（易）

5.在 RAG 应用中为了优化检索精度，其中的数据清洗和预处理怎么做？（中）

6.什么查询扩展？为什么在 RAG 应用中需要查询扩展？（中）

7.什么自查询？为什么在 RAG 中需要自查询？（易）

8.什么提示压缩？为什么在 RAG 中需要提示压缩？    （易）

9.如何进行 RAG 调优后的效果评估？请给出真实应用场景中采用的效果评估标准与方法。（中）

10.什么是 RAG 中的分块？为什么需要分块？（易）

题目来源：AI大模型原理和应用面试题 - 面试鸭 - 程序员求职面试刷题神器 (mianshiya.com)

1.什么是 RAG？RAG 的主要流程是什么？（易）    

RAG（Retrieval-Augmented Generation）即 “检索增强生成”

它是一种将信息检索 系统与大语言模型 的生成能力相结合的技术框架。当用户提出一个问题时，RAG 不会让 LLM 凭空回答。而是先从外部知识库（如公司文档、数据库、网页等）中检索与问题最相关的信息片段，然后将这些检索到的信息 和用户的原始问题 一起打包，发送给 LLM，指令 LLM 基于这些提供的可靠信息来组织语言、生成答案。

主要流程：先检索后生成

拓展：

I.为什么需要RAG

主要是传统的LLM有以下几个问题：

  1. 幻觉问题：LLM 可能会生成看似合理但实际不正确或虚构的信息。

  2. 知识滞后：LLM 的训练数据有截止日期，无法获取和利用其训练之后的新知识。

  3. 缺乏溯源：传统 LLM 的回答像一个“黑箱”，我们很难知道其生成答案的具体依据来源。

  4. 专业/私有领域知识缺乏：通用的 LLM 对企业内部的私有文档、专业知识库了解有限。

II,通俗对比LLM

你可以把它想象成一个开卷考试：

  • 传统LLM（如基础版ChatGPT）：像是“闭卷考试”。模型只能凭借自己记忆（训练数据）中的知识来答题。如果问题超出其记忆范围，或者记忆有误，它就可能答错或“胡编乱造”（幻觉问题）。

  • RAG系统：像是“开卷考试”。当遇到一个问题时，它首先会去允许翻阅的“参考书”（即外部知识库）里找到最相关的段落和章节，然后仔细阅读这些找到的资料，最后组织语言写出答案。这样答案的准确性和可靠性大大提升。

2.什么是 RAG 中的 Rerank？具体需要怎么做？（中）    

Rerank（重排序） 是 RAG 流程中，对首次检索的候选文档进行再次排序的过程。

Rerank 通过一个更强大、更精细的模型对初步检索出的Top K个文档（例如100个）进行重新评估和打分，筛选出与问题最相关的Top N个文档（例如5个），再送给LLM生成答案。提升了最终上下文的质量。

步骤：初步检索、重排序、生成答案。

拓展：

I.通俗比喻

  • 初步向量检索就像用渔网捕鱼，一网下去能捞到很多鱼（文档），但里面可能夹杂着水草、贝壳（不相关或弱相关的文档）。

  • Rerank 就像手工挑选，把捞上来的鱼倒出来，精心挑选出最肥美、最符合要求的那几条，扔掉杂物。

  • 最后，大厨（LLM）只用这些精选的食材做出美味的菜肴（答案）。

II.具体步骤

具体实施 Rerank 通常分为以下几个步骤：

  1. 初步检索（First-Stage Retrieval）：使用高效的向量搜索引擎（如Chroma, FAISS）从海量知识库中快速召回一批（比如Top 100）可能与问题相关的候选文档。这一步追求召回率（Recall）。

  2. 执行重排序（Reranking）：使用一个专门的重排序模型对这100个候选文档逐一进行判别。该模型会计算每个文档与问题的“相关性得分”。

    • 常用模型：如bge-reranker, cohere-rerank 等。这些模型通常是交叉编码器，能更深度地理解问句和文档间的交互关系，但计算成本更高。

  3. 筛选与传递：根据重排序模型给出的相关性得分，对这100个文档进行降序排列，并只选取得分最高的Top N个（比如Top 5）文档作为最终上下文。

  4. 生成答案：将精选后的Top N个文档与原始问题组合成提示，发送给LLM生成最终答案。

3.什么是混合检索？在基于大模型的应用开发中，混合检索主要解决什么问题？（中）

混合检索是一种在RAG或其他搜索系统中进行检索时同时结合语义理解和关键词匹配的一种检索技术，为LLM提供更高质量、更全面的上下文。

主要解决单一检索方法的局限性和偏差问题。

拓展：

I.两种检索方法

  1. 稠密向量检索：基于嵌入模型，将查询和文档转换为向量，通过语义相似性进行匹配。擅长处理语义相关但用词不同的查询（例如：“如何给水果保鲜” 匹配 “香蕉的储存方法”）。

  2. 稀疏向量检索：基于词频（如TF-IDF、BM25），进行关键词匹配。擅长处理字面匹配、包含特定术语或专有名词的查询（例如：“iPhone 15 发布会” 必须精确匹配这些关键词）。

II.解决的问题

在基于大模型的应用开发中，混合检索主要为了解决单一检索方法的局限性：

 1）解决“语义相似”但“主题不相关”的问题（假阳性）

  • 问题：纯向量检索有时会返回语义相近但主题并不相关的文档。

  • 例子：用户查询是“苹果公司发布的新手机”。纯向量检索可能会返回一段关于“如何种植新品种的苹果”的文档，因为“苹果”这个词的语义向量很接近。

  • 混合检索的解决方式：BM25 组件会严格匹配“公司”、“发布”、“手机”等关键词，从而将那些虽然提到“苹果”但主题是水果的文档排名降低，而将同时包含这些关键词的科技类文档排名提高。两者结果融合后，更相关的文档会排在前面。

2）解决“用词不同”但“语义相关”的问题（假阴性）

  • 问题：纯关键词检索（BM25）无法处理查询和文档间用词不同的情况。

  • 例子：用户查询是“机动车燃油效率提升方法”。而知识库中的文档使用的是“提高汽车油耗表现”这样的表述。BM25 因为无法匹配“机动车”、“燃油效率”等关键词而找不到这篇最相关的文档。

  • 混合检索的解决方式：向量检索组件能够理解“机动车”和“汽车”、“燃油效率”和“油耗”在语义上是相似的，从而成功检索到该文档。

3）提升对专业术语、名称、ID等精确信息的检索能力

  • 问题：LLM 在处理代码、错误代码、产品型号、人名、法律条款编号等需要精确匹配的信息时，向量检索可能不够精确。

  • 例子：查询“错误代码 0x80070005 的解决方案”。向量检索可能会返回一堆关于“系统错误”、“权限问题”的泛泛之谈。而 BM25 会精确匹配“0x80070005”这个字符串，直接找到最准确的解决方案文档。

  • 混合检索的解决方式：BM25 确保精确匹配到含有关键代码的文档，而向量检索则从语义上补充一些相关的背景知识文档，两者结合万无一失。

4）提高检索结果的召回率和精度

  • 召回率：在所有真正相关的文档中，系统能检索到多少。

  • 精度：在系统检索到的所有文档中，真正相关的有多少。

  • 混合检索的解决方式：

    • 向量检索通常负责高召回率，它能够“广撒网”，捞回大量语义上可能相关的文档，避免遗漏。

    • 关键词检索通常负责高精度，它能够确保结果中包含最核心的关键词。

    • 将两者的结果融合，相当于既广撒网又精捕捞，从而在整体上实现比任何单一方法更高的召回率和精度。

4.RAG 的完整流程是怎么样的？（易）

1）数据预处理（加载 + 清洗 + 分块）

2）数据向量化存储 + 建立关键字索引

3）用户输入 + 初步检索 + 重排序

4）重新打包 Prompt + LLM生成

拓展：

I.具体流程：

阶段一：数据预处理与索引（离线工作）

这个阶段是为问答做准备的后台过程，旨在构建一个高效、结构化的知识库，通常只需执行一次或定期更新。

  1. 数据获取与加载

    • 来源：从各种数据源（如 PDF、Word、PPT、Markdown、HTML、数据库、API等）获取原始数据。

    • 工具：使用 LangChain、LlamaIndex 等框架的 Document Loaders。

  2. 数据清洗与标准化

    • 内容：去除无关内容（页眉、页脚、广告）、修复编码错误、标准化格式等。

    • 目的：提升后续处理步骤的数据质量。

  3. 文档分割

    • 过程：将长文档切割成更小的、语义上有意义的“块”。这是至关重要的一步，因为检索时我们通常不需要整篇文档，而是最相关的几个段落。

    • 策略：可以采用固定大小重叠分割、按标题等语义分割。重叠分割有助于保持上下文连贯性。

    • 工具：LangChain 的 Text Splitters。

  4. 向量化

    • 过程：使用嵌入模型 将文本块转换为高维向量的过程。这个过程也叫“Embedding”。向量是一个数字数组，可以表示文本的语义信息。语义相近的文本，其向量在空间中的距离也更近。

    • 模型选择：如 text-embedding-ada-002, BGE, M3E 等。

  5. 索引与存储

    • 过程：将这些文本向量及其对应的原始文本内容（元数据）存储到向量数据库中，并建立索引以便快速搜索。

    • 可选步骤：同时为文本块创建关键词索引（如 BM25），为后续的混合检索做准备。

    • 数据库选择：Chroma, Pinecone, Weaviate, Qdrant, Milvus, Elasticsearch 等。

阶段二：查询执行（在线工作）

这是用户每次提问时都会触发的实时过程。

  1. 查询输入：用户提出一个问题。

  2. 查询理解与扩展（高级优化步骤）

    • 过程：对原始查询进行优化，以提升检索质量。

    • 技术：

      • 查询重写：纠正拼写错误、简化表达。

      • 查询扩展：利用LLM生成同义词或相关问题（例如，将“苹果手机”扩展为“iPhone”、“Apple”），增加检索到相关文档的概率。

      • HyDE：让LLM根据问题生成一个假设性的答案，然后用这个答案去检索，有时能更好地捕捉语义。

  3. 检索

    • 初步检索：

      • 向量检索：将优化后的查询转换为向量，在向量数据库中搜索最相似的文本块。

      • 混合检索：同时进行向量检索和关键词检索（如 BM25），然后将两者的结果融合（例如使用RRF算法）。这结合了语义理解和关键词匹配的优势，是生产系统的标配。

    • 后处理：

      • 重排序：使用一个专门的、更精细的重排序模型对初步检索到的Top-N个候选文档进行重新评分和排序。这一步能有效解决“语义相似但主题不相关”的问题，筛选出真正最相关的少量文档（如 Top-3 或 Top-5）。

      • 元数据过滤：在检索时或检索后，根据作者、日期、来源等元数据对结果进行过滤。

  4. 提示工程与生成

    • 构造提示：将检索到的上下文、用户的原始问题 以及系统指令组合成一个新的、内容更丰富的提示（Prompt），输入给LLM。这是一个经典的模板：

      “你是一个有帮助的AI助手。请严格根据以下背景信息回答问题。如果信息不足，请直接说不知道。
      背景信息：{re-ranked_documents}
      问题：{user_question}
      答案：”

    • LLM 生成答案：LLM 根据这个包含了可靠上下文的提示词，生成最终答案并返回给用户。

  5. 评估与反馈（持续优化环节）

    • 过程：通过人工评估或自动评估（如 faithfulness, relevance）来监控RAG系统的表现。

    • 应用：收集反馈数据（如点击率、大拇指评价），用于持续迭代和优化模型、分割策略、检索策略等各个环节。这是一个闭环系统。

5.在 RAG 应用中为了优化检索精度，其中的数据清洗和预处理怎么做？（中）

数据清洗和预处理本质是将原始杂乱数据转化为高质量、结构清晰、易于检索的文本块（Chunks），以便嵌入模型能为其生成高质量的向量表示，从而在检索时能最精准地匹配用户查询。

1）文本提取

2）数据去噪和清理

3）转化为标准化格式

4）分块

5）元数据提取

拓展：

I.具体流程

具体做法分为两个阶段：

  1. 数据清洗：提升文本质量

    • 去噪与清理：移除无关内容，如 HTML/XML 标签、页眉页脚、水印、特殊乱码字符等。

    • 格式标准化：将不同格式（PDF, PPT, Word, 网页）的文本提取并转换为纯文本，确保编码统一（如 UTF-8）。

    • 纠正错误：使用拼写检查工具或模型纠正 OCR 识别或原文中的错误文本。

    • 处理冗余：识别并合并或删除重复的段落和文档。

  2. 数据预处理：优化检索结构

    • 智能分块：这是最关键的一步。根据文档类型选择合适的 chunking 策略：

      • 基于规则：按固定大小（如 512 tokens）重叠分块，简单但可能割裂语义。

      • 基于语义：使用文本分割模型，按自然边界（如标题、段落、句号）进行分块，更好保持语义完整性。

    • 添加元数据：为每个文本块注入丰富的描述信息，如来源文件、标题、章节、创建日期、作者等。这为后续实现元数据过滤提供可能，能极大缩小检索范围、提升精度（例如，只检索“2023年Q3财报”PDF中的内容）。

    • 为特定优化：根据领域需求，可以保留重要表格、图注，或甚至为图像生成描述性文本（Alt Text）以供检索。

6.什么是查询扩展？为什么在 RAG 应用中需要查询扩展？（中）

查询扩展是一种信息检索的优化技术，其核心思想是：在将用户查询发送到检索系统之前，对其进行改写和增强。

在 RAG 应用中需要查询扩展，主要是为了解决原始用户查询的“表述问题”与向量检索的“匹配机制”之间的矛盾。如词汇匹配、语义补全。

拓展：

I.关于查询扩展

查询扩展 是一种信息检索技术，其核心思想是：在原始查询的基础上，自动添加相关的单词、短语或甚至生成新的查询语句，以创建一个信息更丰富、更可能匹配到相关文档的增强版查询。

简单来说，就是当用户输入一个简短或模糊的问题时，系统会“替用户多想一步”，把这个问题的各种可能表述方式都考虑到，然后用这个“增强版”的问题去知识库里搜索。

举个例子：

  • 原始用户查询：“苹果手机多少钱？”

  • 扩展后的查询：“iPhone 价格 最新款 Apple iPhone 售价 多少钱”

II.为什么在 RAG 应用中需要查询扩展？

1）解决“词汇鸿沟”问题

  • 问题：用户提问用的词和知识库文档里用的词可能不一样，但表达的是同一个意思。

  • 例子：用户问 “如何提高电脑运行速度？”，而知识库中的文档写的是 “优化计算机性能的十大技巧”。单纯依靠关键词匹配或语义相似度，可能无法建立强关联。

  • 查询扩展的解决方式：将查询扩展为 “提高 电脑 运行速度 优化 计算机 性能 提升 加速”，这样就能成功匹配到包含“优化”、“计算机”、“性能”等关键词的文档。

2）增强语义理解，提高召回率

  • 问题：用户的查询可能非常简短、模糊或缺乏上下文，导致检索模型无法充分理解其深层意图，从而返回不相关或不全面的结果。

  • 例子：用户查询 “特斯拉”。他的意图是什么？是想买特斯拉股票？了解特斯拉汽车？还是查询特斯拉这家公司的发展历史？简短查询的意图是模糊的。

  • 查询扩展的解决方式：通过扩展，可以生成多个不同意图的查询：

    • “特斯拉 股票价格 TSLA”

    • “特斯拉 电动汽车 型号”

    • “特斯拉 公司 历史”

    • 系统可以并行执行这些查询，并将所有结果合并，最终为用户提供一个更全面的答案，覆盖用户的潜在意图。

3）处理复杂、多意图查询

  • 问题：一个查询中可能包含多个子问题。

  • 例子：“比较一下Python和Java在数据处理方面的优缺点”。

  • 查询扩展的解决方式：可以将这个复杂查询分解或扩展为多个子查询：

    • “Python 数据处理 优点 缺点”

    • “Java 数据处理 优点 缺点”

    • “Python Java 数据处理 对比 差异”

    • 分别检索这些子查询，然后让LLM综合所有信息生成一个完整的比较性答案。

4）纠正拼写错误和表述不规范

  • 问题：用户输入可能存在拼写错误或使用非正式的表达。

  • 例子：用户输入 “如何解决程序报错：NullPointerException？”，但拼写错了，写成 “NullPointerExcepion”。

  • 查询扩展的解决方式：通过LLM或拼写检查，可以识别并纠正这个错误，用正确的术语 “NullPointerException” 进行检索，避免搜索失败。

7.什么是自查询？为什么在 RAG 中需要自查询？（易）

自查询是一种高级的检索优化技术。它通过LLM智能解析用户意图，将自然语言问题自动转换为包含语义查询和元数据过滤器的结构化指令，从而释放向量数据库的筛选能力，从海量知识中高效锁定最相关、最准确的信息片段。

在 RAG 中需要自查询，是因为用户的自然语言提问中，常常混合了语义意图和具体的过滤条件。

拓展：

I.关于自查询

输入：苹果公司2023年发布的新手机有什么亮眼功能？

1）语义解析：苹果公司新手机的亮眼功能

2）元数据过滤：{ "company": "苹果", "date": "2023", "product_type": "手机" }

II.为什么需要自查询

  1. 解锁元数据过滤的强大功能：向量数据库不仅存储向量，还存储每个文本块的元数据（如创建日期、作者、部门、版本号等）。用户的问题中常常隐含了这些过滤条件（例如：“微软2023年的财报”），但普通的语义搜索无法直接利用这些关键词进行精准筛选。自查询可以自动识别出“2023年”并将其作为一个过滤器，极大地缩小检索范围，提升精度和效率。

  2. 实现更精准的查询意图理解：它能够区分用户问题中哪些部分是需要语义匹配的，哪些部分是需要精确匹配的。例如，对于问题“总结一下市场部编写的关于电动汽车的文档”，自查询会将“关于电动汽车”解析为语义查询（query_vector），而将“市场部编写的”解析为元数据过滤器（filter: {department: "市场部"}），从而实现精准检索。

  3. 避免“语义污染”：如果不进行自查询，整个句子都会被拿去进行语义搜索，可能导致检索结果偏离核心筛选条件。自查询确保了硬性条件被优先、精确地满足

III.查询扩展与自查询

特性 查询扩展 自查询
核心目的 提高召回率，避免遗漏 提高精确率，精准筛选
工作原理 扩展查询内容，增加搜索关键词 解析查询内容，拆解为搜索项和过滤项
处理对象 查询的语义内容本身 查询中隐含的元数据条件
输出结果 一个更丰富、 synonym 更多的新查询字符串 一个结构化查询：
1. 一个语义查询字符串
2. 一个元数据过滤表达式
好比 把网撒得更大一些 不仅在撒网，还在想要的区域撒，不想要的鱼直接不要
解决的问题 词汇鸿沟：说法不同，意思相同 意图混合：一个问题里既包含了“找什么”，也包含了“在哪找”

协同工作：

让我们通过一个例子来理解这个工作流：

  1. 用户输入：“苹果公司2023年发布的新手机有什么亮眼功能？”

  2. 自查询首先工作：

    • 解析出语义核心：“苹果公司新手机的亮眼功能”

    • 解析出过滤条件：{ "company": "苹果", "date": "2023", "product_type": "手机" }

  3. 查询扩展接着工作：

    • 对语义核心 “苹果公司新手机的亮眼功能” 进行扩展。

    • 生成扩展查询：“苹果 苹果公司 iPhone 新款手机 亮点功能 创新特性 新功能”

  4. 执行检索：

    • 使用 元数据过滤器 { "company": "苹果", "date": "2023", "product_type": "手机" } 在知识库中先筛选出所有2023年苹果手机的文档。

    • 在这个已经缩小了的、精准的范围内，使用扩展后的查询 “苹果 苹果公司 iPhone...” 进行向量相似度搜索。

  5. 最终结果：你得到的结果既是高度相关的（因为经过了查询扩展），又是严格精准的（因为经过了自查询过滤），完美契合用户问题。

8.什么是提示压缩？为什么在 RAG 中需要提示压缩？（易）

提示压缩是一种 Prompt 优化技术，旨在减少发送给大语言模型的提示内容体积，同时尽可能保留其核心信息和上下文。

在 RAG 中需要提示压缩是为了：降低计算成本和延迟的同时，有效减少了模型受到的噪声干扰。

拓展：

I.关于提示压缩

在RAG中，检索到的上下文（多个文档片段）可能与用户查询一起构成一个很长的提示。提示压缩会分析这些上下文，识别并移除冗余、无关或低相关性的信息，只保留对回答当前查询最关键的内容，形成一个更精简、更集中的提示。

一个简单的比喻：

  • 未压缩的 RAG 提示：就像让 LLM 阅读一本厚厚的书（检索到的所有文档），然后回答一个关于其中某一页内容的问题。

  • 压缩后的 RAG 提示：就像你先把这本书的核心观点、与问题相关的关键段落和论据提取出来，做成一份简洁的摘要或报告，然后让 LLM 基于这份报告来回答问题。

II.为什么在 RAG 中需要提示压缩？

在 RAG 中需要提示压缩，主要是为了解决 “长上下文” 所带来的核心挑战：

  1. 突破模型上下文窗口限制：LLM的上下文长度是有限的。当检索到的文档非常多或非常长时，可能会超出模型的令牌限制，导致无法处理。压缩可以确保所有关键信息都能被放入上下文窗口中。

  2. 降低计算成本与延迟：处理更短的提示意味着更少的计算量（Token消耗），从而能显著降低API成本并加快模型响应速度，这对生产环境至关重要。

  3. 减少噪声干扰，提升答案质量：并非所有检索到的内容都同样相关。大量无关信息（噪声）会分散模型的注意力，可能导致它关注到次要细节而忽略核心答案，甚至产生幻觉。压缩通过聚焦关键信息，直接提升了生成答案的准确性和相关性。

  4. 避免“中间迷失”：对于超长上下文，模型有时难以有效利用位于提示中间位置的信息。压缩通过去除冗余，确保了最重要的信息处于更突出的位置。

9.如何进行 RAG 调优后的效果评估？请给出真实应用场景中采用的效果评估标准与方法。（中）

从三个方面评估：检索质量、生成质量、系统性能

评估方法：构建基准测试集、自动化评估、人工评估

每次对 RAG 的某个组件（如 embedding 模型、分块策略、重排序器、提示词）进行调优后，都在同一个基准测试集上运行评估，对比调优前后的指标变化，用数据驱动决策。

拓展：

I.评估标准

  1. 检索质量：检索到的上下文是否相关？

    • 命中率：在所有问题中，Top K 个检索结果中包含能正确回答问题文档的比例。

    • 平均排名：正确答案在检索结果列表中的平均位置（排名越靠前越好）。

    • 归一化折损累计增益：这是一个更复杂的指标，同时考虑检索结果的相关性等级和其排名位置。

  2. 生成质量：最终的答案是否优秀？

    • 忠实度：答案是否严格基于提供的上下文？这是评估幻觉的核心指标。答案中任何无法从上下文中推断出的声明都算作错误。

    • 答案相关性：答案是否直接回答了问题？是否避免了冗余或无关信息。

    • 正确性：在忠实的基础上，答案中的事实、数据是否准确。

    • 流畅性：答案是否自然、通顺、符合人类语言习惯。

  3. 整体系统效能

    • 延迟：从用户提问到收到完整回答所需的时间。

    • 成本：每次查询的平均处理成本（Token 消耗、API 调用费用）

    • 吞吐量：系统每秒能处理的查询数量。关乎系统扩展性。

II.评估方法

  1. 构建基准测试集：

    • 这是评估的基石。需要手动构建一个包含 (问题， 标准答案， 上下文来源) 的三元组测试集。问题应覆盖核心业务场景，包括简单查询、复杂多跳推理、关键字查询、语义查询等。

  2. 自动化评估：

    • 使用 LLM 作为裁判：当前最主流的方法。使用一个强大的 LLM（如 GPT-4）作为裁判，根据上述标准，对测试集中每个问题的“系统生成答案”进行评分。可以设计提示词让 LLM 为忠实度、相关性等指标输出 1-5 分的评分或 True/False 判断。

    • 传统指标计算：对于检索质量，可以使用代码自动计算命中率、NDCG 等指标。

  3. 人工评估：

    • 自动化评估并非完美。最终必须由领域专家对关键样本进行人工评估，尤其是对“正确性”和“流畅性”进行最终裁定。人工评估结果是校准自动化评估的黄金标准。

III.真实工作流程

每次对 RAG 的某个组件（如 embedding 模型、分块策略、重排序器、提示词）进行调优后，都在同一个基准测试集上运行评估，对比调优前后的指标变化，用数据驱动决策。

假设你为一家公司搭建了一个内部知识库 RAG 系统。

  1. 构建测试集：

    • 从客服日志中收集 200 个高频问题。

    • 让产品专家为每个问题撰写标准答案，并从公司文档中找出最相关的 1-3 个段落标记为 ground_truth_contexts。

  2. 建立基线：

    • 使用初始系统（如 Naive RAG：简单分块 + 向量检索 + 简单提示）在测试集上跑一遍。

    • 使用 LLM-as-a-Judge 计算当前系统的答案正确性（平均分）和检索命中率@5。

  3. 实施优化 & 评估：

    • 假设：你怀疑检索效果不好，于是优化了分块策略（从固定大小改为按标题分块）。

    • 评估：

      • 只评估检索器：在测试集上运行新的检索器，计算 Hit Rate@5 和 nDCG@5，与基线对比。如果指标显著提升，证明优化有效。

      • 端到端评估：运行整个新系统，再次用 LLM 裁判评估答案正确性。如果正确性也提升，说明检索优化成功传导到了最终答案。

  4. 持续监控：

    • 系统上线后，部署监控面板，跟踪：

      • 业务指标：用户满意度反馈按钮的点击情况。

      • 性能指标：API 延迟和错误率。

      • 成本指标：平均每次请求的 Token 消耗和费用。

通过这个“构建基准 -> 建立基线 -> 分模块评估优化 -> 端到端验证 -> 线上监控”的循环，你可以科学地、数据驱动地对 RAG 系统进行迭代调优，确保每一次改动都带来可衡量的提升。

10.什么是 RAG 中的分块？为什么需要分块？（易）

分块，也称为文本分割，是 RAG 流程中数据预处理阶段的一个核心步骤。它的目的是跟据语义结构将冗长的原始文档（如PDF、Word、HTML等）切割成更小、更易于管理的片段或“块”。

为什么需要分块：

1）适配模型的上下文窗口限制

2）提升检索精度与召回率

3）减少噪声干扰，提高答案质量

拓展：

I.关于分块

可以把它想象成：你无法把一整本书直接塞给一个忙碌的专家让他快速回答问题。更有效的方法是，先把书分成不同的章节和段落，然后只把与问题最相关的那些段落拿给他看。

在技术实现上，分块通常会设定一个大小限制（例如 200 个字符、500 个 token），并可能允许块与块之间有部分重叠，以保持上下文的连贯性。

II.为什么需要分块

在 RAG 中需要分块，主要是为了解决以下三个核心问题：

  1. 适配模型的上下文窗口限制：大语言模型的上下文长度是有限的。无法将一整本书或一份长报告作为上下文一次性输入给模型。分块将大数据切分成模型可以“消化”的小块。

  2. 提升检索精度与召回率：

    • 精度：小而专注的文本块能让向量搜索更精准地定位到包含答案的具体段落，而不是返回一整篇可能只有少量相关内容的冗长文档。

    • 召回率：将知识分解为多个块，增加了不同角度的问题能成功检索到相关信息片段的概率。

  3. 减少噪声干扰，提高答案质量：冗长的上下文包含大量与问题无关的信息（噪声），这会干扰模型，导致其分心或产生幻觉。提供高度相关的小文本块，能为模型生成准确、专注的答案提供最干净的上下文。

III.常见的分块策略

策略 如何工作 优点 缺点
固定大小分块 像滑动窗口一样，按固定的字符数或 token 数进行分割，并可以设置重叠区域。 简单、高效、可预测。 可能鲁莽地切断句子和段落，破坏语义完整性。
递归分块 尝试按一组分隔符（如 \n\n, \n, ., !, ?, ）递归地分割文本，直到块大小达到要求。 比固定大小分块能更好地保持句子的完整性。 仍然可能忽略文本的语义结构。
基于标记的分块 使用 NLP 库（如 SpaCy）按句子进行分割，然后将相邻句子组合成块。 能很好地处理语言结构。 计算成本稍高。
语义分块 使用嵌入模型计算句子或段落间的相似度，在语义发生较大转变的地方进行分割。 高级策略。能产生语义高度一致的块。 实现最复杂，计算成本最高。
基于结构的分块 利用文档的固有结构，如 按标题/小节（Markdown 的 #， ##）、按段落、按列表进行分割。 最佳实践之一。非常贴合人类组织信息的方式，检索精度高。 需要文档有清晰的结构。

本文到此结束，如果对你有帮助，可以点个赞~

后续会在合集里持续更新 RAG 等 AI 相关的面试题，欢迎关注~

祝各位都能拿到满意的offer~

# 面试 # java
Logo
武汉城市开发者社区

为武汉地区的开发者提供学习、交流和合作的平台。社区聚集了众多技术爱好者和专业人士，涵盖了多个领域，包括人工智能、大数据、云计算、区块链等。社区定期举办技术分享、培训和活动，为开发者提供更多的学习和交流机会。

更多推荐

cover

吴亚洲：企业AI落地的关键——从幻觉走向可靠的工业级 AI标准

avatar 武汉城市开发者社区
cover

高通骁龙8精英版第五代发布，游戏与AI性能大幅升级

avatar 武汉城市开发者社区

超越单边控制：介绍新一代对话智能体评测基准τ2-Bench

τ2-Bench 是一个用于评估对话智能体在双边控制环境下表现的系统。用户和 AI 智能体都可以调用工具，共同操作一个共享的动态环境。这种设定更贴近现实中的协作场景，例如技术故障排除、远程指导等，其中用户也具备执行动作的能力。τ2-Bench不仅是T-Bench 的自然延伸，更是对话智能体评测从“单边控制”迈向“双边协作”的重要一步。它为我们提供了一个更加真实、可控、可诊断的测试平台，助力构建真正

avatar 武汉城市开发者社区