今年开始 AI 在业务中的落地越来越多，后端面试中也开始频繁涉及相关内容。相比算法细节，面试官更关注的是：你是否理解这些概念，以及能不能结合实际项目讲清楚它们的用途。

　　今天这篇文章从后端工程视角出发，把常见 AI 名词串起来讲清楚。

---

1、LLM（大语言模型）

　　LLM 是当前大多数 AI 应用的基础能力，本质上是一个通过海量数据训练出来的文本生成模型。可以简单理解为：输入一段内容，它会根据上下文预测最合理的输出。

　　在后端系统中，LLM 通常不会直接暴露给用户，而是作为一个能力层存在。例如智能客服、AI 问答、内容生成等场景，底层都是通过调用大模型来完成。

　　实际开发中，后端的职责并不是“训练模型”，而是围绕模型做一层封装，包括请求构建、结果处理以及异常控制。同时还需要考虑成本控制和接口稳定性，这些才是工程上的重点。

---

2、Prompt（提示词）

　　Prompt 是输入给模型的指令，它直接决定了模型输出的质量。在实际项目中，Prompt 并不是简单的一句话，而更像是一种“结构化输入”。

　　通常会包含几个部分：角色设定、任务描述、输入数据以及输出约束。例如可以设定模型是一个“电影推荐助手”，并明确要求它只能基于给定内容进行回答。

　　在后端开发中，Prompt 往往是动态拼接的，一部分是固定模板，一部分来自用户输入，还有一部分来自系统检索的数据。设计合理的 Prompt，可以明显降低模型的不稳定性，也是面试中比较容易被追问的点。

---

3、Token

　　Token 是模型处理文本的基本单位，一段文本在模型内部会被拆分成多个 Token，而不是直接按字符串处理。

　　这个概念在工程中非常关键，因为模型的调用成本通常是按 Token 数量计算的。同时，每个模型都有最大上下文限制，如果输入内容过长，就会出现截断或者直接报错。

　　在后端系统中，常见的优化方式包括限制历史对话长度、裁剪无关信息以及控制检索数据的数量。简单来说，就是在保证效果的前提下尽量减少 Token 消耗。

---

4、Embedding（向量化）

　　Embedding 的作用是把文本转换成向量，从而可以用数学方式计算文本之间的相似度。

　　比如两句话语义接近，那么它们对应的向量距离也会比较近。通过这种方式，可以实现比关键词匹配更智能的搜索能力。

　　在实际项目中，Embedding 常用于语义搜索、相似推荐以及 RAG 架构中的检索环节。对于后端来说，一般会把文本先转成向量，再存入数据库，查询时再进行相似度匹配。

---

5、向量数据库

　　向量数据库是专门用来存储和检索向量数据的系统。与传统数据库不同，它的核心能力是“相似度查询”，而不是条件过滤。

　　当用户输入一段内容时，可以先将其转成向量，再去数据库中找到最相似的几条记录。这种方式特别适合处理自然语言相关的场景。

　　在实际应用中，向量数据库经常用于知识库问答、推荐系统以及内容检索。对于后端开发来说，它通常作为一个独立的存储组件存在，需要和 embedding 服务配合使用。

---

6、RAG（检索增强生成）

　　RAG 是目前最常见的 AI 架构之一，它的核心思想是把“检索”和“生成”结合起来。

　　传统大模型在回答问题时，往往依赖自身训练数据，无法获取实时信息，也不了解私有数据。而 RAG 的做法是，在模型生成之前，先从知识库中检索相关内容，再把这些内容一起提供给模型。

　　这样做的好处是可以显著提升回答的准确性，并减少模型“编造内容”的情况。在企业知识库、智能客服等场景中，RAG 已经成为一个标准方案。

---

7、Agent（智能体）

　　Agent 可以理解为一种更高级的 AI 形态，它不仅能回答问题，还可以根据目标自主决策并调用工具。

　　和普通问答不同，Agent 更强调“执行能力”。比如用户提出一个复杂需求，它可以拆解任务、调用不同接口，并最终给出结果。

　　在后端系统中，Agent 通常需要和各种服务打通，例如数据库查询、搜索接口或业务 API。它的出现，让 AI 从“信息生成”进一步升级为“任务执行”。

---

8、Function Calling（函数调用）

　　Function Calling 是连接大模型和后端系统的一种重要机制。通过这种方式，模型可以在生成过程中决定调用某个函数，并给出对应参数。

　　后端接收到调用请求后执行实际逻辑，比如查询数据库或调用外部接口，然后再把结果返回给模型，模型再继续生成最终答案。

　　在实际项目中，这种机制可以让 AI 具备操作能力，而不仅仅是生成文本。例如订单查询、天气查询等场景，都可以通过这种方式实现。

---

9、Fine-tuning（微调）

　　微调是指在已有模型基础上，用特定数据再次训练，使模型更适合某个业务领域。

　　比如用企业内部数据去训练模型，可以让它更理解业务语境和专业术语。

　　不过在大多数后端项目中，通常不会优先选择微调，而是通过 Prompt 和 RAG 来解决问题。原因在于微调成本较高，而且模型更新和维护复杂，只有在对效果要求非常高的情况下才会考虑。

---

10、Hallucination（幻觉）

　　幻觉是指模型生成了看似合理但实际上错误的内容，这是大模型中比较常见的问题。

　　本质原因在于模型并不是在“查事实”，而是在“预测概率”。因此即使没有相关信息，也可能生成看起来很真实的答案。

　　在工程中，通常会通过增加约束来减少幻觉，例如使用 RAG 引入真实数据，或者在 Prompt 中明确限制模型只能基于给定内容回答。

---

11、Context（上下文）

　　上下文是模型在生成答案时可以看到的全部信息，包括用户输入、历史对话以及系统提供的数据。

　　上下文越丰富，模型理解能力越强，但同时也会带来成本增加和长度限制的问题。

　　在后端设计中，需要对上下文进行合理控制，比如只保留最近几轮对话，或者只传递最相关的检索结果，以平衡效果和性能。

---

12、Streaming（流式输出）

　　流式输出是指模型生成结果时不是一次性返回，而是逐步输出内容。

　　这种方式在用户体验上更加自然，可以让用户更快看到结果，类似聊天应用中的“打字效果”。

　　在后端实现上，一般会通过 SSE 或类似机制，把模型生成的数据实时推送给前端。这一块在实际项目中也比较常见，属于体验优化的重要手段。

---

总结

　　从整体来看，这些 AI 名词可以分成三个层面来理解。

　　第一层是模型能力，比如 LLM 和 Prompt，决定了系统“能生成什么”；
　　第二层是数据能力，比如 Embedding、向量数据库和 RAG，决定了“生成得准不准”；
　　第三层是执行能力，比如 Agent 和函数调用，让 AI 从“回答问题”升级为“完成任务”。

　　对于后端开发来说，真正的核心并不是掌握模型原理，而是如何把这些能力组合起来，融入到业务系统中。

　　当你能从工程实现的角度，把这些概念讲清楚并结合实际场景说明时，基本已经具备 AI 方向面试的核心竞争力了。