1. 从确定性到概率性为什么RAG系统需要“不确定性”度量最近在折腾一个多跳问答项目时我遇到了一个典型问题系统给出的答案看起来“很自信”但仔细一查发现它引用的文档片段之间逻辑是断裂的甚至存在矛盾。更麻烦的是作为开发者我很难量化这种“自信”背后到底有多少水分。这让我开始思考我们构建的检索增强生成RAG系统本质上还是一个“黑盒”。我们输入问题它输出答案和引用但我们很少去追问这个答案的可靠性到底有多高支撑它的证据链有多牢固这正是“不确定性传播”要解决的问题。传统的RAG流程无论是简单的检索-生成还是更复杂的智能体Agentic工作流其内部决策如检索哪篇文档、如何分解问题、如何综合信息大多是确定性的。模型会输出一个看似确定的答案但它无法告诉你“我有多不确定”。在需要高可靠性的场景比如医疗咨询、金融分析或法律文档解读中这种“伪确定性”是危险的。贝叶斯不确定性传播Bayesian Uncertainty Propagation提供了一种框架将这种“黑盒”过程转变为“灰盒”。它的核心思想是将RAG流程中的每个关键组件检索器、重写器、推理器、生成器都视为一个概率模型。每个组件不仅输出一个结果如一篇文档、一个子问题、一个中间答案还会输出一个关于该结果的不确定性度量例如一个概率分布或置信度分数。然后这种不确定性会像涟漪一样从一个组件传播到下一个组件最终累积到最终答案的不确定性上。举个例子在一个多跳问答中系统需要先回答“A公司的CEO是谁”再用这个答案去检索“该CEO在2023年的公开演讲中提到了哪些技术趋势”。如果第一步检索“A公司CEO”时系统的不确定性就很高比如检索到的维基百科页面可能已过时或者公司有联席CEO那么这种高不确定性就应该被传递并放大到第二步的检索和最终答案生成中。最终系统不仅给出一个答案还会给出类似“综合置信度65%主要不确定性来源于第一步的实体识别模糊”这样的诊断信息。这不仅仅是学术上的“绣花枕头”。在实际项目中引入不确定性度量能带来几个实实在在的好处答案质量的可解释性你可以知道答案不可靠时问题出在哪个环节是检索源质量差还是逻辑推理链条薄弱。动态资源分配对于高不确定性的查询系统可以自动触发更昂贵的后备方案比如调用更强大的大模型进行验证或者提示人工审核。用户信任建立系统可以坦诚地告诉用户“这个问题比较复杂我的答案置信度中等建议您参考以下原始文档”这比盲目给出一个错误答案要好得多。因此将贝叶斯思想注入Agentic RAG不是要让系统变得更复杂而是让它变得更“诚实”和“可诊断”。接下来我将结合一个多跳问答的概念验证Proof-of-Concept研究拆解如何一步步实现这种不确定性感知的智能体流水线。2. 构建不确定性感知的Agentic RAG流水线核心组件一个支持不确定性传播的Agentic RAG系统其架构与传统RAG有显著区别。它不再是线性的“检索-生成”而是一个由多个概率化智能体Agent组成的协作网络。每个Agent负责一项子任务并且其输入输出都包含“值”和“不确定性”两部分。以下是这个PoC系统的核心组件设计。2.1 概率化检索器Probabilistic Retriever传统检索器如基于向量数据库的相似度搜索通常返回一个Top-K文档列表及其相似度分数。但这个分数往往不是校准过的概率无法直接用于不确定性量化。我们的实现思路是将其“概率化”输出重构我们让检索器不再只输出一个排序列表而是输出一个关于“相关文档”的概率分布。一种简单有效的方法是使用软最大函数Softmax对Top-K个文档的相似度分数进行归一化将其转化为一个离散概率分布。例如如果使用余弦相似度得分是[0.9, 0.7, 0.5]经过Softmax温度参数调整后可以得到概率[0.52, 0.31, 0.17]。这组概率就是检索器对“哪篇文档最相关”的不确定性度量。不确定性来源检索阶段的不确定性主要来自查询模糊性用户问题本身可能有歧义。语义匹配局限嵌入模型无法完美捕捉复杂语义关系。知识库覆盖不全答案可能根本不在现有文档中。置信度计算我们可以定义一个检索置信度例如使用概率分布的熵Entropy。熵值越高表示检索器越“不确定”哪篇文档是正确答案。或者使用Top-1概率值该值越低不确定性越高。注意直接使用相似度分数的Softmax作为概率是一种近似。更严谨的方法是在训练嵌入模型时就用对比学习等方式让相似度分数具有概率意义或者在检索后接一个小的“相关性校准”分类器来输出概率。在PoC阶段Softmax方法简单有效足以验证思想。2.2 不确定性感知的查询理解与规划器Uncertainty-Aware Query Planner在多跳问答中规划器Planner负责将复杂问题分解成一系列有序的子问题。在不确定性框架下规划器也需要评估这个分解计划本身的不确定性。如何运作输入原始用户问题 可选的初始检索结果带来的不确定性信号。例如如果检索器返回的文档熵值很高规划器可以接收到“当前问题语境模糊”的提示。过程规划器通常是一个LLM被提示Prompt去生成一个分解计划并且要求它同时评估每个分解步骤的“信心分数”例如0到1之间。例如对于问题“苹果公司最新款手机的摄像头传感器尺寸是多少”规划器可能生成子问题1“苹果公司最新款手机是什么型号”信心0.9因为这是一个事实性问题易于检索。子问题2“该型号手机的摄像头传感器尺寸是多少”信心0.6因为传感器规格可能不是公开宣传的重点需要更专业的文档。输出一个带有信心分数标注的子问题序列。这个序列本身的不确定性可以用子问题信心分数的几何平均数或最小值来粗略表示。如果某一步信心极低规划器甚至可以考虑生成备用分解路径。2.3 贝叶斯信息聚合器Bayesian Information Aggregator这是不确定性传播的核心。当系统通过多个步骤检索到多份证据文档片段、中间答案时这些证据可能支持不同的最终答案且各自带有不确定性。聚合器的任务就是像贝叶斯推理一样将这些不确定的证据融合起来更新对最终答案的信念。一个简化的数学模型假设我们要回答一个事实性问题答案是几个互斥选项中的一个例如某个CEO的姓名。每个检索到的证据片段e_i都可以被看作一个“传感器”它提供了一个关于答案A的似然函数P(e_i | A)。先验在没有任何证据时我们对所有答案选项赋予一个均匀的先验概率P(A)。似然估计这里需要一个“证据评估器”。它可以是一个简单的规则如果文档中明确提及答案A则P(e_i | A)高也可以是一个小型的神经网络用于判断文档e_i支持答案A的程度。这个评估器也需要输出一个校准过的概率值。贝叶斯更新根据贝叶斯公式在得到第一个证据e_1后我们对答案的后验信念更新为P(A | e_1) ∝ P(e_1 | A) * P(A)得到第二个证据e_2后继续更新P(A | e_1, e_2) ∝ P(e_2 | A) * P(A | e_1)如此迭代直到所有证据融合完毕。最终输出后验概率分布P(A | 所有证据)就是系统对最终答案的不确定性度量。我们可以选择后验概率最高的答案并以该概率值作为综合置信度。实操心得在实际代码中我们不需要严格实现完整的贝叶斯网络那会非常复杂。一个有效的工程折衷是将每个组件输出的“信心分数”视为一种近似概率然后通过乘法或加权平均的方式进行链式传播。例如最终答案的置信度 检索置信度 * 规划器步骤置信度 * 证据支持度。虽然这在贝叶斯理论中不严格但能有效捕获不确定性在流水线中衰减或放大的趋势对于PoC和许多应用场景已经足够。2.4 生成器与不确定性表述Generator with Uncertainty Verbalization最终我们需要一个生成器通常是LLM来根据聚合的信息和最终的概率分布生成自然语言的答案并且要将不确定性“表述”出来。提示工程是关键我们不再简单地问LLM“请根据以下文档回答问题”。而是设计这样的提示词你是一个严谨的助手。请基于以下证据来回答问题。系统对这些证据的可靠性评估如下 - 证据1 [内容]: 可靠性评分 0.8 - 证据2 [内容]: 可靠性评分 0.5 ... 问题[用户问题] 系统对可能答案的置信度分布为{答案A: 70% 答案B: 25% 答案C: 5%}。 请生成最终答案并在答案中自然地体现这种置信度水平。如果置信度不高请指出推断中的薄弱环节。通过这样的提示LLM能够生成如“根据现有资料很可能是答案A置信度中等因为证据1提供了较强支持但证据2的相关性较弱且可靠性存疑。需要注意的是关于XX细节的信息可能存在缺失。”这样的回答。这实现了不确定性的可解释性传递。3. PoC实现多跳问答场景下的不确定性传播实验为了验证上述想法我设计了一个针对多跳问答的概念验证实验。实验目标是展示不确定性如何在问答链条中传播并最终影响答案的可信度同时提供故障定位的线索。3.1 实验设置与数据任务开放域多跳问答。例如“特斯拉Cybertruck的电池供应商的CEO他毕业于哪所大学”知识库构建一个小型混合文档集包含维基百科片段、新闻文章、公司财报摘要等其中故意植入一些过时、矛盾或模糊的信息。基线系统一个标准的Agentic RAG系统包含工具调用能力的LLM作为智能体可以执行检索、分解问题、综合答案。它输出答案但不提供不确定性度量。实验系统增强后的不确定性感知RAG系统组件如第2章所述。评估指标答案准确性Answer Accuracy最终答案是否正确。置信度校准度Confidence Calibration系统给出的高置信度答案中正确的比例是否也高即置信度是否真实反映了正确的概率。我们可以绘制可靠性图表Reliability Diagram来观察。不确定性溯源有效性Uncertainty Attribution当答案错误时系统指出的主要不确定性来源如“检索步骤1置信度低”是否与实际错误环节吻合。3.2 关键实验步骤与观察步骤一问题分解与规划不确定性实验系统首先对输入问题进行规划。对于上述例子规划器可能生成步骤1检索“特斯拉Cybertruck的电池供应商是谁”信心0.95。这是一个相对明确的事实。步骤2检索“[电池供应商]的CEO是谁”信心0.85。依赖于步骤1的结果但CEO信息通常公开。步骤3检索“[该CEO]毕业于哪所大学”信心0.60。个人教育背景信息可能分散、不权威或缺失。规划器自身的不确定性步骤3信心低为后续流程提供了一个预警信号。步骤二链式检索与不确定性累积系统开始执行计划执行步骤1检索。假设检索到一份2024年的文档明确指出供应商是“宁德时代”另一份2022年的文档提到是“LG新能源”。经过概率化检索器处理得到概率分布宁德时代: 0.7, LG新能源: 0.3。此时检索熵值较高表明第一步就存在歧义。步骤2的检索器会收到“宁德时代置信度0.7”和“LG新能源置信度0.3”两个实体。它可以并行检索这两个实体对应的CEO信息并分别计算置信度然后根据步骤1的概率进行加权。这本身就体现了不确定性的传播。步骤3同理但基础不确定性已经经过前两步的放大。步骤三信息聚合与答案生成假设经过链条系统聚合出两个可能答案答案A清华大学综合置信度 0.4答案B斯坦福大学综合置信度 0.35其他/未知0.25生成器收到这个分布后会生成类似“根据现有信息推断这位CEO可能毕业于清华大学或斯坦福大学但系统对此判断的把握不高综合置信度约40%。主要的不确定性来源于第一步对Cybertruck电池供应商的识别存在分歧以及个人教育背景信息的稀缺。”3.3 实验结果分析通过对比基线系统和实验系统在多个测试问题上的表现我观察到准确性接近但可解释性天差地别基线系统在简单问题上也能答对但一旦出错就是“硬错误”且难以调试。实验系统在复杂问题上可能也答错或给出低置信度答案但它提供了“为什么不确定”的清晰路径。置信度初步校准在实验系统中高置信度0.8的答案其准确率确实显著高于低置信度0.5的答案。这说明通过流水线传播的不确定性度量在一定程度上是有效的、校准过的。成功溯源案例在一个答案错误的问题中系统给出的综合置信度仅为0.3并指出“主要不确定性来源于子问题2的证据支持薄弱”。人工检查发现确实是在第二步检索到的CEO信息来自一篇非权威博客与第一步的权威信息矛盾。系统成功定位了证据链的薄弱环节。踩坑记录在实现概率化检索器时最初直接使用未经校准的余弦相似度进行Softmax结果发现置信度与真实准确性关联很弱。后来引入了温度参数Temperature对Softmax进行调节并采用了一小组验证问题对温度参数进行微调使得高相似度对应的概率更“尖锐”低相似度更“平滑”这才让检索置信度变得更有意义。这提醒我们任何概率输出都需要经过校准Calibration才有价值。4. 工程落地挑战、策略与未来方向将贝叶斯不确定性传播从PoC推向实际生产环境会面临一系列工程挑战。以下是我在实践和思考后总结的几个关键点及应对策略。4.1 核心挑战概率的校准与计算开销挑战一所有组件的输出都需要是校准过的概率。这并非易事。LLM本身输出的“置信度”通常是未校准的。检索器的相似度分数也不是概率。解决策略有事后校准Post-hoc Calibration收集一个开发集对于每个组件如检索器将其原始输出分数相似度、LLM生成logits与真实标签是否相关、答案是否正确进行对比。使用Platt Scaling或Isotonic Regression等方法学习一个校准函数将原始分数映射到校准后的概率。这是相对实用的工程方法。设计概率感知的训练目标在训练嵌入模型或微调LLM时就将输出概率的校准作为目标之一。例如使用负对数似然损失并要求模型输出概率分布。挑战二计算复杂度。完整的贝叶斯推理特别是当答案空间很大或证据很多时计算量是指数级的。近似推断采用蒙特卡洛方法如MCMC或变分推断来近似后验分布。在RAG场景中由于答案空间通常被约束在检索到的文本范围内可以大大简化。模块化与并行将流水线设计成模块化允许不确定性高的模块触发更复杂但更准确的备用子流程如用更强大的LLM重写查询而不是对所有查询都使用最复杂的处理。这实现了计算资源的动态优化分配。4.2 系统设计策略轻量级与可插拔对于大多数团队一开始就构建一个完整的贝叶斯RAG系统是不现实的。我建议采用“可插拔式不确定性增强”策略从关键组件开始优先对系统中你认为最不可靠的环节添加不确定性度量。例如如果你的检索器是瓶颈就先实现概率化检索和置信度计算。定义简单的传播协议制定一个内部协议规定每个模块输入输出的数据格式必须包含(value, confidence)对。置信度是一个0到1之间的浮点数。传播规则可以先简单定为乘法或取最小值。构建监控与评估闭环在日志中记录每个查询的最终答案、综合置信度以及各环节的置信度。定期分析高置信度错误答案有哪些共同模式低置信度正确答案是否源于某个特定环节的误判用这些数据持续迭代校准你的组件。4.3 未来演进方向这个领域还在快速发展我认为有几个方向值得关注不确定性感知的智能体协作未来的Agentic系统可能由多个专家智能体组成。不确定性度量可以指导路由Routing——将高不确定性子任务分配给更专业、更可靠的智能体。基于不确定性的主动学习系统可以自动识别那些高不确定性、高价值的查询将其加入人工标注队列用于持续优化检索器、LLM等组件实现数据收集的智能化。用户交互层面的创新如何将系统的不确定性以直观、非干扰的方式呈现给用户例如在答案后面用颜色绿/黄/红表示置信度或者提供“深入了解推理过程”的按钮展示证据链和每个环节的置信度。我个人在实际操作中的体会是引入不确定性度量最大的价值不在于让系统“永不犯错”而是让系统变得“透明”和“可运维”。它把原来藏在黑盒里的故障模式暴露了出来让我们开发者有了进行针对性优化的抓手。从一个总是自信满满的“实习生”变成一个懂得评估风险、会主动求证的“资深顾问”这或许是RAG系统走向成熟和可靠的关键一步。在PoC中哪怕只是用简单的概率乘法和精心设计的提示词也能显著提升系统的可解释性。不妨从给你的RAG系统添加第一个“置信度”字段开始尝试。