AI 应用八股 · Day 1
🪐 1、什么是 LLM？它生成一段回答的大致原理是什么？
（Large Language Model）大语言模型
LLM会根据已经给定的上下文，预测下一个 Token 的概率分布，并不断重复这个过程，从而生成完整内容。
🪐 2、Token 是什么？
Token 是大模型处理文本的基本单位。
模型会通过 Tokenizer（分词器） 将文本切分成 Token，再将 Token 转换成模型可以处理的表示。
Token 不等于一个单词，也不保证等于一个汉字，具体如何切分取决于 Tokenizer。
🍉为什么调用 LLM API 时，我们会特别关注 Token 数量？
Token 数量会影响 API 成本、上下文窗口占用以及一定的计算开销。
🪐3 、Context Window
模型一次推理时能够处理的上下文 Token 总量上限
🍉为什么做 RAG 时不能把知识库里检索到的内容全塞进 Context？
① Context Window 有上限
② RAG 塞入大量无关内容，会带来更多噪声，降低回答的针对性，甚至影响准确性
③ Token 越多，通常 API 成本越高，处理开销也更大。
🪐 4、Prompt
Prompt 是我们给模型的指令
🪐 5、System / User / Assistant
System Message 用于设定模型的整体行为和规则（你是一个...）
User Message 表示用户的输入；
Assistant Message 表示模型的回复，并可共同组成多轮对话上下文。
🍉为什么多轮对话里，要把之前的 Assistant Message 也作为上下文提供给模型？
使模型了解之前已经回答过什么，从而保持多轮对话的 上下文连续性
🪐 6、Temperature
越高，生成结果通常随机性和多样性越强；
越低，模型越倾向选择高概率 Token，输出结果通常更稳定、更确定
🪐 7、Top-P
Top-P 是核采样参数，它按照 Token 概率从高到低累加，只在累计概率达到 P 的候选集合中进行采样，从而控制生成结果的多样性
🌀8、啥是LLM 幻觉？为啥会产生幻觉？💧 第 1 题｜为什么纯向量检索不够？
模型生成了看起来非常合理、语气非常确定，但实际上错误或根本不存在的信息。
（语言正确，但是与事实相悖）
原因之一是 LLM 的生成机制本质上是根据已有上下文预测后续 Token，而不是在生成每个 Token 时都进行事实核验，因此可能生成"语言上合理但事实上错误"的内容。
🪐 9、Structured Output
主要作用是 让LLM 稳定输出，方便后端解析
AI 应用八股 · Day 2
🧬1、什么是 Embedding？在 AI 应用/RAG 中，把文本转换成向量主要是为了干什么？
Embedding 就是把文本等信息转换成一个由数字组成的向量，用这些数字表示其语义特征。从而方便计算语义相似度，并用于向量检索等任务
🧬2、为什么文本能变成向量？
Embedding 向量不是人工定义的，而是模型通过训练学习得到的语义表示。向量通常具有很多维度，语义信息分布在这些维度中，因此语义相似的文本在向量空间中通常也更加接近。
🧬 3、Embedding Model、向量数据库/FAISS、LLM，这三个东西在 RAG 里分别负责什么？
①把文本转换成语义向量
②存储/索引 向量，并进行相似度检索（存数据时/查询时）
③根据用户问题 + 检索到的上下文生成最终回答
🧬 4、什么是向量维度？
Embedding 维度表示向量中数值的个数，语义信息通常分布在整个向量空间中，不能简单把某一维对应成具体的人类语义特征。
维度越高也不代表效果一定越好，还需要考虑模型本身的能力以及存储和计算成本。
🧬 5、余弦相似度是干什么的？
余弦相似度用于衡量两个向量方向上的相似程度。通常余弦相似度越高，说明两个文本的语义越相似。
🧬 6、Vector Store / Vector DB/ FAISS 是什么？
向量数据库
①存储 / 索引 向量
②并支持高效的向量相似度检索。
🧬7、Top-K 是什么？Top-K 是不是越大越好？
Top-K = 返回相似度最高的前 K 个结果。
K 不是越大越好，过小可能 召回不足；
过大可能 引入噪声 同时占用更多 Context Window 并增加 上下文 和 Token 成本
🍉用户问："我们公司的年假最多能结转多少天？" 系统把问题 Embedding 后，成功检索到了 Top-5 Chunk 。接下来是不是可以只把这 5 个 Chunk 发给 LLM？还是应该把什么东西一起交给 LLM？为什么？
把用户原问题和检索得到的 Top-K 相关 Chunk，
一起作为上下文交给 LLM 生成答案。
🧬 8、关键词检索 vs 向量检索
关键词检索主要基于词项的字面匹配，而向量检索通过 Embedding 表示文本语义，再根据向量相似度进行检索。
关键词检索对精确词、专有名词、编号等通常有优势，而向量检索更擅长处理字面不同但语义相似的内容。
因此实际 RAG 中可以结合两者进行混合检索（Hybrid Search）
🍉假设知识库有 100 万个向量。
用户每问一个问题，都把查询向量和这 100 万个向量逐个精确比较，当然也能找到最相似的结果。
那为什么实际向量检索系统还需要建立向量索引 ？向量索引主要是为了解决什么问题？
向量索引主要用于提高大规模向量数据下的相似度检索效率，避免每次查询都对所有向量进行暴力比较
🍉用户查询流程
【用户查询】 问题 → Embedding → 检索
→ Top-K（用户原问题 + 检索到的相关内容一起作为上下文给 LLM）→ LLM
AI 应用八股 · Day 3
☘️1、RAG 是知识库吗？它到底是什么？
RAG 是检索增强生成，它不是知识库本身，
而是一套先从外部知识库检索相关信息，再把检索结果作为上下文交给 LLM 生成答案的技术方案。
☘️2、既然 LLM 本身已经有很多知识了，为什么 AI 应用还需要 RAG？
① 让 LLM 利用外部知识
② 通过提供相关、可靠的上下文，降低幻觉风险
☘️ 3、公司内部知识每天都在更新，为什么你选择 RAG，而不是每次对 LLM 进行微调？"
对于频繁变化的企业知识，我会优先使用 RAG，因为知识更新主要通过更新外部知识库完成，不需要频繁调整模型参数；
而微调（Fine-tuning）主要通过训练改变模型参数，更适合调整模型的特定行为、风格或任务能力。
☘️4、什么是 Chunk？为什么 RAG 通常要把一个很长的文档切成多个 Chunk，再分别做 Embedding？
文档经过切分后得到的文本片段；
提高检索粒度和相关性，避免整个长文档作为一个向量导致语义过于宽泛。
☘️ 5、Chunk 是不是切得越小越好？
（Chunk Size → 每块有多大）
Chunk 太大 → 语义宽泛、噪声可能更多
Chunk 太小 → 上下文不完整、信息碎片化
☘️ 6、Chunk Overlap 是什么？为什么 RAG 切分文档时要保留一定的 Overlap？
相邻Chunk保留一部分重复内容，这样能够减少切分边界导致的上下文丢失
☘️7、 知识库是怎么构建出来的？
【知识库构建】 文档 → 解析(Parse) → Chunk → Embedding → 存储/索引（Vector DB）
☘️ 8、有了 RAG，为什么还会幻觉？
检索阶段出问题 → 没找到、找错了、相关性差。
生成阶段出问题 → LLM 没有严格依据检索内容回答，仍然产生错误内容。
Day 4｜RAG 优化
✴️ 第 1 题｜Hybrid Search
既然已经有向量检索了，为什么 RAG 还需要关键词检索？Hybrid Search 又是什么？
Hybrid Search 结合 关键词的精确匹配能力 和 向量检索的语义理解能力 ，提升召回效果。
✴️ 第 2 题｜Rerank
Rerank是干什么的？为什么不能把召回的所有 Chunk 都直接给 LLM？
Rerank：对 第一次检索召回的 候选 Chunk，再做一次更精细的相关性排序。
不能全丢给 LLM：因为会增加上下文占用和 Token 成本，还可能引入低相关噪声，干扰最终答案。
✴️ 第 3 题｜Query Rewrite（查询重写）
Query Rewrite 是干什么的？
把用户原始问题改写成更清晰完整、更适合检索的查询。
✴️ 第 4 题｜Metadata Filter（元数据过滤）
Metadata Filter = 利用文档附带的元数据，
先筛掉不符合条件的内容，再进行后续检索。
✴️ 第 5 题｜Recall 和 Precision
Recall：该找的，找回来多少 → 别漏**（召回率）** 衡量真正相关的数据中有多少被成功召回
Precision： 找回来的，有多少是真的 → 别错**（准确率 / 精确率）**衡量召回结果中有多少是真正相关的
✴️ 第 6 题｜综合优化流程
Query Rewrite（ 查询重写）→ 问得更好
Metadata Filter（元数据过滤）→ 范围更准
Hybrid Search （混合检索）→ 找得更全
Rerank （重排序）→ 排得更准
Top-K → 控制最终给多少
LLM → 根据问题和资料生成答案
✴️ 第 7 题｜综合场景题
为什么 RAG 经常采用：
先召回较多候选 → Rerank → Top-K
而不是：
第一次检索直接 Top-K → LLM？
先用低成本检索缩小范围，再用高成本 Rerank 精细排序，在召回效果、准确性、成本和延迟之间取得平衡。
✴️ 第 8 题｜最终综合题
公司要做一个内部 RAG：
用户的问题可能表达模糊 ；知识库包含不同年份和地区 ；既有"员工休假"这种语义问题，也有 ERROR-10086 这种精确关键词；第一次检索的排名还不一定可靠。
你从用户提问开始，把今天学的整个优化版 RAG 查询流程一口气说出来。
提示：今天学的 6 个核心组件都可以串进去。
首先通过 Query Rewrite 将用户问题改写得更清晰、更适合检索；
再利用 Metadata Filter 根据年份、地区等元数据缩小检索范围；
然后通过 Hybrid Search 结合关键词检索和向量检索，提高召回效果；
对召回的候选结果使用 Rerank 进行更精细的相关性排序；
再通过 Top-K 选出最相关的 K 个 Chunk，最后将 用户原问题 和 这些 Chunk 一起交给 LLM 生成答案。
Day 5｜Agent
🧩 第 1 题｜Agent 是什么？
普通 LLM 主要是理解和生成内容；
Agent 可以围绕目标调用外部工具，获取信息或执行实际操作
🧩 第 2 题｜Agent 的组成
🔥 LLM = 大脑，负责判断和决策
🔥 Tools = 手脚，负责执行操作
⭐ Memory/State = 记住执行到哪、已经得到什么信息
🧩 第 3 题｜Agent 的核心循环
Agent 每执行完一个 Tool 后，接下来应该做什么？
Tool 返回的结果要进入当前任务的 State / Context，再让 LLM 根据新结果决定下一步
🧩 第 4 题｜Agent vs Workflow
Workflow：按预先定义的流程执行。
Agent：根据当前任务状态和前一步结果，动态决策下一步行动。
🧩 第 5 题｜Agent vs Tool Calling
Tool Calling 本身不是工具，而是 LLM 选择并 调用外部工具的一种机制
Tool Calling = 让模型"会用工具"。
Agent = 利用 Tool Calling 等能力，围绕目标不断"决策 → 调工具 → 看结果 → 再决策"，直到完成任务。
🧩 第 6 题｜一个很重要的坑
Agent 应该在受控权限范围内自主决策；
对于高风险或不可逆操作，需要增加权限校验、人工确认等机制，而不是让模型无限自主执行
🧩 第 7 题｜Agent 和 RAG 的关系
RAG = 从外部知识库检索相关信息，并把检索结果作为上下文交给 LLM 生成答案的一套技术方案。
Agent = 围绕任务目标，根据当前状态和工具返回结果不断决策、执行、观察，再决定下一步的一套机制。
RAG 可以成为 Agent 使用的一种能力 / Tool。
🧩 第 8 题｜Agent 失败循环
怎么防止 Agent 陷入无限工具调用？
最大执行步数 ：最多执行 10 步，超过就停止。
超时限制 ：整个任务最多运行一定时间。
重复调用检测 ：相同参数反复调用同一 Tool 时终止或换策略。
失败次数限制 ：某个 Tool 连续失败几次就停止。
人工介入：无法继续时，让用户补充信息或确认下一步。
🧩 第 9 题｜Memory / State
State / Memory 到底保存的是什么？
保存当前任务推进所需要的状态信息
🧩 第 10 题｜Agent的动态循环
决策 → Action → Observation（看结果） → 根据结果再决策 → ...... → 完成
Day 6｜Tool Calling
🛠️ 第 1 题｜真正向天气 API 发请求的是 LLM 本身，还是我们的后端程序？
LLM 负责决定"调用哪个 Tool + 传什么参数"；
后端程序负责真正执行 Tool。
🛠️ 第 2 题｜假设后端给 LLM 提供了 10 个 Tool ，LLM 怎么知道每个 Tool 是干什么的、需要哪些参数？
name → searchOrder 工具叫什么
description → 查询用户的指定订单 帮 LLM 判断什么时候用它
parameters → userId、orderId 告诉 LLM 需要生成哪些参数
Tool Schema = 给 LLM 的工具说明书；
LLM 根据 Schema 选择 Tool，并生成符合要求的 Arguments。
🛠️ 第 3 题｜Tool Calling 最核心的完整闭环。
LLM：选工具 + 填参数
后端：执行工具
LLM：读执行结果 + 最终回答
🛠️ 第 4 题｜参数出错怎么办？
假设 Schema 要求：
userId: integer结果 LLM 却生成：
userId = "张三"后端应该无脑执行，还是应该先做某件事？为什么？
🔥 LLM 生成参数 → 后端校验参数 → 校验通过才执行 Tool。
🛠️ 第 5 题｜参数校验应该满足？
🔥 类型是否合法 + 值是否符合业务规则 + 当前用户是否有权限 + 高风险操作是否需要确认。
🛠️ 第 6 题｜开始接近真实开发
现在把前面串起来：
用户："帮我查用户 1001 的订单 A9527。"
你从 用户说话开始 ，一直讲到 LLM 最终回答用户。
尽量把这几个东西都带上：
Tool Schema、LLM、Arguments、后端校验、执行 Tool、Tool Result。
用户提出需求后，LLM 根据 Tool Schema 判断并选择需要调用的 Tool，同时生成对应的 Arguments（实参）；
后端收到 Tool Call（调哪个工具 + 这次传什么 Arguments） 后，对参数和权限进行 校验，然后真正执行 Tool；
得到 Tool Result 后再交给 LLM，最后由 LLM 结合执行结果生成最终回答。
🛠️ 第 7 题｜Tool Result 出错
有限重试 / 备用 Tool / 错误处理策略。
🛠️ 第 8 题｜Schema 设计
重点是让 name 和 description 有明确的业务语义 和 边界。
🛠️ 第 9 题｜最终大串
Tool Calling 是让 LLM 能够使用外部工具的一种机制。
应用程序提前向 LLM 提供 Tool Schema，描述工具的功能和参数要求。LLM 根据用户需求选择合适的工具，生成包含工具名称和 Arguments 的 Tool Call。后端收到请求后，进行参数校验和权限检查，再真正执行工具。
最后将 Tool Result 返回给 LLM，由 LLM 根据结果生成最终回答，或者决定是否继续调用其他工具。
🔌 Day 7｜MCP & Tool Calling & Agent
MCP 是一套让 AI 应用按照统一标准连接和使用外部工具、数据源等能力的协议；
Tool Calling 是让 LLM 能够选择并调用外部工具的机制；
Agent 则围绕任务目标进行决策，通过 Tool Calling 使用工具，并根据 Tool Result / Observation 不断进行下一步决策，直到完成任务。
🔥 LLM = 大脑，负责理解和决策
🔥 Tool Calling = 调工具的机制
🔥 **MCP Client = 使用方，**AI 应用侧负责连接和使用 MCP Server 的组件。
🔥 MCP Server = 提供方，把外部能力按 MCP 标准提供出来( 外部能力的标准化接入协议**)**
MCP 就是给 AI 应用接外部能力定了一套统一标准。
有了这个标准，别人做好的 MCP Server 我也能直接接入复用，不用每次都自己重新适配。
