当前位置：首页 > news >正文

深度解析AI Agent的上下文管理：长对话记忆与信息压缩技术实践

news 2026/7/9 23:45:09

深度解析AI Agent的上下文管理：长对话记忆与信息压缩技术实践

引言

1.1 背景介绍：为什么上下文管理是AI Agent的“大脑皮层前额叶”？

如果把当前主流的大语言模型（Large Language Models, LLMs）比作大脑的海马体与布洛卡/韦尼克语言区的混合体——它能存储数十亿参数化的“静态知识图谱碎片”，能流畅地理解和生成自然语言，能处理短篇幅内的复杂逻辑推导——那它离真正具备自主决策、持续交互、长期目标追踪能力的通用人工智能（Artificial General Intelligence, AGI），还缺了一块至关重要的硬件/软件协同组件：大脑皮层前额叶。

前额叶皮质在人类认知中的核心作用，正是长时记忆的检索与整合、短期工作记忆的维持与更新、目标优先级的分配、以及对无关信息的抑制与压缩。放到AI Agent的语境中，这恰好就是我们常说的**上下文管理（Context Management）**系统的全部职责。

回溯LLM应用的发展历史：

早期的“单轮对话式问答机器人”（如GPT-3初期的API试用版）根本不具备任何上下文感知能力——你上一句问“今天北京的天气怎么样？”，下一句问“明天呢？”，它会完全遗忘“北京”这个核心锚点，只能返回通用的“明天天气无法预测”或“你需要指定具体城市”的回复。
中期的“多轮对话式聊天助手”（如ChatGPT-3.5的4k版本、Claude 1.3的100k版本的原始体验）虽然引入了**“滑动窗口式的全量上下文拼接”**（Full Context Window Concatenation with Sliding），但这种“粗暴”的方法存在两个致命缺陷：
1. 硬件成本的指数级增长：2023年Claude 1.3的200k（约150万汉字）上下文窗口的推理成本，是同期ChatGPT-3.5的4k窗口的50倍以上，是GPT-4 8k窗口的25倍以上；即使是硬件技术飞速迭代的今天（202X年Q2），支持1M+（约750万汉字）全量窗口的LLM推理API（如GPT-4 Turbo 128k的“升级版企业内部专用模型”、Claude 3 Opus的200k/Anthropic Claude 3.5 Sonnet的400k的商业版、以及国内的通义千问4.0 Max 128k、文心一言4.0 Turbo 128k），其推理延迟和硬件资源消耗，仍然是普通开发者和C端用户无法长期承受的奢侈品。
2. LLM自身的“信息遗忘症”与“注意力稀释症”：斯坦福大学在2023年7月发表的经典论文《Lost in the Middle: How Language Models Use Long Contexts》[1]中，通过严谨的实验证明了：即使是支持100k全量窗口的Claude 1.3，当测试信息被放置在上下文窗口的前20%或后20%区域时，其检索准确率可以达到90%以上；但当测试信息被放置在中间60%区域时，检索准确率会暴跌至30%以下——这就像人类在阅读一本1000页的书时，只能记住开头和结尾的部分，中间的内容完全“过目即忘”；同时，即使检索准确率勉强维持在可接受的范围内，当窗口长度超过16k时，LLM的多轮对话逻辑连贯性、数学推理准确性、代码生成正确性都会出现线性或非线性的显著下降——这是因为LLM的自注意力机制（Self-Attention）的计算复杂度是O(n²d)（其中n是上下文长度，d是模型维度），当n呈指数级增长时，计算资源的分配会导致每个Token的有效注意力权重被严重稀释，模型无法准确捕捉长程的语义关联。

正是在这样的背景下，AI Agent的上下文管理系统应运而生——它不再依赖LLM原生的全量滑动窗口，而是通过**“分层记忆架构”、“长对话记忆编码与检索”、“信息压缩与摘要生成”三大核心技术，在有限的硬件成本与LLM注意力容量下，实现了对无限长对话历史**的有效管理，让AI Agent真正具备了“前额叶功能”。

1.2 核心问题：本文要回答的5个关键问题

为了帮助读者从“知其然”到“知其所以然”，再到“能动手实践”，本文将系统性地回答以下5个核心问题：

核心概念层：什么是AI Agent的上下文管理系统？它与LLM原生的上下文窗口有什么本质区别？它的核心组成要素有哪些？它们之间的关系是什么？
理论原理层：分层记忆架构的理论依据是什么？长对话记忆编码与检索的主流技术（如向量检索、图检索、混合检索）的数学模型是什么？信息压缩与摘要生成的核心算法（如MCTS引导的摘要、基于注意力的压缩、基于知识图谱的结构化压缩）的工作流程是什么？
技术选型层：不同场景下（如C端聊天助手、B端客服机器人、科研辅助Agent、代码开发Agent），应该如何选择合适的分层记忆架构、编码检索技术、压缩摘要技术？它们的优缺点有哪些？
动手实践层：如何从零开始搭建一个轻量级但功能完整的AI Agent上下文管理系统？系统的架构设计是什么？核心实现代码是什么？如何与主流的LLM API（如OpenAI GPT-4 Turbo 128k、Anthropic Claude 3.5 Sonnet 400k、通义千问4.0 Max 128k）、向量数据库（如ChromaDB、Pinecone、Weaviate、Milvus）、图数据库（如Neo4j、NebulaGraph）进行集成？
最佳实践与未来趋势层：AI Agent上下文管理系统的最佳实践有哪些？常见的坑有哪些？如何避免？当前的技术瓶颈是什么？未来的发展趋势是什么？

1.3 文章脉络：本文的讲解思路与结构

为了让读者能够循序渐进地学习，本文将采用深度剖析/原理讲解型文章结构，并结合大量的图表、数学公式、代码示例、实际场景应用来组织内容。具体的章节安排如下：

引言：介绍背景、核心问题、文章脉络。
基础概念与术语解释：解释AI Agent、上下文、上下文窗口、分层记忆、工作记忆、短期记忆、长期记忆、向量检索、图检索、混合检索、向量数据库、图数据库、摘要生成、信息压缩等核心概念。
分层记忆架构的理论依据与核心设计：介绍人类认知的记忆模型（阿特金森-希弗林记忆模型、巴德利工作记忆模型），以及AI Agent分层记忆架构的主流设计（如LangChain的ConversationBufferMemory、ConversationSummaryMemory、ConversationBufferWindowMemory、ConversationKGMemory、ConversationVectorStoreMemory的组合；AutoGPT的分层记忆；MetaGPT的分层记忆）。
长对话记忆编码与检索的核心技术：介绍向量编码的主流模型（如OpenAI text-embedding-3-small/large、Cohere Embed v3、HuggingFace的sentence-transformers/all-mpnet-base-v2、bge-large-zh-v1.5），向量检索的数学模型（余弦相似度、点积相似度、欧氏距离、LSH局部敏感哈希、HNSW分层小世界图、FAISS的IVFFlat/IVFPQ），图检索的数学模型（子图匹配、图神经网络GNN的节点/边/子图嵌入），以及混合检索的主流方法（如重排序Rerank、混合相似度融合）。
信息压缩与摘要生成的核心技术：介绍信息压缩的数学模型（如香农熵、编码压缩率），基于规则的信息压缩与摘要生成（如关键词提取、句子排序），基于LLM的信息压缩与摘要生成（如单轮摘要、多轮递归摘要、MCTS引导的摘要），基于知识图谱的结构化压缩与摘要生成（如实体关系提取、知识图谱构建、知识图谱查询）。
从零开始搭建一个轻量级AI Agent上下文管理系统：介绍项目介绍、环境安装、系统架构设计、系统接口设计、系统核心实现代码、与主流LLM API和向量数据库的集成、实际场景测试（如科研辅助Agent的长对话管理）。
最佳实践、常见问题与未来趋势：介绍最佳实践（如分层记忆的阈值设置、检索结果的重排序、压缩摘要的质量评估、隐私保护），常见问题（如检索准确率低、压缩摘要丢失关键信息、长对话逻辑连贯性差、硬件成本高），未来趋势（如端侧向量数据库、自适应分层记忆、多模态上下文管理、与AGI原生记忆的融合）。
总结与回顾：总结文章的核心内容和关键结论，展望未来的发展方向。

2. 基础概念与术语解释

在深入讲解AI Agent上下文管理的核心技术之前，我们需要先明确一些基础概念和术语的定义——这些概念和术语是后续所有讨论的基础，只有准确理解了它们，才能真正掌握AI Agent上下文管理的精髓。

2.1 AI Agent的定义

关于AI Agent的定义，学术界和工业界目前还没有一个统一的标准，但普遍认为，AI Agent是一种**能够感知环境（Perceive Environment）、做出决策（Make Decisions）、执行行动（Execute Actions）、并从反馈中学习（Learn from Feedback）**的自主智能体。

根据不同的分类标准，AI Agent可以分为不同的类型：

按感知和行动的范围分类：
- 单模态AI Agent：只能感知和处理一种模态的信息（如文本、图像、音频、视频），例如文本聊天机器人、图像识别Agent。
- 多模态AI Agent：能够感知和处理多种模态的信息，例如能够同时分析文本、图像、音频的智能客服机器人。
按决策的方式分类：
- 反应式AI Agent（Reactive Agent）：没有记忆能力，只能根据当前的感知做出决策，例如早期的单轮对话式问答机器人、扫地机器人的碰撞传感器驱动模式。
- 基于状态的AI Agent（State-based Agent）：有有限的记忆能力，能够存储当前的状态，并根据当前的感知和状态做出决策，例如具有滑动窗口记忆的多轮对话式聊天助手。
- 基于目标的AI Agent（Goal-based Agent）：有明确的目标，能够根据当前的感知、状态和目标做出决策，例如能够帮你预订机票和酒店的旅行规划Agent。
- 基于效用的AI Agent（Utility-based Agent）：有明确的效用函数（Utility Function），能够根据当前的感知、状态、目标和效用函数做出最优决策，例如能够帮你选择性价比最高的机票和酒店的旅行规划Agent。
- 学习型AI Agent（Learning Agent）：能够从环境的反馈中学习，不断优化自己的决策和行动，例如能够根据用户的反馈不断调整回复风格的聊天机器人、能够不断提高扫地效率的扫地机器人。
按应用场景分类：
- C端AI Agent：面向普通消费者的AI Agent，例如ChatGPT、Claude、通义千问的聊天助手、智能音箱、智能扫地机器人。
- B端AI Agent：面向企业的AI Agent，例如智能客服机器人、智能销售机器人、智能财务机器人、智能人力资源机器人、智能科研辅助Agent、智能代码开发Agent。

2.2 上下文（Context）的定义

在自然语言处理（Natural Language Processing, NLP）和AI Agent的语境中，上下文（Context）是指能够帮助理解和生成当前文本/对话的所有相关信息。

具体来说，上下文可以分为以下几类：

语言上下文（Linguistic Context）：当前文本/对话之前的所有文本/对话内容，例如“今天北京的天气怎么样？明天呢？”中的“今天北京的天气怎么样？”就是语言上下文。
情景上下文（Situational Context）：当前文本/对话发生的时间、地点、人物、事件等情景信息，例如用户在上午9点在公司电脑上问“今天中午吃什么？”时，“上午9点”、“公司”就是情景上下文。
用户上下文（User Context）：用户的个人信息、偏好、历史行为、技能水平等信息，例如用户是一位程序员，喜欢吃辣，历史上多次购买过川菜的外卖，技能水平是Python高级开发工程师，这些就是用户上下文。
领域上下文（Domain Context）：当前文本/对话所属的领域的专业知识，例如用户是一位医生，问“如何治疗高血压？”时，高血压的病因、症状、治疗方法等专业知识就是领域上下文。

在本文中，我们主要关注的是语言上下文的管理——因为语言上下文是AI Agent在多轮对话中最常遇到的上下文类型，也是最难管理的上下文类型；当然，我们也会在适当的地方提及情景上下文、用户上下文、领域上下文的管理方法。

2.3 上下文窗口（Context Window）的定义

上下文窗口（Context Window）是指LLM在一次推理过程中能够处理的最大Token数量——Token是LLM处理文本的基本单位，通常一个英文单词对应1-2个Token，一个中文汉字对应2-3个Token（不同的LLM的Tokenization规则不同，例如OpenAI的GPT-4 Turbo使用的是tiktoken cl100k_base规则，Claude 3.5 Sonnet使用的是Anthropic的自定义规则，通义千问4.0 Max使用的是Qwen的自定义规则）。

例如：

GPT-3.5的原始版本的上下文窗口是4k Tokens（约3000个英文单词或1500个中文汉字）。
GPT-3.5 Turbo 16k的上下文窗口是16k Tokens（约12000个英文单词或6000个中文汉字）。
GPT-4 Turbo 128k的上下文窗口是128k Tokens（约96000个英文单词或48000个中文汉字）。
Anthropic Claude 3.5 Sonnet的上下文窗口是400k Tokens（约300000个英文单词或150000个中文汉字）。
通义千问4.0 Max的上下文窗口是128k Tokens（约96000个英文单词或48000个中文汉字）。

需要注意的是，上下文窗口的大小并不等于LLM能够有效利用的信息数量——正如我们在引言中提到的斯坦福大学的论文《Lost in the Middle: How Language Models Use Long Contexts》所证明的那样，当测试信息被放置在上下文窗口的中间60%区域时，LLM的检索准确率会暴跌至30%以下；同时，当窗口长度超过16k时，LLM的多轮对话逻辑连贯性、数学推理准确性、代码生成正确性都会出现显著下降。

2.4 分层记忆架构（Hierarchical Memory Architecture）的定义

分层记忆架构（Hierarchical Memory Architecture）是AI Agent上下文管理系统的核心设计思想——它借鉴了人类认知的记忆模型（阿特金森-希弗林记忆模型、巴德利工作记忆模型），将AI Agent的记忆分为不同的层次，每个层次存储不同类型、不同时效性、不同重要性的信息，并通过编码、存储、检索、压缩、更新五大核心机制，实现对记忆的有效管理。

根据不同的设计，分层记忆架构可以分为3层、4层、5层甚至更多层，但最常见的是4层架构：

感觉记忆层（Sensory Memory Layer）：存储AI Agent刚刚感知到的原始信息（如文本、图像、音频、视频的原始数据），时效性非常短（通常只有几毫秒到几秒钟），重要性非常低，除非被进一步处理，否则会立即被丢弃。
工作记忆层（Working Memory Layer）：存储AI Agent当前正在处理的信息（如当前的对话内容、当前的任务目标、当前的检索结果），时效性较短（通常只有几分钟到几小时），重要性较高，存储容量有限（通常与LLM的有效工作窗口大小相当，例如16k-32k Tokens）。
短期记忆层（Short-term Memory Layer）：存储AI Agent最近一段时间内处理过的信息（如最近几天的对话内容、最近完成的几个任务），时效性中等（通常只有几天到几周），重要性中等，存储容量较大（通常可以存储几万到几十万Tokens）。
长期记忆层（Long-term Memory Layer）：存储AI Agent认为非常重要的信息（如用户的核心偏好、用户的历史重要事件、领域的核心专业知识、AI Agent的核心经验教训），时效性非常长（通常可以永久存储），重要性非常高，存储容量几乎无限（取决于存储介质的大小，例如硬盘、云存储）。

2.5 向量检索（Vector Retrieval）的定义

向量检索（Vector Retrieval），也称为语义检索（Semantic Retrieval），是一种基于文本/图像/音频/视频的语义相似度进行检索的技术——它的核心思想是：首先，使用向量编码模型（Embedding Model）将所有的候选信息（如长期记忆层中的所有对话片段、所有文档）和查询信息（如用户当前的问题、AI Agent当前的任务目标）编码成高维稠密向量（High-dimensional Dense Vector）；然后，使用向量相似度算法（Vector Similarity Algorithm）计算查询向量与所有候选向量之间的相似度；最后，返回相似度最高的Top-K个候选信息。

与传统的关键词检索（Keyword Retrieval）（如BM25算法）相比，向量检索具有以下几个显著的优势：

能够理解语义：向量检索能够理解文本/图像/音频/视频的语义，而不仅仅是关键词——例如，当用户的查询是“如何制作苹果派？”时，关键词检索只能返回包含“苹果派”、“制作”等关键词的候选信息；而向量检索不仅能返回包含这些关键词的候选信息，还能返回包含“苹果蛋糕”、“烘焙苹果甜点”等语义相近的关键词的候选信息，甚至能返回包含“苹果派的配方”、“苹果派的步骤”等不直接包含“制作”但语义相关的候选信息。
能够处理多模态信息：向量检索不仅能处理文本信息，还能处理图像、音频、视频等多模态信息——例如，当用户的查询是一张苹果派的图片时，向量检索能先将这张图片编码成高维稠密向量，然后再与所有候选文本/图像/音频/视频的向量进行相似度计算，返回最相关的候选信息。
能够处理模糊查询：向量检索能够处理模糊查询——例如，当用户的查询是“如何做那个有苹果的甜点？”时，关键词检索可能无法返回任何有用的结果；而向量检索仍然能返回关于苹果派、苹果蛋糕、苹果酥等甜点的候选信息。

当然，向量检索也有一些缺点：

向量编码模型的质量直接影响检索准确率：如果向量编码模型的质量不高，那么编码出来的向量就无法准确地反映文本/图像/音频/视频的语义，从而导致检索准确率降低。
向量相似度算法的计算复杂度较高：当候选信息的数量非常大（例如几百万、几千万甚至几亿条）时，直接计算查询向量与所有候选向量之间的相似度的计算复杂度是O(n*d)（其中n是候选信息的数量，d是向量的维度），这在硬件资源有限的情况下是无法实现的——因此，我们需要使用**近似最近邻搜索（Approximate Nearest Neighbor Search, ANN）**算法（如LSH局部敏感哈希、HNSW分层小世界图、FAISS的IVFFlat/IVFPQ）来降低计算复杂度，提高检索速度。
无法处理精确的关键词匹配：向量检索在处理精确的关键词匹配时，可能不如传统的关键词检索——例如，当用户的查询是“如何制作‘北京王府井苹果派’？”时，关键词检索能直接返回包含“北京王府井苹果派”这个精确关键词的候选信息；而向量检索可能会返回包含“北京苹果派”、“王府井甜点”等语义相近但不精确的候选信息。

2.6 向量数据库（Vector Database）的定义

向量数据库（Vector Database）是一种专门用于存储和检索高维稠密向量的数据库——它与传统的关系型数据库（如MySQL、PostgreSQL）、NoSQL数据库（如MongoDB、Redis）不同，它的核心功能不是存储结构化或半结构化的数据，而是存储高维稠密向量，并提供高效的近似最近邻搜索（ANN）服务。

常见的向量数据库有：

开源向量数据库：
- ChromaDB：一款轻量级的开源向量数据库，非常适合用于原型开发和小规模部署，支持多种向量编码模型（如OpenAI text-embedding-3-small/large、Cohere Embed v3、HuggingFace的sentence-transformers系列模型），支持多种向量相似度算法（如余弦相似度、点积相似度、欧氏距离），支持多种数据类型的存储（如文本、图像、音频、视频及其元数据）。
- FAISS：Facebook AI Research开发的一款开源的近似最近邻搜索库，不是一个完整的向量数据库，而是一个底层的搜索库，支持多种近似最近邻搜索算法（如IVFFlat、IVFPQ、HNSW、LSH），支持多种向量相似度算法（如余弦相似度、点积相似度、欧氏距离），支持GPU加速，搜索速度非常快，非常适合用于大规模部署，但需要自己实现上层的存储和管理功能。
- Weaviate：一款开源的向量数据库，支持多种向量编码模型（如OpenAI text-embedding-3-small/large、Cohere Embed v3、HuggingFace的sentence-transformers系列模型），支持多种近似最近邻搜索算法（如HNSW、IVFFlat），支持知识图谱功能，支持多种数据类型的存储（如文本、图像、音频、视频及其元数据），非常适合用于需要知识图谱功能的场景。
- Milvus：一款开源的企业级向量数据库，支持多种向量编码模型（如OpenAI text-embedding-3-small/large、Cohere Embed v3、HuggingFace的sentence-transformers系列模型），支持多种近似最近邻搜索算法（如IVFFlat、IVFPQ、HNSW、LSH、DiskANN），支持GPU加速，支持分布式部署，支持多种数据类型的存储（如文本、图像、音频、视频及其元数据），搜索速度非常快，存储容量非常大，非常适合用于大规模企业级部署。
商业向量数据库：
- Pinecone：一款托管式的商业向量数据库，不需要自己安装和维护，支持多种向量编码模型（如OpenAI text-embedding-3-small/large、Cohere Embed v3、HuggingFace的sentence-transformers系列模型），支持多种近似最近邻搜索算法（如HNSW），支持GPU加速，支持分布式部署，搜索速度非常快，存储容量非常大，非常适合用于大规模企业级部署，但价格相对较高。
- Zilliz Cloud：Milvus的托管式商业版本，由Milvus的开发公司Zilliz提供，具有Milvus的所有功能，不需要自己安装和维护，支持多种向量编码模型，支持多种近似最近邻搜索算法，支持GPU加速，支持分布式部署，搜索速度非常快，存储容量非常大，非常适合用于大规模企业级部署，价格相对Pinecone较低。
- 阿里云向量检索（Vector Search）：阿里云提供的托管式向量检索服务，支持多种向量编码模型（如OpenAI text-embedding-3-small/large、通义千问的text-embedding-v2/v3系列模型），支持多种近似最近邻搜索算法（如HNSW、IVFFlat），支持GPU加速，支持分布式部署，搜索速度非常快，存储容量非常大，非常适合用于国内的大规模企业级部署。
- 腾讯云向量数据库（Tencent Vector Database, TVD）：腾讯云提供的托管式向量数据库服务，支持多种向量编码模型（如OpenAI text-embedding-3-small/large、腾讯混元的text-embedding系列模型），支持多种近似最近邻搜索算法（如HNSW、IVFFlat），支持GPU加速，支持分布式部署，搜索速度非常快，存储容量非常大，非常适合用于国内的大规模企业级部署。

2.7 图检索（Graph Retrieval）的定义

图检索（Graph Retrieval）是一种基于图结构进行检索的技术——它的核心思想是：首先，将所有的候选信息（如长期记忆层中的所有对话片段、所有文档）编码成知识图谱（Knowledge Graph）或语义网络（Semantic Network）（由节点和边组成，节点表示实体或概念，边表示实体或概念之间的关系）；然后，将查询信息（如用户当前的问题、AI Agent当前的任务目标）编码成查询子图（Query Subgraph）；最后，使用**子图匹配算法（Subgraph Matching Algorithm）或图神经网络（Graph Neural Network, GNN）**在知识图谱或语义网络中检索与查询子图最相似的Top-K个子图或节点。

与向量检索相比，图检索具有以下几个显著的优势：

能够处理结构化的信息：图检索能够处理实体、概念之间的结构化关系，而不仅仅是语义相似度——例如，当用户的查询是“谁是《哈利·波特》的作者？他还写过哪些书？”时，向量检索可能能返回《哈利·波特》的作者是J.K.罗琳，以及她写过的一些书，但可能无法准确地返回所有她写过的书；而图检索能在知识图谱中找到“《哈利·波特》”节点，通过“作者”边找到“J.K.罗琳”节点，再通过“作品”边找到所有她写过的书的节点，返回结果非常准确。
能够进行复杂的逻辑推理：图检索能够进行复杂的逻辑推理——例如，当用户的查询是“谁是《哈利·波特》的作者的配偶？他/她的职业是什么？”时，向量检索可能无法返回准确的结果；而图检索能在知识图谱中找到“《哈利·波特》”节点→“作者”边→“J.K.罗琳”节点→“配偶”边→“尼尔·默里”节点→“职业”边→“医生”节点，返回结果非常准确。
能够解释检索结果：图检索的检索结果是可解释的——因为它能显示出检索的路径（如“《哈利·波特》→作者→J.K.罗琳→配偶→尼尔·默里→职业→医生”），用户可以清楚地知道为什么会返回这个结果；而向量检索的检索结果是不可解释的——因为它只是返回相似度最高的Top-K个候选信息，用户无法清楚地知道为什么会返回这些结果。

当然，图检索也有一些缺点：

知识图谱的构建成本较高：图检索的前提是要有一个高质量的知识图谱，而高质量的知识图谱的构建成本非常高——需要大量的人工标注或高质量的实体关系提取模型。
知识图谱的更新成本较高：知识图谱需要不断地更新，否则会出现信息过时的问题——而知识图谱的更新成本也非常高。
子图匹配算法的计算复杂度较高：当知识图谱的规模非常大（例如几百万、几千万甚至几亿个节点和边）时，子图匹配算法的计算复杂度是指数级的，这在硬件资源有限的情况下是无法实现的——因此，我们需要使用近似子图匹配算法或图神经网络的节点/边/子图嵌入来降低计算复杂度，提高检索速度。
无法处理非结构化的信息：图检索在处理非结构化的信息（如没有明确实体和关系的文本、图像、音频、视频）时，可能不如向量检索。

2.8 图数据库（Graph Database）的定义

图数据库（Graph Database）是一种专门用于存储和检索图结构数据的数据库——它与传统的关系型数据库、NoSQL数据库、向量数据库不同，它的核心功能不是存储结构化/半结构化/非结构化的数据或高维稠密向量，而是存储节点和边，并提供高效的图查询、图遍历、子图匹配、图神经网络推理等服务。

常见的图数据库有：

开源图数据库：
- Neo4j Community Edition：一款非常流行的开源图数据库，支持Cypher查询语言（一种专门用于图查询的声明式语言，类似于SQL），支持多种图算法（如最短路径算法、社区发现算法、中心性算法），支持知识图谱功能，非常适合用于原型开发和小规模部署。
- NebulaGraph：一款开源的企业级图数据库，支持nGQL查询语言（一种类似于SQL和Cypher的声明式图查询语言），支持多种图算法，支持分布式部署，支持GPU加速，查询速度非常快，存储容量非常大，非常适合用于大规模企业级部署。
- JanusGraph：一款开源的分布式图数据库，支持多种存储后端（如Apache Cassandra、Apache HBase、Google Cloud Bigtable），支持多种索引后端（如Elasticsearch、Apache Solr、Lucene），支持Gremlin查询语言（一种通用的图遍历语言），支持多种图算法，支持分布式部署，存储容量非常大，非常适合用于大规模分布式部署。
商业图数据库：
- Neo4j Enterprise Edition：Neo4j Community Edition的商业版本，具有Neo4j Community Edition的所有功能，还支持分布式部署、高可用性、安全审计、性能优化等企业级功能，非常适合用于大规模企业级部署。
- NebulaGraph Enterprise Edition：NebulaGraph的商业版本，具有NebulaGraph的所有功能，还支持高可用性、安全审计、性能优化、可视化工具等企业级功能，非常适合用于大规模企业级部署。
- 阿里云图数据库GDB：阿里云提供的托管式图数据库服务，支持Gremlin查询语言、Cypher查询语言、nGQL查询语言，支持多种图算法，支持分布式部署，查询速度非常快，存储容量非常大，非常适合用于国内的大规模企业级部署。
- 腾讯云图数据库TGDB：腾讯云提供的托管式图数据库服务，支持Gremlin查询语言、Cypher查询语言，支持多种图算法，支持分布式部署，查询速度非常快，存储容量非常大，非常适合用于国内的大规模企业级部署。

2.9 混合检索（Hybrid Retrieval）的定义

混合检索（Hybrid Retrieval）是一种将关键词检索、向量检索、图检索等多种检索技术结合起来的检索技术——它的核心思想是：取长补短，充分发挥每种检索技术的优势，避免每种检索技术的劣势，从而提高检索的准确率和召回率。

常见的混合检索方法有：

关键词检索+向量检索的混合：这是最常见的混合检索方法——首先，使用关键词检索（如BM25算法）和向量检索分别检索出Top-K个候选信息；然后，使用重排序模型（Rerank Model）（如CrossEncoder模型、LLM）对这2K个候选信息进行重新排序；最后，返回重新排序后的Top-K个候选信息。
向量检索+图检索的混合：这种混合检索方法适合用于需要同时处理语义相似度和结构化关系的场景——首先，使用向量检索检索出与查询信息语义最相似的Top-K个候选节点/子图；然后，使用图检索在这些候选节点/子图的周围进行图遍历，找到更多相关的节点/子图；最后，使用重排序模型对这些候选节点/子图进行重新排序，返回Top-K个候选信息。
关键词检索+向量检索+图检索的混合：这种混合检索方法适合用于需要同时处理精确关键词匹配、语义相似度和结构化关系的场景——首先，使用关键词检索、向量检索、图检索分别检索出Top-K个候选信息；然后，使用重排序模型对这3K个候选信息进行重新排序；最后，返回重新排序后的Top-K个候选信息。

2.10 信息压缩（Information Compression）的定义

信息压缩（Information Compression）是一种在不丢失或尽可能少丢失关键信息的前提下，减少信息的存储容量或传输带宽的技术——它的核心思想是：去除冗余信息，保留关键信息。

根据不同的分类标准，信息压缩可以分为不同的类型：

按是否丢失关键信息分类：
- 无损压缩（Lossless Compression）：压缩后的信息可以完全恢复成原始信息，没有任何关键信息的丢失——例如，ZIP压缩、RAR压缩、PNG图像压缩、FLAC音频压缩。
- 有损压缩（Lossy Compression）：压缩后的信息无法完全恢复成原始信息，会有一些关键信息的丢失，但这些丢失的关键信息通常是人类或LLM无法感知或不重要的——例如，JPEG图像压缩、MP3音频压缩、MP4视频压缩、文本摘要生成。
  在AI Agent的上下文管理系统中，我们主要使用的是有损压缩——因为无损压缩的压缩率通常较低（例如ZIP压缩的压缩率通常只有2:1到10:1），而有损压缩的压缩率通常较高（例如文本摘要生成的压缩率可以达到10:1到100:1甚至更高），能够更有效地减少信息的存储容量和LLM的输入长度。
按压缩的对象分类：
- 文本信息压缩：压缩的对象是文本信息——例如，关键词提取、句子排序、文本摘要生成。
- 图像信息压缩：压缩的对象是图像信息——例如，JPEG图像压缩、PNG图像压缩。
- 音频信息压缩：压缩的对象是音频信息——例如，MP3音频压缩、FLAC音频压缩。
- 视频信息压缩：压缩的对象是视频信息——例如，MP4视频压缩、AVI视频压缩。
  在本文中，我们主要关注的是文本信息压缩——因为文本信息是AI Agent在多轮对话中最常遇到的信息类型，也是最难压缩的信息类型；当然，我们也会在适当的地方提及多模态信息压缩的方法。

2.11 摘要生成（Summarization）的定义

摘要生成（Summarization）是一种将长文本/长对话压缩成短文本/短对话，同时保留关键信息的技术——它是文本信息压缩的一种重要形式。

根据不同的分类标准，摘要生成可以分为不同的类型：

按摘要的生成方式分类：
- 抽取式摘要（Extractive Summarization）：从原始文本/原始对话中抽取一些关键的句子或短语，组成摘要——例如，TextRank算法、BM25算法、基于图的抽取式摘要算法。
- 生成式摘要（Abstractive Summarization）：根据原始文本/原始对话的语义，生成一些新的句子或短语，组成摘要——例如，基于Transformer的生成式摘要模型（如GPT-4 Turbo、Claude 3.5 Sonnet、通义千问4.0 Max、BART、T5）、MCTS引导的生成式摘要算法。
  在AI Agent的上下文管理系统中，我们主要使用的是生成式摘要——因为抽取式摘要的压缩率通常较低，而且生成的摘要可能不够流畅，不够连贯；而生成式摘要的压缩率通常较高，而且生成的摘要通常比较流畅，比较连贯。
按摘要的内容分类：
- 单文档摘要（Single-document Summarization）：压缩的对象是单个文档——例如，将一篇10000字的论文压缩成一篇1000字的摘要。
- 多文档摘要（Multi-document Summarization）：压缩的对象是多个文档——例如，将10篇关于“AI Agent上下文管理”的论文压缩成一篇2000字的综述摘要。
- 对话摘要（Conversational Summarization）：压缩的对象是多轮对话——例如，将一段100轮的用户与AI Agent的对话压缩成一段500字的摘要。
  在本文中，我们主要关注的是对话摘要——因为对话摘要是AI Agent在多轮对话中最常遇到的摘要生成类型，也是最难生成的摘要生成类型。