LBS智能外呼Agent技术分享#

刘涛

吴志朋

1. 📋 背景：为什么要做智能外呼 Agent#

1.1 🎯 智能外呼在业务中的定位#

为什么要外呼？

每天有成千上万的商家在抖音上经营，他们的营业状态、营业时间随时都在变化。通过外呼可以准确、快速的核实POI信息的变化。

人工外呼

智能外呼

吞吐

坐席数量有限（大几百人），每天只能拨打上万次，很难短时间完成大量的外呼任务，扩坐席数量慢

每天拨打上百万次，接通30w，外呼并发可快速扩容

成本

高，1.08元/次接通

低，0.11元/次接通

难度

可完成复杂的核实工艺（占比小）

目前可完成简单、固定的话术（占比大）

效率

受工作时间限制

不间断外呼，全年无休

智能外呼，就是让 AI 代替人工拨打这些电话，完成高效、低成本的的信息核实。

用在哪？

目前核心业务场景包括：

• 对内：作为POI基建方向的核心横向能力之一，支持客开线索意向供给、电话/营业状态/营业时间增补&清洗、UGC审核、众包增补电话等各种依赖电话核实能力的场景。
• 对外：for生服AI新开。深度融合生服AI外呼模型和触达链路，实时意向供给 → 实时引导入驻&加企微 → 实时转人工。

1.2 😤 传统方案（SFT）的痛点#

在 Agent 方案之前，我们 100% 依赖 SFT 模型做对话。用一个比喻来形容 SFT 模型的工作方式：

🔧 SFT 模型就像一个经过大量培训的「固定台词客服」——培训多少台词，就会说多少话。遇到台词里没有的情况，就懵了（泛化能力弱）。

SFT 方案的问题：迭代周期长、策略不透明、成本较高、效果有瓶颈

⏱ 迭代周期长（核心痛点）：从发现问题到修复上线，需要「收集&清洗数据 → 标注 → SFT训练 → 评测 → 部署」全套流程，一个来回至少 4 周。

注：原文此处为在线画板或外部图片占位，离线归档时已移除；本文已补充结构化示意图辅助理解。

1.3 🚀 为什么转向 Agent 方案#

• 核心优势对比：
• 迭代周期对比：

注：原文此处为在线画板或外部图片占位，离线归档时已移除；本文已补充结构化示意图辅助理解。

1.4 🏆 Q1核心成果一览#

以下为智能外呼 Agent MVP版本已验证的核心效果数据（Q1 实测）：

📈 对话合理率：90.99%（Agent）vs 85.77%（SFT）

💰 推理成本：0.22元/千次（Agent，doubao 2.0 mini，缓存命中60%+）vs 0.4元（SFT）

🔄 迭代周期：2.5周（Agent）vs 4周（SFT）

⚡ TTFT P90：约 700ms（可接受范围，有200ms语气词兜底）

2. 🏗️ 整体设计原则#

在设计外呼 Agent 时，我们遵循了四个核心原则，缺一不可：

1️⃣ 实时性优先：外呼是实时通话，用户在等待回复。TTFT（首字延迟）必须控制在可接受范围（业界标准800ms），不能为了「更像 Agent」而牺牲用户体验。

2️⃣ 工程可控：链路要可观测、可灰度、可实验。出了问题能快速定位，新方案能安全验证。

3️⃣ 能力可演进：Prompt、RAG、模型都能独立迭代，不互相耦合。

4️⃣ 业务导向：聚焦终极指标（效果、体验、效率、成本），而不是只看模型评分。

3. ⚙️ 工程设计：链路是怎么搭起来的#

3.1 🔩 核心工程链路#

• 整体链路：
• 环节：
• 阶段1（呼前）：准备知识，异步
• 阶段2（呼中）：实时通话，同步
• 阶段3（呼后）：意图解析，异步

注：原文此处为在线画板或外部图片占位，离线归档时已移除；本文已补充结构化示意图辅助理解。

• Agent核心链路：

注：原文此处为在线画板或外部图片占位，离线归档时已移除；本文已补充结构化示意图辅助理解。

• Agent编排(graph):

注：原文此处为在线画板或外部图片占位，离线归档时已移除；本文已补充结构化示意图辅助理解。

我们的 Agent 链路实现了以下核心能力：

【Prompt 动态配置】接入 Fornax PE 管理，支持prompt片段、版本控制、动态变量注入、一键回滚。改一个 Prompt 不需要发版，配置下发即生效。

【RAG 动态召回】基于历史对话案例构建知识库，根据当前对话实时检索相似案例，注入 Prompt。

【ChatModel 灵活切换】支持多模型配置（方舟、merlin自部署模型等）。

【Tracing 接入】基于 Eino 切面，一键接入 Fornax Tracing，每次对话的完整调用链路、耗时、Token 消耗全都可查。

【AB 分流能力】三级节点标识（orchestration-implement-node），支持动态下发Graph编排中指定节点的策略配置，快速开启AB实验。

3.2 🎯 关键工程设计点#

3.2.1 🧱 框架选型：为什么选 Eino#

Eino 是字节内部 Go 语言 AI 应用开发框架，我们选它的核心理由：

🏎️ 性能强：Go 语言原生，高并发低延迟，天然适合实时外呼场景。

📦 组件丰富：ChatModel、PromptTemplate、Retriever（RAG）、Lambda 等开箱即用。

🔄 流处理完善：支持 Streaming 协议，自动处理流式/非流式节点间的转换，这对流式开发很关键。

🔌 切面可扩展：集成 Fornax Tracing，一行代码接入全链路追踪。

🧩 Graph 编排：通过节点图描述业务逻辑，清晰直观，支持分支、并行。

3.2.2 ⚡ 为什么不用 ReAct？——关于技术选型的思考#

调研阶段，我们认真评估了当下流行的 Agent 范式：

🔄 ReAct（思考→行动→观察）：每次回复需要多轮 LLM 调用，TTFT 直接飙到 5s+，实时外呼完全不可接受。

📋 Plan-Execute：先规划后执行，更适合异步复杂任务，实时对话场景不适用。

✅ 最终选择——轻量 Graph 编排（PE + RAG + LLM）：

Prompt 注入上下文 + RAG 案例，用一次 LLM 调用完成对话，流式输出保证低延迟。这是「在约束条件下的最优解」，而不是技术上最炫酷的方案。

3.2.3 如何支持灵活实验#

实验能力是整个系统的生命线。我们设计了三级节点标识体系：

• Level 1: orchestration（编排层）：Graph 的整体结构
• Level 2: implement（实现层）：编排实例，对应一套特定的节点配置
• Level 3: node（节点层）：节点参数（如chatmodel节点的max_tokens、temperature等参数）

通过动态配置下发，可以在不改代码的情况下，对任意粒度进行 AB 实验。这让我们能在同一个生产环境里同时跑多个实验，互不干扰。

注：原文此处为在线画板或外部图片占位，离线归档时已移除；本文已补充结构化示意图辅助理解。

3.2.4 稳定性与容错设计#

注：原文此处为在线画板或外部图片占位，离线归档时已移除；本文已补充结构化示意图辅助理解。

3.2.5 可观测性#

借助 Fornax Tracing + Eino 切面，我们实现了：

• 实时查询：直接在 Fornax 工作台搜索某次外呼的完整调用链，包括 Prompt 内容、RAG 召回了什么、模型返回了什么
• 离线分析：Trace 数据实时写入小时级 DW 表，可以用 SQL 批量分析 BadCase
• 成本监控：每次外呼的 Token 消耗、API 费用全程可追踪

4. 📊 效果表现：做出来之后怎么样#

4.1 🏆 效果对比（Agent vs SFT）#

以 Doubao 2.0 Mini vs SFT 为例的核心效果数据：

━━━━━━━━━━━━━━━━━━━━━━━━━━

📈 对话合理率：90.99%（Agent）vs 85.77%（SFT） +7.37pp ✅

💰 成本/千次：0.22元（Agent+缓存）vs 0.4元（SFT） 降低 45% ✅

⏱️ TTFT P90：700ms（Agent）vs 200ms（SFT） 慢约 500ms（可接受）

🔄 迭代周期：2.5周（Agent）vs 4周（SFT） 快 38% ✅

━━━━━━━━━━━━━━━━━━━━━━━━━━

4.2 ⏱️ 关于 TTFT 慢 500ms：为什么业务仍可接受#

这是个值得单独说的问题。Agent 的 TTFT 比 SFT 慢了约 500ms，但我们做了两件事让它可接受：

1. 语气词填充策略：当模型思考超过阈值（200ms）时，先输出「嗯」「好的」等语气词，商家感知到的是「对话在进行」而不是「电话卡了」。

2. 端到端看整体体验：整个外呼的端到端延迟约 1.2s（ASR+Agent+TTS），其中 ASR+TTS 约占 1s，Agent 本身的增量延迟在可接受范围内。

3. 业务验证：通过 AB 实验，核实率是正向的，证明用户体验可接受。

4.3 💰 成本分析：缓存是关键#

成本降低 45% 的关键在于 Prompt 缓存：

• 不开启缓存：0.37 元/千次（已优于 SFT 的 0.4 元）
• 开启缓存：0.22 元/千次（命中率60%+，降低 50%）

💡

缓存命中率怎么得出来的？

平均对话轮次4.75轮，从第二轮开始，prefix完全相同，粗估命中率3.75/4.75≈79%

后续可以继续优化prompt，将system prompt中的动态变量抽取出来。

5. 🧠 工程侧 Learning#

5.1 Learning 1：技术选型要务实，别「自 high」#

实践回顾：我们最初调研了 ReAct、Plan-Execute 等范式，但在实时外呼场景下，多轮 LLM 调用让 TTFT 直接飙到 5s+，业务完全不可接受。

最终选择 Graph 编排（PE + RAG + 单次 LLM 调用）——这不是最「酷」的方案，但是约束条件下的最优解。

💡 原则：对话模型的最优解不是最强模型，而是最适合业务链路的模型。延迟、成本、效果三者必须一起看，任何单点最强都不是赢法。

5.2 Learning 2：外呼效果瓶颈不止「对话生成」#

一个容易忽视的认知：对话做得再好，如果解析出错，最终核实结果还是错的。

外呼效果链路：ASR 识别 → 对话生成 → 意图解析 → 核实结果

每个环节都会折损。我们通过引入 Qwen3-Omni-30B（支持音频输入）优化解析模型，名称电话核实准确率提升了 6.2pp（91.3% → 97.5%）。这证明：解析 Agent 和对话 Agent 同样重要。

📌 后续规划：从「对话 Agent」扩展到「解析 Agent」，再到「解析+对话协同的完整 Agent 体系」。

5.3 Learning 3：评估成本不能只看增幅，也要看绝对值#

通过替换更强的模型来达到能力提升，往往意味着成本上升，但是评估成本也不能只看增幅。

以解析模型为例，目前日成本200多元，即使成本翻倍，如果能带来可观的核实能力提升or迭代效率提升，也是可以接受的。

5.4 Learning 4：低中转链路——尽量减少中间层和协议跳转#

对智能外呼来说，这种思路很重要：链路越短，延迟越低，故障点越少，也越容易做高并发稳定性保障。

踩过的坑：

• 最开始采用AI Paas的A2A框架，但是后来测试发现存在1.5s的耗时开销 -> Agent集成在外呼服务中
• Eino的graph编排的streaming输出存在阻塞 -> 但是Eino框架我们必须依赖，故通过callback机制异步传出stream reader

6. 🧭 算法分享一：评测体系 —— Agent 快速迭代的地基#

6.1 🎯 把评测放在第一位#

评测体系的成熟度 = 方案迭代速度的天花板。

在 Agent 研发中，任何优化动作本质上都是 “假设 A 比 B 更好”，是否成立，完全取决于评测。三个原因：

1. 没有可信指标 → 一切 “看起来更好” 都是错觉。 少量人工抽样下，A/B 互有胜负，噪声淹没真实差异，迭代退化为掷骰子。#

2. 指标定义模糊 → 对齐成本爆炸。 “合理性” 并非非黑即白，人均一把尺子时，跨实验、跨周均不可比。#

3. 评测集即 Agent 的事实优化目标。 怎么定义好坏，模型与 Prompt 就朝那个方向被驱动；指标有盲区，Agent 必然 “钻空子”。#

6.2 🛠️ 我们做了什么#

围绕「逐句对话」与「结果解析」两类任务，沉淀了一套覆盖 4 种数据来源（离线 SFT / 离线 Agent / 在线 SFT / 在线 Agent）、5 个评测维度（合理性、GSB、RAG 相关性、问题说明、结果解析）的评测工艺；针对多版 Prompt × 多模型的对照实验框架，每次模型/Prompt/RAG 变更均沿同一标准回归。详细规范见对话模型评测工艺。

6.3 📐 评测工艺的设计原则#

这套工艺抽象出来的设计原则，对其他 Agent 评测同样适用：

• 分层指标，主辅分明：主指标（如核实正确率、合理性）决定上下线；辅指标（核实率、GSB、RAG相关性等）用于分析与归因。
• 评级离散化，标准可枚举：将合理性划分为满分、合理、一般错误、严重错误四档，并对应具体的评价维度（准确性、流畅性等），确保人工评测结果的一致性。
• 错误归因结构化：Bad case 必须打上具体错误类别（如意图识别错误、虚构信息等），连接“评测”与“优化”，实现规模化驱动迭代。
• GSB 用于细粒度对比：在主指标接近时，引入 GSB（A优/持平/B优）评估指标无法体现的细微体验差异。

7. 🧩 算法分享二：模型选型 —— 综合权衡优于单点最强#

7.1 📐 选型框架#

核心观点：模型选型不是“选最强的”，而是“选最合适的”。必须抛弃通用榜单，使用真实业务数据基于“效果、性能、成本、稳定性”进行综合权衡。

外呼场景具有特殊性（短文本、口语化、多轮主动追问、枚举输出），必须使用真实业务数据综合评测。

• 🎯 效果：合理率、核实正确率（业务最终指标）
• ⚡ 性能：TTFT P90 < 1s（外呼场景对响应速度极度敏感）
• 💰 成本：元 / 千次请求（决定规模化上限）
• 🔒 稳定性：成功率 > 99.9%

7.2 🔬 我们做了什么#

围绕「对话生成」与「结果解析」两条主线，对 10 候选模型 × 6 版 Prompt × 文本/音频两种模态进行了系统评测：

覆盖 Doubao Seed 系列（mini / lite / pro）、Gemini 3.1 Pro / Flash-Lite、豆包端到端语音大模型、Qwen3-Omni-SFT 等；指标包括离线/线上合理率、TTFT P90、成本、稳定性等。

具体评测细节：

智能外呼Agent-对话能力分析和

智能外呼Agent-分析报告

7.3 💡 核心 Learning#

7.3.1 选型方法论#

1. 综合权衡优于单点最强：效果、延迟、成本互相制约，业务约束内的最优才是”最合适”；只盯榜单第一，落地时一定被打回。#

a.

规模化阶段，我们最终上线的是 Doubao 2.0 Mini（TTFT P90 700ms），而非能力更强但更贵更慢的 Doubao 2.0 Pro。

b.

Gemini pro 成本是 seed-2.0 的 5 倍以上、效果未能反超。Gemini 的强在 “复杂长推理场景”，外呼任务是 “相对简单场景 + 中文口语噪声”，强模型的能力被浪费在不相关的维度上。

• 豆包端到端语音大模型成本过高，短期不具备规模化条件。 文本和音频模态日成本高达数万元，尽管端到端在延迟和自然度上有理论优势，但当前成本结构下，“ASR + LLM + TTS” 级联架构仍是更务实的选择。

2. 识别并守住硬约束：每类业务都有自己的红线指标，未达标即一票否决。对外呼对话而言，延迟就是硬约束 —— 首字响应 1400ms 与 700ms，是 “明显卡顿” 与 “自然衔接” 的差别。任何方案，哪怕效果指标再亮眼，只要会显著伤害对话体验，就必须慎重权衡，乃至直接摒弃。

3. 缓存命中率是被低估的成本杠杆。当前 60% 的 Prompt Cache 命中率已显著压缩 LLM 成本，且模型越贵收益越大；通过话术模板归一化、Prompt 前缀复用等手段，可显著降低模型成本。#

7.3.2 模态与微调#

1. 多模态 ROI 不默认正向：语义信号已充分的任务 (如店铺名称核实) 中，引入音频反而让模型从声纹 / 口音 / 背景音过度推断，整体没有明显增益；只有在文本信号不足、必须依赖副语言特征才能完成判断的更难场景下(情绪识别、真实性判定) 才上多模态。
2. 警惕少样本微调的泛化性陷阱。 我们前期模型均基于 Qwen 微调，但接入 Agent 扩展场景时发现效果大幅回退 —— 本质是少样本微调过拟合到了训练分布，一旦上下文、调用链路或场景发生变化，泛化能力远不及原生大模型。结论：微调不是默认选项，只有在任务足够稳定、业务逻辑足够复杂、且数据规模与多样性都充分的前提下，才值得考虑；否则优先用 Prompt 与 RAG 在原生大模型上迭代。
3. 先选模型，再调提示词：提示词需要针对具体模型做适配，不同模型偏好差异大，先把模型定下来再针对性打磨。我们实践中 Gemma-4-26B 对提示词最不敏感（多版本波动 < 2pp），适合作为提示词未稳定阶段的基线。

8. 📚 算法分享三：RAG 建设与 Learning#

8.1 🤔 为什么外呼 Agent 需要 RAG#

用一个比喻：Prompt 是 “理论教材”，RAG 是 “实战案例库”。在外呼场景，Prompt + FewShot有两个明显短板：

• 难以覆盖商家的各种模糊表达（「嗯」「啊」「好像是」「差不多」）；
• 缺少 “什么回答 → 什么核实结果” 的经验积累。

RAG 在这里更像一个经验召回器—— 召回最相似的历史案例，让模型有据可依地回答。

8.2 🏗️ RAG 是怎么建设的#

索引阶段（离线）：针对原始对话文本（人工外呼核实案例 + 智能外呼标注数据）进行处理，分为以下四个阶段：

1. 对话切片：将多轮对话按固定窗口切分为 “客服提问→商家回答→客服应答” 三句式原子片段，使 RAG 检索粒度更精准。#

注：原文此处为在线画板或外部图片占位，离线归档时已移除；本文已补充结构化示意图辅助理解。

2. 个性化脱敏：通过模板正则将片段中的店铺名称、地址、电话等替换为通用占位符（如 “这边是 <占位> 吗”），使话术脱离特定 POI 绑定，成为可复用的泛化模板。#

3. 大模型意图标注：将脱敏片段送入大模型，结合核实目标列表逐句判定对应意图（如名称确认、营业状态、地址核实等），为每个片段赋予结构化意图标签。#

4. 去重与分类归档：按内容去重后，依意图组合分类，基于ByteRAG构建可按意图索引的向量化数据库。#

检索阶段（实时）：当前对话 → Query 构造 → 多通道召回（向量索引+文本索引，多字段） → Rerank → Top-K 案例 → 注入 Prompt。

8.3 🎯 RAG 优化中的关键问题#

我们在 RAG 建设中踩过的坑和对应解法：

• V1 整段做向量索引与召回，发现商家关键语义被同片段中的客服话术、过渡语稀释，相似度被”无关原文”主导，命中不准
• V2 仅基于商家话术召回，索引与 Query 都只保留「商家说了什么」，剥离客服侧内容，语义更聚焦；RAG 忠实度提升至 82%+
• 🔍 意图过滤：先识别当前核实意图（名称 / 营业状态 / 营业时间），只召回同类意图案例，避免”跨意图污染”。
• 🔇 噪声控制：设置相似度阈值，低于阈值宁可不召回，也不让弱相关案例干扰模型判断。
• ⚡ 时延控制：检索目标 < 200ms，通过内部 ByteRAG + Top-K ≤ 3 （最多召回 3 条）实现。

8.4 💡 核心 Learning#

1. RAG 不是”有就行”，质量决定上限：数据质量和召回策略才是天花板，一个精准的 RAG 胜过十个泛泛的 RAG；接入前先想清楚”召回什么、为什么准”。#

2. 每一步改动都用基线量化收益：迭代节奏应该是 无 RAG → V1 → V2 → …，每步都和上一步对照打分；这样既能清晰看到每次改动的真实增益，也便于在收益不达预期时快速回退或换方向，避免”做了但说不清效果”。

3. 业务案例 > 泛知识库：垂直场景里，少量高质量的真实业务案例往往胜过海量通用知识；对外呼来说，100 条高质量真实对话比 1000 条通用知识更有价值。#

4. RAG 是 Prompt 的补位，不是替代：Prompt 提供”规则框架”，RAG 补充”经验细节”，两者相辅相成。#

9. 🔮 下一步方向#

9.1 当前问题与 Gap#

坦诚地说，当前还有几个明显的问题需要解决：

1. 平台化能力落后：自助化程度不够，限制了agent迭代效率，也限制了产运自助优化agent策略

2. 解析环节是短板：ASR 错误传导、复杂语义误判，解析 Agent 建设滞后于对话 Agent

扩展到更多外呼场景

只有将验证过的成功模式复制到营业时间核实、潜客挖掘等更广阔的业务中，技术的红利才能真正兑现为商业价值。

持续优化 PE / RAG

这是在现有架构下，投入产出比最高、见效最快的效果提升手段。

建设更完善的 Agent 平台

将研发从无穷无尽的配置修改和查 case 琐事中解放出来，打造agent“自助生产线”，让产运也能参与agent策略迭代。

引入长短期记忆 (Memory)

不带历史背景的对话是冰冷的，记忆是跨越多次通话、提供 “拟人化” 温情服务的关键。

探索语音大模型/多模态链路

彻底绕过 ASR 识别错误的顽疾，并捕捉语音中的细微情绪，这很可能是对话 Agent 体验实现质变的终极武器。

下一步核心方向

为什么这件事最优先？（背后的战略考量）

9.2 🗺️ Q2 Roadmap#

注：原文此处为在线画板或外部图片占位，离线归档时已移除；本文已补充结构化示意图辅助理解。

9.3 P0（当前进行中）：MVP场景放量 + PE模块化管理#

• 对话 Agent 在营业状态场景推全，验证规模化可行性。
• PE模块化管理：对话核实prompt按核实目标维度组织为prompt片段，支持快速拼接新场景prompt，为业务场景拓展提供底层可扩展能力

9.4 P0（TODO）：能力深化 + 平台化#

• 多场景扩展：核实工商执照挂接关系等新业务场景接入
• 外呼产线配置平台化，支持后续新场景配置接入、调研送呼配置、AB实验组别配置
• 实验平台升级：支持更多维度的 AB 实验，加速迭代
• 解析 Agent：将解析链路也 Agent 化，先满足新场景落地需求，后续通过ReAct 框架升级等方式提升解析能力
• 短期记忆（Memory）：引入 Session 级别的对话记忆，作为case分析、RAG构建等能力的基础数据
• Agent 管理平台：可视化编排，自助接入，产运可配，降低研发门槛
• 评测提效：通过人工评测线上化、自动化评测（评测工艺->评测agent）等方式缩短评测周期，保证评测质量
• 线上数据收集 → BadCase 自动识别 → RAG 知识库自动更新 & autoPE优化 → 效果验证 → 循环

9.5 P1（探索）：语音大模型#

• 语音大模型（S2S）：跳过 ASR/TTS，直接端到端语音对话，解决 ASR 识别错误问题

10. 🎯 总结#

智能外呼 Agent 不只是「模型替换」，而是一次从 SFT 到「可配置、可实验、可持续迭代」的系统性升级。

📌 我们已经验证了什么：

✅ Agent 路线在效果上可行：对话合理率 90.99%，超越 SFT（85.77%）

✅ Agent 路线在成本上更优：0.22 元/千次 vs SFT 的 0.4 元/千次（-45%）

✅ Agent 路线在效率上更快：迭代周期 2.5 周 vs SFT 的 4 周（-38%）

✅ 工程体系可扩展：AB 实验、Tracing、PE 管理、节点化配置

📌 真正决定后续上限的，不只是模型：

• 平台化能力：降低接入门槛，才能横向扩展更多场景
• 工程体系：稳定性、可观测性、实验能力决定迭代速度
• 数据飞轮：BadCase 分析、真值积累和 RAG 知识库的建设决定能力上限

💬 最后一句话：

我们做的不是「最复杂的 AI」，我们做的是「最有效果的外呼 Agent」——在实时性、成本、效果、可迭代性的约束下，找到当前最优解，并建立持续进化的能力。

这个过程里最重要的认知是：技术选型要务实，数据驱动要严谨，工程能力要扎实，不要为了技术而技术。

11. 📎 附录#

11.1 术语表#

术语

说明

ASR

Automatic Speech Recognition，自动语音识别

VAD

Voice Activity Detection，语音活动检测

TTS

Text-to-Speech，文本转语音

TTFT

Time To First Token，首 Token 延迟

S2S

Speech-to-Speech，端到端语音大模型

PE

Prompt Engineering

RAG

Retrieval-Augmented Generation，检索增强生成

GSB

Good-Same-Bad，两两对比评测方法

Eino

字节内部 Go 语言 AI 应用开发框架

Fornax

AI Agent Ops 平台，提供 Tracing 和 PE 管理