【小目标】
这一节点回答：上下文窗口是什么？为什么"窗口越大越好"是个误区？ 价值在于——知道了上下文的边界和代价，你就不会被"XX 模型支持 200 万 token"的营销数字牵着走，而是会按任务体量选合适的窗口。
这里最关键的一句判断：上下文 ≠ 越多越好。 处理 token 越多，价格与延迟越高；而且模型对长上下文中段的内容利用变差（lost-in-the-middle）——塞太多反而降精度。正规姿势是"检索注入"：长文本用 RAG 只把最相关的块放进来，而不是硬塞全文。
【方法论】
一句话结论：上下文窗口是"一次性给模型看多少背景"的上限；窗口越大越贵、越易错，够用就好，不够就用检索补。
先把几个核心概念讲清楚：
① Token（词元）——模型计算的基本单位
- 模型不是按"字"或"词"算，而是按 token 算。一个 token 可以是一个整词、半个词、一个字、一个标点
- 大致换算：1 个中文汉字 ≈ 1–2 个 token；1 个英文单词 ≈ 1–1.5 个 token
- 为什么重要：API 收费按 token 算、延迟按 token 算、上下文上限也按 token 算——token 是 LLM 世界的"计量单位"
② 上下文窗口（Context Window）——一次能看多少
- 是模型一次推理中能同时看见的 token 上限，包括输入的 prompt + 输出的回答
- 你给的输入越长，留给回答的空间就越少
- 常见窗口大小：4k / 8k / 32k / 128k / 200k+（越大越贵）
③ 长上下文的三个代价
- 成本：如果把 128k 窗口喂满，费用是 4k 输入的约 30 倍；且大窗口模型的单位 token 单价通常也更高。
- 延迟：处理更多 token 需要更多时间，用户等得更久
- 精度：研究表明，模型对长上下文中段的内容注意力会下降（叫 "lost-in-the-middle" 现象）——中间塞的东西，模型反而没好好看
④ 正确的长文本姿势：检索注入（RAG）
- 不是把整篇文档全塞进去，而是先检索出和问题最相关的几个片段，只把这些片段放进上下文
- 好处：省 token、跑得快、精度高（因为没有无关信息干扰）
- 这就是 RAG（检索增强生成）的核心思路，第三章会讲原理，阶段③第四章会讲工程实现
选型建议：
| 任务类型 | 建议窗口 | 说明 |
|---|---|---|
| 单轮问答 / 客服 FAQ | 4k–8k | 够用，便宜又快 |
| 文档摘要 / 多轮对话 | 16k–32k | 中等长度够用 |
| 多文档综合 / 长代码 | 128k+ | 真的需要时再用，配合检索 |
| 任何长文本任务 | 优先用 RAG | 检索注入比硬塞全文性价比高得多 |
【知识点】
- Token 是 LLM 的基本计量单位：收费、延迟、窗口大小都按 token 算。1 个中文汉字 ≈ 1–2 个 token。
- 上下文窗口 = 一次能看见的 token 上限，包括输入+输出。输入越长，留给回答的空间越少。
- 长上下文 ≠ 更好：三大代价——更贵、更慢、中段注意力下降（lost-in-the-middle）。
- "最大窗口" ≠ "能用好窗口"：别被营销数字带着走，由任务体量定。FAQ 问答不需要超大窗口。
- 正确姿势是检索注入（RAG）：长文本先检索，只把最相关的片段放进上下文，而不是硬塞全文。
- 上下文 ≠ 记忆：窗口是"一次性可见输入"，长期记忆是别的机制（Agent 侧的记忆/状态）。
【名词卡】
| 名词 | 一句话解释 |
|---|---|
| Token / 词元 | 模型处理文本的基本单位（词/子词碎片/字），成本与延迟按 token 计 |
| Context Window / 上下文窗口 | 模型一次能"看得见"的输入 token 上限。窗口长≠用得好 |
| Prompt / 提示词 | 你喂给模型的输入文本，包括系统提示、用户问题、上下文等 |
| Completion / 补全 | 模型生成的回答文本，也叫"输出 token" |
| Lost-in-the-Middle / 中间迷失 | 长上下文里模型对"中间位置"信息利用变差的现象，是"别硬塞全文"的依据 |
| RAG / 检索增强生成 | 用检索只把最相关片段注入上下文，是处理长文本的正确姿势 |
| Injection / 注入 | 把检索到的相关片段放进 prompt 里、让模型基于它回答的动作 |
易混对比：
- 上下文窗口 vs 记忆：窗口是"一次性可见输入"，记忆是"跨会话长期状态"（Agent 侧机制）
- Prompt vs Context：prompt 是你给模型的全部输入，context 是 prompt 里的"背景知识"部分
【练一练】
目标：亲手感受"上下文长度 vs 精度"的关系——看模型在长文本中能不能抓住关键信息。
实验：找一个长文本（任何 5000 字以上的文章/报告/产品说明书都行），然后做两组测试：
A 组（全塞）：把整篇文章直接贴给模型，然后问一个需要从文章中间部分找答案的问题。
- 记录：模型答对了吗？花了多少 token？（如果看不到 token 数，就估算字数×1.5）
B 组（检索注入模拟）：你先从文章里手动找出和问题相关的 2–3 个段落（总共不超过 500 字），只把这几段贴给模型，问同样的问题。
- 记录：模型答对了吗？用了多少 token？
对比分析：
- A 组和 B 组的答案质量差多少？
- A 组用的 token 是 B 组的多少倍？（粗略估算即可）
- 如果 A 组答错了，是不是答案来自文章的开头或结尾，而忽略了中间？（这就是 lost-in-the-middle）
思考题：如果你要做一个"企业内部文档问答"产品，你会选择"买一个超大窗口模型全塞进去"的方案，还是"用 RAG 检索只放相关片段"的方案？为什么？