大模型 Agent 实战工作坊大纲

大模型 Agent 实战工作坊大纲

时间安排 (总时长:3小时)

第一部分:Agent 概念与落地现状 (40分钟)

  • 主题内容与互动:

幻灯片1: Agent的定义与分类

  • Agent的基本定义:能端到端地完成一个或者多个任务,并达到人类可用的程度
  • Agent的主要特点:
    • 能使用工具(如操作文件系统、浏览器、数据库)
    • 能自主规划应该要做什么
  • 满足其中一个特点往往就会被认为是Agent
  • Agent的定义非常宽泛
逐字稿 大家好,欢迎参加大模型Agent实战工作坊。在正式开始之前,我们先来明确一下什么是Agent。 Agent的基本定义是:能端到端地完成一个或者多个任务,并达到人类可用的程度。这个定义非常宽泛,涵盖了从简单到复杂的各种智能系统。 Agent具有两个主要特点: - 首先,能使用工具,例如帮你操作文件系统、浏览器、数据库等 - 其次,能自主规划应该要做什么,具有一定的决策能力 值得注意的是,只要满足这两个特点中的任何一个,往往就会被认为是Agent。在实际应用中,不同类型的Agent包括客服Agent、研究Agent等,都是为了解决特定领域的问题而设计的。

Picture1

幻灯片2: Agent的核心组件

  • 感知(Perception):获取和理解环境信息
    • 往往由人输入,或者由 Agent 调用工具完成
  • 决策(Decision):基于信息做出判断和规划(可选)
    • 往往由大模型完成,偶尔会有人的接入进行二次确认
  • 执行(Action):实施决策并影响环境(可选)
    • 一般由大模型提供工具调用所需要传入的参数,并通过 API 调用
  • 反馈(Feedback):评估行动结果并调整策略
    • 一般和感知是类似的,但可能只在有规划能力的 Agent 里出现

决策和执行是可选的,如果模型只处理文本,是可以不需要决策和执行的。

逐字稿 一个完整的Agent通常包含四个核心组件: 感知(Perception):获取和理解环境信息。这可能是通过文本输入、图像识别、语音识别等方式实现的。通常感知由人工输入提供,或者由Agent调用专门的感知工具来完成。 决策(Decision):基于信息做出判断和规划。这是Agent的"大脑",决定下一步行动。决策环节主要由大模型完成,在关键决策点可能会引入人类进行二次确认。 执行(Action):实施决策并影响环境。这可能是生成文本、调用API、控制设备等。通常由大模型提供工具调用所需的参数,然后通过API调用执行具体操作。 反馈(Feedback):评估行动结果并调整策略。这是Agent学习和改进的关键。反馈机制与感知类似,但主要出现在具有规划能力的Agent中,用于评估和调整后续行动。 需要注意的是,决策和执行是可选的。如果模型只处理文本,不需要与外部系统交互,那么可能不需要明确的决策和执行步骤。比如写小说的 Agent

Picture2

幻灯片3: Workflow型Agent vs 自主型Agent

  • Workflow型Agent:预定义的执行路径,步骤清晰,类似流水线
    • 特点:可控性高,准确率可预测,容易调试
    • 示例:自动化邮件分类与回复系统,数据处理流程
    • 重点:执行路径是提前规划好的,通常没有循环或反馈环
  • 自主型Agent:具有规划、反思能力,可自主决策执行路径
    • 特点:灵活性高,但准确率难以保证,调试复杂
    • 示例:复杂问题求解助手,创意内容生成系统
    • 重点:执行路径由大模型临时生成,通常包含反馈”环”的结构
逐字稿 在当前的技术发展阶段,Agent主要可以分为两大类:Workflow型和自主型。 Workflow型Agent具有预定义的执行路径,步骤清晰,类似流水线。它的特点是: - 可控性高,每一步都有明确的预期输出 - 准确率可预测,整体成功率更容易保证 - 容易调试,问题可以定位到具体步骤 典型例子包括自动化邮件分类与回复系统,或者数据处理流程。 相比之下,自主型Agent具有规划、反思能力,可以自主决策执行路径。它的特点是: - 灵活性高,能应对多变的场景 - 准确率难以保证,特别是在复杂任务中 - 调试复杂,错误原因难以追踪 自主型Agent的例子包括复杂问题求解助手或创意内容生成系统。 两者最关键的区别在于执行路径的决定权:Workflow型Agent的路径是开发者提前规划好的,而自主型Agent的路径是由大模型在运行时临时生成的。另外,自主型Agent通常包含反馈"环"结构,能够根据执行结果调整后续行动,而Workflow型Agent一般是线性执行的。

Picture3

幻灯片4: 当前落地现状分析

  • 落地的真正含义:
    • 落地意味着为用户带来实际价值
    • 如果最终产出不可用或需要大量修正,则不算落地成功
    • 例如:AI代码生成如果错误百出,debug时间超过手写时间,则无实际价值
  • Workflow更易落地的原因:
    • 每个步骤的准确率可控,整体成功率更高
    • 错误可追踪、可定位、可修复
    • 用户体验可预期,不会产生”意外”行为
  • 自主Agent的落地挑战:
    • 基座模型能力限制导致连续决策准确率低
    • 错误累积效应:每步95%的准确率,连续5步后整体准确率仅77%
    • 规划与执行分离的难题
    • 自我纠错能力有限:模型难以可靠地识别并修复自身错误
      • 例如:错误的SQL语句通常需要人工介入修复
      • 即使模型能识别部分错误,修复能力也必然低于识别能力
      • 反馈机制可能帮助但不能根本解决问题
逐字稿 在讨论Agent落地前,我们需要明确"落地"的真正含义。落地意味着什么?它意味着为用户带来实际价值。如果用户觉得最终的产出不可用,则不算落地成功。举个例子,如果AI根据PRD写代码,但写出的代码错误百出,用于debug的时间甚至超过了手写代码的时间,那么这个场景显然没有落地成功。 在实际应用中,我们发现Workflow型Agent比自主型Agent更容易落地,原因有几点: 首先,Workflow型Agent的每个步骤准确率可控,从而保证整体成功率更高。想象一下,如果一个10步流程的每一步准确率都是95%,那么整体成功率就是0.95^10,约59%。而自主Agent可能需要更多步骤,整体成功率会更低。 其次,Workflow型Agent的错误可追踪、可定位、可修复。当出现问题时,我们能清楚地知道是哪一步出了问题,而不是面对一个"黑盒"。 第三,用户体验可预期,不会产生"意外"行为。用户知道Agent会做什么,不会做什么。 自主Agent落地面临的主要挑战是: - 基座模型能力限制导致连续决策准确率低 - 错误累积效应明显:每步95%的准确率,连续5步后整体准确率仅77% - 规划与执行分离的难题:模型可能规划得很好,但执行时遇到意外情况难以应对 - 还有一个关键限制是模型自我纠错能力有限。我们观察到,大模型修复自身错误的能力是受限的。例如,如果模型第一次生成的SQL语句有错误,它在后续步骤中未必能自己正确修复。这是因为模型识别错误的能力不是100%,所以修复错误的能力必然更低。即使我们引入反馈机制,也不能从根本上解决这个问题,只能在某种程度上缓解它。

Picture4

幻灯片5: Agent的交互形式

  • 对话式交互:类似聊天界面的交互方式
    • 特点:灵活性高,适合探索性任务
    • 示例:ChatGPT、Claude等聊天助手
  • 嵌入式交互:集成到现有应用中的功能
    • 特点:上下文明确,触发简单,用户体验流畅
    • 示例:PPT的Designer功能,一键生成设计建议
    • 示例:Teams会议的自动总结功能,无需输入prompt即可生成会议摘要、要点和待办事项
  • 混合式交互:结合对话和嵌入式体验
    • 特点:兼具灵活性和便捷性
    • 示例:Word中的Copilot,可接受特定指令也可自动提供建议
  • 人机协作式交互:设计合理的人工介入点
    • 特点:结合AI效率与人类判断力,提高整体可靠性
    • 关键设计点:确定人类在何时进行校验与选择
    • 示例:文档生成后由人类审核关键点,代码建议需人工确认实施
逐字稿 Agent与用户的交互形式主要有几种类 混合式交互,结合了对话和嵌入式体验。它兼具灵活性和便捷性。例如Word中的Copilot,既可以接受特定指令,也可以自动提供建议。 不同的交互形式适合不同的应用场景,选择合适的交互形式对用户体验至关重要。

Picture5 png

幻灯片5.5: 人机协作式Agent设计

  • 为何必需:
    • 模型能力限制要求人类参与
    • 最终决策责任需人类承担
    • 人机互补提升整体效果
  • 关键设计思路:
    1. 关键节点确认
      • 高风险操作前的人工审核(如文件删除命令)
      • 方向性决策的人工确认(如文章大纲审核)
      • 不可逆操作前的双重确认机制
    2. 最大化效率
      • 批量处理与一次性确认(如PPT整体设计审核)
      • 避免频繁打断工作流(减少上下文切换成本)
      • “流水线”思维优化人机交互节奏
  • 最佳实践:
    • 明确划分AI与人类决策边界
    • 设计友好的确认界面,降低认知负担
    • 从用户反馈中持续优化交互点设计
逐字稿 在设计实用的Agent系统时,我们必须正视一个现实:当前模型的能力有限,要让Agent真正落地,必须精心设计人机协作的交互形式。 人机协作的核心问题是:"人类应该在什么时候进行校验和选择?"针对这个问题,我们有两种关键设计思路: 第一种是"关键节点确认"。这适用于高风险或高重要性的决策点。例如,当Agent准备执行可能删除文件的命令时,应该先获得人类确认。或者在内容创作中,Agent设计好文章大纲后,应该让人类确认方向正确后再继续填充细节。这种方法特别适合那些错误成本高或方向性决策的场景。 第二种是"最大化效率"设计。这种方法避免频繁中断工作流,而是在自然断点处集中进行人工确认。就像一个PPT生成Agent,与其让用户对每一页设计都进行确认,不如让模型完成整体设计,再由人类一次性进行审核和调整。这种"流水线"思维优化了整体效率,减少了上下文切换的认知成本。 在实际应用中,最佳实践是明确划分AI与人类的决策边界,设计友好且不造成决策疲劳的确认界面,并通过持续的用户反馈优化交互点的设计。记住,好的Agent设计不是最大化自动化,而是找到人机协作的最佳平衡点。

Picture6 png

幻灯片6: 案例分析:Microsoft Copilot的优缺点

  • 背景:微软推出的AI助手,承诺能完成复杂任务
  • 优点:
    • 简化了复杂的工具调用、搜索、规划、反思等步骤,用户只需提出最终任务
    • 连接了微软的诸多工具,包括Outlook、SharePoint等数据源
    • 支持上传自定义文档,使知识可以自动补充
  • 缺点:
    • 复杂指令的遵循程度不高,搜索的召回率不高,流程不透明
    • 基座模型能力不足以支撑高复杂度的自主决策
    • 缺乏有效的错误恢复机制
    • 流程和结果难以校验
逐字稿 让我们分析一个真实案例:Microsoft Copilot。它在实际使用中既有突出优势也存在一些明显的局限性。 首先,Copilot的主要优点包括: - 简化了复杂的工具调用、搜索、规划、反思等步骤,用户只要提出需要完成的最终任务即可,大大降低了使用门槛 - 连接了微软的诸多工具,包括Outlook、SharePoint等数据源,实现了无缝的信息检索和处理 - 支持上传自定义文档,使得知识可以自动补充,增强了系统的适应性 然而,它也存在几个明显的缺点: - 复杂指令的遵循程度不高,特别是多步骤任务 - 搜索的召回率不高,例如Email、SharePoint的搜索词或搜索方式不是最优的,有时无法找到用户需要的信息 - 流程不透明,用户难以了解AI是如何得出结论的 这些问题的根本原因在于: - 基座模型能力不足以支撑高复杂度的自主决策 - 缺乏有效的错误恢复机制,一旦某一步出错,整个流程就会失败 - 流程和结果难以校验,用户无法确认AI的输出是否正确

Picture7

幻灯片7: 互动环节 - 案例讨论

  • 分组讨论(4-5人一组):
    • 识别日常生活中已存在的Agent应用
    • 分析这些应用的优缺点
    • 思考改进方向
  • 讨论时间:5-7分钟
  • 汇报:每组选代表分享1-2个最有趣的发现
逐字稿 现在,让我们进行一个小组讨论。请大家分成4-5人一组,讨论以下问题: 1. 识别日常生活中已存在的Agent应用 2. 分析这些应用的优缺点 3. 思考可能的改进方向 讨论时间为5-7分钟,之后每组选一位代表分享1-2个最有趣的发现。 [等待讨论完成]

svgviewer-output (26)

svgviewer-output (27)

幻灯片8: 互动环节 - 思考讨论

  • 引导问题:”为什么某些Agent应用体验不佳?”
  • 思考框架:
    • 技术限制因素
    • 用户期望管理
    • 设计缺陷
    • 应用场景不匹配
  • 全体讨论:收集关键见解,讲师点评
逐字稿 接下来,我想引导大家思考一个问题:"为什么某些Agent应用体验不佳?" 请从以下几个维度思考: - 技术限制因素:模型能力、数据质量等 - 用户期望管理:用户对AI能力的过高期望 - 设计缺陷:交互设计不合理、错误处理不完善 - 应用场景不匹配:使用Agent解决不适合的问题 让我们进行一个全体讨论,分享你的见解和经验。 [进行全体讨论] 非常感谢大家的积极参与!通过讨论,我们看到了几个关键点: 1. 技术能力与用户期望之间存在差距 2. 许多Agent设计过于复杂,没有聚焦于真正的痛点 3. 错误处理和异常情况应对不足 4. 缺乏明确的成功指标和评估方法 这些见解将帮助我们在接下来的工作坊中设计更实用、更有效的Agent应用。 在第一部分结束之前,我想强调:成功的Agent不一定是最复杂的,而是最能解决用户实际问题的。在当前技术条件下,设计合理的Workflow型Agent往往比追求完全自主的Agent更有实际价值。 接下来,我们将进入第二部分:需求挖掘与场景分析,探讨如何发现适合Agent实现的真实需求。

第二部分:需求挖掘与场景分析 (40分钟)

  • 主题内容与互动:

幻灯片1: 从”自动化”角度发现Agent应用场景

  • 自动化思维:识别重复性、规则性、耗时的任务
  • 关键问题:
    • “我每天/每周花最多时间做什么?”
    • “这些任务中哪些是重复的?”
    • “哪些任务有明确的输入和输出?”
  • 自动化潜力评估方法
逐字稿 欢迎来到第二部分:需求挖掘与场景分析。在这一部分,我们将探讨如何发现适合Agent实现的真实需求。 首先,让我们从"自动化"的角度思考。发现Agent应用场景的一个有效方法是识别那些重复性高、规则性强、且耗时的任务。 我建议大家问自己几个关键问题: - "我每天/每周花最多时间做什么?" - "这些任务中哪些是重复的?" - "哪些任务有明确的输入和输出?" 自动化潜力评估可以从频率、耗时和复杂度三个维度进行。频率越高、耗时越长、复杂度适中的任务,通常是最佳的自动化候选。 记住,好的Agent应用不一定是最复杂的,而是能真正节省时间和精力的。

automation_perspective_structured

automation_perspective_english

幻灯片2: 任务拆解方法论

  • 输入-处理-输出模型详解
    • 输入:任务需要的原始数据和信息
    • 处理:转换和操作数据的步骤
    • 输出:期望的结果和格式
  • 任务流程图绘制技巧
  • 实例演示:将”每周ICM工单报告生成”任务拆解为具体步骤
    • 输入:原始数据、报告模板、关键指标、负责人问答信息
    • 处理:数据清洗、分析、可视化、摘要生成
    • 输出:格式化报告、关键发现、行动建议
逐字稿 一旦确定了潜在的Agent应用场景,下一步是进行任务拆解。我们可以使用输入-处理-输出模型来进行系统性拆解。 输入:指任务需要的原始数据和信息。例如,原始数据文件、用户提供的参数、系统中已有的信息等。 处理:指转换和操作数据的步骤。这可能包括数据清洗、分析、计算、判断等。 输出:指期望的结果和格式。可能是报告、图表、决策建议或特定格式的数据。 让我用一个实例来演示:假设我们要自动化"每周ICM工单报告生成"任务。 输入部分包括:原始工单数据、报告模板、关键绩效指标定义、负责人问答信息。 处理部分包括:数据清洗(去除无效记录)、分析(计算各类指标)、可视化(生成趋势图表)、摘要生成(提炼关键发现)。 输出部分是:格式化的周报、关键发现列表、针对问题的行动建议。 通过这种拆解,我们可以清晰地看到任务的各个组成部分,为后续的Agent设计奠定基础。

task_decomposition_methodology_improved

task_decomposition_methodology_english (3)

幻灯片3: 适合当前技术条件下实现的任务特征

  • 理想的Agent任务特征:
    • 步骤明确且可分解
    • 输入输出格式一致
    • 判断标准客观
    • 容错性高
  • 难度评估框架:复杂度、模糊性、专业性
  • 示例分析:为什么”邮件分类”比”战略规划”更适合当前Agent实现
逐字稿 并非所有任务都适合在当前技术条件下用Agent实现。理想的Agent任务应具备以下特征: 首先,步骤明确且可分解。任务应该有清晰的执行路径,能够被分解为一系列明确的步骤。 其次,输入输出格式一致。每次执行任务时,输入和输出的格式应该相对稳定,这样Agent才能可靠地处理。 第三,判断标准客观。任务的成功与否应该有客观的评判标准,而不是高度主观的判断。 最后,容错性高。即使某些步骤出现小错误,也不会导致整个任务完全失败。 我们可以用复杂度、模糊性和专业性三个维度来评估任务难度。 举个例子:为什么"邮件分类"比"战略规划"更适合当前Agent实现? - 邮件分类有明确的分类规则和标准 - 输入(邮件内容)和输出(类别标签)格式一致 - 判断标准相对客观 - 即使偶尔分类错误,影响也相对有限 相比之下,战略规划需要综合考量多方面因素,判断标准高度主观,且错误可能导致严重后果。

svgviewer-output (7)

幻灯片4: 常见应用领域与案例

  • 信息处理:
    • 文档摘要与关键信息提取
    • 数据分析与报告生成
  • 内容创作:
    • 营销文案批量生成
    • 多语言内容本地化
  • 决策辅助:
    • 数据驱动的选项分析
    • 风险评估与建议生成
  • 流程自动化:
    • 客户查询自动回复
    • 例行报告自动化生成
逐字稿 现在,让我们看看Agent的几个常见应用领域和具体案例。 第一类是信息处理。这包括文档摘要与关键信息提取,如自动从长篇报告中提取要点;以及数据分析与报告生成,如将原始数据转化为有洞察力的分析报告。 第二类是内容创作。例如营销文案批量生成,根据产品特性和目标受众自动生成多版本广告文案;以及多语言内容本地化,将内容翻译并适应不同文化背景。 第三类是决策辅助。如数据驱动的选项分析,帮助比较不同方案的优缺点;以及风险评估与建议生成,基于历史数据和模式识别提供风险预警。 第四类是流程自动化。包括客户查询自动回复,根据查询内容提供相关信息;以及例行报告自动化生成,定期汇总数据并生成标准化报告。 这些应用都具备我们前面提到的特征:步骤明确、输入输出一致、判断标准客观、容错性高。

幻灯片5: 从生活和工作中发现Agent机会

  • 个人生活场景:
    • 信息过滤与整理(新闻、邮件)
    • 日程规划与提醒
    • 个人学习助手
  • 工作场景:
    • 会议记录与行动项追踪
    • 客户沟通自动化
    • 数据分析与报告生成
  • 发现方法:时间日志分析、痛点识别、重复任务记录
逐字稿 Agent的应用机会无处不在,让我们看看如何从生活和工作中发现它们。 在个人生活场景中: - 信息过滤与整理:如自动筛选重要邮件或新闻,整理成摘要 - 日程规划与提醒:根据待办事项和时间约束自动规划最优日程 - 个人学习助手:根据学习目标推荐资料,生成复习笔记 在工作场景中: - 会议记录与行动项追踪:自动记录会议要点,提取行动项并分配 - 客户沟通自动化:根据客户问题生成个性化回复模板 - 数据分析与报告生成:定期处理业务数据,生成标准化报告 发现这些机会的方法包括: - 时间日志分析:记录一周内的时间分配,找出耗时任务 - 痛点识别:注意工作中经常抱怨或拖延的任务 - 重复任务记录:留意每天/每周都在做的相似工作 记住,最好的Agent应用往往来自真实的痛点,而不是技术驱动的想象。

幻灯片6: 互动环节 - 个人练习

  • 任务:列出3个自己日常重复性高的任务
  • 工作表填写:
    • 任务名称
    • 完成频率
    • 耗时估计
    • 自动化难度初步评估(1-5)
    • 自动化价值估计(1-5)
  • 时间:5分钟
  • 目标:识别个人最有价值的自动化机会
逐字稿 现在,让我们进行一个个人练习,帮助大家发现自己的Agent应用机会。 请花5分钟时间,列出3个你日常重复性高的任务,并填写以下信息: - 任务名称 - 完成频率(每天、每周、每月等) - 耗时估计(每次完成需要多少分钟) - 自动化难度初步评估(1-5分,1最简单,5最困难) - 自动化价值估计(1-5分,1价值最低,5价值最高) 这个练习的目标是帮助你识别个人最有价值的自动化机会。请尽量具体描述任务,例如不要只写"处理邮件",而是"筛选并回复客户产品咨询邮件"。 [给予5分钟时间完成] 现在请看一下你的列表,哪个任务的"自动化价值"减去"自动化难度"的差值最大?这可能是你最适合优先考虑的Agent应用场景。

幻灯片7: 互动环节 - 小组讨论

  • 分组活动:
    • 每人分享自己识别的最有价值任务
    • 小组选择1个最有潜力的任务
    • 共同完成任务拆解工作表
  • 任务拆解工作表:
    • 步骤清单
    • 每步输入/输出
    • 可能的挑战点
    • 成功标准
  • 时间:15分钟
  • 材料:任务拆解模板纸/电子表格
逐字稿 接下来,我们将进行小组讨论,深入分析潜在的Agent应用。 请分成4-5人一组,每人先分享自己识别的最有价值任务。然后,小组共同选择1个最有潜力的任务,一起完成任务拆解工作表。 任务拆解工作表包括以下内容: - 步骤清单:将任务分解为具体步骤 - 每步输入/输出:明确每个步骤需要什么,产出什么 - 可能的挑战点:预见可能的困难 - 成功标准:如何判断任务完成得好 我们为每组准备了任务拆解模板纸/电子表格,请用15分钟时间完成这个活动。 [给予15分钟时间完成] 请记住,好的任务拆解应该足够详细,每个步骤都应该是可执行的,而不是笼统的描述。

幻灯片8: 互动环节 - 任务评估

  • 小组活动:
    • 评估每个步骤的可行性(1-5)
    • 识别关键挑战点
    • 提出可能的解决方案
  • 引导问题:
    • “哪个步骤最难实现?为什么?”
    • “有哪些步骤可能需要人工干预?”
    • “如何验证每个步骤的输出质量?”
  • 时间:5分钟
逐字稿 现在,让我们对拆解后的任务进行评估,确定其可行性。 请小组成员一起: - 评估每个步骤的可行性(1-5分) - 识别关键挑战点 - 提出可能的解决方案 在评估过程中,请思考以下问题: - "哪个步骤最难实现?为什么?" - "有哪些步骤可能需要人工干预?" - "如何验证每个步骤的输出质量?" 这个评估将帮助我们了解任务的实际可行性,以及可能需要的技术和资源。 请用5分钟时间完成这个评估。 [给予5分钟时间完成] 评估完成后,请在组内讨论:如果发现某些步骤可行性低,是否可以通过重新设计流程或降低要求来提高整体可行性?

幻灯片9: 互动环节 - 全体分享

  • 每组代表:
    • 简述选择的任务
    • 展示任务拆解结果
    • 分享关键发现和挑战
  • 讲师点评:
    • 任务选择的合理性
    • 拆解的完整性
    • 可行性评估的准确性
  • 时间:每组2-3分钟
逐字稿 现在,我们进入全体分享环节。每个小组请选一位代表: - 简述你们选择的任务 - 展示任务拆解结果 - 分享关键发现和挑战 每组有2-3分钟的时间分享。 [各组分享] 非常感谢各组的分享!我注意到几个有趣的模式: [针对具体分享内容进行点评,例如:] - A组的任务选择非常聚焦,拆解得很详细,特别是输入输出定义清晰 - B组识别的挑战点很有洞察力,尤其是关于数据一致性的考虑 - C组提出的解决方案很有创意,特别是将复杂决策点改为多选项选择 这些任务拆解和评估为我们下一步的可行性验证和模型选择奠定了基础。在下一部分,我们将学习如何验证这些任务是否真的适合用当前的大模型技术实现。

第三部分:可行性验证与模型选择 (50分钟)

  • 主题内容与互动:

幻灯片1: 任务可行性验证方法

  • 可行性验证的三个维度:
    • 技术可行性:模型能力是否足够
    • 数据可行性:必要信息是否可获取
    • 实施可行性:是否能集成到现有流程
  • 验证流程图:从概念到实施的评估路径
  • 快速原型测试策略
逐字稿 欢迎来到第三部分:可行性验证与模型选择。在这一环节,我们将探讨如何系统地验证你的Agent方案是否可行,以及如何选择最适合的模型。 首先,让我们了解可行性验证的三个关键维度: 技术可行性关注的是"模型能力是否足够"。我们需要评估当前的大模型技术是否能够完成任务的核心功能。例如,如果任务需要精确的数学计算,我们需要评估模型的数学能力是否达标。 数据可行性关注的是"必要信息是否可获取"。即使模型有能力,如果缺乏必要的数据输入,任务也无法完成。例如,如果我们想建立一个分析公司内部文档的Agent,但这些文档无法被访问或提取,那么这个Agent就无法实现。 实施可行性关注的是"是否能集成到现有流程"。这涉及到技术集成、用户接受度、成本效益等方面。即使技术上可行,如果无法顺利集成到现有工作流程中,项目也难以成功。 在这张幻灯片上,我们可以看到一个验证流程图,它展示了从概念到实施的评估路径。这个流程包括初步评估、快速原型测试、小规模试点和全面实施四个阶段。每个阶段都有明确的评估标准和决策点,帮助我们及早发现问题并调整方向。 快速原型测试是这个流程中的关键环节。它允许我们用最小的投入验证最关键的假设,避免在不可行的方案上浪费时间和资源。在接下来的内容中,我们将详细讨论如何进行有效的原型测试。

幻灯片2: “元任务”拆分法详解

  • 元任务定义:不可再分的基础能力单元
  • 元任务识别方法:
    • 功能独立性:完成一个独立的小功能
    • 不可再分:无法被进一步拆解
    • 可直接测试:有明确的成功/失败标准
  • 元任务示例:
    • “判断Excel单元格是否包含公式”
    • “从文本中提取人名和组织名”
    • “将非结构化数据转换为JSON格式”
逐字稿 接下来,我想介绍一个非常实用的方法——"元任务"拆分法。这是验证Agent可行性的核心方法之一。 什么是"元任务"?元任务是不可再分的基础能力单元。它是构成复杂任务的基本组件,就像原子之于分子。每个元任务都应该是模型需要具备的一个基础能力。 如何识别元任务?有三个关键标准: 第一,功能独立性。每个元任务应该完成一个独立的小功能,有明确的目标。例如,"从文本中提取日期"就是一个功能独立的元任务。 第二,不可再分。元任务是最小的能力单元,无法被进一步拆解为更小的任务。如果一个任务还可以拆分,那它就不是元任务。 第三,可直接测试。每个元任务都应该有明确的成功或失败标准,便于我们直接评估模型的表现。 让我举几个元任务的例子: "判断Excel单元格是否包含公式"是一个元任务,它要求模型能够识别Excel公式的特征。 "从文本中提取人名和组织名"是另一个元任务,它测试模型的命名实体识别能力。 "将非结构化数据转换为JSON格式"测试的是模型的格式转换能力。 通过将复杂任务拆分为这些基础元任务,我们可以更精确地评估模型能力,找出潜在的瓶颈,从而更有针对性地设计解决方案。

幻灯片3: 元任务测试的”一票否决”原则

  • 原则解释:如果模型无法完成元任务,则无法完成由该元任务组成的复杂任务
  • 应用策略:先测试最关键的元任务
  • 决策树:基于元任务测试结果的项目可行性评估
  • 案例:某客服自动化项目因模型无法准确识别客户情绪而被否决
逐字稿 在元任务测试中,有一个非常重要的原则——"一票否决"原则。这个原则的核心是:如果模型无法完成某个关键元任务,那么它就无法完成由该元任务组成的复杂任务。 这个原则听起来可能有些严格,但它帮助我们节省时间和资源。想象一下,如果我们要构建一个需要10个元任务的Agent,而模型在其中一个关键元任务上表现极差,那么无论其他9个任务表现多么出色,整个Agent都无法正常工作。 应用这个原则的最佳策略是:先测试最关键的元任务。什么是最关键的元任务?通常是那些: 1. 在整个流程中不可替代的 2. 没有可行的替代方案或人工干预机制的 3. 对最终结果质量影响最大的 在这张幻灯片上,我们可以看到一个决策树,它展示了如何基于元任务测试结果评估项目的可行性。这个决策树帮助我们在不同的测试结果下做出合理的决策:继续、调整还是放弃。 比如计划开发一个客服自动化Agent,其中一个关键元任务是"准确识别客户情绪"。在测试中,他们发现即使是最先进的模型,在识别微妙的情绪变化时也存在显著误差。考虑到错误识别客户情绪可能导致严重的客户体验问题,团队最终决定放弃完全自动化的方案,转而采用"人机协作"模式,让AI辅助人工客服,而非完全替代。 所以及早识别关键元任务的局限性,可以帮助我们避免在不可行的方向上投入过多资源,转而寻找更实用的替代方案。

幻灯片4: 不同模型在元任务上的表现差异

  • 比较表格:GPT-4 vs Claude vs DeepSeek 等
  • 测试案例:
    • 逻辑推理任务
    • 代码生成与分析
    • 结构化数据处理
    • 多语言理解与生成
  • 性能差异分析与选择建议
逐字稿 不同的大语言模型在各类元任务上的表现存在显著差异。了解这些差异对于选择合适的模型至关重要。 在这张幻灯片上,我们可以看到几个主流模型在不同元任务上的表现比较:GPT-4、Claude、DeepSeek等。这个比较表格是基于我们的实际测试结果整理的。 让我们看几个具体的测试案例: 在逻辑推理任务上,如复杂条件判断和多步骤推理,o1 / Claude 等推理模型通常表现最佳。 在代码生成与分析方面,专门针对代码训练的模型如Codex或CodeLlama往往表现更好,尤其是在理解复杂代码结构和生成高质量代码方面。例如,在修复包含细微逻辑错误的代码时,这些专用模型的成功率可能比通用模型高20%以上。 在结构化数据处理方面,如JSON解析和表格数据分析,大多数模型表现相对接近,但在处理极其复杂的嵌套结构时,仍有明显差异。 在多语言理解与生成方面,不同模型的训练数据分布差异导致了性能差异。例如,DeepSeek 的中文文采明显比其他模型要好。 基于这些差异: 1. 针对任务特性选择模型:如果任务以代码为主,优先考虑代码专用模型;如果需要复杂推理,优先考虑GPT-4等顶级通用模型。 2. 考虑成本效益比:有时候,在非关键元任务上使用较小的模型可以显著降低成本,而对整体性能影响有限。 3. 混合使用策略:在一个Agent中针对不同元任务使用不同模型,发挥各自优势。 记住,模型选择不仅关乎技术表现,还需考虑成本、延迟、API稳定性等实际因素。

幻灯片5: 模型输出细节不足问题

  • 问题表现:模型输出过于简略,缺乏必要细节
  • 原因分析:训练数据分布影响,模型倾向于生成与训练集类似长度的内容
  • 解决策略:
    • 任务拆分:将一个大任务拆分为多个小任务
    • 示例引导:提供详细的输出示例
    • 迭代深化:通过多轮对话逐步获取更多细节
  • 案例演示:如何将”市场分析报告生成”拆分为多个子任务
逐字稿 在实际应用中,我们经常遇到一个常见问题:模型输出细节不足。这个问题表现为模型生成的内容过于简略,缺乏必要的细节和深度,无法满足实际需求。 为什么会出现这个问题?主要原因是训练数据分布的影响。大语言模型倾向于生成与其训练集中常见样本类似长度和详细程度的内容。例如,如果训练数据中的大多数回答都是简短的几句话,模型自然会倾向于生成类似长度的回答。 此外,模型的注意力机制也有局限性。随着生成内容的增长,模型可能"忘记"之前的上下文或指令细节,导致后续内容质量下降。 针对这个问题,我们有几个有效的解决策略: 第一,任务拆分。将一个需要详细输出的大任务拆分为多个小任务,每个小任务专注于内容的一个方面。例如,不要直接要求模型生成一份完整的市场分析报告,而是分别要求它分析市场规模、竞争格局、消费者趋势等,然后整合这些内容。 第二,示例引导。提供详细的输出示例,明确展示你期望的详细程度和格式。模型会倾向于模仿你提供的示例风格。 第三,迭代深化。通过多轮对话逐步获取更多细节。首先获取概要,然后针对每个要点进行深入提问。 让我演示一个案例:如何将"市场分析报告生成"拆分为多个子任务。不要直接要求"生成一份关于可再生能源市场的分析报告",而是拆分为: 1. 首先生成报告大纲和关键要点 2. 针对每个要点分别生成详细内容 3. 要求模型为每个部分添加数据支持和案例 4. 最后整合并生成执行摘要 这种方法不仅能获得更详细的内容,还能更好地控制报告的结构和质量。

幻灯片6: 知识缺失问题与RAG补充

  • 知识缺失的表现与识别
  • RAG(检索增强生成)框架介绍:
    • 架构:检索系统 + 生成模型
    • 工作流程:查询分析→文档检索→上下文融合→回答生成
  • 实施步骤:
    • 知识库构建
    • 检索系统选择与配置
    • 提示词设计与优化
  • 案例:使用RAG解决特定领域专业知识不足问题
逐字稿 另一个常见的挑战是模型的知识缺失问题。这个问题表现为模型无法回答特定领域的专业问题,或者提供的信息已经过时。 如何识别知识缺失?通常有几个明显的信号:模型直接表示不知道;提供的信息明显错误或过时;或者生成非常笼统、缺乏具体细节的回答。 解决这个问题的有效方法是RAG(检索增强生成)框架。RAG结合了检索系统和生成模型的优势,可以大幅提升模型在特定领域的知识表现。 RAG的基本架构包括两个主要组件:检索系统和生成模型。检索系统负责从知识库中找到相关文档,生成模型则基于这些文档生成回答。 其工作流程通常包括四个步骤: 1. 查询分析:理解用户问题的核心意图 2. 文档检索:从知识库中找到最相关的文档 3. 上下文融合:将检索到的文档与原始问题结合 4. 回答生成:基于融合后的上下文生成最终回答 实施RAG系统的关键步骤包括: 首先是知识库构建。这涉及收集、处理和索引相关文档。文档可以是公司内部资料、产品手册、行业报告等。关键是确保这些文档覆盖目标领域的核心知识。 其次是检索系统的选择与配置。常见选择包括基于向量数据库的语义检索、传统的关键词检索,或两者的混合。系统配置需要平衡召回率和精确度。 最后是提示词设计与优化。有效的提示词应该指导模型如何使用检索到的信息,包括如何评估信息的相关性、如何处理冲突信息等。

幻灯片7: 难以拆分的任务类型

  • 文风改写:
    • 挑战:风格转换的主观性和一致性要求
    • 评估方法:A/B测试,人工评价
  • 实体提取:
    • 挑战:领域特定实体识别,新实体处理
    • 测试策略:准确率与召回率平衡
  • 创意生成:
    • 挑战:创意质量难以量化评估
    • 应对方法:多样性生成+人工筛选
  • 其他难以拆分的任务及应对策略
逐字稿 在实践中,我们会遇到一些难以拆分为元任务的任务类型。这些任务通常具有主观性、整体性或创造性特征,难以用客观标准评估。让我们看几个典型例子: 首先是文风改写任务。这类任务的挑战在于风格转换的主观性和一致性要求。例如,将学术论文改写为通俗文章,不仅需要保留原文的核心信息,还需要一致地应用新的语言风格。这种任务难以拆分,因为风格是贯穿全文的整体特性。 对于文风改写,我们推荐的评估方法是A/B测试和人工评价。可以让目标受众比较原文和改写版本,评估改写是否达到预期效果。也可以设计评分标准,如"信息保留度"、"风格一致性"和"可读性"等维度进行评分。 第二类是实体提取任务,特别是涉及领域特定实体或新实体的情况。例如,从医学文献中提取新发现的蛋白质名称,或从技术文档中提取专有名词。这类任务的挑战在于模型可能缺乏对特定领域实体的认知,或无法识别训练数据中未出现的新实体。 对于实体提取,我们建议的测试策略是平衡准确率与召回率。可以使用少量标注数据评估模型性能,并根据业务需求决定是优先保证准确率还是召回率。例如,在医疗场景中,可能更看重准确率;而在研究辅助场景中,可能更看重召回率。 第三类是创意生成任务,如广告文案创作、故事情节构思等。这类任务的挑战在于创意质量难以量化评估,往往依赖人的主观判断。 对于创意生成,我们推荐的应对方法是多样性生成加人工筛选。让模型生成多个不同的创意方案,然后由人工或目标受众筛选最佳方案。这种方法利用了模型的发散思维能力,同时保留了人类在创意评估方面的优势。 其他难以拆分的任务还包括情感分析、文本摘要等。对于这些任务,我们通常需要结合定量和定性的评估方法,并在实际应用中不断调整和优化。 记住,对于难以拆分的任务,我们的目标不是追求完美的自动化,而是找到人机协作的最佳平衡点。

幻灯片8: 模型选择策略与评估框架

  • 模型选择决策矩阵:
    • 任务类型与模型专长匹配
    • 成本与性能平衡
    • 部署环境限制考量
  • 评估指标体系:
    • 准确性指标
    • 效率指标
    • 稳定性指标
  • 模型选择案例分析:
    • 自媒体场景:为什么选择DeepSeek而非GPT-4
    • 代码助手:为什么选择Codex/Copilot而非通用模型
逐字稿 选择合适的模型是构建成功Agent的关键决策之一。我们需要一个系统的评估框架来指导这一选择。 首先,让我介绍模型选择决策矩阵,它考虑三个关键维度: 第一维度是任务类型与模型专长匹配。不同模型在不同任务上有各自的优势。例如,GPT-4等传统旗舰模型在简单提问、知识性问答等方面更强。而专门的代码模型或者推理模型在代码生成方面更有优势。我们需要根据核心元任务的特性选择最匹配的模型。 第二维度是成本与性能平衡。高性能模型通常伴随着更高的成本。我们需要评估性能提升是否值得额外成本,特别是在大规模部署场景中。例如,如果从GPT-4o升级到GPT o1只带来5%的性能提升,但成本增加了10倍,这可能不是一个合理的选择。或者这个需求本身也不太适合用大模型来实现。 第三维度是部署环境限制考量。这包括延迟要求、隐私安全需求、API稳定性等。例如,如果应用需要部署在隔离网络环境中,那么只能选择支持本地部署的模型。 接下来是评估指标体系,它包括三类关键指标: 准确性指标衡量模型完成任务的正确程度。根据任务不同,可能包括精确率、召回率、F1分数、BLEU分数等。 效率指标衡量模型的资源消耗。包括推理延迟、token消耗量、API调用成本等。 稳定性指标衡量模型表现的一致性。包括结果的可重复性、对输入变化的敏感度、长期服务的可靠性等。 让我们来看两个案例分析: 在自媒体内容创作场景中,选择了DeepSeek而非GPT-4。原因是:DeepSeek在中文创意写作方面明显超越GPT-4,并且成本显著更低;内容创作任务对延迟不敏感,可以接受稍长的响应时间;且该场景下的输出会经过人工审核,不需要极高的准确率。 在Github Copilot 的代码补全场景中,团队选择了专门的代码模型如Codex而非通用模型。原因是:专用模型在代码生成的延迟上有明显优势;它们通常提供更好的IDE集成体验;且在理解代码上下文方面更为精准。 记住,模型选择不是一劳永逸的决定。随着新模型的发布和现有模型的更新,我们应该定期重新评估选择,确保始终使用最适合的模型。

幻灯片9: 互动环节 - 实操演示

  • 讲师实时演示:
    • 选择1-2个元任务
    • 在不同模型的Playground中测试
    • 比较结果差异
    • 分析成功/失败原因
  • 演示内容:
    • 提示词设计过程
    • 参数调整(温度、top_p等)
    • 结果评估标准
  • 时间:10分钟
逐字稿 现在,让我们通过一个实操演示,将前面讨论的概念付诸实践。我将选择1-2个典型的元任务,在不同模型的Playground中进行测试,并比较结果差异。 首先,我选择的第一个元任务是"从非结构化文本中提取特定格式的数据"。这是很多Agent应用中的关键能力。具体来说,我们要从一段产品评论文本中提取产品名称、评分、优点和缺点,并将它们格式化为JSON结构。 让我设计提示词。好的提示词应该明确任务目标、输入格式和期望的输出格式。我的提示词是: "请从以下产品评论中提取产品名称、评分(1-5)、主要优点和主要缺点,并将结果格式化为JSON。评论文本:'我最近购买了Sony WH-1000XM4耳机,总体给4.5分。降噪效果非常出色,音质也很棒,电池续航达到了宣传的30小时。不过,价格有点贵,而且耳罩在长时间佩戴后会有些热。'" 现在,我将在GPT-4o和GPT-4o-mini两个模型上测试这个提示词,看看结果有何不同。 [演示在两个模型上的测试结果] 我们可以看到,GPT-4生成的JSON格式完全正确,并准确提取了所有信息。而GPT-3.5虽然也提取了大部分信息,但在处理评分时出现了问题,它没有保留原始的4.5分,而是四舍五入为4分。 接下来,让我调整一下参数。我将温度(temperature)从默认的0.7降低到0.2,看看是否能提高GPT-3.5的精确度。 [演示参数调整后的结果] 有趣的是,降低温度后,GPT-3.5的结果变得更加一致,但仍然将4.5四舍五入为4。这表明这不是随机性问题,而可能是模型对小数处理的系统性偏差。 现在,让我们尝试第二个元任务:"理解复杂的条件逻辑并应用到具体场景"。这是许多决策类Agent必须具备的能力。 [演示第二个元任务的测试过程] 通过这个演示,我们可以看到: 1. 不同模型在处理同一元任务时可能有显著差异 2. 参数调整可以影响结果的一致性,但无法弥补模型基础能力的差距 3. 精心设计的提示词对于获得准确结果至关重要 这种元任务测试方法可以帮助我们在项目早期就识别潜在的技术瓶颈,从而做出更明智的设计决策。

幻灯片10: 互动环节 - 实践练习

  • 个人/小组活动:
    • 为自己的应用场景定义2-3个关键元任务
    • 编写测试提示词
    • 使用提供的API或Playground进行测试
    • 记录结果与发现
  • 提供的资源:
    • 元任务定义模板
    • 提示词结构指南
    • 测试结果记录表
  • 时间:15分钟
逐字稿 现在轮到大家动手实践了!在这个环节中,我希望每个人或小组能够为自己的应用场景定义2-3个关键元任务,并进行实际测试。 具体步骤如下: 第一步,为你的应用场景定义2-3个关键元任务。回想一下,好的元任务应该是功能独立的、不可再分的,并且有明确的成功标准。例如,如果你的应用是一个会议摘要生成器,关键元任务可能包括"识别会议中的关键决策点"、"提取行动项及负责人"等。 第二步,为每个元任务编写测试提示词。提示词应该清晰地描述任务目标、输入内容和期望的输出格式。我们提供了提示词结构指南,可以参考这个框架来设计你的提示词。 第三步,使用我们提供的API访问凭证或公开的Playground进行测试。如果可能,尝试在不同的模型上测试同一元任务,比较结果差异。 最后,使用测试结果记录表记录你的发现。特别注意记录成功和失败的案例,以及可能的原因分析。 我们提供了以下资源来支持你的实践: - 元任务定义模板,帮助你系统地描述每个元任务 - 提示词结构指南,提供设计有效提示词的框架 - 测试结果记录表,用于记录和分析测试结果 这些材料已经通过链接分享给大家,请查看聊天区或邮件。 你有15分钟的时间完成这个练习。我和助教将在各组之间巡回,提供必要的帮助。如果遇到技术问题或概念疑问,请随时举手。 15分钟后,我们将进入下一个环节,讨论测试中遇到的问题和解决方案。 现在,请开始你的实践练习!

幻灯片11: 互动环节 - 问题诊断

  • 小组讨论:
    • 分享测试中遇到的问题
    • 分析失败原因
    • 提出改进方案
  • 讲师巡回指导:
    • 针对性建议
    • 常见问题解决思路
    • 提示词优化方向
  • 全体分享:2-3个典型问题及解决方案
  • 时间:10分钟
逐字稿 时间到!现在我们进入问题诊断环节。在这个环节中,我们将讨论测试过程中遇到的问题,分析失败的原因,并提出改进方案。 首先,请在小组内分享你遇到的问题。特别是那些预期模型能够处理但实际表现不佳的任务。讨论可能的失败原因:是提示词不够清晰?是任务本身超出了模型能力?还是其他因素? 同时,也请分享你的成功经验,特别是那些通过优化提示词或调整参数显著改善结果的案例。 在你们讨论的同时,我和助教将在各组之间巡回,提供针对性的建议和指导。我们会重点关注: - 如何优化提示词以提高成功率 - 如何诊断和解决常见的模型输出问题 - 如何根据测试结果调整任务设计 [讲师巡回指导10分钟] 现在,我想邀请2-3个小组分享你们遇到的典型问题和解决方案。每组有1-2分钟的时间。 [小组分享] 非常感谢大家的分享!我们看到了几个共同的主题: 1. 模型在处理复杂指令时容易遗漏部分要求,解决方案是将指令分解为更小的步骤或使用结构化格式突出关键要求。 2. 领域专业知识的缺失是常见挑战,RAG方法是有效的解决途径。 3. 输出格式控制需要明确的示例和清晰的结构指导。 这些发现将帮助我们在下一部分中设计更有效的提示词和Agent架构。 在结束第三部分之前,我想强调:元任务测试不仅是技术验证的工具,也是项目风险管理的重要手段。通过早期识别模型能力的边界,我们可以更合理地设计解决方案,避免在项目后期遇到无法克服的技术障碍。 接下来,我们将进入休息时间,之后继续第四部分:提示词工程与优化。

休息时间 (15分钟)

第四部分:提示词工程与优化 (35分钟)

  • 主题内容与互动:

幻灯片1: 提示词工程的本质

- 理解模型的iid(独立同分布)特性:
    - 训练数据分布对模型行为的影响
    - 为什么相似训练样本的任务表现更好
    - "模型偏好"的本质:统计规律而非真正的偏好
- 提示词工程的核心目标:
    - 最大化与训练数据分布的匹配度
    - 明确指令与约束条件
    - 减少歧义,增强可预测性
逐字稿 欢迎回到工作坊。在这一部分,我们将深入探讨提示词工程与优化,这是构建高效Agent的关键环节。 首先,我们需要理解提示词工程的本质,这与模型的基本特性密切相关。 大语言模型是基于独立同分布(iid)假设训练的,这意味着训练数据的分布直接影响模型的行为。当我们的任务与训练样本相似时,模型表现会更好。这就解释了为什么某些任务模型能轻松完成,而另一些则困难重重。 我们常说模型有"偏好",但实际上这只是统计规律的体现,而非真正的个性化偏好。模型倾向于生成与其训练数据中高频模式相符的内容。 基于这种理解,提示词工程的核心目标就清晰了:我们要最大化与训练数据分布的匹配度。也就是说,尽量使我们的提示词和期望的输出模式与模型训练时见过的内容相似。 同时,我们需要通过明确的指令和约束条件来引导模型。模型不能读心,它只能根据我们提供的文本作出反应。 最后,减少歧义、增强可预测性是提示词工程的另一个关键目标。好的提示词应当明确无误,不留解释空间,这样才能获得一致、可靠的结果。

幻灯片2: 用词选择的重要性

- 不同用词的效果差异:
    - "总结" vs "精炼" vs "提取要点"
    - "分析" vs "评估" vs "审视"
    - "创建" vs "生成" vs "构思"
- 实例对比:同一任务,不同指令词的输出差异
- 模型对特定术语的敏感度分析
- 行业特定术语的使用建议
逐字稿 在提示词工程中,用词选择可能产生意想不到的影响。看似近义的词汇,可能会导致模型生成截然不同的输出。 举几个例子: "总结"、"精炼"和"提取要点"这三个词表面上都是让模型概括内容,但实际效果可能大不相同。"总结"通常得到的是全面但较长的概述;"精炼"可能会保留原文结构但简化语言;而"提取要点"则往往得到更为精简的要点列表。 同样,"分析"、"评估"和"审视"也有细微差别。"分析"倾向于分解和解释;"评估"暗示了某种价值判断;而"审视"则可能导致更批判性的审查。 "创建"、"生成"和"构思"在创意任务中的效果也各不相同。"创建"暗示了从无到有的过程;"生成"更强调自动化和数量;而"构思"则侧重于创意和概念发展。 让我们通过一个实例来对比。这里是同一个产品评价任务,分别使用"分析"和"评估"作为指令词的结果。使用"分析"时,模型提供了详细的功能分解和数据支持;而使用"评估"时,模型则更多关注产品的优缺点和总体价值。 模型对特定术语的敏感度也值得注意。例如,"逻辑推理"、"step-by-step"、"思考逐步"等词汇往往能触发模型的特定思考模式,提高复杂问题的解决质量。 对于行业特定术语,我建议在提示词中使用标准的专业术语,而非通俗表达。例如,在金融领域使用"资产负债表"而非"财务状况表",在医疗领域使用"预后"而非"恢复前景",这些专业术语往往与模型的训练数据更匹配,能得到更准确的响应。 总之,精确的用词选择可以显著影响模型输出的方向和质量。在设计提示词时,应该有意识地测试不同词汇的效果,选择最能引导模型生成期望结果的表达方式。

幻灯片3: 指令结构与顺序的影响

- 结构要素:
    - 背景信息
    - 任务描述
    - 约束条件
    - 输出格式
    - 评估标准
- 顺序影响分析:
    - 前置背景 vs 后置背景
    - 先约束后任务 vs 先任务后约束
- 最佳实践:
    - 关键信息优先原则
    - 临近原则
    - 逻辑递进结构
    - 视觉分隔与强调
- 案例演示:重构提示词顺序提升效果
逐字稿 提示词的结构和元素顺序对模型的响应有着深远影响。一个完整的提示词通常包含几个关键要素: 背景信息提供上下文,帮助模型理解任务的环境和前提。 任务描述明确告诉模型需要做什么。 约束条件设定边界和限制,确保输出符合特定要求。 输出格式指定结果的组织方式和展示形式。 评估标准告诉模型如何判断输出的质量。 这些元素的排列顺序会显著影响结果。例如,前置背景与后置背景的效果不同:前置背景能更好地引导模型理解任务上下文,而后置背景可能被模型忽视或权重较低。 同样,先提出约束后描述任务,与先描述任务后提出约束,也会导致不同结果。前者使约束成为任务的框架,后者可能导致约束被视为次要考虑。 基于大量测试,我们总结了几个最佳实践: 关键信息优先原则:最重要的指令应该放在开头,确保它们获得足够的注意力。 临近原则:相关的信息应该放在一起,减少模型需要维持的上下文距离。 逻辑递进结构:按照从一般到具体、从背景到任务的顺序组织内容。 视觉分隔与强调:使用分段、标题、加粗等格式增强关键部分的可识别性。 让我演示一个案例。这是一个原始的提示词,要求模型生成一份市场分析报告。在重构顺序后,我们先明确了输出格式和评估标准,然后才提供详细的任务描述和背景信息。结果表明,重构后的提示词生成的报告结构更清晰,重点更突出,符合要求的程度也更高。 这个例子说明,仅通过调整元素顺序,不改变实质内容,就能显著提升提示词的效果。

幻灯片4: 长文本提示词的约束管理

- 问题:当输出内容较长,需要的约束与提示词相隔较远时
- 解决方案:
    - 让模型先复述约束和要求,再执行任务
    - 使用结构化提示词,明确标记约束部分
    - 关键约束重复强调
- 示例:
  </details>
    请先复述以下约束条件,然后再进行任务:
    1. 输出必须包含5个关键点
    2. 每个点必须有数据支持
    3. 总字数控制在1000字以内
  </details>
- 效果对比:使用复述技巧前后的约束遵循率
逐字稿 随着任务复杂度增加,提示词和预期输出的长度也会增加,这就带来了一个常见问题:当模型生成较长内容时,早期提出的约束可能会被"遗忘"或权重降低。 这个问题的本质是大语言模型的注意力机制在处理长序列时存在局限,远距离的信息关联变得困难。当模型生成了几百或上千个token后,最初的约束条件可能已经超出了有效的注意力范围。 为解决这个问题,我们提供几个实用的解决方案: 首先,让模型先复述约束和要求,然后再执行任务。这种做法相当于让模型先"记忆"关键要求,增强这些信息在后续生成过程中的存在感。 例如,我们可以这样设计提示词: "请先复述以下约束条件,然后再进行任务: 1. 输出必须包含5个关键点 2. 每个点必须有数据支持 3. 总字数控制在1000字以内" 这样,模型会先重复这些约束,增强它们在上下文中的权重,然后再开始实际任务。 其次,使用结构化提示词,明确标记约束部分。通过使用标题、分段、编号等方式,增强约束的视觉突出性,使模型更容易记住。 第三,关键约束可以在提示词中重复强调,在开始和结束部分都提及,形成一种"包夹"效果。 我们做了一个对比测试,使用复述技巧前,约束遵循率仅为60%;使用后,遵循率提高到了92%。特别是在字数限制这类容易被忽视的约束上,改进尤为明显。 这些技巧虽然简单,但在实际应用中非常有效,尤其是在需要生成长文本内容的场景中。

幻灯片5: 输入输出长度优化策略

- 长度与模型性能的关系:
    - 注意力机制的局限性
    - 上下文窗口大小的影响
    - 长文本处理的挑战
- 优化策略:
    - 任务分解:将3000字内容拆分为5个600字任务
    - 重要信息前置
    - 增量生成与整合
    - 摘要-详情层次结构
- 案例:长文档分析的最佳实践
逐字稿 处理长文本是大语言模型应用中的常见挑战。为理解这个问题,我们需要先了解长度与模型性能的关系。 大语言模型的注意力机制有其固有限制。虽然理论上可以处理上下文窗口大小范围内的所有内容,但实际上,随着文本长度增加,模型对远距离信息的关注能力显著下降。上下文窗口虽然定义了最大处理长度,但并不保证模型能有效理解窗口内的所有内容。 长文本处理面临多重挑战:维持连贯性、确保前后一致、避免遗漏关键信息、防止生成重复内容等。 针对这些挑战,我们推荐几种优化策略: 首先是任务分解。例如,将3000字的文档分析拆分为5个600字的小任务,分别处理不同部分或方面,然后整合结果。这种方法可以显著提高每个子任务的质量。 其次是重要信息前置。将最关键的指令、约束或信息放在提示词的开头,确保它们获得足够的注意力权重。 第三是增量生成与整合。对于需要生成长文本的任务,可以先生成框架或大纲,然后逐段扩展,最后整合成完整内容。这种方法可以保持整体结构的连贯性。 第四是采用摘要-详情层次结构。先让模型生成内容摘要,确认方向正确后,再基于摘要逐步展开详细内容。 让我分享一个长文档分析的最佳实践案例。在处理一份80页的研究报告时,我们采用了"提取-分析-整合"的三步法:首先让模型提取每一章的关键要点,然后针对这些要点进行深入分析,最后整合各章分析结果形成总体见解。这种方法不仅避免了信息遗漏,还保证了分析的深度和连贯性。 记住,处理长文本并非简单地增加模型参数或上下文窗口,而是需要采取结构化的策略,有效管理信息流和处理流程。

幻灯片6: 提示词迭代优化方法

- 系统性迭代流程:
    - 基准测试
    - 单变量实验
    - 结果分析
    - 优化应用
- 常见优化维度:
    - 指令明确性
    - 示例数量与质量
    - 约束条件精确度
    - 格式要求清晰度
- 提示词版本管理最佳实践
- A/B测试设计与结果分析
逐字稿 提示词工程不是一蹴而就的过程,而是需要系统性迭代优化。现在我要介绍一个实用的迭代优化方法。 首先,让我们了解系统性迭代流程的四个关键步骤: 第一步是基准测试,建立初始提示词的性能基线,这是后续优化的参照点。 第二步是单变量实验,每次只改变提示词的一个方面,比如指令措辞、示例数量或格式要求等。 第三步是结果分析,客观评估每次变更带来的性能变化,可以使用自动化指标或人工评估。 第四步是优化应用,将有效的变更整合到提示词中,形成新的基准版本。 在优化过程中,我们通常关注几个关键维度: 指令明确性:确保指令清晰无歧义,使用精确的动词和描述。 示例数量与质量:测试不同数量和类型的示例如何影响模型理解。 约束条件精确度:明确定义边界和限制,避免模糊表达。 格式要求清晰度:清楚指定期望的输出结构和呈现方式。 在进行多次迭代优化时,提示词版本管理变得非常重要。我建议采用类似软件开发的版本控制方法,为每个版本的提示词添加版本号和变更说明,记录性能变化,这样便于追踪哪些变更带来了积极影响。 A/B测试是提示词优化的有力工具。在设计A/B测试时,应确保测试样本具有代表性,控制变量仅限于需要测试的方面,并使用客观指标评估结果。例如,在测试客户询问回复提示词时,可以并行测试"详细解释型"和"简洁明了型"两个版本,通过客户满意度和问题解决率来评估哪个版本更有效。 记住,提示词优化是一个持续过程,随着应用需求的变化和模型的更新,提示词也需要相应调整。系统化的迭代方法可以确保优化过程既科学又高效。

幻灯片7: 多轮交互设计原则

- 单轮 vs 多轮交互的优缺点
- 多轮交互设计模式:
    - 渐进式细化
    - 反馈纠错循环【需要慎用,因为错误内容可能对幻觉较强的模型有比较强的影响力】
    - 探索-收敛模式
- 上下文管理策略:
    - 关键信息重申
    - 状态追踪
    - 历史摘要
- 案例:客户需求挖掘的多轮对话设计
逐字稿 在实际应用中,单轮交互往往难以满足复杂任务的需求,这就需要我们理解多轮交互的设计原则。 让我们先比较单轮和多轮交互的优缺点: 单轮交互简单直接,易于实现和控制,但难以处理复杂任务和边缘情况。 多轮交互更灵活,能处理复杂任务,适应用户需求变化,但实现复杂,可能存在状态管理问题,且成本较高。 在设计多轮交互时,我们可以采用几种有效的模式: 渐进式细化是最常见的模式,先获取大致方向,然后逐步深入细节。例如,先确定用户想要一份报告,然后询问报告类型、关键内容、风格偏好等。 反馈纠错循环允许模型生成初步结果,用户提供反馈,模型据此调整。这种模式很实用,但需要谨慎使用,因为错误内容对某些容易产生幻觉的模型可能产生负面影响,引导它们继续偏离正确方向。 探索-收敛模式先广泛探索多种可能性,然后根据用户反馈逐渐聚焦到最佳方案。这在创意工作和问题解决中特别有效。 在多轮交互中,上下文管理至关重要。我们推荐三种主要策略: 关键信息重申,在对话进行中定期重复重要信息,确保它们不被"遗忘"。 状态追踪,明确记录对话已达成的决定和待解决的问题。 历史摘要,在长对话中定期生成对话历史的简要总结,帮助模型保持对整体情境的理解。 让我以客户需求挖掘为例,演示多轮对话设计: 第一轮,了解客户基本需求:"能告诉我您遇到的主要问题是什么吗?" 第二轮,深入具体场景:"这个问题在什么情况下最常出现?能举个具体例子吗?" 第三轮,探索潜在需求:"除了这个明显的问题,您是否注意到任何相关的不便?" 第四轮,确认优先级:"在这些问题中,哪一个对您的影响最大?" 最后,总结需求:"根据我们的讨论,您的核心需求是..." 每一轮都建立在前一轮的基础上,逐步构建完整的需求画像,而非一次性提出所有问题。这种渐进式方法不仅减轻了用户的认知负担,也能挖掘出初始可能被忽视的重要信息。 设计多轮交互时,关键是保持对话的自然流动,同时确保每一轮都有明确的目标和进展。

幻灯片8: 互动环节 - 提示词优化实践

- 活动:利用本环节学到的提示词技巧,解决前一阶段无法实现的需求
- 流程:
    - 选择1-2个之前失败的元任务
    - 应用新学到的提示词技巧重新设计提示词
    - 测试并比较优化前后的结果
- 成果分享:
    - 3-4位参与者分享优化经验
    - 讲师点评并总结关键技巧
- 时间:15分钟
逐字稿 现在,让我们把理论付诸实践!在这个互动环节中,我希望大家能够应用刚才学到的提示词技巧,尝试解决前一阶段中遇到的难题。 具体活动流程如下: 首先,请选择1-2个在前一阶段测试中表现不理想或完全失败的元任务。这可以是模型无法正确理解的指令,或者是输出质量不符合要求的任务。 其次,应用我们刚才讨论的提示词技巧重新设计提示词。你可以尝试: - 调整关键指令词的选择,使用更精准的术语 - 重构指令的结构和顺序,确保关键信息得到足够重视 - 添加约束管理技巧,如让模型先复述要求 - 对于长任务,考虑使用分解策略 - 增加明确的输出格式要求 接下来,使用新设计的提示词进行测试,并与之前的结果进行对比。记录下改进的方面和仍然存在的问题。 你们有15分钟的时间完成这个练习。我和助教将在各小组之间巡回,提供必要的帮助和建议。 [15分钟后] 时间到!现在我想邀请3-4位参与者分享你们的优化经验。请简要介绍: - 你选择的是什么任务 - 你应用了哪些提示词技巧 - 优化前后的结果有什么不同 - 你从这个过程中学到了什么 [参与者分享] 非常感谢大家的分享!我注意到几个共同的成功模式: [根据实际分享内容点评,例如:] - 明确的指令和结构化输出要求显著提高了模型的准确性 - 添加示例对于复杂任务特别有效 - 拆分复杂指令为简单步骤大大提升了完成率 这个练习展示了良好提示词设计的重要性。即使是相同的模型,通过优化提示词,我们可以显著提升结果质量。请记住,提示词工程是一个迭代过程,需要不断测试和优化。 接下来,我们将进入第五部分:Agent实现与代码构建,探讨如何将这些优化过的提示词整合到实际的Agent系统中。

第五部分:Agent实现与代码构建 (50分钟)

  • 主题内容与互动:

幻灯片1: Workflow型Agent架构设计

- 简洁架构原则:
    - 从最简单的组件开始
    - 避免引入不透明的框架和步骤
    - 保持流程可控和可解释
- 核心组件:
    - 输入处理模块
    - 任务执行模块
    - 结果整合模块
    - 用户界面模块
- AI编程协助策略:如何利用AI帮助实现不熟悉的部分
逐字稿 欢迎来到第五部分:Agent实现与代码构建。在前面的环节中,我们已经完成了需求分析、可行性验证和提示词优化,现在是时候将这些成果转化为实际可用的Agent了。 首先,让我们聚焦于Workflow型Agent的架构设计。在实际应用中,Workflow型Agent因其可控性和可靠性,往往是最适合落地的方案。 我们的设计遵循"简洁架构原则"。这意味着我们应该从最简单的组件开始,逐步构建系统,而不是一开始就引入复杂的框架。避免引入不透明的"黑盒"框架和步骤,这些可能会增加调试难度。始终保持流程可控和可解释,确保我们能理解系统的每一步操作。 一个典型的Workflow型Agent包含四个核心组件: 输入处理模块负责接收用户输入,进行必要的预处理,如文本清理、格式转换等,确保后续处理能顺利进行。 任务执行模块是Agent的核心,它包含我们前面优化过的提示词和相应的API调用逻辑,负责实际的智能处理工作。 结果整合模块将模型输出进行后处理,确保结果格式正确、内容完整,并能够优雅处理可能的错误情况。 用户界面模块提供与用户交互的界面,展示结果,并收集反馈。 在实现过程中,我们可能会遇到不熟悉的技术领域。这时,我们可以利用AI编程协助策略:使用ChatGPT等工具生成初始代码,理解其工作原理,然后针对性地修改以满足我们的需求。记住,AI是协助工具,最终的设计决策和质量控制仍然需要我们自己把控。

幻灯片2: Streamlit快速原型开发

    - Streamlit优势:
            - 快速开发与迭代
            - Python原生支持
            - 丰富的UI组件
            - 部署简便
    - 基本结构:
            - 页面布局
            - 用户输入处理
            - API调用
            - 结果展示
    - 代码演示:简单Agent界面的实现
    - 性能优化技巧

  <details>   <summary><b>逐字稿</b></summary>
    在构建Agent原型时,我们需要一个既简单又强大的工具来快速验证我们的想法。Streamlit恰好满足这一需求,它是Python生态系统中最受欢迎的Web应用框架之一,专为数据科学和AI应用设计。

    Streamlit有几个显著优势:首先,它支持快速开发与迭代,只需几行代码就能创建交互式应用。其次,它提供Python原生支持,对于熟悉Python的开发者几乎没有学习门槛。第三,它拥有丰富的UI组件,从简单的文本输入到复杂的数据可视化都能轻松实现。最后,部署非常简便,通过Streamlit Cloud甚至可以一键部署。

    一个典型的Streamlit应用包含四个基本结构:页面布局定义了应用的外观和组件排列;用户输入处理负责收集和验证用户提供的信息;API调用部分连接到大语言模型和其他必要的服务;结果展示则负责以用户友好的方式呈现输出。

    让我演示一个简单Agent界面的实现。这个例子创建了一个文档摘要工具:

    [示例代码]
    import streamlit as st
    import openai

    st.title("文档摘要Assistant")
    
    # 用户输入
    user_input = st.text_area("请粘贴需要摘要的文本:", height=200)
    
    if st.button("生成摘要"):
            if user_input:
                    with st.spinner("正在生成摘要..."):
                            # API调用
                            response = openai.ChatCompletion.create(
                                    model="gpt-3.5-turbo",
                                    messages=[
                                            {"role": "system", "content": "你是一个专业的文档摘要助手。"},
                                            {"role": "user", "content": f"请为以下文本生成一个简洁的摘要,突出关键点:\n\n{user_input}"}
                                    ]
                            )
                            
                            # 结果展示
                            st.subheader("摘要结果")
                            st.write(response.choices[0].message.content)
            else:
                    st.error("请输入文本内容")

    关于性能优化,使用Streamlit时要注意几点:利用st.cache_data装饰器缓存计算结果;避免在主程序中加载大型模型或数据;使用会话状态(session_state)保存用户会话信息;针对大量数据,考虑使用分页或延迟加载策略。

    这个简单的例子展示了Streamlit如何帮助我们快速构建功能性Agent界面。随着项目发展,我们可以逐步添加更复杂的功能和更精美的界面。
  </details>

幻灯片2.5: 无代码Agent开发 - Microsoft Copilot

    - Copilot Studio优势:
            - 零代码构建企业级Agent
            - 类似 GPT Store 的界面设计
            - 内置知识库连接功能
            - 与Microsoft生态系统集成
    - 核心功能:
            - 话题创建:定义Agent可以回答的问题类型
            - 知识源连接:网站、文档、SharePoint、数据库
            - Power Platform集成:扩展Agent功能
    - 实现流程:
            - 创建Copilot并定义话题范围
            - 连接相关知识源
            - 配置生成式回答设置
            - 测试、发布与监控
    - 使用场景:
            - 企业内部知识助手
            - 客户服务自动化
            - 员工培训与支持

  <details>   <summary><b>逐字稿</b></summary>
    对于那些不想深入代码实现的参与者,我想介绍一个强大的无代码Agent开发平台 - Microsoft Copilot Studio。这是一个企业级工具,让非技术人员也能创建功能强大的AI助手。

    Copilot Studio的主要优势在于它实现了真正的零代码开发体验。你可以通过直观的界面构建企业级Agent,无需编写任何代码。它提供了类似GPT Store的界面设计,让用户可以轻松创建和分享自定义AI助手。更重要的是,它内置了知识库连接功能,可以直接连接到企业内部资源。对于已经使用Microsoft产品的组织,它与整个Microsoft生态系统无缝集成,包括Teams、SharePoint等。

    Copilot Studio的核心功能围绕三个方面:首先是话题创建,你可以定义Agent可以回答的具体问题类型,设置问题示例和预期回答。其次是知识源连接,支持接入网站、文档、SharePoint、数据库等多种信息源,确保回答基于最新和最相关的信息。第三是Power Platform集成,允许你通过Power Automate自动化流程、Power Apps创建自定义应用等方式扩展Agent功能。

    实现一个基本的Copilot非常简单,通常包括四个步骤:首先,创建新的Copilot并明确定义其能回答的话题范围;然后,连接相关知识源,可以是网页、文档或数据库;接着,配置生成式回答的设置,包括回答风格、长度等参数;最后,进行测试、发布并持续监控其表现。

    这种无代码Agent特别适合几种使用场景:作为企业内部知识助手,帮助员工快速找到内部政策、流程或资源;用于客户服务自动化,回答常见问题并解决基本问题;或者作为员工培训与支持工具,提供即时的学习资源和指导。

    对于那些希望快速部署实用Agent但不想深入代码细节的参与者,Microsoft Copilot Studio提供了一个理想的平台,让你专注于内容和用例,而不是技术实现。
  </details>

幻灯片3: 互动环节 - 完整Agent实现案例

    - 案例:自动化PPT生成助手
            - 需求分析:根据Word文档生成PPT
            - 元任务测试:
            1. 规划PPT内容结构
            2. 生成PPT文字内容
            3. 生成PPT图表建议
            - 使用Streamlit串联各个模块
            - 实现演示与代码讲解
    - 时间:15分钟

  <details>   <summary><b>逐字稿</b></summary>
    现在,让我通过一个完整案例来展示如何将我们学到的所有内容整合起来,构建一个实用的Agent。我们的案例是一个自动化PPT生成助手,它能根据Word文档自动创建演示幻灯片。

    首先,让我们看看需求分析。许多人经常需要将冗长的Word文档转化为简洁的PPT演示,这是一项耗时且重复性高的工作。理想情况下,我们希望Agent能够理解文档内容,提取关键信息,规划合理的幻灯片结构,并生成适合演示的内容。

    在开始编码前,我们进行了元任务测试,确认模型能够胜任三个关键能力:
    第一,规划PPT内容结构,即根据文档内容合理划分章节和幻灯片;
    第二,生成PPT文字内容,包括标题、要点和过渡语;
    第三,生成PPT图表建议,根据内容提出可视化建议。

    测试确认这些能力可行后,我们使用Streamlit构建了应用界面,将这些模块串联起来。

    现在,让我演示这个应用的实际运行效果和核心代码:

    [代码演示]
  </details>
    import streamlit as st
    import openai
    from docx import Document
    import json
    
    # 设置页面
    st.set_page_config(page_title="Word转PPT助手", layout="wide")
    st.title("Word文档转PPT助手")
    
    # 文件上传
    uploaded_file = st.file_uploader("上传Word文档", type=["docx"])
    
    if uploaded_file is not None:
            # 读取文档内容
            doc = Document(uploaded_file)
            full_text = "\n".join([para.text for para in doc.paragraphs])
            
            with st.expander("文档内容预览"):
                    st.write(full_text[:500] + "..." if len(full_text) > 500 else full_text)
            
            if st.button("生成PPT结构"):
                    # 第一步:规划PPT结构
                    structure_prompt = f"""
                    请分析以下文档内容,提出合适的PPT结构规划。
                    返回JSON格式,包含幻灯片数量和每张幻灯片的标题与要点。
                    
                    文档内容:
                    {full_text[:4000]}  # 限制长度避免超出token限制
                    
                    JSON格式示例:
                    slides,
                                    // 更多幻灯片...
                            ]
                    }}
                    """
                    
                    with st.spinner("正在分析文档并规划PPT结构..."):
                            response = openai.ChatCompletion.create(
                                    model="gpt-4",
                                    messages=[
                                            {"role": "system", "content": "你是PPT结构规划专家。请根据文档内容提供最合适的PPT结构方案。"},
                                            {"role": "user", "content": structure_prompt}
                                    ]
                            )
                            
                            structure_text = response.choices[0].message.content
                            try:
                                    # 尝试解析JSON
                                    structure = json.loads(structure_text)
                                    
                                    # 显示PPT结构
                                    st.subheader("生成的PPT结构")
                                    
                                    for i, slide in enumerate(structure["slides"]):
                                            col1, col2 = st.columns([1, 3])
                                            with col1:
                                                    st.write(f"#### 幻灯片 {i+1}")
                                            with col2:
                                                    st.write(f"标题: {slide['title']}")
                                                    st.write("要点:")
                                                    for point in slide["points"]:
                                                            st.write(f"- {point}")
                                                    if "visualization" in slide and slide["visualization"]:
                                                            st.write(f"可视化建议: {slide['visualization']}")
                                    
                                    # 提供导出选项
                                    st.success("PPT结构生成完成!在实际应用中,这里可以添加导出为PPT文件的功能。")
                                    
                            except json.JSONDecodeError:
                                    st.error("JSON解析失败,请查看原始输出")
                                    st.text(structure_text)
  </details>

    这个案例展示了如何将复杂任务拆分为多个元任务,通过适当的提示词工程引导模型完成每个步骤,最后将结果整合为用户可用的输出。

    值得注意的是几个关键设计决策:我们限制了输入文本长度,避免超出模型上下文窗口;使用了结构化的JSON输出格式,便于后续处理;通过明确的指令和示例引导模型生成符合预期的内容结构。

    这个简单的演示可以进一步扩展,例如添加更细致的内容处理、支持主题风格选择、甚至直接生成PowerPoint文件。关键是我们遵循了模块化设计,使系统易于理解和扩展。
  </details>

幻灯片4: 互动环节 - 分组实践

- 编程组:
    - 使用Streamlit实现自己的Agent原型
    - 提供的资源:
        - 代码模板
        - API接口文档
        - 常见问题解决方案
- 非编程组:
    - 使用declarative agent平台构建简单应用
    - 提供的资源:
        - 平台使用指南
        - 配置模板
        - 测试案例
- 时间:1周
逐字稿 现在是时候亲自动手了!我们将根据大家的技术背景分成两组进行实践。 编程组的参与者将使用Streamlit实现自己的Agent原型。为了支持你们的开发,我们提供了几个重要资源:首先是代码模板,包含了基本的应用结构和模型调用功能,你可以直接在此基础上构建你的应用;其次是API接口文档,详细说明了如何调用各种大语言模型API和其他可能需要的服务;最后是常见问题解决方案,帮助你解决开发过程中可能遇到的技术难题。 非编程组的参与者将使用declarative agent平台,如Microsoft Copilot Studio或类似的无代码工具构建应用。同样,我们也为你们准备了支持资源:平台使用指南,详细介绍平台功能和操作方法;配置模板,提供常见场景的预设配置;以及测试案例,帮助你验证应用功能是否符合预期。 无论你选择哪种方式,我都鼓励你回到之前环节中确定的应用场景和任务拆解,将其实现为功能原型。记住,重点不是构建一个完美的产品,而是验证你的想法并获得实际经验。 将有1周的时间完成这个实践项目。在这段时间里,你可以随时在工作坊的在线讨论群中提问或分享进展。我和助教也会定期检查,提供必要的指导。 一周后,我们将进入最后一个环节:成果展示与总结,每个小组将有机会展示自己的Agent成果,并从其他参与者那里获得反馈。 现在,请根据自己的技术背景选择合适的实践路径,开始动手构建你的Agent原型!有任何问题,请随时提出。

第六部分:成果展示与总结

  • 主题内容与互动:

幻灯片1: 项目展示指南

  • 展示内容建议:
    • 项目背景与目标
    • 核心功能演示
    • 技术亮点
    • 遇到的挑战与解决方案
  • 展示时间:每组3分钟
  • 评分标准介绍:
    • 创新性:解决问题的独特方式
    • 实用性:实际应用价值
    • 完成度:功能完整性与稳定性
    • 技术难度:实现复杂度

幻灯片2: 互动环节 - 项目展示

  • 3-5个小组展示他们的Agent原型
  • 每组展示流程:
    • 简短介绍(30秒)
    • 功能演示(2分钟)
    • 简要总结(30秒)
  • 时间:总计15分钟

幻灯片3: 互动环节 - 反馈与建议

  • 参与者互相评价:
    • 每个项目的优势
    • 改进建议
    • 潜在应用场景扩展
  • 反馈方式:
    • 口头评论
    • 在线评分表
  • 时间:5分钟

幻灯片4: 互动环节 - 评选环节

  • 参与者投票选出:
    • “最具创意Agent”
    • “最实用Agent”
    • “技术实现最佳Agent”
  • 投票方式:
    • 在线投票工具
    • 现场举手表决
  • 获奖项目简短分享经验
  • 时间:5分钟

附录

幻灯片1: 准备材料清单

  1. 预设的Agent案例库
    • 简单案例:自动邮件分类器
    • 中等复杂度:会议摘要生成器
    • 高复杂度:研究助手
    • 失败案例分析:过于宏大的自主决策Agent
  2. 元任务测试集
    • 文本分类元任务
    • 信息提取元任务
    • 格式转换元任务
    • 逻辑推理元任务
  3. 提示词优化指南与示例对比集
  4. 代码模板(基于Streamlit)
  5. 任务拆解工作表与可行性评估清单
  6. 常见问题诊断与解决方案手册

幻灯片2: 参与者准备事项

  1. 硬件要求:
    • 笔记本电脑
    • 互联网连接
  2. 软件准备:
    • OpenAI/Claude/其他大模型API账号(可选)
    • Python环境(编程组):
      • Python 3.8+
      • pip或conda
      • 推荐安装包:streamlit, langchain, requests
  3. 预先思考:
    • 列出3个日常重复性任务
    • 思考这些任务的步骤与流程
    • 考虑可能的自动化价值

幻灯片3: 后续支持计划

  1. 线上讨论群组:
    • 平台:Slack/Discord
    • 加入方式:二维码/链接
    • 内容:技术讨论、项目分享、资源推荐
  2. 额外学习资源:
    • 代码示例库链接
    • 教程与文档集合
    • 推荐阅读清单
  3. 一周后线上答疑会议:
    • 时间:待定
    • 平台:Zoom/Teams
    • 注册方式:邮件/表单
  4. 项目迭代指导:
    • 一对一咨询机会
    • 代码审查服务
    • 部署与优化建议

幻灯片4: 参考资源

  1. 官方文档:
    • OpenAI API文档
    • Anthropic Claude文档
    • Streamlit官方指南
  2. 学术论文与技术博客:
    • “Building Effective Agents with LLMs” - Anthropic
    • “LLM Powered Autonomous Agents” - Lilian Weng
  3. 开源项目:
    • LangChain
    • AutoGPT
    • BabyAGI
  4. 社区资源:
    • Hugging Face社区
    • GitHub优秀项目集合
    • AI Agent开发者论坛

幻灯片5: 联系方式

  • 讲师邮箱
  • 社交媒体账号
  • 个人网站/博客
  • 工作坊反馈表单链接