Token、上下文窗口与 RAG 的工程取舍

做 RAG 或 AI 助手时，很容易有一种直觉：模型的上下文越长，就把越多资料直接塞进去；资料越多，回答应该越准确。

实际做下来会发现，这个直觉并不可靠。

模型并不是按“多少页文档”或“多少个汉字”处理输入，而是按 Token 处理。上下文变长会带来成本、延迟和注意力分散的问题；检索到的内容太少，模型缺少依据；检索到的内容太多，又可能把真正关键的信息淹没。

所以 RAG 的重点不是单纯给模型更多资料，而是在用户问题、可用上下文和资料质量之间做取舍。

Token 是模型实际处理的单位

用户看到的是文字，模型实际处理的是 Token。

一段文字进入模型前，会先被 Tokenizer 切分成 Token，再映射成 Token ID 和向量。Token 不一定等于一个完整的汉字、英文单词或字符；它可能是子词、标点、空格、字节片段或特殊标记。

这意味着“这篇文档有多少字”不能直接推导出它会占用多少上下文。同一段内容在不同模型、不同 Tokenizer 下，Token 数也可能不同。

系统指令、用户问题、历史对话、工具调用结果、RAG 检索片段和模型输出，都会一起占用上下文窗口。真正可用的空间，通常比只看用户输入时想象得更少。

因此，做 AI 应用时不应该把某个“一个 Token 等于几个字”的经验值当成固定公式。需要精确估算时，应该使用目标模型或接口对应的 Tokenizer；只需要粗略规划时，也要给输出和工具结果预留空间。

长上下文不等于模型一定更会回答

更长的上下文窗口让模型能够看到更多信息，但它不能保证模型会稳定地抓住最重要的内容。

如果把整份产品文档、历史记录和无关说明全部塞进提示词，模型可能会：

• 忽略真正和问题有关的段落；
• 受到旧版本或互相矛盾内容的干扰；
• 生成成本更高、响应更慢；
• 在有限输出空间里给出更泛的回答。

这不是说长上下文没有价值。对需要比较多个文档、理解较长链路或分析一段代码时，它很有用。问题在于，长上下文只是容量，不是自动的知识组织能力。

在实际产品中，更重要的是先判断：用户这次的问题到底需要哪些资料？哪些内容是当前版本？哪些内容只是背景，不应该参与回答？

RAG 解决的是“按问题找资料”，不是永久记忆

RAG 的基本流程并不复杂：把资料清洗、切块并建立索引；用户提问后，先找出相关片段，再把这些片段连同问题交给模型回答。

它的价值在于，模型不必依赖训练阶段从未见过的私有资料，而可以在回答前读取与问题相关的依据。

但 RAG 也不是给模型外挂一个永远准确的记忆。

检索系统只负责找到“可能相关”的片段。它不会天然知道哪份文档已经过时，不会自动解决同一概念在不同版本里写法不一致的问题，也不能保证切分后每个片段仍保留完整语义。

所以，RAG 的效果很大程度上取决于知识本身是否可用：文档是否清楚、版本是否可辨认、切块是否保留了必要上下文、检索结果是否真的和用户问题相关。

切块不是越细越好，也不是越长越好

资料切块时，常见的两个极端都容易出问题。

切得太小，单个片段可能只剩一句结论，没有前提、对象或操作步骤。模型拿到它以后，容易把结论用到错误的场景。

切得太大，一个片段里会混入多个主题。它虽然看起来信息完整，但检索时很难精确命中，也会占用更多上下文。

更实用的思路是围绕资料的自然结构切分：一个功能说明、一个故障排查步骤、一条配置规则、一个问答单元，通常比按固定字数生硬截断更容易保留语义。

必要时还应把标题、版本、产品模块或来源位置作为元信息保留。这样在检索到片段后，模型和用户都更容易判断它适用于什么场景。

检索质量比“塞得多”更重要

如果用户问的是某个功能怎样配置，最有价值的可能是一段当前版本的操作说明，而不是十段泛泛相关的介绍。

如果用户问的是某个报错，最有价值的可能是包含复现条件、错误信息和解决步骤的记录，而不是整个项目的概览。

因此，检索结果进入模型前最好再经过一层判断：

• 结果是否真的回答了当前问题？
• 来源是否属于当前有效版本？
• 多个片段之间是否互相矛盾？
• 是否需要把来源或不确定性告诉用户？

这层判断可以由规则、人工维护、模型重排或它们的组合完成。具体方式取决于产品规模，但目标始终一样：让模型看到少而可靠的依据，而不是大量模糊相关的内容。

上下文预算是一项产品决策

上下文窗口不是一个单纯的模型参数，它会直接影响用户体验。

给每次请求加入更多资料，可能提高部分问题的覆盖度，也可能增加费用和等待时间。保留完整历史对话，可能让回答更连贯，也可能把已经失效的偏好和内容一直带下去。

所以，一个 AI 应用通常需要先决定：

• 哪些信息每次都必须带上；
• 哪些信息应该按问题检索；
• 哪些历史需要摘要、压缩或丢弃；
• 哪些资料必须标注版本或失效状态；
• 用户在什么情况下需要看到回答依据。

这些选择不会有一套适合所有产品的固定答案。客服知识库、个人笔记助手、代码问答和内部业务助手，面对的资料形态、错误成本和用户期待都不一样。

结语

模型上下文再长，也不会自动替产品整理知识。RAG 再完整，也不能替人判断资料是否正确、是否最新、是否适用于当前问题。

我现在更愿意把它们看成一套信息取舍机制：Token 决定模型实际能处理什么；上下文窗口决定一次请求能带多少信息；RAG 决定哪些信息值得带进去；产品设计决定怎样在准确性、速度和成本之间取舍。

当这些边界被考虑清楚后，AI 助手才更可能从“偶尔答对”变成一个能在真实资料上稳定工作的工具。