大模型能力边界如何判断？哪些任务不适合直接交给 LLM？

简化版

判断 LLM 能不能承担一项任务，要看它是否允许概率性结果、能否提供充分上下文、错误能否被检测，以及失败后是否会产生不可逆副作用。LLM 适合语言理解、生成、归纳和候选方案探索；不适合单独充当事实数据库、精确计算器、强一致规则引擎、权限系统，或直接决定付款、删库、医疗处置等高风险动作。可靠架构应让模型负责“理解与建议”，把事实查询交给检索或数据库，把计算交给确定性代码，把执行交给受权限和审批约束的工具层。

详细版

可以用四个问题判断边界：输出是否有唯一正确答案，错误能否自动验证，知识是否要求实时且完整，动作是否有高风险副作用。任务越要求精确、实时、可审计和强一致，就越不能只靠 LLM 自由生成。

任务	LLM 合适的角色	不应承担的角色
客服问答	理解意图、组织有出处的回答	凭参数记忆承诺价格和政策
数据分析	生成查询计划、解释结果	心算财务结果或编造缺失数据
工作流	选择候选工具、补齐参数	绕过权限直接执行不可逆操作
代码开发	生成草案、解释和重构	未经测试直接发布生产代码

工程上先把任务拆成“模型判断—确定性验证—受控执行”。事实答案绑定可信数据源，数值由程序计算，结构化输出经过 Schema 和业务规则校验，高风险动作要求幂等键、权限检查和人工确认。模型无法满足证据或置信条件时，系统应允许拒答、澄清或转人工，而不是强迫它给出流畅答案。

完整版教学

一、先区分语言能力和系统保证

LLM 的训练目标通常是根据上下文预测后续 token。这个机制能学到丰富的语言模式和世界知识，却不会自动提供数据库事务、访问控制、实时一致性或形式证明。模型说出“余额是 100 元”和账户系统真的读到 100 元，是两种完全不同的保证。

因此不能只问“模型会不会做”，还要问“系统能不能证明它做对了”。写一封营销邮件允许多个好答案；计算税额可能只有一个正确答案；执行退款还必须证明调用者有权限。越靠近唯一真值和现实副作用，模型越应该退到辅助位置。

记忆钩子：LLM 提供的是概率性能力，不是事务性承诺；语言流畅度不能替代事实、权限和一致性证明。

二、用四个维度判断任务是否越界

第一是容错性：错一个措辞和错一个药物剂量的后果完全不同。第二是可验证性：代码能跑测试，SQL 能比对行数，而开放式建议很难自动判定。第三是信息闭合度：所需事实是否都在上下文或工具中。第四是副作用：输出只是草稿，还是会发邮件、转账或修改数据。

可以形成一个简化风险分数：

R = 2 × 不可逆性 + 2 × 权限敏感度 + 事实时效性 + 难验证程度

每项按 0～2 分。若一个自动退款任务四项分别为 2、2、1、1，则 R=10，不应让模型直接闭环执行；一篇广告标题可能是 0、0、0、1，适合让模型大量生成候选。公式不是行业标准，而是帮助团队把“感觉危险”变成可讨论的决策。

三、哪些任务天然适合 LLM

适合的任务通常具有多解、语言密集、结果可复核三个特点。例如总结文档、改写语气、分类工单、抽取候选字段、解释代码、生成测试草案。模型能把非结构化输入转成更容易处理的中间结果，从而降低人工阅读和创作成本。

即使是适合任务，也要说明质量标准。摘要需要覆盖关键事实且不添加原文没有的结论；分类需要固定标签集和混淆矩阵；字段抽取需要 Schema 校验并保留证据位置。“适合”并不等于“无须评测”。

一个好用的分工是让模型产生候选，让规则或人做选择。例如一次生成 5 个标题，编辑挑选 1 个；模型的随机性此时创造多样性，而不是制造不可控风险。

四、四类任务不应直接交给模型

精确计算不应靠自然语言推演完成，尤其是金额、统计和密码学运算；让模型生成公式或代码，再由计算引擎执行。权威事实查询应访问数据库、搜索或知识库，模型负责理解问题与解释结果。强规则决策如资格判定应由版本化规则引擎给结论，模型只能解释规则。高风险执行必须经过权限、限额、幂等和审批。

不合适的直连方式	更可靠的替代架构
让模型背库存数字	模型生成查询参数，库存服务返回真值
让模型心算复利	调用经过测试的计算函数
让模型决定是否放贷	规则/风控模型决策，LLM 解释材料
让模型直接删除账号	生成操作计划，人工确认后受控 API 执行

这里的关键不是排斥模型，而是把它放在擅长的位置。可靠系统常常仍使用 LLM，只是不让它成为最后的事实源和授权者。

五、把任务拆成“理解、求真、执行”

用户说“把上个月重复扣的会员费退给我”，模型适合从口语中识别时间范围、扣费类型和用户意图；订单与支付服务负责查出真实交易；退款规则引擎计算可退金额；执行服务校验权限、限额和幂等键。模型最后可以用友好语言解释结果。

自然语言请求
  -> LLM：意图与参数候选
  -> 数据服务：查询交易真值
  -> 规则引擎：资格与金额
  -> 审批/权限：是否允许执行
  -> 退款 API：带幂等键执行
  -> LLM：解释确定性结果

这种分层让每一步都能单独测试和审计。若模型把“上个月”解析错了，用户可以在执行前看到具体交易；若 API 超时，幂等键防止重复退款。系统可靠性来自边界，而不是来自一条更强硬的 Prompt。

六、验证器必须独立于生成器

让同一个模型先生成答案，再问它“你确定吗”，只能得到相关的第二次概率判断，不等于独立验证。有效验证要引入不同的信息或确定性约束：JSON 用解析器和 Schema，引用用文档位置核对，代码用编译与测试，SQL 用只读权限和行数上限。

假设字段抽取有 1000 条样本，格式成功率 99%，字段准确率 95%。真正可自动入库的比例最多约为：

0.99 × 0.95 = 0.9405，也就是 94.05%

剩余近 6% 必须进入修复、重试或人工队列。只汇报“99% 能返回 JSON”会掩盖语义字段仍可能填错的问题，所以格式验证和业务验证要分别度量。

七、能力边界会随上下文和工具改变

边界不是固定的“某模型会或不会”。不接数据源时，模型不能知道一分钟前的库存；接入库存工具后，它能查询，但仍可能选错商品或参数；再增加参数校验和确认页面，端到端可靠性才提高。每增加一种能力，也会增加新的失败面。

模型升级同样会移动边界，但不能默认新版在所有任务上都更好。更长上下文可能改善资料覆盖，也可能带来中间遗忘；更强的工具调用能力可能提高完成率，也可能扩大误操作范围。边界必须用本业务评测和故障演练重新确认。

评测集应覆盖信息不足、指令冲突、工具超时、数据为空、权限不足和恶意输入。真正要测的是系统能否在不知道时停下来，而不只是正常样例里答得多漂亮。

八、上线时建立“拒答、澄清、转交”出口

如果产品只允许成功答案，模型会受到强烈诱导去猜。可靠交互至少有三条非成功路径：缺参数时向用户澄清；没有可信证据时明确拒答；风险或歧义过高时转人工。它们不是失败体验，而是能力边界的产品表达。

例如客服系统对政策问题要求至少命中一份有效期内的官方文档，并且引用片段支持结论。没有命中时返回“暂时无法确认”，而不是引用旧政策。高风险意图还应携带模型输入、工具结果、规则版本和审批记录，便于事后审计。

监控指标可以包括无证据回答率、校验失败率、人工转交率、越权工具调用次数和不可逆动作拦截次数。仅看用户点赞率会鼓励模型过度迎合，无法反映边界是否守住。

九、常见误区与追问

误区：模型足够大以后就不需要规则和工具。 参数规模不会自动带来实时真值、事务一致性和业务授权。
误区：温度设为 0，输出就完全确定且正确。 解码更稳定不代表事实正确，底层服务和模型版本也可能改变结果。
误区：让模型自我反思等同于事实核查。 自我反思仍可能沿用同一错误前提，核查需要独立数据或验证器。
误区：有人工确认按钮就一定安全。 如果页面不展示目标、参数和影响范围，人会习惯性点击，确认只是形式。
误区：拒答率越低，产品能力越强。 在证据不足和高风险场景，合理拒答恰恰是可靠性的表现。
追问：怎样判断一个任务可以全自动？ 要同时满足错误代价可接受、结果可自动验证、输入信息充分、执行可回滚，并通过真实分布评测。
追问：规则引擎和 LLM 如何分工？ LLM 解析自然语言和解释结果，规则引擎执行明确、版本化、可审计的判定。
追问：工具调用后是否就不会幻觉？ 不会；模型仍可能选错工具、填错参数或误读结果，因此需要参数约束和结果校验。

十、加强记忆

判断 LLM 边界，记住“容错、验证、信息、副作用”四问：错误代价多大，能否独立验真，事实是否充分且实时，输出会不会改变现实世界。语言生成、多解探索和可复核草稿可以交给模型；精确计算、权威查询、强规则判断和高风险执行必须交给确定性组件。最终架构按“模型理解—外部求真—规则验证—受控执行”拆开，并为证据不足准备拒答、澄清和转人工出口。

简化版

详细版