4.1 外部存储与记忆系统

4.1.1 为什么需要外部存储和记忆系统

LLM本身没有持久记忆系统,而能依赖上下文,导致的问题:

1. 会话隔离:不用的会话之间无法共享信息
2. 容量限制:大量信息无法同时放入上下文窗口
3. 时效性:模型训练数据有截至时间,缺乏最新知识

人脑记忆机制的工程启示: 人脑处理信息的闭环是 “刺激 → 筛选 → 巩固 → 遗忘 → 再学习”。

1. 刺激和筛选:写入阶段选择性过滤,选择相关信息防止冗余
2. 短期记忆和激活记忆:短期记忆追求读写速度
3. 长期记忆(外显和内隐):外显记忆:外部大容量知识库;内隐记忆:固化在模型权重中的参数(写慢读快)
4. 遗忘机制:长期不用的会主动淘汰

4.1.2 外部存储的类型

结构化存储

适合存储结构化数据:用户信息,配置,元数据等等 关系型数据库:PostgreSQL,MySQL 键值存储:Redis,DynamoDB 文档数据库:MongoDB

向量存储

适合存储和检索语义内容,是RAG系统的核心

• 专用向量数据库:Pinecone,Weaviate,Milvus,Qdrant
• 通用数据库支持:PostgreSQL,部分企业数据库的向量能力以及Elasticsearch等

图存储

适合存储实体关系和知识网络

• 图数据库：Neo4j、Amazon Neptune
• 知识图谱平台：专用知识图谱系统据库

文件存储

适合存储原始文件和非结构化内容

• 对象存储:S3,GCS,Azure Blob
• 文件系统:本地或网络文件系统

4.1.3 记忆系统的设计模式

模式一:全量加载

将全部信息加载到上下文 适用场景:信息量小,任务简单

模式二:按需检索

只检索当前任务相关的信息,高效但是需要精确的检索能力 使用场景:信息量大,查询明确

模式三: 层级缓存

热数据缓存在快速缓存,冷数据存储在持久层.平衡效率和容量 适用场景:高频查询,大规模系统

模式四:流式更新

持续更新存储中的信息,保持数据新鲜,适合实时应用 适用场景:动态信息,实时系统

4.1.4 记忆与上下文的协作

关键设计决策:

• 何时读取：请求处理前还是过程中
• 读取什么：基于什么条件选择记忆
• 何时写入：响应后、会话结束时、还是实时
• 写入什么：全部内容还是提取的关键信息
• 能否写入：是否有用户同意、来源可信度、租户/权限范围、可回滚版本和中毒记忆隔离策略

4.1.5 记忆更新策略

1. 记忆淘汰算法 (Eviction Algorithms)

当存储空间受限时，决定哪些记忆应该被移除：

• LRU (Least Recently Used)
  • 原理：维护一个链表，最近访问的移动到表头。当容量满时，淘汰表尾（最久未访问）的记忆。
  • 适用：假设最近使用的信息在未来最可能被再次使用。
  • 缺陷：可能淘汰掉低频但非常关键（如用户过敏原）的信息。
• 时间衰减 (Time-Decay)
  • 原理：为每条记忆分配一个初始权重，随时间推移按指数衰减。Weight=Weight0×e−λt*Weight=Weigh**t0×e−λ**t。当权重低于阈值时淘汰。
  • 优化：每次访问时重置权重，模拟人类的“复习”巩固机制。
  • 适用：模拟人类遗忘曲线，保留新鲜记忆。
• 重要性评估 (Importance Scoring)
  • 原理：利用 LLM 对每条新记忆进行评分（1-10 分）。淘汰时优先保留高分记忆。
  • 示例：“我想吃披萨”（2 分） vs “我对花生过敏”（10 分）。
  • 适用：确保关键事实不被错误淘汰。

2. 记忆整合机制 (Consolidation Mechanisms)

将零散的短期记忆转化为结构化的长期记忆：

• 摘要 (Summarization)
  • 过程：定期（如每晚或每积累 N 条对话）触发 Summarization Agent。
  • 操作：读取最近的对话记录，生成一段精炼的摘要，存入长期记忆，然后清空原始对话。
  • 效果：极大压缩存储空间，同时保留核心上下文。
• 合成 (Synthesis)
  • 过程：检测到新信息与旧记忆相关但不完全一致时触发。
  • 操作：Retrieve 相关旧记忆 -> 让 LLM 分析冲突或增量 -> 生成新的综合性记忆 -> 覆盖旧记忆。
  • 效果：解决信息冲突，维持知识库的一致性。

4.1.6 实现考量

一致性

• 多个请求并发访问时如何保证一致性
• 记忆更新的原子性保证

可靠性

• 存储系统的持久性保证
• 故障恢复机制

性能

• 读写延迟对响应时间的影响
• 大规模数据下的检索效率

成本

• 存储成本
• 计算成本（特别是嵌入计算）

4.2 记忆架构设计

4.2.1 认知科学的启发

长期记忆-存储持久知识;短期记忆-负责当前任务,主要快速读取

4.2.2 LLM三层记忆建模

粒度进一步细化,将记忆系统规划为三层

1. 参数化记忆（隐性记忆）：通过训练或微调固化在模型权重中的知识。读取极快，但写入成本极高（类似人类的肌肉记忆）。可以进一步分为“内置参数记忆”（出厂权重）和“外置参数记忆”（随用户交互动态低秩更新的偏好与事实）。
2. 激活记忆（暂态记忆）：例如推理过程中产生的高速 KV Cache。它暂存在显存中，读写速度居中，用于维持当前对话的极速响应，随时可丢弃或常驻。（按 MemOS 论文的口径，KV Cache 与隐藏状态同属隐式记忆。）
3. 明文记忆（显性外部记忆）：可显式读取的外部存储（如知识库）。按常规检索逻辑维护，容量大、更新灵活，但需要重新编码和上下文拼接计算。

工作记忆

短期记忆:对话历史

维持当前对话(Session)的连贯性,最经典恶的形态就是对话历史(Conversation history),存在问题:

• 存储介质:存在Redis等内存数据库中,Session ID为键隔离
• 生命周期:随会话开始而建立,随着会话超时或者显式结束而销毁/持久化
• 上下文注入:通常采用FIFO和滑动窗口的形式注入上下文

长期记忆与类操作系统管理

将上下文窗口视为主内存,外部存储视为磁盘

• 显存分页:系统在主存和磁盘之间主动交换数据
• 中断机制:上下文占满触发"内存管理中断"
• 读写接口:通过特定的工具调用(API)来读写外部记忆

4.2.3 语义记忆与情景记忆

长期记忆可以进一步划分为:

语义记忆

存储抽象的事实和概念,不依赖于特定事件 应用实例: 用户偏好;领域知识;规则约束 实现方式: 结构化存储中的事实表 向量数据库中的知识片段 知识图谱中的实体和关系

情景记忆

存储具体的事件和经历,包括时间,地点等上下文 应用实例: 历史对话;操作记录;问题解决 实现方式: 时序数据库中的事件记录 带时间戳的向量存储 检索时考虑时间相关性

4.2.4 工程落地的五层记忆结构

1. 存储层（Storage）：为各类记忆量身定制存储媒介（如图+向量混合存储），解决高效共享与持久化。
2. 治理层（Governance）：保障记忆的安全与一致性。包括全生命周期管理、幻觉评估、版本控制、权限与隐私隔离等。
3. 调度层（Scheduling）：记忆系统的内核。通过动态行为预测与预加载，将所需记忆在任务前就置于“就绪（Ready）”状态，确保最佳读写效率。
4. 应用层（Application）：把复杂的记忆操作流程对开发者完全屏蔽，提供标准 API 服务（如 Memory-as-a-Service）。
5. 解码层（Decoding）：大模型结合已调度的记忆上下文进行最终的推理生成。

4.2.5 记忆框架设计实践

设计原则:

1. 分层分离:不同类型的记忆使用不同的存储策略
2. 访问效率:热数据快速访问,冷数据按需加载
3. 一致性保证:确保记忆内容不互相矛盾
4. 隐私保护:敏感信息需要特殊处理

4.2.6 记忆管理机制

记忆提取

决定从长期记忆中提取什么内容到工作记忆：

• 基于语义相似度（Retrieve）
• 基于时间相关性（Recency）
• 基于重要性评分（Importance）- 重要信息优先保留
• 组合多种条件

记忆巩固

决定将工作记忆中的什么内容写入长期记忆：

• 显式保存：用户明确要求记住
• 重要性判断：自动识别重要信息（如 Reflection 机制）
• 摘要压缩：提取关键内容存储
• 定期回顾：对已有记忆进行整理

记忆遗忘

管理长期记忆的容量和时效：

• 遗忘曲线：模拟人类遗忘规律，随时间降低记忆权重
• 使用频率（LRU）：不常用的记忆优先淘汰
• 主动清理：按策略删除过时信息

4.2.7 记忆架构的挑战

一致性问题:

信息更新后,如何保证相关记忆保持一致

相关性问题:

如何判断相关性

规模问题

检索效率和存储成本如何控制

安全问题

如何保护敏感信息不被不当访问或者泄露

4.2.8 案例：从“记忆存储”到“持续状态维护”

上述挑战在近期的开源项目中开始出现系统性的工程解法。以 Supermemory 为代表的新一代记忆框架，将记忆问题从 信息检索 重新定义为 持续状态维护，在架构层面回应了一致性、相关性和规模三大挑战。

三层架构设计

Supermemory 的架构可以映射为三个协作层：

层次

职责

对应本节概念

记忆引擎

从对话中抽取事实，处理时间变化、矛盾和自动遗忘

记忆巩固 + 记忆遗忘

用户画像

维护 static（长期稳定事实）和 dynamic（近期上下文）两层画像

语义记忆 + 情景记忆

外部连接器

实时同步 Google Drive、Notion、GitHub 等外部源

记忆提取的扩展

这种分层的关键洞察在于：个性化任务中最常见的错误不是“检索不到”，而是系统不区分长期偏好与临时状态。将 static 和 dynamic 拆开，既提升命中率，也减少注入上下文窗口的噪声。

状态维护 vs 文本存储

传统做法是将对话原文存入向量数据库，依赖语义相似度召回。这种方式在处理时间维度的事实冲突时存在结构性缺陷——旧事实和新事实的嵌入向量语义相似度几乎相同，系统无法自动判断哪个应该失效。

Supermemory 的做法是：不存原文，而是抽取事实并管理状态。当用户说“我刚搬到旧金山”时，系统不是简单地新增一条记录，而是识别出这与“我住在纽约”存在冲突，自动执行覆盖。这种机制直接回应了 4.2.7 中提到的一致性问题。

混合检索：知识与记忆的统一查询

另一个值得借鉴的设计是将记忆检索与文档检索合并为单次混合查询。传统架构中，用户记忆和知识库是两套独立系统，导致“能找到技术文档但不知道用户偏好哪种方案”的割裂。混合检索让每次回答都能同时基于外部知识和用户上下文，是上下文完整度的显著提升。

统一语义层

Supermemory 通过多模态抽取器（PDF 解析、图片 OCR、视频转写、代码 AST 感知分块）将异构来源统一进入同一个记忆结构和本体。这解决了许多系统中“来源异构导致跨源召回错配”的问题——聊天、文件、代码、邮件各存各的，检索时上下文不统一。

设计启示：记忆系统的效果上限，往往不取决于检索算法的优劣，而取决于 目标函数是否准确。多数系统默认优化语义相似度，但长期记忆场景真正需要优化的是更新正确性、时间正确性、冲突消解和噪声抑制。

4.3 知识库构建与管理

4.3.1 知识库的定义与价值

知识库 是组织化的信息集合，专门用于为 AI 系统提供领域知识支持。与通用存储不同，知识库经过精心设计和优化，以支持高效的知识检索和利用。

知识库的核心价值：

• 弥补模型知识空白：提供模型训练数据中没有的信息
• 保证信息时效性：包含最新的事实和数据
• 实现领域深度：提供特定领域的专业知识
• 确保信息权威性：使用经过验证的可靠来源

4.3.2 知识库的类型

文档知识库

存储非结构化文档内容,是最常见的知识库形式

• 内容：产品文档、技术手册、FAQ、博客文章
• 处理：文档解析 → 分块 → 向量化 → 索引
• 检索：基于语义相似度检索相关片段

结构化知识库

存储结构化数据,支持精确查询

• 内容：产品数据库、用户信息、配置数据
• 处理：数据建模 → Schema 设计 → 索引优化
• 检索：SQL 查询或结构化 API

知识图谱

存储实体及其关系,支持关系推理

• 内容:实体,属性,关系三元组
• 处理:实体提取-关系抽取-图构建
• 检索:图遍历.路径查询

4.3.3 知识库构建流程

阶段一:数据收集

收集构建知识库的原始数据：

• 内部文档：产品文档、技术规范、内部知识库
• 外部资源：公开文档、API 文档、行业标准
• 生成内容：FAQ 整理、知识提炼

数据收集注意事项：

• 确保数据来源可靠
• 清晰的版权和使用授权
• 记录数据来源和更新时间

阶段二:数据处理

将原始数据转换为可用格式：

文档解析

• PDF 提取：表格、图片、文本
• 网页清洗：移除广告和导航
• 格式标准化：统一为 Markdown 或纯文本

文本分块 (Text Chunking)

分块策略直接决定了检索的粒度和质量（关于分块策略的详细讨论请参见 5.2 文档分块策略）。常用的三种分块策略包括：

1. 固定大小分块 (Fixed-size Chunking)：设定固定的 Token 数量切分，简单快速但可能破坏语义。
2. 递归字符分块 (Recursive Character Chunking)：使用一组分隔符按优先级递归切分，较好保持段落和句子完整性，是大多数场景的首选。
3. 语义分块 (Semantic Chunking)：利用嵌入模型计算语义相似度进行话题转换切分，精度高但计算成本大。

元数据标注

• 来源标记
• 时间戳
• 分类标签
• 重要性权重

阶段三:向量化和索引化

转化为可检索形式

嵌入生成

• 选择合适的嵌入模型
• 批量处理提高效率
• 考虑多语言支持

索引构建

• 向量索引：HNSW、IVF 等算法
• 倒排索引：支持关键词检索
• 混合索引：结合多种方法

阶段四:质量验证

验证知识库的质量：

• 检索测试：验证典型查询的检索效果
• 覆盖测试：确认关键知识都被包含
• 准确性测试：抽样验证内容正确性

4.3.4 知识库维护

4.3.5 多源知识整合

整合挑战：

• 格式统一：不同来源的内容格式不同
• 优先级管理：来源之间可能有冲突
• 一致性维护：保持信息的一致性

整合策略：

• 建立统一的检索接口
• 定义清晰的优先级规则
• 实现冲突检测和处理机制

4.3.6 知识库最佳实践

1. 从核心开始

先覆盖最常用、最重要的知识。不要试图一开始就构建一个包罗万象的知识库，而是识别用户最频繁查询的问题和场景，优先确保这些核心内容的质量和覆盖度。核心知识往往只占全部内容的一小部分，却能覆盖大部分高频查询需求。

2. 质量优先

高质量的小知识库胜过低质量的大知识库。每一条进入知识库的内容都应经过审核：信息是否准确？表述是否清晰？是否有歧义？低质量内容不仅无法帮助用户，还会降低整个系统的可信度，导致模型生成错误或矛盾的回答。

3. 持续迭代

基于实际使用反馈不断改进。知识库构建不是一次性项目，而是持续演进的过程。收集用户的查询日志，分析哪些问题检索失败或答案不满意，针对性地补充和优化内容。每一次用户交互都是改进知识库的机会。

4. 版本管理

维护知识库的版本历史。与代码库一样，知识库也需要版本控制。这样可以追踪内容变更、回滚错误更新、对比不同版本的效果。对于企业知识库，版本管理还有助于合规审计和问题追溯。

5. 监控使用

跟踪知识库的使用情况和效果。建立关键指标：检索成功率、用户满意度、知识覆盖度等。定期分析这些指标，发现知识空白和质量问题。数据驱动的优化比主观判断更有效。

4.4 向量数据库实践

4.4.1 向量数据库概述

向量数据库 是专门优化用于存储和检索高维向量的数据库系统。在上下文工程中，向量数据库是实现语义检索的核心基础设施。

工作原理：

1. 将文本通过嵌入模型转换为向量（详见 5.3 嵌入模型与语义搜索）
2. 将向量存储到向量数据库
3. 查询时，将查询文本也转换为向量
4. 在数据库中搜索最相似的向量
5. 返回对应的原始文本

4.4.2 主流向量数据库对比

4.4.3 向量检索算法

核心:近似最近邻搜索(Approximate Nearest Neighbor, ANN) 在牺牲极小精度的情况下,换取检索速度的指数级提升 下面是三种算法详解:

1.HNSW

HNSW（Hierarchical Navigable Small World，分层可导航小世界图）是目前综合性能最强的近似最近邻索引之一，结合了“小世界网络”和“分层结构”的思想。

原理机制： 想象一个多层的交通网络：

• 顶层（高速公路）：节点稀疏，连接跨度大，用于快速逼近目标区域。
• 中间层（主干道）：节点较多，连接跨度适中，用于缩小搜索范围。
• 底层（街道）：包含所有节点，连接密集，用于精确定位目标。

搜索过程：

1. 从顶层的一个入口节点开始。
2. 在当前层贪婪地寻找距离目标最近的节点。
3. 找到该层最近点后，“降落”到下一层对应的节点。
4. 重复步骤 2-3，直到到达底层（第 0 层）。
5. 在底层进行最终的精细搜索，找到最近邻。

特点：

• 优点：检索速度极快，查全率（Recall）高，对高维数据适应性好。
• 缺点：构建索引慢，且需要将整个图结构加载到内存，内存消耗大。
• 关键参数：
  • M：每个节点的最大连接数（邻居数）。M 越大图越密，搜索质量越高但内存消耗越大。
  • efConstruction：构建索引时的搜索深度。值越大索引质量越好，但构建越慢。
  • efSearch：查询时的搜索深度。值越大召回率越高，但查询延迟增加。

HNSW（Hierarchical Navigable Small World，分层可导航小世界图）是目前综合性能最强的近似最近邻索引之一，结合了“小世界网络”和“分层结构”的思想。

原理机制： 想象一个多层的交通网络：

• 顶层（高速公路）：节点稀疏，连接跨度大，用于快速逼近目标区域。
• 中间层（主干道）：节点较多，连接跨度适中，用于缩小搜索范围。
• 底层（街道）：包含所有节点，连接密集，用于精确定位目标。

搜索过程：

1. 从顶层的一个入口节点开始。
2. 在当前层贪婪地寻找距离目标最近的节点。
3. 找到该层最近点后，“降落”到下一层对应的节点。
4. 重复步骤 2-3，直到到达底层（第 0 层）。
5. 在底层进行最终的精细搜索，找到最近邻。

特点：

• 优点：检索速度极快，查全率（Recall）高，对高维数据适应性好。
• 缺点：构建索引慢，且需要将整个图结构加载到内存，内存消耗大。
• 关键参数：
  • M：每个节点的最大连接数（邻居数）。M 越大图越密，搜索质量越高但内存消耗越大。
  • efConstruction：构建索引时的搜索深度。值越大索引质量越好，但构建越慢。
  • efSearch：查询时的搜索深度。值越大召回率越高，但查询延迟增加。

2.IVF

IVF（Inverted File Index，倒排文件索引）是一种基于聚类的倒排索引方法，类似于将数据分桶存储。

原理机制：

1. 训练阶段：使用聚类算法（如 K-means）将向量空间划分为 nlist 个聚类中心（Voronoi 单元）。
2. 索引阶段：将每个向量分配到距离其最近的聚类中心，归入对应的倒排链中。
3. 查询阶段：
   • 粗搜（Coarse Quantizer）：先计算查询向量与所有聚类中心的距离，找到最近的 nprobe 个聚类中心。
   • 精搜：仅在选中的这几个聚类对应的倒排链中进行遍历搜索，忽略其他无关数据。

特点：

• 优点：大大减少了搜索范围，支持增量更新，内存占用相对较低。
• 缺点：位于边界处的点可能被漏掉（通过增加 nprobe 缓解）。
• 关键参数：
  • nlist：聚类中心的数量。
  • nprobe：查询时扫描的聚类数量。nprobe 越大，精度越高，速度越慢。

3.PQ

PQ（Product Quantization，乘积量化）是一种有损压缩技术，主要用于解决内存占用问题。

原理机制：

1. 切分：将高维向量（如 128 维）切分为 $M$ 个子向量（如 8 个 16 维的子向量）。
2. 聚类：对每个子空间分别进行 K-means 聚类（例如每个子空间聚成 256 类）。
3. 量化：将每个子向量替换为它所属聚类中心的 ID（只需 1 byte）。
4. 压缩：原始 128 浮点数向量（512 bytes）被压缩为 8 个 ID（8 bytes），压缩比高达 64x。
5. 查询：查询时，预先计算查询向量各子段与各聚类中心的距离表，通过查表快速计算近似距离。

特点：

• 优点：极大地降低内存占用（通常可达几十倍压缩），使得单机可处理十亿级数据。
• 缺点：距离计算是近似值，存在精度损失。通常与 IVF 结合使用（IVF-PQ）以从海量数据中快速筛选。

4.4.4 向量数据库使用实践

嵌入模型选择

选择考虑：

• 质量需求
• 成本预算
• 是否需要本地部署
• 语言支持

文档分块策略

良好的分块策略直接影响检索效果

分块要点：

• 语义完整性：尽量保持语义单元完整
• 大小适中：通常 200-1000 Token
• 适当重叠：防止信息断裂
• 保留元数据：来源、章节、时间等

检索优化:

提升检索效果的实用技术

混合检索:

结合向量搜索和关键词搜索：

1

最终得分 = α × 语义得分 + (1-α) × 关键词得分

元数据过滤:

先按元数据过滤，再在子集中向量搜索：

• 按时间范围过滤
• 按类别过滤
• 按来源过滤

重排序

对初步检索结果进行二次排序：

• 使用专门的重排序模型
• 考虑更多上下文因素

4.4.5 实际部署考量

性能优化

• 批量操作：批量写入和批量查询
• 缓存策略：缓存热点查询结果
• 索引预热：提前加载索引到内存

扩展性

• 分片策略：数据量大时的分片方案
• 副本配置：高可用和读扩展
• 容量规划：预估存储和计算需求

成本控制

• 向量维度：较小的维度降低存储和计算成本
• 压缩技术：使用量化减少存储
• 冷热分离：不常用数据使用低成本存储

4.4.6 常见问题处理

1. 检索结果不相关

通常是由于语义偏差或分块不当导致。

• 解决方案：
  • 检查嵌入模型是否适合当前领域的专有名词。
  • 优化分块策略，增加块之间的重叠，或尝试父子文档索引。
  • 引入混合检索（Hybrid Search），结合关键词匹配来纠正语义漂移。
  • 添加重排序（Reranking）步骤，使用高精度模型对召回结果进行二次筛选。

2. 检索延迟过高

随着数据量增长，暴力搜索变得不可接受。

• 解决方案：
  • 调整索引参数，如 HNSW 的 efSearch，在精度和速度间寻找平衡。
  • 使用更高效的索引算法，或者开启量化（如 SQ8, PQ）以减少内存占用和计算量。
  • 考虑硬件升级，使用 GPU 加速索引或查询。
  • 实现分片（Sharding），将数据分布到多台机器并行查询。

3. 更新导致不一致

向量更新滞后于源数据更新。

• 解决方案：
  • 实现实时增量更新机制，源数据变更立即触发嵌入更新。
  • 设计合理的版本控制策略，在重建索引期间保留旧版本查询。
  • 定期全量重建索引，以消除增量更新产生的碎片，优化索引结构。

本章小结:

本章深入探讨了上下文工程的写入策略，涵盖外部存储、记忆架构、知识库构建和向量数据库实践。

关键概念清单

核心观点

1. 外部存储是必需的：上下文窗口有限，复杂应用需要外部存储支持持久记忆和大规模知识
2. 记忆架构应分层设计：
   • 工作记忆：上下文窗口
   • 短期记忆：会话级别
   • 长期记忆：跨会话持久化
3. 知识库构建是系统工程：
   • 数据收集 → 处理 → 向量化 → 质量验证
   • 需要持续维护更新
4. 向量数据库是语义检索的核心：
   • 选择合适的嵌入模型和索引算法
   • 优化分块策略和检索流程

常见误区

• 误区一：直接用传统数据库存储知识 正解：语义检索需要向量数据库支持
• 误区二：知识库越大越好 正解：质量比数量更重要，噪声会降低效果
• 误区三：向量数据库可以替代其他存储 正解：不同类型数据需要不同存储方案
• 误区四：构建一次就完成了 正解：知识库需要持续维护和更新

实践建议

1. 从简单开始：先用简单方案验证可行性，再逐步优化
2. 关注分块质量：分块策略对检索效果影响巨大
3. 选择合适工具：根据规模和需求选择向量数据库
4. 建立评估机制：持续监控检索质量和系统性能
5. 规划维护流程：设计知识库的更新和维护机制

6.1.1 信息密度的概念

信息密度是指单位Token中包含的有效信息量.高密度意味着最少的token传达更多有价值的内容

1

信息密度= 有效信息量/token数量

信息密度对于上下文工程的影响:

• 容量利用:更高上下文窗口的利用率
• 成本效率:更低的token成本
• 处理效率:更快的响应速度

6.1.2 信息的冗余与噪声

上下文中的低效内容主要来自于两个方面:

冗余信息

• 重复表达相同含义
• 过渡性词汇和填充语
• 不必要的修饰和解释

噪声信息

• 于任务无关的信息
• 过时或错误的信息
• 格式化符号和无意义标记

6.1.3 压缩的基本原则

原则一:信息保真 不能损失关键信息,是提炼精华而非截断

原则二:任务导向 根据当前任务决定保留什么

原则三:可理解性 压缩结果应该把持连贯,让模型能够理解和使用

6.1.4 压缩技术分类

6.1.5 压缩与质量的权衡

压缩率 vs 信息完整度 高压缩率:节省空间但细节丢失 低压缩率:占用过多上下文

通用性 vs 针对性 通用压缩:一次压缩多次复用 针对性压缩:针对具体任务定制

成本 vs 效果 简单压缩(如截断):成本低但效果差 高级压缩(如LLM摘要):效果好但是需要额外成本

6.1.6 何时需要压缩

以下场景: 1.上下文接近容量上限 2.成本敏感场景 3.延迟敏感场景 4.对话历史过长 5.检索结果过多

6.1.7 压缩比与质量损失对比

压缩率越高，信息损失风险越大。下图展示了不同压缩比对问答准确率影响的 示意趋势

6.1.8 压缩效果评估

评估压缩效果需要考虑:

直接指标

• 压缩率：1 − 压缩后大小 / 原始大小，即削减掉的比例（压缩率越高＝压得越狠）。注意不要写成「压缩后/原始」，那是保留率，方向相反
• Token 减少量：压缩前后 Token 数量差异

间接指标:

• 任务效果：压缩后任务完成质量
• 信息保留率：关键信息的覆盖程度

6.2 摘要和信息提取

6.2.1 抽取式方法

从原文选择重要句子或者段落,保持原文描述

关键句提取:

根据句子的重要性选择关键句

TextRank算法: 借鉴 PageRank 思想，根据句子之间的相似度构建图，计算每个句子的中心性分数

基于嵌入的方法:

1. 计算每个句子的嵌入向量
2. 计算句子与文档整体的相似度
3. 选择相似度最高的句子

关键片段提取

抽取包含关键信息的文本片段

• 包含实体的句子
• 包含数组和日期的句子
• 定义行语句

抽取式方法的优缺点

1
2
3
4
5
6
7
8
9

优点：
- 保持原文表述，准确性高
- 计算成本相对较低
- 可追溯到原文

缺点：
- 可能不够连贯
- 无法重组或精简表达
- 受限于原文的表述质量

6.2.2 生成式方法

使用语言模型生成新的精简表述

大语言模型摘要

直接使用LLM生成摘要

1
2

请将以下内容总结为不超过 200 字的摘要，保留关键信息：
[原始内容]

技巧:

• 明确指定输出长度
• 指明需要保留的信息类型
• 提供输出格式要求

递进式摘要

对于超长文档,采取递进压缩

递进式摘要流程:

1. 将文档分为多个段落
2. 分别生成段落摘要
3. 合并段落摘要
4. 可选:对合并结果再次摘要

多级摘要

生成式方法的优缺点

1
2
3
4
5
6
7
8
9

优点：
- 表述更连贯流畅
- 能够重组和精简
- 可按需定制输出

缺点：
- 可能引入新的错误
- 需要额外的 LLM 调用成本
- 可追溯性较弱

6.2.3 信息提取

从文本中提取结构化信息

实体提取

提取关键实体:人名.地名,时间,数值等等

1
2
3
4
5
6

输入：2026年3月，张三在北京发布了新产品，售价1999元。
输出：
- 人物：张三
- 地点：北京
- 时间：2026年3月
- 价格：1999元

关系提取

1
2
3
4

输入：李四是A公司的CEO，该公司总部位于上海。
输出：
- (李四, 职位, A公司CEO)
- (A公司, 总部, 上海)

事实提取

提取关键事实点

1
2
3
4
5

输入：[长篇报告...]
输出：
1. 2025年营收增长15%
2. 新增用户100万
3. 计划明年进入欧洲市场

6.2.4 最佳实践

1. 根据场景选择方法

不同的压缩方法适合不同场景，选错方法会导致效果大打折扣。需要精确引用原文（如法律、医疗场景）时使用抽取式，保证信息准确；需要流畅表达（如给用户的摘要）时使用生成式；需要结构化处理（如数据分析）时使用信息提取。常见错误是不加区分地使用同一种方法，导致需要引用时找不到原文，需要连贯时读起来支离破碎。

2. 组合使用多种方法

单一方法往往难以兼顾多个目标，组合使用能发挥各自优势。典型模式是：先用抽取式选出关键段落，再用生成式整合为连贯摘要；或者生成摘要的同时，附上结构化的关键事实列表。这样既保证信息的可追溯性，又提供流畅的阅读体验。组合时注意控制总长度，避免压缩后反而变长。

3. 保留元信息以便追溯

压缩后的内容应该能追溯到原始来源。记录摘要来自哪份文档、第几页或第几段；标注使用的压缩方法（抽取/生成/提取）和生成时间。这些元信息在调试问题时非常有价值——当输出不准确时，可以快速定位是原始数据问题还是压缩过程引入的偏差。元信息的存储成本很低，但排查问题时能节省大量时间。

4. 建立质量验证机制

压缩必然带来信息损失，需要验证损失是否在可接受范围内。建立定期抽样检查机制，人工对比压缩前后的内容，评估关键信息是否保留。更重要的是对比压缩前后的任务效果——如果压缩后模型的回答质量明显下降，说明压缩过度或方法不当。用 A/B 测试量化压缩对最终效果的影响，找到压缩率与质量的最佳平衡点。

5. 多智能体场景下的上下文压缩与持久化执行

在企业级多智能体系统中，上下文累积特别容易超出限制。实践中常见的模式是 两部分编排（Two-Part Orchestration）：

• 初始化智能体（Initializer Agent）：接收用户的原始需求，进行查询理解、计划分解，并生成对下游智能体的结构化指令和压缩后的上下文
• 编码智能体（Coding/Execution Agent）：专注于具体任务执行，工作上下文已被精心构建和压缩，避免冗余信息导致的上下文爆炸

持久化执行与状态恢复（Durable Execution Pattern）：

为了在长时间运行的智能体流程中提高可靠性，应该采取：

1. 步骤化执行：将长任务分解为原子性的步骤，每步生成可持久化的输出（Step Artifacts）
2. 检查点保存：在完成关键步骤后保存完整的执行状态，包括输入、中间结果、输出和元数据
3. 失败恢复：如果执行中断（网络问题、模型超时等），可以从最后一个成功的检查点重新开始，而不需要重新计算前面的步骤
4. 可重放验证：使用保存的工件重新执行同样的操作，验证结果的确定性和一致性

这种模式特别适合批量处理、数据管道或需要跨多个 API 调用的复杂工作流，既提高了成功率，也降低了因重复计算导致的成本浪费。

6.3 对话历史管理

6.3.1 对话历史的挑战

• 上下文膨胀
• 信息稀释
• 成本积累
• 性能下降

6.3.2 对话历史管理策略

滑动窗口

只保留最近N轮对话

**优点:**简单直接,容易实现 缺点:可能丢失重要的早期信息

参数调优:

• 窗口的大小取决于任务特性
• 简单问答2-5;复杂任务:5-10

选择性保留

根据重要性选择保留哪些历史

重要性判断依据:

• 包含任务关键信息
• 用户明确要求记住的内容
• 定义了重要约束或者偏好
• 最近的交互

实现方式: 规则标记:基于关键词或者模式 模型判断:让LLM判断

对话压缩

将冗长的对话历史压缩为摘要 即时压缩:每轮对话之后立即压缩

批量压缩:达到阈值之后批量压缩较早的历史

递进压缩:按照时间距离采取不同压缩级别: 最近(1-3轮):完整保留 近期(4-10轮):轻度压缩 早期(10轮以上):重度压缩

分层管理:

6.3.4 上下文拼接策略

整合不同来源的历史信息：

复制

1
2
3
4
5

[系统提示词]
[用户画像/偏好]（从长期记忆）
[会话摘要]（早期历史的压缩）
[最近对话]（保留原文）
[当前问题]

6.3.5 最佳实践

1. 结合多种策略构建历史管理体系

单一策略难以应对复杂场景，推荐组合使用：滑动窗口保留最近的完整对话；压缩技术处理较早的历史；重要信息提取确保关键约束不丢失。例如：保留最近 5 轮原文 + 早期历史压缩摘要 + 提取的用户偏好列表。这种分层策略在控制上下文长度的同时，最大化保留有价值的信息。根据任务特点调整各层的比例。

2. 始终保留关键锚点信息

用户明确表达的约束和要求是“锚点”，必须始终保留在上下文中。例如：“请用简体中文回复”、“预算不超过 5000 元”、“不要推荐海鲜”。这些信息一旦丢失，模型会给出违背用户意愿的回答，严重影响体验。实现时可以用特殊标记标识锚点信息，确保压缩过程不会删除它们。宁可多保留一些锚点，也不要冒丢失关键约束的风险。

3. 确保压缩后内容的自然过渡

压缩后的摘要应该与当前对话自然衔接，避免风格突兀。使用第一人称还是第三人称？是口语化还是正式表达？压缩摘要的风格应与原始对话保持一致。突兀的风格切换会让模型“困惑”，影响后续生成质量。在压缩提示词中明确要求保持风格一致，必要时提供示例。

4. 保持完整历史的可恢复性

虽然在上下文中使用压缩版本，但完整的对话历史应该保存在持久化存储中。这样在需要时可以回溯——例如用户投诉某次回答不当，需要完整上下文来分析原因；或者用户要求“回到之前讨论的那个方案”，需要恢复详细信息。将完整历史与压缩版本关联存储，建立索引便于快速检索。

5. 持续监控压缩对对话质量的影响

压缩策略不是设置后就不管的“一次性配置”，需要持续监控效果。观察指标包括：用户是否需要重复说过的信息？模型是否遗忘了早期约束？对话连贯性如何？建立反馈机制，当检测到质量下降时自动调整压缩参数。定期审查压缩效果，随着对话模式变化优化策略。

6.3.6 实战案例：电商客服对话管理（示意）

以下示例用于说明一种对话历史管理的实现思路，生产环境需根据并发、权限、合规与成本要求进行改造。

场景描述

用户咨询退换货，对话可能持续 20+ 轮，涉及订单查询、问题确认、方案协商等多个阶段。

完整实现

复制

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139

from dataclasses import dataclass, asdict
from typing import List, Optional
import json
import sqlite3

@dataclass
class Message:
    role: str  # "user" 或 "assistant"
    content: str
    is_anchor: bool = False  # 是否为锚点信息

    def to_dict(self):
        return asdict(self)

    @staticmethod
    def from_dict(data):
        return Message(**data)

class ConversationManager:
    def __init__(self, session_id: str, db_path="chat.db", max_recent=5):
        self.session_id = session_id
        self.db_path = db_path
        self.messages: List[Message] = []
        self.anchors: List[str] = []
        self.summary: str = ""
        self.max_recent = max_recent
        self._init_db()
        self.load_history()

    def _init_db(self):
        """初始化 SQLite 数据库表结构"""
        with sqlite3.connect(self.db_path) as conn:
            conn.execute("""
                CREATE TABLE IF NOT EXISTS sessions (
                    session_id TEXT PRIMARY KEY,
                    summary TEXT,
                    anchors TEXT,
                    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
                )
            """)
            conn.execute("""
                CREATE TABLE IF NOT EXISTS messages (
                    id INTEGER PRIMARY KEY AUTOINCREMENT,
                    session_id TEXT,
                    role TEXT,
                    content TEXT,
                    is_anchor BOOLEAN,
                    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
                    FOREIGN KEY(session_id) REFERENCES sessions(session_id)
                )
            """)

    def load_history(self):
        """从数据库加载历史"""
        with sqlite3.connect(self.db_path) as conn:
            # 加载会话元数据（摘要和锚点）
            cursor = conn.execute(
                "SELECT summary, anchors FROM sessions WHERE session_id = ?",
                (self.session_id,)
            )
            row = cursor.fetchone()
            if row:
                self.summary = row[0]
                self.anchors = json.loads(row[1]) if row[1] else []

            # 加载最近的消息
            # 注意：实际生产中可能只需要加载最近 N 条，早期的已压缩
            cursor = conn.execute(
                """
                SELECT role, content, is_anchor FROM messages
                WHERE session_id = ?
                ORDER BY id ASC
                """,
                (self.session_id,)
            )
            self.messages = [Message(*r) for r in cursor.fetchall()]

    def save_snapshot(self):
        """保存当前状态到数据库"""
        with sqlite3.connect(self.db_path) as conn:
            # 更新会话元数据
            conn.execute(
                """
                INSERT OR REPLACE INTO sessions (session_id, summary, anchors)
                VALUES (?, ?, ?)
                """,
                (self.session_id, self.summary, json.dumps(self.anchors))
            )

            # 简单的全量保存（生产环境应改为增量保存）
            conn.execute("DELETE FROM messages WHERE session_id = ?", (self.session_id,))
            for msg in self.messages:
                conn.execute(
                    """
                    INSERT INTO messages (session_id, role, content, is_anchor)
                    VALUES (?, ?, ?, ?)
                    """,
                    (self.session_id, msg.role, msg.content, msg.is_anchor)
                )

    def add_message(self, role: str, content: str):
        is_anchor = self._detect_anchor(content)
        msg = Message(role, content, is_anchor)
        self.messages.append(msg)

        if is_anchor:
            self.anchors.append(content)

        # 实时保存（或采用异步批量保存）
        self.save_snapshot()

        # 触发压缩检查
        if len(self.messages) > self.max_recent * 2:
            self._compress_history()
            self.save_snapshot() # 压缩后再次保存更新状态

    def _detect_anchor(self, content: str) -> bool:
        anchor_patterns = ["订单号", "手机号", "必须", "预算"]
        return any(p in content for p in anchor_patterns)

    def _compress_history(self):
        """将较早的非锚点消息折叠进摘要，只保留最近消息"""
        old, recent = self.messages[:-self.max_recent], self.messages[-self.max_recent:]
        if not old:
            return
        # 教学示例用截断拼接；生产中应调用 LLM 生成语义摘要，
        # 并将旧消息归档到冷存储而非直接丢弃
        digest = "；".join(f"{m.role}: {m.content[:40]}" for m in old if not m.is_anchor)
        if digest:
            self.summary = f"{self.summary}\n{digest}" if self.summary else digest
        self.messages = recent

    def build_context(self) -> str:
        parts = []
        if self.anchors: parts.append("【关键约束】\n" + "\n".join(f"- {a}" for a in self.anchors))
        if self.summary: parts.append(f"【历史摘要】\n{self.summary}")
        recent = "\n".join([f"{m.role}: {m.content}" for m in self.messages[-self.max_recent:]])
        parts.append(f"【最近对话】\n{recent}")
        return "\n\n".join(parts)

实际效果

20 轮对话后的上下文示例：

复制

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

【关键约束】
- 订单号：2024010512345
- 不接受换货，只要退款
- 必须今天处理完

【历史摘要】
用户购买的蓝牙耳机存在左耳无声问题，已确认在保修期内。
用户尝试过重置配对但未解决。客服已记录问题，准备发起退款。

【最近对话】
user: 退款多久到账？
assistant: 审核通过后3-5个工作日到账。
user: 太慢了，能加快吗？
assistant: 我帮您申请加急处理，预计1-2个工作日。
user: 好的，那就这样吧。

踩坑经验

1. 订单号必须作为锚点 — 曾因压缩丢失订单号，导致后续无法查询，用户需要重复提供
2. 用户情绪需要记录 — “用户表达了不满”这类信息应保留，影响后续安抚策略
3. 压缩时机要对 — 不要在用户等待回复时压缩，会增加延迟；应在对话间隙异步执行
4. 保留否定约束 — “不要推荐 X”比“推荐 Y”更容易被压缩丢失，需特殊标记

6.4 上下文窗口优化策略

6.4.1 Token估计和上下文预算管理

精确的Token估计是上下文预算管理的基础

Token计数策略:

• 精确计数:使用上次API调用返回的input_token值作为基准
• 粗估计: 使用"字符数/经验系数"进行估计,但是中文,代码,JSON和不同的tokenizer差别很大
• 输出预留:按任务期望输出,模型Max+tkones和上下文窗口保留缓冲,避免填满窗口导致截断或者停止
• 跨版本迁移注意:从旧版本切换到新版本,由于tokenzier的不同,需要重新估算

上下文窗口分辨率优先级

需要模型动态确定模式上下文窗口大小时,系统往往采取优先级链

1. 模型能力查询:优先读取供应商模型元数据,token counting API等等配置
2. 显式应用配置:按照模型ID,区域,账号层级和beta flag固化允许的上下文
3. 请求/响应能力信号:某些API会通过beta header,错误码或者响应元数据暴露可用接口
4. 模型名称标记:只能作为复制提示,不能把后缀当成权威来源
5. 保守默认值:无法确定时应Fail closed,要求显式配置,而不是假设200k或者1m

预算分配

为不同的组成部分预先分配不同的token预算

结合实际任务进行动态调整

动态调整

知识密集任务:增加检索内容预算 多轮对话任务:增加对话历史预算 长文生成任务:增加输出预留预算

6.4.2 系统提示词优化(可以看看O/最新的文章)

system prompt是最稳定的上下文部分,应该尽量的精简

精简策略

删除冗余:

• 删除重复说明;合并相似指令;使用简介表达

结构化表达:

• 使用列表代替段落;使用表格组织规则;使用编号易于引用

模板复用:

• 将通用部分模板化;动态部分参数化;条件加载可选内容

提示词压缩技术

人工精简: 最直接最有效(存疑)

LLM辅助压缩: 让模型帮助精简

符号化表达: 用简洁符号代替冗长说明

1
2

原文：如果用户没有明确指定格式，请使用 Markdown 格式输出
精简：默认格式=Markdown

6.4.3 检索内容占用优化

精确检索

• 提高精度;使用重排序过滤低相关结果;使用置信度阈值截断结果

检索后压缩

对检索结果进行二次压缩

• 提取与查询相关的字段
• 生成针对性摘要
• 合并重复信息

渐进式检索

按需检索

1. 先用少量关键信息回答
2. 如果需要更多的关键信息再检索
3. 避免预防性的大量检索(但是貌似有一个检索策略是预加载,比如滑动窗口会加载相邻的内容)

6.4.4 格式优化

格式选择影响token效率

结构化格式对比

格式优化建议:

• 非必要不使用嵌套结构
• 属性名尽量简短
• 避免冗长的key名称
• 考虑自定义间接格式

6.4.5 KV缓存压缩技术

在不降低模型能力的情况下,压缩KV缓存体积是实现更长上下文的关键路径

多头隐式注意力(MLA: Multi-head Latent Attention)

DeepSeek-V2/V3采用的MLA将KV Cache压缩到了极致:

• 原始 KV 缓存占用：以 Llama-3.1-405B 为例，单个 Token 需要约 516KB 的 KV 缓存
• MLA 压缩后：每个 Token 的 KV 缓存仅需约 70KB，压缩比约 7 倍
• 实现原理：将 KV 映射到低维隐向量，再按需扩展到多个查询头，既保留了多头注意力的表达能力，又大幅降低显存需求

分组查询注意力(CQA/MQA)

GQA（Grouped Query Attention） 和 MQA（Multi-Query Attention）：多个查询头共享一个或几个 KV 头组，线性降低 KV 缓存体积。

• GQA：8 个查询头共享 1 个 KV 头，KV 缓存减少约 8 倍
• MQA（极端情况）：所有查询头共享单个 KV 头，缓存最小化但精度可能下降
• 权衡：在精度损失与缓存收益间找到最优点，通常 GQA 是最佳选择

KV缓存量化

将 KV 缓存从 FP32 或 BF16 量化到 INT4 或 FP8：

• INT4 量化：降低位宽同时保留关键信息，从 BF16/FP16 量化到 INT4 理论上可将 KV 缓存显存需求降至约 1/4，有效上下文长度可放大约 4 倍
• 实现策略：对 KV 进行分段量化，采用动态范围缩放，降低量化误差
• 成本：推理时需额外的反量化开销，但总体 Token 吞吐仍能提升

6.4.6 缓存和复用

减少重复内容传输和计算

提示词缓存和基础设施级缓存

提示词缓存是优化成本和延迟的最有效的手段之一,而基础设施层面的KV缓存共享技术为系统级优化提供了新的可能性

经济学原理:

• TTL(存活时间):缓存通常拥有较短的生命周期
• 成本不对成性:写入缓存一般比常规输入token更贵,但是读取缓存读比input更便宜

基础设施级缓存:

Radix Attention 在系统级别实现全局 KV 缓存共享，超越单个会话的限制：

• 全局基数树：维护所有历史 KV 缓存的全局 Radix 树，每个节点代表一个 Token 序列的 KV 缓存切片
• 前缀匹配与重用：新请求到达时，系统自动检测其前缀是否在树中存在。若存在完全匹配的前缀（如相同的系统提示词 + RAG 文档），新请求可跳过该前缀部分的 Prefill 计算；新增的后缀（本轮用户输入）仍需 Prefill，之后才进入 Decode 阶段
• 应用场景：系统提示词和 RAG 文档在多个请求间高度重复时，收益最大。客服、内部知识库等场景可能获得较高命中率，但具体比例必须用线上流量验证。

KV 缓存感知路由（KV-Cache-Aware Affinity Routing）

API 网关在接收请求时计算请求前缀的哈希，将其路由到缓存该前缀的 GPU 节点，避免冷启动：

• 哈希映射：对请求的系统提示词 + 前 k 个用户消息计算哈希
• 节点亲和性：根据哈希值选择已缓存该前缀的节点，若无则选择最近空闲的节点
• 成本效益：对于高重复的前缀（RAG 文档、系统提示词），可显著降低 Prefill 计算；具体节省比例取决于请求重复度、缓存生命周期和调度实现。

架构级最佳实践:

为了最大化缓存命中率,系统设计需要严格保持"前缀一致性"

• 使用消息而非修改系统提示词(非纯及坏)
• 延迟加载工具:同样的道理,不要中途加载和删除tools
• 跨模式保持工具稳定:如果系统拥有诸如“计划模式”与“执行模式”，不要在模式切换时尝试通过增删工具列表来加以限制。应保持全量的工具定义始终不变，仅仅通过添加一条普通的前置消息来指示模型改变其行为

各场景的缓存收益分析:

• 复杂系统提示词:避免复杂system prompt的prefill
• 代码补全和生成:避免对未修改的代码进行重复计算
• 文档摘要与问答:最大化缓存复用
• 多轮对话:收益随着对话轮次进行而递增

设计上下文时应始终考虑缓存特性：**将频繁变化的内容（如用户输入、最新检索结果）放在提示词末尾，将稳定内容（如系统提示词、工具定义）放在前部。**这一原则不仅适用于单轮请求，在多轮对话和智能体工作流中同样关键。

基于前缀匹配

预计算(prefill)

对于频繁使用的内容预先计算：

• 预生成摘要并存储
• 检索结果预处理
• 通用模板预填充

6.4.7 监控和调优

监控指标

• token使用分布:各部分占比(system prompt,tool call,tool result,user message)
• 使用效率:有效部分/总token
• 边界情况:接近上限的频率
• 成本追踪

持续优化:

1. 建立基准线
2. 识别最大消耗点
3. 针对性优化
4. 验证效果
5. 持续监控

6.4.8 长任务场景的高级压缩策略

紧凑化技术

Compaction:在上下文窗口接近限制时,对对话内容进行摘要并重新初始化上下文窗口 核心:高保真地提炼上下文窗口地内容,减少质量损失

实现要点:

• 将消息历史传递给模型进行总结和压缩
• 保留决策框架,未解决地问题和实现细节
• 丢弃冗余地消息和工具输出
• 用压缩的上下文加上最近的文件继续工作

分叉操作和缓存复用: 在执行压缩操作时的,一个关键的设计时将压缩请求作为当前对话的"分叉(Fork操作)",在压缩请求钟尽量复用原绘画稳定的系统提示词,知识库和工具定义作为前缀,仅将对话信息部分替换为原消息副本以及"请总结上述对话"的指令消息

压缩的艺术: 保留什么和丢弃什么 是一种上下文细节和上下文空间的trade-off

结构化笔记

定期将笔记持久化到上下文窗口外部存储的技术,后续在需要时被拉回上下文窗口

工作方式

• 智能体创建待办事项或者维护NOTES.md文件
• 用于追踪复杂任务的基站
• 保持关键上下文和依赖关系,防止这些信息的在上下文中丢失

选择策略的指南

6.4.9 压缩前的记忆刷写和检查点

为了降低信息损失,生产级系统通常在压缩前执行记忆刷写(Memory Flush)并建立压缩检查点(Compaction checkpoint)来支持任务恢复

记忆刷写:

当上下文占用接近窗口的某个阈值时,系统在执行压缩之前触发一次记忆刷写:将需要长期保留的关键信息(决策,偏好,待办事项)写入外部持久化存储,确保不会在压缩中丢失

压缩检查点

压缩检查点在每次压缩时额外保存:

• 压缩摘要
• 结构化状态:任务进度,待办事项,已完成步骤
• 活跃文件列表

工具输出的分层裁剪

按照时间衰减处理工具执行结果的输出

6.4.10 智能体上下文缩减策略:

将工具执行结果分为“完整版”和“紧凑版”两种形式…

2. 陈旧结果压缩

随着对话进行，早期结果被替换为摘要…

3. 基于结构的轨迹摘要

即便使用摘要，也强制使用结构化 Schema…

6.5 压缩策略案例分析

6.5.1 案例一: 长文档会议纪要生成

场景描述

用户上传一份长达5万字得行业研报,希望生成一份结构化得摘要,包含关键数据,主要观点,未来趋势

挑战:

• 长度限制:超出绝大多数模型上下文窗口
• 信息分散
• 结构要求:严格遵循特定格式

解决方法:递进式压碎+对话历史管理

1. 分块(Chunking)
2. 并行摘要(Map):对每个部分进行摘要,提取关键数据和观点
3. 聚合(Reduce):对各部分合并
4. 最终生成:整合信息,符合格式要求

6.5.2 案例二: 多轮对话中的长期记忆

挑战:

• 上下文膨胀
• 遗忘

解决方案:关键信息提取+摘要总结

1.短期记忆:保留最近10轮对话的完整内容

2.长期记忆:

• 实体提取:每天结束对话扫描当天对话提取用户信息
• 摘要归纳

3.检索增强:再次对话时,检索相关实体

6.5.3 案例三: 代码库理解与问答

场景描述

开发者询问关于整个项目架构的问题,项目包含数百个文件

挑战:代码块理解

• 代码量巨大:无法一次放入Context Window
• 依赖关系复杂

解决方法:结构化压缩(骨架提取)

1. 生成骨架:
   • 保留：Class 定义、函数签名、关键注释、Import 语句
   • 移除：函数体具体实现、内部逻辑。
2. 构建全景图:将所有文件的骨架连接,形成项目的高层地图
3. 按需展开:
   1. LLM先阅读这些骨架,定位到负责相关逻辑的文件
   2. 工具调用读取这些文件的完整内容

6.5.4 案例四: 长时程变成助手渐进式上下文管理

场景描述：长时程编程助手

以 Claude Code 这类长时程编程助手为例，系统需要支持用户进行数小时甚至数天的开发任务，包括代码编写、文件修改、工具调用等。同时要在有限的上下文窗口内维持任务连续性，并控制成本。

挑战:长时程编程助手

• 任务跨度长
• 信息多层次
• 成本敏感
• 无缝体验

解决方法:递进式上下文策略

第 1 层：工具结果持久化（Disk + 2KB Preview，冻结状态缓存命中）

每次工具执行（如 grep、read file）的结果不仅回传给模型，也同时写入磁盘。当上下文接近限制时，工具结果从上下文中移除，仅保留 2KB 的摘要预览。若模型在后续步骤中需要再次引用该结果，系统检测缓存命中情况：

• 缓存命中：直接返回之前的完整结果，无需重新执行
• 缓存未命中：重新执行工具并缓存

第 2 层：微压缩（Micro-compaction，60 分钟 TTL）

与提示词缓存 TTL 对齐，每 60 分钟自动对旧的工具输出进行一次轻量级压缩。不调用 LLM，而是采用启发式规则：

• 删除重复的执行结果
• 保留首次和最后一次执行的完整结果
• 中间结果聚合为一句话摘要

第 3 层：会话记忆（Session Memory，结构化笔记，零 API 成本）

在每个关键里程碑（如完成一个功能、解决一个问题），系统引导用户（或自动）生成结构化笔记 MEMORY.md：

• 容量限制：最多 200 行或 25KB
• 条目格式：每条约 150 字符，包含类别标签（项目模式、用户偏好、工具配置、领域知识）
• 成本：零 API 调用，完全本地存储
• 效果：新会话加载时，这份预构建的摘要能快速恢复关键上下文

第 4 层：完全压缩（Full Compaction，9 部分总结）

当会话记忆仍不足以处理新的查询时，触发完全压缩。调用 LLM 对整个会话进行总结，生成 9 个部分：

1. 任务目标与原始需求
2. 整体架构与设计决策
3. 已完成的步骤
4. 当前进度与活跃文件
5. 遇到的问题与解决方案
6. 用户偏好与特殊约束
7. 待解决的问题
8. 下一步计划
9. 关键代码片段与路径

• 处理：去除详细的思考过程、冗余工具输出，保留结构化信息
• 存储：压缩摘要保存为 COMPACTION.md，成为新会话的起点

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

会话开始
  ↓
加载 MEMORY.md（如存在）
  ↓
执行任务，记录工具结果到磁盘
  ↓
上下文接近 75%？
  ├─ 否：继续执行
  └─ 是：
      ├─ 距离上次压缩 < 60 分钟？
      │   ├─ 是：执行第 2 层微压缩
      │   └─ 否：检查 MEMORY.md 是否需要更新
      └─ 上下文仍接近限制？
          ├─ 是：执行第 4 层完全压缩，生成 COMPACTION.md
          └─ 否：继续工作

本章小结:

核心观点

1. 压缩是必要的优化：
   • 控制 Token 用量和成本
   • 提高上下文利用效率
   • 改善响应延迟
2. 压缩方法各有适用场景：
   • 抽取式：需要精确引用
   • 生成式：需要流畅表达
   • 信息提取：需要结构化数据
3. 对话历史需要专门管理：
   • 结合滑动窗口和压缩
   • 保留关键信息点
   • 分层次管理不同时间距离的内容
4. 上下文优化是系统工程：
   • 预算分配
   • 格式优化
   • 缓存复用
   • 持续监控

常见误区

• 误区一：压缩就是截断 正解：压缩是提炼精华，需要保留关键信息
• 误区二：压缩率越高越好 正解：需要在压缩率和信息完整性之间平衡
• 误区三：一次压缩永久使用 正解：不同任务可能需要不同的压缩版本

实践建议

1. 建立 Token 预算：明确各部分的 Token 分配
2. 优化最大消耗点：通常是检索内容和对话历史
3. 组合多种策略：摘要 + 提取 + 窗口管理
4. 监控优化效果：对比压缩前后的任务效果和成本
5. 保留原始信息：压缩结果可能需要回溯验证

Context Engineering

1.1.1定义与内涵

上下文工程（Context Engineering）是一门系统性的工程学科，它研究如何设计、组织、优化和管理大语言模型所需的全部信息环境，以确保模型能够在正确的时间获得正确的信息，从而产生准确、可靠、符合预期的输出。 关键要素:

1. 系统性:具有完整的方法论体系
2. 信息环境:关注的不仅仅是输入给模型的文本,还有可能影响模型行为的其他信息,比如:持久化的信息,agent状态,运行时环境而非单纯的prompt(tools,system prompt,user_messages,tool_results)
3. 时机和形式:正确时机正确形式
4. 目标导向:实现可靠的,可预测的输出

1.1.2 上下文的多维构成

包括以下的角色:

• 系统指令(对应system prompt部分)
• 用户输入
• 对话历史(memory部分)
• 外部知识(通过其他方法例如检索引入的外部知识)
• 工具定义
• 示例样本

1.1.3 上下文工程的核心挑战

主要有三:

1. 有限的上下文窗口:超出上下文时,相关内容的选择很关键
2. 信息的质量和密度:模型的输出质量高度依赖于输入信息的质量
3. 动态和实时性:构建动态的上下文管理系统确保信息的实时性是一个挑战

1.1.4 与驭具工程(Harness Engineering)的关系

在智能体工程的完整版图中，上下文工程并非孤立存在。业界提出的驭具工程（Harness Engineering） 涵盖了让智能体在生产环境中可靠运行的全部工程实践，包括工具与权限编排、上下文动态管理、反馈纠错闭环、安全守卫四大职能。上下文工程正是其中“上下文动态管理”这一核心支柱——决定在什么时间节点、把哪些记忆和背景信息注入模型的上下文窗口。

换言之，上下文工程关注“模型看到什么”，驭具工程关注“模型如何安全可靠地执行”。两者互为补充：即使上下文管理做得再精准，如果缺少权限控制、错误恢复和安全守卫，智能体仍然无法在真实业务中稳定运行。

1.1.5 上下文工程的重要性

1. 模型能力的放大器:模型的输出质量高度依赖于输入信息的质量
2. 可靠性的保障:能显著降低幻觉,错误和不一致行为的发生
3. 成本效率的关键
4. 可拓展性的基础

1.2 从提示词工程到上下文工程

1.2.1 提示词工程的起源与局限

提示词工程（Prompt Engineering）是指通过精心设计输入给模型的文本指令，来引导模型产生期望输出的技术

提示词工程的典型技巧包括:

1. 角色设定
2. 任务描述:清晰准确
3. 输出格式:指定如JSON,Markdow等结构化输出
4. 少文本学习(few-shot)
5. 思维链(CoT)提示

1.2.2 上下文工程的演进

关注如何构建完整的信息环境 Anthropic将上下文工程定义为: “在推理过程中策划与维护最优 token 集合的一整套策略”

1.2.3 上下文工程和提示词工程的核心差异对比

1.3上下文工程的核心价值

3.1.1 信息环境的概念

信息环境（Information Environment）是指模型在执行任务时可获取的全部信息的集合与组织方式

一个优秀的信息环境的应该满足以下特性:

• 包含任务所需的充分信息
• 排除无关的噪声信息
• 以模型易于理解的方式组织
• 能够动态适应任务需求

3.1.2 注意力预算与上下文腐烂

注意力预算(Attention budget)

上下文应该视为有限资源,投入每个token的注意力不是均等的;边界效应递减;需要在上下文大小和注意力集中度之间权衡

上下文腐烂(Context rot)

随着上下文大小的增长,有效利用率下降 原因:长上下文增加位置偏置,噪声和冲突证据的暴露面;模型训练方式和推理系统差异很大

核心指导原则:优秀的上下文工程意味着找到最小可能的高信号token集

3.1.3 设计原则一: 相关性优先

核心理念:只包含和当前任务直接相关的信息

相关性的筛选: 将全量信息按照下面几种方式处理 进行相关性评测:

• 高相关: 纳入上下文
• 低相关: 排除
• 可能相关: 条件纳入

3.1.4 设计原则二: 信息密度优先

核心理念: 用最少的token传达最多的有效信息

信息密度定义为:有效信息/token数量

提高信息密度的方法:

• 删除冗余和重复内容
• 使用结构化格式代替散文
• 压缩长文本为摘要
• 提取关键事实而非全文

3.1.5 设计原则三: 结构化组织

核心理念:用清晰的结构组织信息,便于模型理解和定位

常见的结构化方法:

3.1.6 设计原则四: 上下文分层

核心理念: 根据信息的重要性和稳定性,分层组织上下文

典型的分层结构:

• 系统层:最稳定,定义模型的基本角色和行为边界
• 知识层:相对稳定,提供任务所需的背景知识
• 任务层:随任务变化,描述当前的具体目标
• 交互层:最动态,反应即时的用户输入和对话状态

3.1.7 设计原则五: 显式优于隐式

核心理念:明确说明期望而非依赖模型预测

模型擅长那个遵循明确的指令,对于隐含期望的推测可能不可靠

• 明确输出格式要求
• 显式说明限制条件
• 清楚定义术语含义
• 提供具体的正例和反例

3.1.8 设计原则六: 渐进式提供

核心理念:按需提供信息,避免一次性加载全部内容

渐进式提供的方式有:

• 即时加载
• 分布展开
• 条件触发

3.1.9 设计原则七: 系统提示词的高度校准

系统提示词是上下文的基础,定义了模型的基本角色和行为

两个常见的失败模式:

1. 过低的高度(Brittle logic):在系统提示词中硬编码if-else逻辑,试图通过冗长的条件语句精确指定每种情况下的行为
2. 过高的高度(Vague Assumptions): 系统提示词过于宽泛或者依赖隐含理解,导致模型无法获得足够的具体信息

校准方法：

1. 从最小提示词开始，测试模型在你的目标任务上的表现
2. 识别失败模式，添加明确的指导原则（不是规则）
3. 测试新版本，迭代改进
4. 定期审视，移除不必要的条件和过度说明
5. 优先使用示例和启发式原则，而非 if-then 条件

3.2 四大核心策略概览

可以归纳成四大核心策略: 写入策略(write),选择策略(select).压缩策略(compaction),隔离策略(isolate)

3.2.2 写入策略

回答的问题是:如何在上下文窗口外存储和管理信息 主要技术:

• 外部记忆系统:将信息持久化到外部
• 知识库构建:组织结构化的领域知识
• 向量数据库:将文本转化为向量进行存储和检索
• 记忆框架:设计多层次的记忆结构

应用场景:

• 构建企业知识库
• 实现跨对话的长期记忆
• 存储用户偏好和历史

3.2.3 选择策略

回答的问题:如何从海量的信息中获取与当前任务最相关的内容

选择策略是RAG(检索增强生成)的核心

主要技术:

• 语义检索:基于语义相似度
• 关键词检索:基于关键词匹配
• 混合检索:结合前两者
• 重排序:对检索结果进行二次排序优化

应用场景

• 文档问答系统
• 知识库查询
• 代码检索

3.2.4 压缩策略

要回答的问题:如何在有限的上下文空间中容纳更多的有效信息 旨在提高信息密度

主要技术:

• 文本摘要:长文档压缩为精炼摘要
• 信息提取:提取关键事实和实体
• 对话压缩:压缩冗长的对话历史
• 递进式摘要:分层次压缩

应用场景:

• 长文档处理
• 对话历史管理
• 成本优化

3.2.5 隔离策略

如何组织和结构化上下文中的不同信息

主要技术:

• XML/标签标记:用标签区分不同类型的内容
• 指令分层
• 任务隔离:为不同的任务单独创建上下文
• 多智能体编排:在多智能体间分配上下文

应用场景:

• 复杂提示词设计
• 多任务系统
• 智能体协作

3.2.6 策略之间的关系

策略之间可能需要迭代执行,例如:

• 检索后发现信息不足,触发写入
• 压缩后发现关键信息确实,调整压缩策略
• 隔离过程中发现结构不合理,重新组织

同时要警惕 边界泄漏：四种策略之间相互污染 写入层存储的外部内容、选择层召回的文档、压缩层生成的摘要都可能混入看似“指令”的文本。进入隔离层前应保留来源、权限、时间戳和可信等级；进入最终上下文后，也要明确把外部内容标记为“数据”而不是“系统指令”。否则四种策略会在边界处相互污染，导致提示注入、旧事实覆盖新事实或跨用户数据串扰。

3.3 上下文质量评估

3.3.1 为什么需要评估

上下文质量直接影响模型的输出质量(Garbage in Garbage out)

评估的难点在于:

• 主观性:说明是好的上下文取决于具体任务
• 多维性:需要同时考虑多个维度
• 动态性:随着知识库的更新,评估结果也会发生变化

3.3.2 检索质量评估

在RAG系统中,检索是第一道关卡

常见的指标为:

召回率指标:

常见写法: Recall@K 定义:在前K个检索结果中,包含了多少个相关文档 $$ Recall@K=

前 K 个结果中的相关文档数/总相关文档数 ​ $$ 意义:衡量检索系统"找全"能力 适用场景:需要保证关键信息不遗漏时

平均倒数排名指标:

常见写法: MMR(Mean Reciprocal Rank) 定义:第一个相关文档出现位置的倒数的平均数(如果相关文档排在第 1 位，倒数得分为 1/1=1；排在第 2 位，倒数为 1/2=0.5，依次类推) $$

MRR = \frac{1}{|Q|}\sum_{i=1}^{|Q|}\frac{1}{\operatorname{rank}_i} $$ 意义:衡量检索系统"首中"的能力.因为模型对于靠前的信息关注度最高 适用场景:问答系统

归一化折损累计增益指标:

常见写法:NDCG(Normalized Discounted Cumulative Gain) 定义:考虑了所有相关文档的排名位置,排名越靠前权重越高 意义:最全面的排序指标,不仅看"有没有",还看排得"对不对" 适用场景:复杂的检索任务,需要对对各相关文档进行优先级排序

3.3.3 生成质量评估

传统指标

BLEU/ROUGE:基于n-gram重叠度的字面匹配指标 局限性:对语义的理解能力弱,LLM的回答可能字面不同但是意思完全正确,因此在LLM评估中权重逐渐降低

基于模型的评估

利用更强的LLM作为裁判(LLM as a Judge):

• G-Eval:让LLM基于明确的评分标准对输出进行打分
• BERTScore(基于嵌入而非LLM裁判): 用上下文嵌入的token级cos相似度计算生成文本与参考文本的语义相似度,输出P/R/F1标量分数(参考文本可能是更强的LLM生成的,也可能是人工生成的)

评估框架指标

Ragas是目前流行的RAG评估框架之一,常见的指标包括

1. 信实度 (Faithfulness)：
   • 答案是否完全基于上下文生成？
   • 用于检测幻觉（Hallucinations）。
2. 答案相关性 (Answer Relevance)：
   • 答案是否直接回答了用户的问题？
   • 用于检测答非所问。
3. 上下文精确度 (Context Precision)：
   • 检索到的上下文中有多少是真正有用的？
   • 用于评估信噪比。
4. 上下文召回率 (Context Recall)：
   • 黄金答案所需证据是否被检索到？
   • 用于定位“没找全”而不是“找太多”的问题

LLM-as-a-Judge 和自动指标都需要校准。关键发布前应与人工黄金集、反例集和线上反馈交叉验证，避免只优化指标而忽略真实用户问题。

3.3.4 端到端系统评估

人工评估(Human Evaluation)

• Likert Scale:1-5分打分
• Pairwise Comparison: A/B 两个答案选更好的
• 优点:更准确 缺点:贵,慢,不可拓展

A/B测试: 在生产环境中分流,比较不同策略下的用户反馈(点击率,点赞/点踩,后续追问率)

3.3.5 构建评估数据集

构建高质量的评估集(Golden Dataset)是上下文工程的重要一环

数据集的结构:

一个标准的评估样本通常包含:

1
2
3
4
5
6

{
  "question": "如何配置 Redis 缓存？",
  "ground_truth": "需要在配置文件中设置...",
  "contexts": ["doc_id_1", "doc_id_2"],  // 期望检索到的文档ID
  "answer": "配置 Redis 缓存的步骤如下..." // 期望的标准答案
}

构建方法

人工构建(Human Curated)

• 挑选真实的用户高频问题
• 由领域专家撰写标准答案和标注相关文档
• 质量很高,但成本昂贵

合成数据生成(Synthetic Data Generation)

• 利用LLM"逆向"生成数据
• Doc2Query:给一段文档,让LLM生成"用户可能问的问题"
• 流程:
  1. 分块文档
  2. Prompt:请针对这段文字生成三个相关的问题和标准答案
  3. 人工抽检生成的质量
• 这种方法可以快速低成本的构建数千个QA对

3.3.6 评估与迭代闭环

3.4 上下文工程方法论

3.4.1 方法论的必要性

方法论提供:

• 可重复的工作流程
• 清晰的决策框架
• 持续改进的机制

3.4.2 上下文工程生命周期

阶段一:需求分析

任务分析:任务类型,复杂度,领域特性 信息分析:信息来源,规模和动态性 约束分析:上下文窗口限制;延迟要求;成本预算

阶段二:设计

架构设计:

• 确定上下文分层结构
• 设计各层的内容和格式
• 规划动态加载机制

策略选择:

• 确定核心策略
• 设计策略的具体实现方式
• 规划策略之间的协作

工具选型:

• 选择检索方案
• 选择向量数据库
• 选择压缩方式

阶段三:实现

基础设施:

• 搭建向量数据库
• 配置嵌入模型
• 建立数据处理流水线

上下文构建:

• 实现各策略模块
• 开发上下文组装逻辑
• 构建工具调用机制

集成测试:

• 端到端功能验证
• 性能基准测试
• 边界情况处理

阶段四:评估

质量评估:

• 按3.3方法评估上下文质量
• 评估端到端任务效果
• 收集用户反馈

性能评估:

• token使用效率
• 响应延迟
• 系统吞吐量

成本评估:

• API调用成本
• 基础设施成本
• 维护成本

阶段五:优化

识别瓶颈:

• 分析评估数据
• 定位主要问题
• 确定优化优先级

迭代改进:

• 调整策略参数
• 优化实现细节
• 尝试新技术方案

持续监控:

• 建立监控仪表盘
• 设置告警阈值
• 跟踪长期趋势

3.4.3 决策框架

3.4.4 最佳实践原则

1.从简单开始 2.数据驱动:基于数据和评估而非主观;建立评估标准 3.模块化设计:策略单独实现;模块解耦,通过接口交互 4.持续迭代 5.关注端到端:最终优化为用户价值

3.4.5 团队协作

上下文工程通常涉及多个角色：

• AI 工程师：实现核心策略和系统
• 数据工程师：处理数据流水线和存储
• 产品经理：定义需求和评估标准
• 领域专家：提供专业知识支持

3.4.6 实战案例库

以下案例展示了上述方法论在真实场景中的应用：

案例一：企业级知识库检索系统

背景：某大型制造企业拥有海量内部文档（Wiki、技术手册、维修记录），员工需要快速查找解决生产线问题的方案。

挑战：

• 信息孤岛：数据分散在 SharePoint、Confluence 和文件服务器。
• 专业术语多：通用模型难以理解内部缩写（如 “ABC-123 故障”）。
• 权限复杂：不同层级员工可见内容不同。

上下文工程方案：

1. 需求分析：确认为“检索密集型”任务，准确性优先于创造性。
2. 设计：采用 RAG 架构，配合混合检索（Hybrid Search）。
   • 分层：
     • 系统层：固定的企业安全规范和输出格式。
     • 知识层：动态检索的文档片段（Top-5 chunk）。
     • 任务层：用户当前的查询和元数据（部门、设备 ID）。
3. 关键实现：
   • 术语增强：在写入阶段，利用 LLM 将内部缩写扩展为全称，建立同义词库。
   • 权限过滤：在检索阶段（Pre-retrieval），根据用户 ID 过滤索引，确保不越权访问。
4. 评估指标（示例口径）：
   • Recall@5、MRR、NDCG 等检索指标的变化趋势。
   • 用户满意度（CSAT）与后续追问率等体验指标。

案例二：多智能体协作编程

背景：一个致力于自动化代码生成的开源项目，使用多个智能体协同完成从需求分析到代码实现的流程。

挑战：

• 上下文传递丢失：产品经理智能体的详细需求，传到开发者智能体时变得模糊。
• 幻觉累积：早期的错误理解在后续环节被放大。
• 上下文超限：多轮协作后，完整的对话历史迅速撑爆窗口。

上下文工程方案：

1. 隔离与结构化：
   • 使用标准化的 JSON schema 定义 Agent 间的通信协议。
   • 每个 Agent 只接收与其职责相关的上下文片段（Context Slicing）。
2. 压缩与检查点：
   • 在交接点（Hand-off）引入“总结者 Agent”，将上一步的输出压缩为“已确认的决策点”。
   • 必须包含的锚点信息（如技术栈版本、核心 API 签名）始终保留，不被压缩。
3. 效果（常见观察）：
   • 复杂任务的一次通过率与返工率可被明显改善。
   • 通过压缩、切片与缓存，Token 消耗在高重复场景下可显著下降。

3.5 上下文管理的量化评估方法

3.5.1 引言 为什么需要量化评估

3.5.2 相关性评分指标

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176

from typing import List, Tuple, Set
import numpy as np

class RelevanceScorer:
    """相关性评分工具"""

    @staticmethod
    def mean_reciprocal_rank(
        retrieved_items: List[bool],  # True表示相关
        threshold_position: int = 10
    ) -> float:
        """
        平均倒数排名 (Mean Reciprocal Rank, MRR)

        衡量第一个相关项目出现的位置。
        越靠前，分数越高。

        公式: MRR = (1/position of first relevant item)

        示例:
        - [True, False, False] -> 1/1 = 1.0 (最优)
        - [False, True, False] -> 1/2 = 0.5
        - [False, False, False] -> 0.0 (无相关项)
        """

        for i, is_relevant in enumerate(retrieved_items[:threshold_position]):
            if is_relevant:
                return 1.0 / (i + 1)

        return 0.0

    @staticmethod
    def recall_at_k(
        retrieved_items: List[bool],
        relevant_item_count: int,
        k: int = 10
    ) -> float:
        """
        召回率 (Recall@k)

        在前k个结果中，找到了多少个相关项。

        公式: Recall@k = (前k个结果中的相关数) / 总相关数

        示例:
        - 总共10个相关项，前20个结果中找到8个 -> 8/10 = 0.8
        - 总共5个相关项，前10个结果中找到3个 -> 3/5 = 0.6
        """

        if relevant_item_count == 0:
            return 0.0

        relevant_in_top_k = sum(retrieved_items[:k])
        return relevant_in_top_k / relevant_item_count

    @staticmethod
    def precision_at_k(
        retrieved_items: List[bool],
        k: int = 10
    ) -> float:
        """
        精确度 (Precision@k)

        前k个结果中有多少比例是相关的。

        公式: Precision@k = (前k个中的相关数) / k

        示例:
        - 前10个结果中有8个相关 -> 8/10 = 0.8
        - 前5个结果中有1个相关 -> 1/5 = 0.2
        """

        if k == 0:
            return 0.0

        relevant_in_top_k = sum(retrieved_items[:k])
        return relevant_in_top_k / k

    @staticmethod
    def f1_score(
        retrieved_items: List[bool],
        relevant_item_count: int,
        k: int = 10
    ) -> float:
        """
        F1分数 (F1 Score)

        Precision和Recall的调和平均。
        在精确度和召回率之间找到平衡。

        公式: F1 = 2 * (Precision * Recall) / (Precision + Recall)
        """

        precision = RelevanceScorer.precision_at_k(retrieved_items, k)
        recall = RelevanceScorer.recall_at_k(retrieved_items, relevant_item_count, k)

        if precision + recall == 0:
            return 0.0

        return 2 * (precision * recall) / (precision + recall)

    @staticmethod
    def ndcg(
        relevance_scores: List[float],
        k: int = 10,
        ideal_dcg: float = None
    ) -> float:
        """
        归一化折损累计增益 (Normalized Discounted Cumulative Gain, NDCG)

        考虑相关性的"程度"（不只是相关/不相关）。
        排名靠前的相关项贡献更大。

        公式:
        DCG@k = sum(relevance[i] / log2(i+2)) for i in 0..k-1
        NDCG@k = DCG@k / IDCG@k

        其中IDCG是完美排序下的DCG。

        示例:
        relevance_scores = [0.9, 0.7, 0.0, 0.5, 0.8]
        DCG@5 = 0.9/1 + 0.7/log2(3) + 0/log2(4) + 0.5/log2(5) + 0.8/log2(6)
        """

        if not relevance_scores or k == 0:
            return 0.0

        # 计算实际的DCG
        dcg = 0.0
        for i, score in enumerate(relevance_scores[:k]):
            # 注意：log2(i+2)表示从位置1开始计数
            dcg += score / np.log2(i + 2)

        # 计算理想的DCG（如果没有给出，则用排序后的最优值）
        if ideal_dcg is None:
            sorted_scores = sorted(relevance_scores, reverse=True)
            ideal_dcg = 0.0
            for i, score in enumerate(sorted_scores[:k]):
                ideal_dcg += score / np.log2(i + 2)

        if ideal_dcg == 0:
            return 0.0

        return dcg / ideal_dcg


# 使用示例
if __name__ == "__main__":
    # 场景：搜索"Python教程"，返回了10个结果
    # 其中标注的相关性：
    retrieved = [
        True,   # 位置1: 很相关
        False,  # 位置2: 不相关
        True,   # 位置3: 相关
        False,  # 位置4: 不相关
        False,  # 位置5: 不相关
        True,   # 位置6: 相关
        False,  # 位置7: 不相关
        False,  # 位置8: 不相关
        True,   # 位置9: 相关
        False,  # 位置10: 不相关
    ]

    total_relevant_count = 6  # 来自黄金标注：语料库中共有6个相关项

    scorer = RelevanceScorer()

    mrr = scorer.mean_reciprocal_rank(retrieved)
    recall = scorer.recall_at_k(retrieved, total_relevant_count, k=10)
    precision = scorer.precision_at_k(retrieved, k=10)
    f1 = scorer.f1_score(retrieved, total_relevant_count, k=10)

    print(f"MRR: {mrr:.2f}")        # 应该是1.0（第1个位置）
    print(f"Recall@10: {recall:.2f}")  # 应该是0.67（找到6个相关项中的4个）
    print(f"Precision@10: {precision:.2f}")  # 应该是0.4（4/10）
    print(f"F1: {f1:.2f}")

分级相关性指标

实际场景中，相关性常常不是二元的（相关/不相关），而是有多个等级

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68

class GradedRelevanceScorer:
    """处理分级相关性的评估工具"""

    # 常见的相关性等级
    RELEVANCE_GRADES = {
        0: "完全不相关",
        1: "部分相关",
        2: "相关",
        3: "高度相关",
    }

    @staticmethod
    def dcg_with_grades(
        relevance_grades: List[int],  # [3, 2, 0, 1, 3, ...]
        k: int = 10
    ) -> float:
        """
        使用分级相关性计算DCG。
        """

        dcg = 0.0
        for i, grade in enumerate(relevance_grades[:k]):
            # 标准NDCG使用 (2^grade - 1) 作为相关性权重
            weight = (2 ** grade) - 1
            dcg += weight / np.log2(i + 2)

        return dcg

    @staticmethod
    def ndcg_with_grades(
        relevance_grades: List[int],
        k: int = 10
    ) -> float:
        """
        使用分级相关性计算NDCG。
        """

        dcg = GradedRelevanceScorer.dcg_with_grades(relevance_grades, k)

        # 理想的DCG：把同一批候选的人工相关性等级按从高到低排序
        ideal_grades = sorted(relevance_grades, reverse=True)[:k]
        ideal_dcg = GradedRelevanceScorer.dcg_with_grades(ideal_grades, k)

        if ideal_dcg == 0:
            return 0.0

        return dcg / ideal_dcg

    @staticmethod
    def metric_at_each_level(
        relevance_grades: List[int],
        k: int = 10
    ) -> dict:
        """
        计算每个相关性等级的指标分布。
        """

        grade_counts = {grade: 0 for grade in range(4)}

        for grade in relevance_grades[:k]:
            grade_counts[grade] += 1

        return {
            'not_relevant': grade_counts[0],
            'partially_relevant': grade_counts[1],
            'relevant': grade_counts[2],
            'highly_relevant': grade_counts[3],
        }

3.5.3 检索质量度量

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94

class RetrievalQualityEvaluator:
    """综合的检索质量评估"""

    def __init__(self):
        self.scorer = RelevanceScorer()

    def evaluate_retrieval(
        self,
        query: str,
        retrieved_results: List[dict],  # [{'id': '...', 'is_relevant': True/False, 'relevance_score': 0.8}]
        total_relevant_count: int,
        top_k_values: List[int] = None
    ) -> dict:
        """
        对单个查询的检索结果进行多维度评估。

        total_relevant_count 必须来自黄金标注或完整候选集，不能从 retrieved_results 推断。
        """

        if top_k_values is None:
            top_k_values = [1, 5, 10]

        # 提取相关性标签
        is_relevant = [r.get('is_relevant', False) for r in retrieved_results]
        relevance_scores = [r.get('relevance_score', 0.0) for r in retrieved_results]

        evaluation = {
            'query': query,
            'total_retrieved': len(retrieved_results),
            'total_relevant': total_relevant_count,
        }

        # 计算多个k值下的指标
        for k in top_k_values:
            k_metrics = {
                'mrr': self.scorer.mean_reciprocal_rank(is_relevant, k),
                'recall': self.scorer.recall_at_k(is_relevant, total_relevant_count, k),
                'precision': self.scorer.precision_at_k(is_relevant, k),
                'f1': self.scorer.f1_score(is_relevant, total_relevant_count, k),
            }

            evaluation[f'metrics@{k}'] = k_metrics

        return evaluation

    def evaluate_retrieval_batch(
        self,
        queries: List[str],
        retrieved_results_batch: List[List[dict]],
        total_relevant_counts: List[int],
        top_k_values: List[int] = None
    ) -> dict:
        """
        对多个查询的检索结果进行批量评估，并计算平均指标。
        """

        if top_k_values is None:
            top_k_values = [5, 10]

        individual_results = []
        aggregated_metrics = {f'@{k}': {} for k in top_k_values}

        for query, results, total_relevant_count in zip(queries, retrieved_results_batch, total_relevant_counts):
            indiv = self.evaluate_retrieval(query, results, total_relevant_count, top_k_values)
            individual_results.append(indiv)

            # 累积指标
            for k in top_k_values:
                k_str = f'@{k}'
                k_metrics = indiv[f'metrics@{k}']

                for metric_name, metric_value in k_metrics.items():
                    if metric_name not in aggregated_metrics[k_str]:
                        aggregated_metrics[k_str][metric_name] = []

                    aggregated_metrics[k_str][metric_name].append(metric_value)

        # 计算平均值
        for k_str in aggregated_metrics:
            for metric_name in aggregated_metrics[k_str]:
                values = aggregated_metrics[k_str][metric_name]
                aggregated_metrics[k_str][metric_name] = {
                    'mean': np.mean(values),
                    'std': np.std(values),
                    'min': np.min(values),
                    'max': np.max(values),
                }

        return {
            'individual_results': individual_results,
            'aggregated_metrics': aggregated_metrics,
            'total_queries': len(queries),
            'average_retrieval_count': np.mean([r['total_retrieved'] for r in individual_results]),
        }

3.5.4 上下文效率指标

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153

class ContextEfficiencyAnalyzer:
    """分析上下文的使用效率"""

    @staticmethod
    def information_density(
        context: str,
        relevant_spans: List[str]
    ) -> float:
        """
        信息密度 = 相关信息量 / 总信息量

        衡量上下文中"有用信息"的比例。

        relevant_spans 是上下文中被判定为“与当前任务相关”的片段原文，
        来自人工标注或评估模型。密度必须由两侧的实际规模算出：只传入一个
        现成的 relevance_score 再乘回总量，分子分母会约掉，得到的永远是
        传进来的那个分数本身，与 context 无关。
        """

        total_tokens = len(context) // 4  # 粗略估计
        if total_tokens <= 0:
            return 0.0

        useful_tokens = sum(len(span) // 4 for span in relevant_spans)

        return min(1.0, useful_tokens / total_tokens)

    @staticmethod
    def redundancy_ratio(
        context: str
    ) -> float:
        """
        冗余度 = 重复内容的比例

        通过n-gram重复频率估计冗余度。
        """

        # 简化：提取所有5-gram并统计重复
        words = context.split()

        if len(words) < 5:
            return 0.0

        ngrams = []
        for i in range(len(words) - 4):
            ngram = ' '.join(words[i:i+5])
            ngrams.append(ngram)

        unique_ngrams = len(set(ngrams))
        total_ngrams = len(ngrams)

        # 冗余度 = 1 - (unique / total)
        redundancy = 1 - (unique_ngrams / total_ngrams) if total_ngrams > 0 else 0

        return redundancy

    @staticmethod
    def context_coverage_ratio(
        context: str,
        query: str
    ) -> float:
        """
        覆盖率 = 查询中被上下文覆盖的关键词比例

        衡量上下文对查询的覆盖程度。
        """

        query_keywords = set(query.lower().split())
        context_lower = context.lower()

        covered = sum(1 for kw in query_keywords if kw in context_lower)
        total = len(query_keywords)

        return covered / total if total > 0 else 0

    @staticmethod
    def efficiency_score(
        context: str,
        query: str,
        relevant_spans: List[str],
        max_tokens: int = 2000
    ) -> float:
        """
        综合效率分数 (0-100)

        综合考虑：
        - 信息密度（越高越好）
        - 冗余度（越低越好）
        - 覆盖率（越高越好）
        - Token利用率（在预算内）

        四项里只有信息密度需要外部标注（relevant_spans），其余三项都能
        从 context 和 query 直接算出。权重是可调的工程约定，不是通用常数。
        """

        density = ContextEfficiencyAnalyzer.information_density(context, relevant_spans)
        redundancy = ContextEfficiencyAnalyzer.redundancy_ratio(context)
        coverage = ContextEfficiencyAnalyzer.context_coverage_ratio(context, query)

        # Token利用率
        context_tokens = len(context) // 4
        token_utilization = min(1.0, context_tokens / max_tokens)

        # 加权综合
        efficiency = (
            density * 0.35 +           # 信息密度权重35%
            (1 - redundancy) * 0.25 +  # 非冗余度权重25%
            coverage * 0.25 +           # 覆盖率权重25%
            token_utilization * 0.15   # Token利用率权重15%
        )

        # 规范化到0-100
        return efficiency * 100


# 使用示例
if __name__ == "__main__":
    evaluator = RetrievalQualityEvaluator()

    # 评估单个查询
    query = "Python教程"
    results = [
        {'id': '1', 'is_relevant': True, 'relevance_score': 0.95},
        {'id': '2', 'is_relevant': False, 'relevance_score': 0.2},
        {'id': '3', 'is_relevant': True, 'relevance_score': 0.85},
        {'id': '4', 'is_relevant': False, 'relevance_score': 0.15},
        {'id': '5', 'is_relevant': True, 'relevance_score': 0.8},
    ]

    total_relevant_count = 4  # 来自黄金标注：语料库中共有4个相关文档
    evaluation = evaluator.evaluate_retrieval(query, results, total_relevant_count)

    print("单个查询评估:")
    print(f"  总相关: {evaluation['total_relevant']}")
    print(f"  Recall@5: {evaluation['metrics@5']['recall']:.2f}")
    print(f"  Precision@5: {evaluation['metrics@5']['precision']:.2f}")

    # 评估效率
    context = """
    Python是一种高级编程语言，以其简洁易读的语法而闻名。
    Python支持多种编程范式，包括过程式、面向对象和函数式编程。
    Python广泛用于数据科学、机器学习和Web开发。
    Python有一个庞大的标准库和第三方库生态系统。
    """

    # 标注出上下文里真正回答了"Python教程"的片段
    relevant_spans = [
        "Python是一种高级编程语言，以其简洁易读的语法而闻名。",
        "Python支持多种编程范式，包括过程式、面向对象和函数式编程。",
    ]

    efficiency = ContextEfficiencyAnalyzer.efficiency_score(context, query, relevant_spans)
    print(f"\n上下文效率分数: {efficiency:.1f}/100")

3.3.5 A/B测试框架在上下文优化中的作用

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153

from scipy import stats

class ABTestFramework:
    """
    A/B测试框架
    用于统计显著性验证
    """

    @staticmethod
    def paired_ttest(
        control_group: List[float],
        treatment_group: List[float],
        alpha: float = 0.05
    ) -> dict:
        """
        配对t检验

        同一批查询分别跑 control 和 treatment 时，应该比较逐查询差值。
        """

        t_stat, p_value = stats.ttest_rel(control_group, treatment_group)

        is_significant = p_value < alpha

        return {
            't_statistic': t_stat,
            'p_value': p_value,
            'is_significant': is_significant,
            'control_mean': np.mean(control_group),
            'treatment_mean': np.mean(treatment_group),
            'improvement': (
                (np.mean(treatment_group) - np.mean(control_group)) /
                np.mean(control_group) * 100
                if np.mean(control_group) != 0 else 0
            ),
        }

    @staticmethod
    def cohen_d(
        control_group: List[float],
        treatment_group: List[float]
    ) -> float:
        """
        计算效果量 (Effect Size)

        衡量两组差异的实际大小（不只是统计显著性）。
        """

        deltas = np.array(treatment_group) - np.array(control_group)
        mean_diff = np.mean(deltas)

        pooled_std = np.std(deltas)

        if pooled_std == 0:
            return 0

        return mean_diff / pooled_std

    @staticmethod
    def calculate_sample_size(
        effect_size: float = 0.5,  # Cohen's d
        alpha: float = 0.05,
        power: float = 0.8
    ) -> int:
        """
        计算所需样本量

        为了达到统计显著性，需要多少样本？
        """

        # 简化公式
        z_alpha = stats.norm.ppf(1 - alpha / 2)
        z_beta = stats.norm.ppf(power)

        sample_size = int(
            2 * ((z_alpha + z_beta) / effect_size) ** 2
        )

        return sample_size


class ContextOptimizationABTest:
    """上下文优化的A/B测试设计"""

    def __init__(self, control_strategy: str, treatment_strategy: str):
        self.control_strategy = control_strategy
        self.treatment_strategy = treatment_strategy
        self.control_results = []
        self.treatment_results = []

    def run_test(
        self,
        queries: List[str],
        ground_truth_answers: List[str],
        llm_generate_func
    ) -> dict:
        """
        执行A/B测试。

        control_strategy: 原始的上下文工程方案
        treatment_strategy: 新的上下文工程方案
        """

        print(f"Running A/B Test: {self.control_strategy} vs {self.treatment_strategy}")

        # 测试Control组
        for query, ground_truth in zip(queries, ground_truth_answers):
            context = self._prepare_context(query, strategy=self.control_strategy)
            answer = llm_generate_func(context, query)
            similarity = self._similarity(answer, ground_truth)
            self.control_results.append(similarity)

        # 测试Treatment组
        for query, ground_truth in zip(queries, ground_truth_answers):
            context = self._prepare_context(query, strategy=self.treatment_strategy)
            answer = llm_generate_func(context, query)
            similarity = self._similarity(answer, ground_truth)
            self.treatment_results.append(similarity)

        # 统计分析
        test_results = ABTestFramework.paired_ttest(
            self.control_results,
            self.treatment_results
        )

        effect_size = ABTestFramework.cohen_d(
            self.control_results,
            self.treatment_results
        )

        test_results['effect_size'] = effect_size

        return test_results

    def _prepare_context(self, query: str, strategy: str) -> str:
        """准备上下文（这里是简化实现）"""
        # 实际应该调用不同的上下文处理流程
        return f"Using {strategy}: {query}"

    def _similarity(self, text1: str, text2: str) -> float:
        """计算两个文本的相似度"""
        # 简化：基于词重叠。生产评估应换成经过校准的语义指标、
        # LLM-as-a-judge 量表或人工黄金标注，避免把复述当成正确性。
        words1 = set(text1.lower().split())
        words2 = set(text2.lower().split())

        if not words1 or not words2:
            return 0.0

        overlap = len(words1 & words2)
        union = len(words1 | words2)

        return overlap / union

5.1.1 RAG的定义与动机

检索增强生成（Retrieval-Augmented Generation，RAG）是一种将信息检索与语言模型生成相结合的技术。它允许模型在生成答案时参考外部知识源，从而克服模型知识的局限性。 RAG解决的核心问题:

• 知识时效性：模型训练数据有截止日期，无法获知最新信息
• 知识准确性：模型可能产生幻觉，检索提供事实依据
• 知识专业性：通用模型可能缺乏特定领域的深度知识
• 知识可控性：可以精确控制模型能够访问的知识范围

5.1.2 RAG的基本框架

标准 RAG 流程：

1. 查询处理：理解和转换用户查询
2. 信息检索：从知识库检索相关内容
3. 上下文构建：将检索内容组装到提示词中
4. 模型生成：模型基于增强的上下文生成答案
5. 输出响应：返回生成的答案

5.1.3 RAG的技术组件

5.1.4 RAG与模型能力的关系

RAG不是替代模型能力,而是增强模型能力:

• LLM提供:语言理解,推理和生成能力
• RAG提供:事实依据,专业知识,最新能力

RAG 配合高能力模型效果最好。模型需要足够的理解和推理能力，才能有效利用检索到的信息。

5.1.5 RAG的优势与局限

优势：

• 显著减少幻觉，提高事实准确性
• 支持知识的实时更新
• 知识来源可追溯，增强可信度
• 无需重新训练模型

局限：

• 检索质量直接影响最终效果
• 增加了系统复杂度和延迟
• 对于需要深度推理的问题效果有限
• 阻断式延迟瓶颈：传统的 RAG 呈现“被动式阻断检索”——用户提问 -> 检索 -> 拼接 -> 推理。这种串行流程极大拉长了首 Token 延迟，尤其是大并发下，算力浪费与响应等待尤为明显。

5.1.6 从"被动阻断"到"主动式全时调度"

面对传统 RAG 的串行阻断式延迟，前沿工程探索出一种突破性策略：异步预加载（如 Memory Cube 机制）。

与其让用户思考、打字、阅读的“碎片空档时间”白白流逝，不如将记忆管理、调度与预热工作化整为零，嵌入每一个空隙。通过预测用户意图，系统在后台并行地提前完成记忆检索和组合操作。当用户真正发出查询时，所需的增强上下文已经处于“就绪（Ready）”状态，只需一次轻量调用即可极速交付。

这标志着 RAG 系统从“请求即时检索”向“全时异步调度”的重大演进。 我说白了提前加载,这不是其他用烂了的策略嘛

5.1.7 RAG的发展阶段

第一代：朴素 RAG

• 简单的向量相似性检索
• 固定的分块和检索策略
• 直接拼接检索结果

第二代：高级 RAG

• 引入重排序和混合检索
• 优化的分块和嵌入策略
• 查询增强和结果后处理

第三代：模块化 RAG

• 灵活组合各种 RAG 技术
• 自适应检索策略
• 与智能体系统集成

5.2 文档分块策略

5.2.1 分块的重要性

分块（Chunking）是将大文档切分为小片段的过程，是 RAG 系统的关键步骤。分块质量直接影响：

• 检索精度：能否找到最相关的内容
• 上下文完整性：检索到的内容是否包含完整语义
• Token 效率：是否高效利用上下文空间

5.2.2 分块的基本原则

• 原则一:语义完整性
• 原则二:大小适中:太大:占用上下文空间 太小:信息不完整
• 原则三:信息自包含

5.2.3 常见的分块方法

固定大小分块

按固定的字符数或 Token 数切分

1
2
3

优点：实现简单、结果可预测
缺点：可能破坏语义完整性
适用：快速原型、对质量要求不高

参数：块大小（通常 500-2000 字符）、重叠大小（10-20%）

基于分隔符分块

按自然分隔符（段落、句子、换行）切分。

1
2
3

优点：保持自然边界
缺点：块大小不一致
适用：结构清晰的文档

常用分隔符：\n\n、\n、.、。

递归分块

尝试按多级分隔符切分，自动适应文档结构。

1
2
3

优点：平衡完整性和一致性
缺点：实现较复杂
适用：大多数文档类型

典型分隔符序列：["\n\n", "\n", " ", ""]

语义分块

基于语义相似度切分,保证语义单元完整

1
2
3

优点：语义完整性最好
缺点：计算成本高
适用：对质量要求高的场景

实现方式：计算相邻句子的嵌入相似度，在相似度低谷处切分。

基于LLM分块

使用语言模型理解内容结构进行切分。

1
2
3

优点：理解能力最强
缺点：成本高、延迟大
适用：高价值内容、复杂文档

5.2.4 分块策略对比实验

5.2.5 分块参数调优

块大小选择

重叠设置

重叠可以防止信息被切断在边界处,典型设置为快大小的10-20%

元数据保留

为每个快附加元数据:

• 来源文档
• 位置信息（第几章、第几节）
• 标题层级
• 时间戳

5.2.6 特殊文档类型处理

代码文档

按函数、类等逻辑结构切分，而非按行数。

表格数据

保持行完整性，必要时将表头附加到每个块。

对话记录

按对话轮次切分，保持问答对完整。

技术文档

尊重标题层级结构，将标题作为块的上下文前缀。

5.2.7 分块质量评估

评估分块效果的方法：

1. 边界检查：人工检查切分边界是否合理
2. 检索测试：测试典型查询能否检索到相关块
3. 下游效果：观察最终任务效果

5.2.8 最佳实践

1. 从递归分块开始：适用于大多数场景
2. 根据内容调整：不同类型文档使用不同策略
3. 保留结构信息：将标题等信息附加到块中
4. 测试和迭代：持续评估和优化分块效果

5.2.9 实战案例: 三种场景的分块对比

以下是三种典型场景的分块策略对比，展示如何根据内容特点选择合适的方法。

案例一：产品规格表

场景：用户问“这款手机支持 5G 吗？”需要从产品说明书中检索答案。

错误做法：

复制

1
2
3
4

# 按 500 字符固定分块

第一块: "...4800万像素主摄像头，支持光学防抖。5G 网络..."  ← 5G信息被切断
第二块: "...支持 SA/NSA 双模。电池容量 5000mAh..."

正确做法：

复制

1
2
3
4
5

# 按产品规格表的属性分块

块-网络: "网络制式: 5G SA/NSA 双模，支持 n1/n28/n41/n78 频段"
块-相机: "摄像头: 4800万像素主摄，支持光学防抖"
块-电池: "电池: 5000mAh，支持 67W 快充"

踩坑经验：规格表按固定字符数分块会把相关属性切断，导致模型无法完整回答。应按语义属性分块，每个块对应一个完整的产品特性。

案例二：法律合同

场景：找出合同中的“不可抗力”免责条款。

错误做法：

复制

1
2
3
4

# 按段落分块，但切断了条款

第一块: "...第八条 不可抗力 如因战争、地震、洪水等不可..."
第二块: "...抗力事件导致合同无法履行，双方均不承担违约责任。"

正确做法：

复制

1
2
3
4
5

# 按条款层级分块，保持完整

块-第八条: "第八条 不可抗力
如因战争、地震、洪水等不可抗力事件导致合同无法履行，双方均不承担违约责任。
不可抗力事件发生后，受影响方应在 7 日内书面通知对方。"

踩坑经验：法律文本的完整性至关重要。曾因分块切断句子导致法律含义改变（“不承担”变成“承担”）。必须按条款结构分块，宁可块大一点也不能破坏语义完整性。

案例三：代码库

场景：开发者问“这个函数是怎么实现的？”

错误做法：

复制

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# 按 50 行固定分块

第一块: "def calculate_price(items):
    total = 0
    for item in items:
        if item.discount:"  ← 函数被切断

第二块: "            price = item.price * 0.8
        else:
            price = item.price
        total += price
    return total"  ← 缺少函数开头

正确做法：

复制

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

# 按函数/类为单位分块

块-calculate_price: "# 位置: pricing.py:45-62
def calculate_price(items):
    '''计算购物车总价，支持折扣'''
    total = 0
    for item in items:
        if item.discount:
            price = item.price * 0.8
        else:
            price = item.price
        total += price
    return total

调用方: checkout.py:process_order()"

踩坑经验：代码按行数分块会切断函数逻辑，模型无法理解完整实现。应按 AST（抽象语法树）提取函数/类为单位，并附带调用关系元数据。

5.3 嵌入模型与语义检索

5.3.1 嵌入的基本概念

嵌入(Embedding)是将文本转化为数值向量的过程.语义相近的文本在向量空间中距离也相近,这是语义搜索的数学基础

嵌入模型的核心任务:将任意长度的文本映射到固定维度的向量空间,保持语义相似性

5.3.2 嵌入模型的工作原理

主要步骤:

1. 分词:将文本切分为token
2. 编码:通过Transformer编码器获取上下文表示
3. 池化:将多个token表示合并为单一向量
4. Norm(归一化):可选,将向量归一化为单位长度

5.3.3 嵌入模型类型对比

5.3.4 嵌入模型选择因素

质量需求:

5.3.4 嵌入模型选择因素

质量需求

• 高质量场景：选择能力更强的模型
• 一般场景：平衡模型可能足够

语言支持

• 纯中文：BGE 系列表现突出
• 多语言：BGE-M3、Cohere、Voyage、Gemini 等

上下文长度

• 长文档检索：需要支持更长输入的模型
• 短查询：大多数模型都能胜任
• 长上下文嵌入：可结合 late chunking，先编码较长文档再对片段池化，减少切块前丢失的上下文

成本与性能

• 云服务：按调用计费，需要考虑成本
• 本地部署：需要考虑硬件资源
• 维度裁剪：OpenAI 与 Gemini 等模型支持或采用 Matryoshka 式维度控制，可在召回质量、存储和延迟之间做实测权衡

5.3.5 语义搜索实现

相似度的度量

余弦相似度最为常用，因为它专注于方向而非长度。

检索流程

5.3.6 嵌入质量优化

查询增强:

增强查询以提高检索效果:

• 查询扩展：添加同义词或相关术语
• 查询改写：使用 LLM 改写为更好的搜索形式
• 假设文档：生成假设的理想答案，用于检索

文档增强

优化文档嵌入:

• 添加标题前缀：将标题拼接到内容前
• 摘要增强：为每个块生成摘要，用摘要嵌入
• 多向量表示：同一内容生成多个嵌入
• late chunking：对长文档先编码、后按块池化，适合指代关系和跨段上下文较强的材料
• late interaction：保存查询和文档的细粒度 Token 表示，在检索或重排阶段计算更细的相似度

5.3.7 嵌入的局限与对策

语义鸿沟

嵌入基于字面语义，可能忽略领域特定含义。

对策：使用领域微调的嵌入模型，或结合关键词搜索。

跨语言差异

不同语言的嵌入质量可能不一致。

对策：选择多语言优化的模型，或翻译后检索。

长尾查询

罕见表达可能嵌入效果差。

对策：查询扩展，或结合多种检索方式。

5.3.8 嵌入模型更新

嵌入模型更新时需要注意：

• 重新生成全部文档嵌入
• 保持查询与文档使用相同模型
• 考虑过渡期的兼容性

5.4 重排序与相关性优化

5.4.1 为什么需要重排序

向量检索存在以下的局限性:

• 嵌入是预计算的，无法考虑查询特定的语义
• 向量相似不等于真正的相关性
• 检索时只考虑局部匹配，缺乏全局视角

重排序(Reranking)是对初步检索结果进行二次排序的技术,能够显著提高最终结果的相关性

5.4.2 两阶段检索架构

第一阶段:快速召回大量候选(例如Top-100) 第二阶段:精细排序,选出最相关结果(例如Top-5)

5.4.3 重排序技术

交叉编码器

原理:将查询和文档拼接输入模型,直接输出相关性分数

1
2

输入：[CLS] 查询 [SEP] 文档 [SEP]
输出：相关性分数 (0-1)

优点：精度最高，能够捕捉查询-文档交互 缺点：计算成本高，无法预计算

常用模型：

• BGE-Reranker
• Cohere Rerank
• ms-marco 系列

大语言模型重排序

方式一:逐对比较

1
2
3
4

"以下两段内容哪个与查询更相关？
查询：...
内容A：...
内容B：..."

方式二:直接评分

1
2
3

"评估以下内容与查询的相关性（1-10分）：
查询：...
内容：..."

优点:灵活,可使用任何LLM 缺点:成本高延迟大

5.4.4 重排序性能对比实验

5.4.5 混和打分

结合多个信号进行打分

1

最终分数 = α × 语义分数 + β × 重排序分数 + γ × 其他信号

其他信号可以包括：

• 关键词匹配得分
• 文档权威性
• 时间新鲜度
• 用户行为数据

5.4.6 重排序实践

召回候选数量

• 太少：可能遗漏相关结果
• 太多：增加重排序成本

通常召回 20-100 条供重排序。

重排序结果数量

根据后续使用确定：

• 问答场景：通常 3-5 条
• 综合分析：可能需要 10+ 条

性能优化

• 批量处理减少调用次数
• 使用轻量级重排序模型
• 缓存频繁查询的结果

5.4.7 相关性优化的其他技术

查询优化

在检索前优化查询：

• 语义扩展：添加同义词
• 意图识别：理解查询真实意图
• 子查询分解：复杂查询拆分

结果多样化

避免返回重复或相似的结果：

• MMR（最大边际相关性）
• 聚类去重

反馈学习

利用用户反馈改进排序：

• 点击数据
• 满意度评分
• A/B 测试结果

5.4.8 重指标

5.5 混合检索和高级RAG

5.5.1 混合检索

混合检索（Hybrid Search）结合多种检索方法的优势，是当前 RAG 实践的标准配置。

语义检索和关键词检索对比

混合检索实现

分数融合策略

简单加权

1

融合分数 = α × 语义分数 + (1-α) × 关键词分数

倒数排名融合(RRF)

1

RRF(d) = Σ 1/(k + rank_i(d))

RRF不要来原始分数,只使用排名,更加鲁棒

5.5.2 高级RAG

查询转换

在检查之前对查询进行增强

查询拓展:

扩大查询覆盖范围

• 同义词拓展
• 相关术语添加
• 多语言翻译

查询分解

将复杂查询拆分:

1
2
3
4
5
6

原始查询：比较 A 产品和 B 产品在性能和价格方面的差异
分解为：
- A 产品的性能
- B 产品的性能
- A 产品的价格
- B 产品的价格

假设文档生成(HyDE)

生成假设的答案,对其嵌入进行检索:

1. 让LLM生成假设答案
2. 将假设答案转换为嵌入
3. 将假设答案的嵌入检索

多跳检索

应用场景:

• 需要背景知识支持的问题
• 设计对各实体关系的问题

自适应检索

根据查询特点动态调整策略

路由机制

根据查询类型不同选择不同的检索路径:

• 事实查询 → 精确检索
• 概念查询 → 语义检索
• 对比查询 → 多路检索

无需检索的识别:

并非所有的查询都需要检索:

• 常识问题
• 创意任务

不需要检索

上下文增强

丰富检索结果的上下文

父子块策略

• 使用小块检索:precision
• 返回大块内容:context

滑动窗口拓展

检索到模块后,自动包含相邻块

元数据增强

将来源,章节等元数据附加到结果中

5.5.3 RAG评估框架

组件级评估

分别评估RAG的各组件

常用评估工具

• RAGAS：自动化 RAG 评估框架
• TruLens：RAG 质量监控
• 人工评估：复杂场景仍需人工判断

5.5.4 RAG调优策略

问题诊断

常见问题及对策

• 检索不到相关内容->优化分块/嵌入
• 检索质量低->添加重排序
• 生成答案错误->优化提示词,加入约束

迭代优化

1.收集失败案例 2.分析失败原因 3.针对性优化 4.验证效果 5.持续监控

本章小结

本章深入探讨了上下文工程的选择策略，重点介绍了 RAG 技术体系。

关键概念清单

概念

定义

RAG

检索增强生成，结合信息检索与语言模型生成

分块

将大文档切分为小片段的过程

嵌入

将文本转换为数值向量的过程

语义搜索

基于语义相似度的信息检索

重排序

对初步检索结果进行二次排序优化

混合检索

结合语义检索和关键词检索

核心观点

1. RAG 是上下文选择的核心方法：
   • 弥补模型知识局限
   • 提供时效和准确的信息
   • 知识来源可追溯
2. 分块质量决定检索效果：
   • 保持语义完整性
   • 大小适中（200-1000 Token 常见）
   • 根据内容类型选择策略
3. 嵌入是语义搜索的基础：
   • 选择适合领域的嵌入模型
   • 查询增强提升检索效果
   • 注意多语言和长尾问题
4. 重排序显著提升相关性：
   • 两阶段架构：召回 + 精排
   • 交叉编码器效果最佳
   • 平衡效果与成本
5. 混合检索已成标准：
   • 结合语义与关键词优势
   • RRF 是常用融合方法
   • 配合查询转换更强大

常见误区

• 误区一：语义检索可以解决所有问题 正解：关键词检索对专有名词更有效，应混合使用
• 误区二：分块越小越精确 正解：太小会丢失上下文，需要平衡
• 误区三：检索到就能用好 正解：还需要通过提示词引导模型正确利用

实践建议

1. 从基础 RAG 开始：先实现基本流程，再逐步优化
2. 关注分块策略：这是影响最大的环节之一
3. 引入混合检索：可快速提升效果
4. 添加重排序：在基础效果稳定后引入
5. 持续评估迭代：收集失败案例，针对性优化

检索系统核心指标一览

指标维度

指标名称

典型目标值（示意）

说明

性能

端到端延迟 (P99)

取决于产品形态

包含检索、排序、生成全流程

检索延迟 (P99)

取决于索引与规模

仅检索环节耗时

吞吐量 (QPS)

视场景定

系统每秒处理请求数

质量

Recall@K

以基线提升为目标

前 K 个结果中包含正确答案的比例

MRR（平均倒数排名）

以基线提升为目标

正确答案在结果列表中的排名优劣

准确率 (Precision)

以基线提升为目标

检索结果的有效性（信噪比）

成本

单次查询成本

以账单与压测为准

包含 Embedding、存储和 LLM 生成成本

索引构建成本

视数据量

初始向量化和存储的费用

7.1.1 为什么需要结构化

1.消除歧义: 2.提升理解:帮助快速定位和理解信息 3.便于维护:结构化内容更容易更新和管理 4.支持模块化:支持独立修改和测试

7.1.2 结构化的基本原则

• 分类清晰 将内容按功能分类:指令,知识,示例,约束
• 层次分明: 重要高层信息在前,支撑细节信息在后
• 边界分明
• 关系显式

7.1.3 上下文的经典结构

7.1.4 结构化的实现方式

最简单的方式:分隔符

常用分隔符:

• Markdown标题:###标题###
• 分隔线:—或者===
• 块标记:[BEGIN]…[END]

使用标签(见7.2 XML标签和指令分层)

使用结构化配置格式

对于复杂配置或者需要程序处理的场景

1
2
3
4
5

{
  "role": "技术顾问",
  "constraints": ["只回答技术问题", "使用中文"],
  "knowledge": { ... }
}

7.1.5 架构设计的考量

信息位置

不同位置的信息模型的关注度不同

• 开头和结尾更受关注,存在中间丢失问日

策略:重要指令放开头;关键约束放在结尾重申;长知识块放中间

冗余与精简

结构化标记本身也占用token,需要在清晰度和效率中间trade-off 策略:使用简洁标记;避免过深嵌套;必要时合并相似类别

模式适配

7.1.6 结构化的效果验证

方法:

1. 指令遵循测试:能否正确理解和执行结构化指令
2. 信息定位测试:能够准确引用不同区块的信息
3. 边界测试:能够区分不同区块的内容

7.2 XML标签与指令分层

7.2.1 XML标签的优势

1. 边界信息
2. 可嵌套
3. 自描述
4. 模型友好

7.2.2 基本用法

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

<system_instructions>
你是一个专业的数据分析师，擅长解读商业数据。
</system_instructions>

<context>
以下是本季度的销售数据：
...
</context>

<user_query>
请分析销售趋势并给出建议。
</user_query>

7.2.3 常见标签体系

7.2.4 嵌套结构

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

<system>
  <role>你是一个代码审查助手</role>
  <capabilities>
    <item>代码质量分析</item>
    <item>安全漏洞检测</item>
    <item>性能优化建议</item>
  </capabilities>
  <constraints>
    <item>只分析提交的代码</item>
    <item>不执行代码</item>
  </constraints>
</system>

<code_to_review language="python">
def calculate_sum(numbers):
    return sum(numbers)
</code_to_review>