过去两年,生成式 AI(GenAI)从技术圈的前沿话题迅速走向企业核心业务:智能客服、企业 Copilot、研发提效、流程自动化、AI Agent……
然而,当越来越多的人开始“用”AI,另一个问题也随之浮现:我们是否真正理解它?
RAG、Agent、MCP、MoE、DPO、Graph RAG、Tool Calling、AI Governance……
这些术语频繁出现在技术文章、产品发布和架构讨论中,却往往停留在“听过”“大概知道”的层面,难以形成系统认知,更谈不上指导企业落地。
这些术语频繁出现在技术文章、产品发布和架构讨论中,却往往停留在“听过”“大概知道”的层面,难以形成系统认知,更谈不上指导企业落地。
这篇文章试图解决的,正是这个问题:
系统性地梳理 GenAI 领域的核心专业术语,并从企业视角解释它们“是什么、怎么工作、什么时候该用”。
无论你是工程师、产品经理、业务负责人,还是管理层决策者,都可以通过这份全景式指南,建立一张清晰、可落地的 GenAI 知识地图。
系统性地梳理 GenAI 领域的核心专业术语,并从企业视角解释它们“是什么、怎么工作、什么时候该用”。
无论你是工程师、产品经理、业务负责人,还是管理层决策者,都可以通过这份全景式指南,建立一张清晰、可落地的 GenAI 知识地图。

一、基础模型与训练 (Large Models & Training)
核心涵义:本部分涵盖大型语言模型(LLM)及其底层架构(Transformer)、训练范式(预训练与微调)和模型对齐技术等。大型模型掌握通用语言能力,借助预训练获取广泛知识,通过微调和人类反馈强化学习提升对用户指令的理解和符合性。以下是相关术语的定义、原理及应用场景:
| 术语 | 类别 | 定义 | 关键原理 | 企业场景 | 价值 |
|---|---|---|---|---|---|
| LLM(大型语言模型) | 模型 | 参数规模达数十亿甚至数万亿的深度神经网络,具备理解和生成自然语言的能力。典型如GPT-4、Claude等,能执行对话、问答、翻译、代码生成等广泛任务。 | 通常采用Transformer架构,在庞大文本语料上进行自监督预训练,通过统计语言模式来学习语法、语义和知识。参数规模越大,模型往往出现涌现能力,完成小模型难以胜任的复杂任务。 | 企业智能客服、知识问答、文档分析等场景中作为核心AI引擎为用户提供类人对话与内容创作服务。 | 自动化处理文本密集型任务,提高人机交互效率。能总结报告、生成内容,减轻人工负担,提高生产力。 |
| Transformer 架构 | 模型 | 2017年提出的深度学习模型架构,奠定了现代LLM的基础。核心特征是多头自注意力机制,能够并行处理序列中任意位置的元素。 | Transformer利用自注意力让模型对输入序列中每个词之间关系赋予不同权重。与RNN不同,Transformer可以有效捕捉长距离依赖,极大提升序列数据处理效率。 | 几乎所有当代LLM(如BERT、GPT系列)都采用此架构。企业在自研或部署AI模型时使用Transformer作为标准架构,以确保模型性能和扩展性。 | 提供高并行性和长程依赖捕获能力,使训练和推理速度大幅提升,支持处理长文本文档。使大模型成为可能。 |
| 预训练(Pre-training) | 训练 | 在大规模未标注数据(如整个互联网文本)上以自监督任务训练模型的阶段。目标是学习通用语言模式和世界知识,为后续特定任务打下基础。 | 常采用遮挡预测或下一个词预测等任务,使模型掌握语言结构和常识。预训练生成基础模型(Foundation Model),具有广泛知识和生成能力,但未针对具体任务优化。 | 企业通常从开源或商业预训练模型(如GPT-3)出发,再进行定制化。这允许企业利用预训练模型的通用能力,减少从零训练所需的数据和成本。 | 提供通用智能“底座”,让模型具备广博知识和语言理解能力。显著降低企业训练AI的门槛和成本(相比完全自研模型),加速AI项目落地。 |
| 微调(Fine-tuning) | 训练 | 在预训练模型基础上,用少量特定领域标注数据进一步训练模型,使其适应特定任务或场景。也称“专业训练阶段”。 | 固定预训练模型的大部分参数,仅调整部分层(或添加小型适配器层),令模型在有监督标注数据的指导下优化性能。Fine-tuning成本远低于从头训练,能让预训练模型快速掌握领域专用格式/风格。 | 企业使用fine-tuning将通用模型定制为内部助手或行业模型。如在企业法律文档上微调LLM用于法律咨询,或用公司客服历史问答微调模型用于客服辅助手段。 | 能快速适配模型到垂直领域,提高输出的专业性和准确度。相对预训练极大降低额外数据需求与训练时间。 |
| SFT(监督微调) | 训练 | Supervised Fine-Tuning的缩写,即在预训练模型上进行指令数据的有监督精调。例如让模型学习高质量问答对话示范,学会遵循人类指令进行回复。 | SFT本质是微调的一种特殊形式,使用人类提供的问答或对话示例数据对模型参数进行微调。其核心思想是迁移学习:将预训练模型岗位培训成更擅长“遵循指令”的助手。通常在RLHF之前进行。 | 以ChatGPT为代表的大模型都是经过SFT,使其学会遵循用户自然语言指令、提供有帮助的回答。企业内部构建专属Copilot时,也往往先用SFT阶段使模型学会企业沟通风格和任务格式。 | SFT让模型更听懂人话,按照示范模式提供符合指令的回答。显著提升LLM的易用性和实用价值,使其输出更贴合用户需求。 |
| RLHF(人类反馈强化学习) | 对齐 | Reinforcement Learning from Human Feedback,一种将人类偏好融入大模型训练、对齐模型行为的方法。RLHF通过人类对模型输出的反馈(比如偏好评级)来微调模型,使其输出更符合人类期望和价值观。 | RLHF训练分多步:首先收集人类对模型输出的偏好数据,训练一个奖励模型(Reward Model)衡量输出质量;然后对LLM应用强化学习(常用PPO算法),不断调整模型参数以最大化奖励。这一步骤建立在前一阶段SFT模型之上,以人类反馈作为优化目标。 | ChatGPT的成功在很大程度上归功于RLHF,使得模型回答更礼貌、有用且无害。企业在部署LLM时,也会考虑使用RLHF(或类似方法)基于企业用户反馈进行额外训练,让模型更贴近企业调性和用户需求。 | RLHF显著提高模型的可靠性和用户满意度。输出更符合人类偏好和安全标准,减少无关或有害内容。这使模型更适宜在商业场景下直接面对用户。 |
| DPO(直接偏好优化) | 对齐 | Direct Preference Optimization,2023年提出的一种替代RLHF的简化模型对齐算法。通过跳过奖励模型的构建,直接利用人类偏好比较数据来优化模型参数,从而简化对齐流程。 | 相比RLHF需要独立训练奖励模型并用RL算法优化,DPO假设LLM自身可看作隐含的奖励模型。DPO利用人类标注的**“优选/不优选”**输出对,构造损失函数直接优化LLM,使其倾向人类偏好的输出。由于无需训练额外模型和复杂的RL过程,方法更简洁稳定。 | 能用于企业对齐模型行为的快速迭代。例如在开放域对话或营销文案生成中,企业可通过收集用户偏好数据集,用DPO方法直接对模型进行一次性微调,从而降低RLHF的工程复杂度。 | 降低了模型对齐的技术门槛和不稳定性。无需复杂的三阶段训练,使模型更易控。对齐过程简单可靠,有助于企业更快调整模型输出风格,减少训练资源占用。 |
| MoE(Mixture-of-Experts) | 模型 | 混合专家模型,通过多个“专家”子模型协作组成的大模型架构。特点是模型参数虽极为庞大,但每次推理时仅激活部分专家参与计算,从而平衡超大模型容量和计算效率。 | MoE将Transformer的前馈层替换为包含多个专家网络的稀疏层,由门控网络学习决定每个输入应送至哪些专家处理。例如Switch Transformer启用任意输入的一小部分专家,使模型拥有千万亿级参数却保持可接受的推理速度。 | 超大模型(千亿/万亿参数级)且部署受限于计算资源的场景下会采用MoE。例如企业需要离线部署一个能力极强的语言模型,可选择含MoE架构的模型以在有限硬件上实现高性能推理。 | MoE架构提供高效扩展:在不显著增加计算成本的情况下扩大模型容量。使大模型能更快预训练、推理更快。同时每个专家可专长不同任务,提升模型对复杂多样任务的适应性。 |
| 多模态(Multimodal) | 模型 | 指模型可以同时处理多种类型的输入/输出模态,如文本、图像、音频和视频等。典型如GPT-4的多模态版本可以理解图像并输出文字说明。 | 通常通过在LLM架构中融合视觉、音频编码器等跨模态模块实现。模型学习将不同模态数据映射到统一向量空间以理解关联。例如CLIP模型将图像和文本embedding映射统一空间。 | 用于跨媒体内容理解和生成的企业应用:如智能产品视觉识别助手,可基于产品图片自动生成描述文案;或会议辅助AI,既能听取语音又能输出会议纪要。 | 扩展了AI适用范围,使模型能处理企业真实场景中多模态信息,比如读懂表格、图片等数据,提供更全面的智能服务。组合多模态可以提升任务精度,也创造新应用可能性(如人机协作设计)。 |
| 上下文长度 (Context Window) | 模型 | 模型单次推理时可接收的最大文本长度,通常以Token数量衡量。例如GPT-3的上下文长度约4,000 token,而Claude-2达到100万token,可处理非常长的文档。 | 上下文窗口受Transformer结构中位置编码和显存限制影响。更长的上下文需要改进的架构或检索机制(如稀疏注意力、RAG)来处理。新技术扩展上下文至百万Token以上,让模型能全局分析长篇幅内容。 | 需要处理长文档或持续对话的企业应用:如法律合同审阅(动辄数万字)、长周期项目会议记录分析、多轮客服对话跟踪等。大上下文窗口模型允许一次性纳入完整文档或长对话进行推理。 | 提升模型“记忆力”,避免频繁分段处理。支持更复杂的长文场景,减少上下文窗口不足导致的信息丢失和重复沟通。提高长文本分析、长期对话场景下的准确性和用户体验。 |
| 分词器(Tokenizer) | 模型 | 将连续文本切分为基本符号(Token)的工具。Token可视为模型处理文本的最小单位,例如GPT模型通常以子词粒度的Token作为输入输出。 | 常用BPE(字节对)或SentencePiece算法,根据语料频率将词拆成子词或字符序列。好的分词能平衡词汇量与泛化能力:既减少罕见词拆分过长,也保留基本词义单元。 | 针对不同语言、领域需要自定义分词策略。例如处理多语言文本、编写代码或化学公式时需要特殊token化规则。企业在预处理内部文档数据时也会侧重自定义分词以优化模型理解精度。 | 决定模型输入如何被编码理解。高质量的分词提升模型效率和性能;反之不当的分词(如将常见词过度拆分)会降低模型效果、增加token成本。对于中文等无空格语言尤其重要。 |
| 推理(Inference) | 模型 | 指模型在部署后接受输入并生成输出的过程,即应用阶段的预测/生成过程。也称“推断”。在LLM场景,推理通常指模型根据提示生成文本回答。 | 推理时模型根据内部参数和推断算法(如前向传播、采样策略等)输出结果。与训练不同,推理不更新参数,但需考虑温度、Top-p等解码超参数调控输出风格。推理效率受模型大小和硬件算力影响。 | 所有使用LLM功能的应用场景都是模型推理在起作用:如对话问答、文本摘要、代码生成等。这是模型为企业用户提供服务的阶段。 | 快速高效的推理决定了服务响应速度和成本。改进推理性能(如模型量化、优化硬件)可以降低延迟和计算开销,提升用户体验和企业ROI。 |
| 延迟(Latency) | 模型 | 在AI系统响应请求的延迟,即从接收输入到输出结果所需时间。在实时应用中,延迟越低越好。 | Latency由网络传输+模型推理时间构成。模型规模、硬件性能等直接影响推理时间。常采用批处理、GPU并行或Distillation等优化降低延迟。 | 实时性要求高的场景:语音助手需毫秒级响应、自动驾驶决策要求超低延迟。在客服聊天或交易系统中,过高延迟将损害用户体验甚至造成业务损失。 | 直接影响用户体验和业务安全。通过优化模型或基础设施降低延迟,可确保AI能实时反馈并避免延时引发的效率或安全问题。 |
| 吞吐率(Throughput) | 模型 | 单位时间内AI系统可处理的任务数量或数据量。通常以每秒完成的推理请求数或tokens生成速率来衡量。 | 吞吐率受硬件并行能力和模型优化影响。多线程/多GPU并行处理、批量推理、模型剪枝或更轻量模型都能提高吞吐。也可通过模型路由(根据任务复杂度选择不同模型)实现集群层面的吞吐优化。 | 高并发场景(如企业高峰期客服问答、批量内容生成):LLM服务需要高吞吐来同时处理大量请求。离线批处理任务(如处理百万级文档摘要)也要求高吞吐以缩短总耗时。 | 较高的吞吐率意味着更强的并发服务能力。能支持更多用户同时使用AI服务,也降低每任务平均成本。对企业而言,高吞吐可带来可扩展性,满足业务增长需求。 |
说明:以上基础层术语构成了生成式AI的技术底座。大型模型(如LLM)基于Transformer架构和预训练技术获得能力,之后通过微调与对齐策略(SFT、RLHF等)优化输出品质。理解这些概念,有助于明确大型模型为何强大以及如何被定制调整来满足商业应用需求。
二、数据与表示 (Data & Embeddings)
核心涵义:生成式AI的知识与推理很大程度上依赖于数据表示和检索技术。本部分涵盖向量嵌入(Embedding)及相关概念,包括文本切分、语义搜索方式,以及数据准备策略如数据策展和合成数据。企业往往通过语义嵌入和检索增强来让大模型实时获取最新、私有知识,从而增强模型的准确性和时效性。下面是具体术语释义:
| 术语 | 类别 | 定义 | 关键原理 | 企业场景 | 价值 |
|---|---|---|---|---|---|
| 嵌入向量 (Embedding) | 表示 | 将文本、图像等数据转换为高维数字向量的表示方法。Embedding捕捉了语义特征:语义相似的内容其向量距离更近。例如“银行”与“金融机构”会有相近的向量表示。 | 通过神经网络(如Word2Vec、BERT的Encoder)将每个输入映射为固定大小的向量。这些向量在向量空间中保留了原始内容的语义信息,可用于相似度计算(如余弦相似度)。 | 语义搜索、推荐系统、聚类分析等:企业可将知识库文档转换为向量,当用户提问时将查询转为向量寻找最相似的文档段落。在推荐中,用户行为嵌入可匹配类似产品的嵌入。 | 提供机器可理解的语义表示,使模型**“理解”内容**而非逐字匹配。Embedding支撑语义搜索和内容匹配,帮助企业利用非结构化数据资产,实现更精准的信息检索和推荐。 |
| 向量数据库 (Vector DB) | 表示 | 专门用于存储和快速检索高维向量的数据库系统。通过向量索引和相似度查询,可在海量嵌入中迅速找到与某给定向量最近的项。 | 利用近似最近邻(ANN)算法组织向量索引(如HNSW、IVF),使得语义相似度搜索的查询速度得以大幅提升。向量数据库提供按相似度排序集合的Top-K检索接口。 | 企业知识库搜索是典型场景:公司将海量文档转成嵌入存入向量库,当员工问问题时,系统在库中找语义匹配的文档片段。向量DB也用于推荐和反洗钱风控(比对Embedding发现异常相似行为)。 | 在RAG等系统中充当外部知识记忆核心。相比传统关键词搜索,向量DB基于语义相似度,极大提高搜索结果相关性(尤其对措辞不同但语义相同的查询)。 |
| 文本切分 (Chunking) | 表示 | 将长文档拆分为较小文本块的过程。每块通常作为独立单元进行嵌入和检索,以适应模型上下文窗口限制和提高检索精度。 | 可按固定大小(如每段落/500字)或基于语义边界拆分。分块粒度需平衡信息完整性与检索粒度:块太大可能引入无关内容,过小则上下文割裂。智能分块避免在句子中间切断以保持语义完整。 | 构建企业知识问答时,需将厚重的PDF、技术文档拆成合理片段来建立向量索引。也用于处理长网页或聊天记录,将内容分段embedding以匹配具体问答。 | 有效的文本切分能提高检索命中率和模型回答的准确性。通过语义感知的切分策略,可减少上下文丢失,使RAG系统回答时更精确引用相关段落,不易发生遗漏或张冠李戴的错误。 |
| 语义搜索 (Semantic Search) | 检索 | 一种基于语义相似度的检索方法,区别于传统关键词匹配。通过比较内容嵌入向量的距离,找到与查询意义最接近的文档或答案。 | 利用Embedding表示和向量检索算法实现。查询和候选内容都转换为embedding,然后在向量空间找最近邻。可以结合稀疏检索提升覆盖率。即所谓混合检索(Hybrid Search),结合语义向量+关键词精确匹配。 | 企业内部搜索:员工搜索知识库/文档,语义搜索能理解自然语言问句,返回含义相关的结果而不局限于字面关键词。也用于客户支持,根据客户描述语义匹配常见问题答案。 | 打破了对关键词匹配的依赖,用户可以用自然语言查询而获得准确结果。解决企业知识未组织良好导致的搜索难题,提高知识利用效率。混合搜索进一步兼顾精度与召回,提升用户满意度。 |
| 稀疏/稠密/混合检索 | 检索 | 稀疏检索指传统基于关键词倒排索引的方法(如BM25),匹配显式词汇;稠密检索依赖嵌入向量进行语义相似搜索;混合检索将两者结合,利用各自优势提高检索效果。 | 稀疏检索精准匹配关键词,擅长处理特定术语和例外情况;稠密检索模糊匹配语义,能涵盖同义表述。混合检索可先用向量召回语义相关候选,再用关键词过滤/重排序(re-ranking)。 | 企业知识问答系统常采用混合RAG模式:先语义检索找到几份相关文档,再用关键词或交叉编码器对候选进行精排,确保引用精确。对于及时的新闻搜索等也类似结合。 | 提升检索性能:混合方式大幅改善召回率和准确度,避免纯稀疏漏掉语义近似的信息,也避免纯稠密返回无关词义相近的结果。为企业提供更可靠的检索。 |
| 数据策展 (Data Curation) | 数据 | 指对模型训练或应用所需数据进行收集、清洗、筛选、标注和组织的过程。它确保数据质量和相关性,使模型更有效地学习或回答。 | 数据策展涉及去除噪音和冗余、补充多样化样本、标注关键信息等环节。LLM时代日益强调数据质量的重要性:“以数据为中心”的范式正兴起。对指令数据策展尤其关键,以提升模型指令遵循能力。 | 企业在训练自有模型或构建知识库时,会进行数据策展:如清洗敏感信息、统一格式,加标签分类等。一个典型场景是为客服AI整理高质量问答对或知识对话数据来fine-tune模型。 | 高质量数据是模型效果的基础。完善的数据策展减少模型学到有偏或错误信息的风险,提高产出准确度和可靠性。对于企业,良好数据管理保障AI系统符合法规合规并持续改进性能。 |
| 合成数据 (Synthetic Data) | 数据 | 人为生成的、模拟真实数据分布的数据,用于弥补真实数据的不足。可通过规则程序或AI模型(如GAN、扩散模型、LLM)生成。 | 当真实标注数据稀缺时,可利用模型根据少量样本合成额外数据以扩大训练集。例如用LLM生成多样化的问题回答对,或用扩散模型生成新图像。synthetic data需注意质量和分布,避免引入偏差。 | 训练数据不足的场景:如新产品问答数据较少,可用模型模仿生成一些问答;或隐私受限场景下用合成数据代替真实敏感数据进行模型开发。 | 解决数据匮乏问题,降低数据采集成本。对有隐私敏感的数据,可用脱敏的合成数据代替,从而保护个人隐私。但要谨慎验证合成数据质量,以确保其真正提升模型能力。 |
说明:数据与表示层技术使LLM与外部知识连接成为可能。Embedding向量和语义检索是实现RAG(检索增强生成)的基础。企业通过构建向量数据库和混合检索系统,让LLM获得外部信息,避免闭门造车产生幻觉。数据策展和合成数据则确保模型输入的数据源质量,为模型训练和应用奠定稳健基础。
三、架构与方法 (Architectures & Methods)
核心涵义:为克服基础LLM的局限和增强其能力,业界发展出多种架构模式和方法论。本部分介绍检索增强生成(RAG)、智能代理(Agent)、模型多步推理策略(如Chain-of-Thought、Tree-of-Thought、ReAct)等前沿概念,以及工具调用和Planner-Executor等组合模式。这些方法旨在让模型更好地获取知识、规划任务并执行操作,以提升复杂任务的表现。下面是关键术语:
| 术语 | 类别 | 定义 | 关键原理 | 企业场景 | 价值 |
|---|---|---|---|---|---|
| RAG(检索增强生成) | 模式 | Retrieval-Augmented Generation,通过检索外部知识来增强LLM生成答案的技术方案。先检索知识库找到相关信息,再将其与用户问题一起送入LLM生成回答。 | RAG的三步流程:1) 索引:将企业文档等知识切分并向量化存入向量数据库;2) 检索:对用户问题embedding,在知识库中找相关内容块;3) 生成:将检索结果和原问题拼接输入LLM生成基于检索内容的回答。此流程为LLM接上”外脑“,有效缓解幻觉和知识时效性问题。 | 企业知识问答系统的标配,用于在LLM中集成公司内部知识库。也广泛用于电商客服(即时查询商品/订单信息)、法律咨询(引用法规文档)等需外部知识支撑的场景。 | RAG是企业级AI应用的基石:无需重新训练模型即可动态注入最新知识,解决模型幻觉和知识盲区。具备低成本、高灵活可更新等优势。 |
| Graph RAG | 模式 | RAG的进阶形式:以知识图谱为知识库结构,实现基于图的多跳检索。不同于普通向量列表,图RAG明确实体及关系。 | 将知识构造成图数据库或知识图谱,以实体-关系连接。检索时能进行关系推理(multi-hop reasoning)。如通过关系链回答复杂问题(“公司CEO的母校是哪所?”)。代表实现包括微软的GraphRAG框架。 | 企业知识图谱问答、情报分析等场景:如查询组织结构关系、人名地名关联的问答。GraphRAG在有图谱数据时效果更优。 | 提供可解释的链式推理能力,能回答需要跨越多条知识关联的复杂问答。提高查询准确率达数十个百分点,增强系统处理复杂信息的推理能力。 |
| AI Agent(智能体) | 模式 | 能感知环境、自主规划和执行动作以完成目标的AI软件。LLM Agent利用语言模型的能力进行观察决策和调用工具完成多步任务。与传统聊天机器人单轮问答不同,Agent可以连贯执行任务。 | Agent通过循环感知-决策-行动:LLM基于输入判断要采取何种行动(如调用API、工具或产生回答),执行后获取结果再决策下一步。它维护内部状态或记忆,以完成多步骤任务。常结合Chain-of-Thought、工具调用等技术增强能力。 | 个人助理(如Microsoft 365 Copilot)本质是LLM Agent,可帮用户执行跨应用的复杂任务。其它场景如自动化数据分析(连接数据库提取数据并作报告)、软件测试Agent(自行生成代码调用API测试),都属Agent范畴。 | 实现从AI“回答者”到任务执行者的跨越。AI Agent可以自主帮人完成功能复杂的工作(信息搜集、事务处理等)。这增强了AI在自动化流程、提升效率方面的潜力。 |
| 多智能体 (Multi-Agent) | 模式 | 由多个AI Agent协作或竞争组成的系统,以分工合作解决复杂任务。通过不同Agent之间的信息交换和协调,完成单一Agent难以胜任的任务。 | 多Agent体系可分集中(一个主Agent协调子Agent)和分布式(Peer协同)等架构。Agents可以采用消息通信、共享记忆等方式协作。常见模式如Orchestrator-Worker架构,由中央调度Agent拆分任务给多个专家Agent并整合结果。 | 复杂流程自动化:如在供应链场景,一组Agent分别负责库存监控、物流调度、异常处理,通过协作完成全流程优化。软件开发领域也有研究用多个码农Agent相互review代码,提高代码质量。 | 通过专业分工与并行处理,提升任务执行效率与可靠性。在实验中,多Agent系统可以显著提高任务成功率(超过单Agent近90%)。不过也带来更高开发复杂度和资源消耗,需要平衡成本效益。 |
| 工具调用(Tool Use/Calling) | 方法 | 指LLM通过输出特殊格式指令来调用外部工具/函数的能力。基础模型仅能生成文本,通过工具调用,模型可获取实时信息或执行操作。例如让LLM查询数据库、执行计算、访问网页等。 | 典型实现如ReAct和OpenAI 函数调用。LLM在推理过程中生成动作指令(如”搜索…“、”计算…“),由外部程序执行后将结果反馈给模型。模型据此调整后续推理,最终返回答案。需要在Prompt中嵌入工具列表格式,让模型学习何时以函数格式请求工具。 | 搜索问答(模型通过调用搜索API获取网络信息),运算助理(LLM调用计算器API解数学题),文件操作(LLM通过工具读写文件)等。工具使用使模型能力从纯文本扩展到执行具体动作,可实现“思考-行动”循环。 | 大幅扩展了LLM的外部交互和执行能力。借助工具,LLM不再局限于其内部知识,而能动态获取数据和执行操作。这提升了解决问题的准确性和实用性,可满足复杂业务需求。 |
| 函数调用(Function Calling) | 方法 | 一种将LLM生成的结构化函数请求转交给应用程序执行的机制,由OpenAI在2023年提出。模型能按开发者提供的函数定义产生JSON参数,然后由外部函数执行相应动作,将结果返回给模型处理。 | 开发者先定义允许LLM调用的函数签名,并将其描述嵌入到模型提示中。模型推理时若判断需要外部信息/操作,会返回一个函数名和参数的结构化调用。应用接收到此调用后执行对应函数,把返回结果追加至模型上下文供其生成最终回答。 | 开放平台AI服务:如ChatGPT插件就是函数调用的应用。企业开发者可定义自家业务接口(CRM查询、下单系统等)为可被LLM调用的函数,让AI助手具备业务系统操作能力。 | 提供LLM与外部系统标准化集成方式,简化AI应用开发。使模型输出可靠的结构化请求而非自由文本,降低模型回答不确定性与解析难度。打通AI与业务系统,实现真正可控的“AI+软件”融合。 |
| Chain-of-Thought(思维链) | 方法 | 一种提示技术,让模型在回答复杂问题前显式输出推理步骤,从而提高答案正确性。例如通过要求模型“分步骤思考”来解决数学题。 | Chain-of-Thought (CoT)通过在提示中加入“让我们一步步推理”的要求,或提供带推理过程的范例 (few-shot CoT),引导模型生成中间推理步骤。显性推理有助模型自身检查逻辑,显著提升数学、逻辑推理任务准确率。 | 金融分析或诊断推理等需要严谨步骤的场景:如风控模型解释决策过程;或模型在代码调试前列出逻辑步骤。Chain-of-Thought亦用于工具调用场景(如ReAct)以规划工具使用顺序 | 通过模拟人类逐步思考过程提高模型决策质量。让输出不仅有答案,还有推理可解释性。在企业中,这有助于审计AI决策的透明度,增强信任。 |
| Tree-of-Thought | 方法 | Chain-of-Thought的扩展概念:鼓励模型在推理时探索树状多分支的思路而非单线性思路。模型可以生成多个假设路径、评估选择最佳分支。 | 在提示或算法上调整,使模型能发散思考多个可能解决方案,并通过自我评价或外部评判筛选最优路径。类似游戏里的搜索树,扩展LLM的推理空间,提升复杂问题解决能力和健壮性。 | 战略决策、规划任务:如制定供应链计划,模型可提出多套方案并比对优势。AI游戏AI(如决策树搜索)等研究领域正在探索这类方法。 | 帮助模型突破单一路径的局限,更全面地考虑问题。显著提高处理具有不确定性或解空间广的问题的性能。不过目前仍为前沿研究概念,企业应用还在探索阶段。 |
| ReAct | 方法 | Reason + Act的简称,是一种LLM交互范式,将推理(Reasoning)与动作(Acting)相结合。模型以交替方式既输出思考过程又输出执行动作,实现边思考边与外界交互。 | ReAct结合Chain-of-Thought和工具(API)调用:模型先输出推理(想法),再根据推理生成行动指令与环境交互获取新信息,然后继续推理 – 如此循环,直至达到目标。这使模型能动态调整策略、利用外部信息避免幻觉。 | 信息查询及问题求解任务:如让LLM解决一个需要查资料的复杂问题时,使用ReAct模式,模型会自动决定何时调用搜索引擎获取信息、何时整合结果回答。 | 提升LLM在开放领域和复杂任务中的能力。通过交替推理和行动,模型更不易受自有知识局限,准确性与鲁棒性增强。ReAct模式已成为开发高级AI Agent的基础范式之一。 |
| Planner-Executor 模式 | 模式 | 智能体架构的新范式:将任务规划与执行职责拆分由不同组件(或不同模型)承担。Planner负责高层次任务分解和决策,Executor专注于按计划逐步执行具体行动。 | 通过分治思想提升Agent稳健性。Planner(可由一个LLM担当)生成行动计划,然后Executor(另一个LLM或程序)根据计划依次执行。优点是规划结构清晰,可避免单一模型即兴胡乱探索。 | 长流程任务如项目管理AI:Planner将高层目标(如开发产品功能)拆解成子任务,分派给专门的执行Agent完成。或表单填写机器人:Planner问用户问题收集信息,Executor根据收集结果填写表单。 | 可靠性提升:规划与执行分层使Agent行动可控、易调试。适合复杂/高风险任务,降低出错和幻觉执行几率。同时支持职责分工,用不同模型分配不同子任务,达到更好性能与效率。 |
| 记忆 (Memory) | 方法 | 智能体或LLM系统用于存储并检索对话历史、知识或状态的机制,以支持长期连贯交流或多步任务执行。 | 短期记忆通常由LLM的上下文窗口承载,即提示中包含最近对话内容。长期记忆则需借助外部存储(如向量数据库)存放过往信息以随需检索。一些Agent引入工作记忆模块(scratchpad)来记录中间结果。 | 长会话场景:如企业客户的长对话,Agent需要记住客户早先提供的信息。**持续任务】**如项目助理Agent需要保留项目上下文。Memory机制使之可能。 | 让AI具有跨轮次上下文保持能力,改善交互体验。能个性化应用(记住用户偏好)并处理复杂任务状态(记住已完成步骤),提高可靠性和实用性。 |
| 反思 (Reflection) | 方法 | 又称“自我复盘(Reflect)”,一种让LLM在完成任务或初次尝试后,对结果进行自我检查和改进的策略。 | Reflection模式通常包括让模型审视自己的输出或任务执行过程,发现可能错误或不足,并有机会进行修改。例如让模型对自己的回答作出评价,再根据反馈自我修正。 | 代码生成中的错误调试:模型编代码后先自己检查执行结果,发现错误则尝试修正;文案生成中让模型对自己初稿打分评价再完善。 | 提升输出质量和准确性。对高要求任务,通过增加反思步骤,可以降低错误率,产出更可靠的结果。缺点是增加计算开销和时延,但在高价值任务(如代码审查、报告生成)中常被接受。 |
说明:这些架构与方法是对LLM“纯文本生成”范式的拓展,使模型具备与外界交互、规划、持久记忆和自我纠错的能力。RAG和Graph RAG将LLM与知识库相结合,提高事实性和时效性;Agent架构让模型能主动执行任务;ReAct、Plan-Exec和Reflection等增强推理、规划与纠错能力,使AI在复杂任务中的实用性和可靠性显著增强。
四、平台与集成 (Platform Integration & Deployment)
核心涵义:将生成式AI纳入企业现有IT体系需要一系列平台层技术。包括MCP等开放协议、模型托管/推理服务、多模型编排与网关、以及AI插件/Copilot等应用集成方式。这部分术语关注如何将LLM模型部署、管理和与业务系统对接,以发挥其实际价值。
| 术语 | 类别 | 定义 | 关键原理 | 企业场景 | 价值 |
|---|---|---|---|---|---|
| MCP(模型上下文协议) | 平台 | Model Context Protocol,由Anthropic等提出的开放标准协议,作为LLM与外部工具、数据源之间的通用接口。类似“AI系统的USB-C接口”,实现跨模型、跨平台的一致化集成方式。 | MCP规定了LLM主机(Host)、客户端(Client)、服务端(Server)三方如何交互数据。LLM通过Host向Client提出资源/工具请求,由Client经MCP协议与Server(实际数据源或服务)通讯并返回结果。这样各种LLM和工具只需各自遵守MCP协议,就能随时互联。 | 跨产品AI集成:MCP已有丰富插件库,从文件系统访问到数据库查询等。企业可使用MCP让LLM安全访问本地数据:如Claude通过MCP访问本地文件保存用户请求的文档。 | 提供标准化的AI-工具接口,降低不同模型、平台间集成成本。MCP让企业能灵活切换LLM而不必重写集成逻辑,并具备更好的安全可控性(如权限管理、数据传输审计)。 |
| 模型托管与Serving | 平台 | 指将训练好的AI模型部署在服务器或云平台上,通过API服务形式对外提供推理能力的方式。包括开放平台(如OpenAI API)或企业私有化部署。 | 模型托管需要推理引擎(如ONNX Runtime、vLLM)高效加载模型、处理推理请求。在云平台上,它通常与容器或无服务器架构结合,实现按需缩放。关键在于优化内存和计算以支持多用户并发。 | 企业如果不自建基础设施,可使用云厂商的模型服务(Azure OpenAI、AWS Bedrock等)来调用大模型。也可以在本地服务器托管开源LLM模型,作为REST API供内部系统访问。 | 将模型变为易用的服务。确保可扩展(有负载管理、弹性伸缩)、可监控(日志/监控)和高可用。对企业而言,这是一种可靠方式将LLM能力集成进应用,如手机App的后台调用模型实时返回结果。 |
| 模型网关 (Model Gateway) | 平台 | 面向大规模企业应用的统一入口服务,管理和路由对多个AI模型的访问。类似API Gateway,用于集中控制各类模型的调用、版本、权限及流量。 | 模型网关接受客户端请求,根据请求内容、策略路由到合适的模型或管线上。支持A/B测试、多模型回退、负载均衡等。网关还能统一实现鉴权、日志与配额管理,保证合规与安全。 | 复杂AI服务(如多租户AI平台)需要一个模型网关调度多个模型实例。AI中台架构中,网关允许不同部门调用适当的模型(如通用模型vs专用模型),支持统一运维和权限管理。 | 提供集中管理与安全。通过网关,企业能灵活实验不同模型、平滑升级模型版本而不影响前端应用。还可统一审计日志用于合规(符合AI治理要求)。 |
| 模型编排 (Orchestration) | 平台 | 对多模型或多步骤AI流程进行组合调度的过程。复杂AI应用通常由多个模型、工具串联而成,模型编排负责安排顺序、数据依赖和交互。 | Orchestration通常由一个调度逻辑或专门服务实现,定义模型调用顺序和条件。可能基于if/else逻辑或更高级的工作流引擎。在Agent架构中,此角色由Orchestrator Agent承担。 | AI流水线示例:先用OCR模型识别图片文字,再调用LLM进行文本摘要,最后调用翻译模型产出结果。编排服务负责将OCR输出送给LLM,然后LLM输出送翻译模型并返回翻译。 | 通过模型编排,企业可构建端到端的AI工作流,发挥各自模型特长,完成单一模型无法独立完成的任务。编排使AI应用更模块化,易于维护扩展,并优化整体性能(如按任务选用更高效模型)。 |
| 企业Copilot | 应用 | 一类深度融合企业业务场景的AI助理,能够理解上下文,提供决策支持和自动化。名称源于Microsoft “Copilot”,现泛指集成于产品中的AI助手。 | 企业Copilot通常构建在LLM之上,经过微调或配置知识库后集成于业务应用中。它具备数据访问权限(受控于安全策略),可在上下文(如用户文件、邮件、代码库)中提供建议或执行操作。 | 如编码辅助工具(GitHub Copilot)、Office文档Copilot(帮助写文档、邮件),以及企业特定Copilot如销售助理(根据CRM数据提供推荐)等。 | 将生成式AI潜能融入具体工作流,充当员工的“智囊”。Copilot可以显著提升人效:如开发效率提高,通过自动生成代码片段;或营销人员借助其快速生成文案。 |
说明:借助平台与集成层技术,企业得以快速部署、管理并安全使用大模型。MCP等协议扫清了模型对接的障碍;模型托管、网关、编排等机制保证高并发、弹性可控的AI服务;而Copilot/插件等形式则将LLM无缝嵌入产品,为终端用户提供智能体验。这些共同使得生成式AI落地企业成为现实。
五、工程评估与运维 (Engineering, Evaluation & Ops)
核心涵义:构建企业级生成式AI应用,需要关注工程实践与运营环节。本部分涵盖Prompt工程、模型评测、内容质量控制、观测调优及成本优化等主题。通过科学评估和监控模型表现,及时调优和防范幻觉,同时控制算力成本,企业才能高效、安全地运维AI系统。
| 术语 | 类别 | 定义 | 关键原理 | 企业场景 | 价值 |
|---|---|---|---|---|---|
| 提示工程 (Prompt Engineering) | 工程 | 针对指令驱动的大模型,设计和优化输入提示以引导模型输出期望结果的技术和实践。包括措辞选择、示例构造等。 | 利用LLM对上下文敏感的特点,通过精心构造的系统提示、说明和示例对,调整模型输出风格和内容。Prompt工程涉及反复试验,包括few-shot示例、角色扮演等手段来稳定模型表现。 | 客服:设计提示模板控制客服AI语气和格式;报表生成:提供特定格式示例让模型按模板输出。Prompt工程也是零代码AI平台的重要内容,用户通过提示配置AI行为。 | 是调校LLM输出的重要手段,在无须模型重训情况下微调其行为。良好的Prompt能使模型更准确回答并遵守格式要求,减少不良输出出现,确保企业应用的稳定性和质量。 |
| Prompt模板 | 工程 | 将提示词结构化、参数化的模板,以便应对重复性的输入输出任务。 | Prompt模板可包含占位符和固定框架,由系统填入具体上下文数据后发送给模型。这实现标准化的提示工程过程,适合API集成。 | 常用于批量任务:如对一批文档生成摘要,每个请求使用统一提示模板插入不同文档内容;自动问答应用也为每类问题定义相应Prompt模板。 | 提升可复用性和一致性。通过预定义模板,企业在不同场景都能保持AI响应的质量和格式统一。降低每次重新设计Prompt的成本,提高开发效率。 |
| 模型评估 (Evaluation) | 评估 | 系统地度量AI模型性能的过程,包括准确性、可靠性、安全性、效率等指标。针对LLM,除了通用NLP指标,还需关注内容质量与安全。 | 评估方式有基准测试(Benchmark):使用标准数据集衡量模型性能;A/B测试:将不同模型版本比较用户反馈;Evals:如OpenAI Evals框架可自动判断模型回答是否正确。 | 模型选型时用基准数据(如MMLU通识测试)选择性能最佳模型;上线前以A/B测试确保新模型优于旧版。安全评测使用针对不良内容的测试集(如诱导违法、偏见)的应答情况衡量模型安全性。 | 保障AI部署质量过关和持续改进。客观评估指标帮助企业比较不同模型、跟踪优化效果。透过评测能发现模型短板并有针对性改进,如对特定任务准确率不够时增补数据或优化Prompt。 |
| A/B测试 | 评估 | 一种对比评估方法:同时让用户或评审随机使用两种不同版本的模型或参数设置,以评估哪种效果更好。 | 将用户请求随机分配给A组模型(旧版)和B组模型(改进版),对比用户指标(如满意度、点击率)或专家打分,统计显著性差异。若B优于A,则推广新方案。 | 模型升级和参数调优时都会用A/B测试验证:如新微调模型在小流量用户中A/B测试,观察其回复质量和用户满意度相对原模型是否提升。 | 提供实证比较,避免主观判断,用数据驱动模型优化决策。帮助企业以控制风险的方式引入改进,更好平衡模型性能与用户体验。 |
| 可观测性 (Observability) | 运维 | 针对AI系统运行状态的监控和追踪能力。包括记录请求日志、响应时间、错误率、token使用量等,便于分析性能瓶颈和异常行为。 | 通过在API网关或应用添加分析模块,收集每次模型调用的输入输出、使用的token数、延迟等。一些工具可追踪模型注意力权重、内部思路,以调试理解模型行为。 | 企业AI服务上线后,技术团队利用日志监控性能指标(QPS、延迟)及错误情况,及时扩容或排障。对于敏感业务,可能还要记录模型输出用于审计(例如检查模型是否泄露隐私)。 | 提供AI运维可见性,保障服务稳定和安全。通过深入观测,定位效率瓶颈、预防服务故障。对于安全审计,记录模型决策过程有助于问责和改进。 |
| 追踪 (Tracing) | 运维 | 记录贯穿整个AI推理链路的每个步骤(包括内部调用如RAG的检索片段、Agent的行动序列等)的技术。 | 通过在模型交互框架中植入钩子,抓取模型生成的中间过程(如Chain-of-Thought步骤、函数调用请求、检索返回内容),形成完整的执行轨迹。 | 问题诊断:如果模型回答错误,开发者可以检查其推理链条、检索记录发现问题环节(检索不相关内容?逻辑跳步?)。监控:也可用追踪实时检测模型行为异常,如异常调用外部API。 | 帮助理解模型行为,加快调试迭代。提供模型决策过程透明化,对于关键应用让企业更有掌控感。如有问题可精准定位改进,提升AI系统可靠性和安全性。 |
| 幻觉 (Hallucination) | 内容 | 模型生成看似合理但实际虚构或错误的内容的现象。LLM有时会在不确定答案时编造信息,这被称为幻觉。 | 原因是模型基于语言模式生成,可能会在缺乏知识时仍输出自信的虚假内容。幻觉是LLM当前的主要挑战,因为它给出了无依据的答案。通过RAG(用外部真实资料)或训练中加入事实核验,可减轻幻觉发生。 | 知识型AI如医疗诊断、财务咨询中,幻觉风险尤其需要控制。企业部署前通常测试模型的正确率并加入grounding(如引用来源)机制以减少幻觉。 | 减少幻觉对于AI应用可信度至关重要。识别并降低幻觉输出可避免误导用户或造成业务错误。采用RAG和基于检索的响应能有效让答案有据可依。 |
| 根植 (Grounding) | 内容 | 确保模型输出内容基于真实来源的过程和方法。例如要求LLM回答问题时引用具体出处来支持其结论。 | Grounding通常利用RAG或数据库查询,使模型的回答直接来源于检索结果或知识库内容而非凭空生成。可以通过提示词强制模型在回答中加入引用或证据。 | 企业内部问答要求AI必须只根据知识库回答,并给出引用(如政策条款编号)以示可信。商业情报分析也需要AI基于可信数据源推断并输出可查证的结论。 | 提升AI输出的可信度和可审查性。通过grounding,AI提供可验证的信息,减少错误传播风险。对企业来说,这可满足合规要求并增加用户信任。 |
| 成本控制 (Cost Control) | 运维 | 在使用云端大模型服务时,管理API调用成本的策略和方法。LLM通常按token计费,因此需平衡调用频率、模型大小与成本。 | 将请求分配给不同规格模型(Model Routing),优先使用小模型处理简单任务、仅在必要时调用大模型。此外,通过缓存常见问答结果、批量处理等技术减少重复计算,也可降低token花费。 | 企业规模使用LLM时,需要监控并控制开支。比如客服AI每天成千上万次api调用,可通过记录热门问答缓存,或在闲时挖掘重复性高问题以缓存答案,减少实时调用。 | 降低AI服务运行费用,提高ROI。在大规模应用中,精细化的模型路由策略和缓存可为企业节省显著成本,同时维持良好性能。 |
| 缓存 (Caching) | 运维 | 存储和重用LLM的常见输入/输出结果,以避免重复计算的技术。 | 通过哈希存储已经处理过的Prompt及结果,当新请求与缓存键匹配时直接返回存储的结果,而不实际调用模型。适用于确定性较高的任务或高频重复查询。 | FAQ问答服务可以缓存热门问题的回答;翻译API对常用句子进行缓存。当有大量重复或相似请求时,缓存极大减少不必要的模型调用。 | 可减少重复推理节省成本。也减少高延迟服务的响应时间(直接访问缓存)。但注意对实时性要求高或上下文敏感的任务不宜缓存。 |
| 批量推理 (Batch Inference) | 运维 | 将多个独立请求合并一起给模型一次性处理,以提高算力利用率的技术。 | LLM可以同时处理一批输入(如多个Prompt拼接为大Prompt),利用GPU并行性摊薄单个请求的开销。需要一定框架支持(如vLLM可合并请求)。 | 离线处理:对成百上千文档做摘要、分类等,可打包批量输入模型,获得多个结果后再拆分。 | 提高GPU的吞吐效率,降低单位请求的平均时延和成本。特别适合批处理场景,节省资源。 |
| 模型路由 (Model Routing) | 运维 | 在同时部署多种模型时,根据请求特征将其路由给最合适模型的过程。 | 依据输入长度、难度、所需任务等,动态选择模型。例如短而简单的请求用速度快的小模型处理,复杂任务用大型模型。可以用分类器或规则决定路由。 | 多层模型服务:如某厂商同时部署BERT类模型与GPT-4,用户简单查询走本地模型,复杂问题才调用云上GPT-4。微软导入Mosaic技术就是类似的多模型选择器。 | 降低开销同时保证效果。多数请求由便宜模型解决,疑难问题交给昂贵大模型,从而高效利用资源。 |
| AI财务运维 (FinOps for AI) | 运维 | 将金融运营(FinOps)理念应用于AI项目,强调成本可视化、优化和治理。在云端使用LLM时特别重要。 | FinOps倡导跨部门合作,监控云成本并持续优化资源利用率。针对LLM应用,FinOps可能涉及开发成本仪表盘、模型调用限额设置、自动缩放策略以及定期算法优化来控制支出。 | 大规模AI应用(如SaaS AI服务提供商)需要专业团队实践FinOps。监控各模型API使用情况,分析成本构成并优化各种参数以降低费用。 | 确保AI系统经济可持续。在模型仍不断演进、费用高昂的背景下,FinOps帮助企业避免预算失控,实现业务价值最大化与成本最低化。 |
说明:有效的工程实践和运维策略是AI落地成功的保障。通过完善的提示工程和模型评测,企业迭代优化模型性能和输出质量;借助监控追踪技术,掌握AI系统运行动态,及早发现并消除问题输出和性能瓶颈;成本/性能优化手段则确保AI应用以可负担的投入持续运行。这些“幕后”工作虽不直接体现在用户界面,却是保证AI服务高质可控、经济高效的关键。
六、安全治理与合规 (Safety, Governance & Compliance)
核心涵义:随着AI进入企业核心业务,人们愈发重视模型的安全性、道德规范和法律合规问题。本部分涵盖Guardrails(安全护栏)、内容安全机制、隐私数据隔离、AI治理框架、模型风险评估和合规要求等。通过安全治理,企业可保证AI行为在合规范围内运作、降低风险并维护声誉。
| 术语 | 类别 | 定义 | 关键原理 | 企业场景 | 价值 |
|---|---|---|---|---|---|
| Guardrails(安全护栏) | 安全 | 泛指AI系统中内置的约束和安全机制。其作用是防止有害、虚假或不符合范围的输出。实现方式包括内容过滤、响应格式校验、限制回答范围等。 | Guardrails通常在后处理阶段检查模型输出,或作为额外约束融入模型推理过程。如对生成结果进行不良内容检测(基于敏感词/分类模型),或预定义规则避免模型提供金融/医疗建议。部分Guardrails通过”Constitutional AI”或安全指令在模型内部实现。 | 聊天机器人过滤敏感内容:防止AI输出歧视、仇恨言论或机密信息。金融投顾AI的回答需加免责声明。企业在发布AI系统前会投入设计各类Guardrails,避免不当内容造成法律或公关风险。 | 确保AI输出安全合规、不触犯道德法律底线。Guardrails降低企业使用AI的风险(如错误医疗建议引发责任)。它也是构建可信AI、通过审核和取得用户放心使用的关键。 |
| 内容安全 (Content Safety) | 安全 | 指AI系统对敏感或有害内容的防护策略。包括监测并阻止AI生成或传递违规信息(淫秽、暴力、违法、隐私泄露等)。 | 通常由组合的方法保障:1) 训练时对模型进行安全对齐(如禁用特定话题);2) 推理时实时审查输入输出(过滤敏感词/分类检测)并中止或修改不当响应。OpenAI、Anthropic等模型均内建基本安全规则。 | 用户交互AI必须实现内容安全。如社交平台的AI写作助手需防止其输出仇恨言论或隐私信息。内部员工AI工具也应避免泄露机密。 | 避免法律和声誉风险。内容安全体系防止AI侵害用户或企业利益,确保AI符合公司价值观和外部监管要求。例如遵守GDPR中对敏感内容处理的规定。 |
| 数据隔离 (Data Isolation) | 安全 | 在AI训练和推理中,确保各租户或场景的数据相互隔离、不发生跨权限泄露的机制。 | 可能通过多实例部署物理隔离,或通过加密/标签控制模型访问。对于共享模型服务,需要明确定义数据边界(如不同API密钥对应不同embedding库)。 | 多租户AI服务如SaaS平台必须确保客户数据隔离,防止在一个客户对话中透露另一个客户信息。内部部门多项目共用模型,也要隔离各项目私密数据。 | 防止数据越权访问,保护企业和用户隐私。数据隔离是AI安全架构的重要一环,与身份与访问管理(IAM)集成,确保AI的上下文访问符合最小权限原则。 |
| PII(个人身份信息) | 安全 | Personally Identifiable Information,如姓名、身份证号、联系方式等可识别特定个人的信息。处理此类信息的AI系统需严格遵守隐私法规和企业规范。 | 企业AI系统中引入PII检测和匿名化流程:模型输入前,将PII替换/标记(如用占位符代替姓名);模型输出后也需检查是否含不应泄露的敏感信息。有时,专门训练模型避免输出PII或能识别隐私数据类型。 | 金融客服AI接触大量客户PII(账户、余额),必须确保这些数据不被包含在其他客户查询中。医疗AI处理病人记录时需做严格脱敏。 | 保障用户隐私,符合GDPR等法规要求。防范数据泄露事件,维护企业声誉。正确管理PII还可降低AI训练数据中的隐私风险,促进更多数据合规使用。 |
| AI治理 (AI Governance) | 管理 | 企业层面对AI系统进行策略、流程和问责管理的实践,以确保AI符合道德和法规要求并实现业务价值。 | 包括建立治理框架(如AI伦理准则、决策权限)、监督机制(定期审查模型行为、偏差检测)、风险评估(评估模型错误可能性及影响)等。需要跨职能团队合作(IT、安全、法务)。 | 大型金融机构创建AI治理委员会制定AI伦理准则并监控执行。法规管制行业(医疗、保险)必须有AI合规人员参与模型设计测试,确保满足各项法规。 | 强化企业对AI应用的可控性和透明度。完善的AI治理防止技术滥用,提高AI系统的可靠性和公众信任度。也有助于快速响应监管变化,减少违规风险。 |
| 模型风险 | 管理 | 指AI模型在使用中可能导致的潜在负面后果。包括错误决策风险、偏见歧视风险、安全攻击风险等。 | 模型风险通常通过风险评估和红队测试发现。企业需识别模型对业务和用户的威胁来源,如错误率过高导致的决策失误、训练数据偏差导致的歧视、或被恶意输入诱导输出敏感信息等。 | 贷款审批AI模型可能存在种族或性别偏见风险,需要评估并纠正。司法辅助AI若决策失当将造成严重后果,需特别关注。 | 识别并管理模型风险以采取针对性缓解措施(如改进训练数据、设置使用范围)。这是负责任AI的基础,保障AI系统在控制范围内运行,不对业务和社会造成严重损害。 |
| 红队 | 管理 | AI系统上线前或迭代中,安排专家模拟恶意攻击或极端使用来测试AI稳健性的过程。称为“红队”测试。 | 红队会扮演对抗者,设计极端输入来诱导模型产生错误或违规输出,借此提前发现系统漏洞。OpenAI、Anthropic等公司都依赖红队改进模型安全边界。 | 内容审核AI系统上线前,红队人员可能输入各类敏感内容测试模型是否会忽略规则。对话AI接受红队提问以检查是否存在信息泄露隐患。 | 通过攻击性测试,提前发现AI的缺陷和脆弱点,进行修复加固。红队实践是打造安全AI的重要环节,防范在真实世界中被别有用心者利用。 |
| 合规 (Compliance) | 管理 | 确保AI系统的开发和使用过程符合相关法律法规、行业标准和内部政策的要求。 | 包括数据合规(个人数据使用需授权/脱敏),内容合规(不得输出违法言论),及AI输出的责任认定等。企业通常在AI上线前经过合规团队审核,并制定审计机制确保持续合规。 | 受监管行业(医疗、金融)在部署AI前需取得监管机构认可;普通企业也需遵守国家网络安全法规。GDPR等要求在AI中保护欧洲公民数据。 | 降低法律风险,避免因AI不合规导致处罚。建立用户和监管的信任。合规性要求也引导企业规范AI流程,如记录决策日志、提供问责渠道,大幅提升AI系统透明度和可靠性。 |
说明:当生成式AI深入企业核心业务领域,安全和合规就变得不可或缺。通过技术手段(Guardrails、内容过滤、数据隔离)以及管理流程(AI治理、红队、安全评估)相结合,企业可以最大化发挥生成式AI的潜能,同时最小化风险,确保AI系统的输出安全、负责任且符合各种法规要求。这样,AI才能真正成为企业可信赖的生产力工具。
生成式 AI 的竞争,已经不再是“谁的模型参数更大”,而是谁能真正把 AI 变成可靠、可控、可持续的生产力。
从模型与训练方法,到 RAG 与 Agent 架构;
从工程评估与成本控制,到安全治理与合规体系——
这些专业术语并不是为了“显得高级”,而是构成企业级 GenAI 系统不可或缺的工程与治理基础。
从工程评估与成本控制,到安全治理与合规体系——
这些专业术语并不是为了“显得高级”,而是构成企业级 GenAI 系统不可或缺的工程与治理基础。
希望这篇文章不仅能帮你“看懂术语”,
更能在你设计架构、评估方案、推动落地时,
知道该问什么问题、做什么取舍、避免哪些常见陷阱。
更能在你设计架构、评估方案、推动落地时,
知道该问什么问题、做什么取舍、避免哪些常见陷阱。
GenAI 仍在快速演进,但真正拉开差距的,永远是系统性认知 + 工程化能力 + 业务判断力。
如果这份术语全景图,能成为你构建企业 AI 能力的一块“认知底座”,那它的价值就已经实现了。
如果这份术语全景图,能成为你构建企业 AI 能力的一块“认知底座”,那它的价值就已经实现了。