近日，腾讯研究院联合复旦大学发布了名为 “CL-bench” 的基准测试，其结果给如火如荼的大语言模型（LLM）应用泼了一盆现实的冷水：在需要完全从上下文（Context）中学习新知识、新规则的 1899 个任务上，参与测试的 19 个顶尖模型平均成功率仅为17.2%，表现最佳的 GPT-5.1 也仅达到 23.7%。这意味着，即使将所有必要信息都 “喂” 给模型，它仍有超过四分之三的概率无法正确理解并运用。这项研究直指当前 AI 系统的核心软肋 ——上下文学习（Context Learning）瓶颈。
这一瓶颈并非学术玩具，它直接导致了 LLM 在真实业务场景中的 “水土不服”。例如，在根据一份新拟定的、虚构的金融法规回答合规问题时，或在理解一个全新的内部工作流程后执行步骤，模型往往表现得像一位 “心不在焉的专家”，要么忽略关键细节，要么错误套用旧有知识。腾讯的论文指出，模型的失败主要源于三种模式：忽略或误用提供的上下文、在长上下文中依赖关系跟踪能力下降，以及面对全新数据模式时归纳推理能力不足。换言之，模型过于依赖静态的预训练知识，而缺乏从动态提供的上下文中进行有效学习、推理和执行的 “现场适应能力”。
瓶颈根源：静态知识与动态需求的脱节
问题的本质在于，当前主流 LLM 的架构和工作模式，与 “上下文学习” 所要求的动态性存在根本性错配。模型在预训练阶段学习了海量的静态知识关联，但在推理时，它更像一个基于庞大记忆库的 “模式匹配器”，而非一个灵活的 “问题解决者”。当上下文信息与内部知识冲突、或完全新颖时，模型固有的偏好是倾向于其训练数据中的统计规律，而非眼前的事实。此外，随着上下文长度和复杂度的增加，模型对信息位置的敏感性（如 “迷失在中间” 效应）和长距离依赖建模的局限性会进一步放大这一缺陷。
单纯扩大上下文窗口（如支持 128K 甚至 1M tokens）只是提供了 “场地”，并未解决模型在场地内 “有效组织信息” 的能力问题。这正是检索增强生成（RAG）技术被寄予厚望的原因。然而，传统的扁平化 RAG（将文档切块后统一检索）在面对复杂、结构化的知识库时，同样会陷入检索噪声大、关键信息被稀释的困境，无法从根本上提升模型的上下文学习效能。
工程破局：分层检索与动态上下文优化
要突破这一瓶颈，我们需要从 RAG 系统工程的角度进行双重升级：一是引入分层检索（Hierarchical RAG, HRAG） 架构，优化信息供给的 “质”；二是实施动态上下文窗口优化，精准控制信息供给的 “量” 与 “序”。
1. 分层检索：构建知识的 “导航地图”
分层检索的核心思想是模仿人类查阅手册的过程：先看目录（摘要）定位章节，再翻阅具体页面（细节）。技术上，它通过构建多层级的向量索引来实现：
- 摘要层索引：为每个文档或知识单元生成高质量的摘要（如利用 LLM 提取核心主张、实体、关系），并为之建立向量索引。此层索引体积小，旨在快速定位相关文档范畴。
- 块层索引：对文档进行细致的语义切块，并为每个块建立向量索引，同时关联其所属的上级文档元数据。
检索时，流程变为两阶段：
- 粗筛：用查询语句在摘要层索引中进行检索，找出最相关的若干个（如 Top-3）文档或知识单元。
- 精查：仅在上一步选定的文档范围内，于块层索引中进行二次检索，获取最相关的具体文本块。
这种方式极大地提升了检索的信噪比。腾讯论文中指出的模型 “忽略上下文” 问题，部分原因正是检索结果中混入了大量不相关的干扰信息，导致关键信号被淹没。分层检索通过前置的摘要过滤，确保了输入模型的上下文主体与问题高度相关，为模型的有效学习奠定了基础。
2. 动态上下文窗口优化：实现 “按需配送”
在确定了要输送哪些知识（检索结果）后，如何将它们组织并填充进有限的上下文窗口，是另一个关键工程决策。固定长度的上下文拼接策略（如总是返回前 5 个块）是低效的，动态优化策略则根据本次查询的复杂度和检索结果的质量，智能决定窗口参数：
- 动态长度与文档数：对于简单的、事实型查询，可限制上下文总长度（如 1500 字符）和文档数量（如 2 个），避免冗余。对于复杂的、需要多步推理或综合多源信息的查询，则允许更长的上下文（如 4000 字符）和更多的文档（如 5 个）。
- 智能填充率：并非总是将检索到的所有块内容完整填入。可以设定一个目标填充率（例如 0.6，即占用 60% 的可用上下文窗口），并优先填充相关性分数最高的内容。剩余空间可预留给系统指令、对话历史或模型思考的 “暂存区”。
- 重排序与压缩集成：在将检索块送入最终上下文前，可引入交叉编码器（Cross-Encoder）进行重排序，确保最相关的信息排在更靠前、更不易被模型忽略的位置。对于较长的文本块，可以使用 LLM 进行摘要压缩，在保留核心信息的前提下节省令牌。
通过将分层检索与动态窗口优化相结合，我们构建的 RAG 系统能够为 LLM 提供一份高相关、高密度、结构清晰的 “学习材料”，从而显著改善其上下文学习的表现。
可落地参数配置与监控清单
理论需付诸实践。以下是一份可供工程团队参考的核心参数配置与监控要点清单：
分层检索配置清单：
| 组件 | 配置项 | 推荐值 / 选项 | 说明 |
|---|---|---|---|
| 摘要层 | 摘要生成模型 | GPT-4o-mini, Claude Haiku | 平衡质量、速度与成本 |
| 向量数据库 | Milvus, Pinecone | 支持大规模向量检索 | |
| 粗筛返回数量 (Top-K1) | 3 - 5 | 控制进入精查的范围 | |
| 块层 | 分块策略 | 语义分块（递归式） | 避免割裂完整语义 |
| 块大小 | 512 - 1024 字符 | 根据模型窗口权衡 | |
| 向量数据库 | FAISS, Chroma | 可与摘要层不同 | |
| 精查返回数量 (Top-K2) | 3 - 8 | 最终送入窗口的候选块 |
动态上下文窗口优化参数：
| 查询类型 | 最大上下文长度 | 最大文档数 | 目标填充率 | 动作 |
|---|---|---|---|---|
| 简单事实查询 | ≤ 2000 字符 | 2 | 0.4 - 0.6 | 优先使用高相关度单一块 |
| 中等复杂度分析 | 2000 - 3500 字符 | 3 - 4 | 0.6 - 0.75 | 启用重排序，确保关键信息在前 |
| 复杂综合任务 | ≤ 4000 字符 | 5 | 0.75 - 0.85 | 可集成摘要压缩，管理总长度 |
系统监控与警报要点：
- 检索相关性衰减：监控摘要层与块层检索结果的平均相似度分数，设立基线，持续下降可能意味着索引漂移或查询分布变化。
- 上下文窗口溢出率：统计动态调整后，实际使用长度超过模型限制（或安全阈值）的查询比例，需优化填充逻辑。
- 模型忽略上下文指标：通过设计测试（如在上下文中插入特定指令或矛盾信息），定期评估模型遵循上下文的比率，关联检索质量进行分析。
- 分层检索延迟：拆解粗筛、精查两阶段的耗时，确保额外开销（通常增加 30-50ms）在业务可接受范围内。
结论与展望
腾讯 CL-bench 的警示表明，让 AI 真正理解并运用上下文，仍是一条漫长的工程化道路。它不是一个仅靠放大模型参数或扩展窗口就能解决的单一问题，而是一个涉及检索精度、信息组织、模型诱导的系统工程。
本文提出的分层检索与动态上下文窗口优化，正是从系统工程层面应对这一挑战的务实路径。通过构建层次化的知识导航和自适应的信息配送机制，我们能够将高质量的、结构化的学习材料更有效地呈现在模型面前，从而部分弥补其内在的上下文学习能力短板。未来，进一步的突破可能需要更紧密的 “检索 - 推理” 耦合架构，例如让模型在推理过程中主动发起多轮、精准的检索请求，实现真正的动态上下文构建与学习。在此之前，精耕细作的 RAG 工程优化，无疑是提升当前 AI 系统现实表现最具性价比的投入。
资料来源
- 腾讯研究院 CL-bench 基准测试相关论文与报道摘要。
- 关于分层检索增强生成（Hierarchical RAG）与动态上下文窗口优化的工程技术文章与讨论。