ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

证据优先:从“我认为”到“我证明”——大模型工程的第一性原理(第1期)

证据优先:从“我认为”到“我证明”——大模型工程的第一性原理(第1期) 证据优先从“我认为”到“我证明”——大模型工程的第一性原理第1期专栏《大模型落地之道智能体生态卷》作者Valhalla Matrix治理实验室文章类型原创技术实践与方法论总结适用读者技术负责人、架构师、AI 产品负责人、研发管理者摘要大模型能够生成代码并不意味着生成的代码可信。真正的工程风险往往不是语法错误而是模型在缺乏证据时自信地补全不存在的接口、参数和算法步骤。本文提出“证据优先Evidence-First”原则并将其与fail-closed机制结合讨论企业级 AI Agent 如何固定能力边界、减少模型幻觉、提升研发过程的可追溯性。文章同时给出一套从论文证据抽取、方法图构建、实现计划生成到代码验证和发布门禁的实践路径。关键词大模型、AI Agent、证据优先、Fail-Closed、企业智能体、能力边界、工程治理、提示工程一、从一次“自信的翻车”说起在一次论文复现任务中我们让一个 Agent 根据论文内容生成算法实现骨架。模型很快给出了结构完整、命名规范、能够运行的代码甚至还补充了若干看似合理的 API 和配置项。初步测试全部通过但经过第二轮语义核对后发现其中几个方法并不存在于原论文部分参数也没有对应的证据来源。模型并不是有意造假。问题在于它被要求“尽量完整”却没有被强制要求回答这个结论的证据在哪里于是缺失信息被模型的语言生成能力填补成了“看起来合理”的实现。这类问题比普通 Bug 更危险因为它通常具备三个特征代码可以通过语法检查示例输入下可能得到正常输出错误会在后续设计、测试和发布环节继续传播。因此大模型工程首先需要解决的不是如何让模型生成更多代码而是如何让系统在证据不足时停止扩展结论。二、什么是证据优先传统的模型使用方式通常是输入文本 - 模型总结 - 生成计划 - 生成代码证据优先的流程则强调获取来源 - 建立可定位的证据索引 - 构建方法图 - 生成实现计划 - 生成代码骨架 - 测试、评审和发布门禁它遵循一条核心原则先有证据再有计划先有计划再谈实现实现之后还必须能够复现。在企业级应用中模型可以负责提取、归纳和压缩信息但不应在没有证据时替证据下结论。一个完整的论文复现链路可以抽象为intake 论文元数据与来源确认 normalize 章节、公式、表格、指标结构化 method graph 方法、数据、训练和评估关系建模 code plan 将方法节点映射到实现任务 scaffold 生成可运行代码骨架 validation 测试、基准、人工复核 release 满足门禁后才允许交付任何一个关键节点缺少证据都应保留“未确认”状态而不是自动填入一个默认答案。三、为什么关键路径必须采用 Fail-Closedfail-open的逻辑是没有证据时先放行出了问题再补救。fail-closed的逻辑是没有证据时先拒绝补齐证据后再放行。对比项Fail-OpenFail-Closed缺少证据默认继续暂停并标记缺失缺少字段使用猜测或默认值保留未知状态权限申请先授权再审计先确认依据再授权发布决策先交付再发现问题通过门禁后交付风险处理事后补救事前拦截对于论文阅读、代码草拟等低风险探索任务允许模型提出假设是有价值的但对于以下场景默认策略应更加严格修改生产配置调用敏感业务 API访问内部数据生成对外发布的代码执行不可逆操作给出安全、合规或性能结论。一个简单的发布门禁可以写成证据是否存在 否 - 标记为缺失 - 拒绝放行 - 转人工复核 是 - 是否完成关联验证 否 - 保持待确认 是 - 进入下一阶段Fail-Closed 并不意味着所有步骤都要阻塞而是要把严格门禁放在真正高风险的边界上。四、模型“脑补”能力会怎样传播假设模型虚构了一个论文中不存在的接口后续链路可能发生如下变化不存在的接口 - 错误的方法图 - 错误的实现计划 - 带有伪能力的代码骨架 - 针对伪能力编写的测试 - 错误的评估结果 - 错误的发布决策最危险的地方在于后续测试可能只是验证“代码是否按照自己的假设运行”而不是验证“代码是否忠实实现了原始方法”。所以测试通过不一定说明论文复现正确。还需要增加语义一致性检查每个核心方法是否能定位到论文章节、公式或表格每个关键参数是否有来源代码中的数据流是否与方法描述一致实验指标是否使用了论文定义的口径未在论文中出现的扩展是否被明确标注为工程假设。这也是“证据链”比“代码能运行”更重要的原因。五、证据应该具备什么特征证据不是越多越好而是越容易复核越有价值。一条合格的证据至少应具备以下属性1. 可定位能够追溯到明确的章节、页码、公式、表格、代码行或版本提交。2. 可验证第三方可以根据原始材料重新检查而不必相信某个 Agent 的解释。3. 可关联证据与实现任务之间存在清晰映射例如公式 3 - 损失函数实现 表 2 - 评估指标配置 第 4 节 - 数据预处理流程4. 可版本化记录文档版本、代码版本、模型版本和数据版本避免来源内容发生变化后无法回溯。5. 能表达未知如果原始材料没有说明某个参数或边界条件应记录为“未说明”而不是由模型自行补齐。可以采用如下结构保存证据{claim:模型使用某种损失函数,source:paper.pdf,location:section_3.2, equation_4,evidence:原文或公式摘要,confidence:confirmed,linked_tasks:[implement_loss,add_loss_test]}其中confidence不应只是模型主观打分而应结合来源类型、定位信息和人工复核状态。六、Prompt-First 不是不能用但必须明确边界证据优先并不意味着完全拒绝提示词和大模型总结。模型非常适合完成以下工作将长文本压缩为结构化摘要提取候选方法、参数和指标发现章节之间的关联生成待核对的问题清单根据已确认的方法生成代码草稿。真正需要限制的是不能让模型用语言流畅性替代来源证据。更稳妥的职责划分是工作更适合由谁完成原文定位文档解析器、检索系统、人工复核证据关联结构化规则与人工确认语义压缩大模型代码草拟大模型与模板系统编译和测试自动化工具链最终放行规则门禁与责任人一句话概括模型负责提高处理效率证据负责约束最终结论。七、企业 Agent 的能力边界从“能做什么”到“允许做什么”个人助手可以在低风险场景中“试试看”企业 Agent 则必须回答在什么条件下允许它做什么一个企业 Agent 可能具备读取文档、查询数据库、调用业务 API、修改配置、触发部署和发送通知等能力。如果这些能力没有明确边界模型可能调用未授权接口访问与任务无关的数据修改超出范围的配置在错误时间触发部署使用过高权限完成简单任务。建议为每项动态能力建立能力卡至少包含能力名称 允许的调用方 所需权限 可访问的数据范围 前置证据 参数约束 失败处理 审计字段 人工确认条件例如Agent 要执行部署操作时不仅要判断“模型是否能生成部署命令”还要检查目标环境是否明确变更是否经过审批镜像和依赖是否已扫描回滚方案是否存在当前账号是否具备最小必要权限。能力治理的重点不是限制模型“会什么”而是限制系统“允许它在什么条件下做什么”。八、证据优先也是安全治理机制1. 防止模型生成错误的安全实现模型可能补写不存在的认证方式、错误的权限检查或不安全的默认配置。代码结构看起来完整并不能证明安全边界正确。涉及身份认证、权限控制、数据访问和密钥管理的实现必须回到真实接口、官方文档、代码调用链和安全测试中核对。2. 防止过度授权每一次能力授权都应能回答这个权限服务于哪个任务 证据来源是什么 为什么不能使用更低权限 权限何时失效3. 让审计记录“为什么允许”高质量审计不应只记录已经发生的操作也应记录放行依据请求主体 能力名称 证据版本 审批状态 参数摘要 执行结果 失败原因这样才能在出现问题时回溯“当时依据了什么”而不仅是回放日志。九、如何在团队中落地证据优先第一步识别关键路径优先识别生产变更、敏感数据访问、模型发布、依赖升级、权限申请和不可逆操作。第二步定义最低证据要求为不同操作指定必需证据例如操作最低证据要求生成论文复现代码方法章节、公式、参数和评估指标定位访问内部数据数据用途、授权范围、脱敏状态修改生产配置变更单、目标环境、回滚方案发布模型模型版本、评测结果、依赖扫描、审批记录执行部署镜像摘要、测试结果、发布窗口、权限校验第三步设置自动化门禁门禁应优先检查结构化条件而不是只让另一个模型阅读自然语言说明证据字段是否齐全 来源是否可访问 版本是否一致 测试是否通过 权限是否满足最小范围 回滚信息是否存在第四步为低风险任务保留快速通道探索性问答、草稿生成、非生产代码建议可以允许模型提出假设但必须明确标注已确认事实 待验证推断 工程假设 尚无证据第五步持续复盘误拦和漏拦定期检查哪些门禁误拦了正常任务哪些低风险流程不必要地增加了成本哪些操作在证据不足时被错误放行证据要求是否需要调整审计信息是否足以支持复盘。十、一个可执行的最小实践方案如果团队准备从零开始不必一次性建设完整治理平台可以先实现一个最小闭环用户需求 - Agent 提取候选结论 - 检索系统返回原始证据 - 规则校验来源和定位 - Agent 生成带引用的计划 - 代码生成 - 自动测试与人工评审 - 满足门禁后交付最小版本至少应具备三项能力引用强制化关键结论必须附带来源位置。未知状态保留缺少证据时输出“未确认”不自动补全。发布前阻断未满足最低证据和测试要求时系统不得将结果标记为完成。可以将 Agent 的输出统一分为四种状态confirmed 已有可复核证据 inferred 基于证据的推断 assumed 工程假设 unknown 当前没有足够证据这比让模型只输出一个看似确定的自然语言答案更适合进入企业研发流程。十一、常见误区误区一有测试通过就说明实现正确测试可能只覆盖了代码自身的假设并未验证它是否忠实对应原始需求或论文方法。误区二来源是公开的就不需要版本管理公开网页、论文和仓库都会更新。没有提交号、文档版本和时间信息就无法稳定复现当时的判断。误区三所有流程都采用严格阻断过度门禁会显著降低探索效率。应根据风险和可逆性设计分级策略。误区四把模型的置信语气当作证据强度“显然”“完整实现”“已经支持”等表达不会自动增加事实可信度。证据必须来自可定位、可验证的来源。十二、总结大模型时代工程判断必须回答“凭什么”证据优先不是一种单独的模型技巧而是一套工程纪律先定位证据 再形成结论 再制定计划 再生成实现 最后通过验证和门禁交付它的核心价值不是让模型永远不犯错而是让错误更早暴露、更容易定位并且不会在缺乏依据时被系统默认放行。对于企业智能体而言最关键的问题不是模型能不能完成这件事而是它凭什么认为自己能完成 系统凭什么允许它执行 执行结果如何被复核和追溯当 AI 开始参与代码生成、数据访问、配置修改和生产发布时“看起来合理”已经远远不够。用证据定义能力用验证决定放行用审计保证长期可控。延伸阅读方向企业级 AI Agent 的动态能力边界与权限治理Agent 上线前的安全评估与可验证保障论文到代码的可复现工程流程大模型生成代码的测试、审计与发布门禁**版权声明**本文为原创技术文章。转载或引用时请保留作者及原文出处信息并确保内容未被断章取义。
返回列表