大模型开发工作手册指南

一、写在前面

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

“大模型” 爆发至今已有 2 年的时间，行业持续火热，模型基础能力持续升级。2024.9. OpenAI

发布的 “O1” 模型为领域再一次带来了新的突破，期间多模态也持续展现了令人惊喜的发展。于此同时，成本的降低与效率的提升也在持续进行，让大模型融入到了更多的场景之上。但相对的，在模型基础能力突飞猛进的背景下，“模型应用” 的发展就显得相形见绌，从 “领域模型” 到 “AI原生应用

” 再到 “AI-Agent”，这些应用层的概念均获得了极高的热度，但时至今日，人们也没有看到新时代的到来，AI应用并没有如人们预期的一样爆发，其原因是什么呢？

img

我们可以从 “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的方式，帮助用户做一些工作，首先我们先来看看大模型应用研发的过程：

img

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

1. 建模：首先我们要对问题进行定义，明确需要模型为我们做什么。从业务视角看，我们要把模型能力引入到业务中，首先要把问题定义清楚，这是模型应用的关键，类似传统研发中需求的产出，只有明确了需求和目标，才能进行后续的研发和调试。同时，我们需要将业务问题翻译为技术语言，用AI思路对问题进行转换，也就是完成问题建模的过程。这个过程往往容易被忽略，但对后续研发十分重要（最简单的：模型输入什么？模型输出什么？）
2. 数据：数据是大模型的3大关键要素之一（算法，算力，数据），与任务对应的数据是模型的主要输入，是模型训练和调试的主要依据，应尽可能覆盖任务的假设空间

1. 。数据标注任务是其中最苦难的环节，很多情况下，我们仅能找到数据的 “输入” 部分，而无法得到数据的 “输出”，此时就需要我们进行标注，在今天的大模型时代，AI标注成为了常用的解决方案，后文还会展开介绍。
2. 模型：在前面的两个步骤中，我们准备好了模型的输入，下面就需要根据这些输入进行具体的模型调试，优化模型在任务中的效果。这是模型研发过程的主要工作，可能会分为多个部分：

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

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

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

” 等等，以此进一步提升模型的效果。

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

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

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

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

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

1. 建模：

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

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

1. 数据：

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

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

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

1. 模型：

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

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

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

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

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

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

1. 效果评测：在模型调试过程中，我们进行了多次的模型效果评测，计算模型在数据集

上的“准确率”，“精确率”，“召回率

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

3.3. 我们要做什么

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

img

1. 建模：

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

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

1. 数据：

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

读取数据。

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

c. 数据标注：标注是数据准备阶段最困难的工作，我们往往仅能批量获取任务输入部分的数据，而无法获取任务的输出部分，若依赖人工标注则往往会产生较高的成本。工具会提供一定的AI标注能力，事前应用能力较强的闭源模型

（混元，GPT4）对数据进行粗标，再结合人工确认，低成本的和用户共同完成数据标注工作

1. 模型：

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

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

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

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

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

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

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

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

1. 部署&运维：

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

a. API接口

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

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

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

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

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

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

3.4. 总结

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

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

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

4.1. 建模

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

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

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

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

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

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

img

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

4.2. 数据

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

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

img

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

1. S3框架：通过使用大型语言模型

来缩小小型模型在合成数据集和真实任务数据分布之间的差距。实验结果表明，S3框架在多个自然语言处理（NLP）