1. 为什么别再问大模型“你有多确定？”

如果你用过 ChatGPT、Claude 或者任何大语言模型，大概率问过类似的问题：“你确定吗？”或者“请给出一个置信度分数”。我们习惯性地希望得到一个像传统软件系统那样的概率输出，比如“我有 95% 的把握这个答案是正确的”。但今天我要告诉你一个核心观点：直接向大语言模型索要一个置信度分数，是一个无效且可能误导你的操作。

这背后不是一个简单的功能缺失问题，而是由大语言模型（LLM）的根本工作原理决定的。LLM 本质上是一个基于海量文本训练出的、极其复杂的概率模型，它的核心任务是“预测下一个最可能的词”。当你问它“法国的首都是哪里？”，它并不是从一个知识库里检索出“巴黎”，然后计算一个置信度。它是在计算，在“法国”、“的”、“首都”、“是”这一连串词之后，“巴黎”这个词出现的概率有多大。这个概率，和你理解的“答案正确的把握”是两回事。

更关键的是，当你直接问它“你有多确定？”时，你得到的回答，只是模型根据你的指令，生成的一段符合“表达确定性”模式的文本。它可能说“我非常确定”，也可能说“我有 90% 的把握”。但这只是它“扮演”一个自信的实体时产生的文本，这个数字本身并没有经过校准，也不代表模型内部对事实正确性的真实评估。它可能对一条完全错误的信息，也“自信满满”地给出 99% 的分数。

所以，这篇文章不是要告诉你某个模型不支持这个功能，而是要彻底改变你对 LLM 输出“确定性”的认知方式。无论你是开发者正在构建基于 LLM 的应用（Agent、RAG 系统），还是普通用户希望更可靠地使用 AI，理解这一点都能帮你避开很多坑。我们接下来要讨论的，就是当你真正需要评估 LLM 回答的可信度时，应该看什么、做什么。

2. 拆解“置信度”：模型输出 vs. 事实正确性

要理解为什么不能直接问，我们需要先拆解几个容易混淆的概念。当我们谈论“置信度”时，通常混合了两种完全不同的诉求：

1. 模型的内在概率：即模型在生成当前这个 token（词）时，分配给它的概率值。例如，在生成了“法国的首都是”之后，模型计算“巴黎”的概率是 0.85，“伦敦”的概率是 0.1。这个概率反映了模型在训练数据中学到的语言模式的强弱，比如“巴黎”与上下文的共现概率极高。但这不等于“巴黎是法国首都”这个事实在现实世界中的正确性概率。模型可能对一段编造得合乎语法、但完全虚假的历史叙述，也赋予很高的生成概率。

2. 事实正确性的概率：这才是我们用户真正关心的——“这个答案符合事实的可能性有多大？”这是一个需要外部知识或验证过程才能得出的评估结果，而不是模型能直接“感受”并吐出的一个数字。

LLM 擅长生成第一种概率（作为其工作过程的副产品），但它无法直接提供第二种概率。当你命令它“给出一个置信度分数”时，它实际上是在执行一个新的文本生成任务：“根据刚才生成的答案，编造一个合理的置信度描述”。这个过程可能参考了它训练数据中关于“确定性”的表述，但与答案的真实性无关。

2.1 一个简单的思维实验

假设你问一个 LLM：“珠穆朗玛峰的高度是多少？”它回答：“8848米。”然后你追问：“你有多确定？” 它可能回答：“我非常确定，我有 99% 的把握。” 现在，你换一种方式问：“珠穆朗玛峰的高度是 8848 米，对吗？”它回答：“对。” 你再问：“你有多确定这个‘对’的判断？”它可能回答：“我相当确定，大约 95%。”

看到了吗？针对同一个事实性答案，模型根据你提问方式的不同，可以“生成”出不同的“置信度”文本。这些数字是随上下文而变的文本产物，不是可度量的、稳定的真实性指标。

2.2 这对开发者和用户意味着什么？

对于开发者，尤其是构建LLM Agent或RAG系统的人，这意味着你不能依赖model.generate(..., return_confidence=True)这样的幻想 API 来做关键决策，比如是否自动执行一个危险操作，或者是否将一个未经验证的答案直接呈现给用户。你需要设计一套外部验证机制。

对于用户，这意味着你需要改变使用习惯。不要因为模型说“我确定”就全盘接受，也不要因为它说“我不太确定”就完全否定。你需要建立自己的交叉验证习惯。

3. 如何可靠地评估 LLM 输出的可信度？

既然不能直接问模型要分数，那我们该怎么办？答案是：将评估工作从模型内部转移到外部流程中。下面是一套从简单到复杂、可实操的评估策略。

3.1 基础策略：交叉验证与溯源检查

这是不需要任何编程基础就能用的方法。

• 多轮追问与压力测试：不要只问一次。用不同的方式问同一个问题，或者要求模型从不同角度解释它的答案。如果答案在多次询问下保持一致且逻辑自洽，可信度相对更高。例如，问完“如何修复这个代码错误？”后，接着问“这个修复方案可能有什么潜在风险？”。
• 要求提供来源/引用：直接提示模型：“请为你的答案提供依据或来源。”虽然 LLM 可能会“幻觉”出不存在的引用，但这个要求本身能促使它的回答更倾向于基于训练数据中的事实片段。对于具备联网搜索功能的模型，这个策略更有效。
• 领域常识比对：用你自己的知识或快速搜索，对答案的关键点进行核实。对于完全陌生的领域，至少可以检查答案内部是否有明显的逻辑矛盾或违反常理之处。

3.2 进阶策略：基于提示工程与自洽性

适合有一定经验的用户或开发者，通过设计提示词来间接“探测”模型的确定性。

• 思维链提示：要求模型“一步一步思考”。通过展示其推理过程，你可以判断结论是否建立在合理的步骤上。一个逻辑跳跃、步骤混乱的思维链，其最终答案的风险也更高。
• 自我质疑提示：让模型自己挑战自己。例如：“针对你刚才给出的答案，请列出三个可能不成立的理由或假设。”如果模型能列出扎实的质疑点，说明它对这个答案的边界有认知；如果列出的质疑点很弱或无关，可能意味着它“盲目自信”。
• 多视角提示：让模型以不同身份或立场来回答同一问题。例如：“请分别以支持者和反对者的角度，分析这个观点。”如果从两个对立角度得出的分析都指向同一个核心事实，那么这个事实部分的可信度就更高。

3.3 工程化策略：构建外部验证管道

这是生产级应用必须考虑的方法。核心思想是：不信任单一输出，引入冗余和验证。

1. 多次采样：对于同一个问题，让模型在相同的条件下独立生成多次（例如 5 次）。然后比较这些输出。

   • 一致性检查：如果 5 次输出在关键事实和结论上高度一致，那么最终答案的可信度较高。你可以统计一个“共识度”（如 5 次中有 4 次提到同一个关键数据）。
   • 工具：通过设置temperature > 0和多次调用generate来实现。

2. 验证模型：使用另一个模型（最好是不同架构或训练数据的）来评估主模型的输出。这可以是：

   • 事实核查：提问“以下陈述是否正确：[主模型的输出]”，让验证模型判断真伪。
   • 逻辑一致性检查：让验证模型分析主模型答案中的推理是否存在漏洞。
   • 注意：验证模型本身也有幻觉风险，但这构成了一个简单的冗余系统，比单一模型可靠。

3. RAG 的检索置信度：在 RAG 系统中，真正的“置信度”应该来自于检索到的参考文档。

   • 关键指标：关注检索到的文档与生成答案的相关性分数（如向量相似度得分）。如果生成答案所依据的 top-k 个文档片段都具有很高的相关性分数，那么答案的根基更牢。
   • 引用溯源：确保生成的答案能明确关联到具体的文档片段。这样，置信度就转移到了“文档是否权威”以及“引用是否准确”这两个更可验证的问题上。

4. 元提示评估：设计一个复杂的提示，让模型对自己答案的多个维度进行评分。这不是要一个简单的分数，而是一个结构化的评估报告。例如：

   请你以评估员的身份，对以下答案进行评估：

   1. 事实准确性（低/中/高）：基于公开常识判断。
   2. 逻辑连贯性（低/中/高）：答案内部推理是否自洽。
   3. 对问题核心的回应程度（低/中/高）。 请为每个维度提供简要理由。

   这种方法得到的评估文本，比一个孤立的分数包含更多可解释的信息。

4. 给开发者的实战建议：在 Agent 与 RAG 中处理不确定性

当你构建一个LLM Agent时，Agent 需要决定何时调用工具、何时给出最终答案。一个常见的错误设计是：让 LLM 自己说“我 80% 确定，可以执行此操作”。这非常危险。

4.1 为 Agent 设计决策逻辑

更稳健的设计模式如下：

1. 设定确定性阈值：这个阈值不是模型给的，而是你作为系统设计者定义的。例如，对于“发送邮件”这类高风险操作，你的系统阈值可能是“需要至少 3 个独立信息源交叉验证”。
2. 工具调用作为验证手段：让 Agent 在给出最终答案前，必须调用搜索工具、计算器工具或查询工具来验证关键信息。LLM 的角色是规划验证步骤、解析工具返回结果，并综合判断。
3. 基于验证结果的决策：决策逻辑基于工具返回的客观结果，而不是 LLM 自我宣称的置信度。
   • 示例流程：
     • 用户问：“特斯拉2023年全球交付量是多少？”
     • Agent（LLM）规划：需要查询权威数据。调用搜索工具。
     • 搜索工具返回：多个来源显示约为 181 万辆。
     • Agent 分析结果：多个来源一致，数据可信。
     • Agent 最终回答：“根据公开财报和数据，特斯拉2023年全球交付量约为181万辆。” （这里隐含了高可信度，但依据是外部验证，而非内部分数）。

4.2 在 RAG 系统中量化可信度

在 RAG 架构中，你可以构建一些可量化的、有意义的“置信度”指标：

你可以为这些指标设定权重，综合计算出一个RAG 可信度分数。这个分数比直接问 LLM 要可靠得多，因为它基于可观测、可解释的组件状态。

4.3 落地方案：一个简单的可信度评估管道示例

假设我们有一个问答系统，以下是一个简化的 Python 伪代码流程，展示了如何不依赖 LLM 自评，而是通过流程来管理不确定性：

def answer_with_confidence(question): # 1. 检索 retrieved_chunks, similarity_scores = retrieve(question, top_k=5) avg_similarity = np.mean(similarity_scores) # 2. 基于检索结果生成答案 context = "\n".join(retrieved_chunks) prompt = f"基于以下信息回答问题：\n{context}\n\n问题：{question}\n答案：" # 3. 多次采样以评估一致性 answers = [] for _ in range(3): answer = llm_generate(prompt, temperature=0.7) answers.append(extract_key_facts(answer)) # 提取关键事实（如实体、数字） # 4. 计算一致性 consistency_score = calculate_fact_overlap(answers) # 5. 检查答案是否忠实于上下文 faithfulness_score = check_faithfulness(final_answer, retrieved_chunks) # 6. 综合评分（简单加权示例） overall_confidence = 0.5 * avg_similarity + 0.3 * consistency_score + 0.2 * faithfulness_score # 7. 根据置信度决定响应策略 if overall_confidence > 0.8: return final_answer, overall_confidence # 高置信度，直接返回 elif overall_confidence > 0.5: return final_answer + "\n\n（注：该信息基于多方资料综合，建议进一步核实。）", overall_confidence else: return "未能找到足够确定的信息来回答此问题。", overall_confidence

5. 总结：从“索取分数”到“设计流程”

回到最初的问题：“Don‘t ask an LLM for a confidence score.” 这句话的真正启示是，我们应该停止向一个文本生成模型索取它无法提供的、具有严格统计意义的可靠性度量。这就像向一台优秀的打印机询问它刚打印出来的那份报告内容的真实性有多高——打印机只负责墨迹的精确，不负责内容的真伪。

正确的路径是：

1. 心态转变：将 LLM 视为一个极具创造力和语言能力的提议生成器，而不是一个事实数据库。它的输出默认需要经过验证。
2. 流程前置：在设计任何依赖 LLM 的系统时，提前把“如何验证输出”作为核心模块来设计，而不是事后补救。
3. 依赖客观信号：关注那些可观测、可量化的信号，如检索相关性、多答案一致性、外部工具返回结果，用这些信号来构建你的“置信度”。
4. 分层响应：根据你构建的外部可信度指标，设计不同的响应级别。高可信度答案可以直接呈现，中等可信度的答案可以附带提示，低可信度的则应该明确表示无法回答或建议用户核查。

最终，与 LLM 协作的最高效率，来自于理解它的强项（语言、推理、创意）和弱项（事实性、确定性），并通过我们的设计和流程来弥补其弱项，而不是要求它变成一个它永远无法成为的“全知全能且自知”的系统。