清晨七点,你还在刷牙,收件箱里已经躺着四十七封未读邮件:客户催报价、航班改签、同事转发会议纪要、三封疑似广告。如果有一位贴身管家,她已经连夜读完所有邮件,在每封上贴好便利贴、用不同颜色的标签标明紧急程度,还模仿你的说话风格拟好了回信草稿——你只需要点头确认,就能在一杯咖啡的时间里处理完全部邮件。这不是科幻片,Gmail AI 助手正在做这件事。本篇文章就以这位「邮件管家」为线索,拆解邮件 Agent 的内部架构:它如何生成摘要、判断意图、拟写回复,又如何管理多轮对话、编排工具调用并保证可靠运行。把这套架构看懂,你也就掌握了构建一个实用 Agent 的完整思路。

岗位关联

对 AI 从业者而言,这是一份「最小可用 Agent」的完整解剖图:掌握邮件摘要、意图分类、回复生成与编排调度,你就能把任何重复性工作搬进 AI 流水线。

目录
  1. 可视化演示
  2. 邮件摘要生成
  3. 意图分类引擎
  4. 智能回复建议
  5. 上下文建模
  6. 多轮对话管理
  7. Agent编排架构
  8. 性能可靠性
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

动态演示Gmail AI助手的核心机制,通过输入/处理/存储/输出四种模式展示关键概念与交互流程。

本节配有交互动效(进入视口后自动加载,约 3KB)。

Gmail AI助手:Gmai Gmail AI助手的核心功能 智能撰写(Smart Comp 核心机制可视化 Gmail AI助手整体架构与关键组件

邮件摘要生成

清晨七点,管家 Zoe 已经坐在书桌前读完你的四十七封邮件。她不会把全文念给你听,而是在每封邮件上贴一张黄色便利贴:客户问我们什么时候上线、还催今天内确认;航班改签通知;同事转发的会议纪要需要周五前反馈。三行字,让你扫一眼就抓住要点。

这个动作对应 AI 里的「抽取式摘要」技术。它不编写新句子,而是从原文里挑出信息密度最高的几句话,排序后拼在一起。Gmail AI 助手在选句时会从三个角度给每个句子打分:是否包含业务关键词、在文中的位置、长度是否适中。

最终摘要控制在 1-3 句:太短丢信息,太长失去速读价值。正如 Zoe 的便利贴永远只写三行,摘要的目标是让人在 3 秒内做出「要不要点开」的判断,把几十封邮件的阅读时间从半小时压缩到五分钟。

Score(s)=0.4×Sig(s)+0.3×Pos(s)+0.3×Len(s)\text{Score}(s) = 0.4 \times \mathrm{Sig}(s) + 0.3 \times \mathrm{Pos}(s) + 0.3 \times \mathrm{Len}(s)
这个公式就像管家给句子发「值得被写进便利贴」的考卷:关键词越重要、位置越靠前、长度越合适,总分越高,越可能被选中。
  1. 显著性 Sig(s)统计句子里命中「请、尽快、截止、谢谢」等业务关键词的次数,命中越多说明越接近邮件主旨。
    Sig(s)=∑k∈K1[k∈s]\mathrm{Sig}(s) = \sum_{k \in K} \mathbb{1}[k \in s]
  2. 位置权重 Pos(s)句子在正文中的序号越小,位置得分越高,越靠前的句子往往承载整封邮件的核心结论。
    Pos(s)=1i\mathrm{Pos}(s) = \frac{1}{i}
  3. 长度得分 Len(s)句子长度与 40 字左右比较,接近时取 1,过长或过短都会被压缩到 1 以内。
    Len(s)=min⁡(1,∣s∣40)\mathrm{Len}(s) = \min\left(1, \frac{|s|}{40}\right)

意图分类引擎

Zoe 看完邮件后,还会抽出一叠彩色标签:红色代表「催办」、蓝色代表「询问」、绿色代表「通知」、灰色代表「闲聊」。这叠标签就是邮件 Agent 的意图分类引擎——它决定每封邮件应该被归入哪个处理通道,以及后续回复要采取什么策略。

技术上,分类器会对每个候选意图输出一个原始分数,这些分数不能直接比较大小,因为在不同的邮件中分数尺度可能完全不同。Agent 会用一个叫 softmax 的归一化层,把一堆任意实数转换成总和为 1 的概率分布,取概率最大的类别作为最终意图。

工程上还设置了置信度阈值:当最高概率低于 0.4 时,说明邮件意图太模糊,Agent 会标记为「多意图混合」或「待确认」,而不是强行给出一个错误结论——正如 Zoe 遇到拿不准的邮件时,宁可多问主人一句,也不乱贴标签。

P(y=i∣x)=ezi∑j=1KezjP(y = i \mid x) = \frac{e^{z_i}}{\sum_{j=1}^{K} e^{z_j}}
softmax 就像把管家心里对每种标签的「好感度」翻译成百分比:红色 72%、蓝色 21%、绿色 7%,加起来一定等于 100%。
  1. 分类得分 z_i模型为第 i 个意图类别产生的原始分数,越大表示这个意图越可信。
    zi=linear(hidden)z_i = \text{linear}(\text{hidden})
  2. 指数映射 e^{z_i}对每个得分取自然指数,把所有得分变成正数,并拉大分数之间的差距。
    ezie^{z_i}
  3. 归一化分母把所有类别的指数值相加,作为概率分布的总基准。
    ∑j=1Kezj\sum_{j=1}^{K} e^{z_j}
  4. 输出概率每个类别指数除以总和,得到总和为 1 的概率,最大者即为预测意图。
    P(y=i∣x)P(y = i \mid x)

智能回复建议

管家 Zoe 最讨喜的本领是模仿主人的笔迹。她不会用网上那种四平八稳的官方模板,而是学你平时怎么回信:你对熟人习惯简短、对客户习惯客气、对上级习惯先感谢再提条件。这份「笔迹」就是智能回复的风格模型基础。

实现上,生成模型会把邮件正文、近年历史回复和一份风格向量拼接起来作为条件,然后逐词生成回信草稿。训练时,模型被要求最大化用户真实回复中的每个词出现的概率——更像「照着主人的旧信学习」,而不是「凭空造句」。

草稿生成后还会做质量评估:是否包含原邮件的关键实体、是否符合长度要求、是否语气一致。受控细节不合格时,助手会退回重写,保证出门的信件不丢主人的脸。

L=−∑t=1Tlog⁡P(wt∣w<t,ctx)\mathcal{L} = -\sum_{t=1}^{T} \log P(w_t \mid w_{<t}, \text{ctx})
该公式衡量草稿与「主人真实风格」的差距:如果模型在每一步都准确预测了主人会写的词,损失就小;如果写得像陌生人,损失就大。
  1. 条件上下文 ctx把邮件正文、最近往来线程、历史回复风格向量拼接成生成时的输入条件。
    ctx=[mail;thread;style]\text{ctx} = [\text{mail}; \text{thread}; \text{style}]
  2. 词概率 P(w_t)模型在第 t 步预测下一个词 w_t 的概率,每一步都依赖前面已经生成的所有词。
    P(wt∣w<t,ctx)P(w_t \mid w_{<t}, \text{ctx})
  3. 整句对数似然把 T 个词的概率取对数后连加,衡量整句草稿被写出的总概率。
    ∑t=1Tlog⁡P(wt∣w<t,ctx)\sum_{t=1}^{T} \log P(w_t \mid w_{<t}, \text{ctx})
  4. 取负成为损失加负号后,优化目标变成「让损失最小」,等价于让整句概率最大。
    L=−∑t=1Tlog⁡P(wt∣w<t,ctx)\mathcal{L} = -\sum_{t=1}^{T} \log P(w_t \mid w_{<t}, \text{ctx})

上下文建模

为什么 Zoe 能准确判断「客户这句‘价格再低一点’是急还是不急」?因为她会翻旧账——看你和这位客户过去五封往来邮件,记得你上周已经给过 9 折优惠,这周对方又提价,大概率是委婉催你给更低方案。只看单封信,没人知道这层关系。

邮件 Agent 的上下文建模做同样的事:把邮件线程的往返回复、用户的历史画像(身份、常用语气、偏好)以及近期的交互记录融合成一个上下文向量。融合过程有个关键细节——时间衰减:一周前的邮件和五分钟前的邮件,影响力显然不同。

多源信息融合后,Agent 既能理解「这封信在说什么」,也知道「这个人在意什么」。Zoe 之所以显得聪明,不是因为她看得多,而是因为她知道什么是重点、什么是过期的琐事。

wi=e−λΔtiw_i = e^{-\lambda \Delta t_i}
时间衰减权重好比管家心中的「记忆曲线」:越久远的事在决策中占比越轻,最近的互动最值得参考。
  1. 时间间隔 Δt_i当前时刻与第 i 封历史邮件之间的间隔天数,间隔越大代表越久远。
    Δti=tnow−ti\Delta t_i = t_{\text{now}} - t_i
  2. 衰减速率 λ控制「忘得快还是忘得慢」的超参数,λ 越大,旧信息越快速退居次要位置。
    λ=0.02 /天\lambda = 0.02\ \text{/天}
  3. 指数权重 w_i间隔时间代入指数函数,得到介于 0 到 1 的权重,并与其他信息源加权求和。
    wi=e−λΔtiw_i = e^{-\lambda \Delta t_i}

多轮对话管理

主人看完 Zoe 拟的草稿,通常会有意见:「第三封再客气一点」「最后那段删掉」「把时间写到第二句」。Zoe 会一边点头一边在笔记本上更新任务清单:第三封、语气调客气、其他保持不变。这个「笔记本」就是对话状态。

在技术层面,对话状态 S 记录着当前会话已生成的草稿内容、已识别的意图和待确认项。每一轮,Agent 接收用户反馈 U_t,结合自己刚执行的动作 A_t,通过一个更新函数合并出新状态,再决定下一步是重写、局部修改还是向用户询问。

反复迭代直到用户点击「发送」,对话状态判定结束,任务清空。Zoe 永远不会被批评「重头再来」惹烦,因为她每次都只改动需要改的那几处。

St=Update(St−1,At,Ut)S_t = \text{Update}(S_{t-1}, A_t, U_t)
管家的工作台:旧清单 + 我刚做的事 + 主人新指令 = 新清单。多轮对话的本质不是「多聊几句」,而是「每次更新都记住前因后果」。
  1. 上一状态 S_{t-1}保存上一轮结束时的草稿内容、意图和待确认项,是这次更新的基础。
    St−1={草稿,意图,待确认项}S_{t-1} = \{\text{草稿}, \text{意图}, \text{待确认项}\}
  2. 本轮动作 A_tAgent 本轮执行的操作,例如生成新草稿、修改某个句子或请求用户补充信息。
    At∈{生成,修改,确认,询问}A_t \in \{\text{生成}, \text{修改}, \text{确认}, \text{询问}\}
  3. 用户反馈 U_t用户对上一版本的评价或新指令,例如「再正式一点」「把报价去掉」。
    Ut=「再正式一点」U_t = \text{「再正式一点」}
  4. 更新函数 Update把旧状态、本轮动作和用户反馈合并,输出新的对话状态,驱动下一轮生成。
    St=Update(St−1,At,Ut)S_t = \text{Update}(S_{t-1}, A_t, U_t)

Agent编排架构

一个人再能干也忙不过来的,Zoe 背后其实是一个团队:摘要员负责扫读邮件、分类员负责贴标签、写作参谋负责拟草稿、记忆库管理员负责调取历史资料。Zoe 本人只做一件事——接到新邮件后快速判断「这单该交给谁」,这判断就是模型路由。

Gmail 邮件 Agent 的编排层也类似:面对一封邮件,先做轻量意图判断,再路由到摘要模块、回复生成模块,或直接调用记忆库查询历史信息。每个模块都是一个可被调用的工具,编排层根据上下文为每个工具计算匹配度,选择得分最高的执行。

与此同时,编排层还有记忆机制和安全控制:敏感词检测、发送前人工确认、对私密信息的访问权限校验。Zoe 团队之所以高效,是因为分工明确,而为什么可靠,是因为每道工序都有人复核。

t~=arg⁡max⁡t∈Tscore(ctx,t)\tilde{t} = \arg\max_{t \in \mathcal{T}} \text{score}(\text{ctx}, t)
这相当于管家在一排工具里挑最称手的那把:谈价格时找写作参谋,查往事时找记忆库管理员,简单通知则直接走最短路径。
  1. 工具集合 T编排层可调用能力模块,如摘要模块、意图模型、写作模型、记忆库等。
    T={t1,t2,…,tn}\mathcal{T} = \{t_1, t_2, \dots, t_n\}
  2. 匹配分数根据当前上下文判断每个工具对本任务的适配度,综合任务类型、模型特长与成本。
    score(ctx,t)=匹配度\text{score}(\text{ctx}, t) = \text{匹配度}
  3. argmax 决策选择得分最高的工具执行,并可在得分过低时回退到预设规则,避免盲目调用大模型。
    t~=arg⁡max⁡t∈Tscore(ctx,t)\tilde{t} = \arg\max_{t \in \mathcal{T}} \text{score}(\text{ctx}, t)

性能可靠性

每到周日晚,Zoe 会做质量自检:本周有没有贴错标签、摘要是不是漏了关键数字、草稿有没有哪封差点发出去得罪客户。她会把问题记录在案,下周改进——这就是 Agent 的评估与反馈闭环。

邮件 Agent 同样需要量化指标。只追求「敢不敢推荐」或「准不准」都不够,工程上更常用精确率与召回率的调和平均 F1。精确率回答「给用户的推荐里有多少是对的」,召回率回答「真正该推荐的情况里有多少被抓住了」,两者往往此消彼长。

延迟和成本同样被纳入优化:高峰期大模型负载高时,系统自动降级为轻量规则摘要;用户反馈「建议不准确」则会回流训练集,驱动下一轮模型更新。Zoe 的可靠并不来自天赋,而来自严格的自我审查和持续改进的纪律。

F1=2×P×RP+RF_1 = \frac{2 \times P \times R}{P + R}
一个管家既不能为了不出错就什么都不敢推荐(精确率高但召回低),也不能什么都往用户面前推(召回高但精确低)。F1 惩罚这种「偏科」。
  1. 精确率 P在 Agent 主动给出的建议中,被用户真正采纳的比例,衡量「推荐的靠谱程度」。
    P=TPTP+FPP = \frac{TP}{TP + FP}
  2. 召回率 R在所有本应由 Agent 处理的邮件中,Agent 成功拦下并处理的比例,衡量「覆盖的完整程度」。
    R=TPTP+FNR = \frac{TP}{TP + FN}
  3. 调和平均 F1用倒数平均把两个指标合并成一个数字,偏向较小的那个,防止精度与覆盖出现短板。
    F1=2×P×RP+RF_1 = \frac{2 \times P \times R}{P + R}

AI 应用场景

企业客服邮箱自动化

阶段:邮件预处理与意图路由

解决的问题:客服团队每天收到数百封邮件,人工逐封阅读耗时巨大且容易漏掉紧急请求。Gmail AI 助手先做摘要和意图分类,将高优先级的「催办、投诉」邮件置顶,并拟好回复草稿,客服只需确认或微调后一键发送,处理时长从平均 6 分钟降到 1 分钟以内。

具体案例:某电商公司客服邮箱接入了类似 Agent:用户发来「我的订单三天没发货,能尽快处理吗?」系统自动摘要为「催发货」,意图归类为「投诉」,生成草稿「抱歉让您久等,已加急处理,预计 24 小时内发货」。客服确认后直接发送,用户满意度显著提升。

销售团队跟进报价

阶段:上下文建模与智能回复

解决的问题:销售同时跟进几十个客户,容易忘记前文承诺。Agent 将邮件线程、历史报价和客户画像纳入上下文,在生成草稿时自动提醒「你上周承诺过 9 折」,并生成贴合你语言习惯的跟进话术,避免销售在客户面前说漏嘴。

具体案例:某 SaaS 公司销售在 Gmail 中收到客户「你们的价格能不能再低一点?」的回复。Agent 读取三个月往来记录,发现对方是续费临近的活跃客户,生成草稿「老客户可以让步 5%,同时需要您升级到专业版」,既留住了客户又做了增购。

法律与咨询助理的多轮修改

阶段:多轮对话管理

解决的问题:律师对措辞要求极高,一次生成的草稿往往不满意的。Agent 支持连续指令修改:「再正式一点」「删除最后一段」「把时间提到第二句」。每轮更新对话状态,只修改用户指出的部分,不会推倒重来。

具体案例:某律所助理通过 Gmail 插件草拟对外回复,先生成初稿,再依次下达三条修改指令。三分钟后获得措辞严谨、结构清晰的终稿,原本需要半小时的润色工作被压缩到一个极短的时间窗口。

Python 演示

python96 行
import refrom collections import Counter INTENT_KEYWORDS = {    '询问': ['请问', '能否', '是否', '怎样', 'how'],    '催促': ['尽快', '截止', 'due', '催一下', '今天内'],    '通知': ['通知', '告知', '安排', '会议', 'schedule'],    '感谢': ['谢谢', '感谢', 'thanks', 'appreciate'],    '闲聊': ['哈哈', '最近怎么样', '有空'],} STYLE_OPENERS = {    '正式': {        '询问': '您好,感谢您的来信。关于您提到的问题,',        '催促': '您好,收到您的提醒,我和团队正在处理,',        '通知': '您好,已收到通知,我会尽快安排,',        '感谢': '您好,不客气,很高兴能帮上忙,',        '未知': '您好,来信已收到,',    },    '简洁': {        '询问': '收到,关于这个问题,',        '催促': '已收到提醒,正在处理,',        '通知': '通知收到,会跟进,',        '感谢': '不客气!很高兴帮忙,',        '未知': '收到,',    },} class Email:    def __init__(self, sender, subject, body, thread_count=1):        self.sender = sender        self.subject = subject        self.body = body        self.thread_count = thread_count     def digest(self, max_sentences=2):        sentences = [s.strip() for s in re.split(r'[。!?.!?\n]', self.body) if len(s.strip()) > 5]        scored = []        keywords = ['请', '尽快', '谢谢', '会议', '通知', '确认', '截止']        for idx, sent in enumerate(sentences):            score = 0.0            score += 0.4 * min(1.0, len(sent) / 40.0)            score += 0.3 * (1.0 if idx < 3 else 0.15)            score += 0.3 * (1.0 if any(k in sent for k in keywords) else 0.05)            scored.append((score, sent))        scored.sort(reverse=True)        return ' '.join(s for _, s in scored[:max_sentences])     def classify_intent(self):        text = (self.subject + self.body).lower()        votes = Counter()        for intent, kws in INTENT_KEYWORDS.items():            hits = sum(1 for kw in kws if kw.lower() in text)            if hits > 0:                votes[intent] += hits        if not votes:            return '未知'        top_intent, top_cnt = votes.most_common(1)[0]        total = sum(votes.values())        return top_intent if top_cnt / total >= 0.4 else '多意图混合'     def draft_reply(self, style='简洁'):        intent = self.classify_intent()        opener = STYLE_OPENERS[style].get(intent, STYLE_OPENERS[style]['未知'])        bridge = self.digest(1)        return opener + bridge + ',我会尽快跟进处理。'  def run_agent_pipeline(emails, style='简洁'):    results = []    for email in emails:        results.append({            'from': email.sender,            'digest': email.digest(),            'intent': email.classify_intent(),            'draft': email.draft_reply(style),        })    return results  def main():    emails = [        Email('alice@example.com', '项目进度询问',              '请问你们的最新版本什么时候能上线?客户在等,麻烦今天内确认一下,谢谢!'),        Email('bob@example.com', '会议安排',              '通知下周五下午三点召开项目周会,请提前准备材料。'),        Email('carlo@example.com', '闲聊',              '哈哈,最近怎么样?有空一起喝咖啡聊聊近况吧!'),    ]    for item in run_agent_pipeline(emails):        print(item['from'], '| 摘要:', item['digest'])        print('  意图:', item['intent'], '| 草稿:', item['draft'])  if __name__ == '__main__':    main()
目的:用 60 行实现一个简化版邮件 Agent 流水线,覆盖摘要生成、意图分类、风格化回复草稿三个核心步骤。
  1. class Email:封装一封邮件数据,包括发件人、标题、正文和往来次数,方便后续流水线统一读取。
  2. def digest(self, ...)抽取式摘要:把正文按标点切成句子,用显著性、位置、长度三个指标打分并排序。
  3. def classify_intent(self)基于关键词投票的意图分类,模拟真实 Agent 中 softmax 输出层的「近似判断」。
  4. def draft_reply(self, style='简洁')根据意图选择开头模板并拼接摘要第一句,模拟风格适配后的草稿生成。
  5. if __name__ == '__main__':程序入口:读取 3 封不同场景的邮件,依次跑完 Agent 流水线并打印结果。

常见误区

误区Gmail AI 助手的摘要应该是用 GPT 重新写一遍,所以摘要里包含原文没有的新信息也正常。

正解真实产品的主流水线是「抽取式摘要」,直接从正文挑选原句拼成摘要。生成式改写只在受控的回复草稿中使用,并有内容审核机制,防止模型编造数字、人名和日期。抽取式的好处是来源可追溯,不会无中生有。

为何常见:聊天机器人太能说,让人误以为摘要也必然来自「创作」,忽略了可控性才是工程落地最看重的东西。

误区意图分类就是给邮件贴一个唯一标签,要么是催办、要么是询问,二选一。

正解真实邮件经常意图混合,比如「催报价 + 顺便问新功能上线时间」。Agent 输出的是概率分布,当最高概率不足以压过其他类别时,会标记为「多意图混合」或「待确认」,而不是硬塞进一个类别。

为何常见:教科书上的分类任务多为单标签,初学者容易忽略真实场景中的复杂性。

误区摘要压缩到一句话才叫高效,越短越方便看。

正解过短的摘要会丢失关键数字、日期和姓名,反而逼用户点开原文,失去摘要的意义。工程上通常给 1-3 句的浮动长度,并用「信息保真」指标检查关键实体是否保留。

为何常见:「短 = 高效」的直觉在社交网络适用,但商务邮件对信息完整性的要求更高。

误区只要能连续聊很多句,就说明多轮对话能力强,模型上下文窗口加大就够了。

正解任务型多轮对话的灵魂是「状态更新」:Agent 必须知道上一轮生成过什么、用户改了什么、还有什么没确认。上下文窗口只是存储,状态跟踪才是决策依据。窗口再大,没有状态更新机制,Agent 依然会答非所问。

为何常见:ChatGPT 的连续闲聊让大众以为「多轮 = 长上下文」,忽视了任务型 Agent 对状态控制的依赖。

误区Agent 质量取决于模型大小,所以摘要、分类、生成全都要调用最大的那个模型。

正解实际采用模型路由:简单任务用规则或小模型,只有复杂改写、歧义消解才调用大模型。这样既能保证大部分场景的响应速度,也能把单封邮件成本控制在合理范围。

为何常见:大模型的热度容易让人高估其性价比,忘了工程里「分层设计、够用就好」的原则。

面试题

Q1. 邮件摘要生成通常属于哪类任务?

单选题 · easy

  • A.文本分类任务
  • B.序列标注任务
  • C.文本摘要任务← 正确答案
  • D.机器翻译任务

答案:C。邮件摘要的核心目标是从长文本中压缩出关键信息,属于文本摘要任务。文本分类负责贴标签,序列标注负责给每个词打标记,机器翻译负责跨语言转换,都不是摘要的核心目标。

Q2. 在意图分类中,softmax 函数的主要作用是什么?

单选题 · mid

  • A.将原始得分转换为独立的概率
  • B.将原始得分转换为总和为 1 的概率← 正确答案
  • C.对得分进行排序选出最大值
  • D.将得分压缩到 0 到 1 之间且总和为 K

答案:B。softmax 将所有意图的原始得分通过指数与归一化,得到总和恒为 1 的概率分布,因此选项 B 正确。A 错在「独立」,归一化使各类别相互制约;C 只是取最大值的操作;D 混淆了归一化后总和应为 1 而非 K。

Q3. 上下文建模阶段通常利用哪些信息源?

多选题 · mid

  • A.当前邮件正文和主题← 正确答案
  • B.用户历史回复风格← 正确答案
  • C.邮件线程的往来记录← 正确答案
  • D.浏览器的历史浏览记录

答案:ABC。上下文建模需要融合当前邮件、历史线程和用户画像,这三者共同决定回复的语气与内容。浏览器历史浏览记录与邮件处理无关,既涉及隐私也不属于邮件 Agent 的合理信息源。

Q4. 在时间衰减权重 w_i = e^{-λΔt_i} 中,参数 λ 的作用是什么?

单选题 · mid

  • A.控制历史邮件的总数
  • B.控制衰减快慢,λ 越大越偏向近期信息← 正确答案
  • C.控制摘要的最大长度
  • D.控制回复草稿的语气强度

答案:B。λ 是衰减速率,λ 越大指数下降越快,时间间隔较大的邮件权重被压得越低,因此系统更侧重近期信息。A 描述的是数据量而非权重,C 和 D 分别属于摘要和生成模块的参数,与时间衰减无关。

Q5. 多轮对话管理中「对话状态」主要指什么?

单选题 · easy

  • A.用户的网络连接状态
  • B.Agent 运行的服务状态
  • C.当前会话已生成及待确认的内容← 正确答案
  • D.Gmail 的同步状态

答案:C。对话状态记录当前会话进行到哪一步:已生成的草稿、已识别的意图、用户反馈过的修改点。它决定下一轮 Agent 该做什么。网络连接、服务状态和 Gmail 同步都属于系统层状态,与对话内容无关。

Q6. 在 Agent 编排架构中,模型路由需要权衡哪些因素?

多选题 · hard

  • A.当前任务的复杂度← 正确答案
  • B.各模型的延迟和成本预算← 正确答案
  • C.模型擅长的任务领域← 正确答案
  • D.邮件服务器的磁盘占用

答案:ABC。路由本质上是「把合适的任务派给合适的模型」:简单任务走小模型省成本,复杂任务才调大模型,同时还要考虑各模型的专长。邮件服务器的磁盘占用是基础设施问题,不由模型路由控制。

Q7. 当模型对邮件意图的置信度低于阈值时,合理做法是什么?

单选题 · mid

  • A.直接归类为垃圾邮件
  • B.标记为「待确认」并交给用户判断← 正确答案
  • C.随机选一个意图
  • D.重读一遍整封邮件正文

答案:B。低置信度说明信息不足或意图混杂,最稳妥的做法是返回「待确认」或「多意图混合」,由用户接手。直接归垃圾邮件可能误伤重要来信,随机选择没有依据,重读正文并不能提高已训练模型的置信度。

Q8. 为保证摘要质量,信息保真要求摘要具备哪些性质?

多选题 · hard

  • A.原文中的关键数字和日期不能遗漏← 正确答案
  • B.不添加原文没有的新信息← 正确答案
  • C.尽量压缩到一句话
  • D.使用幽默或煽情的表达方式

答案:AB。信息保真的核心是「忠实原文」:关键实体必须保留,新增内容必须避免。长度只是偏好而非保真约束,一句话摘要如果丢掉日期照样不合格;幽默表达属于风格属性,与信息保真无关。

Q9. 智能回复训练中,风格学习主要以什么为参考?

单选题 · easy

  • A.用户自己的历史邮件回复← 正确答案
  • B.网络上公开的回复模板
  • C.其他同事常说的话术
  • D.系统默认的界面文案

答案:A。每个人的表达习惯不同,Agent 要让草稿「像你写的」,最直接的学习素材就是该用户过去发出的邮件。公开模板、同事话术和界面文案都不代表个人风格,用它们训练会让所有用户收到一模一样的腔调。

Q10. 某模型精确率 P=0.8、召回率 R=0.5,其 F1 分数约为多少?

单选题 · extreme

  • A.约 0.60
  • B.约 0.62← 正确答案
  • C.约 0.65
  • D.约 0.70

答案:B。F1 是精确率与召回率的调和平均,代入公式 F1 = 2 × 0.8 × 0.5 / (0.8 + 0.5) = 0.8 / 1.3 ≈ 0.62。选项 C 的 0.65 是算术平均 (0.8+0.5)/2,调和平均永远不会高于算术平均,因此正确的只有 B。