一句话怎么变成模型的回答

1值班助手：拼请求，选模型

值班助手把系统提示、61 行日志和问题拼成一个 JSON，发到模型服务。请求里还写了用哪个模型、最多写多少个 token。对模型来说，这就是一大段要续写的文字，没有别的。

为什么要它模型不会自己去拉日志，它能看到的只有这一次请求里的文字。请求里没放的东西，它就不知道。

Java 里≈ 用 RestTemplate 调一个按量计费的 HTTP 接口。model 字段选模型，就像选云主机规格：Claude Opus 5.5 输入每百万 token 4 美元，Haiku 5.5 只要 0.1 美元（按文档）。

往下一层怎么选模型：能力、价格、速度、开源闭源、国内外 待做

常出的事把整段日志原样塞进去，不挑也不删：又贵又慢，关键的那一行还容易被淹没（第 3、5 站）。

2分词器：文字切成 token

模型不认字，只认一张词表里的编号。分词器把文字切成词表里有的片段，每段换成一个编号（token id）。这个模型的词表有 151936 项。实测 一行 120 个字符的 GC 日志切成了 80 个 token，数字几乎一位一个：

整个请求一共 4950 个 token。中文的问题“order-04 这 10 分钟变慢，是不是 GC 导致的？”切成 21 个，“是不是”是一个 token。

为什么要它模型内部只做数字运算，得先把文字变成数字。按片段切而不是按字符切，序列短得多。

Java 里≈ String.getBytes(UTF_8)，只不过查的是一张十几万项的词表。每家模型的词表不一样，同一段话在 Claude 上是多少 token，要用它的 count_tokens 接口算，别拿别家的分词器估（按文档）。

往下一层token、分词和计费 待做

常出的事按字数估成本：日志里的时间戳、地址、数字特别费 token，实际比估的多出好几倍。

3上下文窗口：装不装得下

模型一次能处理的 token 有上限，叫上下文窗口，输入和输出共用。本机这次开的是 8192：4950 个输入，加上最多 120 个输出，装得下。Claude Opus 5.5 的窗口是 100 万个 token，单次最多输出 12.8 万个（按文档）。

为什么要它第 5 站要让每个 token 和前面所有 token 都算一遍关系，还要把中间结果存在显存里，长度不可能无限。

Java 里≈ 堆内存上限。区别是装得太满不会报 OOM：超过上限会直接报错，没超但塞得很满时，它会悄悄抓不住重点。

往下一层上下文窗口：输入输出共用，越长越慢越贵 待做

常出的事日志从 10 分钟改成 60 分钟，约 3 万 token：本机 8192 的窗口直接装不下；换成大窗口能装下，但更慢、更贵。

4向量表：每个 token 变成一串数

每个 token id 去一张大表里查一行，得到一个向量。这个模型每个向量有 896 个数（n_embd = 896，读自模型文件）。从这里开始，模型处理的就是 4950 个向量。

为什么要它编号本身没有意思，1358 和 1359 未必相近。向量是训练出来的，意思相近的 token，向量也挨得近，后面的计算才有东西可算。

Java 里和 hashCode 正好相反：hashCode 要把东西打散，向量要让意思近的靠在一起。

往下一层Embedding：文本变向量，意思近的靠得近 待做 · 补给：够用的数学：向量、点积和概率 待做

常出的事把这张表和站 06 做检索用的 Embedding 模型当成一回事：思想相同，但检索用的是另一个专门的模型，输出一整段话的向量。

5读完输入：注意力，再存下 KV 缓存

4950 个向量一起穿过模型的每一层。每一层里，每个 token 都去“看”它前面所有的 token，按相关程度把它们的信息加权混进来，这一步叫注意力。算的过程中，每个 token 在每一层留下两组中间结果，叫 K 和 V，全部存下来，就是 KV 缓存。实测 这一步花了 133.1 秒，平均每秒处理 37 个 token。

为什么要它“20:15 变慢”和 61 行之外的“Pause Full 1873ms”要能联系起来，靠的就是注意力。存下 KV，后面每写一个新 token 就不用把前面重算一遍。

Java 里KV 缓存 ≈ 把算过的中间结果存进一个 Map，下次直接取。同一段前缀再来一次，实测 只要 1.3 秒；Claude 的提示缓存是同一个道理，命中的部分按 5%～10% 的价格计费（按文档）。

往下一层注意力和 KV 缓存（只讲到够用） 待做

常出的事在系统提示开头放当前时间或请求号：前缀每次都变，缓存一次也命中不了。

6算出下一个 token 的概率

只看最后一个位置的结果，模型给词表里的 15 万多个 token 各打一个分，换算成概率，加起来是 1。实测 回答的第一个 token：

“是”和“不是”加起来不到八成。到了“20:15”这样的数字，下一个 token 几乎是确定的，概率是 1.000。

为什么要它这就是模型的全部本事：给定前文，下一个 token 是什么的概率。回答、写代码、调工具，都是一个 token 一个 token 接出来的。

Java 里≈ 一个巨大的纯函数 f(前文) → Map<token, 概率>，没有查库，也没有 if 判断“日志里有没有 Full GC”。

往下一层一次只写一个 token：下一个词预测 待做

常出的事把高概率当成“查过了”。概率高只说明这么写像，不说明它对。第 10 站的“10 次 Full GC”就是这么来的。

7采样：从概率里挑一个

有了概率表，还要真的挑出一个。温度（temperature）控制挑法：温度 0 每次都挑概率最大的；温度越高，概率小的越有机会被挑中。实测 同一个问题各问 4 次：

• 温度 0：4 次一字不差，“是的，订单服务 20:15 变慢，是 order-04 的 GC 导致的。”
• 温度 1：4 次 4 个样。有一次开头就是“订单服务…”，有一次引用了 GC（1259），日志里那一行只是普通的 Young GC。

为什么要它永远挑最大的，回答会呆板、容易原地打转；完全随机又会胡说。采样在稳和活之间调。

Java 里≈ 按权重随机抽一个（ThreadLocalRandom 加累积概率）。注意：Claude 新一代模型已经不让调这个参数，Opus 5.5 收到 temperature 或 top_p 会直接报 400（按文档）。

往下一层采样：temperature 和 top_p 改的是什么 待做

常出的事以为温度 0 就一定每次一样。服务端的批处理和浮点运算顺序会带来细小差别，两个候选概率接近时可能翻转，所以不保证。

8接上，再来一圈

挑中的 token 接到末尾，回到第 6 站再算下一个。这一次只需要算这一个新 token：前面的 K、V 都在缓存里。所以一圈出一个 token，实测 每秒 11.6 个。服务端每出一个就可以推给值班助手，这就是“流式输出”。

推理模型多了一段：先在这个循环里写一段“思考”，再写给你看的回答。思考也是 token，按输出计费；Claude Opus 5.5 的思考关不掉，只能用 effort 调深浅（按文档）。

为什么要它下一个 token 要依赖刚写出的那一个，没法一次并行写完。这是写得慢、输出单价贵的根本原因。

Java 里≈ while (!done) { sb.append(next(sb)); }，配上一个缓存，让 next 不必每次从头读 sb。

往下一层一次只写一个 token：下一个词预测 待做 · 推理模型和“思考”：用 token 换质量 待做 · 注意力和 KV 缓存 待做

常出的事不开流式，又让它写长文：用户盯着空白等几十秒，HTTP 客户端还可能先超时。

9停下

停下有两种情况。一是模型自己写出了结束符，它也是词表里的一个 token，这时 stop_reason 是 end_turn；二是写到了 max_tokens，被硬生生截断，stop_reason 是 max_tokens。实测 这次写了 28 个 token 后自己停了。

为什么要它循环得有出口。“什么时候说完”也是模型学出来的，而 max_tokens 是调用方的保险丝。

Java 里≈ 循环的退出条件：要么 break，要么到了最大次数。

往下一层一次只写一个 token：下一个词预测 待做

常出的事不检查 stop_reason：被截断的半句话、半个 JSON 当成完整结果用了。

10值班助手：结算，核对

回答和用量一起回来：输入 4950、输出 28 个 token。按 Claude 的价格算这一问（按文档的价格估算，Claude 的分词结果和本机小模型不同）：

输出按 300 估，是给思考 token 留的余量。然后核对：追问“有几次 Full GC”，实测 它答“一共有 10 次 Full GC”，列出 1200、1201……，其实那是 Young GC 的编号，Full GC 只有 1 次；问“堆最大是多少”，它答 1200M，日志里写的是 1024M。

为什么要它钱按 token 算，要心里有数；回答是“像”出来的，关键事实要拿原文核对。

Java 里≈ 云服务账单加对账：调用方要自己记 usage，自己校验返回值。

往下一层为什么会一本正经地编（幻觉） 待做 · token、分词和计费 待做 · 怎么选模型 待做

常出的事把模型说的数字直接写进值班报告。缓解办法：要它逐字引用原文，再用程序去日志里查这一行在不在，这就是站 06 “先查资料再回答”的出发点。