模型温度能降低图片理解幻觉吗这个问题我在过去大半年里被问过不下二十次每次我都想先反问一句你说的“降低”是把错误答案变少还是把错误答案说得更少这两件事在视觉语言模型上是完全不同的两个指标。我自己在一套六百张图的自建样本上把温度从 0 拉到 1.0 扫了一遍结论有点扫兴温度不是消除图片理解幻觉的开关它只是一个调节“先验”和“证据”谁说话更大声的旋钮。调得好能把描述型幻觉压掉三到五个百分点调得不好会让模型变得更自信地胡说。这篇就把我踩过的坑、量化的数据、以及比调温度管用得多的几个手段一次讲清楚。适合正在做多模态应用落地、被“图里明明没有这个东西它非说有”折磨过的同学也适合刚接触视觉语言模型、想搞清楚采样参数到底在干什么的朋友。1. 先搞清楚温度到底在改什么1.1 从 logits 到概率一行公式背后的取舍很多人对温度的理解停留在“越小越严谨、越大越有创意”这话不算错但它掩盖了一个关键事实温度不改变模型对世界的认知它只改变模型在已有认知上的选择倾向。数学上它做的事非常朴素就是在 softmax 之前把 logits 除以温度 Tp_i exp(z_i / T) / Σ_j exp(z_j / T)T 小于 1分布被“锐化”高分区被进一步放大T 大于 1分布被“抹平”低分区被抬起来T 趋近 0 时退化成 argmax 贪心解码工程实现里一般直接特判避免除零。光看公式没感觉我拿一组具体数字算给你看。假设某一步模型输出的 logits 是[4.0, 2.0, 1.0]分别在三个温度下算一遍温度 T缩放后 logits概率分布0.5[8.0, 4.0, 2.0]0.980 / 0.018 / 0.0021.0[4.0, 2.0, 1.0]0.844 / 0.114 / 0.0422.0[2.0, 1.0, 0.5]0.628 / 0.231 / 0.140看到了吧T 从 1.0 降到 0.5第二名从 11.4% 掉到 1.8%基本等于被判了死刑。这就是问题的核心温度锐化的是“排名”不是“正确性”。如果排名第一的那个 token 本身就是错的你把温度调到 0.1只会让模型更坚决地错下去。我经常用这样一个类比跟团队新人解释温度像是会议室里的麦克风音量旋钮它调的是“谁的声音更大”不是“谁说得对”。如果平时嗓门最大的那位恰好说错了你把音量拧到最大只会错得更响亮。1.2 温度不等于“事实性旋钮”为什么低温会显得更准那为什么很多人包括曾经的我第一反应是“低温更准”因为在判别式任务上这个经验确实部分成立。像“图中有没有猫”“这句话和图是否一致”这类问题候选答案空间极小往往就是 yes/no 两个 token 的对抗而视觉证据通常足以把正确答案顶到第一名。此时温度降低等于把本来就不大的领先优势放大成压倒性优势方差变小输出稳定主观感受就是“准了”。但这个“准”是稳定性带来的错觉。我做过一个很简单的对照同一批图同一套 yes/no 问题让模型跑五次T0 时五次答案完全一致T0.7 时有 22% 的题出现了答案翻转。人眼看到前者会觉得“这模型挺靠谱”看到后者会觉得“飘”。可如果统计首次答案的正确率两者差距远小于稳定性差距。换句话说低温帮你买到的是一致性不是知识。更麻烦的是另一面低温会系统性地偏袒训练分布里的高频模式。图片里到底有没有伞模型内部其实有两股力量在博弈——视觉 token 给出的证据和语言先验给出的“这个场景通常有什么”。温度降低等于给领先者加权而领先者往往是先验因为先验在训练数据里被重复了太多次。于是出现一个反直觉的现象在“反常识图片”上低温的幻觉率反而更高。这一点我在第 3 节会用数据说明。1.3 图片理解幻觉的四种类型与温度敏感性差异要把这件事说清楚必须先给“图片理解幻觉”分个类因为不同类别对温度的敏感度差了一个数量级。我在实际项目里一般拆成这么几类存在性幻觉问“图中有没有某物体”模型答有实际没有。这类问题的答案空间是一个二元判断视觉证据权重高温度影响最小。属性幻觉颜色、材质、数量、状态搞错比如把三个人数成四个、把蓝色说成灰色。数量类对温度中等敏感因为数字 token 的分布本身就偏斜低温容易锁定高频数字比如“2”和“3”。关系与空间幻觉左右颠倒、遮挡关系搞错、“A 在 B 上面”说反。这类错误主要来自视觉编码阶段的空间信息损失温度几乎无能为力。文字与数值读取幻觉截图、票据、图表里的字读错数字抄错。这类任务需要的是确定性温度必须压到最低同时配合结构化约束。还有一类是推理型幻觉前面读对了后面基于错误前提编出一套因果解释。这类在开放式描述里最常见也恰恰是温度影响最大的地方——因为一旦进入自由生成候选空间从几个 token 变成几万个 token采样随机性的杠杆被放大了。所以如果有人问我“温度能不能降低幻觉”我的标准回答是在描述型任务上选对温度能降一点在判别型任务上温度主要是降方差在 OCR 和空间关系上温度基本无关别指望它。把力气花错地方是这类调参最常见的浪费。2. 实验设计把“感觉变好了”变成可复现的数字2.1 评测集怎么造三类样本、四类问题去年我接手一个内部需求要给一套视觉问答链路做质量评估。最开始团队的做法是随便找几十张图人工看输出“感觉还行”然后就上线了。这种评估方式的问题在于它没法回答“温度从 0.2 调到 0.5是变好还是变差”因为没有基线、没有样本量、没有口径。我重新搭了一套自建样本规模 600 张图来源是公开图片素材和内部脱敏截图覆盖六类场景室内杂物堆叠、街景与招牌、表格与报表截图、手写单据、多物体密集场景、低照度与逆光照片。选取这六类的理由是它们分别对应了前面说的几种幻觉类型——杂物堆叠考存在性和计数街景考文字读取表格考数值密集场景考漏检低照度考“证据不足时会不会硬编”。每张图配四类问题共计约 2400 条题目存在性二选一随机注入图中不存在的物体构造“有/没有”的判断正负样本各半。这对应前面说的存在性幻觉也是最容易量化的。计数题针对可数物体人、车、瓶、窗提问允许 ±0 严格判定。开放式描述要求用三到五句话描述图片用于统计描述幻觉率。反常识子集从正常场景里人工擦除一个高频物体比如把桌面上的杯子 P 掉再问“图里有什么”。这一组专门用来验证“低温强化先验”的假设。提示反常识子集是整个评测里最有价值的部分。普通样本上各温度差异很小看不出东西只有在“视觉证据和语言先验打架”的样本上温度的偏向性才会暴露出来。如果你只想做一组对照实验优先做这一组。2.2 打分口径准确率、幻觉率、拒答率、一致率口径不统一数据就白跑。我最后定下来四个核心指标加两个辅助指标指标定义为什么需要它存在性准确率二选一判断正确的比例衡量判别能力描述幻觉率生成描述中与金标冲突的实体数 ÷ 生成实体总数衡量“编造”程度比整体打分更敏感一致率同图同题采样 5 次答案完全相同的比例衡量稳定性业务上直接影响用户信任拒答率输出“无法确定”“图中未显示”的比例防止用“少说话”刷低幻觉率平均输出长度字符数中位数长度崩了说明解码退化平均延迟端到端毫秒数高温 多次采样会显著抬高成本这里要特别强调拒答率。我见过有团队把温度调到极低然后宣称幻觉率下降仔细一看是模型变得极度保守一半以上的问题回答“图片信息不足”幻觉率当然低。这是典型的指标被优化不是模型变好。所以幻觉率和拒答率必须成对看任何一个单独看都会被带偏。2.3 变量控制清单避免踩坑跑多温度对照最容易出的问题是“只有温度一个变量在变”这件事做不到。我把当时固定住的变量列一下你可以直接抄提示词模板逐字一致包括标点和换行max_tokens固定避免长度差异影响幻觉率分母首轮实验统一top_p 1.0、top_k关闭、repetition_penalty 1.0只让温度单飞图片预处理统一长边缩放到同一尺寸、同一压缩质量、同一色彩空间关闭联网、关闭工具调用、关闭任何外部检索每条样本独立请求不复用会话上下文记录服务端返回的模型版本号防止中途灰度切换。最后一条特别重要。我在第二轮实验时就吃过亏跑了两天中间服务端做了一次版本灰度前后半段数据根本不可比白跑。后来我加了版本号落盘一旦发现版本变化就整批重跑。3. 实测结果与解读先说清楚下面的数字来自我自建的 600 图样本、两个模型一个参数量较小的模型 A一个较大的模型 B、单次运行只能看方向不能当行业结论换数据集换模型大概率不一样。我把它放出来是因为趋势本身很有说服力。3.1 温度扫描曲线0.0 / 0.2 / 0.5 / 0.7 / 1.0模型 B 的结果大致是这样温度存在性准确率描述幻觉率计数准确率一致率拒答率描述长度中位数0.084.2%18.6%61.3%100%6.1%92 字0.285.1%17.2%63.0%96.4%5.4%105 字0.583.6%19.8%58.7%88.1%4.8%128 字0.781.0%23.4%54.2%77.6%4.2%141 字1.077.4%28.9%49.5%61.3%3.9%156 字三个观察。第一存在性准确率是一条很平的山丘峰在 0.2 附近但 0.0 到 0.5 之间的差距只有 1.5 个百分点。我算了一下600 条样本、准确率 85% 附近二项分布的标准差大约是sqrt(0.85 × 0.15 / 600) ≈ 1.46个百分点也就是说这套样本量下小于 3 个百分点的差异基本在噪声范围内。所以老实说在判别式任务上温度从 0 调到 0.5你测不出显著差异。真要分辨样本量得翻到四五千条。第二描述幻觉率是明显的 U 形最低点在 0.2 附近接近 0 时反弹超过 0.5 后快速上升。这个形状很好解释温度太低时模型锁死高频模板遇到不典型的图就按“常见场景该有的东西”去编温度太高时采样空间打开各种低概率的、视觉上并无依据的细节被抽出来幻觉自然涨。第三一致率是单调下降的从 100% 一路掉到 61%。这条曲线对业务的影响其实比幻觉率更直接用户连着问两次得到两个不同答案信任度会立刻崩。如果你的场景是客服、审核、辅助决策这类需要可复现的温度上限建议压在 0.3 以内。3.2 不同任务类型的敏感度排序把六类场景拆开看敏感度差异非常明显任务类型温度敏感度最优温度区间原因存在性判断低0.0 - 0.3答案空间小视觉证据占主导计数中0.1 - 0.3数字 token 分布偏斜低温易锁高频数开放式描述高0.2 - 0.5候选空间巨大采样随机性杠杆被放大文字/数值读取极低0.0需要确定性任何随机都是负收益空间关系低0.0 - 0.2错误主要来自视觉编码解码层改不动反常识图片高方向反转0.3 - 0.5低温强化先验压过视觉证据最后一行值得单独说。3.3 反常识子集低温反而更容易编我把擦除了高频物体的那组样本单独拎出来统计结果和直觉相反温度反常识子集幻觉率普通子集幻觉率0.031.4%16.2%0.228.7%15.4%0.422.1%16.8%0.725.6%21.3%1.033.8%27.5%在普通子集上0.2 是最优的但在反常识子集上0.0 的幻觉率比 0.4 高出近十个百分点。典型的表现是我把一张桌面图里的杯子擦掉问“桌上有什么”T0 的模型依然斩钉截铁地说“有一个白色马克杯右侧还有一杯咖啡”。它不是在“看图”它是在“根据桌面的样子回忆桌面通常长什么样”。这就是 1.1 节那个公式的现实版本当视觉证据有杯子的概率是 0.32、语言先验桌面常有杯子的概率是 0.35 时正确答案排在第二名。温度一降0.35 被锐化到接近 1.0模型就再也看不到那个 0.32 了。温度抬到 0.4第二名有了出头机会采样偶尔能抽到“桌面上是空的”这条更贴合证据的路径幻觉率反而降。这个发现直接改变了我们的参数策略如果你的业务图大多是“标准场景”低温没问题如果你的业务图经常出现缺件、异物、异常状态工业质检、货架盘点、安防巡检一味压低温度是在给自己挖坑。3.4 低温的代价退化、拒答和长尾丢失除了幻觉率反弹低温还有三个我实测到的副作用都挺隐蔽。解码退化。部分模型在 T0 且输出较长时会出现复读比如“图中有一张桌子桌子上有一张桌子桌子上有一张桌子”。原因是贪心解码在没有任何回退机制的情况下一旦进了循环就出不来。加一点温度0.1 到 0.2或加frequency_penalty能缓解。拒答率上升。从表里能看到T0 的拒答率是 6.1%T1.0 是 3.9%。低温让模型更倾向走“保守模板”对模糊图片直接说“无法判断”。这在开放问答里算优点但在缺陷检测、漏检排查这类场景就是灾难——你要的是召回它给你的是沉默。长尾词丢失。低温会系统性地抹掉低频表达。同样是描述一件衣服T0 大概率输出“一件蓝色的上衣”T0.5 才会出现“袖口有磨损的深蓝色针织开衫”。如果你的下游需要细粒度属性颜色、材质、磨损状态温度压太低等于主动放弃这部分信息。4. 比调温度更管用的四件事讲到这里应该说结论了温度能带来的改善上限大概就是三到五个百分点而且不稳定真正能把图片理解幻觉压下去的是下面这四件事任何一件的收益都比调温度大。4.1 有效视觉分辨率与切图策略这是被低估最严重的一项。很多“模型看不懂”的问题本质是图传到模型那儿已经没有细节了。算一笔账一张 4000×3000 的原图如果按长边缩到 1024缩放系数约 0.256一个原本 120 像素宽的物体比如货架上的小包装缩完只剩 30 像素。视觉编码器常见 patch 尺寸是 14 或 16 像素30 像素意味着这个物体在特征图上只占不到 2×2 个 patch模型基本不可能准确读出它的颜色和文字。你在这时候调温度调到 0 也不会变对。我的做法是三条先判断任务类型再定分辨率。整图理解类任务长边 1024 到 1280 够用文字读取、小目标计数必须切图。切图用网格 重叠。2×2 切分配 10% 到 15% 重叠避免物体正好被切在缝上。如果原图长宽比极端比如票据改成沿长边等分 3 到 4 段。每张切片单独提问最后做合并去重。合并时用实体名归一大小写、单复数、同义词否则同一辆车会被数成两辆。实测下来光是加上 2×2 切图这一步密集场景的计数准确率就能从 58% 提到 74%比任何温度设置都有效。4.2 提示词与输出结构约束第二件事是把“自由发挥”改成“按格式填表”。温度之所以能在描述型任务上兴风作浪是因为你给了它一片毫无边界的草原。约束住输出结构采样随机性的作用面就小了一大半。我常用的一套模板长这样你是一个严谨的图像信息提取器。请严格按以下步骤工作 1. 先列出你在图中确实看到的物体每个物体附带它在画面中的大致位置 左/中/右、上/中/下。 2. 再回答用户的问题。 3. 如果某个信息在图中无法确认写 uncertain不要推测。 4. 只输出 JSON不要输出任何解释性文字。 输出格式 { observed: [{name: , position: , color: }], answer: , confidence: high | medium | low } 用户问题{question}三个关键点先列举证据再回答问题强制模型走一遍视觉 grounding允许输出 uncertain给它一条体面的退路比逼它编强结构化输出把自由文本变成受约束的字段能显著削弱高温带来的发散。这套模板在我这边把描述幻觉率从 18% 左右压到 11% 上下而且是在温度 0.3 的前提下不需要牺牲多样性。4.3 两阶段生成 回问校验第三件事是加一个校验回路代价是成本翻倍但收益是数量级的。流程是第一阶段自由生成描述 → 抽取其中所有实体和属性 → 第二阶段逐条回问模型“图中是否存在 X” → 删除未通过校验的项。回问这一步的提示词要单独设计不能用生成时的那个否则模型会顺着自己刚才的话往下说。我的写法是每次只问一个实体问法要中立请只回答 yes 或 no。图中是否存在「{entity}」 不要结合上下文推测只依据你在图像中直接观察到的内容。为什么这么做有效因为“生成描述”是一个高熵任务模型在一句话里要同时管语法、连贯、内容很容易顺手编而“判断某物是否存在”是一个低熵任务模型只需要对一件事做判断视觉证据的权重被显著抬高。两个任务的失败模式不一样交叉验证能过滤掉相当一部分幻觉。成本估算假设一张图平均描述 200 token抽取 8 个实体逐个回问每次约 60 token总消耗大约 200 8×60 680 token是纯生成的三倍多。如果业务量小、准确率优先这笔钱花得值如果量大可以只对置信度低的样本做校验或者只校验颜色、数量这类高风险字段。4.4 采样参数组合别只盯着温度温度从来不是一个人在战斗它和top_p、top_k、repetition_penalty是一套组合拳。我整理了一张按任务类型来的配置表可以直接拿去用任务类型temperaturetop_ptop_k其他说明文字/票据读取0.01.0关闭结构化输出 切图需要绝对确定存在性判断0.10.9关闭yes/no 约束低方差为主计数任务0.20.9关闭先列举后计数避免锁高频数字开放描述0.3 - 0.50.9关闭结构化 长度上限兼顾细节和稳定异常/缺件排查0.40.95关闭多次采样投票优先召回多候选枚举0.6 - 0.70.9关闭5 次采样取并集要多样性补一句top_p和温度的关系top_p是在温度锐化/抹平之后做截断所以两者叠加会放大效果。温度 0.3 配top_p0.9 是温和收紧温度 0.3 配top_p0.5 就会明显削掉长尾输出变得很“标准答案”细节全丢。我一般只在文字读取场景用低top_p其他场景保持 0.9 左右别叠太狠。5. 参数配置模板与代码实现5.1 一次请求的最小可用配置不管你用哪家的接口请求体里这几个字段是共通的我把一个偏保守、适用于大多数图像理解场景的配置贴出来{ model: your-vision-model, temperature: 0.3, top_p: 0.9, max_tokens: 512, messages: [ { role: user, content: [ {type: text, text: 你的结构化提示词}, {type: image_url, image_url: {url: base64 或可访问地址}} ] } ] }几点实操提醒。max_tokens别设太小低温下模型有时会先复述再回答太小会截断在半句话上反而让幻觉率统计失真。图片如果走 base64注意请求体大小限制超过 5MB 的图先压缩。另外不同实现对temperature的下限处理不一样有的允许 0有的会内部截到 0.01评测时要在报告里注明否则复现不了。5.2 批量评测脚本骨架下面是我扫温度用的脚本精简版去掉了内部依赖逻辑保留完整。核心是同一批样本、只变温度、结果落盘import json, time, hashlib, os from concurrent.futures import ThreadPoolExecutor from statistics import mean TEMPERATURES [0.0, 0.2, 0.5, 0.7, 1.0] PROMPT open(prompt.txt, encodingutf-8).read() def cache_key(image_id, temp, prompt): raw f{image_id}|{temp}|{prompt}.encode(utf-8) return hashlib.md5(raw).hexdigest() def call_model(image_b64, temp, prompt): 替换为你所用服务的调用方式返回 (文本, 输入token, 输出token, 模型版本) payload { temperature: temp, top_p: 1.0, max_tokens: 512, messages: [{ role: user, content: [ {type: text, text: prompt}, {type: image_url, image_url: {url: fdata:image/jpeg;base64,{image_b64}}} ] }] } # resp your_client.chat(payload) # return resp.text, resp.usage.prompt, resp.usage.completion, resp.model_version raise NotImplementedError def run_one(item): image_id, image_b64 item[id], item[b64] rows [] for t in TEMPERATURES: key cache_key(image_id, t, PROMPT) path fcache/{key}.json if os.path.exists(path): rows.append(json.load(open(path, encodingutf-8))) continue try: text, ptok, ctok, ver call_model(image_b64, t, PROMPT) row {id: image_id, temp: t, text: text, ptok: ptok, ctok: ctok, version: ver, ts: int(time.time())} except Exception as e: row {id: image_id, temp: t, error: str(e)} json.dump(row, open(path, w, encodingutf-8), ensure_asciiFalse) rows.append(row) return rows if __name__ __main__: samples json.load(open(samples.json, encodingutf-8)) all_rows [] with ThreadPoolExecutor(max_workers4) as pool: for part in pool.map(run_one, samples): all_rows.extend(part) # 版本号一致性检查中途换版本说明数据不可比 versions {r.get(version) for r in all_rows if version in r} if len(versions) 1: print(f[警告] 检测到多个模型版本{versions}建议整批重跑) # 按温度聚合 for t in TEMPERATURES: subset [r for r in all_rows if r[temp] t and text in r] if not subset: continue avg_len mean(len(r[text]) for r in subset) print(fT{t:.1f} n{len(subset)} 平均长度{avg_len:.0f})几个我加进去的细节值得说明。缓存键包含提示词哈希改了提示词就自动失效避免拿旧结果骗自己。落盘带时间戳和版本号方便事后定位“数据为什么前后不一致”。并发数控制在 4 左右太高容易触发限流返回一堆 429反而拖慢整体进度。5.3 成本估算与降级策略跑之前先算钱。600 张图 × 5 个温度 × 平均图片 token 约 1000 输出 200≈ 360 万 token如果再加两阶段校验平均 8 个实体回问总量会翻到 1000 万 token 上下。这个量级在正式评测前最好先用 50 张图做预跑确认脚本没有 bug 再全量。生产环境的降级策略我是这么设计的默认温度 0.3 结构化输出这是基线检测到输出里有不确定表达可能似乎无法确定或长度异常短自动升级到 0.4 重跑一次并做实体校验OCR 类请求固定走 0.0 且不重试避免两次结果不一致给下游埋雷。这套策略跑下来整体调用量增加约 18%但人工复核率降了将近四成。6. 常见问题排查与踩坑实录6.1 温度调了完全没变化先查这五处这是我最常被问到的问题按概率从高到低排第一服务端忽略了你的参数。有些网关会对特定模型强制覆盖temperature或者做了参数白名单。验证方法很简单把温度设成 1.5如果允许看输出是否明显发散如果毫无变化基本可以确定被忽略了。第二走了缓存。同一图片同一提示词的重复请求被服务端缓存返回的是第一次的结果。加一个随机 nonce 到提示词末尾就能验证。第三结构化输出模式削弱了采样。带 JSON schema 约束的解码时模型在每个位置只能从合法 token 里选可选空间被人为压缩温度的作用被大幅削弱。这时候温度 0.1 和 0.7 的差异会小得超出预期不是 bug。第四请求被路由到不同后端。负载均衡后面挂了多个版本你调的是 A 的效果测的是 B 的表现。查返回体里的版本字段。第五你的指标不敏感。用 30 条样本、准确率指标去比两个温度噪声比信号大。前面算过600 条样本下标准差约 1.5 个百分点30 条样本下标准差约 6.5 个百分点测什么都测不出来。6.2 幻觉问题速查表现象最可能的原因优先动作图里没有的东西被说成有且描述得很具体语言先验压过视觉证据温度提到 0.3-0.4加“先列举后回答”模板同一张图两次回答不一致温度偏高或未固定温度压到 0.2 以下检查是否有 seed 参数小物体、远处物体识别不出来有效分辨率不足切图 提高输入分辨率与温度无关数字、金额、编号读错文字区域太小或压缩过度温度 0切图要求逐字输出并二次核对数量总是少数一个遮挡或密集场景漏检切图 分区域计数再求和输出开始复读同一句话贪心解码进入循环温度 0.1-0.2或加 frequency_penalty大量回答“无法确定”温度过低或提示词过于保守温度提到 0.3放宽不确定表达的限制描述很流畅但细节全是编的高温 无结构约束温度降到 0.3改结构化输出 实体校验6.3 几个我实打实踩过的坑坑一以为 T0 就是完全确定。实际上在批处理场景下同一请求在不同 batch 里的浮点累加顺序可能不同导致 T0 时偶尔也会出现输出差异。差异通常很小标点、语序但在做严格 diff 时会让你怀疑人生。如果你的业务要求逐字节可复现除了温度 0还得固定 batch 策略或者干脆加结果缓存。坑二只看准确率不看幻觉率。早期我用一个综合打分做评估温度从 0.2 调到 0.5综合分只掉了 0.3 分看起来无所谓。后来拆开看描述幻觉率涨了 2.6 个百分点但描述丰富度评分涨了不少两相抵消。如果你的业务对“编造”零容忍就必须把幻觉率单独拎出来当主指标别让它被平均掉。坑三样本量和结论不匹配。我一度用 120 条样本得出“0.2 比 0.0 好 4 个百分点”的结论兴冲冲写进文档。后来扩到 600 条差距缩到 0.9 个百分点落在噪声里。这件事教会我任何小于 3 个百分点的差异在几百条样本上都不值得写进结论。要么扩大样本要么承认测不出来。坑四忽略了图片预处理的一致性。同一张图一次用 PNG 一次用 JPEG 质量 75模型的输出可能差出一大截尤其是文字和细纹理。我后来把预处理写死在代码里任何评测都走同一个函数杜绝这类变量。坑五把温度当成万能挡箭牌。有段时间线上出幻觉第一反应就是“把温度调低”。调了之后幻觉没降多少拒答率倒是涨了用户体验更差。真正解决问题的是加了切图和实体校验。温度在这件事里贡献大概不到两成。6.4 一个反直觉的用法用中等温度做召回最后分享一个我觉得比较有意思的实践。在“异常排查”类任务里比如货架缺货、设备缺件正确做法不是压低温度求稳而是适度提高温度做多次采样取并集。具体做法是温度 0.5、采样 5 次把所有提到过的异常项汇总再用一个独立的判断请求逐条核实。5 次里只要有 2 次以上提到同一个异常就进入人工复核队列。这套流程在缺件排查上的召回比单次 T0 高出接近一倍代价是误报多了但因为有人工兜底整体反而是划算的。背后的道理还是那句话低温让模型只走最熟悉的那条路而“异常”恰恰是最不熟悉的那条路。你要它发现异常就得允许它偶尔乱走。我个人在实际项目里的体会是模型温度这个参数被赋予了太多它承担不起的期待。它是个好东西但它管的是“分布的形状”不是“知识的对错”。真要把图片理解幻觉压下去得把力气花在分辨率、提示词结构、校验回路这些看起来笨、但收益实打实的地方。温度更像是最后的微调——在别的地方都做对了之后花半小时扫一遍 0.0 到 0.6找到那个让你的业务指标最舒服的点然后就别再动它了。我现在的默认值是 0.3异常排查场景用 0.5 加多采样文字读取一律 0.0一年下来没怎么改过。