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

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

适用场景

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

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．其他图片：借助多模态视觉大模型理解并生成图片的摘要用于索引与检索，但是在检索后需要递归检索出原始图片用于后面的生成

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