27届大模型岗面试准备（十三）：长上下文与上下文工程------从位置外推到分块策略的完整考点
写在前面
上一篇（十二）我们把 RAG 的完整链路走了一遍，其中"分块"环节埋了一个问题：为什么非要把文档切碎？直接把整本手册塞进模型不行吗？2026 年的模型动辄标称 128K、1M 上下文，看起来"塞进去"已经不是问题。但面试官如果问你"上下文窗口 1M 了，RAG 是不是可以退休了"，你要是答"是"，这场面试基本就结束了。
长上下文（Long Context）和上下文工程（Context Engineering）是这两年面试权重涨得最快的话题之一。它横跨三个层面：模型层 （位置编码怎么外推）、系统层 （KV Cache 怎么扛住百万 token）、应用层（上下文预算怎么分配、长文本怎么分块）。本文按这三层展开，最后给一段可直接运行的长文本分块代码。
一、先想清楚：长上下文到底难在哪
很多同学的第一反应是"显存不够"。对，但不全对。长上下文的困难是三个维度叠加的：
1. 计算与显存的平方/线性增长。 自回归注意力对序列长度 n 是 O(n²) 计算；KV Cache 是 O(n) 显存。第十篇我们算过：一个 7B 模型、4096 序列的 KV Cache 约 2GB，把序列拉到 128K，单条请求的 KV Cache 就奔着 64GB 去了------比模型权重还大好几倍。
2. 位置编码的外推失效。 模型在 4K 长度上训练，RoPE 的旋转角度只见过 4K 以内的组合。推理时直接跑 32K，模型看到的是"从没见过的相对位置"，注意力分布直接崩掉。这就是为什么"支持 128K"从来不是改一个配置就行的。
3. 有效利用率的衰减。 这是最容易被忽略、也最容易在面试中出彩的一点：模型"能读完"不代表"能用好"。Lost in the Middle 现象------关键信息放在长上下文中间位置时，召回准确率显著低于放在开头或结尾------说明上下文窗口的"标称长度"和"有效长度"是两回事。
把这三点讲清楚，面试官就知道你不是只会背"某某模型支持 1M"。
二、模型层：位置外推的技术谱系
第三篇我们讲过 RoPE 的数学原理，这里接着往下讲"怎么把 4K 训练的模型拉长用"。核心思路只有两条路：让新位置看起来像旧位置 （内插），或者让模型适应新位置（继续训练/调整频率）。
| 方法 | 核心思想 | 是否需要微调 | 效果特点 | 代表应用 |
|---|---|---|---|---|
| 直接外推 | 什么都不做，硬跑 | 否 | 超过训练长度后 PPL 爆炸 | 反面教材 |
| Position Interpolation (PI) | 把位置索引线性压缩回训练范围 | 少量微调 | 均匀压缩，短程分辨率受损 | LLaMA 长上下文早期方案 |
| NTK-aware 插值 | 高频维度少压、低频维度多压 | 可免微调 | 兼顾短程精度与长程覆盖 | 各开源社区"免训练拉长" |
| YaRN | NTK 分段插值 + 注意力温度缩放 | 少量微调 | 目前开源侧主流，效率高 | Qwen、DeepSeek 系列 |
| ALiBi | 干脆不用位置嵌入，用线性偏置惩罚远距离 | 天然外推 | 外推强但长程建模上限受争议 | BLOOM、MPT |
| 双阶段长训 | 先短后长、调大 RoPE base 继续预训练 | 大量训练 | 效果最好，成本最高 | 各家官方长上下文版本 |
面试高频追问："NTK-aware 为什么高频少压、低频多压？"答题抓手：RoPE 不同维度的旋转频率不同------高频维度负责编码相邻 token 的精细位置关系，压缩它会伤近距离分辨率；低频维度负责远距离的粗粒度关系，本来就"转得慢"，压缩空间大。这个"按频段区别对待"的思想借自 NTK（神经正切核）对高频学习的分析，故得名。
三、系统层：百万 token 的工程账
模型能外推了，系统还得扛得住。这一层的考点和第十篇（推理加速）强关联，可以串联作答：
- KV Cache 压缩：MQA/GQA 从头数上砍（第四篇讲过），量化 KV Cache 从精度上砍（INT8 KV 已是长上下文标配），滑动窗口注意力从范围上砍。
- 稀疏注意力：不是每个 token 都要看全部历史。StreamingLLM 发现"注意力汇聚"（attention sink）现象------保留开头几个 token + 最近窗口，就能维持流式生成不崩。
- Prefix Caching：多轮对话/多请求共享的长前缀（如系统提示、长文档）只算一次 KV，vLLM 的 RadixAttention 用前缀树管理。这一点在 Agentic 场景尤其重要------B10 讲 Agentic RAG 时提过，Agent 每轮都带着几乎相同的长前缀。
- Chunked Prefill：128K 的 prefill 一口气算完会把 decode 请求全部饿死，切成小块和 decode 交错调度，平衡 TTFT 和 TPOT。
一句话总结给面试官："长上下文的系统优化，本质是围绕 KV Cache 的省（压缩）、复用（前缀缓存）、调度（chunked prefill）三件事。"
四、应用层：上下文工程------把窗口当预算来管理
2026 年"Prompt 工程"这个词在工程圈已经明显让位给"上下文工程"。区别在哪？Prompt 工程琢磨"指令怎么写"，上下文工程琢磨"这有限的窗口里到底该放什么、放多少、按什么顺序放"。它把上下文当成一种要精打细算的稀缺资源，像操作系统管理内存一样管理它。
上下文的典型构成与预算分配思路：
| 组成部分 | 内容 | 预算特点 | 管理策略 |
|---|---|---|---|
| 系统指令 | 角色、规则、输出格式 | 固定开销，常驻 | 尽量精简，可用 prefix caching |
| 工具定义 | function schema | 随工具数线性涨 | 按任务动态挑选工具子集 |
| 检索内容 | RAG 召回的文档块 | 弹性最大 | top-k 截断、重排后按分数分配 |
| 历史对话/轨迹 | 多轮消息、Agent scratchpad | 随轮数膨胀 | 滑动窗口 + 递归摘要（B6 讲过） |
| 少样本示例 | few-shot 演示 | 边际收益递减 | 强模型可减，弱模型保留 2--3 个 |
| 用户输入 | 当前问题 | 不可压缩 | 保持原样 |
这张表背后的三条工程原则值得在面试里主动说出来：
- 相关性优先于完整性：塞进 10 万 token 的"可能相关"不如 5 千 token 的"高度相关"，Lost in the Middle 会惩罚前者。
- 位置即权重：关键信息放开头或结尾；检索结果按重要性做"两头高、中间低"的排布是常见 trick。
- 压缩是常态操作：摘要、去重、截断不是退而求其次，而是常规手段------窗口再大，注意力预算和成本预算也是有限的。
长上下文 vs RAG 不是二选一。 标准答法：长上下文解决"单次能看多少"，RAG 解决"从海量知识里挑什么给它看"。知识库是 TB 级的，1M 窗口也塞不下；而且全量塞入的推理成本（prefill 计算 + KV 显存）比"检索后精准投喂"高一到两个数量级。真实系统是"RAG 负责粗筛 + 长上下文负责细读"的配合关系。
五、代码实战：三种长文本分块策略的实现与对比
分块（chunking）是上下文工程最基础也最容易被问"你实际怎么做"的环节。下面用纯标准库实现三种策略：固定长度切分、句子边界切分、滑动窗口重叠切分，并对比它们在"语义完整性"上的差异。可直接 python chunking.py 运行。
python
# -*- coding: utf-8 -*-
"""三种长文本分块策略：固定长度 / 句子边界 / 滑动窗口重叠（纯标准库可运行）"""
import re
def chunk_fixed(text: str, size: int = 100) -> list[str]:
"""策略1：固定长度硬切。实现最简单，但会把句子拦腰斩断。"""
return [text[i:i + size] for i in range(0, len(text), size)]
def chunk_by_sentence(text: str, max_size: int = 100) -> list[str]:
"""策略2：先按句子边界切，再贪心合并到不超过 max_size。
保证每个 chunk 都由完整句子组成，语义不被截断。"""
sentences = [s for s in re.split(r'(?<=[。！？；\n])', text) if s.strip()]
chunks, buf = [], ""
for sent in sentences:
if len(buf) + len(sent) <= max_size:
buf += sent
else:
if buf:
chunks.append(buf)
# 单句超长时退化为硬切
buf = sent if len(sent) <= max_size else ""
if len(sent) > max_size:
chunks.extend(chunk_fixed(sent, max_size))
if buf:
chunks.append(buf)
return chunks
def chunk_sliding(text: str, size: int = 100, overlap: int = 20) -> list[str]:
"""策略3：滑动窗口重叠切分。相邻 chunk 共享 overlap 字符，
缓解'答案恰好跨在切点上'的边界丢失问题，代价是索引膨胀。"""
assert 0 <= overlap < size, "overlap 必须小于 size"
step = size - overlap
return [text[i:i + size] for i in range(0, max(len(text) - overlap, 1), step)]
def boundary_break_rate(chunks: list[str]) -> float:
"""度量：不以句末标点结尾的 chunk 占比（越低说明语义越完整）。"""
bad = sum(1 for c in chunks if c and c[-1] not in "。！？；\n")
return bad / max(len(chunks), 1)
if __name__ == "__main__":
doc = (
"长上下文不等于无限上下文。窗口越大，注意力越稀释，成本越高。"
"上下文工程的目标是让每个 token 都物有所值。分块是其中最基础的操作。"
"固定切分实现简单，却常把句子拦腰斩断，导致检索命中后语义残缺。"
"句子边界切分尊重语义单元，是多数生产系统的默认选择。"
"滑动窗口用冗余换鲁棒，适合答案常跨越切点的问答场景。"
"实践中还会叠加父子分块：小块负责精准检索，大块负责提供上下文。"
) * 3
strategies = {
"固定长度": chunk_fixed(doc, 100),
"句子边界": chunk_by_sentence(doc, 100),
"滑动窗口": chunk_sliding(doc, 100, 20),
}
print(f"原文长度: {len(doc)} 字\n")
print(f"{'策略':<8}{'块数':>4}{'平均块长':>8}{'断句率':>8}")
for name, chunks in strategies.items():
avg = sum(map(len, chunks)) / len(chunks)
print(f"{name:<8}{len(chunks):>4}{avg:>8.1f}{boundary_break_rate(chunks):>8.0%}")
print("\n句子边界切分示例（第1块）:")
print(" ", strategies["句子边界"][0])运行后能直观看到：固定长度切分的"断句率"接近 100%（几乎每块都切断句子），句子边界切分为 0%，滑动窗口介于两者之间但对跨切点信息更鲁棒。面试时如果能主动补一句"生产里我会在句子切分之上再做父子分块------检索用小块保精度，喂给模型用父块保上下文"，就把 A12 的内容也串起来了。
六、高频面试题与答题要点
- "上下文窗口 1M，RAG 还有必要吗？" ------ 有。知识库规模 >> 窗口；全量塞入成本高一到两个数量级；Lost in the Middle 让有效利用率打折。RAG 与长上下文是粗筛与细读的配合。
- "模型标称 128K，怎么验证它真的可用？" ------ 大海捞针（NIAH）测不同深度的召回率，但要指出 NIAH 偏简单，进阶用 RULER/LongBench 这类含多跳、聚合任务的基准；同时压测 128K 下的 TTFT 和显存。
- "YaRN 和 PI 的区别？" ------ PI 均匀线性内插伤高频；YaRN 按维度频率分段处理 + 注意力温度补偿，同等微调量下长短程质量更均衡。
- "Agent 跑几十轮后上下文爆了怎么办？" ------ 滑动窗口 + 递归摘要 + 关键事实外置到长期记忆（向量库），即 B6 的三层记忆架构；工具返回值做截断与结构化压缩。
小结
长上下文是"模型外推 + 系统扛量 + 应用会用"三层问题的交集：位置编码决定能不能读，KV Cache 工程决定扛不扛得住，上下文工程决定用得好不好。把"标称长度 ≠ 有效长度"和"窗口是预算不是仓库"这两个观念讲透，这个话题你就立住了。下一篇（十四）进入多模态大模型 VLM------当上下文里不只有文字，还有图像时，问题又升了一个维度。