概念-渐进式加载

一句话理解

渐进式加载（Progressive Loading）是一种上下文管理策略，核心思想是分步注入上下文：先给模型摘要或索引，当模型需要更多细节时，再加载完整内容。它的设计动机很简单——在上下文窗口有限（4K-32K tokens）的年代，你不可能一次性把所有相关资料塞进去，所以必须”按需加载”，像网页的懒加载（Lazy Loading）一样，只加载当前需要的内容。

类比：看一本参考书时，你不会从头到尾逐页阅读。你先看目录（索引），找到相关章节，再翻到那一页读详细内容（全文加载）。渐进式加载就是让模型也这样工作。

核心机制

两阶段加载流程

阶段一：轻量上下文
┌──────────────────────────────────────┐
│ System Prompt + 任务描述              │
│ + 文档摘要/索引（如：文档1讲A，文档2讲B）│
│ → 模型分析：需要哪些文档的全文？         │
└──────────────────────────────────────┘
        │
        ▼
阶段二：按需加载
┌──────────────────────────────────────┐
│ System Prompt + 任务描述              │
│ + 文档A全文（模型选择的）              │
│ + 文档C全文（模型选择的）              │
│ → 模型基于全文生成最终回答              │
└──────────────────────────────────────┘

多级渐进式加载

对于特别大的文档集合，可以使用三级甚至更多级加载：

第一级：分类标签（10个文档分3类）
   ↓ 模型选择：需要"技术类"文档
第二级：技术类文档摘要（5篇摘要，每篇100字）
   ↓ 模型选择：需要文档2和文档5的全文
第三级：文档2全文 + 文档5全文
   ↓ 模型基于全文生成回答

与本 Vault 漏斗模型的关系

本 Obsidian 知识库（Vault）使用的漏斗架构（Funnel Architecture），其前身就是渐进式加载的思想：

层级	漏斗模型	渐进式加载映射
第一层	概念笔记（一句话理解 + 核心特征）	摘要层（轻量上下文）
第二层	深挖笔记（详细机制 + 代码）	全文层（按需加载）
第三层	对比笔记（横向比较）	综合分析层
第四层	来源笔记（原始论文/文档）	原始数据层

在 AI 使用这个 Vault 时，检索策略天然就是渐进式的：先检索概念笔记（轻量），如果发现需要更多细节，再检索深挖笔记（全文），最后如果需要原始数据，才去查来源笔记。

与上下文压缩的关系

维度	渐进式加载	上下文压缩
策略方向	先少后多（由浅入深）	先多后少（由繁入简）
信息完整性	最终可能获得完整信息	始终是压缩后的摘要
适用场景	用户知道需要什么但不确定	内容太多必须精简
模型调用次数	可能多次（2-3次）	通常1次
延迟	较高（多轮交互）	较低（单轮）
关键挑战	模型能否准确判断”需要什么”	压缩过程是否丢失关键信息

两者在实际应用中常常结合使用：先用上下文压缩生成摘要，再用渐进式加载按需获取全文。

代码示例：文档问答的渐进式加载

from typing import Optional

# 文档库：每篇文档有摘要和全文
documents = {
    "doc_1": {
        "title": "Python 异步编程指南",
        "summary": "介绍 asyncio、协程、事件循环的基本概念和使用方法",
        "full_text": "...（2000字全文）..."
    },
    "doc_2": {
        "title": "Python 性能优化实践",
        "summary": "涵盖 profiling、caching、并行计算等优化技术",
        "full_text": "...（3000字全文）..."
    },
    "doc_3": {
        "title": "Python Web 框架对比",
        "summary": "比较 Django、FastAPI、Flask 的适用场景和性能差异",
        "full_text": "...（2500字全文）..."
    }
}

def progressive_qa(user_query: str) -> str:
    # 阶段一：只给摘要，让模型选择需要的文档
    summaries = "\n".join([
        f"文档ID: {doc_id}\n标题: {doc['title']}\n摘要: {doc['summary']}\n"
        for doc_id, doc in documents.items()
    ])

    selection_prompt = f"""以下是可用文档的摘要：

{summaries}

用户问题：{user_query}

请判断需要哪些文档的全文来回答用户问题。只输出需要的文档ID列表（用逗号分隔），例如：doc_1,doc_3
如果所有文档都不需要，输出：none"""

    selection = llm_call([
        {"role": "user", "content": selection_prompt}
    ]).strip()

    if selection.lower() == "none":
        return "抱歉，没有找到相关文档"

    # 阶段二：加载选中的文档全文并生成回答
    selected_ids = [s.strip() for s in selection.split(",")]
    full_texts = "\n\n---\n\n".join([
        f"【{documents[doc_id]['title']}】\n{documents[doc_id]['full_text']}"
        for doc_id in selected_ids if doc_id in documents
    ])

    answer_prompt = f"""基于以下文档内容回答问题：

{full_texts}

用户问题：{user_query}

请基于文档内容给出详细的回答，并标注信息来源。"""

    return llm_call([
        {"role": "user", "content": answer_prompt}
    ])

2026 年：渐进式加载还必要吗

长上下文窗口的冲击

2026 年，主流模型普遍支持 200K+ tokens 的上下文窗口（Claude 支持 200K，Gemini 支持 2M）。对于大多数场景，你完全可以直接把所有文档全文塞进去，不需要渐进式加载。

但思想仍在延续

渐进式加载的核心思想——“按需组织信息，而不是全部倾倒”——在以下领域仍然活跃：

Agent 记忆管理：Agent 不会把所有历史对话都塞进上下文，而是”按需回忆”相关片段
RAG 的检索策略：先检索、后生成，本质就是渐进式加载的现代化实现
上下文工程的层次设计：System Prompt → 工具描述 → 检索结果 → 对话历史，按优先级分层
多 Agent 系统的信息传递：Agent 之间传递摘要而非全文，按需请求详细信息

关键洞察

长上下文窗口解决了”能不能放进去”的问题，但没有解决”放进去后效果好不好”的问题。 把 200K tokens 的内容塞进上下文，模型可能仍然只会关注开头和结尾的信息（Lost in the Middle 效应）。渐进式加载的”精选+按需”思想，在信息质量层面仍然有价值。

来源

https://arxiv.org/abs/2307.11760 — “Lost in the Middle” 论文：长上下文中的信息位置效应
https://docs.anthropic.com/en/docs/build-with-claude/context-windows — Anthropic 上下文窗口指南
https://arxiv.org/abs/2312.10997 — RAPTOR: 分层检索与上下文组织
https://www.anthropic.com/engineering/building-effective-agents — Agent 中的上下文管理策略