作者：rhino

自 “Prompt工作手册” 发布以来，我持续研究大模型能力的应用及研发方法，结合产业发展，在研发框架和模型应用上有了新的思考，并形成了新的方法论，希望我们的能力不仅仅停留在模型研发的某一阶段，而能贯穿在研发全流程之上。本文介绍了我们近半年的工作成果，通过对研发框架的工程化，我们大幅降低了模型应用研发的成本，让人人都能开发大模型应用。

一、写在前面

1.1. 大模型应用是未来也是现在

“大模型” 爆发至今已有 2 年的时间，行业持续火热，模型基础能力持续升级。2024.9. OpenAI 发布的 “O1” 模型为领域再一次带来了新的突破，期间多模态也持续展现了令人惊喜的发展。于此同时，成本的降低与效率的提升也在持续进行，让大模型融入到了更多的场景之上。但相对的，在模型基础能力突飞猛进的背景下，“模型应用” 的发展就显得相形见绌，从 “领域模型” 到 “AI原生应用” 再到 “AI-Agent”，这些应用层的概念均获得了极高的热度，但时至今日，人们也没有看到新时代的到来，AI应用并没有如人们预期的一样爆发，其原因是什么呢？

我们可以从 “2024 Gartner AI 技术成熟度曲线” 中得到一些启发，“Generative AI” 即如今大模型使用的底层技术，已经到了 “期望膨胀期” 和 “泡沫破裂期” 的边界点上。这个敏感的节点表明，在前期的发展中，领域已经积累了大量的 “伪创新”，且在未来的一段时间里，伪创新会被大量的清洗，留下那些真的“金子”，稳步爬升，直至成熟。从这个角度，“AI应用” 对曲线来说似乎还是一个 “过早” 的话题，“稳步爬升” 期才是应用会大量爆发的时期，这在其他科技领域的发展中也可以被观察到（PC互联网，移动互联网）。

而这与大多数人的感受似乎有所差异，我们可以很明显的感知到大模型能力的强大，并且实际上，我们也已经在很多场景中使用它了，那为什么现在 “AI应用” 似乎还是为时过早，还是有些没到时候呢？上面这张趋势图中除了 “Generative AI” ，还有包含很多技术点，代表了AI各个领域的发展状态，其中不乏和大模型相关的领域，如：

发展期：AI Engineering，Model Ops，Prompt Engineering

萌芽期：Multiagent Systems，Decision Intelligence，AI-Ready Data，First-Principles AI，AGI

我们稍加观察就可以发现，这些与 “AI应用” 相关的领域，大多还处于 “发展期” 和 “萌芽期”。这些技术都是模型应用开发的关键节点，对模型的应用效果起到了决定性的影响。例如，我们最熟悉的 “Prompt Engineering”，一个几乎和大模型同时诞生的概念，在领域发展期间得到了持续的关注和研究，但直至今日依然处于发展的早期阶段。再如，近期火热的 “Multiagent System”，对于模型的应用效果，尤其是工业化的应用效果，至关重要，在2023年就被认为是未来最重要的技术之一，但时至今日依然处于 “萌芽期”。

如果我们综合观察这些技术的现状，不难得到一个结论：应用技术的落后成为了模型应用的关键阻碍。

在领域的发展中，持续有一种声音存在：模型的效果的根本取决于模型的基础能力，在模型基础能力的高速发展时期，不应该过多做应用层的事，基于当前模型能力做的工作，可能被一次模型升级彻底推翻。这种想法不无道理，但站在今天的视角下，我们看到模型基础能力的发展速度在明显衰减，人们对模型应用的需求持续增长，各项模型应用的基础能力仍待增强。所以，要做出更好的模型应用，不能再像以前一样，仅仅依靠模型能力的升级，而是要把尽力投入到模型应用技术的建设当中。

以上，我从领域发展的角度，阐述了应用侧技术的不成熟是大模型难以应用的关键，并引出了我们希望通过模型应用层的工作，让模型能力更好的落地。下面我就来具体分析，应用侧技术的不成熟，对模型能力的应用产生了哪些阻碍？我们具体想做什么？

1.2. 什么阻碍了模型应用？

首先，我们再来重新看看前文中提到的这些应用层能力，我们可以大致把他们划分为2种，一种是帮助开发者更好的完成模型能力的研发和部署，另一种是更好的利用模型能力产生更好的应用效果。

模型应用的研发&部署：AI Engineering，Model Ops，Prompt Engineering

模型应用效果：

1.  综合行为能力：Agent，MultiAgent Systems

2.  推理能力：Decision Intelligence，First-Principles AI

3.  数据能力：AI-Ready Data

这也就对应了模型在实际应用阶段的问题：开发成本高，应用效果差。

1.2.1. 模型研发成本高昂

首先，需要对我们所说的模型应用加以说明。一方面看，即便不使用任何技术，今天的大模型依然可以产生令人惊喜的效果，但当我们要将其应用到工作中时，就会发现其存在的各种问题，例如：稳定性，准确性，可控性，以及 “对齐” 问题等等，而我们讨论的也正是这种场景。

为了解决这些问题，我们就需要使用一些技术，例如：

Prompt工程：通过优化Prompt框架，影响模型的输入，获得更好的效果。

模型训练：通过数据训练的方式，影响模型的参数，获得更好的效果。

RAG & 知识库：赋予模型检索外部数据的能力，以补充模型知识不足的问题，获得更好的效果。

Agent系统：通过拓展模型的能力（记忆，插件，多模型调度），以及构建由多个模型组成的系统，获得更好的输出。

这些技术即便有对应的工具支持，也都有较高的使用门槛，需要使用者具备一定的专业能力，这也就对模型的研发造成了不小的成本。即便是其中技术难度相对较低的 “Prompt 工程”，也已经不断发展中积累了不少的技巧，还包含不同模型之间的分别，“非技术人员” 想要掌握并不简单。

其次，即便开发者掌握了一些技术（可以完成Prompt的编写），也很难独立完成模型应用的研发。整体的研发流程不仅是单一模块的工作，涉及 “数据”，“算法”，“工程” 等多个模块，包含 “数据准备”，“数据标注”，“问题建模”，“能力研发”，“效果评测”，“模型调试”，“上线部署”，“落地应用”，“优化迭代” 等多个阶段，是一项系统化的工程，这也对模型的应用造成极大的成本。

因此，即便人人都可以在和模型 “聊天” 的时候感受到模型能力的强大，但并非人人都能真的应用模型。

1.2.2 模型效果优化困难

前文说了模型的开发成本，此处还需要说明模型的应用效果，两者有所关联，但不完全一致。由于大模型的基础能力所限，即便模型能力在不断更新迭代，其依然存在若干无法根治的问题，例如：

知识不足：模型并非知识库，在很多时候会展现出知识上的不足，尤其是在应对： “高时效性知识” ，“专业领域知识” ，“业务领域知识”。

推理能力不足：目前的大多数模型，都存在推理能力不足的问题，尤其是在面对数理问题时，甚至无法完成最基础的数理逻辑，即便是在 “O1“ 发布以来，推理能力仍然被认为是如今大模型最需提升的能力之一。

稳定性不足：自大模型诞生以来，“不稳定性” 就是被人们谈论最多的问题，今天我们可以看到“幻觉”问题已经大幅减少，但效果上的不稳定依然存在，并且实际影响到了模型的“可控性”，目前还没有得到很好的解决。

当然，我们有一些技术手段来应对这些问题，例如：

RAG：从行业的趋势，慢慢长成了行业的共识，很好的解决了 “知识不足” 的问题， 时至今日已经演化出多中类型的方法，已应对不同种类的数据，并且知识应用的效果也得到了大幅的提升。

Hidden COT：O1 模型的发布在模型推理上带来的新的突破，从OpenAI官网的文章及各种的采访中，我们可以大致了解到 O1 使用了 Hidden COT 的技术。如果分析OpenAI官网给出的例子的话，会发现它确实能通过这样逐步拆分，提升其推理能力，并在这样逐步的思考中，意识到之前犯的错误，并自动进行修正。这种问题切分和错误修正的能力对于模型能做长链条思考及解决复杂任务非常重要。

Agent & MultiAgent：要让模型真的在应用中发挥效果，仅仅让模型 “聊天” 是远远不够的。我们可以赋予模型更多的能力，让他帮我们去完成实际的任务，让他有记忆，会计划，能执行。同时，我们可能还需要更多的模型加入，组建一个由Agent组成的团队，去完成更加复杂的任务

这些技术可以帮助我们更好的应用模型的能力，让他发挥出更好的效果。然而，这些技术还都处于“萌芽期”，还在不断的产生和迭代。换句话说，只有用好这些“技术”，模型才能在应用中展现出令人满意的“效果”，即便是对专业的技术人员，这也是一项不太容易的工作。这些技术中的存在的专业壁垒，也对模型应用的研发造成了不小的困难。

1.3. 模型应用研发的痛点

痛点：模型效果难优化，成本高，技术挑战大

如前文所述，模型应用的开发成本高，应用效果差。这使得，即便大模型的基础能力十分强大，大家也无法真的把他应用起来。

大模型的能力本是通用的，大家对未来的畅想，也是希望他是通往AGI的道路。但由于他极高的研发成本，和不可靠的应用效果，模型应用从通用走向了定制，开发模式也变成了集中化的闭源模式，并且，这并不是一两个模块的改进就可以解决的，而是整个研发流程都需要进行的优化。

目前市场上也不乏有一些单一环节的研发工具，如：Prompt工具，模型训练工具，模型调度工具。这些工具无疑是降低了研发环节的成本，并提供了一定的效果保障。但如果我们要让每个人都能完成模型的应用，这还远远不够。单一环节工具带来的降本增效，往往是面向开发人员的，并没有起到降低专业壁垒的作用。要降低应用模型的成本，首先要降低研发流程的成本，让每个人都能较低成本的完成这个研发过程，比单一环节的优化更为重要。

尤其是对于大模型的领域化应用而言，依赖算法专业人员集中式的构建领域能力，不仅与大模型通用化的发展趋势不符，也不能满足领域的诉求。只有让领域内的专家（非算法开发人员）自己完成模型的应用，搭建类似开源的能力研发生态，才能真的做到模型能力的领域化，毕竟领域最重要的价值，是领域内的人，而并非纸面上的知识和技术。

二、让人人都能开发大模型应用

前文分析了我们希望解决的问题，以及我们想达到的效果。我们希望可以降低模型的研发成本，提升模型研发的效率和应用的效果，让每个人都能完成模型能力的应用。

近 1 年多的时间里，我一直在探索大模型和“质效”领域的结合，希望可以将模型能力融入到业务的质效工作当中，在 “测试用例”，“缺陷”，“需求”，“代码” 等领域中完成了若干尝试，其中也有不少能力在业务落地，并取得成效。但在工作中，也遇到了一些明显的阻碍：

模型研发效率无法匹配领域诉求：质效领域是一个贯穿产品研发周期的领域，其中包含大量的领域诉求，仅仅“测试用例”相关的模型能力点，就可以做到上百个。并且在领域和业务常年的积累下，诉求的定制化严重，可复用性差。而在这种情况下，模型能力从研发到应用落地的周期为，“1个/人月”，与领域诉求存在巨大差距。

模型研发人员无法掌握领域专业：质效领域的每个模块都包含着大量的专业知识和专家经验，结合复杂的业务知识，模型研发人员很难完全掌握，而这些领域往往又不具备大量的数据，在模型研发过程中就十分依赖研发者的专业能力，而这些复杂的专业能力又不是非领域人员可以轻松掌握的，这无论是对模型能力的研发效率还是应用效果都造成了极大的苦难。

无法与领域专家建立高效的协作模式：领域专家提供专业知识和指导是模型重要的输入之一，但由于算法与领域均包含较高的专业壁垒，且模型研发流程不规范，导致很难建立高效的协作模型，领域专家的知识很难传导至模型。

这些问题并不专属“质效”领域，对于大多数模型应用的场景都存在类似的问题：领域专家无法应用模型，模型开发人员不了解领域知识。

因此，我们希望降低模型应用的研发成本，降低专业壁垒，提高模型的研发效率。让领域内的人都能完成模型应用的研发，都能完成模型能力的应用。以此让模型能力更好的在领域内落地，持续推进大模型的领域化。

目标：让人人都能完成大模型应用

人人：对大模型（AI）不了解的人（领域专家）

完成：低成本的满足自己的诉求，并达到稳定的效果

大模型应用：能在实际场景中落地，并产生应用效果

三、大模型研发框架

为了达到前文中阐述的目标，我们希望打造一个模型应用的研发工具，可以帮助大家降低模型研发的成本，提升模型研发的效率。与目前市场上的模型研发的工具不同，目前的研发框架在效率和效果上可以提供一定的帮助，但并未降低模型研发的专业比例，大多还是面向技术人员，对用户提出了不小的技术门槛。

我们希望通过大模型能力的加持，对整体研发流程进行改进，让用户仅需处理“任务”维度的信息即可完成研发。类似于 “2024百度世界大会” 上发布的“秒哒”工具，一款不用写代码就能实现任意想法，输入自然语言或PRD，即可生成应用，无需技术与设计经验的无代码开发工具。我们也希望研发一个针对模型能力的 “MultiAgent” 系统，通过简单的输入即可完成模型应用的生成。

与现有模型研发工具的差异：

面向所有人：我们希望可以让所有人都可以低成本的实现一项模型能力，而非仅仅针对专业人员

我们本身就是一个多智能体系统：我们希望搭建由多智能体组成的系统，具备各个环节的模型研发能力，尽可能降低各个环节的成本

不仅仅是针对单一模块：我们并不想成为某一单一环节的增效工具，而是希望从目标出发，作用于研发全流程上。

3.1. 从 “Prompt工程” 到 “模型研发框架”

正如我们之前论述的，我们希望赋能在研发全流程上，而非单一的研发环节。但实际上，最初我们想做的和很多人一样，仅仅是一个 “Prompt工具”，这里的心路历程是怎样的呢？

“Prompt” 是影响模型效果最直接的变量，领域中充斥了大量对Prompt的研究，我也并不例外。在大模型应用的探索中，为了更好的让Prompt产生稳定的效果，为了提升对Prompt的管理能力，以及Prompt生成的效率，我花了不少时间聚焦在Prompt框架的研究上、。

对于 “Prompt工程” 的框架化进而产生了工程化的想法，是否可以通过将“Prompt工程”工具化，帮助开发者自动完成Prompt的编写和优化呢？事实上，无论是方法，框架，产品，这类工具在市场上都并不少见：

算法：APE ，APO，OPRO

技术框架：DsPy 提示词工程自动优化框架（一种自动优化提示词的方法）
GitHub - stanfordnlp/dspy: DSPy: The framework for programming—not prompting—foundation models
关于 DSPy | AI工具中文文档

产品：
Prompt优化_大模型服务平台百炼(Model Studio)-阿里云帮助中心
PromptPerfect - AI Prompt Generator and Optimizer
Prompt优化 - ModelBuilder

这些产品都可以帮助用户完成Prompt的生产，他们了解各类大模型的特点，善于使用各种Prompt技巧性，并可以通过算法结合数据不断对Prompt进行优化。这无疑对 Prompt 的生产和管理提供了极大的帮助，在大模型日新月异的今天，即便是Prompt专家也很难熟悉每种模型的特点，和每一种Prompt技巧，这些工具是一个很好的帮手，可以显著提升Prompt编写的效率和效果。

但如果我们进一步思考，即便Prompt工程对模型效果十分重要，但他只是一种技巧，并非模型研发的 “第一性”。甚至在很多场景下，人们会对该使用什么技巧产生争论，例如 “Prompt” 和 “模型训练” 的争论。

基于目前大模型自身强大的能力，我们认为模型研发的 “第一性” 就是 “提升应用效果”，用户不需要也不应该了解模型研发背后的技术，只需要对当下的任务负责，对当前的效果负责即可，而比起提供若干的Prompt技巧，对“提升应用效果”更有帮助的问题或许是：

1. 如何评估效果：目前的Prompt好不好，效果怎么样？

2. 如何 debug：模型犯了某种错误，我该如何调试？

3. 如何优化模型：模型某些方面的能力不够强，我该怎么办？

4. 如何应用模型：我怎么把模型用到工作中？

这些问题均不指向某个单一的研发模块，而是更全面的指向整个研发流程。大家需要的不仅是一段段的Prompt，而是一个可以帮助我们不断提升模型应用效果的工具。因此，我们最终把目标转向了模型研发流程的工具化，希望这个工具能让每个人能具备应用模型的能力。

3.2. 模型研发流程

简单来说，我们就是希望在“大模型应用研发”的过程中，用AI的方式，帮助用户做一些工作，首先我们先来看看大模型应用研发的过程：

结合我在模型应用研发上的探索，目前的模型应用研发工作可以大致分为如下几个环节：

1. 建模：首先我们要对问题进行定义，明确需要模型为我们做什么。从业务视角看，我们要把模型能力引入到业务中，首先要把问题定义清楚，这是模型应用的关键，类似传统研发中需求的产出，只有明确了需求和目标，才能进行后续的研发和调试。同时，我们需要将业务问题翻译为技术语言，用AI思路对问题进行转换，也就是完成问题建模的过程。这个过程往往容易被忽略，但对后续研发十分重要（最简单的：模型输入什么？模型输出什么？）
2. 数据：数据是大模型的3大关键要素之一（算法，算力，数据），与任务对应的数据是模型的主要输入，是模型训练和调试的主要依据，应尽可能覆盖任务的假设空间。数据标注任务是其中最苦难的环节，很多情况下，我们仅能找到数据的 “输入” 部分，而无法得到数据的 “输出”，此时就需要我们进行标注，在今天的大模型时代，AI标注成为了常用的解决方案，后文还会展开介绍。
3. 模型：在前面的两个步骤中，我们准备好了模型的输入，下面就需要根据这些输入进行具体的模型调试，优化模型在任务中的效果。这是模型研发过程的主要工作，可能会分为多个部分：

a. 模型选型：首先我们需要依据任务类型，以及我们对应用的要求，选择合适的大模型进行调试。通常我们会进行一些轻量的实验，辅助初步的选择。

b. Prompt工程：在选择好模型后，我们就需要根据我们的任务对Prompt进行调试。随着领域的不断发展，Prompt工程已经积累的大量技巧，也产生了一些方法框架，以及相应的工具。理论上，如果模型能力足够强大，我们仅仅通过 “Prompt工程” 即可完成效果的调试。

c. 其他优化技术：“Prompt + 模型” 已经构成了模型应用的最小单元，但实际上，这往往并不能产生令人满意的效果。因此，在这个基础上，我们还需要增加一些额外的调试手段，例如：“RAG”，“训练”，“CoT” 等等，以此进一步提升模型的效果。

d. Agent & MultiAgent：当我们处理的问题更加复杂时，单纯的模型语言能力无法满足我们的诉求，我们需要赋予模型环境感知、自主理解、决策制定，执行行动等能力，让其处理更加复杂的任务。同时，我们的任务也可能包含多个推理阶段，需要我们引入多个Agent的能力，通过系统级的模型调度来完成

模型的调试方法很多，且在不断的更新迭代当中，这里仅仅罗列其中最主要的一些方法。是否需要使用，以及如何使用，往往需要结合任务的具体情况以及模型现状来进行判断，这往往依赖模型研发人员的经验，也是模型研发过程中专业壁垒最高的部分。

4. 效果评测：在我们调试模型的过程中，以及初步完成模型调试后，我们都需要对模型的效果进行评测。通常的方法就是应用模型在我们实现准备的数据上尽性推理，并计算模型推理结果和实际结果的差异。对于不同的任务会应用不同的评估指标，但总体来看，均是度量两者间的相似度。比起量化的指标结果，模型在评测过程中出现的问题更加重要，针对badcase的分析，是模型进一步提升效果的关键。
5. 持续优化调试：模型调试不是一个一蹴而就的单向过程，在领域持续发展的今天，即便基础模型都会持续更新，其中的若干优化方法更是在不断的迭代当中。即便是模型上线应用以后，分析badcase并不断提升模型效果，也是一个持续不断的过程。
6. 部署&运维：当模型效果达到应用标准后，我们就需要进行模型的部署，将其融入到我们的应用场景当中。无论是通过接口，定时任务，还是通过定制的工程开发，我们需要让模型能力尽可能的贴合我们的应用场景，让模型在应用中产生效果。

在过去1年多的时间里，我们一直在业务中探索大模型和质效领域的结合，尝试应用大模型能力解决业务的质效问题，完成了多项能力研发，并在业务落地，下面用一个实际例子，更直观的解释模型研发的过程。

在业务质效能力的建设中，“用例检查” 任务通过大模型能力的引入，发现“测试用例”中存在的问题，辅助“测试用例”质量提升，缓解业务因用例导致的漏测问题。在 “用例检查” 要发现的具体问题上，“二义性” 问题是其中最典型的问题之一，也是目前应用最广成效最多的能力之一。我们希望引入大模型能力，对用例进行检查，发现 “测试用例” 中存在的二义性问题：

1. 建模：

a. 问题定义：对用例中存在的 “二义性” 问题进行分析，并对其引起的漏侧问题进行分析，找到其中的典型案例，确定 “二义性” 定义，补充必要的业务知识和专业知识。

b. 问题建模：用技术语言对问题进行描述，检查问题实际是一个 “分类任务” ，我们需要根据用例的“标题”，“步骤”，“预期结果”对用例进行分类，将用例分为2类：“存在二义性问题” 和 “不存在二义性问题”。

2. 数据：

a. 原始数据采集：我们的数据输入就是用例内容，目前业务有近20w+的用例数据，数据储备充足

b. 数据清洗/计算：任务聚焦在对用例内容的检查，因此无需做过多的计算，仅需对数据格式进行统一，并筛选出适合用于模型调试的数据即可。

c. 数据标注：虽然业务的用例储备充足，但由于过往没有经历系统化的检查，因此没有充足的标注信息。因此我们引入了 AI 标注的手段，应用 GPT4 对用例进行了粗标，并人工进行确认，获得了 500条 左右的标注数据

3. 模型：

a. 模型选型：由于任务的敏感性和成本的要求，我们无法直接使用闭源的外部模型，而是选择了在公司内部私有部署的 qpilot-chat（底层是ChatGLM，由Qpilot团队微调得到）。

b. Prompt工程：结合我们的任务定义和数据，我们进行了多轮的 Prompt调试 工作，在“定义”，“任务描述”，“要求”，“限制条件” 等多个方面对进行了多次的优化，产出了多版 Prompt，反复提升模型效果。

c. RAG：测试用例不仅与领域专业结合紧密，与业务知识也有很大的关联，因此我们引入RAG技术，结合知识库，对 “业务专用词”，”领域专用词“ 进行解释，提升能力的应用效果以及在各个业务的适应度。

d. CoT&稳定性提升：为了提升能力的稳定性，引入了CoT模块，拆分思维链，并增加“反思”等机制，缓解小模型的幻觉问题，提升能力的稳定性。

e. 格式限制&条件限制：抽象模型的各类“限制模块”，作为单独的推理环节，结合模型调度能力，在任务推理的各个环节提升模型的可控性和稳定性。

f. Agent & MultiAgent：对整体系统而言，我们为模型增加“记忆调度”，“插件调度”，“条件限制” 等多项能力，尤其是在格式限制和条件限制方面，抽象模型的各类“限制模块”，作为单独的推理环节，结合模型调度能力，在任务推理的各个环节提升模型的可控性和稳定性。

4. 效果评测：在模型调试过程中，我们进行了多次的模型效果评测，计算模型在数据集上的“准确率”，“精确率”，“召回率”等指标。并持续对badcase进行分析，指导模型的优化方向。
5. 部署&运维：为了让模型能力更好的在业务中落地，我们提供了多种应用方式：api接口，定时检查任务，以及我们结合业务的实际应用场景，进行了专项的工程化开发，研发智能用例平台，承载用例的检查和问题的修复。同时我们为了让检查问题得到更好的闭环解决，我们将检查问题和Tapd打通，并制作质量看板对数据进行分析，通过推送等方式进行业务触达，切实推动问题闭环解决。

3.3. 我们要做什么

前文中，我们结合示例叙述了模型应用的研发流程，我们希望引入大模型能力，为用户承担这个流程中的部分工作，以此提升模型研发的效率，降低模型研发的成本和技术壁垒，让人人都可以完成模型能力的应用。因此，我们需要进一步分析，具体要在哪些环节提供帮助。下图用3中颜色进行了标识，分别表示研发流程中需要用户负责的，系统负责的，以及共同负责的部分。

1. 建模：

a. 问题定义：问题定义是与具体任务最为相关的部分，用户需要明确希望大模型为自己做什么，并进行清晰的定义，此步重点在用户需求的定义，由用户独立负责。

b. 问题建模：把问题定义转换为技术语言，对于非技术人员并不简单，但由于是模型研发的基础输入，且依然属于用户需求的范畴，知识表现形式有所差异，因此也需要用户独立负责。工具会根据任务类型，通过清晰的模版定义帮助用户，但内容的编写还是由用户完成。

2. 数据：

a. 原始数据采集：除了问题的建模，用户还需要提供一定量级的输入数据，此处指的是原始数据，并不包含标注信息，因此仅与任务内容相关，需要用户独立负责。工具会以插件的形式提供一定的数据获取能力，例如从Tapd，腾讯文档读取数据。

b. 数据清洗/计算：我们可能还需要在原始数据的基础上进行一定的清洗/计算，但并非必要环节，工具会提供一定的能力支持，如：格式解析，格式整理，但主体由用户独立负责。

c. 数据标注：标注是数据准备阶段最困难的工作，我们往往仅能批量获取任务输入部分的数据，而无法获取任务的输出部分，若依赖人工标注则往往会产生较高的成本。工具会提供一定的AI标注能力，事前应用能力较强的闭源模型（混元，GPT4）对数据进行粗标，再结合人工确认，低成本的和用户共同完成数据标注工作

3. 模型：

模型阶段的所有工作都可以由系统自动处理，但为了提升用户的定制化程度，在某些环节用户可以进行一定程度的干预：

a. 模型选型：工具会结合业务的实际情况（数据类型，复杂程度，成本）推荐合适的模型，用户也可以手动选择进行更改

b. Prompt工程：工具具备强大的Prompt编写和优化能力，可以根据用户的前序输入自动进行Prompt的生成。

c. 其他模型调试技术：“基础模型 + Prompt” 已经构成了模型应用的最小单元，但我们往往为了达到更好的效果，需要引入更多的技术模块进行优化。工具会结合任务的实际情况，进行技术的选取和使用，自动完成效果的优化工作。

4. 效果评测：在完成一次模型调试后，模型就会对事前提供的数据进行推理，产出每条数据的推理结果，并结合具体的任务类型，产出评测指标，如：准确率，精确率，召回率，F1-score 等。
5. 持续优化调试：

理根据评测的实际结果，我们需要对模型的效果进行持续的优化迭代，在工具的帮助下，这是一个半自动化的过程：

a. 数据驱动的自动优化：工具会对评测数据中的badcase进行分析，并基于分析结果，调用模型调试环节中的各个模块，对模型效果进行优化（Prompt优化，RAG，reflection，等等）

b. 人为驱动的半自动优化：对于评测结果中的共性问题，可以人为进行分析和抽象，形成对应的限制目标，如：“输出格式需满足 xxx ”，“过滤输入中的url”，“xxx 情况不属于类别 A ”，等等。通过自然语言对优化目标进行描述，工具即可完成相应的优化。

6. 部署&运维：

为了让研发的模型能力得到实际应用，我们提供了多种应用方式，希望可以尽量贴近模型的应用场景。最基础的，我们对所有能力均提供：

a. API接口：提供统一的API接口能力，方便在各种场景中即成。

b. 定时任务：仅需要简单的脚本编写，即可部署定时任务，定期批量对模型能力进行应用。

同时，我们还在探索各种其他的能力集成方式，如：

c. 智能用例平台：对于质效域能力，尤其是测试用例的相关的能力，我们已经自主研发了智能用例平台作为承载，用户可以将各项子能力一键在平台中完成上线。

d. 聊天驱动的agent能力：通过 "聊天机器人" 的方式对能力进行部署，用户可以通过聊天对搭建的能力进行调用。

e. Tapd + 看板：用户可以将模型输出的结果直接连通至Tapd，并结合数据看板进行结果的查看和处理。

3.4. 总结

前文中已经详细阐述了，为了达到目标，我们希望在模型研发流程中提供哪些帮助。实际上，我们自身就是一个 “MultiAgent” 系统，让用户只需要 “明确需求”，“提供数据” 就可以无代码的完成模型应用的研发。并通过这种方式，不断积累领域能力，推进模型应用在领域中的发展，建立类似开源的研发环境，真正实现模型能力的领域化。

四、构建模型能力的Agent系统

前文中介绍了，我们希望达成的目标，以及我们具体要做的事。下面我就针对工具的几个关键模块，从技术角度，简单阐述我们是如何做到的。

4.1. 建模

建模部分是模型调试阶段最重要的信息输入，相当于功能的需求文档，只有将需求定义清洗，才能保证模型的效果符合预期。与前文中介绍的一致，建模由2个环节组成：问题定义，问题建模。

对问题定义而言，用户可以根据业务应用的视角进行任意问题的定义，但对问题建模而言就需要增加一定的限制。两者在内容上并无差异，但在视角上有所差别。首先是要区分任务的类型，将任务首先映射到对应到常见的AI任务类型上，如：

基础任务类型：分类，聚类，生成，回归

综合任务类型：信息抽取，文本总结，问答，关键词抽取

这其中的每种任务类型，都可以在应用层演化出多种任务，例如前文中提到的 “用例检查”，就是 “分类” 任务的一种。而每种任务类型内，是有共性存在的，这也就在一定程度上，构成工具可以成立的底层基础。工具对每种任务类型的共性部分进行封装，每种任务类型对应相应的研发流程，通过这种封装和复用，降低应用任务的研发成本。例如：所有分类任务在 Prompt 上有共性的成分，可以应用相似的Prompt结构。

由于这个阶段十分重要，为了确保建模的过程可以提供足够的信息，工具为每种任务类型定义了相应的模版，辅助用户完成问题的建模，例如分类的模版如下：

用户需要根据任务的实际情况，确定任务类型，并填写相应的模版，完成对任务的建模。在模版的填写上，由于此处是用户唯一的输入方式，目前没有引入任何的智能填写手段，可能会涉及多处的描述和定义，也是后期调试模型需要重点修改优化的地方，是影响模型效果的重要因素之一。此处内容的具体填写标准与任务复杂程度和模型能力均有关系，无法产出统一的标准，考虑到可能存在的不确定性和填写的成本，用户可以通过先简单填写，再在后续调试过程中逐步优化的方式完成填写工作。

4.2. 数据

数据也是任务的关键输入之一，在后续的多个调试，训练，评测步骤中均会得到应用。由于数据与任务定义强相关的特性，数据准备工作也需要用户完成。工具中的所有对象均以任务维度进行管理，用户在模型调试前，需要上传任务对应的数据集，以完成准备工作。

工具对数据并没有过多的要求，每种任务类型会有相应的数据格式要求。但总体上看，数据集仅需简单的包含模型的 “输入-输出” 即可。同时，尽量保证对任务假设空间的覆盖，以保证更好的效果。

此处还会涉及数据标注的工作，通常会造成较高的人力成本。工具支持使用大型模型对数据进行标注，并应用这些数据训练小模型，这种方式已经逐渐成为了共识的做法，其有效性也在有多篇论文中得到了论证。其中最有代表性的：

1. S3框架：通过使用大型语言模型来缩小小型模型在合成数据集和真实任务数据分布之间的差距。实验结果表明，S3框架在多个自然语言处理（NLP）任务上均取得了显著的性能提升，相较于其他基线方法，如ZeroGen和GoldGen，S3能够显著提高小型模型的性能：相比ZeroGen提高了9.48%，相比GoldGen提高了2.73%，且最多能比基于人工标注的数据训练的小型模型提高15.17%。
2. FreeAL框架：该框架通过大模型时代的主动学习技术实现大小模型协同工作，达到Human-Free的数据标注。在协同训练期间，LLM作为主动标注者灌输其粗粒度知识，而下游SLM则作为学生过滤出高质量的上下文样本，以反馈LLM以供后续标签精炼。对八个基准数据集的大量实验表明，FreeAL在没有任何人工监督的情况下极大地增强了SLM和LLM的零样本性能

我们也在工具中集成了这种AI标注的能力，即应用大型模型（混元，GPT4）帮助用户进行粗标，再由人工确认后，完成标注工作。

4.3. 模型

模型效果调试是模型研发流程中成本最大，技术壁垒最高的阶段，也是工具最主要的价值。理论上，用户只需完成“建模”和“数据”的相关工作，工具就可以自主完成模型应用的研发，并通过多个模块的方法保证应用的效果。下面我就具体介绍一下，其中几个重要模块的实现方法。

4.3.1. MultiAgent System

相对于大语言模型，智能体（Agent）是一个更广泛的概念，是一个能够独立做出决策并实际执行任务的实体，而大语言模型仅仅是一种通过分析大量的文本数据来学习语言模式和结构，从而能够执行文本任务的模型。大语言模型自身不具备执行任务的能力，却可以很好为智能体做出决策，并驱动智能体完成交互任务。显然，在大多数任务中，我们仅仅拥有语言模型是远远不够的，对我们的工具而言也是如此，我们需要智能体帮助我们完成一个个任务的执行。

对于由多个智能体组成的系统，我们可以称为 “多智能体系统”（MultiAgent System），在这些系统中，多个智能体可以协同工作以完成复杂的任务。这项技术自2023年底至今，持续获得了学术界和产业界的关注，诞生了大量的研究，比如：

1. MetaGPT：一种新颖的元编程框架，将高效的人工工作流融入到基于LLM的多智能体协作中。其将复杂的开发任务分解为分配给不同角色的特定可操作过程（例如Product Manager, Architect, Engineer等等）。
2. AutoGen：通过Multi-agent框架设置各类完成各种复杂任务，如论文中列举的：解数学题，检索增强问答，代码生成，国际象棋，等等。

我们的工具也是一个 “多智能体系统”，通过多个“智能体”的协作，完成模型应用的开发。同时产出的每项模型能力也都是基于多智能体的系统，帮助用户在各种复杂场景中完成任务。

上图展示了系统的大致结构，整体分为6个Agent模块，每个模块包含多项模型能力，覆盖从模型能力研发到优化迭代的完整研发过程

1. 综合调度Agent：系统的决策中心，负责对输入进行理解并对任务进行分析和拆解，制定执行计划，并调度各个模块。
2. Prompt Agent：负责 Prompt 的编写和管理工作，结合Prompt框架完成编写，并结合效果不断优化。
3. 模型训练Agent：负责模型的训练，调度各类模型训练脚本，处理训练数据集，串联模型训练流程，完成模型训练。
4. 能力调度Agent：负责根据实际情况调度各种能力优化模型效果，如：RaG，CoT Reflection 等，每种子能力也作为执行Agent，且支持横向扩展
5. 插件调度Agent：负责在各个环节调用外部插件，如：数据获取，格式转换。插件独立于模型研发过程，为系统提供额外的能力加持。
6. 意见理解Agent：负责理解评测结果，根据BadCase和认为修改意见给出修改建议，提供给综合调度Agent，进行持续的优化迭代。

为了让 Agent 模块内部以及多个 Agent 之间可以高效协作，我们采用了4层的职责划分框架，也在底层构成了 Agent 的统一结构。如上图所示，我们将Agent职责划分为了：Decison（决策），Plan（规划），Action（执行），Result（结果）。

1. Decision 决策：负责分析当前任务，理解输入和上下文，觉定要应用的系统能力，以及各项能力的具体应用方式。
2. Plan 规划：负责规划能力的具体实施方式，规划工作流程，并指导执行层有序开展工作。
3. Action 执行：负责具体任务的实施，完成每个原子单元的任务，并串联各个模块的工作，产生最终的执行结果。
4. Result 结果：负责汇集执行层的结果并反馈至决策层，作为决策层下一步工作的主要输入。

为了帮助大家更直观的理解各个层级的实际作用，我们在上图中以 “Prompt 编写” 环节为例，展示了各个环节的工作。这个框架构成了Agent的最小工作单元，不仅是单一模块的工作，对于多个Agent的组成的复杂系统，也同样是由这样的结构组成的。

以上，我们描绘了系统的整体框架，下面为了让大家更好的了解系统的运作方式，对其中的几个关键的 Agent 模块进行进一步介绍。

4.3.2. Prompt Agent

Prompt Agent 负责 Prompt 的编写工作，是模型调试环节最重要的模块之一，对模型效果起到了很关键的作用。自探索大模型应用以来，就在Prompt工程上进行了若干探索，结合应用经验，构建了Prompt框架。把一个Prompt拆分成了 “立角色 + 述问题 + 定目标 + 补要求” 这四个部分，并在其之上引入了统一的研发流程，实现了Prompt编写的框架化。

我们基于这套统一的的研发流程，建立了Prompt Agent，可以根据用户需求自动完成 Prompt 的编写。包含Prompt模版中各个部分的编写和整体Prompt的优化重写，在内容和格式上均对Prompt提供质量保障。

要说明的是，Prompt 是模型效果提升的一种方式，即：通过影响模型的输入，让模型获得更好的应用效果，而并非仅仅是一段“文本”。我们前文中所有的描述都是以 “任务” 维度进行的，而一个 “任务” 可能不止包含一次模型推理，可能由多次模型推理构成，而每次模型推理都有对应的输入，也就对应着各自推理阶段的 Prompt。因此，Prompt的数量应该与模型推理的次数一致，而并非一个任务只包含一个。

任务的拆分则与 “CoT” 技术相关，与传统的直接输入到输出的映射不同，CoT通过将任务拆分为多个环节提升模型的效果，即：输入 ——>思维链——> 输出。这种方式是目前证实，提升模型推理能力最有效的手段之一，GPT-o1 就是通过强化学习与CoT的结合实现了模型在推理能力上的巨大提升。而这一过程可能是隐含与模型单次推理内的，也可能是显性表现在多次模型推理的编排上的。

我们应用这种思想，首先对任务的思维链进行拆分，将任务拆分为多个推理环节，并针对各个推理环节生成prompt，以此提升模型在任务中整体的应用效果，同时提升模型的稳定性和可控性。

为了不造成额外的成本，并保证工具在任务上的通用性，任务拆分同样会由Agent完成，不需要用户额外介入。在Agent将任务拆分为多个阶段后会完成各个阶段的Prompt编写，最终产生任务的整体Prompt及调度流程。

4.3.3. 能力调度 Agent

除Prompt的编写外，对模型效果影响最大的就是各种额外能力的引入了。这类能力在定位上，与模型自身的推理相独立，但可以在模型推理的各个环节产生作用，其中最具代表性的就是 “RAG” 技术。

“RAG” 已经从行业的发展趋势，变成的行业的共识，通过对文档的检索和生成为大模型补充来自外部的相关数据与上下文，通过数据的方式引导大模型生成正确的回答，并弥补大模型知识的不足。类似这样的技术还在不断的发展当中，且针对具体的业务场景，用户可能需要用到更加定制的外部能力，因此我们对这一层进行了抽象，将各个能力作为 "子Agent" 作用于模型推理的各个阶段，并通过调度Agent进行能力的调用，通过这种方式提升工具的可扩展性。

目前的能力调度主要作用于模型能力的3个阶段

1. 前处理阶段：事前对用户输入的数据进行处理，以便让大模型更好的理解，并在其之上完成推理，包含的能力类型有：

a. 数据解析：对于特别复杂的数据，或包含内容较多的数据，需要事先对数据进行理解，如：需求文档，多模态数据，大段长文本。通过文本理解，文本总结，关键词理解 等方法，对数据进行分析，以便让模型更好的理解。

b. 数据格式化：按照指定格式对数据进行整理，可以结合Prompt让模型更有针对行的利用数据，提升模型效果

c. 异常数据检查：事先发现异常的输入数据，避免对模型造成误导，提升模型的稳定性

2. 模型推理阶段：影响模型的推理过程，以求获得更好的推理效果，包含的能力类型有：

a. Prompt修改：在 prompt 中增加额外的补充信息，或修改 prompt 内容，提升模型的效果。RAG 就是这类能力的典型代表，通过引入额外的知识数据或上下文数据，弥补模型在数据上的不足。

b. 要求限制：通过认为的限制条件，提升模型效果的可控型，典型的黑/白名单，输出字数限制，就属于这项能力的范畴。

3. 后处理阶段：对模型的输出结果进行处理，在格式和内容上贴合应用的需求，并进一步提升输出结果的稳定性，包含的能力类型有：

a. 结果格式转换：对输出结构的格式进行限制，例如转换成规定的json格式，以便在业务场景中应用。

b. 结果内容转换：模型输出的内容可能包含不需要的部分，或不直接包含我们预期的内容，分类任务就是其中的典型场景，我们需要将模型输出的内容转换为对应的类别。

c. 结果校验：为了提升模型输出的准确率，可以引入额外的测试/校验逻辑，例如常用的反思机制，可以有效的提升模型输出的稳定性。

这其中的每项能力我们均当作一个agent对待，在底层结构上进行统一，由决策，规划，执行，结果组成（如前文中介绍），规范各项能力的开发方式和应用方式，提升能力的可拓展性。在能力的应用上，我们具备 “Agent自主调度” 的能力，也支持人为干预的方式，可以在各个环节内调用对应的能力。

用户可以根据需求自己完成各个类型能力的定义，在某种程度上，每一个可服用的“模型应用”都可以成为一个通用的外部能力，被应用在其他的模型能力上，这些能力的增加也构成了工具成长的潜力，也是我们后续要继续探索的重点方向之一。

4.4. 调试 & 优化

模型效果提升不是一个一蹴而就的单向工程，需要我们在实验的应用中不断优化提升，其依据大多来自：

1. BadCase 数据：实验和应用数据是优化最主要的输入，尤其是其中的 BadCase，是模型效果提升的关键依据，通过对Bad Case 的分析和修复，不断提升模型的应用效果。
2. 规则要求：除数据外，我们可能还会引入一些规则或要求，基于人为经验对模型效果进行分析，并进行干预，以此提升模型效果。
3. 基础能力升级：除任务维度的优化外，模型系统基础能力的提升也会影响模型的应用效果，尤其是在领域快速发展的时期，底层模型或技术的迭代，可能会对应用效果带来质的改变。

如前文所述，为了提升模型研发效率，降低模型研发成本，我们同样采用Agent驱动的方式辅助完成调试优化工作。

如上图所示，调试模型效果的途径有 2 种：

1. Agent驱动的半自动方式：将自然语言和数据输入给 Agent，Agent将进行分析和理解，形成修改意见传递至任务的“综合调度Agent”，再传递至模型的各个环节进行修正，其输入主要有2类：

a. BadCase 数据：在一轮模型研发完成后，系统会在数据集上进行评测，产出BadCase数据，BadCase 数据会作为模型调试的主要输入，传递至下一轮迭代当中。模型上线应用后产生的数据同样会进入这个自迭代的闭环当中，用数据自驱动的方式完成模型优化。

b. 人为规则要求：除数据自迭代外，用户可以自行对模型效果进行分析，并依据经验对模型的要求或规则，为了提升这些要求对模型效果的可控性，我们依据要求类型提供了填写模版（如：输出格式类要求，特殊处理类要求，过滤类要求），并研发了单独的模块进行处理，以提升模型的可控性。这些要求和规则仅需通过自然语言描述即可。同时在规则的实现上，我们依旧沿用前文中提到的agent架构，让要求独立可插拔，以此支持要求的拓展及上下线等操作。

2. 修改输入的人工方式：在本章的前几节中，我们介绍了任务的主要输入，包含建模部分的定义及任务相关的数据集，这些内容由用户负责，是用户控制任务的主要途径。同时，在 “能力调度” 模块中，部分能力agent也需要用户额外的输入，例如与RAG能力相关的知识库。在调试模型效果的过程中，用户可以通过修改这些输入来直接完成对模型的影响，可能包含：

a. 修改定义：定义会直接影响任务Prompt以及整体的推理流程，可以帮助模型理解任务，规范模型的行为，是非常重要的输入之一。

b. 增加数据：数据是模型调试和训练的依据，结合模型现有的问题补充对应的数据，是很有效的优化手段。

c. 扩充知识库：在外部能力调度中，RAG对模型效果起到了很大的影响，尤其是在专业领域内应用时，可以弥补模型专业知识不足，业务知识不足的问题，并可以进一步约束模型的输出，根据任务补充相应的知识库可以很好的提升模型在任务上的应用效果。

我们可以通过以上方法，尽量低成本的进行模型效果的调试，但即便我们引入了相应的Agent能力和数据驱动的方法，这一步骤也十分依赖开发人员的经验和专业能力，如何帮助用户更好的完成这一过程是我们还需长期摸索的话题。

五、最佳实践

目前，我们的工具已经完成了初版研发，并在实际工作中应用落地。结合近1年多时间里我们在质效领域的探索，我们应用工具完成了多项模型能力的研发落地，在保证效果的前提下获得了大幅的效率提升和成本降低，下面我详细介绍一下我们目前的应用成果。

5.1. 研发效率提升最佳实践

5.1.1. 效率低带来的痛点

在过去一年多里，我们在业务中持续探索模型能力和质效工作的结合，已完成了8项模型能力的研发落地，覆盖了 “用例域”，“缺陷域”，“代码域” 中的多个痛点场景。即便各项模型能力都在业务得到的应用落地，并切实取得成效，我们距离业务的质效诉求还是有较大差距。

业务质效诉求贯穿产研的各个环节，需求量大，能力繁杂，业务分隔度高，仅 “用例域” 的单项任务就可能产生几十个模型能力点。相比之下，目前 1 项模型能力从研发到落地就需要 “1人月” 的研发成本，造成了产能和需求的巨大差距。面对这种现状，我们急需提升模型研发的效率，提升对业务需求的覆盖度。

5.1.2. 实践成效

在大模型和 “缺陷域” 质效问题结合的探索中，业务希望可以引入模型能力，对 “用户反馈” 进行检查，发现 “用户反馈” 中存在的严重问题，并进行特殊关注，确保严重问题的跟进解决。通常 “用户反馈” 问题的严重程度由 2 方面判断：“反馈量”，“反馈内容”。反馈量可以很直观的获得，但反馈内容的严重程度则依赖人为经验判断，这就存在 “反馈量小，反馈内容严重” 的问题被遗漏的风险。

根据业务经验，在业务中，目前已确定了 “10+” 种需要监控的严重问题，如：隐私相关问题，白屏相关问题，消息无法导入问题，聊天记录损坏问题，等等。我们需要构建模型能力，对这些检查点进行覆盖。

通过工具的引入，我们在 “2周” 内就完成了 “2项” 模型能力的研发（“隐私相关问题”，“白屏相关问题”），并通过工具完成了能力的部署应用，成功将模型能力从0到1的拓展到了“用户反馈”相关的问题中。每 1 项模型能力的研发成本从 “1人月” 降低至 “1人周”，且准确率均保持在 80% 以上，效率提升数倍。

5.1.3. 效率提升详情

通过工具的应用，我们将本需要 “1人月” 完成的工作压缩至了 “1人周”，这得益于工具对模型研发环节的框架化和工具化，具体表现在：

1. 建模框架化：通过前文中提到的 “建模” 模版，我们明确了定义任务所需要填写的内容，指导完成研发前的定义和数据准备工作，通过明确目标的工作流程提升这个阶段的工作效率（由 “2天” 提升至 “1天”）
2. 辅助数据标注：系统具备借助强大闭源模型（混元，GPT）辅助数据标注的能力，通过模型进行数据粗标，再人工进行确认，大幅提升了数标注的效率（“2天” 提升至 “0.5天”）
3. Prompt 编写：通过对 Prompt 编写环节的工具化，以及Agent能力的建设，我们无需人工进行编写和反复调试，仅需输入 “建模定义” 和 “数据” 即可应用 Agent 完成prompt的编写工作。（由 “3天” 提升至 “0.5天”）
4. 能力调用：工具对多种能力进行了封装，并通过Agent能力完成各项能力的自主调用，省去了能力开发和引入的成本。在本项任务中，工具引入了：RAG 知识库，CoT，格式标准化，反思，专用词解释，等多项能力，并结合任务状况进行调用，无需进行二次开发（由 “1周” 提升至 “1天”）
5. 插件调用：除了模型能力外工具内还封装了一些插件，可在研发流程的各个阶段进行调用。在本项任务中，只用了 “腾讯文档读写插件”，“Tapd数据读写插件”，“数据格式转换插件”，避免了二次开发的成本。（“1天” 提升至 “1小时”）
6. 上线部署：工具提供模型能力的自动部署能力，可通过配置产生接口供用户调用。此外我们还提供多种部署方式：如结合用户提供的脚本完成定时任务的部署；在本项任务中，我们通过工具将能力部署为定时任务，定期对用户反馈数据进行检查。（由 “3天” 提升至 “1天”）
7. 流程串联：研发框架除提升各个单一模块的效率外，还对模型研发的整体了流程进行了规范化和串联，提升了研发过程的流程效率（由 “3天” 提升至 “1天”）
8. 效果调试&优化：系统支持多种调试方法，并引入了相应的Agent能力和数据驱动的方法，半自动的辅助完成模型效果的调试。相较于传统基于评测结果的人工调试方法，大幅提升了调试效率（由 “1周” 提升至 “2天”）

5.2. 研发成本下降最佳实践

5.2.1. 成本高带来的痛点

在我们探索大模型和质效工作的结合中，大多模型研发工作均有开发人员承担，但质效领域具备较高专业深度和广度，且与业务关系紧密，具备很高的业务复杂度。模型开发人员在专业和业务上均存在不足，导致模型开发与领域人员的诉求存在差距，不仅增加了模型开发的成本，还降低了模型实现的效果。

如前文所述，大模型能力的领域化，不应当仅仅局限于能力的开发，而应当赋予领域专业人员应用模型的能力，是一个 “授之以渔” 的过程。为了更好进行模型能力的领域化，我们希望通过工具，让领域内的专业人员也可以完成模型能力的研发。

5.2.2. 实践成效

在大模型和 “用例域” 质效问题结合的探索中，“用例检查” 是其中应用最广效果最显著的能力，通过对测试用例的检查，发现测试用例中存在的问题，以此提升用例质量，解决因用例原因导致漏侧引发的线上问题。目前，我们已经完成了6个检查点的建设，可以有效发现用例中存在的问题，并推动修复，切实保证已覆盖的检查点无相关线上问题。

但测试用例的检查点众多，且存在业务区分，结合 “用例checklist”业务已经积累了200+个检查点，若持续采用集中式的孵化模式，难以满足业务诉求。因此，希望通过工具的引入，让业务的质量同学也可以完成检查点的开发，共同在领域中建设模型能力。

通过工具的引入，我们与质量同学合作，在 “2周” 内就完成了 “2项” 用例检查能力的研发（“杀进程用例缺失检查”，“写操作用例缺失检查”）。在没有模型开发人员介入的情况下，仅由 “质量同学” 进行输入，即完成了能力的研发，准确率均在 80% 以上。

通过如上定义，及少量数据 即可完成模型能力的研发。在调试过程中，结合模型的评测结果，也可低成本的，通过 “修改定义” 和 “补充数据” 完成模型效果的提升。同时，我们还针对用例检查的应用场景，提供了更方便的部署方式，除提供 API 接口外，检查能力可以一键上线至 “智能用例平台”（用例检查的应用平台），并可自动创建定时任务，定期对用例进行检查。通过这种方式，我们全链路的降低了模型能力的研发成本，在保证质量的前提下，让质量人员也可以完成模型能力的研发。

5.2.3. 成本降低详情

如上图中所示的模型研发流程，工具为用户自助完成了大量的研发工作，用户仅需完成任务维度的输入，即可完成模型能力的研发，从而大幅降低了模型研发过程的成本和技术比例，其中：

1. 用户负责：

a. 问题定义：确定检查点定义

b. 问题建模：将检查任务翻译为分类任务，并填写对应的建模模版

c. 原始数据采集：采集任务需要用到的 “测试用例” 数据

d. 数据清洗/计算：统一 “测试用例” 数据结构，无需额外的清洗/计算

2. 工具与用户协同负责：

a. 数据标注：应用 “混元” 模型对数据进行粗标，再有人工确认，完成标注工作

b. 调试&优化：工具利用 badcase 数据 及 人为归纳的问题 自主对模型系统进行优化，最终保证准确率达到应用标准（>80%）。

3. 工具负责：

a. 模型调试：模型阶段的所有工作均有工具负责，在保证效果的前提下调度工具中的多个Agent系统，完成模型能力建设

b. 效果评测：在数据集上自动产出评测结果，计算 准确率，召回率，精确率 等指标。

c. 部署运维：工具自动完成模型能力的上线，除提供 API 接口外，检查能力可以一键上线至 “智能用例平台”（用例检查的应用平台），并可自动创建定时任务，定期对用例进行检查。

六、写在最后

6.1. 从 “Prompt框架” 到 “模型研发工具”

在一年多的模型应用探索当中，我们进行了多项模型能力的研发和应用，期间持续对模型的应用效果提升和研发流程进行研究和实践。此前的很长时间里，我们都认为 Prompt 是模型应用的钥匙，对模型的应用效果起到决定性的作用，如何又快又好的完成Prompt，是模型应用研发的关键。

但随着领域的发展和研究的深入，我们越来越能感受到 Prompt 并不是模型的全部（虽然依然很重要），尤其是在 Agent，MultiAgent 技术持续发展的今天，Prompt在模型效果中所占的比重越来越小。就如本文开篇提到的，模型应用相关的技术对模型应用效果是否重要，但 “Prompt工程” 只是众多应用技术的其中之一。

于是，我们把目光放大到了整个 “模型研发流程” 当中，而不仅仅关注某项单一的技术，模型研发的 “第一性” 就是 “提升应用效果”，而非不断的优化单一环节的能力，通过对研发框架的优化不断提升模型的应用效果，才是我们应当做的正确的事。

6.2. 总结 & 后续规划

目前，我们初步完成了工具的研发和应用尝试，希望可以通过工具带来的效率提升和成本下降，进一步推动大模型的领域化。大模型被认为是通往 AGI 的道路，但现存的模型开发模式不仅没有像通用化发展，反而在近一步限制模型的通用性以求得其在领域中的稳定性，这种偏闭源的开发模式，无论是在效果上，还是在效率上，都不符合大模型发展的趋势。我们希望可以通过我们的工具，让领域中的人都可以加入到模型能力的研发上，建立更开源的开发模式，让领域中的人具备使用大模型的能力，才是真的领域化。

在技术上，本文开篇论述了一些对趋势的观察，这些曲线未必都正确，但模型应用层技术的发展一定是领域中不可或缺的一部分，且对于模型的应用效果而言，会起到越来越重要的作用。而目前，我们应用层建设的成熟度还远远不够，持续提升 “MultiAgent System” 的能力，不断引入更多的模型能力，丰富应用插件，并和用户形成更好的协作模式，都是未来要努力的方向。

本文中叙述的观点多有主观判断的成分，仅是个人结合应用研发经验的若干想法，大模型相关技术还在持续的高速发展当中，非常期待和大家交流。

七、参考文献

1.DSPy: https://dspy.ai/learn/programming/modules/
2.MetaGPT: https://github.com/geekan/MetaGPT/blob/main/README.md
3.AutoGen: https://microsoft.github.io/autogen/dev/user-guide/agentchat-user-guide/quickstart.html
4.OpenAI O1原理逆向工程解: 
https://blog.csdn.net/qingkahui24689/article/details/142547941