P6-2.4 连接到 prompt 长度、RAG chunk 与成本的 token 视角¶

Section ID: P6-2.4 Version: v2026.07.26

如果已经理解 token 与 tokenization 的差异，接下来剩下的问题只有一个。看到真实故障或运营不便时，能不能马上选出应该把 token 视角重新应用到哪里。

本节不是重复上一节关于长度、成本、chunk 的说明。这里要收住的是token 标准会连接到哪一个运营 lever。

核心可以压缩成下面一句话。

token 视角会连接到在输入、检索、输出、评估中决定留下什么、减少什么的运营判断。

失败场景与运营 lever¶

需要再次使用 token 视角的场景很多，但首先要做的事，是把场景改写成应该调整哪里的问题。

这张表就是本节的核心。上一节看的是 token 用在哪里，这里要选择的是所以现在应该调整哪里。

如果把这个判断画成顺序，可以像下面这样读。如果表格是并排比较使用处，这个图则展示了看到实际失败时，先确认 token 证据，再决定把问题送到哪一个 lever 的流程。

flowchart TD
  A["与 token 相关的失败<br/>出现在日志或复核中"]
  B["确认 token 证据<br/>输入长度 / chunk 边界 / 输出上限"]
  C{"压力最先<br/>出现在哪里？"}
  D["输入侧<br/>压缩 prompt 或拆分长文档"]
  E["检索侧<br/>重新调整 chunk 与 overlap"]
  F["输出侧<br/>缩短格式并把核心句提前"]
  G["评估侧<br/>用 token trace 比较失败案例"]

  A --> B
  B --> C
  C --> D
  C --> E
  C --> F
  C --> G

区分 token 问题的运营 lever¶

Prompt 长度调整¶

同一个请求如果改写得更短、更干净，就能减少输入 token 数。这里重要的不是句子是否变得漂亮，而是是否用更少的 token 传达了同样的意思。

RAG chunk 设计¶

按段落边界看起来漂亮的 chunk，不一定适合检索。从 token 视角看，更重要的是问题、条件、例外、依据是否留在同一个输入捆绑里。

成本预算估算¶

如果输入与输出成本按 token 计算，预算估算也应该先看平均 token 数，再看件数。数字、表格、URL、代码片段很多的请求，可能比表面看起来更贵。

长文档输入策略¶

即使文件数量少，只要每个文件很长，总 token 长度也会很快变大。所以处理长文档时，应该先按 token 标准问留下什么、拆开什么，而不是先问有几个文件。

输出格式设计¶

表格、列表、补充说明、代码块越多，输出 token 也越多。这里重要的问题不是什么看起来好，而是什么必须留到最后。

评估日志解读¶

评估(evaluation)结果低时，如果马上只怀疑模型质量，失败原因可能会变模糊。从 token 视角看，要把失败案例的输入长度、检索依据被截断的位置、触碰输出上限的地点、实际使用的 token 数一起看。同样是评估分数下降，由输入被截断导致的失败，和因为回答格式太长而把核心句挤掉的失败，下一步动作不同。

案例与示例¶

案例 1. 前置条件总是被挤走时¶

请求很相似，但前半部分的条件总是被截掉或推到后面时，很容易先认为这是模型质量问题。可是这个场景中最先要调整的是 prompt 长度。用更少的 token 传达同样的意思，模型必须读取的条件就能更稳定地留在输入前部。

这个案例的问题场景是必须遵守的前置条件随着请求变长而变弱。人最先使用的标准是把条件写得更详细，模型就会更好遵守。这个标准的限制在于，详细说明本身也会消耗输入 token，因此必须保留的条件可能被其他表达挤开。

因此这个案例里要确认的结果，不是先问模型为什么做不到，而是先问输入预算里要留下什么。

案例 2. 检索结果漏掉例外时¶

检索结果只带来原则，却总是漏掉例外时，很容易觉得检索模型太弱。可是这个场景中最先要调整的是 RAG chunk 设计。问题、条件、例外、依据必须留在同一个输入捆绑里，检索候选才不容易摇晃。

这个案例的问题场景是明明找到了相关文档，答案却漏掉例外条件。人最先使用的标准是检索结果带来了相关文档，所以检索已经成功。这个标准的限制在于，如果检索候选里只有原则，而例外没有留在同一个 token 捆绑中，答案仍然可能出错。

因此这个案例里要确认的结果是，检索质量问题不一定立刻就是检索算法问题，chunk 边界可能先发生摇晃。

案例 3. 回答最后的核心句被截断时¶

不断添加表格和列表，回答可能看起来更亲切，但最后核心句被截断的风险也会变大。此时最先要做的判断，不是增加更亲切的格式，而是以什么必须留到最后为标准缩减输出格式。

这个案例的问题场景是回答前半部分很丰富，但最后的结论或限制条件经常被截断。人最先使用的标准是表格、列表、补充说明越多越亲切。这个标准的限制在于，格式本身也会先消耗输出 token，并可能把必须留到最后的核心句挤掉。

因此这个案例里要确认的结果是，token 视角会让我们先确定信息保留的优先级，而不是先看输出格式是否美观。

token 视角改变的运营判断¶

把失败分流到运营 lever¶

应用 token 视角时常见的卡点是，虽然同意token 很重要，但看到实际问题时，不能马上选出应该先调整哪一个运营 lever。此时不要重新解释 token 概念，而要把当前最先显露出来的失败分成输入问题、检索捆绑问题、输出格式问题或评估日志问题。

前置条件被挤走，就先看输入压缩。例外没有被检索到，就先看 chunk 边界。成本估算偏离，就先看实际输入、输出 token 日志。结论被截断，就看输出格式是否在核心句之前先消耗 token。评估失败很模糊时，不要只看回答句子，而要看输入、检索依据、输出上限之中哪一个先摇晃。

改写成运营问题¶

本节要留下的核心应用，不是token 很重要，而是现在的问题应该改写成哪一个运营问题。因此把失败场景重新改写成下面的问题与 lever。

这张表的目的不是让你背更多运营 lever。它的目的，是在看到实际服务场景时，让你马上选择token 视角应该重新连接到哪一个判断标准。

Chapter 2 最后要带走的感觉是这个。token 不只是一个术语，而是在阅读、设计、运营 LLM 时帮助你决定先调整哪里的判断标准。

练习与示例¶

下面的练习不是要求重新说明 token 概念。它是在看到实际失败场景后，选择最先调整的运营 lever 的练习。每一项都先自己回答，再和下面的解说比较。

练习 1. 选择最先调整的 lever¶

观察值：

先自己回答。

• 每个场景中最先调整的运营 lever 是什么？
• 为什么一开始就怀疑模型质量或检索算法会太快？

解说：前置条件被挤走的场景，先看 prompt 长度调整。检索结果漏掉例外的场景，先看 RAG chunk 设计。响应最后被截断的场景，先看输出格式设计。三个场景都可能涉及模型本身的性能问题，但在那之前，必须先确认 token 预算内有什么留在输入、检索候选和输出里。重点不是把失败直接推给模型，而是把失败改写成最先调整的运营 lever。

练习 2. 把观察值改写成运营问题¶

观察值：

先自己回答。

• 每个观察值应该改写成什么运营问题？
• 分别连接到哪一个使用处？

解说：预算超出要改写成是否按实际日志查看平均输入、输出 token 数？，使用处是成本预算估算。长文档结论缺失要改写成是否用 token 预算决定留下什么、先拆开什么？，使用处是长文档输入策略。表格格式之后最后一句被截断，要改写成格式是否在核心句之前先消耗输出 token？，使用处是输出格式设计。失败的评估案例集中在长输入和长输出格式上时，要改写成输入、依据、输出之中哪一个先碰到 token 上限？，使用处是评估日志解读。这样改写观察值后，token 视角就不再是抽象原则，而会变成实际调整项。

练习 3. 区分留下的东西和减少的东西¶

观察值：

先自己回答。

• 上面各项分别连接到哪一个运营 lever？
• 为什么只靠做短一点还不够？

解说：法律限制条件与重复说明的区分连接到 prompt 长度调整。例外条款是在 RAG chunk 设计中必须留在同一组的上下文。表头和装饰性分隔短语，是输出格式设计中可以减少的 token。重要的不是无条件做短，而是在 token 预算内，按运营 lever 分别决定留下什么和减少什么。

检查清单¶

• 能否说明在实际失败场景中，token 视角会连接到哪一个运营 lever？
• 能否在 prompt 长度、chunk 设计、成本预算、长文档输入、输出格式、评估日志之间选择先调整什么？
• 能否不只把 token 当作定义，而是作为运营判断标准重新拿出来？

出处与参考资料¶

• OpenAI Help Center, What are tokens and how to count them?, 确认日期：2026-07-19。用于确认输入、输出 token 数与使用量、成本、长度判断相连接。
• OpenAI Help Center, Controlling the length of OpenAI model responses, 确认日期：2026-07-19。用于确认输出长度可以通过 token 限制控制。
• OpenAI API Reference, Vector store files, 确认日期：2026-07-19。用于确认 file search 所用 vector store 文件的 chunking_strategy、max_chunk_size_tokens、chunk_overlap_tokens 字段。
• OpenAI API Reference, Evals, 确认日期：2026-07-19。作为评估执行和基于日志的数据源会作为独立运营观察值管理的背景依据。
• Daniel Jurafsky, James H. Martin, Speech and Language Processing, 3rd ed. draft, online manuscript released January 6, 2026, 确认日期：2026-07-19。作为 tokenization 与语言模型输入说明的一般 NLP 背景依据。