大模型应用怎么保障可靠性?

回答与解析

用证据链而非自创置信度

输入层：校验schema、类型、范围、时间、来源和权限；对文档做版本与哈希记录，对用户输入做注入和敏感数据检测。

检索与生成层：保留query、召回结果、重排分数、prompt、模型版本和工具调用trace。要求关键事实能回指证据；高风险计算交给确定性程序或受控API，结构化输出用schema约束。

验证层：业务规则、单元测试、代码执行、数据库校验或独立模型可以提供信号，但验证器也要有独立测试集。Self-Consistency的答案一致度只能作为不确定性特征之一，不是经过校准的正确概率；不能自创“输入置信度乘模型置信度”公式。

评测层：建立黄金集、对抗集和回归集，按任务分桶统计准确率、校准、拒答、证据支持率和端到端成功率。

反馈闭环：点赞点踩默认只能归因到整条响应；若要定位到步骤或token，必须额外收集span标注、步骤评价或可回放trace。反馈经审核后再进入数据或规则版本。

口语版讲法(约4分钟)

• 从输入来源和schema开始
• 保留检索生成全链路trace
• 组合确定性与模型验证
• 建立分桶测试和校准
• 限定反馈归因粒度

保障准确性不能靠一个自创的置信度分数，而要建立从输入到输出的证据链。输入侧先做schema、类型、范围、时间和权限校验。外部文档要记录来源、版本、抓取时间和哈希，用户输入要检测提示注入、敏感信息和越权请求。若数据本身过期或来源不明，模型输出再流畅也不可靠。

进入检索和生成阶段后，要保留query改写、召回候选、重排分数、最终上下文、prompt版本、模型版本、解码参数和工具调用trace。对关键事实要求能回指证据片段，并检查证据是否真的支持结论，而不是只看有没有引用。金额计算、库存、权限和规则判断应尽量交给确定性程序或受控API，输出则用JSON schema或语法约束减少格式错误。

验证可以组合业务规则、单元测试、代码执行、数据库查询和独立模型，但验证器自身也会犯错。要用独立黄金集测它的准确率、漏检和误杀，并避免生成器和验证器共享完全相同的失败模式。Self-Consistency可以通过多条随机推理路径观察答案是否一致，但一致并不等于正确，更不是天然校准的概率。不能把输入质量分数、模型分数随意相乘后称为真实置信度。

测试层需要黄金样本、边界样本、对抗样本和历史故障回归集。按任务、语言、长度、数据新鲜度和风险等级分桶，分别统计准确率、证据支持率、拒答质量、格式合法率、端到端任务成功率和延迟。若系统输出概率，还要检查可靠性图、Brier分数或期望校准误差，而不是只看平均准确率。

线上采用shadow、灰度和阈值告警，任何模型、prompt、检索器或知识库变更都要带版本并可回滚。失败样本进入待审队列，由人工确认是输入、检索、工具、生成还是验证问题，再决定修规则、补数据或改模型。

反馈归因也要保守。一次点赞或点踩通常只说明用户对整条响应的评价，无法自动知道是哪一个token导致。如果需要细粒度学习，必须额外收集span标注、步骤级评价、引用点击或可回放操作结果。只有证据和归因粒度匹配，反馈闭环才不会把噪声写回系统。

还要预设停止与降级条件。证据不足、验证器冲突或外部工具超时时，系统应返回不确定、请求补充信息或转人工，而不是强制生成完整答案。可靠性不仅是把正确率做高，也包括在不知道时采取可控行为。

关键一句:怎样证明一个验证器没有和生成模型共享同样的错误模式。

核验来源

1. NIST AI Risk Management Framework
2. On Calibration of Modern Neural Networks
3. Holistic Evaluation of Language Models

面试官还可能这样问

1. 问法 1 · 场景切入

   假设你在做客服机器人，用户问了一个订单问题，模型生成了答案，但答案里引用的订单号根本不存在。你怎么通过技术手段提前拦住这种错误，而不让用户看到？

2. 问法 2 · 层层追问

   大模型落地时怎么保证输出靠谱？……你可能会想到校验吧？那具体怎么设计？……如果既要保证事实准确，又要控制延迟，你怎么组合不同的校验手段？

3. 问法 3 · 直球架构

   设计一个保障大模型输入输出准确可靠的工程方案，包括输入过滤、输出校验和反馈闭环，你会怎么搭？关键组件和流程是什么？