企业官网建设流程全解析

本文深入解析了RAG（检索增强生成）系统架构，重点阐述了三个核心指标：上下文精确度（Context Precision）、上下文召回率（Context Recall）和上下文相关性（Context Relevancy）。通过这三个指标，可以评估并优化RAG系统的排序质量、信息完整性和查询相关性，从而提升最终生成答案的质量。文章还提供了具体的判断方法和优化策略，以及在不同应用场景下的实践案例，帮助读者全面理解和应用RAG系统优化技术。

RAG 系统架构

检索增强生成（Retrieval-Augmented Generation, RAG）系统由两个核心模块组成：

1. 检索器（Retriever）：从知识库中检索相关文档片段（chunks）
2. 生成器（Generator）：基于检索到的上下文生成最终答案

用户查询 → 检索器 → 检索上下文 → 生成器 → 最终答案 ↓ ↓ 知识库 LLM (GPT/Claude等)

最终生成答案质量的上限由检索质量决定。

即使使用最强大的 LLM，如果检索器提供的上下文缺失关键信息或充斥噪声，生成器也无法生成准确的答案。

因此，检索器评估是 RAG 系统优化的第一步。

在传统信息检索中经常使用的指标 Precision 和 Recall，它们只关心“检索到多少相关文档”，但 RAG 场景有三个额外要求：

1. 排序质量：相关信息必须排在前面，LLM 对前排内容更敏感
2. 信息完整性：必须检索到回答问题所需的所有信息
3. 查询相关性：检索内容必须与用户查询直接相关

为了处理这三个要求，Context Precision、Context Recall和Context Relevancy三个指标被设计出来，用来评估检索器的质量。

这三个指标的目标是在检索器的排序、覆盖、相关三个维度上提供可量化的评估，帮助优化 RAG 系统的端到端性能。

核心指标 1：Context Precision - 上下文精确度

定义

Context Precision 指标用来评估检索器是否将相关块排序到无关块之前。

它专门用于优化排序算法，解决“相关信息被检索到了，但排在后面”的问题，它通过加权求和强调前排位置的重要性。

数学定义

结果中的相关项总数

其中：

• = 检索的总块数
• = 位置 的文档块是否有助于生成答案（1=有帮助，0=无帮助）
• 前个位置中的相关块数

计算示例

场景：检索 5 个块，相关块在位置 1, 3, 5

对比场景：如果相关块在位置 3, 4, 5（排序更差）

对比后会发现，3 个相同的相关块，但排序质量不同导致分数从 0.76 降至 0.48。

判断块是否有帮助

在上述的计算公式中，表示当前文档块是否有助于生成答案，RAGAS 框架提供三种实现方式进行判断：

1. 基于参考答案（LLMContextPrecisionWithReference）：

• 输入：检索块 + 参考答案
• LLM 判断：该块是否有助于生成参考答案
• 输出：（有助）或 （无助）

2. 基于生成答案（ContextUtilization）：

• 输入：检索块 + 实际生成的答案
• LLM 判断：该块是否在生成答案中被实际使用
• 输出：（被使用）或 （未使用）

3. 基于文档 ID（IDBasedContextPrecision）：

• 输入：检索到的文档 ID 列表 + 参考文档 ID 列表
• 直接比对：检索到的文档 ID 是否在参考列表中
• 输出：（在列表中）或 （不在列表中）

方法选择建议：

• 基于参考答案：最常用，适合有高质量参考答案的场景
• 基于生成答案：适合评估实际生成效果，但受生成器质量影响
• 基于文档 ID：最快速，但需要预先标注参考文档，且粒度较粗

判断是否需要优化

Context Precision < 0.6 ↓ 首先确认：相关块是否被检索到？ ├─ 否 → 这是 Recall 问题，非 Precision 问题 │ 解决方案：增加检索数量 K，降低相似度阈值 │ └─ 是 → 相关块排在第几位？ ├─ 集中在后半部分 → 排序算法问题 │ 解决方案： │ • 引入 re-ranker（cross-encoder） │ • 使用更强的 embedding 模型 │ • 调整检索算法（如从余弦相似度改为最大内积） │ └─ 均匀分散 → 检索范围过宽 + 排序失效 解决方案： • 提升 query 理解质量（query rewriting/expansion） • 检查 chunking 策略是否破坏语义完整性 • 清洗知识库噪声数据

核心应用场景

场景 1：引入或调优 re-ranker

问题：基础检索器，如向量检索的排序不够精准，关键信息排在后面

应用方法：

• 对照组：仅使用向量检索
• 实验组：向量检索 + cross-encoder re-ranker
• 用 Context Precision 评估 re-ranker 是否改善了排序质量

场景 2：对比不同 embedding 模型

问题：不确定哪个 embedding 模型更适合当前领域

应用方法：

• 在相同测试集上对比 OpenAI ada-002、Cohere embed-v3、BGE-large 等模型
• 用 Context Precision 判断哪个模型的排序更符合“重要信息在前”的要求

核心指标 2：Context Recall - 上下文召回率

定义

**Context Recall 指标用于评估检索器找到的所有 chunks 集合中是否包含回答问题所需的所有信息，**解决“检索器遗漏了回答问题所需的关键信息”的问题。

它将参考答案分解为独立声明 claims，检查这些 chunks 中是否能找到每个声明。

数学定义

中可验证的声明数参考答案中的总声明数

计算示例

问题：法国大革命何时爆发及主要原因？

参考答案分解为独立声明：

1. 声明 A：法国大革命于 1789 年爆发
2. 声明 B：财政危机是重要导火索
3. 声明 C：第三等级对贵族特权不满
4. 声明 D：启蒙思想的传播推动了革命

被召回的 chunks：

• 块 1：“法国大革命始于 1789 年，当时法国面临严重财政危机……”
• 块 2：“第三等级代表对贵族和教士的特权极为不满……”
• 块 3：“伏尔泰和卢梭的启蒙思想在法国广泛传播……”

验证结果：

• 声明 A：✓（块 1 支撑）
• 声明 B：✓（块 1 支撑）
• 声明 C：✓（块 2 支撑）
• 声明 D：✓（块 3 支撑）

对比场景：如果被召回的 chunks 只包含块 1 和块 2，声明 D 缺失后

判断方法

Context Recall 核心特征是只关心的是信息完整性，而非块的排序位置或与查询的直接相关性。即使相关块排在最后，只要所有声明都能找到支撑，Recall 就是满分。

Context Recall 的判断分为两个步骤，每个步骤都依赖 LLM：

步骤 1：声明分解

输入：参考答案 - 完整的文本

LLM 任务：将参考答案分解为独立的原子声明列表

输出示例：

参考答案："法国大革命于1789年爆发，主要原因是财政危机和等级矛盾。" 分解后的声明： 1. "法国大革命于1789年爆发" 2. "财政危机是法国大革命的主要原因之一" 3. "等级矛盾是法国大革命的主要原因之一"

步骤 2：声明验证

输入：单个声明 + 检索上下文（被召回的 chunks）

LLM 任务：判断检索上下文是否包含支撑该声明的证据

判断标准：

• ✓可验证：检索上下文中存在明确支撑该声明的文本
• ✗不可验证：检索上下文中没有相关证据，或证据不足以支撑该声明

输出示例：

声明："法国大革命于1789年爆发" 检索上下文包含："法国大革命始于1789年……" 判断：可验证 ✓ 声明："启蒙思想推动了革命" 检索上下文不包含任何关于启蒙思想的内容 判断：不可验证 ✗

这两步中最重要的是原子性原则：一个声明只表达一个独立事实，不可再分。

判断是否需要优化

Context Recall < 0.6 ↓ 分析：哪些类型的声明被遗漏？ ├─ 事实性声明（日期、地点、人名） │ → 知识库覆盖度不足 │ 解决方案：扩充知识库，补充缺失文档 │ ├─ 因果关系声明（A 导致 B） │ → Chunking 破坏了跨句子的因果链 │ 解决方案： │ • 增加 chunk overlap │ • 使用语义分块而非固定长度分块 │ • 保留段落完整性 │ └─ 背景信息声明（定义、解释） → Embedding 模型对背景信息不敏感 解决方案： • 使用针对性训练的 embedding 模型 • Query expansion（将查询扩展为包含背景需求） • 混合检索（关键词 + 语义）

核心应用场景

场景 1：评估知识库覆盖度

问题：不确定知识库是否足够全面，哪些类型的问题答不好

应用方法：

• 准备不同类型的测试查询，包含事实性、因果性、程序性等
• 计算每种类型查询的 Context Recall
• 识别 Recall 低的类型，针对性补充文档

场景 2：优化 chunking 策略

问题：信息被切碎了，因果关系、列表、表格跨越多个 chunk，导致检索不完整

应用方法：

• 对比不同 chunking 策略的 Context Recall

• 固定长度分块： 512 tokens
• 语义分块：按段落、章节
• 不同 overlap 比例：0%, 10%, 20%

场景 3：调整检索数量 K

问题：不确定检索 top-5 够不够，还是需要 top-10 或更多

应用方法：

• 绘制 K vs Context Recall 曲线
• 找到性价比最高的 K 值，边际收益递减的拐点

案例：

• 企业知识库问答：

• K=3: Recall = 0.58
• K=5: Recall = 0.68
• K=10: Recall = 0.82
• K=20：Recall = 0.84（提升不明显）

• 结论：选择 K=10，Recall 提升明显，且不会引入过多噪声

场景 4：评估 query expansion 效果

问题：用户查询太短或太模糊，检索器理解不全面

应用方法：

• 对照组：使用原始查询
• 实验组：使用 query rewriting/expansion
• 用 Context Recall 判断扩展后是否检索到更多必要信息

核心指标 3：Context Relevancy - 上下文相关性

定义

Context Relevancy 指标是用于评估被召回的 chunks 与用户查询的相关性，不依赖参考答案或生成答案。

它是用来解决“检索结果充斥与用户查询无关的内容”的问题。

数学定义

与查询相关的语句数被召回中的总语句数

计算示例

用户查询：如何优化 Python 代码性能？

检索上下文（5 个语句）：

1. “使用 Cython 可以将 Python 代码编译为 C 扩展” ✓ 相关
2. “NumPy 数组操作比 Python 列表快 10-100 倍” ✓ 相关
3. “Python 由 Guido van Rossum 于 1991 年创建” ✗ 无关
4. “多进程可以绕过 GIL 限制，利用多核 CPU” ✓ 相关
5. “Python 3.11 引入了 Faster CPython 项目” ✓ 相关

。80% 的检索内容与查询相关，但有 20% 是噪声。语句 3 是 Python 历史背景，对性能优化无帮助。

这个指标是唯一不需要参考答案的检索指标，只关注噪声比例。计算得到的分数越低，说明检索结果中无关信息越多。

判断方法

Context Relevancy 的判断同样分为两个步骤：

步骤 1：语句分割

输入：检索上下文（被召回的 chunks）

任务：将检索上下文分割为独立的语句列表

分割方法：

1. 按标点符号分割：

• 优势：实现简单，速度快
• 劣势：会错误分割列表、公式、引用
• 适用场景：简单文本，对精度要求不高

2. 使用 NLP 分句器：

• 优势：准确识别句子边界
• 劣势：对非英语支持较差，需要语言模型
• 适用场景：英文为主的正式文档

3. 使用 LLM 分割：

• 优势：灵活，支持多语言，能理解语义边界
• 劣势：成本高，速度慢
• 适用场景：多语言混合，复杂格式文档

示例：

检索上下文："使用 Cython 可以提升性能。NumPy 比列表快。Python 由 Guido 创建。" 分割后的语句： 1. "使用 Cython 可以提升性能" 2. "NumPy 比列表快" 3. "Python 由 Guido 创建"

步骤 2：相关性判断

输入：单个语句 + 用户查询

LLM 任务：判断该语句是否与用户查询相关

判断标准：

• ✓相关：语句直接回答查询，或提供回答查询所需的必要信息
• ✗无关：语句与查询主题无关，或仅提供背景信息但对回答查询无帮助

输出示例：

查询："如何优化 Python 代码性能？" 语句 1："使用 Cython 可以提升性能" 判断：相关 ✓（直接提供优化方法） 语句 2："NumPy 比列表快" 判断：相关 ✓（提供性能优化的具体技术） 语句 3："Python 由 Guido 创建" 判断：无关 ✗（历史背景，与性能优化无关）

判断是否需要优化

Context Relevancy < 0.7 ↓ 步骤 1：抽样分析无关语句的类型 ├─ 类型 A：完全无关的主题 │ → Query 理解错误 │ 解决方案： │ • Query rewriting（将自然语言查询改写为检索友好形式） │ • Query classification（先分类查询意图，再检索） │ ├─ 类型 B：相关主题但细节不匹配 │ → Embedding 模型粒度过粗 │ 解决方案： │ • 使用更精细的 embedding 模型 │ • 混合检索（语义 + 关键词） │ • 调整 chunk size（更小的块 = 更精确的匹配） │ └─ 类型 C：重复或冗余信息 → 去重机制缺失 解决方案： • 语义去重（检测相似度 > 0.9 的块） • Maximal Marginal Relevance (MMR) 算法 • 后处理过滤 步骤 2：检查检索参数 ├─ top_k 过大 → 降低 K 值 ├─ similarity_threshold 过低 → 提高阈值 └─ 未使用 re-ranking → 引入 re-ranker

核心应用场景

场景 1：生产环境实时监控

问题：RAG 系统已上线，需要持续监控检索质量，但无法为每个查询都准备参考答案

应用方法：

• Context Relevancy 是唯一不需要参考答案的检索指标，可以对每个查询实时计算
• 设置告警阈值（如 Relevancy < 0.7）
• 按查询类型、时间段、用户群体分组监控

监控策略：

实时监控面板： - 整体 Relevancy 趋势图（按小时） - 按查询类型分组的 Relevancy（产品咨询 vs 售后问题 vs 物流查询） - 低 Relevancy 查询 Top 10（人工复查） - 告警规则：单小时 Relevancy < 0.7 或环比下降 > 15%

场景 2：优化 query 理解

问题：用户的自然语言查询模糊或有歧义，检索器理解错了意图

应用方法：

• 对照组：直接使用原始查询
• 实验组：先进行 query classification 或 query rewriting
• 用 Context Relevancy 评估理解优化的效果

场景 3：调整检索阈值

问题：不确定相似度阈值设多少合适，太低会引入噪声，太高会漏掉信息

应用方法：

• 测试不同阈值（0.5, 0.6, 0.7, 0.8）
• 同时监控 Context Relevancy 和 Context Recall
• 找到平衡点

场景 4：评估混合检索策略

问题：想对比纯向量检索 vs 向量+关键词混合检索，判断混合检索是否引入了更多噪声

应用方法：

• 对照组：纯向量检索（如 FAISS）
• 实验组：向量检索 + BM25 关键词检索（加权融合）
• 用 Context Relevancy 判断混合策略的噪声水平

场景 5：去重与 MMR（Maximal Marginal Relevance）

问题：检索结果有很多重复或高度相似的内容，浪费了 LLM 的上下文窗口

应用方法：

• 对照组：不去重
• 实验组：语义去重或使用 MMR 算法
• 用 Context Relevancy 评估去重后是否提升了信息密度

2026年AI行业最大的机会，毫无疑问就在应用层！

字节跳动已有7个团队全速布局Agent

大模型岗位暴增69%，年薪破百万！

腾讯、京东、百度开放招聘技术岗，80%与AI相关……

如今，超过60%的企业都在推进AI产品落地，而真正能交付项目的大模型应用开发工程师**，**却极度稀缺！

落地AI应用绝对不是写几个prompt，调几个API就能搞定的，企业真正需要的，是能搞定这三项核心能力的人：

✅RAG：融入外部信息，修正模型输出，给模型装靠谱大脑

✅Agent智能体：让AI自主干活，通过工具调用（Tools）环境交互，多步推理完成复杂任务。比如做智能客服等等……

✅微调：针对特定任务优化，让模型适配业务

目前，脉脉上有超过1000家企业发布大模型相关岗位，人工智能岗平均月薪7.8w！实习生日薪高达4000！远超其他行业收入水平！

技术的稀缺性，才是你「值钱」的关键！

具备AI能力的程序员，比传统开发高出不止一截！有的人早就转行AI方向，拿到百万年薪！👇🏻👇🏻

AI浪潮，正在重构程序员的核心竞争力！现在入场，仍是最佳时机！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】

⭐️从大模型微调到AI Agent智能体搭建

剖析AI技术的应用场景，用实战经验落地AI技术。从GPT到最火的开源模型，让你从容面对AI技术革新！

大模型微调

• 掌握主流大模型（如DeepSeek、Qwen等）的微调技术，针对特定场景优化模型性能。

• 学习如何利用领域数据（如制造、医药、金融等）进行模型定制，提升任务准确性和效率。

RAG应用开发

• 深入理解检索增强生成（Retrieval-Augmented Generation, RAG）技术，构建高效的知识检索与生成系统。
• 应用于垂类场景（如法律文档分析、医疗诊断辅助、金融报告生成等），实现精准信息提取与内容生成。

AI Agent智能体搭建

• 学习如何设计和开发AI Agent，实现多任务协同、自主决策和复杂问题解决。
• 构建垂类场景下的智能助手（如制造业中的设备故障诊断Agent、金融领域的投资分析Agent等）。

如果你也有以下诉求：

快速链接产品/业务团队，参与前沿项目

构建技术壁垒，从竞争者中脱颖而出

避开35岁裁员危险期，顺利拿下高薪岗

迭代技术水平，延长未来20年的新职业发展！

……

那这节课你一定要来听！

因为，留给普通程序员的时间真的不多了！

立即扫码，即可免费预约

「AI技术原理 + 实战应用 + 职业发展」

「大模型应用开发实战公开课」

👇👇

👍🏻还有靠谱的内推机会+直聘权益！！

完课后赠送：大模型应用案例集、AI商业落地白皮书