6.5 压缩策略案例分析

本节通过具体案例展示压缩策略的实际应用，帮助读者深入理解不同压缩技术的适用场景和效果。

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

场景描述

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

挑战

• 长度限制：5 万字远超大多数模型的上下文窗口。

• 信息分散：关键数据散落在文档各处。

• 结构要求：输出需要严格遵循特定格式。

解决方案：递进式压缩 + 对话历史管理

1. 分块（Chunking）：将 5 万字按章节切分为 10 个部分，每部分约 5000 字。

2. 并行摘要（Map）：对每个部分并行调用 LLM，要求提取关键数据和观点。

   • 提示词策略：明确要求输出 JSON 格式，包含 key_points, data, trends 字段。

3. 聚合（Reduce）：将 10 个部分的摘要合并，再次调用 LLM 进行整合与去重。

4. 最终生成：基于整合后的信息，生成符合用户要求的结构化报告。

效果对比

指标	直接输入（截断）	递进式压缩
信息覆盖率	低（仅覆盖截断范围）	高（覆盖范围更完整）
幻觉率	较高风险（因信息缺失）	较低风险（基于提取的事实）
处理时间	快（单次调用）	中（多次调用，可并行）

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

场景描述

一个陪伴型 AI 角色，需要记住用户几天前提到喜欢的电影，并在后续对话中自然引用。

挑战

• 上下文膨胀：随着对话进行，历史记录越来越长，迅速消耗 Token。

• 遗忘：简单的滑动窗口会丢弃早期的重要信息（如用户喜好）。

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

1. 短期记忆（Short-term Memory）：保留最近 10 轮对话的完整内容。

2. 长期记忆（Long-term Memory）：

   • 实体提取：每天结束时，使用专门的 Prompt 扫描当天对话，提取用户画像信息（如“喜欢《星际穿越》”）。

   • 摘要归档：将当天的非关键闲聊压缩为一句话摘要（“周二聊了关于电影的话题”）。

3. 检索增强：当用户再次聊到电影时，检索长期记忆中的相关实体。

代码实现示意（伪代码）

def compress_history(history):
    # 提取实体
    user_profile_updates = extract_entities(history)
    update_user_profile(user_profile_updates)
    
    # 生成摘要
    summary = summarize_conversation(history)
    
    # 存入长期记忆库
    save_to_long_term(summary)
    
    return [] # 清空当前历史（或保留最后几轮）

# 在每轮对话前
context = get_recent_history() + retrieve_relevant_long_term_memory(current_query)

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

场景描述

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

挑战

• 代码量巨大：无法将所有代码放入 Context。

• 依赖关系复杂：文件之间存在引用关系，单看一个文件难以理解全局。

解决方案：结构化压缩（骨架提取）

1. 生成骨架（Skeleton）：为每个源代码文件生成“骨架”版本。

   • 保留：Class 定义、函数签名、关键注释、Import 语句。

   • 移除：函数体具体实现、内部逻辑。

2. 构建全景图：将所有文件的骨架拼接，形成项目的“高层地图”。

3. 按需展开：

   • LLM 先阅读骨架，定位到具体负责相关逻辑的文件。

   • 工具调用读取这些具体文件的完整内容。

压缩效果（示意）

• 原始大小：可能达到 MB 级源码

• 骨架大小：通常可显著缩小到原来的一个小比例（取决于代码风格与注释量）

• 效果：更易让模型先建立项目结构，再按需展开细节，避免一次性加载全量代码。

6.5.4 经验总结

1. 压缩不是目的，保留价值才是：不仅要看压缩后省了多少 Token，更要看任务完成率是否下降。

2. 结构化优于非结构化：在压缩代码或数据时，保留结构（如 JSON, XML, 代码签名）比纯文本摘要更有效。

3. 动态调整：根据当前任务的复杂度动态调整压缩率。简单问答可以高压缩，复杂推理需要保留更多细节。