AI应用开发 Day 2｜大模型五个关键参数

一Token 是计费和截断的单位，不是字数

token 跟字数不是一回事，按字数估算一定偏低。

中文一个常用字大约 1 到 2 个 token，生僻字、繁体、带标点的表格更费。英文和代码更碎：VARCHAR(2000) 这种串会被切成好几段，一个 JSON 的括号和引号也各占一个。

这意味着两件事。第一，计费按 token，成本模型必须建在 token 上，不能建在“文档多少字”上。第二，截断也按 token，你算出来“没超”的输入，实际可能已经超了。

项目里的日志表每次调用都记 prompt token 和 completion token，不是为了好看。它是唯一可信的口径——出问题时打开表，就能看到那次调用到底塞了多少进去，而不是靠字数反推。

粗略换算：一千个汉字大概一千五到两千 token，一千行 Java 代码可能顶三千个汉字。做容量规划，先用真实样本跑一遍，把返回里的 usage 记下来再乘。别拍脑袋。

二上下文超限，按三级处理，顺序不能反

上下文超了，处理手段只有三种，代价从低到高。

第一级是截断：保住 system，保留最近 N 轮，把中间的老消息丢掉。它最便宜，但会丢信息，只适合闲聊类对话——用户不会追问十轮前说过的话。

第二级是摘要：把老对话压成一段“此前讨论了什么、已确认哪些结论”，替换掉原始消息。它保住语义，但摘要本身要花一次调用，而且会失真。

第三级是分段：长文档切成块，一块一块送，最后合并结果。它最贵，但唯一能保证不丢细节。

顺序是先分段、再摘要、最后才截断。

很多人反过来，先截断图省事，结果模型答得驴唇不对马嘴，还以为是模型不行。

PDF 抽取平台里就是这个逻辑：pdf_chunk 存分片，切坏的段落（跨页表格、OCR 断行）重新智能切分，把结果写进 smart_content 再送模型。真正的问题从来不是“上下文不够长”，而是“切在了不该切的地方”。跨页表格被从中间截断那次，抽取结果里出现“表格仅显示部分内容”，我查了半天 Prompt，最后发现是切分。

三温度和 Top-P，只调一个

这两个参数都在控随机性，同时调等于两个变量互相干扰，你永远不知道效果变化是谁带来的。

我的做法是固定一个：抽取、分类、结构化输出，temperature 设 0，要的是可复现；文案、起名、头脑风暴，温度调到 0.7 上下，Top-P 那边不动。

温度低不等于一定正确，它只保证同样的输入倾向于同样的输出。这对回归测试很关键——同一批样本跑两遍结果不一样，你根本没法判断是改了 Prompt 起了作用，还是模型自己在抖。

Top-P 是另一套思路：从概率最高的一批候选里采样，累加到阈值就停。它和温度不是“两个旋钮都拧一点更好”。选一个当你唯一的旋钮，另一个锁死，出了变化才好归因。

四max_tokens 留不够，JSON 会断在半句

这是最容易被忽略的一个。max_tokens 限的是输出长度，不是输入。设小了，模型不是“说得简短”，是直接被砍断。

抽取任务最怕这个。你要的是一段完整 JSON，模型写到第三个字段，额度用完，返回一个 finish_reason=length 的半截文本，解析报错，重试逻辑再跑三次，三次都断在同一处。

三条正确做法：按最坏情况估输出长度再往上留一截；把 finish_reason 记进日志，等于 length 就直接判失败，别当解析异常处理；Prompt 里明确“只输出 JSON，不要解释”，减少无关 token 的消耗。

返回被截断的时候，先看 finish_reason，再看内容。顺序反了，你会花半天去调 Prompt，其实只是额度不够。

五面试速记

六Java 存量映射

这五个参数合起来，就是一次 HTTP 调用的超时、重试和报文大小限制，只不过下游从 DB 换成了模型：token 是报文长度，上下文窗口是单次请求上限，max_tokens 是响应体大小，温度和 Top-P 是同一个业务开关的两种实现——你不该同时拧两个。

七一句话带走