前言

AI 技术如何推动业务智能化？近期这一主题在团队内部引起了广泛关注。无论是公司战略还是研发一线，都给予了这一议题相应的重视。间断性的探索了一个月，回想自己当初刚接手时的雄心壮志，还是感慨于自身眼界之浅显，并未具备超前的眼光提前洞察生成式 AI 的复杂度和挑战。过程中解决了一些问题，也走了不少弯路。借着最强推理模型 OpenAI o1 的发布，跟大家聊聊作为执行层的我们，如何从实际应用场景出发，深入思考我们可以在其中承担的角色和责任。

实际场景的应用

背景

为服务内容生产，提升高考听力模拟题的生产效率是一个急需攻坚的项目。由于命题组老师稀缺，期望可以用大模型来生产听力题，再让老师介入遴选和审核。难点：容错率低，内容精准度要求高，内容质量评价维度多元等。

基础门槛

如果你不了解 Agent 的基础概念，请先花一分钟时间学习：什么是 AI Agent？文中提到的常见名词不做过多解释。另外推荐万字科普GPT4为何会颠覆现有工作流有助于你读懂下文。

单智能体（Agent）的局限性

单 Agent 在任务定义明确且对外部反馈依赖较低的情况下表现出色，但由于大部分大语言模型（Large Language Model, LLM）的上下文（Context）限制，单 Agent 设定过于复杂的人设逻辑难以避免生成结果的不可控，不满足我们低容错率预期。建议综合多个不同功能的 Agent 优点，通过多个 AI Agent 一起工作，以构建比单个 Agent 更好的解决方案。可以使用单 Agent 模式完成 PoC，长期来看还是需要构建 Multi-Agent 工作流。

Multi-Agent 工作流模式

Multi-Agent 在需要多方协作和多路径并行处理任务的环境中显示出其独特的优势，但实现难度较大。其中以生成式与判别式模型的协同使用为案例。

生成式与判别式的协同使用

生成式模型可以用于生成候选输出，而判别式模型则用于评估这些输出的质量，如生成对抗网络（GAN）在试题生成任务中，生成模型（如GPT）可以生成多种文本候选，而判别模型（如BERT）可以对这些候选进行评分，选择最优的输出。同时生成式模型可以生成合成数据来扩展训练集，尤其是在标注数据稀缺的情况下。生成的合成数据可以用于训练判别式模型，从而提升其泛化能力，同时可以结合工程能力（如 ASR / TTS）来实现多模态输入输出。

评价体系的建设

上文提到期望通过判别模型来构建一套专家评价体系，当然在实际落地过程中就遇到了模型验证时很难找到合适人员来验证模型水平的困境，找用户验证试题质量基本不可行，找命题组专家验证，我们就需要很高水平的专家来把关，但这样的专家资源是非常稀缺的。所以从业务层面，业务人员需要对大模型的基础原理有深入的了解，知道怎样评估模型落地的效果。工程师则需要深入到一线生产环节，比如说高考试题生产的研发人员就要融入命题组老师的工作环境，理解老师命题的过程，并在这一过程中自己对比模型生成的结果与老师的评价，再去请教老师细节问题。通过这类方法，可以比较好地弥补业务和技术之间的鸿沟。而且大模型出现幻觉的几率是一定存在的，那么工程师还要了解怎样的错误是业务侧不在乎的，哪些错误是业务侧不能容忍的，而不是只从概率的视角来看待这些幻觉问题。例如英语听力试题评价标准包括：主题贴合、题型准确、小题数量符合预期、问答回合准确、文本词数准确、解析符合预期、选项符合要求、考查点准确、文本难度符合预期等。

提示词（Prompt）

（2024/9/13 补充）注：由于时代变化的太快了，笔者甚至还没写完这篇文章，OpenAI 的推理模型就横空出世。快思考大模型的 Prompt 技巧请参考提示工程指南。

在以 GPT 为代表的快思考大模型时代，你可能还需要引导智能体将复杂的任务分解为简单的步骤，再引用每个步骤的中间输出，直到今日 OpenAI o1 的发布。 OpenAI o1 是经过强化学习训练来执行复杂推理任务的新型语言模型。特点就是，o1 在回答之前会思考 —— 它可以在响应用户之前产生一个很长的 内部思维链。

针对 OpenAI o1，OpenAI 给出的最佳写法是：

保持提示简单直接：模型擅长理解和响应简短、清晰的指令，而不需要大量的指导。
避免思路链提示：由于这些模型在内部进行推理，因此不需要提示它们“逐步思考”或“解释你的推理”。
使用分隔符来提高清晰度：使用三重引号、XML 标签或章节标题等分隔符来清楚地指示输入的不同部分，帮助模型适当地解释不同的部分。
限制检索增强生成 (RAG) 中的附加上下文：提供附加上下文或文档时，仅包含最相关的信息，以防止模型过度复杂化其响应。

检索增强生成（RAG）

我们利用大模型做内容生成或是知识问答，必然需要与我们行业知识图谱关联。这其中涉及大量的微调来提升数据的有效性、问答的准确性和减少智能体幻觉。文本抽取相关涉及特定格式抽取、实体抽取、要素提取等场景。例如关联题卷库后台的真题数据就需要抽取富文本标签、提取知识点、难易度、题干、选项、解析、答案等标签。

角色

由于看到了某些伙伴的迷茫与焦虑，笔者期望从团队层面梳理出一个体系，找到推进智能化业务转型在各个环节需要具备的知识，大家找出自身的盲区，再去学习补充。

AI Product Manager

产品经理必须了解 AI 大模型的基础原理，在大模型领域大家都缺乏实战经验，单从生成式模型来考虑，任何 LLM 均有自身能力边界，同时可能存在不可提前预见的能力缺陷。在这个前提下，必须优先完成业务场景 PoC，而不是先做研发落地实现，否则投入将付诸东流。

Prompt Eengineer

提示工程（Prompt Engineering）关注提示词开发和优化，帮助用户将 LLM 用于各场景和研究领域。掌握了提示工程相关技能将有助于用户更好地了解大型语言模型的能力和局限性。工程师要懂场景、产品设计、用户体验。

数据工程师

上文中提到 RAG 就离不开数据清洗与数据分析，需要结合工程能力将行业知识图谱与向量数据库关联，需要分析大量数据来判断解决方案是否可行。

——————

当然以上角色在前期完全可以由单人包揽，当前不同语言之间的技术门槛在不断下降，能力模型单一的工程师终将失去竞争力。祝愿所有读者未来都会成长成既精通业务逻辑，又掌握先进技术的复合型人才。