| AI适用性判断 |
确定任务是否需要引入 AI、若需要何种形式最简单、以及当前是否具备构建条件的决策工作。 |
| 解决方案之梯 |
从最底层的规则与查询开始,依次经过检索、分类与预测模型、生成模型调用、工作流,直至最顶层的智能体,按照由轻到重的顺序构建的框架。若底层方案即可达到目的,则不选择更上层的方案。 |
| 规则与查询 |
对于输入和规则明确且结果唯一的任务,通过条件分支或数据库查询进行处理的方式。 |
| 检索增强生成 |
先通过检索找到依据文档,再结合该依据生成答案的架构。适用于需要基于模型未知的企业内部文档或最新信息组织语言回答的场景;若仅需查阅原文,则单纯检索即可满足需求。 |
| 工作流 |
将 LLM 与工具按预设代码路径编排而成的系统(Anthropic 的定义)。 |
| 智能体 |
由 LLM 自主决定执行流程与工具调用的系统。适用于步骤数无法预估的开放性问题。 |
| 路由 |
对输入进行分类并分发至专门的后续处理环节的工作流形态。 |
| 评估器-优化器 |
一次调用生成结果,另一次调用提供评估与反馈的循环迭代架构。适用于评估标准明确的场景。 |
| 自动化与辅助 |
代替人工执行工作(自动化)与协助人工完成工作(辅助)。在风险较高的场景下,通常由人工掌握控制权,采用辅助模式。 |
| 高影响人工智能 |
应用于韩国《人工智能基本法》第2条第4项所规定的领域(招聘与贷款审批等判断与评估、公共服务资格认定、学生评价等),可能对生命、安全和基本权利产生重大影响的人工智能系统。 |
| 生成式人工智能 |
通过模仿输入数据的结构与特性,生成文本、声音、图像、视频等内容的人工智能系统(韩国《人工智能基本法》第2条第5项)。 |
| 人工智能业务经营者 |
开发并提供人工智能的主体(开发经营者)以及利用其提供产品或服务的主体(利用经营者)。亦包含国家机关等。 |
| 事先告知 |
向用户预先告知利用高影响或生成式人工智能的产品或服务是基于该人工智能运行的法定义务(韩国《人工智能基本法》第31条第1款)。 |
| 生成结果标识 |
对生成式人工智能的输出内容标识其系由生成式人工智能生成的法定义务(第31条第2款)。 |
| 高影响确认 |
经营者预先审查是否属于高影响范畴,并在必要时可向科学技术信息通信部长官申请确认的法定程序(第33条)。 |
| 自动化决策 |
完全依托自动化系统(含 AI)处理个人信息而作出的决定(韩国《个人信息保护法》第37条之2)。依照韩国《行政基本法》第20条由行政机关作出的自动化处分除外。若对权利或义务产生重大影响,当事人享有拒绝权。 |
| 成功标准 |
判定功能是否成功的标准。须具备指标、数据、基准值、基准线以及测量方法。 |
| 上线阻断标准 |
若未达标,即便其他指标表现优异亦不得上线的硬性标准。通常针对触犯法律与合同违约或可能导致用户利益受损的项目设立。 |
| 改进目标 |
上线后持续追踪并着力提升的水平目标。通常设在不影响正常使用的质量项上。 |
| 基准线 |
作为对比起点的当前水平。例如人工操作或既有系统的性能表现。 |
| 精确率 |
在判定为正例的样本中,实际为正例的比例。在误报代价高昂的功能中须重点保障该指标。 |
| 召回率 |
在实际为正例的样本中,被成功识别出的比例。在漏报代价高昂的功能中须重点保障该指标。 |
| 假正例与假负例 |
将非正例误判为正例的错误,以及遗漏真正例的错误。需权衡两者的代价来决定重点保障的指标。 |
| F1 分数 |
综合考量精确率与召回率的调和平均指标。 |
| 输入契约 |
功能所接收输入的范围(语言、格式、长度、必填信息)以及超出范围时的处理规则。 |
| 输出契约 |
功能所返回结果的格式、空值处理以及校验失败时的处理规则。 |
| 结构化输出 |
约束响应遵循指定 JSON Schema 的功能。在模型拒答或达到 max_tokens 上限时可能会偏离该格式。 |
| Schema |
规定输出结果的字段名称、格式以及是否必填的规范说明。 |
| TTFT |
发送请求后输出首个 token 所需的时间。它直接决定了用户在屏幕前等待时的体感延迟。 |
| 流式传输 |
在全部输出完成之前即开始回传响应的方式。即便总耗时相同,也能提升体感响应速度。 |
| 批处理 |
将无需即时响应的大量请求汇集并进行异步处理,以降低成本并提升吞吐量的方式。例如 Anthropic 的 Message Batches API 可降低 50% 的成本,且绝大多数任务在 1 小时内完成,若超过 24 小时未完成则自动失效(2026-10-22 确认)。 |
| max_tokens |
输出 token 数量的上限。一旦触及上限,生成过程会在句子或结构化数据中途中断,因此它不应用于调节长度,而应作为成本与延迟的上限兜底,并需检查生成停止的原因。 |
| 评估 |
衡量模型或功能性能的结构化测试。由评估集、评分方式和成功标准构成。 |
| 评估集 |
用于评估的输入与期望结果集合。须能够代表实际业务使用的分布情况。 |
| 边界案例 |
无关输入、超长输入、有害输入,以及人工评判也存在分歧的模糊案例等极易导致失败的用例。 |
| 保留集 |
在优化调整过程中不参与查看、仅用于最终评定的评估集子集。用于防范过拟合。 |
| 过拟合 |
因针对同一评估集过度优化调整,导致评测得分虚高于实际真实性能的现象。 |
| 代码评分 |
通过精确匹配、字符串包含、格式校验等基于代码逻辑进行评判的评分方式。速度最快且最可靠。 |
| LLM 评分 |
依据给定评分量表由 LLM 对结果进行裁定的评分方式。适用于复杂判断,但须预先与人工评分对照以验证其可靠性。 |
| 人工评分 |
由人工进行裁定的评分方式。虽然是质量的金标准,但耗时且成本高昂,通常用于构建基准数据及校准。 |
| 评分量表 |
详细列明各评估维度的评判标准与分值量表,以提高评分一致性的评分标准表。 |
| 位置偏差 |
LLM 评分器根据回复呈现顺序的不同而改变裁决的倾向。可通过调换顺序进行成对对比来减轻该偏差。 |
| 盲测对比 |
评估者在不知晓具体版本的情况下,将两份结果并排进行对比的评估方法。 |
| 能力评估 |
由当前尚不擅长的任务构成、从较低通过率起步的评估。 |
| 回归评估 |
用于确认既有优势任务是否依然稳定保持的评估。通过率应接近 100%。 |
| 评估饱和 |
评估任务已全数通过,无法再展现进一步优化空间的饱和状态。 |
| pass@k |
在 k 次尝试中至少成功一次的概率。 |
| pass^k |
k 次尝试全部成功的概率。适用于每次调用都要求稳定品质的功能。 |
| 离线评估 |
基于预先准备的评估集进行测算,无需面向终端用户发布的评估方式。 |
| 在线指标 |
在实际生产运营中测量的指标(重新生成、转人工客服、跳出、举报、购买转化)。 |
| A/B 实验 |
将用户随机分流以对比两种方案指标的实验方法。适用于风险较低且流量充足的场景。 |
| 凭空编造 |
将毫无根据的内容当作事实生成的失效现象(幻觉)。可以减少但无法彻底消除。 |
| 过度拒答 |
连本可回答的问题也一并拒绝的失效现象。由于该问题不会体现在错误答案的比例中,因此须单独统计合规可答问题的拒答率。 |
| 格式错误 |
因未遵守约定的输出格式而导致前端界面或系统对接崩溃的失效现象。 |
| 指数退避 |
每次重试时逐步延长等待间隔的重试机制。 |
| 渐进降级 |
即便 AI 功能停摆,也能确保核心业务通过更简单的路径继续运转的设计。 |
| 事前审批 |
所有结果均须经人工核实后方可对外输出的人工介入机制。 |
| 条件转交 |
仅在置信度较低或触发风险条件时才转交人工处理的人工介入机制。 |
| 事后抽检 |
自动生效应用后,定期抽取部分样本进行复查的人工介入机制。 |
| 申诉复核 |
接收结果的用户提出请求时,由人工重新处理的人工介入机制。 |
| 形式化审批 |
审核人员缺乏依据或权限,对几乎所有结果照单全收,导致监督机制形同虚设的状态。 |
| 自动化偏差 |
人类不加甄别地接纳 AI 建议的倾向。这是造成形式化审批的主要诱因。 |
| 严格工具输入 |
强制工具名称与输入值严格遵循所定义 Schema 的设置(strict tool use)。 |
| 信任校准 |
引导用户合理调整信任程度,使其既能在特定场景下信赖 AI,又能在必要时刻主动进行复核的工作。 |
| 隐式与显式反馈 |
记录在日志中的用户行为(隐式)与用户主动留下的意见反馈(显式)。 |
| 背景错误 |
系统虽运行异常,但用户与系统本身均未将其识别为错误的失效现象(Google PAIR 提出的 background errors)。亦称静默失败。 |
| 影子测试 |
将真实请求的副本发送给新版本,但仅向用户返回既有版本结果的测试方式。 |
| 金丝雀发布 |
将变更限制在极小比例的生产流量中进行限时灰度部署,通过与对照组对比评估,确认无误后再逐步扩大覆盖范围的方法。 |
| 对照组 |
在相同时期内使用既有版本的对比群体。 |
| 中止标准 |
上线前预先设定的指标及其阈值,一旦超出该阈值便停止放量并执行回滚。通常需一并指定判定的最小样本量。 |
| 功能特性开关 |
无需部署代码即可开启、关闭功能或调整其开放范围的机制。 |
| 护栏指标 |
在实验或发布过程中,即便目标指标向好,也绝不允许超出容许限度而恶化的指标(举报率、退款率等)。 |
| 模型生命周期 |
模型的支持与停用状态及其变化。例如 Anthropic 将其划分为 Active、Legacy、Deprecated、Retired,向已下线(Retired)模型发送的请求将会失败。具体状态与时间表须针对各厂商及提供平台逐一确认。 |
| 复盘 |
记录事故经过、影响、应对措施、原因以及防范复发措施并展开讨论的机制。 |
| 无指责复盘 |
不归咎于个人或团队,专注于探寻诱发原因的复盘方式。 |