AI 不说“不知道”的真相：为何宁可瞎编

事情是这样的。

一位朋友搭建了企业内部知识库问答机器人。

第一轮测试表现良好。用户问“报销发票抬头如何填写”，机器人从制度文档中检索到答案，回复清晰有条理。

第二轮，用户追问“跨部门项目报销要走什么审批流程”，它也能接上，大致回应需项目负责人审批。

第三轮，用户接着问“那这个跨部门项目是否需要补交报销附件？”问题暴露了。

知识库里其实没有关于“跨部门项目报销附件”的明确条款。但机器人没有回答“不知道”。它开始一本正经地编造：“跨部门项目报销需提交项目编号及审批附件，格式为PDF或图片。”朋友当场愣住了——因为公司根本没有这项流程。更要命的是，这句话听上去真实得可怕：语气平稳，格式规范，还透着一股正式制度文件的腔调。

这就引出了今天的核心问题：为什么AI明明不知道答案，却非要装作知道？

先下结论：它不是嘴硬，而是其工作机制压根不依赖“知道或不知道”

很多人习惯把AI拟人化。人类回答问题，大脑大致有三种状态：我确定、我不确定、我不知道。但大语言模型的工作方式完全不同。

它的底层目标可概括为：给定上文，预测下一个最合理的词。听起来无害？但放在问答系统里，风险极高——因为“下一个最合理的词”不等于“事实正确的词”。

换句话说，模型不会先扫描一遍自己的知识库：“我是否知道答案？”然后再决定如何回应。它更像是在当前提示词、上下文、训练经验和解码参数的共同驱动下，生成一段“看起来最像答案”的文本。

AI的默认行为不是追求事实，而是延续文本。如果系统没有额外设计“拒答机制”，它很容易把“不知道”续写成“假装知道”。

第一层，训练目标本身就没有教会它闭嘴

预训练阶段，大模型学习的是语言模式。它扫描过海量网页、书籍、问答、代码、论坛和技术文档。训练目标大致如下：输入“报销发票抬头应该填写”，期望输出后续token。模型学会的是“公司全称，并确保与税务登记信息一致”。这在多数场景下有效。问题在于，它学到的是语言分布，而非企业制度数据库。

它知道“这类问题通常该如何回答”，却不知道“你们公司的具体规定”。因此，当用户提出一个缺乏证据支撑的问题时，模型依然能生成流畅的答案。

这好比一位候选人在面试中从没做过某项目，但听过大量模板话术，于是现场拼凑出一套听起来很像项目经验的叙述。能说，不代表做过；能生成，不代表知晓。

第二层，许多系统提示词正在鼓励它“不要冷场”

更现实的工程问题在于，很多人接入大模型时，提示词是这样写的：“你是一位专业、耐心、友好的企业助手。请详细回答用户问题。回答应清晰、完整、有条理。”听起来没问题？但线上系统最怕的就是这种“只要求有帮助，不要求有证据”的设定。

因为模型会把“专业、详细、完整”理解成一种输出风格，进而倾向：不要显得无能、不要回答太短、不要让用户失望、尽量补全缺失信息。于是，当资料不足时，它不会停下来，而是继续补充。

更糟糕的提示词是这种：“如果未找到相关资料，请结合你的通用知识回答。”这句话基本等于给幻觉开了绿灯。在企业知识库、法务、财务、医疗、客服等场景下，“结合通用知识”往往不是兜底，而是事故入口。

正确的做法，是把拒答设计成第一等公民：“你只能基于中的资料回答。如果资料不足以支持结论，必须回答：‘根据当前资料无法确认。’严禁编造制度、流程、编号、时间、金额、负责人、审批规则。”注意这里的差别——不是礼貌地建议它“不确定可以说不知道”，而是明确告知：没有证据时，拒答就是正确答案。

第三层，RAG系统经常“未检索到也照常生成”

很多幻觉并非模型单独犯错，而是RAG链路设计失误。一个常见的糟糕实现如下：

def answer(question):
    docs = vector_db.search(question, top_k=5)
    prompt = build_prompt(question, docs)
    return llm.generate(prompt)

这段代码看似正常，但问题在于它永远会调用llm.generate()——无论检索到的文档是否相关，无论相似度分数有多低，无论文档中是否包含答案。

结果就是：检索未命中 → 上下文很空或很脏 → 模型仍被要求回答 → 它开始根据语言经验补全。

一个靠谱的实现至少需要阈值判断：

def answer(question):
    docs = vector_db.search(question, top_k=5)
    useful_docs = [doc for doc in docs if doc.score >= 0.78]
    if not useful_docs:
        return {"answer": "根据当前资料无法确认。",
                "status": "insufficient_context", "citations": []}
    prompt = build_grounded_prompt(question, useful_docs)
    return llm.generate(prompt)

这段代码解决的不是“让模型更聪明”，而是一个更基础的问题：没有证据时，别把模型推上台表演。RAG中最常见的幻觉链路，不是模型突然发疯，而是系统拿着一堆低质量甚至空资料，对模型说“请回答”——那它当然会编造。

第四层，模型没有天然的“置信度仪表盘”

很多人会问：“那模型难道不知道自己是在编造吗？它输出的概率分布不就反映了置信度吗？”这话只对了一半。模型生成时确实有概率分布，比如下一个token可能有这些候选：需要（0.41）、建议（0.22）、可以（0.17）、不需要（0.08）、无法确认（0.03）。但这个概率并非事实置信度——它只表示在当前上下文里，哪个词更像下一个词。“需要”概率高，不代表现实中真的需要。

这就是许多系统误判的地方。你让模型输出{"answer": "...", "confidence": 0.92}，看起来很高级。但如果这个confidence也是模型自己生成的，它很可能只是另一段文本——而非监控指标、统计校准或事实保证。

真正可用的置信判断，应该来自系统侧的证据：

模型说“我很确定”，不太值钱；系统能证明“这句话出自哪份资料”，才真正有价值。

第五层，产品体验也在逼迫它撒谎

还有一个很现实的痛点。很多产品经理不喜欢“不知道”。客服机器人说“不知道”，用户觉得没用；销售助手说“不知道”，业务觉得不智能；知识库助手说“不知道”，老板觉得模型买亏了。于是系统会被调成：尽量回答、尽量详细、尽量给出建议、尽量不拒绝用户。这在演示中很好看，但上线后迟早出问题。

因为在企业系统里，错误答案的成本常常比没有答案高得多——财务制度答错可能导致报销违规，法务条款答错可能引发合同风险，运维操作答错可能造成线上故障，医疗建议答错后果更不用多说。

因此工程上必须接受一个反直觉的事实：一个会说“不知道”的AI，才是更成熟的AI。并非每个问题都回答才叫智能，知道何时该闭嘴也是一种能力。

真正的解法，不是指责模型，而是给它装上刹车

如果只在提示词里写一句“不要胡说”，作用有限——因为幻觉是系统性问题。要解决它，至少需要一套组合拳。

1. 将问题先改写成可检索的问题

多轮对话中，用户经常这样问：“那这个要不要补附件？”——这个“这个”指什么？是普通报销？跨部门项目？差旅？外包采购？如果直接拿这句话去检索，向量库很可能跑偏。更好的做法是先做query rewrite：

用户当前问题：那这个要不要补附件？
对话历史：用户询问跨部门项目报销流程。
改写后的检索问题：跨部门项目报销是否需要补充附件，附件材料包括哪些？

但query rewrite也有副作用——它可能改错用户意图。所以改写结果必须能被记录、调试、回放，不能变成黑盒。

2. 检索结果必须经过门禁

不要搜到什么就塞给模型，要判定：分数是否够、文档是否过期、来源是否可信、内容是否与当前问题同域、多份资料是否冲突。可以加一个简单的门禁层：

def validate_context(docs):
    if not docs:
        return False, "empty_context"
    if docs[0].score < 0.78:
        return False, "low_retrieval_score"
    if has_conflict(docs):
        return False, "conflicting_documents"
    return True, "ok"

这层逻辑很朴素，但能挡住大量“没资料还硬答”的事故。

3. Prompt中要标清资料边界

不要把资料一股脑塞进去，要告诉模型每段资料的来源、时间、版本、可信等级：

[doc_1] 来源：财务制度 v2026.03 更新时间：2026-03-12 可信等级：高 内容：跨部门项目报销需关联项目编号...
[doc_2] 来源：旧版报销FAQ v2024.11 更新时间：2024-11-02 可信等级：低 内容：部分项目报销可补充审批截图...

要求：
1. 只基于可信等级高且未过期的资料回答。
2. 如果资料之间冲突，说明无法确认。
3. 每个关键结论必须引用doc id。

这不是形式主义——这是在告诉模型：资料边界清晰，不要越界。没有这些边界，模型很容易把旧资料、新资料、用户猜测、历史对话混在一起。

4. 输出后做引用校验

生成答案后，不要直接返回给用户，至少做一层claim check。例如模型回答“跨部门项目报销必须提交项目立项书”，系统要检查：“必须”有没有来源？“项目立项书”有没有来源？对应文档是否确实这么写？引用是否只是贴了个无关文档？如果关键结论找不到证据，就降级为：“根据当前资料无法确认是否必须提交项目立项书。已找到的资料仅说明需要关联项目编号。”

这一步会增加延迟，但在高风险场景里，这个成本值得。

工程上如何落地

如果你现在负责一个企业AI问答系统，别一上来就追求“回答更聪明”，先把系统从“必答模式”改成“有证据才答”。一个可落地的链路大致如下：

用户问题 → 问题改写 → 混合检索 → 重排序 → 上下文门禁 → 基于证据生成 → 引用校验 → 答案 / 拒答 / 转人工

上线前重点监控以下几个指标：

这里有个平衡：拒答太少，幻觉高；拒答太多，用户觉得没用。所以不要拍脑袋调提示词，要用评估集来调——例如准备200个问题：100个知识库有明确答案的，50个资料不足的，30个资料冲突的，20个恶意诱导或越权问题。然后看系统能否区分这些问题。

真正的AI工程，不是把模型接上去就完事，而是让它该回答时回答，该拒绝时拒绝，该转人工时转人工。

面试如何回答这个问题

如果面试官问“为什么AI会产生幻觉”，不要只答一句“因为它是概率模型”，太浅了。

可以这样回答：

我会从训练目标和系统工程两个层面展开。第一，大模型预训练目标是预测下一个token，它天然更擅长生成“像答案的文本”，而非判断事实是否存在。第二，很多对话系统的提示词强调helpful、详细、完整，却没有把“资料不足必须拒答”设计成强约束。第三，RAG系统如果没有检索阈值、上下文门禁和引用校验，就会出现没搜到也继续生成的情况。第四，模型自己输出的confidence不能直接当作事实置信度，真实置信要结合检索分数、引用覆盖率、文档一致性和人工评估。因此解决幻觉不能只靠一句提示词，而要从query rewrite、retrieval gating、grounded generation、claim verification和eval指标一起下手。

如果面试官继续追问“具体怎么做？”，可以进一步回答：

我会做三件事。第一，在提示词和输出协议里明确拒答条件，没有证据时返回insufficient_context。第二，在检索层设置门禁，比如top1分数过低、文档冲突、资料过期时，不进入生成链路。第三，在评估层单独统计correct refusal rate和unsupported claim rate，避免系统为了看起来有用而降低拒答率。

这比“调低temperature”靠谱多了。顺便提一句，调低temperature可以让输出更稳定，但它不能从根源上解决无证据生成——低温瞎编，还是瞎编，只是编得更稳定。

最后回到开头的那个机器人

它为什么不说“不知道”？不是因为它有坏心眼，也不是因为它真的自信。而是整个系统从训练目标、提示词、检索、生成到产品指标，都在推着它回答。用户问“这个要不要补附件”，知识库没给证据，检索没拦住，提示词还要求它专业、详细、完整——于是它只能顺着语言惯性往下写，写出一个像制度、像流程、像标准答案的假答案。

所以别再只问“AI为什么会有幻觉”。在生产系统里，更应该问的是：“我们有没有让它在没证据时闭嘴？”因为很多时候，AI最有价值的一句话不是长篇大论，而是那句真诚的——“根据当前资料无法确认。”

来源：互联网