上下文窗口

• 位置偏差（Positional Bias）与 Lost in the Middle 现象
• 系统提示、历史、检索块在上下文中的优先级排序
• 关键信息放在上下文开头与结尾的取舍

模型对上下文的不同位置存在系统性偏差：开头（primacy）和结尾（recency）的信息被利用得最好，中间部分最容易被忽略。因此在超大上下文下应把"最重要"的信息放在锚点位置：将系统提示（约束、格式、最新指令）放在开头，把对当前任务最关键、最相关的检索块放在接近结尾的位置（紧邻最新用户指令），而把对话历史、参考性材料放在中间。同时要控制检索块数量与内容密度，避免把大量低相关度的块塞进中间造成噪声。对需要"全局记住"的约束还应定期在结尾重申，防止模型在中途遗忘早期指令。

上下文不是"均等存储"，而是"注意力的资源分配"。合理布局的本质是尊重模型的位置注意力权重，把高价值信息放在高权重区域，同时控制总量防止在中间堆积大量无效内容。

• Lost in the Middle 的定义与成因
• 对检索 Top-K 排序策略的影响
• 如何抵消中间位置偏差

Lost in the Middle 指当信息位于上下文中间位置时，模型对它的利用正确率显著下降。对检索结果排序的启示是：不能只按"相关度"排序，还要考虑"位置"。工程上有几种应对：一是把最相关的 Top-K 结果放在上下文最前面，把次相关的放后面，让信息处在高注意力区；二是采用"最相关放两端"的布局，把最重要的首条放开头、次重要的放结尾；三是限制注入的块数量，只注入高相关度的少数几块，避免用大量中间块稀释注意力；四是必要时用分隔符和明确标签（如"下面是最重要的证据"）强化对中间信息的引导。

检索排序的终极目标是"让模型真正用到"，而不是"让结果出现在上下文中"。位置感知的排序是对纯相关度排序的重要修正，尤其当 Top-K 很大时。

• 简单拼接的缺点（证据冲突、冗余、上下文超长）
• 证据聚合的处理流程（去重、冲突消解、归纳）
• 结构化中间表示（如证据摘要、论点合并）

简单拼接会把多个文档的段落直接堆进上下文，导致证据冲突、冗余信息、上下文超长，且模型难以判断哪些证据可信。跨文档证据聚合应分为几步：先做去重与去冗余（相同或重叠信息只保留一份）；再识别证据间的冲突（同一问题不同文档给出矛盾答案），对冲突做消解（结合权威性、时间戳、版本号判定谁更可信）；最后做归纳聚合，把多份证据压缩成一份结构化的证据摘要（如"问题+结论+支撑来源列表"），再连同各来源的原文一起交给模型。这样既保留了证据链，又避免了信息爆炸。

聚合的本质是把"多文档的信息"压缩成"可推理的证据结构"，让模型聚焦于判断而非海量信息。关键在于保留证据来源，使答案可追溯、可验证。

• 自注意力/价格随 Token 数增长的规律
• 输入长度约束的工程手段
• 成本与质量的平衡

超长上下文的计算成本随输入长度增长并非线性：Transformer 的注意力是 O(n²) 量级，且许多 Provider 按 token 计费，输入价格随长度分段递增。因此输入长度必须被显式约束。工程手段包括：对输入做预算分配（系统提示、历史、检索各占多少 token），超长历史滚动压缩或摘要化，检索块只注入高相关度的 Top-K，给历史设置滑动窗口并丢弃过期消息，以及用 caching 降低重复前缀的重复计费成本。核心是"用最少的 token 传递最多的有效信息"，并把成本上限作为硬约束写进系统设计。

成本约束倒逼输入长度优化。设计上应先定 token 预算，再决定每类内容能占多少，避免"把所有内容都塞进去"的惰性做法。

• 抽取式与抽象式摘要的定义与区别
• 保真度、信息损失、成本与幻觉的权衡
• 如何根据场景选择

抽取式摘要是从原文中挑选关键句子/片段，不改变原文措辞，因此保真度高、不易幻觉、可溯源到原文，但缺乏归纳能力，可能遗漏跨句信息。抽象式摘要是用 LLM 重新组织语言，能压缩率高、更精炼，但可能产生幻觉、丢失细节、且生成成本高。取舍原则：对需要高保真、可溯源、不能出错的内容（如法律条款、代码、数字）用抽取式；对需要高度概括、压缩比大、允许语义归纳的内容（如长对话总结、会议纪要）用抽象式。实际中常混合使用：先抽取关键片段，再对抽取结果做抽象压缩。

压缩的本质是"用信息损失换 token 节省"。选择的依据是下游任务对保真度的容忍度——出错代价越高越倾向抽取式。

• proxy context 的信息损失来源
• 评测方法（问答召回、信息覆盖、对比原文）
• 量化指标与召回验证

用摘要替代原文会丢失信息，评测这种信息损失需要"以问题为中心"的验证：先构建一组覆盖原文关键信息的问题集，再用"原文"和"摘要"分别作为上下文回答问题，对比答案召回率与正确率，摘要导致的下降即信息损失。更精细的方法是用信息覆盖度（原文是否包含摘要中缺失的关键实体/事实）、摘要忠实度（摘要是否源自原文而非编造）等指标。工程上还会做"二次问答"：用摘要回答不了的问题再回退到原文换近邻块，若检索失败率高说明摘要检索覆盖不足。

评测必须面向"下游任务"而非摘要本身的流畅度。信息损失最直接的度量是"用了摘要后同样的问题答得对不对"。

• 两级结构：始终在上下文的摘要 + 按需加载的细节
• 展开的触发机制
• 摘要与细节的一致性维护

分层上下文把信息分为两级：第一级是始终保持在上文中的核心摘要（全局概览、最新状态、关键结论），第二级是细节（原文、代码、长文档章节），按需才加载。设计上，系统先给模型一个精炼的摘要作为"全局地图"，当任务需要具体细节时，模型通过工具调用（如检索某章节、读取某函数）按需拉取细节块注入上下文。关键点：摘要必须足够准确以支撑"决定展开哪里"的决策；展开后的细节要能与摘要形成"摘要-细节"的对应关系，避免两者矛盾；同时要控制细节的注入量，防止一次展开过多。

两级加载的本质是"用摘要做导航，用细节做落地"，把海量信息压缩到上下文可承载的范围，同时保留按需深挖的能力。是解决超长上下文的核心模式。

• 代码库的层级结构（项目→文件→函数）
• 分层索引与检索
• 按需注入与上下文控制

长代码库不能把整个仓库塞进上下文，需要做文件级/函数级的分层检索。上游先建立代码索引：项目级（结构、依赖、模块地图）、文件级（文件职责、关键类）、函数级（函数签名、实现、调用关系）。检索时先拿到项目级/文件级概览，让模型判断要改哪个文件，再按需检索具体函数实现并注入。实践中常用"代码语义分块+调用图"：把函数/类作为检索单元，同时记录符号间的调用关系，检索到某个函数时把它的调用链也一并注入，帮助模型理解上下文。注入时控制范围，只注入与当前任务相关的函数及其近邻。

代码理解的关键是把"代码库"抽象成"可导航的层级结构"，让模型先看地图再深入细节，避免把无关代码占用上下文。

• MemGPT 的分层记忆思想（in-context + out-of-context）
• 记忆读写与遗忘机制
• 失效场景与边界（记忆冲突、检索失败、摘要漂移）

MemGPT 受操作系统启发，把上下文当作"主存"，把外部记忆当作"外存"，通过自省机制决定何时把重要信息写入外存、何时把外存信息加载回上下文。其边界与失效场景包括：记忆检索失败（需要的信息找不到导致上下文断裂）；记忆摘要漂移（长期滚动摘要导致早期细节被过度压缩、语义失真）；记忆冲突（新旧记忆矛盾，模型无所适从）；记忆管理本身消耗 token 与推理（自省调用成本）；以及"记忆写不漏"——模型可能忘记写入关键信息。失效时表现为主观遗忘、引用错误、前后矛盾。

分层记忆的长处是能处理超长会话，但其失效本质都是"信息在层级间转移时丢失或失真"。工程上要加记忆审计、检索兜底、冲突检测来缓解。

• Agentic Chunking 的做法
• 收益（语义边界更准、切块更完整）
• 成本（LLM 推理成本、延迟、不确定性）

Agentic Chunking 是让 LLM（而非固定规则）来决定文档在哪里切分，它能识别语义边界（如章节、主题转换点），切出的块更完整、语义更内聚，从而提升检索质量。收益是检索的语义相关性更高、减少跨块信息割裂。成本却很高：切分本身要调用 LLM，长文档切分 token 消耗大、延迟高、价格贵；且 LLM 输出不确定，需要校验切分结果；对海量文档批次切分，成本会被放大。因此 Agentic Chunking 通常只用于对高价值文档在离线阶段做一次切分，把切分结果缓存，避免每次在线请求都调用。

这是"用高质量但昂贵的切分换检索精度的提升"。是否值得取决于文档价值与检索质量收益，可通过对比评测（Agentic vs 固定切分的检索命中率）来量化。

• 引用溯源的数据流（原文→检索块→答案→回映射）
• 块级元数据携带（页码、段落、坐标）
• 回映射的实现方式

引用溯源的工程实现依赖"把原文元数据贯穿检索到生成的全链路"。切分时，每个块都携带元数据（页码、章节、段落号、版面坐标，甚至字符偏移区间）。检索返回的块把元数据原样带给生成环节；生成时要求模型在断言后标注来源块 ID（如 [src:3]），系统再把块 ID 回映射到原始页码/段落/坐标。回映射的关键是"块→原文位置"的映射表保持稳定，以及切块后能定位到原文的精确位置（如通过字符偏移）。若块被摘要压缩，则需记录摘要每一句对应的原文位置，否则溯源会丢失。

引用溯源的本质是"在切块造成的粒度丢失后，仍然能锚定回原文位置"。需要元数据一致性设计与可靠的映射表，且生成时强制要求模型附带来源标记。

• 流式输出（SSE）的实现
• 生成中断/超时的处理
• 中间状态保存（每次生成进度的持久化）

超长文档生成的输出可能超过一次请求的限度，需要流式输出与分块生成。流式输出用 SSE 把 token 逐段推给前端，避免用户长时间等待；同时把已生成的中间状态持久化（保存到数据库/对象存储），这样即使请求中断或超时，也能从断点继续。工程上采用"段落级生成"：先生成第一段并流式下发，同时保存，再继续生成下一段，每段完成后更新进度状态。对超长文档可拆成多个子任务（标题/章节）并行或串行生成，配合进度追踪与断点续跑。

超长生成的难点是"一次生成不完"与"中断丢失"。流式解决体验，中间状态保存解决可靠性，两者结合才能支撑超长文档的稳定产出。

• 长任务的幂等与可恢复设计
• 处理单元划分与结果缓存
• 断点续跑的实现

长文档处理任务把大任务拆成可并行的处理单元（如按章/按页分块），每个单元的结果独立缓存（以内容哈希为 key）。这样某个单元失败时，只需重跑失败单元，其余单元结果直接复用——这就是部分结果复用。断点续跑则需要持久化任务进度（哪些单元完成、哪些失败），重启后从进度表恢复继续处理而非从头开始。配合幂等设计（同一单元重跑结果一致），可保证续跑的确定性。工程上用一个任务状态表记录每个单元的状态，后台 worker 消费未完成单元。

断点续跑与部分结果复用的本质是"把长任务变成可独立追踪的短任务集合"。配合内容哈希缓存能避免重复计算，显著降低失败成本。

• 结构化的三层索引（目录、章节、段落）
• 检索策略（先定位章节再精检）
• 全局摘要与按需细节

书籍/法规级文档体量巨大，需要结构化设计。一是建立目录索引：把目录/章节结构化成导航树，模型可先定位到相关章节。二是章节级+段落级两级检索：先根据问题用章节标题粗筛定位到章节，再在章节内做段落级精检，避免全局检索的噪声。三是维护全局摘要：对每个章节/整本书生成摘要作为"地图"，帮助模型判断信息在哪个章节。问答流程是：问题→章节定位→章节内检索→聚合证据→带引用生成答案。法规类还要注意条款版本、生效日期、新旧法衔接。

书籍级问答的关键是"先导航后检索"，利用文档固有的目录结构做索引入手，而不是对整本书做无差别向量检索。分层检索能大幅提升召回与精度。

• 引用定位失败的常见原因
• 诚实呈现（不伪造）的原则
• 降级策略（返回章节/段落而非精确页码）

切块后页码可能丢失（如 PDF 文本流切分把页码信息剥离）、版面可能偏移（OCR 或重排导致页码对不上）。此时绝不能伪造锚点——模型不应编造页码或在无法确证时给出错误的坐标。处理原则是"诚实降级"：能定位到精确页码就展示页码；定位不到就降级为章节/段落标题或"第 X 节附近"；若连章节都拿不准，就明示"无法精确定位，请核对原文"。工程上给每个块维护"最可靠的位置信息"（页码可用则用页码，否则用章节/段落号），并在 UI 上区分"精确定位"与"近似定位"两种呈现。

引用溯源的第一原则是可信。伪造锚点比没有锚点危害更大，会误导用户。诚实降级既保护了可信度，也降低了实现复杂度。

• Prompt Caching 的原理（前缀匹配）
• 命中边界（前缀、可复用性、变化频率）
• 布局设计以最大化命中率

Prompt Caching 按"前缀"缓存，只有前缀完全一致才命中。因此设计命中边界时，要把"不变的部分"放在前面，"多变的部分"放在后面：系统提示、固定指令、稳定的知识库前缀放最前（可复用），而用户个性化输入、动态检索块、实时变化内容放后面（不参与缓存）。要避免把变化内容插进稳定前缀中间，否则会破坏前缀匹配导致缓存全部失效。还要考虑缓存时效（TTL）与缓存命中的计费折扣，以及缓存大小上限（长缓存可能不划算或超出容量）。

命中边界的本质是"把可复用前缀与多变后缀分离"。布局越靠前的部分越应稳定，才能最大化缓存命中率、降低重复计费成本。

• 引用支持率/定位准确率的定义
• 评测方法（人工+LLM 检查）
• 门禁设定与回退

引用溯源质量的两个核心指标：引用支持率（答案中每条断言是否有对应引用支撑，或引用的内容是否真的支持该断言）与定位准确率（引用所指向的页码/段落是否真的包含支撑内容）。评估方法：对评测集逐条断言，检查该断言是否被所引引用的原文支持（可用 LLM 做二分类判断，人工抽样复核），以及引用位置是否准确命中。发布门禁=设定指标阈值（如引用支持率≥90%、定位准确率≥95%），在灰度/发布前跑基线评测，未达标则阻塞发布或回退。同时把人工复判的误判样本回流修正评测集。

引用溯源是事实性产品的生命线，必须量化并进门禁。评测不只看"有没有引用"，更看"引用是否真的支撑"，两者都要纳入。

• semantic chunking 的做法
• 固定窗口切块的缺陷
• 语义切块的优势

固定窗口切块按固定 token 数硬切，可能把语义连贯的内容（一句话、一个段落、一个概念）拦腰截断，导致块内信息不完整、检索时上下文割裂。语义分块则依据语义边界（标题、段落、主题转换、语义相似度变化）切分，使每个块语义内聚、内容完整。优势是检索命中率更高（完整语义更易匹配）、检索到的块能独立支撑答案、减少跨块信息丢失。代价是切分逻辑更复杂、可能需要嵌入模型或 LLM 判断边界，切分成本略高。

语义分块是"用更合理的切分粒度换取检索质量"，本质是让每个检索单元都"自洽完整"，避免固定窗口造成的语义断裂。

• 混合检索三阶段的作用
• 关键参数（Top-K、权重、Rerank 候选数）
• 长文档场景的特殊调优

混合检索用 BM25 抓精确词匹配、向量抓语义、Rerank 精排。调参重点：一是各召回通道的候选数（Top-K），向量字面量少时提高 BM25 的 K；二是融合权重（加权/RRF），长文档中术语精确匹配很重要，可适当提高 BM25 权重或 RRF 的常数；三是进入 Rerank 的候选数（如每通道取 20-50 注入 rerank），覆盖不足则漏检、过多则提升异步且可能引入低相关噪声；四是长文档需要注意块粒度与检索单元一致，避免大块稀释向量相似度。调参用带标注的评测集做离线网格搜索，观察 recall@K 与 MRR。

长文档混合检索的调参核心是"各通道召回覆盖与精排成本的平衡"。用评测集量化各参数组合的召回与精度，避免拍脑袋。

• RAPTOR 的树状结构（自底向上聚类+摘要）
• 宏观（树上层）与细节（树下层）检索
• 双路检索的融合

RAPTOR 把文档切块后，对相似块做聚类并生成摘要，再对摘要递归聚类摘要，形成一棵树：底层是原始细节块，上层是逐步抽象的摘要。检索时双路进行：宏观问题聚类到上层摘要节点（快速把握全局主题），具体问题检索到底层细节块（精确命中事实）。返回时把不同层级的节点合并作为上下文，让模型既看全局又看细节。工程上要为每个节点建立索引，查询时按相似度匹配到合适的层，恢复该层的叶子与父节点路径。

RAPTOR 是"多粒度检索"的经典实现，用树结构同时支持宏观概览与微观细节，解决了单一粒度检索要么太粗要么太细的问题。

• RAG Triad 的三个指标
• Context Relevance 的定义与评测
• 长文档场景的注意点

RAG Triad 是 RAG 评测的铁三角：Context Relevance（检索到的上下文与问题是否相关）、Answer Faithfulness（答案是否忠实于上下文）、Answer Relevance（答案是否回答了问题）。Context Relevance 的评测方式：对每个检索结果块，用 LLM 判断"这块内容是否与问题相关"，计算相关块占比，或用"检索到的上下文回答问题的关键信息覆盖率"衡量。长文档场景要特别注意：检索块多时，相关性不能只看 Top-1，要看整体召回覆盖；块的数量与冗余也会影响最终答案质量，需结合 Faithfulness 一起看。

RAG Triad 把 RAG 链路拆成"检索、忠实、有用"三个可独立评测的环节。Context Relevance 单独量化检索质量，需与 Faithfulness 联动评估，避免"检索相关但生成不忠实"。