1、基础认知与技术选型

Q1-1. RAG 和微调（SFT）的核心区别是什么？能不能一起用？

RAG 解决的是“知识从哪里来”，微调解决的是“模型应该怎么表现”。

RAG 不改模型参数，而是在运行时把相关资料检索出来，再交给模型生成答案，所以更适合处理时效性强、更新频繁、需要可溯源的知识。微调会改模型参数，更适合提升输出风格一致性、结构化能力、分类能力或领域行为稳定性。

它们当然可以一起用，而且很多企业项目就是这么落地的：用 RAG 提供知识，用微调或强约束输出提升行为稳定性。比如客服项目里，产品政策靠 RAG 保持最新，回复格式和字段输出靠微调或结构化输出保证稳定。

常见追问：

• 为什么多数企业项目不会优先做续训？
• 什么场景适合 RAG + 微调 组合？
• 如果预算有限，先做哪一个？

重要度：必刷（出现次数：3次） | 难度：中等

**考察点：**知识增强和行为优化的区分能力。

对应章节：1-3 RAG、微调、续训与智能体选型 §1、RAG；1-3 RAG、微调、续训与智能体选型 §2、微调（Fine-tuning）

Q1-2. 什么是 AI Agent？它和传统 AI 应用的区别是什么？

可以概括为：Agent = 模型 + 工具集 + 运行循环 + 当前状态。

• 模型负责理解目标和决定下一步。
• 工具集负责提供外部能力。
• 运行循环负责让系统不是只回答一次，而是能“想一步、做一步、看结果、再决定下一步”。
• 当前状态负责保存消息、工具结果和中间结论。

传统 AI 应用更接近“输入一个请求，返回一个结果”的单轮系统；Agent 更接近“围绕目标持续做决策”的运行方式。它的关键不只是用了大模型，而是具备了工具调用、状态推进和动态决策能力。

所以不是所有 AI 应用都该叫 Agent。固定表单生成、固定知识问答、固定流程审批，这类系统往往用普通链路或 Workflow 就够了。只有在路径不固定、需要根据中间结果继续选择工具或调整路线时，Agent 才真正合适。

另外也要注意，很多人会把“长期记忆、复杂规划、多智能体协作”都当成 Agent 的必备条件，不是。对很多入门场景来说，能做到“理解目标、决定是否调工具、拿到结果再继续判断”，就已经是 Agent 了。

重要度：高频（出现次数：2次） | 难度：基础

**考察点：**是否理解 Agent 的本质，不会把任何聊天机器人都叫 Agent。

对应章节：21 Agent智能体 §1、Agent 简介；1-3 RAG、微调、续训与智能体选型 §4、智能体开发

Q1-3. 什么时候该用 Prompt、RAG、微调、Workflow、Agent？

最稳的判断方式，是先判断问题到底是缺知识、缺行为，还是缺流程能力。

• 如果模型本来就会，只是任务没描述清楚，先用 Prompt。
• 如果缺的是私有知识、最新知识、外部知识，优先上 RAG。
• 如果缺的是稳定行为，比如固定格式、固定语气、固定分类习惯，再考虑微调。
• 如果流程固定、节点明确、强调稳定和可审计，优先 Workflow。
• 如果路径不固定，需要边做边决定下一步、动态调用工具，再考虑 Agent。

这条选型主线可以压缩成一句话：

• Prompt 解决任务表达问题。
• RAG 解决知识来源问题。
• 微调 解决行为稳定问题。
• Workflow 解决固定流程问题。
• Agent 解决动态决策问题。

真实项目里通常不会一开始就说“必须做 Agent”。大部分需求先用 Prompt + RAG + Workflow 就能覆盖，只有在任务开放度高、工具选择依赖中间结果、流程没法提前写死时，Agent 的价值才会真正体现出来。

常见追问：

• 为什么很多项目不一开始就做微调？
• 为什么不是所有复杂任务都适合 Agent？
• Workflow 和 Agent 的分界线是什么？

重要度：必刷（出现次数：1次） | 难度：中等

**考察点：**技术选型能力、边界意识、是否有工程判断。

对应章节：1-3 RAG、微调、续训与智能体选型 §1、RAG；1-3 RAG、微调、续训与智能体选型 §4、智能体开发

Q1-4. Token 和上下文窗口是什么？它们在工程上意味着什么？

Token 可以看作模型处理文本的基本计量单位，不等于“字数”或“单词数”。模型在训练和推理时看到的不是原始文本，而是 tokenizer 切出来的一串 token。

上下文窗口则是模型单次推理时最多能看到多少 token 的上限。工程上常说的 8K、32K、128K，本质上说的都是“这次请求里系统提示、历史对话、检索结果、用户问题加起来最多能塞多少 token”。

它的工程意义非常直接：

• 上下文窗口决定了你能不能做长文问答、多轮对话和大段 RAG 上下文拼接。
• token 越多，成本通常越高，延迟也更容易上升。
• 超出窗口的内容会被截断、压缩或根本进不了模型，所以不是“塞得越多越好”。

如果只做一个大致口径，128K token 可以看作很长的一段内容。按常见经验口径，1 个中文字符大约是 0.6 个 token，1 个英文字符大约是 0.3 个 token，所以 128K token 粗略可以近似成二十万级别的中文字符量级。但这只是估算，真实数字会因为 tokenizer、语言类型、代码、标点和格式不同而波动。

常见追问：

• 1 个汉字、1 个英文单词大概是多少 token，为什么不能死记一个固定值？
• 如果上下文被截断了，你会优先怎么处理？

重要度：高频（出现次数：1次） | 难度：基础

**考察点：**是否真正理解 token、上下文窗口和成本 / 截断 / 长文本场景之间的关系。

对应章节：1-1 大模型认知与工程概览 §1、认识大模型；11 Model I/O 与模型接入 §2、LangChain 模型分类、参数与返回

**来源：**腾讯AI后台工程师一面（实际大厂面试题）

Q1-5. 大模型应用上线前你最关心哪些工程指标？

通常会从效果、性能、成本、稳定性、治理性五个维度看。

• 效果：准确率、忠实度、任务完成率、引用正确率。
• 性能：首 token 延迟、端到端延迟、P95/P99。
• 成本：token 消耗、检索成本、工具调用成本。
• 稳定性：超时率、错误率、重试率、降级命中率。
• 治理性：日志、Trace、Prompt 版本、索引版本、权限审计。

如果是 RAG / Agent 项目，我还会额外看检索召回质量、工具调用成功率、人工兜底比例和 badcase 回灌效率，因为这些才是真正影响线上体验的关键指标。

常见追问：

• 你怎么设计降级策略？
• 如果成本超预算，先优化哪一层？
• 怎样做 Prompt / 模型 / 索引回滚？

重要度：高频（出现次数：1次） | 难度：中等

**考察点：**是否具备生产环境意识。

对应章节：1-1 大模型认知与工程概览 §4、大模型的工程实现（概览）；7 企业级大模型部署 §1、企业级大模型部署概述