股票 
板块 
用户 
资讯 作者：蔡洛维 博士（普元信息）关键词：RSI｜数据标准｜核验门禁｜AI Coding｜智能体
编者按
「本体洞见」关注本体在企业 AI 落地中的真实作用。本篇从工程一线切入自我改进闭环：模型要真正进步，前提不是跑更多轮、造更多数据，而是先把「什么算对」沉淀成可核对、可版本化的数据标准。这套标准，正是企业本体上下文在训练环节的延伸——不讲概念热度，只讲怎么让每一次报错变成一条清晰的门禁规则。
很多团队改了无数遍规程，模型却还在原地打转
做企业级代码助手或智能体（Agent）的同行，大多经历过这种抓狂的局面：
业务上的规程（Skill、Prompt）改了一轮又一轮，针对各种 bad cases 加了一堆提示词约束，但只要换个类似的需求，模型依然在同类任务上反复翻车。到了复盘会上，大家面面相觑——你说这几周模型能力到底有没有提升？没人说得清；下次遇到新场景能不能跑通？全凭运气。
问题到底出在哪？
很多人以为是“规程写得不够细”、“模型参数不够大”。但在实际工程里摸爬滚打下来，我们发现根子完全在别处：整个链路缺少一套客观、可核对的数据标准来界定“什么算对、什么算进步”。 因为没有清晰的标准门禁，上一轮暴露的缺陷无法固化为下一轮的训练输入，模型只能在混沌的打分中碰运气。
现在业界谈“递归自我改进”（Recursive Self-Improvement，简称 RSI），最流行的一句口号是：“用 Agent 生产合成数据，再去微调训练 LLM。”
方向听起来很美，但这句话把最关键的工程细节省略了——如果 Agent 自己对业务标准都糊里糊涂，它批量造出来的无非是一堆看似漂亮、实则通不过真实编译与业务校验的“垃圾数据”，用它训练只会让模型在错误的方向上越陷越深。
在我们的实践里，真实有效的自我改进闭环，逻辑必须倒过来：
不是用 Agent 盲目堆数据，而是用 Agent 把数据标准立起来，再用提升后的标准驱动训练，让模型的进步肉眼可见、可验证。
小结
模型反复翻车，缺的不是更细的规程，而是一套能界定“什么算进步”的数据标准。
别把“打个分”当核验：为什么核验必须有「双产出」？
想让系统具备自我改进的能力，第一道关卡就是重新定义“核验（Verification）”。
传统的评测逻辑非常简单粗暴：让模型生成一段代码或业务方案，测试套件跑一下，或者外挂一个评判大模型（LLM-as-a-Judge）打个分数——比如 60 分。
这种核验方式对工程迭代几乎毫无意义。它只回答了“这一期行不行”，却给不出“下一轮怎么改”。程序员在系统里加一句“注意检查数据字典”，下一次模型依然可能漏掉。
为了打破这种无效循环，我们在核验环节设立了一条铁律：核验绝对不能只有单一的质量结论，必须同时交出两份独立产出。
产出一：当期的确定性质量结论
这是对本轮交付物的严格体检，绝不是笼统的主观打分，而是由三类反馈综合归因得出的确定性事实：
- 过程反馈查看模型执行时的完整轨迹——读了哪些上下文、调用了哪些接口、在哪个步骤陷入了反复重试或超时。
- 结果反馈对照原始需求基线，核对功能是否完整覆盖、业务逻辑是否合法、交付结构是否符合规范。
- 核验机制反馈反思检查逻辑本身是否存在漏检、误报或偏误。
产出二：面向下一轮训练的标准优化提案
这是让系统能够自我进化的核心支点。核验程序不能仅仅抱怨“结果不对”，必须把发现的系统性缺陷，翻译成一份下一轮数据规格与门禁规则的优化提案。
举个我们在供应商管理模块里的真实案例：
在最初的一轮测试中，模型生成的代码在自动化检查程序（CHECK）中只拿到了 48.73 分。
从反馈归因来看，模型的执行轨迹里根本没有输出顶层的架构设计计划文档；虽然代码包里建了数据集和基础表单，但需求覆盖严重残缺，尤其是底层缺少最核心的“数据字典定义”。
如果按照过去的做法，无非是在 Prompt 里写一句“请注意生成完整的数据字典”，然后祈祷模型下一次听话。但我们没有这么做，核验给出了第二份产出——标准优化提案：
- 将文字提醒升级为硬性版本门禁在代码生成停机前，必须强制校验“顶层设计开发计划”，门禁规则本质上是把本体约束翻译成可执行检查；
- 制定完整树门禁规则明确规定“计划概览、需求基线、数据集、表单索引、数据字典”五要素缺一不可，只有五项全部齐备，才能触发后续的流程与服务编排。这里的要素并非临时编的检查项，而是来自企业本体中的实体—关系—字典约束；
- 固化为修复规程将缺失项拆解为可自动化回归的检查步骤，沉淀进数据清洗与训练流程。
经过这一套标准的严格升级，再把任务送回训练闭环，多轮迭代后，同样的供应商管理需求，模型在自动化检查中的评分直接拉升到了 80.79 分，且一次性通过了平台底层的结构校验。
这就是“双产出”的威力：第一份产出告诉你死在哪，第二份产出把死因变成下一轮必须遵守的铁律。数据标准往前走了一步，模型的质量才可能往前走一步。
小结
只给分数的核验答不出“下一轮怎么改”；双产出把死因变成了下一轮必须遵守的门禁。
真实落地的四步闭环：如何在工程中运转自我改进？
有了“双产出”的思路，闭环到底该怎么转？
在实际工程落地中，我们摸索出了一套四步执行框架。这套框架的核心思想只有一条：在受控的实验环境里找准病因，在严格的门禁下验证改进。
（图 RSI 四步闭环）
第一步：规划并冻结比较条件（不许在比赛中改裁判）
许多团队做模型评测时最容易犯的错误，就是一边跑测试，一边临时改 Prompt，甚至一边调整评分规则。这种“移动球门”的做法，会让所有前后对比失去科学性。
我们的规则非常明确：每启动一轮评估前，必须把所有外部条件彻底冻结——包括原始业务需求、当前候选模型、上下文工具链、评分口径与预算上限。复杂任务可以引入高阶模型协助拆解规划，但条件一旦锁定，运行过程中绝不允许任何人擅自修改评判标准。
第二步：真实工程环境下的执行与监控
模型不能脱离企业真实的开发底座去跑玩具 Demo。必须把它放进真实工程流水线中运行，并全程挂载监控：
- 它不仅要交付最终代码，还要实时记录中间产物；
- 记录每一次工具调用的输入输出；
- 一旦发生失败，精确归类是接口超时、语法解析错误、还是实体映射违规。
这样我们才能从“只知道结果失败”，变成“清晰知道在第几步断掉、为什么断掉”。
第三步：深度核验与双产出归因
结合监控捕获的三类反馈（过程轨迹、最终交付物、检查器本身的表现），执行前面提到的“双产出”：
- 给出当期的质量通过率；
- 更关键的是，输出针对标准漏洞的《优化提案》。不仅审视模型犯了什么错，也反查当前的评分规则是否出现了漏判或误报。
第四步：最小修改、正反例回归与训练闭环
拿到优化提案后，不要做大而全的激进改动，而是坚持“最小修改原则”：
- 把提案里的规则，正式写入可版本管理的代码门禁（Harness/Rule）；
- 拿着这套升级后的规则，不仅要重跑刚才失败的案例，还要跑历史上的正例（确保没有产生能力倒退）和反例（确保门禁确实能拦住错误）；
- 验证通过后，将这批高质量、符合新门禁的数据打包为正式样本，送入下一轮模型的微调或蒸馏训练。
只有当新模型在升级后的标准下复验通过，这一轮 RSI 才算真正闭合。
小结
冻结条件、全程留痕、双产出归因、最小修改回归——每一步都服务于同一件事：让改进可验证。
踩过坑才总结出的三条工程铁律
在探索这套闭环的过程中，我们也走过不少弯路，交过真金白银的算力学费。总结下来，有三条雷区千万不能踩：
铁律一：光谈“做数据”，不建“版本化门禁”，全是假闭环
很多项目宣称自己在搞自我改进，做法无非是写个脚本让模型生成几万条对话，清洗一下就拿去微调。这种没有强规则约束的闭环，往往是一场灾难。如果模型生成的代码根本连最基本的实体关系、字典规范都对不上，喂再多数据也只是加剧模型的幻觉。
没有写入 CI/CD 流水线、无法版本化追溯的门禁规则，就谈不上有效的数据标准。
铁律二：运行过程中绝不改裁判，改标准必须另起炉灶
发现现有标准有漏洞怎么办？千万不要在当前运行批次中直接修补评判逻辑。正确的做法是：当前批次如实记录缺陷，将修改诉求沉淀为提案；在新批次启动时，统一升级测试基线与检查门禁。把“评测”与“升级规则”解耦，数据才有说服力。
铁律三：远端运行结束，不等于本轮闭环完成
很多工程师把“训练脚本跑完了”、“测试集打出分数了”当成项目终点。但在企业级工程里，远端任务跑完只是开始。只有把训练后的新模型拉回真实的业务项目里，跑通复杂的端到端场景，确认没有引起历史能力回退，这一轮迭代才算拿到了真正的业务验收。
小结
没有版本化门禁、中途改裁判、远端跑完就算完，是让闭环失效的三种典型做法。
写在最后：让模型进步的，从来不是跑了多少轮
学术界近期的诸多前沿研究（例如关于开放式任务评分量表构建、以及有界递归自评机制的探讨），都在指向同一个本质事实：未经严密拆解和校验的奖惩机制，不仅无法引导模型成长，反而会迅速拉低裁判的信度与有效性。
大模型时代的工程实践，很容易让人产生一种算力崇拜：似乎只要把模型挂在服务器上无休止地自问自答、跑上一万轮，智能就会自动涌现。
但在严谨的企业级研发环境里，现实往往极其残酷：低水平的重复迭代，除了消耗昂贵的 Token 和电费，什么都不会留下。
完整意义上全自主的递归自我改进（RSI），在今天仍然是一个极具挑战的前沿探索；但在具体的工程场景中，我们已经可以用最扎实的方式让闭环落地：
不要迷信跑了多少轮迭代，先看看每一次报错有没有变成一条清晰的门禁规则；不要沉溺于生成了多少条数据，先看看你的数据标准有没有真正向前迈进一格。
标准走在前面，训练跟在后面。看得见、验得过的进步，才是工程的真功夫。
小结
低水平重复迭代只会消耗算力；先让数据标准往前一格，进步才看得见、验得过。
参考文献
[1] Shen, W. F., et al. (2026). Rethinking Rubric Generation for Improving LLM Judge and Reward Modeling for Open-ended Tasks. arXiv:2602.05125.
（指明评分量表若覆盖不足或维度纠缠会显著降低裁判准确度，主张通过递归拆解与过滤机制重塑评判基准。）
[2] Liu, K., Zhuang, Z., Weng, R., & Ye, J. (2026). RecurSE: Bounded Recursive Self-Evaluation for LLM Rubric Judges. arXiv:2608.24231.
（探讨有界递归自评估在评判模型中的应用，强调基于结构化元规则审查推理链路，并将自产奖励与独立监控机制解耦。）
作者简介
蔡洛维，普元信息 AI 科学家、智能创新中心总监、博士后研究员，参与编写 CCSA TC601《面向人工智能的数据治理实践指南》，并在多模态大语言模型与主数据管理方向有深入研究与实践积累。从企业级数据治理与本体，他关注的问题始终是同一个：模型在真实约束下，如何给出可信结果。
「本体洞见」系列关注本体在企业 AI 落地中的真实作用——它是什么、为什么中国企业可以从既有数据资产出发、又如何真正跑起来。本系列将持续更新。
扫码咨询产品专家，了解普元本体能力！
评论 (0)