RAG本质是贝叶斯推理：从概率公式到可部署代码

1. 项目概述：当RAG脱下“黑箱”外衣，露出的是一张贝叶斯老面孔

你有没有在深夜调试RAG系统时，盯着检索结果和大模型输出之间那道若隐若现的“信任鸿沟”发过呆？明明文档库里有精准答案，LLM却绕着弯子编造；明明用户只问“2023年Q3营收同比变化”，系统却把整份财报PDF的前五页都塞进上下文——最后还加一句“根据以上材料，我推测……”。这种“看似聪明、实则费力”的割裂感，正是当前RAG落地中最普遍的隐痛。而这篇标题里那个带靶心emoji的断言——RAG is Just Bayesian Inference——不是修辞，不是类比，更不是营销话术，它是一把解剖刀，直接切开了RAG系统最底层的逻辑肌理。我用三年时间在金融、医疗、法律三个强合规领域部署过27个RAG应用，从早期用LangChain硬套模板，到后来自己重写检索-重排-生成三阶段协同逻辑，最终在一次给某头部律所做合同审查系统时，被一位退休的统计学教授一句话点醒：“你们这不就是先验知识（知识库）+似然函数（检索相关性）+后验更新（LLM生成）吗？”那一刻我才真正看懂：所谓RAG的“魔法”，不过是贝叶斯定理在向量空间里的一次朴素实践。它解决的从来不是“怎么让AI记住更多”，而是“如何在不确定中，用已有证据动态校准判断”。这篇文章不讲API调用、不列参数表格，只做一件事：把RAG每一行代码背后隐藏的贝叶斯公式，翻译成工程师能摸到、产品经理能听懂、法务能签字确认的语言。如果你正被检索不准、幻觉难控、响应迟滞这些问题反复折磨，或者只是好奇“为什么RAG必须配重排器、为什么提示词要强调‘仅基于以下内容回答’”，那么接下来的内容，就是你一直在找的底层操作手册。

2. RAG系统设计的贝叶斯本质：从“拼凑模块”到“概率推理流水线”

2.1 传统RAG设计的三大认知陷阱与贝叶斯视角的矫正

绝大多数RAG项目失败，并非源于技术选型错误，而是始于对系统本质的误判。我见过太多团队把RAG当成一个“检索+大模型”的简单串联，就像把咖啡机和奶泡器并排放在一起就宣称做出了拿铁。这种设计隐含三个危险假设，而贝叶斯框架能一针见血地戳破它们：

陷阱一：“检索即真理”假设
典型表现：把向量数据库返回的Top-K文档无条件喂给LLM，认为“最相似=最相关”。但现实是，向量相似度衡量的是语义距离，而非事实真伪或逻辑支撑强度。一份2018年的过期政策文件，可能因用词与当前问题高度一致，被排在首位。贝叶斯视角下，这相当于把似然函数P(D|H)（文档D在假设H成立下的出现概率）直接当成了后验概率P(H|D)（假设H为真时，看到文档D的反向置信度）。而真正的推理必须包含先验P(H)——比如该政策是否已被新法规废止。我们后来在医疗问答系统中强制加入“时效性衰减因子”，对超过18个月的文献，其检索得分乘以0.6，这就是对先验P(H)的显式建模。

陷阱二：“LLM即全知”假设
典型表现：提示词写“请基于以下信息回答”，却不对LLM的生成过程施加任何概率约束。结果模型在证据薄弱时，依然自信输出长篇大论。贝叶斯告诉我们，LLM的生成本质上是在计算P(Q|D, θ)，其中θ代表模型参数（即其内在知识先验）。当D（检索文档）信息量不足时，P(Q|D, θ)会严重依赖θ，也就是回归到模型自身的“幻觉先验”。我们的解决方案是在重排阶段引入证据置信度评分：对每个检索片段，用轻量级分类器评估其“是否包含问题答案的直接证据”，只有得分>0.85的片段才进入LLM上下文。这相当于在似然函数上叠加了一个门控，强制P(D|H)必须达到阈值，才能触发后验更新。

陷阱三：“静态流程”假设
典型表现：RAG pipeline固定为“检索→重排→生成”三步，无法根据问题复杂度动态调整。一个简单事实查询（如“CEO姓名”）需要的证据强度，远低于一个开放性分析（如“对比A/B两款产品的合规风险”）。贝叶斯推理天然支持序贯更新：第一次检索得到粗粒度答案后，可将LLM的初步回应作为新的“观测数据”，触发第二轮聚焦检索（例如，针对初答中提到的“GDPR第32条”，再检索该条款的司法解释）。我们在某跨境支付风控系统中实现了这一机制：当问题涉及多法域时，第一轮检索全球通用原则，第二轮自动提取初答中的国家关键词（如“新加坡”、“欧盟”），发起定向检索，整个过程在200ms内完成。这不是炫技，而是让P(H|D₁,D₂)真正替代了僵化的P(H|D₁)。

提示：识别你的RAG是否陷入这些陷阱，最简单的测试是——删掉LLM，只保留检索模块，人工查看Top-3结果。如果其中任意一个结果能让人直接得出答案，说明你的RAG在“过度设计”；如果人工也无法判断哪个结果更可靠，说明你的系统缺失了关键的不确定性量化环节，而这正是贝叶斯框架的核心价值。

2.2 RAG全流程的贝叶斯公式映射：从抽象符号到工程变量

现在，让我们把贝叶斯定理P(H|D) = P(D|H) × P(H) / P(D)这张“纸面公式”，逐项翻译成RAG系统中可触摸、可配置、可监控的工程实体。这不是理论推演，而是我在生产环境里亲手拧紧的每一个螺丝：

P(H) —— 先验概率：知识库的“可信度基线”
在传统理解中，P(H)常被忽略或设为均匀分布。但在真实场景中，它必须是可配置的元数据。例如，在金融投研RAG中，我们为每份文档定义了三个先验维度：

• 来源权威性（Source Authority）：监管文件=0.95，券商研报=0.75，自媒体文章=0.3；
• 时效性衰减（Temporal Decay）：使用指数衰减模型，T=当前时间-发布日期，P(H) ∝ e^(-λT)，λ根据业务敏感度设定（高频交易λ=0.02/天，长期战略λ=0.001/天）；
• 领域匹配度（Domain Fit）：通过轻量级BERT微调模型，计算文档主题与知识库整体主题分布的KL散度，散度越小，P(H)越高。
  这三个维度相乘，构成最终的P(H)。它不参与向量检索，但在重排阶段作为权重因子，直接修正检索得分。一个2024年发布的央行货币政策报告，其P(H)可能是0.95×0.98×0.92≈0.86；而一篇2020年关于区块链的博客，即使向量相似度高，P(H)也仅为0.3×0.65×0.4≈0.078。这个数字，就是系统对“这份材料有多大概率承载正确答案”的初始判断。

P(D|H) —— 似然函数：检索引擎的“证据强度计”
这是向量数据库的核心输出，但绝不能止步于余弦相似度。我们将其拆解为三个可解释的子分量：

• 语义匹配度（Semantic Match）：标准向量相似度，范围[0,1]；
• 关键词强化项（Keyword Boost）：对用户查询中的专有名词（如人名、产品代号、法规编号），在文档中进行精确匹配，每命中一次+0.05，上限+0.2；
• 段落位置权重（Position Weight）：同一文档内，不同段落的P(D|H)不同。引言和结论段落权重=1.2，方法论段落=1.0，附录=0.7。这源于经验：法律合同的关键条款90%位于“双方义务”和“违约责任”章节。
  最终P(D|H) = 语义匹配度 × (1 + 关键词强化项) × 段落位置权重。这个公式被硬编码进我们的自研检索器，所有得分都可追溯到具体计算项。当业务方质疑“为什么这份报告没排第一”，我们能立刻展示：它的语义分0.82，但关键词强化项为0（未提及查询中的“碳关税”），位置权重0.7，综合得分为0.48；而排第一的备忘录语义分0.75，但关键词命中两次（+0.1），位置权重1.2，得分为0.75×1.1×1.2=0.99。争议瞬间消解。

P(H|D) —— 后验概率：LLM生成的“可信度锚点”
这才是RAG的终极目标——不是生成一段文字，而是生成一个带置信度的答案。我们弃用了所有“自由发挥”式提示词，统一采用后验约束模板：

你是一个严谨的[领域]专家。你将收到若干份经审核的参考资料（标记为[DOC1]、[DOC2]...）。请严格遵循： 1. 若参考资料中存在明确、无歧义的答案，直接复述，不得添加、删减或解释； 2. 若参考资料相互矛盾，列出各方观点及对应出处，不强行调和； 3. 若参考资料均未提供答案，明确回答“根据现有资料，无法确定”，并说明缺失的信息类型。 请以JSON格式输出：{"answer": "...", "confidence": 0.0-1.0, "sources": ["DOC1", "DOC3"]}

这个模板强制LLM将生成过程显式建模为P(H|D)的采样：confidence字段是模型对自身输出为真的估计，sources字段是其决策所依据的似然证据。在日志系统中，我们实时监控confidence分布。当某类问题（如“XX产品上市时间”）的平均置信度低于0.6，系统自动告警——这表明P(D|H)整体偏低，需优化检索策略，而非怪罪LLM“不聪明”。

P(D) —— 边缘概率：系统的“自我怀疑开关”
P(D) = Σ P(D|Hᵢ) × P(Hᵢ)，即所有可能假设下观测到D的总概率。在RAG中，它体现为系统对“当前检索结果集是否足以支撑可靠推理”的全局评估。我们设置了一个动态阈值：当Top-3文档的P(D|H)×P(H)之和 < 0.5时，触发证据不足协议——LLM不生成答案，而是返回：“现有资料覆盖度不足（当前置信度0.42），建议补充以下信息：[具体缺失的关键词或文档类型]”。这个0.5阈值并非拍脑袋，而是通过A/B测试确定：当阈值设为0.4时，用户追问率上升37%；设为0.6时，有效答案率下降22%。0.5是业务准确率与用户体验的帕累托最优解。

3. 核心环节实现：把贝叶斯公式变成可部署、可监控、可解释的代码

3.1 先验概率P(H)的工程化落地：从元数据到实时衰减

先验P(H)的构建，是RAG摆脱“检索即真理”陷阱的第一道防线。很多人以为这只需在文档入库时打标签，但真实挑战在于动态性——权威性会变（某券商被证监会处罚）、时效性在流逝、领域匹配度随知识库扩充而漂移。我们的方案是“静态元数据+动态服务”的双层架构，已在日均10万次查询的保险理赔系统中稳定运行14个月。

第一步：元数据注入——让每份文档自带“出生证明”
我们改造了文档解析流水线，在PDF/Word转文本阶段，同步提取四类元数据：

• source_type: 枚举值（regulation,internal_policy,external_research,case_law），对应预设权威性基线；
• publish_date: 精确到日的时间戳，用于时效性计算；
• jurisdiction: 法域代码（CN,US,EU），用于后续领域匹配；
• key_entities: 通过spaCy NER识别出的人名、机构名、法规编号，存为列表。

这些元数据不存于向量库，而是写入独立的PostgreSQL元数据表，与向量ID通过doc_id关联。这样做的好处是：元数据可独立更新，无需重新嵌入向量。当某份监管文件被修订，我们只需更新其publish_date和source_type，向量保持不变。

第二步：动态衰减服务——让先验随时间呼吸
时效性衰减不能是离线批处理，必须实时。我们开发了一个轻量级gRPC服务prior-service，其核心逻辑是：

def calculate_prior(doc_meta: Dict) -> float: # 权威性基线（查表） base_authority = AUTHORITY_MAP[doc_meta['source_type']] # 时效性衰减：e^(-λ * days_since_publish) days = (datetime.now() - doc_meta['publish_date']).days temporal_decay = math.exp(-LAMBDA * days) # 领域匹配度：实时计算，避免离线漂移 domain_fit = calculate_domain_fit( doc_entities=doc_meta['key_entities'], query_entities=QUERY_ENTITIES # 从当前请求中获取 ) return base_authority * temporal_decay * domain_fit

关键创新在于calculate_domain_fit：它不依赖离线训练好的模型，而是对本次查询中的关键实体（如“GDPR Article 32”），实时计算其与文档key_entities的Jaccard相似度。如果查询含3个实体，文档含2个匹配，则相似度=2/3≈0.67。这确保了P(H)始终与当前问题强相关，而非泛泛而谈的“文档质量”。

第三步：实时注入重排器——让先验成为检索的“刹车片”
在重排阶段，我们不修改向量库返回的原始分数，而是将其作为base_score，再乘以calculate_prior()返回的prior_score：

# 重排器核心逻辑 for doc in retrieved_docs: prior_score = prior_service.get_prior(doc.meta) doc.rerank_score = doc.base_score * prior_score * BIAS_FACTOR

BIAS_FACTOR是可调参数，默认为1.0，当业务要求“宁缺毋滥”时，可设为1.5，强力压制低先验文档。所有prior_score和rerank_score均记录到ELK日志，供数据科学家分析P(H)分布。上线后，我们发现某类“历史案例”文档的平均prior_score仅0.23，远低于其他类型，遂推动法务团队启动专项修订，将过期案例批量归档——这证明先验建模不仅能提升效果，更能驱动知识库健康度治理。

注意：P(H)的数值范围必须严格控制在[0,1]。我们曾因temporal_decay计算错误（未处理days=0导致exp(0)=1，但base_authority已含时效性），造成某些新文档prior_score>1，进而扭曲重排结果。教训是：所有概率计算必须有归一化校验，我们在服务入口增加断言assert 0 <= score <= 1.001，超限则返回默认值0.5并告警。

3.2 似然函数P(D|H)的精细化建模：超越余弦相似度的三维打分

向量相似度是P(D|H)的起点，而非终点。把“文档D在假设H（正确答案）成立下出现的可能性”简化为一个浮点数，是对复杂语义关系的粗暴降维。我们的三维打分模型，将似然分解为可解释、可干预、可归因的三个正交维度，已在法律合同审查场景将关键条款召回率从78%提升至94%。

维度一：语义匹配度（Semantic Match）——向量空间的“直觉”
我们坚持使用Sentence-BERT微调版，而非通用Embedding模型。微调数据来自10万份真实法律文书问答对，损失函数特别加强了“否定关系”（如“不适用”、“除外”、“除非”）的区分能力。这使得模型能理解：“本协议不适用于乙方子公司”与“本协议适用于乙方”在向量空间中距离极远，而非相近。微调后的模型在内部测试集上，对否定语义的F1-score达0.91，远超开源模型的0.63。语义匹配度直接取余弦相似度，范围[0,1]，不做额外缩放。

维度二：关键词强化项（Keyword Boost）——对抗“语义漂移”的锚点
语义匹配可能被“同义词泛化”误导。例如查询“PCI DSS 4.1”，语义模型可能因“支付卡行业数据安全标准”与“网络安全规范”相似，而召回无关文档。关键词强化项是硬规则补丁：

• 从查询中提取强标识符：正则匹配\bPCI\s+DSS\s+\d+\.\d+\b（如PCI DSS 4.1）、\bGDPR\s+Art\.\s+\d+\b（如GDPR Art. 32）、公司股票代码（AAPL）、产品型号（iPhone 15 Pro）；
• 在文档文本中进行精确字符串匹配（大小写不敏感，但空格和标点必须一致）；
• 每匹配一次，boost_score += 0.05，上限+0.2。
  这个设计的精妙在于：它不改变语义向量，而是在重排阶段“加权投票”。一个语义分0.78但命中PCI DSS 4.1两次的文档，boost_score=0.10，综合分=0.78×1.10=0.858；而一个语义分0.85但无关键词匹配的文档，综合分=0.85。关键词成了“可信度担保人”，确保核心证据不被语义噪声淹没。

维度三：段落位置权重（Position Weight）——利用人类写作的“潜规则”
法律、金融、医疗文档有强烈的结构化特征。我们通过分析5000份样本，归纳出各类型文档的“高价值段落”分布规律，并固化为规则引擎：

权重计算在文档解析时完成，存入元数据。重排时，直接读取当前段落的position_weight。这避免了LLM在长文档中“平均用力”，让系统天然聚焦于人类作者刻意放置关键信息的位置。

三维融合与可解释性输出
最终P(D|H) =semantic_score× (1 +boost_score) ×position_weight。所有中间值均记录到日志，当业务方问“为什么这份合同没排第一”，我们能生成这样的解释报告：

[DOC123] 合同名称：XX采购协议 - 语义匹配度：0.82 （与查询"付款条件"语义相近） - 关键词强化：+0.05 （命中"付款条件"一次） - 段落位置：1.2 （位于"双方权利义务"章节） - 综合似然：0.82 × 1.05 × 1.2 = 1.033 → 截断为1.0

这种透明度，是赢得法务、合规等强审慎部门信任的关键。他们不需要懂向量，但能看懂“命中关键词”和“位于权利义务章”。

3.3 后验概率P(H|D)的生成约束：让LLM从“创作家”变成“证据书记员”

LLM的幻觉，本质是其内在先验P(H|θ)压倒了外部证据P(D|H)。要让RAG真正成为“贝叶斯推理器”，必须对生成阶段施加刚性约束，使其输出严格服从P(H|D)的采样逻辑。我们摒弃了所有开放式提示词，构建了一套基于后验约束模板（Posterior-Constrained Prompting）的生成协议，已在银行信贷审批系统中将幻觉率从12.7%降至0.9%。

核心模板设计：三阶纪律性指令
模板不是自由文本，而是结构化JSON Schema，强制LLM输出带元数据的响应：

{ "answer": "字符串，必须是参考资料中的原文复述或逻辑推导，禁止添加、删减、解释", "confidence": "浮点数，0.0-1.0，表示模型对answer为真的自我评估", "sources": ["字符串数组，引用的文档ID，如['DOC7', 'DOC12']"], "reasoning": "字符串，仅当answer为推导结果时填写，说明推导链（如'根据DOC7第3条和DOC12第5款，可得...'）" }

这个Schema通过OpenAI的response_format参数或本地vLLM的guided_decoding强制执行，杜绝了格式错误。

三阶纪律的具体实现：

1. 零创作纪律：answer字段禁用一切LLM的“润色”行为。我们用正则校验：若answer包含“可能”、“或许”、“一般而言”、“据我所知”等模糊词，或长度超过最长参考文档的120%，则拒绝响应并重试。这迫使模型只做“证据搬运工”，而非“观点评论员”。

2. 置信度校准纪律：confidence不是随意填写。我们在提示词中嵌入校准指令：“请评估：若参考资料完全真实且完整，您的answer为真的概率。若参考资料存在矛盾，confidence ≤ 0.5；若仅有一份资料支持，confidence ≤ 0.7；若两份及以上独立资料一致支持，confidence ≥ 0.85。” 这将LLM的主观信心，锚定到客观证据数量上。

3. 溯源强制纪律：sources字段必须精确到文档ID，且只能填入检索返回的文档。我们开发了source-validator中间件，在LLM输出后，自动检查sources中的每个ID是否存在于本次检索结果中。若出现DOC999（不存在的ID），则拦截响应并告警——这暴露了模型在“编造证据”，是幻觉的早期信号。

后验监控与闭环优化：
所有confidence值进入实时监控看板。我们定义了三个关键指标：

• 证据充分率：confidence ≥ 0.8的请求占比。目标>85%；
• 证据冲突率：confidence ≤ 0.5且reasoning非空的请求占比。目标<5%；
• 溯源准确率：sources中ID与实际支撑文档的匹配度。目标100%。

当证据充分率连续3天<80%，系统自动触发根因分析：是P(H)普遍偏低（知识库陈旧）？还是P(D|H)不准（检索关键词漏配）？分析结果推送至知识库运营团队。这种数据驱动的闭环，让RAG从“调参艺术”变成了“可管理的工程”。

实操心得：不要迷信LLM的confidence输出。我们在初期发现，模型对“简单事实”（如日期、数字）的confidence普遍虚高。解决方案是引入外部校验器：对answer中提取的日期、金额、百分比等结构化数据，用正则+规则引擎二次验证。若验证失败，强制将confidence设为0.0并标记validation_failed:true。这增加了0.3%的延迟，但将关键数据错误率降至0。

4. 常见问题与排查技巧实录：从“为什么不准”到“如何精准归因”

4.1 问题诊断树：五分钟定位RAG失效的贝叶斯根源

当用户反馈“RAG回答错了”，新手工程师往往一头扎进LLM日志，而资深从业者会先问：“错在哪个概率环节？”我们总结了一套基于贝叶斯公式的五步诊断树，已在团队内部培训中将平均故障定位时间从47分钟缩短至6分钟。

步骤一：隔离LLM，检验P(D|H)——“检索本身准不准？”
操作：关闭LLM生成，将用户问题输入检索模块，人工查看Top-3文档。

• ✅ 若其中一份文档原文包含答案（如查询“2023年净利润”，文档中有“净利润：¥1.23B”），则P(D|H)正常，问题在P(H|D)（LLM生成）；
• ❌ 若Top-3均未包含答案，或答案被埋在长段落中（如“净利润”一词出现在第17段末尾），则P(D|H)失效，需检查检索策略。
  典型案例：某客户投诉“查不到最新融资额”，我们发现其知识库中最新融资新闻的标题是“XX公司完成C轮融资”，但向量模型将“C轮”嵌入为“see round”，与查询“C轮融资”语义失配。解决方案：在文档预处理中，强制将“C轮”、“B+轮”等标准化为“Series C”、“Series B Plus”，并加入同义词表。

步骤二：固定P(D|H)，检验P(H)——“知识库可信度够不够？”
操作：用步骤一中“正确的Top-1文档”作为唯一输入，喂给LLM，观察输出。

• ✅ 若LLM能准确复述答案，说明P(H|D)正常，问题在P(H)（先验过低，导致该文档未被检索到）；
• ❌ 若LLM仍编造或回避，说明P(H|D)失效，需检查提示词约束或LLM微调。
  典型案例：某医疗问答中，一份权威指南明确写了“禁忌症：孕妇禁用”，但RAG回答“请咨询医生”。我们发现该指南的source_type被误标为external_research（权威性0.75），而非regulation（0.95），导致其P(H)过低，未进入Top-3。修正元数据后，问题消失。

步骤三：检查P(H|D)的置信度——“LLM是否知道自己在说什么？”
操作：查看日志中该请求的confidence值。

• ✅ 若confidence ≥ 0.85且答案错误，说明LLM的内在先验（θ）与知识库冲突，需微调或更换模型；
• ❌ 若confidence ≤ 0.5，说明LLM已感知证据不足，此时应检查为何P(D|H)×P(H)之和过低——是检索召回率低？还是先验衰减过猛？
  典型案例：某金融问答中，confidence=0.3，日志显示Top-3文档的P(D|H)×P(H)之和仅0.21。深入发现，用户查询含“2024年Q1”，而知识库中最新财报是2023年Q4，publish_date导致P(H)衰减至0.4。解决方案：为财报类文档设置temporal_decay=0（永不衰减），因其时效性由发布日期定义，而非当前日期。

步骤四：验证P(D)边缘概率——“系统是否该主动说不知道？”
操作：计算本次请求Top-3文档的P(D|H)×P(H)之和。

• ✅ 若该和 > 0.5，系统应生成答案；若未生成，检查后验约束模板是否被绕过；
• ❌ 若该和 < 0.3，系统应触发“证据不足协议”，若未触发，检查P(D)计算逻辑或阈值配置。
  典型案例：某法律咨询中，系统本该返回“无法确定”，却生成了长篇分析。日志显示P(D)计算中，LAMBDA参数被误设为0.1（应为0.001），导致所有文档P(H)被过度压缩。修复参数后，系统行为恢复正常。

步骤五：交叉验证贝叶斯一致性——“三个概率是否自洽？”
操作：对同一问题，用不同方式验证：

• 用curl直接调用prior-service，获取各文档P(H)；
• 用curl调用retriever，获取各文档P(D|H)；
• 手动计算P(H|D) ≈ P(D|H)×P(H)，看是否与LLM的confidence趋势一致。
  不一致即为系统bug。我们曾发现，因时区配置错误，prior-service计算days_since_publish时少算了1天，导致所有P(H)偏高。此问题仅通过此交叉验证暴露。

4.2 高频问题速查表：症状、根因、解决方案、验证方法

4.3 我踩过的坑与独家避坑技巧

坑一：“先验P(H)必须完美，否则RAG就废了”
这是最大的误解。我曾花两个月试图构建一个“万能权威性评分模型”，收集了数百个特征，结果在A/B测试中，简单规则（source_type查表）的效果反而更好。避坑技巧：P(H)的价值不在于绝对精确，而在于方向正确。只要它能让监管文件（0.95）稳压研报（0.75），就能解决80%的“权威性混淆”问题。过度追求P(H)的精度，是典型的“用火箭送快递”——成本远超收益。我的经验是：用80%的精力做好P(D|H)的三维建模，用20%精力维护一个足够好的P(H)基线。

坑二：“LLM的confidence就是真相”
上线初期，我们把confidence直接展示给用户，结果销售团队抱怨“客户看到0.6的置信度就不信我们了”。避坑技巧：confidence是系统内部的诊断指标，绝不对外暴露。对外，我们只展示“答案来源”（如“根据《2024年信贷政策》第5.2条”）和“证据强度”（如“高：单一权威来源明确支持”）。将概率语言翻译成业务语言，才是产品思维。

坑三：“重排器越复杂越好”
我们曾引入XGBoost对P(D|H)×P(H)进行非线性融合，F1-score只提升了0.3%，但延迟增加了40ms，