大模型上下文管理指在有限token窗口内策略性组织、筛选、压缩和调度信息。包括语义分块（按标题/函数/句子边界）、动态检索注入（RAG）、滑动窗口与摘要缓存协同，以及关键实体索引。
什么是大模型上下文管理
大模型的“上下文”指的是模型在一次推理中能接收和参考的最大文本长度，单位通常是 token。超出这个长度的输入会被截断或拒绝，导致关键信息丢失。上下文管理不是简单地“塞更多文字”，而是有策略地组织、筛选、压缩和调度信息，让模型在有限窗口内始终看到最相关的内容。
长文本分块与语义对齐技巧
原始长文档（如PDF、日志、报告）不能直接切分成固定字数的片段——这容易割裂句子、段落甚至表格结构。应优先按自然语义单元划分：
- 以标题层级（如 #、##）为锚点，保留小节完整性
- 对技术文档或代码，按函数/类/配置块切分，避免跨函数截断
- 使用 spaCy 或 NLTK 识别句子边界，再合并为 200–500 token 的语义段（而非硬性字符数）
- 为每个块添加轻量元信息，例如 [Section: 数据预处理, Source: report_v2.pdf p12]，帮助模型定位上下文
动态上下文检索与注入（RAG 核心逻辑）
面对百页文档回答具体问题时，不需把全文喂给模型。先用嵌入模型（如 text-embedding-small）将所有文本块向量化，再用相似度检索出 Top-k 最相关块（通常 k=3–5），最后拼接成 prompt：
- 检索前对用户问题做简要重写（如“怎么调参？” → “模型超参数设置方法”），提升匹配精度
- 在 prompt 中明确标注检索块来源和顺序，例如：【参考片段①】……【参考片段②】……
- 预留 20% 上下文空间给模型生成答案，避免因注入过多参考而挤压输
出长度
滑动窗口与状态缓存协同策略
对于多轮对话式长文本处理（如逐章分析小说、持续调试日志），需维持跨轮次的上下文连贯性：
- 维护一个轻量“摘要缓存”：每轮结束后，用一句话总结本轮结论（如“确认第3章主角动机源于童年事件”），加入下一轮 prompt 开头
- 采用滑动窗口机制：只保留最近 N 轮的完整交互 + 缓存摘要，旧轮次原始输入自动淘汰
- 对关键实体（人名、变量名、错误码）建立实时索引表，在 prompt 中以键值对形式附在末尾，例如：{"ERR_CODE_403": "权限不足，请检查 token scope"}
出长度