模型 幻觉 风险 报错怎么解决

模型一本正经地编出一个不存在的函数名、一个查不到的字段，代码跑起来报错，你还以为是接口坏了。这类问题介于「模型输出质量问题」和「工程报错」之间，两边的排查文档都不太覆盖。这篇给一套可落地的识别信号、降低手段和排查顺序，让你遇到时不用靠猜。

模型一本正经地编出一个不存在的函数名、一个查不到的字段，代码跑起来就报错，你还以为是接口挂了。这类问题夹在「输出质量」和「工程报错」中间，两边的排查文档都不太覆盖，所以最容易靠猜。

这篇不聊原理，只给一套能落地的动作：先认出幻觉长什么样，再从源头压下来，接着在代码里兜住，最后真报错了按顺序排。所谓幻觉率、模型对比这类数字随时在变，需要对照时到站内模型资料库看当时的结论，别拿旧印象下判断。

先认出幻觉：它长什么样，别跟接口报错混在一起

处理幻觉的第一步不是修，是归类。归错类，后面全白干。先拿你业务里 5 到 10 条真实问题跑一遍，给每条回答打一个标签，量出这条链路大概是什么水位，再决定投多少工程成本。

• 回答过于整齐、通篇没有具体出处，先怀疑内容层，别先怀疑网关；
• 同一个问题问两次答案不一致，基本可以判定不稳定，先记进日志再改；
• 让你「参考某文档」却给不出可点开的路径，是典型的编造信号；
• 模型明确回「不知道」或给出低置信度提示，这不算幻觉，别误伤。

从源头降：提示词、检索、结构化输出三件事按顺序做

能靠约束解决的，不要留到代码里救。成本最低的是提示词，其次是检索，最后才是结构化输出，按这个顺序投入回报最高。

1. 提示词限定范围系统提示词里写清只能基于给定材料回答、不确定时显式说不知道、禁止编造函数名与字段名，改完拿同一批问题重跑对比。
2. 该检索的上检索需要事实依据的场景，把资料切片入库，让模型基于召回内容回答并要求标来源；检索链路怎么搭不在这儿展开，按站内 RAG 相关文章走。
3. 结构化输出收口能上函数调用或严格 JSON Schema 就别用自由文本再正则去抠，格式约束越硬，编造字段的空间越小。

不适用的情况要说清：创意写作、头脑风暴这类本来就要求发散的活，不要上强约束，否则输出会变得干瘪。约束只加在需要确定性的链路上。

在代码里兜住：输出校验与失败重试的最小设计

提示词是概率，代码是确定。真正保命的是解析前那几行校验，按成本从低到高排三层，别跳步。

结构校验

能不能解析、必填字段在不在，最便宜，先跑这个

类型与取值校验

枚举值、数字范围、字段是否存在，挡住越界输出

业务校验

引用的函数名、表名、接口路径是否真实存在，最值钱也最容易漏

• 业务校验别省：把模型给的函数名、字段名拿去和你的代码或 schema 对一遍，对不上直接拦，别让它进执行环节；
• 失败要分级：结构错了可以把报错回填给模型重试一次，业务校验不过就别重试，降级到人工或更保守的回答；
• 重试次数设上限，避免既烧钱又拖慢响应；
• 把失败的原始输出记日志，字段至少含提示词版本、模型、失败类型，攒够几十条就能看出是提示词问题还是模型不适合这活。

真报错了，按这个顺序排：先分锅，再修

报错时的第一反应往往是换模型，这通常只是换个形式继续错。下面四步按顺序走，一步只动一个变量。

1. 先看原始输出把模型返回的完整内容（不是你的解析结果）打出来看一眼，很多所谓报错只是多了一段解释文字导致解析失败，跟接口无关。
2. 分幻觉还是正常报错报错里出现不存在的字段、函数、表名，八成是幻觉；出现 401、429、超时这类，去站内对应的排查文章，别在这儿耗。
3. 定位层级提示词层、检索层、模型层、后处理层，逐层单独替换一次就能锁定是哪一层的问题。
4. 定改法能靠约束就改提示词，靠资料就补检索，靠代码就把校验写严；换模型放到最后再考虑。

幻觉不是模型坏了，是你的链路上少了一道校验。