RAG商业化缺陷

文本向量化构建索引的过程-Index Process

• MIssing Content(内容缺失): 原本的文本中就没有问题的答案
• 文档加载准确性和效率： 比如pdf文件的加载，如何提取其中的有用文字信息和图片信息等
• 文档切分的粒度： 文本切分的大小和位置会影响后面检索出来的上下文完整性和与大模型交互的token数量，怎么控制好文档切分的度，是个难题。

检索增强回答的过程中-Query Process

• Missed Top Ranked: 错过排名靠前的文档
• Not in Context: 提取上下文与答案无关
• Wrong Format(格式错误): 例如需要Json，给了字符串
• Incomplete(答案不完整): 答案只回答了问题的一部分
• Not Extracted(未提取到答案:) 提取的上下文中有答案，但大模型没有提取出来
• Incorrect Specificity: 答案不够具体或过于具体

内容缺失

• 增加相应知识库：将相应的知识文本加入到向量知识库中。
• 数据清洗与增强：输入垃圾，那也必定输出垃圾。任何RAG工作流程想要获得优良表现，都必须先清洁数据。
• 更好的Prompt设计：通过Prompts，比如让大模型在找不到答案的情况下，输出“根据当前知识库，无法回答该问题”等提示。

文档加载准确性和效率

• 优化文档读取器：一般知识库中的文档格式都不尽相同，针对每一类文档，涉及一个专门的读取器。
• 数据清洗与增强

文档切分的粒度

• 内容重叠分块：为了保持文本块之间语义上下文的连贯性，在分块时，保持文本块之间有一定的内容重叠。
• 基于结构的分块：基于结构的分块方法利用文档的固有结构，如HTML或Markdown中的标题和段落，以保持内容的逻辑性和完整性。
• 基于递归的分块：重复的利用分块规则不断细分文本块。比如先通过段落换行符（\n\n）进行分割。然后，检查这些块的大小。如果大小不超过一定阈值，则该块被保留。对于大小超过标准的块，使用单换行符（\n）再次分割。以此类推，不断根据块大小更新更小的分块规则（如空格，句号）。
• 分块大小的选择：
  • 不同的嵌入模型有其最佳输入大小。比如Openai的text-embedding-ada-002的模型在256 或 512大小的块上效果更好。
  • 文档的类型和用户查询的长度及复杂性也是决定分块大小的重要因素。

错过排名靠前的文档

外挂知识库中存在回答问题所需的知识，但是可能这个知识块与问题的向量相似度排名并不是靠前的，导致无法召回该知识块传给大模型，导致大模型始终无法得到正确的答案。

• 增加召回数量：增加召回的 topK 数量，也就是说，例如原来召回前3个知识块，修改为召回前5个知识块。不过此种方法，因为知识块多了，不光会增加token消耗，也会增加大模型回答问题的干扰。
• 重排（Reranking）

其它缺陷

• 提取上下文与答案无关: 内容缺失 或 错过排名靠前的文档 的具体体现
• 格式错误
  • Prompt调优优化Prompt逐渐让大模型返回正确的格式。
  • 进行结果格式验证，例如使用LangChain中的PydanticOutputParser类来校验输出格式。
  • Auto-Fixing自修复：对不符合要求的格式进行自动修复
• 答案不完整: 将问题分开提问一方面引导用户精简问题，一次只提问一个问题。 另一方面，针对用户的问题进行内部拆分处理，拆分成数个子问题，等子问题答案都找到后，再总结起来回复给用户
• 未提取到答案: 提示压缩技术
• 答案太具体或太笼统:提示词改善或者提升基座大模型能力

解决方案-Advanced RAG

RAG概述

Advanced RAG重点聚焦在检索增强，即优化Retrieval阶段。增加了Pre-Retrieval预检索和Post-Retrieval后检索阶段，同时对检索本身也有优化。

• 预检索过程优化/检索前优化
  • 高级RAG着重优化了索引结构和查询的方式。优化索引旨在提高被索引内容的质量，包括增强数据颗粒度、优化索引结构、添加元数据、对齐优化等策略。查询优化的目标则是明确用户的原始问题，使其更适合检索任务，使用了查询重写、查询转换、查询扩展等技术。
• 检索优化
  • 检索阶段的目标是确定最相关的上下文。通常，检索基于向量搜索，它计算查询与索引数据之间的语义相似性。因此，大多数检索优化技术都围绕嵌入模型展开，比如微调嵌入模型，将嵌入模型定制为特定领域的上下文，特别是对于术语不断演化或罕见的领域。
• 还有其他检索技术，例如混合搜索，通常是指将向量搜索与基于关键字的搜索相结合的概念。

后检索过程优化/检索后优化

• 对于由问题检索得到的一系列上下文，后检索策略关注如何优化它们与查询问题的集成。
• 这一过程主要包括重新排序和压缩上下文。重新排列检索到的信息，将最相关的内容予以定位标记，这种策略已经在LlamaIndex2、LangChain等框架中得以实施。
• 有时直接将所有相关文档输入到大型语言模型（LLMs）可能导致信息过载，为了缓解这一点，后检索工作集中选择必要的信息，强调关键部分，并限制了了相应的上下文长度。

3. RAG优化

3.1. Pre-Retrieval预检索优化

3.1.1. 摘要索引

在处理大量文档时，如何快速准确地找到所需信息是一个常见挑战。摘要索引可以用来处理半结构化数据，比如许多文档包含多种内容类型，包括文本和表格。这种半结构化数据对于传统 RAG 来说可能具有挑战性，文本拆分可能会分解表，从而损坏检索中的数据；嵌入表可能会给语义相似性搜索带来挑战。

• 解决方案

1. 让LLM为每个块生成summary，并作为embedding存到summary database中
2. 在检索时，通过summary database找到最相关的summary，再回溯到原始文档中去
3. 将原始文本块作为上下文发送给LLM以获取答案

3.1.2. 父子索引

• 我们在利用大模型进行文档检索的时候，常常会有相互矛盾的需求，比如：

  1. 你可能希望得到较小的文档块，以便它们Embedding以后能够最准确地反映出文档的含义，如果文档块太大，Embedding就失去了意义。
  2. 你可能希望得到较大的文档块以保留较多的内容，然后将它们发送给LLM以便得到全面且正确的答案。

• 解决方案

文档被分割成一个层级化的块结构，随后用最小的叶子块进行索引

1.在检索过程中检索出top k个叶子块
2.如果存在n个叶子块都指向同一个更大的父块，那么我们就用这个父块来替换这些子块，并将其送入大模型用于生成答案。

3.1.3. 假设性问题索引

假设性问题是一种提问方式，它基于一个或多个假设的情况或前提来提出问题。在对知识库中文档内容进行切片时，是可以以该切片为假设条件，利用LLM预先设置几个候选的相关性问题的，也就是说，这几个候选的相关性问题是和切片的内容强相关的。

1.让LLM为每个块生成3个假设性问题，并将这些问题以向量形式嵌
2.在运行时，针对这个问题向量的索引进行查询搜索（用问题向量替换文档的块向量）
3.检索后将原始文本块作为上下文发送给LLM以获取答案

3.1.4. 元数据索引

在企业复杂的知识密集型应用中，可能会面临几百个不同来源与类型的知识文档。如果只是简单地依赖传统的文本分割与 top-k 检索，就会产生精度不足、知识相互干扰等问题，从而导致效果不佳。想象一下，你想在一个医学文献数据库中查找关于“糖尿病足”的资料，但数据库中也充斥着大量关于其他糖尿病并发症的信息。

一个重要的优化方法是在大文档集下“分层”过滤与检索。比如元数据索引

元数据是对文档的一种属性描述，假设我们使用一个存储了大量科技博客文章的向量数据库。每篇文章都关联了以下标签：
topic: 人工智能, 区块链, 云计算, 大数据  
author: 作者A, 作者B, 作者C  
year: 2022, 2023, 2024

• 基本思路(LangChain 中使用SelfQueryRetriever自查询检索器实现)

1.定义元数据标签，如果文档本身没有，可以利用大模型推理出输入问题的元数据
2.通过标签先对文档进行过滤
3.结合向量检索进一步定位到最相关的前 K 个知识块

3.1.5. 各索引适用场景

3.2. 查询优化

3.2.1. Enrich完善问题

我们希望实现让人们通过自然的口语对话来使用大模型应用。然而，在口语表达需求和意图时，人们往往会遇到一些问题。例如，表达过于简略或含糊，容易引发语义歧义，导致大模型产生误解；用户的问题可能包含许多隐含要素，但表达的信息却不足，只能通过多轮对话逐步补全；

理想情况：通过大模型多次主动与用户沟通，不断收集信息，完善对用户真实意图的理解，补全执行用户需求所需的各项参数

3.2.2. Multi-Query 多路召回

当用户没有正确书写查询语句，或者LLM不能够正确理解用户查询语句的含义时，此时LLM生成的答案可能就不够完整和全面。

当用户输入查询语句(自然语言)时，
我们让大模型(LLM)基于用户的问题再生成多个查询语句，这些生成的查询语句是对用户查询语句的补充，它们是从不同的视角来补充用户的查询语句，
然后每条查询语句都会从向量数据库中检索到一批相关文档，
最后所有的相关文档都会被喂给LLM，这样LLM就会生成比较完整和全面的答案。
这样就可以避免因为查询语句的差异而导致结果不正确

• 利用 LLM 生成 N 个与原始查询相关的问题
• 将所有问题（加上原始查询）发送给检索系统。
• 通过这种方法，可以从向量库中检索到更多文档。

3.2.3. Decomposition 问题分解

如果用户的问题很复杂，大模型需要推理分解多个步骤才能完成，但是大模型不具备推理能力怎么办？

• 可以用提示词工程中的CoT策略，把用户的问题拆成一个一个小问题来理解接下来可以使用并行与串行两个策略来执行子任务。
• 并行执行是将每个子任务抛出去获得一个答案，然后再让大模型把所有子任务的答案汇总起来。
• 串行是依次执行子任务，然后将前一个任务生成的答案作为后一个任务的提示词的一部分。

3.2.4. 总览

查询优化：查询优化的目标是提升用户意图理解的准确性，包括：

• Enrich完善问题：通过大模型引导完善用户问题，产生一个更利于系统理解的完善后的用户问题。
• 多路召回（Multi-Query）针对用户问题生成多个相关问题，分别检索后汇总结果。
• 问题分解（Decomposition）将复杂问题拆分为多个子问题，依次或同步解决所有子问题从而获取最终答案。

3.3. 混合检索

3.3.1. 混合检索的核心价值：取长补短，动态适配混合检索

• 本质是根据数据特性、查询需求和场景约束，动态组合多种检索技术：
• 向量检索擅长捕捉语义相似性，但可能受限于向量空间的表示能力；
• 关键词 / 全文检索适合精确匹配，但对自然语言表达不友好；
• SQL检索利用数据库，却难以应对非结构化文本。

3.3.2. 适用场景

• 异构数据场景：处理多类型、多格式数据
• 复杂查询场景：兼顾精确匹配与语义理解
• 动态知识与实时性需求：融合静态知识与实时数据
• 高准确率与召回率要求：医疗、法律等关键领域

3.4. Post-Retrieval后检索

与检索前处理相对应，这是在完成检索后对检索出的相关知识块做必要补充处理的阶段。比如，对检索的结果借助更专业的排序模型与算法进行重排序或者过滤掉一些不符合条件的知识块等，使得最需要、最合规的知识块处于上下文的最前端，这有助于提高大模型的输出质量。

• 重排序:可以使用模型或者算法进行
• RAG-Fusion
• 上下文压缩和过滤

在多个查询检索后，会检索到大量的上下文，但并非所有上下文都与问题相关，有的不相关文档可能出现在文档前面，影响答案生成的准确性

3.4.1. RAG-Fusion

RAG-Fusion 是一种搜索方法，通过使用多重查询生成和互惠排名融合（Reciprocal Rank Fusion）对搜索结果进行重新排序。在Multi Query的基础上，对其检索结果进行重新排序(即reranking)后输出Top K个最相关文档，最后将这top k个文档喂给LLM并生成最终的答案

3.4.2. 上下文压缩和过滤

我们划分文档块的时候，通常不知道用户的查询，这意味着，与查询最相关的信息可能隐藏在一个包含大量不相关文本的文档中，这样输入给LLM，可能会导致更昂贵的LLM调用和较差的响应。

• 使用给定查询的上下文来压缩它们，以便只返回相关信息，而不是立即按原样返回检索到的文档

4. RAG应用评估

当我们准备将一个基于大模型的 RAG 应用投入生产时，有一些问题是需要提前考虑与应对的：

• 大模型输出的不确定性会带来一定的不可预知性。一个 RAG 应用在投入生产之前需要科学的测试以衡量这种不可预知性。
• 在大模型应用上线后的持续维护中，需要科学、快速、可复用的手段来衡量其改进效果，比如回答的置信度是上升了 10%还是下降了 5%？
• RAG 应用的“外挂”知识库是动态的，在不断维护的过程中，可能会产生新的知识干扰。 因此， 定期检测与重新评估是确保应用质量的重要手段。
• 由于 RAG 应用依赖基础大模型，那么如何在大量的商业与开源大模型中选择最适合企业的大模型或如何知道大模型升级一次版本对 RAG 应用产生了多大影响？

4.1. 评估方法

4.1.1. 人工

人工评估是RAG评估的基础方法，通过邀请专家或人工评估员对RAG生成的结果进行质量评估。

评估标准通常包括准确性、连贯性、相关性等。

尽管人工评估能够提供高质量的反馈，但这种方法耗时费力，且受限于评估员的主观性和经验差异

4.1.2. 自动化

自动化评估是当前RAG评估的主流和发展方向。通过利用大型语言模型和相关算法，自动化评估工具能够实现对RAG生成文本的质量评分，从而快速评估模型性能。

这种方法不仅提高了评估效率，还降低了人力成本。

4.2. RAG应用的评估依据与指标

基于大模型的RAG应用与传统应用有很大的不同：传统应用的输出大多是确定的且易于衡量的，比如输出一个确定的数值； 

RAG应用的输入和输出都是自然语言，其输出一般是一段文字，无法通过简单的定量判断评估其相关性与准确性等，往往需要借助更智能的工具与评估模型。

任何RAG系统的有效性和性能都严重依赖于这两个核心组件：检索器和生成器。

• 检索器必须高效地识别和检索最相关的文档，而生成器应该使用检索到的信息生成连贯、相关和准确的响应。
• 在部署之前，对这些组件进行严格评估对于确保RAG模型的最佳性能和可靠性至关重要。

4.3. RAG应用的评估类型和输入

4.3.1. 评估类型

1. 检索评估

检索评估的主要目标是评估上下文相关性，即检索到的文档与用户查询的匹配程度。
它确保提供给生成组件的上下文是相关和准确的。

2. 响应评估

响应评估适用于系统的生成组件。
这些评估衡量系统根据检索到的文档提供的上下文有效地生成响应的能力。

4.3.2. 评估依据(评估模块的输入)

• 输入问题（question）：用户在使用RAG应用时的输入问题。
• 生成的答案（answer）：需要评估的RAG应用的输出，即问题的答案。
• 上下文（context）：用于增强RAG应用输出的参考上下文，通常在检索阶段生成。
• 参考答案（reference_answer）：输入问题的真实的正确答案，通常需要人类标注

4.3.3. 检索评估

1. 上下文相关性（Context Relevancy）:检索出的上下文与输入问题之间的相关性，即上下文中有多少内容与输入问题相关

若用户提问 “埃菲尔铁塔的建造年份？”，
检索器返回：
	埃菲尔铁塔于 1887 年动工，1889 年竣工。
	巴黎是法国的文化中心。
尽管第二个片段与巴黎相关，但未包含建造年份的信息。
此时context_relevancy会根据关键信息（如 “1887”“1889”）的存在与否进行评分，而非仅统计相关片段的数量，这个一般用的比较少。

2. 上下文精度（Context Precision）: 一种是检索出的上下文context中与参考答案reference_answer相关的部分在上下文context中是否出现在最前面的位置，另一种是检索到的上下文中相关信息的比例（上下文中与问题相关的信息数量/上下文总信息数量）

问题：“苹果公司的总部在哪里？”
上下文：“苹果公司（Apple Inc.）成立于 1976 年，总部位于美国加利福尼亚州库比蒂诺市，CEO 是蒂姆・库克，主要产品包括 iPhone 和 Mac。”
分析：问题关注 “总部位置”，上下文中仅 “加利福尼亚州库比蒂诺市” 相关，其余（成立时间、CEO、产品）无关 → 精确率 = 1/4=25%。

3. 上下文召回率（Context Recall）: 衡量检索到的上下文中是否包含回答问题所需的全部关键信息，或者说检索到的上下文context与参考答案reference_answer之前的一致程度，也称为命中率hit_rate 即context Recall = 上下文中包含的关键信息数量/参考答案中关键信息数量

问题：“《三体》的作者是谁？哪一年出版？”
参考答案：“刘慈欣，2006 年。”
上下文：“刘慈欣，中国科幻作家，2006 年开始在《科幻世界》连载《三体》。”
分析：参考答案的关键信息是 “刘慈欣” 和 “2006 年”，上下文均包含 → 召回率 = 100%。
反例：若上下文仅包含 “刘慈欣”，未提 “2006 年”，则召回率 = 50%

4.3.4. 响应评估

响应评估适用于系统的生成组件。这些评估衡量系统根据检索到的文档提供的上下文有效地生成响应的能力。

1. 忠实度(Faithfulness):生成的答案（ answer）是否完全基于提供的上下文（context）信息，没有捏造、幻觉或与上下文矛盾的内容。将生成答案拆解为原子事实（如时间、地点、事件），逐一检查是否能在上下文中找到直接依据，如果存在上下文未提及的信息，即使正确，若上下文无依据也视为不忠实

问题：“爱因斯坦在哪一年获得诺贝尔奖？”
生成答案：“爱因斯坦于 1921 年因光电效应研究获得诺贝尔物理学奖。”
上下文：“1921 年诺贝尔物理学奖得主阿尔伯特・爱因斯坦，获奖理由为‘发现光电效应定律’。”
分析：答案中 “1921 年”“光电效应”“诺贝尔物理学奖” 均来自上下文，无额外信息 → 忠实度 = 100%。
反例：若答案添加 “他当时在普林斯顿大学任教”（上下文未提及），则忠实度下降。

2. 答案相关性(Answer Relevancy):生成的答案（answer）是否直接、清晰地回答了用户原始的查询问题（question） 。即使答案忠实于上下文，但如果答非所问，那么这个答案也是无效的。

问题：“如何煮咖啡？”
生成答案：“咖啡豆需研磨至中粗度，用 90℃热水冲泡 3 分钟。”
分析：答案直接针对 “如何煮” 的步骤，包含关键动作（研磨、冲泡温度、时间）→ 相关性高。
反例：若答案为 “咖啡豆起源于埃塞俄比亚”（回答 “起源” 而非 “方法”），则相关性低。

4.3.5. 评估指标

4.3.6. 评估工具

ragas

RAGAs是一个用于评测检索增强生成（RAG）应用的评测框架，它的核心目标是提供一套综合性的评测指标和方法，以量化地评测RAG管道(RAG Pipeline)在不同组件层面上的性能。
RAGAs特别适用于那些结合了检索（Retrieval）和生成（Generation）两个主要组件的RAG系统，支持Langchain 和 Llama-Index。工具地址

1. 评估检索质量：context_precision context_recall
2. 评估生成质量：faithfulness answer_relevancy

Ragas 的 Context Precision（上下文精度）是一种衡量检索系统返回的上下文（文本块集合）中与查询相关的文本块比例的指标。
它的定义稍稍有点不同，它通过对每个相关文本块的位置k计算Precision@k值，反映关注相关文本块的排序质量（如是否排在前列）, 
实际更接近MAP指标（所有相关项的平均精确度），
而传统 Context Precision 则反映检索结果的整体相关性密度。

Trulens

TruLens是一款旨在评估和改进 LLM 应用的软件工具，相对独立，可以集成 LangChain 或 LlamaIndex 等 LLM 开发框架。
使用反馈功能来客观地衡量 LLM 应用的质量和效果。包括分析相关性、适用性和有害性等方面。TruLens 提供程序化反馈，支持 LLM 应用的快速迭代，这比人工反馈更快速、更可扩展

5. 实例-助手

在金融领域，开发一个能够仿效专家解读上市公司年报的智能对话系统，一直是人工智能技术进步的关键目标。
尽管目前的人工智能系统在文本对话领域已展现出显著的进展，但在更为精细、更具挑战性的金融领域交互方面，其性能尚需进一步提升。

• 比如经常看见的企业年报，属于最常见的图片、文本、表格混排的 PDF 文档，图片、表格都可以归属于半结构化或非结构化的数据。

• 半结构化数据对于传统 RAG 来说可能具有挑战性，文本拆分可能会分解表，从而损坏检索中的数据；嵌入表可能会给语义相似性搜索带来挑战。

通过构建摘要索引解决这个问题：分别为每个文本和表格数据创建摘要，将其嵌入文档

4.3.7. RAG应用中使用RAGAS

指标关联

这四个指标之间是有协同关系的，RAG 的性能是检索器和生成器协同工作的结果，指标之间存在紧密的关联：

• 检索器是生成器的基础： Context Recall 和 Context Precision 直接决定了输入给生成器的上下文质量。
• 理想状态： 高召回率 + 高精确率。检索器能找到所有相关信息，且只找到相关信息。
• 现实权衡： 在大规模数据集中，召回率和精确率往往难以兼得。提高召回率（找全）可能牺牲精确率（引入噪声），反之亦然。

很多业务场景，如技术文档问答或客服，倾向于优先保证信息不遗漏，因此 “高召回率 + 中等精确率” 常常是可接受甚至追求的目标

• 生成器依赖高质量输入： Faithfulness 和 Answer Relevancy 的表现很大程度上取决于检索器提供的上下文。
• 如果上下文不完整（低 Context Recall），生成器可能因缺乏信息而无法给出完整或准确的答案（影响 Answer Relevancy），甚至可能被迫“猜测”（影响 Faithfulness）。
• 如果上下文充满噪声（低 Context Precision），生成器可能难以聚焦关键信息，导致答案冗余、偏题（影响 Answer Relevancy），或错误地依据了不相关信息（影响 Faithfulness）。

同时对于context_recall和context_precision这两个指标，如果各有高低，比较难判断的时候，我们还会引入F1分数进行综合评估，F1分数用来平衡精确度和召回率，目标是找到适合特定应用需求的最佳平衡，是精确度和召回率的调和平均值：F1分数=2*(准确率*召回率/(准确率+召回率))

指标等级标准

系统性优化路径与策略-从基础到协同

1. 性能问题，特别是多个指标偏低时

- 核心优化原则：先固根基，再求精进 (检索器优先)  
- 依赖关系： 生成器的输出质量上限受限于检索器提供的输入质量。“Garbage In, Garbage Out”。优化检索器是提升整体性能的杠杆点。  
- 成本效益： 优化检索策略（如调整参数、混合检索、重排序）通常比大规模微调生成模型或复杂的提示工程更快见效，成本也相对较低。

2. 分阶段优化策略

第一阶段：夯实检索基础 (优化 Context Recall & Context Precision)
第二阶段：提升生成质量 (优化 Faithfulness & Answer Relevancy)

3. 提升context_recall（上下文召回率）

4. 检索器增强

混合检索：结合BM25（关键词匹配）和向量检索，例如在医疗场景中，使用BM25召回包含特定症状术语的文档，再用向量检索补充相关病例。
查询改写：通过 LLM 将用户问题扩展为多个同义词或子问题，例如将 “如何治疗糖尿病” 改写为 “糖尿病的药物治疗方案” 和 “饮食管理方法”，提升检索覆盖范围。

5. 知识库优化

数据清洗：去除重复或低质量文档（如网页爬取的广告内容），确保检索空间的有效性。
增量更新：定期补充新数据（如行业报告、政策文件），并重新构建索引，避免知识滞后。

6. 提升context_precision（上下文精度）

重排序技术，对检索结果进行二次排序，例如在法律场景中，优先展示与案件类型匹配的法律条文。
分块策略优化，语义分块、调整块大小、动态分块。
调整检索参数: 优化 Top-K、相似度阈值、 通过实验确定混合检索权重的最优权重、平衡召回率和精度等。

7. 提升faithfulness（忠实度）:在良好检索，检索器已能提供相对靠谱的上下文基础上，确保答案忠实、相关

生成器约束：
  提示词工程：在提示中明确要求 “仅基于提供的上下文回答”，并添加示例（如 “根据上下文，以下哪项是正确的：...”）。
  事实核查：在生成答案后，使用 LLM 对答案进行二次验证等。
上下文截断与增强：
  截断策略：优先保留上下文开头和结尾的关键信息（如论文摘要、法律条文标题），避免因 LLM 输入长度限制导致中间信息丢失。
  元数据增强：为每个文档块添加标题、关键词等元数据，帮助生成模型快速定位关键信息。

8. 提升answer_relevancy（答案相关性）

问题理解优化：
  问题分类：对用户问题进行分类（如 “事实型”“比较型”“建议型”），并针对不同类型生成结构化提示（如 “请分点回答...”）。
  多轮对话：在答案中添加追问提示（如 “是否需要更详细的解释？”），引导用户明确需求。
生成策略调整：
  摘要压缩：对上下文进行摘要，去除冗余信息后再输入生成器，提升回答的针对性。
  对比学习：微调生成模型，使其学习问题与答案的匹配模式。

9. 设定合理的性能目标：因地制宜的阈值

指标的理想值并非一成不变，需结合业务场景的风险和需求来设定
核心指标通用基准范围 (参考)：  
- Faithfulness: ≥ 0.85 是行业普遍追求的目标。低于 0.7 可能存在严重幻觉。  
- Answer Relevancy: ≥ 0.8 保证较好的用户体验。低于 0.6 可能用户难以接受。开放域问答≥0.7也可以接受（如维基百科 QA 场景中，RAGAS 默认测试集平均得分 0.72）  
- Context Recall: ≥ 0.7-0.8 是常见目标。知识密集型场景要求更高。若知识库规模庞大且允许部分信息缺失（如新闻摘要），可降至 0.6  
- Context Precision: ≥ 0.7 通常是好的起点。高风险场景要求更高。

10. 行业阈值建议

医疗 / 法律 (高风险):    
- 核心: Faithfulness ≥ 0.9, Context Recall ≥ 0.9。    
- 关注: 任何事实错误或信息遗漏都可能导致严重后果。  
客服 / 电商 / 咨询 (效率与体验并重):    
- 核心: Answer Relevancy ≥ 0.8, Context Precision ≥ 0.7。    
- 关注: 回答需直接解决问题，避免冗余信息干扰用户。  
通用问答 / 内容生成 (平衡信息覆盖与相关性):    
- 核心: Answer Relevancy ≥ 0.7, Context Recall ≥ 0.7。    
- 关注: 在开放域中，保持答案相关性和信息覆盖面的平衡。

11. 持续评估与优化的闭环

通过 RAGAS 的四大核心指标，我们可以：
1. 量化理解 RAG 应用在检索和生成环节的具体表现。
2. 诊断分析 指标间的协同关系和潜在的性能瓶颈。
3. 指导优化 遵循“检索优先、生成增强、协同调优”的系统性路径。
4. 设定目标 结合业务场景制定合理的性能阈值。
最终，RAG 应用的性能提升是一个持续迭代的过程。定期使用这些指标进行评估，结合用户反馈，不断调整优化策略，才能打造出真正高效、可靠的 RAG 系统。

选择合适的知识块大小-基础参数问题

1. 在将外部知识特别是文档进行向量化存储时，都会使用 chunk_size 这个决定把原始知识分割成多大块（ Chunk）的简单参数，而知识块也是后面从向量库中检索上下文知识的基本单位。因此chunk_size 在很大程度上会影响后面的检索与响应质量。

• chunk_size 越小，产生的知识块越多、粒度越小。尽管知识块越小，语义越精确，但是风险是携带的上下文越少，可能导致需要的重要信息不出现在检索出的顶部知识块中（特别是当 top_K 比较小时）。
• chunk_size 越大，携带的上下文越完整，但也带来语义不精确的隐患。此外，过大的 chunk_size 可能导致性能下降、携带的上下文过多，从而导致上下文窗口溢出及 token 成本升高。

2. 知识块大小是否合适有时候与 RAG 应用需要完成的任务类型有关:

• 常见事实性回答，可能只需要少量特定的知识块
• 摘要、总结、对比之类的任务，你可能需要更大的知识块甚至全部知识块

3. 常见的分块方式有：固定大小分块；句子分割；递归分割；专门分块（比如按标题）；语义分块等等
4. 每个块的大小依然是很重要的参数，多大分块合适

   1. 通用场景推荐 128-512 tokens：这是最常见的分块区间，平衡了上下文完整性和检索效率。例如：微软研究指出，512 tokens 是较小块的基准，而企业级应用中甚至会采用 100 tokens 的块大小以提升精准度。 Databricks 实验使用 512 tokens 块大小和 256 tokens 重叠步幅，在长上下文场景中表现优异。 1024 tokens：LlamaIndex 测试显示，该大小在响应时间和质量（忠实度、相关性）之间取得最佳平衡，尤其适合需要更多上下文的复杂任务 2. 细分场景推荐 技术文档 / 学术论文：采用200-300 tokens，确保专业术语和逻辑结构的完整性。例如，微软分析显示，技术文档分块过大会导致术语稀释，影响检索准确性。 长叙事文本（如小说）：可扩展至500-1000 tokens，减少分块数量以保留情节连贯性。 社交媒体 / 短文本：使用100-200 tokens，适配碎片化内容的检索需求

   最好的办法使用应用评估框架与评估数据集来评估不同的 chunk_size 下的各种性能指标，进而做出最优的选择

应用

评估中，使用LangChain的RecursiveCharacterTextSplitter分块，默认分割符，chunk_overlap为chunk_size的20%，使用阿里百炼系列模型，向量数据库FAISS， 仅使用单纯向量检索，未使用任何AdvanceRAG技术，top_K = 10。

• chunk_size = 128 ，将分块为1546个
  
• chunk_size = 256 ，将分块为821个
  
• chunk_size = 512 ，将分块为462个
  
• 综合来看，3种分块大小下RAG应用的性能都不错，大部分指标差距几乎都在3%以内。
  

  如果要优中选优，chunk_size=128 的指标组表现最优。F1 分数最高，说明上下文质量综合最优，在信息完整性（Recall）和纯净度（Precision）之间达到最佳平衡，Faithfulness 和 Answer Relevancy 均处于高位，既保证回答忠实于手册内容，又能有效关联用户问题。大分块在回答相关性和信息召回上有一定优势，但上下文精确率的显著下降和 F1 分数的降低表明其引入了过多无关信息。 另外，成本也是128指标组的一大显著优势

• 在我们上面的实战中，128指标组的召回率在三者中最低，能否继续提高？提高后对其他指标是否有影响？前面我们已经知道，提高召回率有混合检索或者查询改写之类的方法。我们接下来试试，维持其他参数不变，但是改变检索器为混合检索，作为对照组，我们还同时引入一个上下文压缩检索器

从结果来看，毫无疑问我们希望提升召回率的想法通过混合检索切切实实的达到了，在召回率提升的同时，回答相关性和忠实度也得到了提升。

mix_retriever：
  context_recall=1.0：表示检索器完美召回了所有相关文档，没有遗漏关键信息。
  faithfulness=0.9848：回答忠实度极高，几乎完全基于检索到的上下文生成，较少引入虚构内容。
但是：
  context_precision=0.4811：精确率极低，意味着检索结果中近一半是不相关文档，引入大量噪音，可能增加模型处理负担，甚至干扰回答相关性。
  F1 分数 = 0.6497：精确率和召回率失衡，综合表现一般。

对照组compression_retriever：
  context_precision=0.8057：精确率较高，检索结果相关性较好。
  faithfulness=0.9770：忠实度接近 mix_retriever，回答可靠性较强。
  context_recall=0.7037：召回率显著低于前两者，可能遗漏大量关键文档，导致回答缺乏必要信息。
  answer_relevancy=0.8227：回答相关性最低，可能因召回不足或压缩过程中信息损失导致。
  F1 分数 = 0.7513：主要受限于召回率和回答相关性的不足。

从这三组指标来看：
  faiss_retriever：F1 分数最高（0.8773），精确率和召回率均处于高位（0.90/0.85），回答相关性（0.8994）和忠实度（0.9650）也表现优异。
  mix_retriever：召回率极致但精确率拖后腿，这种指标较为适合对 “零遗漏” 有绝对需求的场景（如极端严格的法律合规审查，医疗领域）。
  compression_retriever：各项指标无突出优势：召回率和回答相关性较低，仅适合对检索效率（如压缩存储）有特殊要求且对信息完整性要求不高的场景。

总的来说，faiss_retriever 的指标表现最优，mix_retriever是次优选择，但是需要对context_precision做进一步提升，或者严格限定使用场景。

• 提升召回率、回答相关性和忠实度,但精确率太低了，有没有办法改善

5.1. 步骤

• 首先用Unstructured 来提取文档 （PDF） 中的文本和表格，并进行分块
• 然后用LLM分别对每个文本和表格创建摘要，将其嵌入向量数据库
• 最后通过摘要使用MultiVectorRetriever过滤出相关文档，喂给LLM当作上下文

Unstructured 使用：

• tesseract ：用于光学字符识别 （OCR）
• poppler ：用于 PDF 渲染和处理

5.2. PDF中存在图片

借助多模态视觉大模型（比如 Qwen-VL、 GPT-4V 等）结合 OCR技术对图片进行理解是常见的方法。这还可以进一步分为以下两种情况。

a．纯文字信息图片：可利用 OCR 技术识别成纯文本，再按照普通的文本做索引与检索。
b．其他图片：借助多模态视觉大模型理解并生成图片的摘要用于索引与检索，但是在检索后需要递归检索出原始图片用于后面的生成

生成答案时，如果只需要文字，大语言模型就可以，但是希望图文混排，那么需要借助多模态大模型生成答案，并且要将对应的原始表格或者图片交给多模态大模型