AI 面试题
本页只放 AI 应用工程化面试标准回答、项目话术、常见追问和知识点跳转。大模型、Prompt、Embedding、向量库、RAG、微调、Agent、评估、安全和 LLMOps 的原理统一放到知识点页。
使用方式
mermaid
flowchart TD
A["面试页:会回答概念和落地"] --> B["知识点页:理解模型应用原理"]
B --> C["项目页:RAG、Agent、评估、安全、成本治理"]高频问题
| 面试题 | 标准回答 | 原理知识点 |
|---|---|---|
| AI、机器学习、深度学习、大模型是什么关系 | AI 是人工智能的总称,机器学习是 AI 的一种方法,深度学习是机器学习的一类方法,大模型是深度学习发展出来的通用模型。大模型能力很强,但 AI 不等于大模型。商业系统里通常会把规则、搜索、RAG、工具调用和大模型组合使用,而不是所有问题都直接丢给模型。 | AI是什么、大模型基础 |
| 机器学习模型怎样从数据学到参数 | 先定义样本、特征和标签,模型用当前参数前向计算预测,Loss衡量预测和标签的差距,反向传播计算各参数梯度,优化器沿降低Loss的方向更新参数;经过多个Batch和Epoch后,在独立验证、测试数据上检查泛化,再固定参数用于新数据推理。 | 模型训练完整过程 |
| 参数和超参数有什么区别 | 参数是模型从训练数据中学习出的值,例如线性模型的权重和偏置、神经网络权重;超参数是训练前或实验中设定的配置,例如学习率、Batch大小、训练轮数和网络层数。超参数通常通过验证集和实验选择,不能用测试集反复调。 | 机器学习基础术语 |
| Loss下降为什么不代表业务一定变好 | Loss是为优化参数设计的数学目标,不等于Precision、Recall、事实正确率或业务成本。类别不平衡时全部预测多数类也可能有很高Accuracy;还可能发生训练集过拟合、数据泄漏或高风险少数类退化,所以必须在独立数据上按业务标签和风险分组评估。 | Loss与业务指标、欠拟合与过拟合 |
| 为什么训练集、验证集和测试集要分开 | 训练集用于计算梯度更新参数,验证集用于选择超参数、阈值和训练轮数,测试集用于最后估计未见数据上的泛化。如果根据测试结果反复改模型,测试集就间接参与优化,分数会虚高;用户、文档和时间数据还应按实体或时间分组,避免近重复和未来信息泄漏。 | 数据集切分与泄漏 |
| 神经网络为什么需要非线性激活 | 多层纯线性变换仍可合并为一次线性变换,无法表达复杂决策边界。ReLU、GELU、Sigmoid等激活函数引入非线性,使多层网络能够组合形成复杂表示;反向传播再利用链式法则计算每层参数对Loss的影响。 | 神经网络原理 |
| 模型参数、RAG和Tool分别提供什么知识 | 模型参数适合通用语言和相对稳定模式,但不保证实时、精确和按权限查询;RAG把经过版本和ACL过滤的企业文档作为本次上下文;Tool从订单、库存等权威业务系统获取实时事实。三者不能互相替代。 | 三类知识来源 |
| 为什么大模型不是万能知识库 | 大模型主要根据上下文和训练中学到的模式生成下一个 token,不是实时查询企业数据库。它可能不知道最新数据、私有知识和用户权限,也可能产生幻觉。订单、库存、权限、金额、医疗和法律等事实必须来自业务系统、RAG 或受控工具,并配合引用、校验、审计和人工兜底。 | AI是什么、RAG知识库、工具调用 |
| AI 应用从 Demo 到生产要补什么 | 不能只调用模型接口。生产级 AI 应用要有场景边界、权限控制、Prompt 管理、RAG 或工具调用、结构化输出校验、评估集、安全防护、日志审计、成本监控和失败兜底。企业知识库和业务 Agent 还必须保证用户只能访问有权限的数据,高风险工具调用由后端校验和审计。 | AI从零到商业生产级掌握、AI从零到精通验收清单 |
| 大模型是什么 | 大模型通常指经过海量数据训练、具备通用语言理解和生成能力的模型,可以做问答、摘要、翻译、代码生成、内容创作等任务。 | 大模型基础 |
| Token 是什么 | Token 是模型处理文本的基本计量单位,不完全等于一个字或一个单词。它影响上下文长度、调用成本、截断策略和响应延迟。 | 大模型基础 |
| Tokenizer为什么通常使用子词 | 完整单词词表会非常大且无法覆盖新词,只按字符又会让序列过长。BPE、WordPiece、Unigram等子词方法在词表大小和序列长度之间折中。Token ID只是词表索引,大小没有语义;模型权重与Tokenizer必须配套。 | Tokenizer完整原理 |
| 大模型怎样生成一句话 | 文本先经过Tokenizer、Embedding和位置信息,多层Transformer形成上下文表示,LM Head输出整个词表的Logits,再经过Softmax和解码策略选出下一个Token;新Token追加到上下文后重复,直到EOS、停止词或长度上限。 | 大模型生成全过程 |
| Transformer 的核心是什么 | 输入Token先变成带位置信息的隐藏向量,每个Block用Self-Attention在位置间混合信息,用FFN对每个位置做非线性变换,再配合残差和归一化稳定深层训练。Decoder通过Causal Mask避免看未来,堆叠多层后由LM Head预测词表Logits。 | Transformer Block全过程 |
| Self-Attention 的 Q、K、V 怎么理解 | 输入X分别乘不同可训练矩阵得到Q、K、V;QK转置计算每个Query位置与Key位置的分数,缩放并加Mask后Softmax得到权重,再用权重汇总V。Q/K负责学习匹配特征,V负责被关注后贡献的信息,并不是把输入简单复制三份。 | QKV投影、Attention数值过程 |
| 为什么Attention分数要除以sqrt dHead | 头维度增大时Q、K点积分数的方差会增大,Softmax容易过早进入接近one-hot的饱和区域,非最大位置梯度很弱。除以sqrt(dHead)用于稳定分数尺度和训练。 | Attention缩放原理 |
| Causal Mask为什么必须在Softmax前加入 | 将未来位置分数置为负无穷方向,Softmax后对应权重趋近零,其余可见位置仍归一化为总和一。若训练时不遮罩未来,模型会偷看目标;若Softmax后简单置零但不重新归一,会改变输出尺度。 | Mask完整原理 |
| MHA、MQA和GQA有什么区别 | MHA每个Query Head有对应K/V Head;MQA让多个Query Head共享一组K/V;GQA让一组Query Head共享一组K/V,在质量、显存和带宽之间折中。KV Cache估算主要看K/V Head数量Hkv,不能机械使用Query Head数。 | MHA、MQA与GQA |
| 为什么 Transformer 需要位置编码 | Self-Attention本身不天然表达序列顺序。绝对位置、相对位置或RoPE让计算携带位置和距离;RoPE常对Q/K维度对按位置旋转,使点积包含相对位置关系。直接调大最大长度不代表模型在超训练长度上质量不变。 | 位置编码与RoPE |
| 为什么大模型生成会慢 | Prompt的Prefill可并行处理已有Token但长上下文会增加TTFT;Decode必须生成一个Token后才能继续,并且每步读取历史KV,主要影响TPOT。输出越长串行步数越多,高并发和长上下文还会扩大KV Cache与排队。 | Prefill与Decode、推理优化 |
| 训练和推理有什么区别 | 训练时目标Token已知,模型计算交叉熵损失并反向传播更新参数,配合Causal Mask可并行计算序列中的多个位置;推理不更新基础参数,而且下一个Token未知,必须生成后才能继续下一步,因此单请求Decode具有逐Token依赖。 | 训练与推理 |
| Temperature、Top-k和Top-p有什么区别 | Temperature缩放整个Logit分布,越高通常越发散;Top-k只保留固定数量的最高概率候选;Top-p保留累计概率达到阈值的最小候选集合。它们改变采样,不会给模型补充知识,也不能从根本上消除幻觉。 | 解码策略 |
| KV Cache为什么提速又占显存 | 历史Token每层的K/V在后续Decode中不变,缓存后只需计算新Token并读取历史K/V;但每个活跃序列都要保存K和V,理论元素量随层数、序列长度、K/V头数、Head Dim、精度和并发线性增长。GQA/MQA主要通过减少K/V头降低缓存与带宽。 | KV Cache形状与容量 |
| 大模型为什么会幻觉 | 模型优化的是上下文中下一个Token的条件概率,不是数据库里的事实约束。训练知识缺失或过期、上下文不足、RAG召回错误、工具结果误读和指令冲突都可能让流畅但错误的后续概率更高。应结合RAG或工具、引用校验、拒答、评估和高风险人工审核。 | 幻觉原理与治理 |
| 图片怎样进入多模态大模型 | 图片先安全解码、纠正方向、缩放或切Tile,再被划分为Patch或视觉区域;视觉Encoder生成特征,Projector映射到语言模型隐藏维度,形成可与文本Token融合的视觉表示,模型再通过Attention读取图片和问题并逐Token生成。 | 多模态图片处理原理 |
| 视觉Patch和视觉Token是什么关系 | 固定Patch方案会把图片切成区域并编码,但视觉Encoder可能继续降采样、重采样或按动态分辨率切Tile,所以理论Patch数不一定等于最终视觉Token或Provider计费Token。必须以目标模型实际Usage和规则为准。 | Patch与视觉Token |
| OCR和多模态模型怎么配合 | OCR擅长稳定提取文字、坐标和置信度,版面模型恢复表格结构;多模态模型结合图像布局和问题理解语义。票据等商业场景通常组合使用,并用Schema、金额日期规则和人工门槛验收关键字段。 | OCR与多模态 |
| 为什么高分辨率图片更慢更贵 | 分辨率和图片数量增加通常产生更多Patch、Tile或视觉表示,占用上下文、Prefill计算、显存和模型费用;高分辨率还增加上传、解码和存储成本。实际视觉Token算法由模型和Provider决定。 | 视觉Token与容量 |
| 视频为什么需要抽帧 | 视频帧数很大,全部送模型成本过高,因此按时间、镜头变化或事件触发抽帧,并提取音频做ASR。固定抽帧太稀会漏掉短事件,太密会产生大量重复,需要带时间标注的业务评估集选择策略。 | 视频处理链路 |
| 多模态RAG怎么做权限和引用 | 入库时为页、图片区域、帧或音频时间段保存稳定assetId、页码、坐标、时间戳、版本、租户和ACL;查询时先按权限过滤再召回,回答引用由应用绑定真实资产位置,不能让模型自由编造页码。 | 多模态RAG |
| 多模态上传接口要防什么 | 除扩展名和Content-Type外还要检查Magic Number、安全解码、解码后像素、宽高、页数、帧数、压缩比、病毒、处理时间和并发。小文件也可能是解压炸弹;原图、OCR和日志还要按敏感数据策略存储。 | 多模态上传安全 |
| DeepSeek是一个固定模型吗 | 不是。DeepSeek包含Base、Chat/Instruct、Coder、MoE、Reasoning和Distill等不同模型与服务;云API、本地权重、Ollama标签和第三方量化也可能不是同一产物。必须说明仓库、Revision、底座、参数、架构、Tokenizer、量化和许可证。 | DeepSeek模型家族 |
| DeepSeek R1小参数模型就是完整R1缩小版吗 | 通常不能这样理解。常见R1小参数标签对应基于某个Dense学生底座的蒸馏产物,学习了教师的部分推理行为;其架构、Tokenizer、参数和能力由学生底座及蒸馏过程决定,不等于完整大型MoE模型机械裁小。 | DeepSeek Distill原理 |
| MoE为什么总参数大但单Token计算相对少 | MoE有多个专家,Router对每个Token打分并只选择Top-k路由专家参与计算,所以单Token激活参数少于全部专家总参数;但部署仍需存储或分布加载专家权重,因此总参数、激活参数和部署显存必须分开看。 | Dense与MoE |
| MoE Router怎么工作 | Router读取Token隐藏状态,为专家计算分数,选择Top-k专家,各专家执行FFN后按路由权重聚合;共享专家是否参与、Top-k和负载均衡方式取决于具体版本。Router还要避免专家热点和负载失衡。 | MoE Router |
| MoE部署为什么有跨卡通信 | 专家可能分布在不同GPU,Token必须根据Router结果发送到专家所在设备,计算后再将输出返回原Token位置,形成All-to-All方向的数据交换。性能受互联、专家布局、热点、Batch和通信计算重叠影响。 | MoE专家并行 |
| MLA解决什么问题 | MLA是部分DeepSeek架构中对注意力KV状态进行低维潜表示压缩的设计方向,目标之一是降低KV Cache和内存带宽压力。它不会让Cache消失,也不能泛化到所有DeepSeek和蒸馏模型,必须看具体模型配置。 | MLA原理 |
| DeepSeek的OpenAI兼容接口能零修改替换吗 | 不一定。兼容通常表示请求形状相似,模型名、Reasoning字段、Tool Calling、JSON Schema、Usage、错误体和SSE事件可能不同。应通过适配层逐项契约测试并记录Provider版本。 | 兼容接口边界 |
| DeepSeek本地知识库为什么还需要Embedding模型 | 聊天或推理模型负责生成,不会自动把上传文档建立向量索引。RAG还要用Embedding模型将文档和问题映射到同一向量空间,经权限Filter、召回和Rerank后,再把片段交给DeepSeek回答。 | DeepSeek与RAG |
| Prompt Engineering 是什么 | Prompt Engineering是把业务任务编译成模型可执行协议的工程过程,包含消息角色、可信数据边界、上下文选择、Few-shot、结构化输出、注入防护、Token预算、版本管理、评估和灰度。Prompt只是软约束,权限和业务安全仍由后端保证。 | Prompt完整生命周期 |
| 为什么Prompt不能作为权限边界 | 自然语言规则只是参与模型下一个Token概率计算,不能像鉴权代码一样提供确定性隔离,还可能受用户、RAG文档和工具结果的间接注入影响。租户与角色必须来自认证上下文,RAG召回前做ACL,工具在后端重新鉴权。 | 消息角色与可信边界、注入分层防线 |
| Prompt怎样从业务请求编译出来 | 应用先完成认证和场景路由,加载不可变Prompt版本,校验模板变量,选择并按ACL过滤历史、RAG和工具上下文,再按Token预算裁剪,组装分角色消息、工具和输出Schema;响应经过语法、Schema与业务三层校验。 | Prompt编译全过程 |
| Prompt上下文超预算怎样裁剪 | 先保留安全规则、输出契约和当前问题,再压缩或裁剪历史;RAG片段去重并按相关性、权威性、时效性和证据覆盖取舍;工具结果只保留必要字段。不能直接从字符串尾部截断,否则可能截掉Schema、引用或问题。 | Token预算与裁剪 |
| Prompt Injection为什么不能只靠一句提示词防住 | 模型同时处理规则和不可信文本,不提供操作系统式强隔离;攻击还可能藏在PDF、网页、OCR、RAG文档或工具结果中。需要输入检查、检索ACL、指令数据分层、工具允许列表与后端鉴权、输出校验、安全评估共同防御。 | Prompt Injection原理 |
| 结构化输出为什么要做三层校验 | 第一层验证JSON等语法能否解析,第二层验证字段、类型和枚举是否符合Schema,第三层验证金额、资源归属、权限、引用和状态机等业务语义。Provider原生Schema能改善形状,但不能证明事实和业务合法。 | 结构化输出三层校验 |
| Prompt怎样发布和回滚 | 新Prompt使用不可变版本,与模型、知识库和工具Schema版本联合记录;先做变量测试和固定评估集A/B,通过质量、安全、成本硬门禁后再影子或小流量灰度。线上分场景指标恶化时切回稳定版本,并把失败样本加入回归集。 | Prompt版本发布 |
| Prompt评测完整流程是什么 | 先用版本化Case定义身份、Fixture、预期路由、事实、禁用内容、引用、Tool Call、Schema和硬门禁,再冻结应用、Prompt、模型参数、RAG、Tool、策略、数据集及评分器形成Run Manifest。对同一Case配对运行基线和候选并保存中间证据,先做确定性评分,再做校准Judge与人工复核;按风险分层通过后依次进入Shadow和Canary。 | Prompt评测完整流程 |
| 为什么评测要冻结Prompt、模型、RAG和Tool版本 | 最终输出由整条应用链共同决定,只保存Prompt无法复现。模型别名、索引Alias、Embedding、Reranker、Tool Schema或Judge任一变化都可能改变结果。运行开始时要把解析后的配置保存成不可变Manifest并计算Hash,报告只能引用该快照。 | 不可变Run Manifest |
| 为什么平均分提升也不能直接上线 | 大量普通问题的小幅提升可能掩盖跨租户泄露、未授权写工具或JSON失败。发布先检查Critical单例和关键场景硬门禁,再看分层质量、成本、延迟和统计区间;平均分只是一个证据。 | 权重、分层与硬门禁、AI安全 |
| Prompt黄金答案应该怎么写 | 不应只保存一段全文,而应组合必须事实、禁止内容、允许引用、拒答条件、期望Tool及参数、JSON Schema、业务不变量和人工Rubric。精确枚举、金额和权限优先由确定性规则判断。 | 完整样本契约 |
| Pointwise和Pairwise Judge有什么区别 | Pointwise对单答案按Rubric评分,适合多维报告但尺度可能漂移;Pairwise比较同题A/B相对优劣,更容易判断差异但存在位置偏差。Pairwise应随机换位,两者都需固定版本、人工校准和争议复核。 | LLM-as-Judge |
| 用模型给模型打分可靠吗 | 可用于语义初筛,但Judge会有位置、冗长、风格、自偏好、知识越界和版本漂移。必须用业务人工标签校准,要求返回理由与证据;权限、金额、医疗等高风险结论仍交给确定性规则或合格人工。 | Judge偏差与校准 |
| 为什么同一个评测Case要重复运行 | 模型和Provider可能具有随机性,单次结果可能碰巧成功。基线和候选应使用相同Fixture分别重复运行,比较均值、中位数、最差结果、格式成功率和硬失败;安全样例任一次严重泄露通常就应阻断。 | 重复运行原理 |
| 配对Bootstrap区间说明什么 | 先对同一Case计算候选减基线的差,再对Case索引有放回重采样,估计平均差的不确定范围。区间跨0表示当前样本不足以清晰支持平均改善;它依赖代表性样本,也绝不能覆盖独立安全硬门禁。 | Bootstrap原理与Demo |
| Shadow和Canary有什么区别 | Shadow复制真实请求给候选,但用户仍看到基线,候选写工具必须禁用或模拟;Canary让小比例真实用户收到候选,需要会话稳定路由、阶段门槛、观察窗口和自动回滚。离线通过通常只允许进入Shadow。 | 从离线到全量发布 |
| 结构化输出为什么重要 | 业务系统需要稳定解析结果。通过 JSON Schema、格式约束、重试校验等方式,可以降低模型输出不可解析的风险。 | 提示词工程、AI评估 |
| Embedding 是什么 | Embedding是模型把文本等对象映射成固定维度向量,使训练任务定义的相似对象在空间中更接近。文本一般经过Tokenizer、Encoder、Pooling、可选投影与归一化;它适合语义候选召回,但不负责权限、版本和事实正确性。 | Embedding完整原理 |
| Token Embedding和文本检索Embedding有什么区别 | Token Embedding是Vocab×Hidden查表矩阵,为每个Token提供初始向量;Transformer隐藏状态结合了上下文;文本检索Embedding再按模型约定对有效Token Pooling并投影、归一化成每段一个向量。聊天模型任意隐藏状态不等于经过检索训练的句向量。 | 三种表示的区别 |
| Embedding模型怎样训练 | 常见双塔方向分别编码Query和Document,使用应匹配文本对作为正样本,使用随机、In-batch和困难负样本作为不匹配候选;对比Loss提高正对相似度、降低负对相对分数,反向传播更新编码器。假负样本会错误推远真正相关文档。 | Embedding对比学习 |
| Mean Pooling为什么要使用Attention Mask | Batch中的Padding只是补齐长度,不是正文。Mean Pooling要累加Mask为1的Token并除以有效Token数;把Padding算进去会污染向量,短文本通常受影响更明显。CLS、Last Token等策略也必须与模型训练约定一致。 | Pooling原理 |
| 余弦、点积和欧氏距离有什么关系 | 余弦主要比较方向,点积同时受方向和模长影响,欧氏距离比较空间距离。文档与查询都L2归一化后,点积等于余弦,平方欧氏距离等于2-2cosine,排序方向等价;未归一化时不能直接替换。 | 相似度数学关系 |
| 文档和问题为什么要用兼容的Embedding契约 | 两者必须位于兼容向量空间,但可能分别需要Query和Document指令。模型、Tokenizer、角色指令、Pooling、归一化、维度和预处理共同组成embeddingRevision;任一侧不一致都可能导致召回退化。 | Query与Document契约 |
| 更换Embedding模型为什么通常要重建索引 | 新模型产生不同坐标空间,即使维度相同也不可直接比较。应以新Revision构建独立候选索引,校验数量、维度和ACL,用固定集比较Recall、MRR、延迟与成本,通过后原子切换Alias;查询Revision必须和索引匹配。 | Embedding索引迁移 |
| 怎样评估Embedding召回质量 | 建立真实Query与相关Chunk标注,Recall@K看相关文档是否进入前K,MRR关注第一个相关结果名次,nDCG评估多级相关排序;还要按业务域、语言、长度、精确词、困难负样本和权限分组,不能只看总平均。 | Embedding检索评估 |
| 向量相似度高就一定能回答吗 | 不一定。相似度高可能只是同主题、不同问题、旧版本或相反结论。应分别检查正确Chunk是否进入召回、Rerank、最终Prompt以及答案是否受引用支持,并结合关键词、Metadata、ACL、阈值和评估集。 | 相似度与答案覆盖 |
| 向量数据库做什么 | 向量数据库保存向量、主键和Metadata,通过精确KNN或ANN返回相似TopK,并处理Filter、分片归并、写入可见性、更新删除、副本和恢复。它是语义检索副本,不替代订单、金额等权威事务数据。 | 向量数据库完整原理 |
| 向量数据库为什么查询快 | 它通常用ANN避免对全部N条向量逐一比较。HNSW在分层近邻图上导航,IVF只扫描最近的nprobe个桶,PQ用码本压缩并近似距离;访问候选减少换来低延迟,但可能漏真实TopK,因此必须同时测Recall。 | 精确KNN与ANN |
| HNSW查询过程是什么 | 从最高层入口点开始,沿更接近Query的邻居贪心移动,局部收敛后逐层下降;到Layer 0后维护efSearch规模方向的候选和最佳集合并继续扩展。M影响图边和内存,efConstruction影响构图质量,efSearch影响Recall与查询延迟。 | HNSW构建、HNSW查询 |
| IVF的nlist和nprobe是什么 | nlist是粗聚类中心或倒排桶数量,建库时向量分配到最近桶;nprobe是查询时搜索的最近桶数。增大nprobe通常扫描更多候选、提高Recall并增加延迟。Query位于分桶边界时,真实最近邻可能在第二个桶。 | IVF完整原理 |
| PQ为什么节省空间又损失精度 | PQ把向量拆成多个子空间,每段只保存最近码字编号;查询保留原向量并用码字距离表估算候选距离。真实子向量被码字近似,量化误差会改变距离和排序,所以常配合过采样和原向量精排。 | PQ完整原理 |
| 为什么Post-filter可能不足K条 | Post-filter先做全库ANN TopN,再删除不满足租户或权限的候选。若高分项多数越权,合法但全局排名稍低的记录从未进入TopN,最终会少于K;越权候选也可能进入内存或日志。应优先Pre-filter或Filter-aware ANN。 | 向量过滤执行方式 |
| 分布式向量检索怎样得到全局TopK | Coordinator将Query和Filter路由到相关Shard,各Shard执行Local ANN并返回过采样候选;Coordinator在分数可比较的前提下归并、去重,按需做混合融合与Rerank,再得到Global TopK。P99常受最慢Shard、Fan-out和热点影响。 | 分片与Global TopK |
| 删除向量后为什么空间不立即下降 | 很多索引先写墓碑让记录查询不可见,后台Compaction或索引重建才物理回收Segment、HNSW节点和文件空间;WAL、快照和副本也可能保留历史。删除后仍能搜到还要检查副本延迟、旧Alias、关键词索引和缓存。 | 更新删除与墓碑 |
| 向量库选型和压测看什么 | 要用真实数据同时测Recall@K、MRR、P95/P99、QPS、CPU、内存、构建时间、写入可见和删除传播,并覆盖不同Filter选择性、TopK、并发、增量写与Compaction。应画参数到质量和延迟曲线,而不是只测官方单点Demo。 | 生产压测 |
| RAG 是什么 | RAG 是检索增强生成,先从知识库检索相关资料,再把资料和问题一起交给模型回答,让模型基于外部知识作答。 | RAG知识库、RAG流程 |
| 为什么需要 RAG | 通用模型不知道企业私有知识,知识可能过时,也可能产生幻觉。RAG 能把回答锚定到指定资料,并支持知识更新。 | RAG知识库 |
| RAG 离线建库流程是什么 | 离线流程包括文档解析、清洗、脱敏、按语义切分 Chunk、补充标题路径、来源、版本、权限等元数据,生成 Embedding,并写入向量库和结构化库。建库质量决定检索质量,解析错、切分错、权限元数据缺失都会导致线上答错或越权。 | RAG知识库 |
| RAG 在线问答流程是什么 | 在线流程包括身份认证、问题清洗、多轮问题改写、实体抽取、权限过滤、向量和关键词混合检索、Rerank、阈值判断、Prompt 组装、模型生成、引用校验和日志记录。 | RAG知识库 |
| RAG为什么要使用稳定docId和chunkId | 稳定ID让系统能判断内容是否变化、复用未变Embedding、幂等写入、删除旧Chunk、保持引用并按文档对账。每次随机UUID会让增量更新退化为重复新增,也难以传播删除。 | RAG稳定ID |
| Embedding批处理失败怎样恢复 | 每批记录batchId和chunkId,校验响应数量、维度和NaN;以chunkId + contentHash + embeddingRevision作为幂等身份,只重试失败批次。所有批次和索引计数校验完成前,候选索引不能发布。 | Embedding批处理 |
| RAG索引怎样做到蓝绿发布和回滚 | 新数据写入独立候选索引,完成文档/Chunk计数、维度、ACL、抽样检索和固定评估后,原子切换Alias;请求固定记录实际indexVersion,缓存Key带版本。异常时Alias切回旧索引。 | RAG蓝绿索引 |
| Query Rewrite有什么风险 | 多轮改写可把“第二个怎么用”补成独立查询,但也可能错误加入实体、改变意图或扩大范围。应保存原问题和改写问题,只有指代/省略场景才改写,并用检索评估证明Recall或MRR确实提升。 | Query Rewrite |
| RAG为什么使用混合召回 | 向量检索擅长语义同义,关键词/BM25擅长错误码、字段名和编号精确匹配。可各召回候选后用RRF等方法融合排名,再去重和Rerank;不能直接相加不同检索器未归一的原始分数。 | 混合召回与RRF |
| RAG引用怎样防止模型编造 | Prompt中只给候选Chunk的内部引用ID,模型只能引用这些ID;返回前应用校验ID属于本次候选、用户有权限、索引版本一致,并从真实Metadata渲染URL、页码、坐标或时间段。 | RAG引用验证 |
| RAG为什么需要定期对账 | 源系统、原始快照、元数据数据库、向量索引和缓存是多个副本,更新、删除和重试可能部分成功。应按docId、chunkId、batch和indexVersion比较active文档、Chunk、Embedding、索引和删除结果。 | RAG对账 |
| RAG 数据治理是什么 | RAG 数据治理是对知识库资料从采集、解析、清洗、脱敏、切分、元数据、权限、向量化、发布、更新、删除到评估的全生命周期管理。目标是让资料来源清楚、内容干净、权限正确、版本可控、可引用、可回滚、可排查。 | RAG数据治理 |
| RAG 为什么不能只存文本和向量 | 因为文本和向量只能做相似度检索,不能支持生产需要的权限过滤、引用来源、版本控制、增量更新、删除同步和问题排查。至少要保存 docId、chunkId、标题、路径、版本、权限标签、租户、内容哈希、Embedding 模型和入库批次。 | RAG数据治理:元数据设计 |
| 文档删除后为什么 RAG 还可能回答旧内容 | 常见原因是只删除了原文,没有删除向量库里的 Chunk,或者缓存里仍保留旧召回结果。正确做法是文档删除时同步标记 Chunk 失效、删除向量、清理缓存,并在检索条件里只允许 active 状态资料。 | RAG数据治理:删除同步和过期治理 |
| RAG 的 TopK 怎么设置 | TopK 太小容易漏掉答案,太大会引入噪声、增加 token 成本并干扰模型。生产常用两段式:先召回较多候选,再用 Rerank 选出少量高质量片段进入 Prompt。 | RAG知识库 |
| Chunk 切分为什么重要 | Chunk 是检索和组装上下文的最小单元。切太碎会丢上下文,切太大会召回不准并增加噪声。应按标题、段落、条款、表格、字段等语义边界切分,并保留来源、版本、权限等元数据。 | RAG知识库 |
| 为什么 RAG 要做混合检索和 Rerank | 向量检索擅长语义相似,关键词检索擅长字段名、表名、接口名、错误码等精确匹配。Rerank 会对候选结果二次排序,让真正能回答问题的片段排到前面。 | RAG知识库 |
| RAG 和微调区别 | RAG 不改模型参数,适合补充知识和引用资料;微调会改变模型行为,适合稳定任务风格、领域格式或特定能力。企业私有知识通常先考虑 RAG。 | 模型微调、RAG知识库 |
| 什么场景应该微调 | Prompt已经清楚、任务输入输出长期稳定、基础模型具有潜在能力,并且有授权数据、独立测试集和可量化基线时,可以考虑微调分类、抽取、固定格式、话术或工具参数。频繁更新知识用RAG,实时事实和动作使用Tool Calling。 | 微调决策流程 |
| 为什么微调前必须建立基线 | 基线用于证明训练是否值得。至少比较基础模型加当前Prompt、优化Prompt、适用时的RAG/工具方案和微调模型,并固定测试集、推理参数和评分规则;否则输出“看起来更像”可能掩盖事实正确率下降。 | 微调基线 |
| 训练Loss下降为什么不代表可上线 | Loss衡量训练Token预测目标,可能因为记住训练样本而下降。上线还要在独立测试集比较业务指标、安全硬门槛、通用能力回归、延迟和成本,并通过Shadow、Canary和回滚验证真实流量。 | Loss与业务效果 |
| 微调数据为什么要先去重再切分 | 如果先随机切分,同一工单、模板或近似改写可能跨Train和Test,模型测试时实际见过答案,造成分数虚高。应先规范化、去重和按事件/实体形成groupId,再按group切分并检查泄漏。 | 数据去重与切分 |
| Train、Validation和Test分别做什么 | Train用于更新参数;Validation用于选学习率、Epoch和Checkpoint;Test在候选方案冻结后做最终独立验收。若反复根据Test结果修改数据和参数,Test就变成验证集,需要新的盲测集。 | 数据集职责 |
| SFT中的Label Mask是什么 | Chat样本包含System、User、Assistant和Padding。Assistant-only SFT通常只在目标回答Token上计算Loss,把其他位置设为忽略值。Mask错误可能让模型学习复述输入,或把答案全部遮掉而学不到目标。 | Chat Template与Labels |
| LoRA为什么能减少可训练参数 | LoRA冻结原线性层W,用低秩增量ΔW=BA适配任务。W有d_out×d_in个参数,而A、B只有r(d_in+d_out),当Rank远小于输入输出维度时,可训练参数、梯度和优化器状态显著减少。 | LoRA矩阵原理 |
| QLoRA和LoRA有什么区别 | LoRA通常以较高精度加载冻结基础权重并训练Adapter;QLoRA将冻结基础权重量化为4-bit等低比特存储,计算时反量化到BF16/FP16等计算精度,仍只更新LoRA参数。它降低权重显存,但激活、梯度和工作区仍占资源。 | QLoRA原理 |
| LoRA的Rank和Alpha怎么理解 | Rank决定低秩Adapter容量和参数量;Alpha通常通过alpha/r缩放增量路径。Rank太小可能欠拟合,太大增加成本和过拟合风险;它们还与目标层、学习率和数据共同作用,必须通过验证和回归选择。 | LoRA关键参数 |
| QLoRA为什么仍可能显存OOM | 4-bit主要压缩冻结基础权重,训练仍需要Adapter、梯度、优化器、激活、Kernel工作区和CUDA开销。长序列和Micro Batch会显著增加激活,因此模型能加载不代表能够以目标长度和并发训练。 | 训练显存组成 |
| 微调模型怎样证明可以上线 | 在冻结Test和评估协议下,对同一输入公平运行基线与候选,比较任务指标、分层类别、安全硬门槛、通用回归、延迟和成本;通过后先Shadow再Canary,并设置阶段停止条件、自动回滚和完整版本血缘。 | 微调评估与上线 |
| Shadow和Canary有什么区别 | Shadow复制真实请求给候选,但用户仍看到基线结果,候选写工具必须禁用;Canary让小比例用户真正使用候选,需要稳定路由、最小样本量、阶段门槛和自动回滚。 | Shadow、Canary |
| 为什么微调模型回滚不只是切模型 | 路由切回只影响新请求,旧异步任务、长连接和缓存可能继续返回候选结果;候选已执行的工单、消息等写操作还需要业务补偿。因此回滚要处理流量、进程、任务、缓存、Adapter和业务数据。 | 微调回滚 |
| AI 幻觉是什么 | 幻觉是模型生成看起来合理但事实错误、来源不可靠或与资料不一致的内容。 | AI安全、AI评估 |
| 如何降低幻觉 | 可通过 RAG、资料引用、明确边界、结构化输出、拒答策略、事实校验、评估集和人工审核降低风险。 | AI评估、AI安全 |
| RAG 答错怎么定位 | 要拆成检索和生成两层看。先确认正确文档是否存在,再看 TopK 是否召回正确 chunk、重排是否把正确 chunk 排前面、Prompt 是否要求基于资料回答,最后看答案是否被引用支持。 | AI评估、RAG流程、商业实践:RAG排查 |
| RAG怎么防止越权 | tenant、role和dataScope从认证上下文构造Metadata Filter,在ANN或安全候选集阶段过滤;Rerank、缓存、日志和引用保持相同ACL。不能先全库召回再让模型过滤,因为无权限Chunk进入应用、Prompt或Provider时泄露已发生。 | RAG安全、RAG数据治理 |
| 直接和间接Prompt Injection有什么区别 | 直接注入来自用户;间接注入藏在网页、邮件、PDF、OCR、RAG文档或Tool Result中,用户可能只要求总结内容。指令分层只能降低概率,外发Tool目的地、字段、权限和执行副作用必须由后端硬控制。 | Prompt Injection原理、数据外传链 |
| AI安全为什么不能只靠Prompt | 模型把系统规则和不可信数据放在同一Token序列中处理,没有操作系统式硬隔离。Prompt用于引导;认证、ACL、对象权限、Tool允许列表、参数、确认、网络目的地和输出Sink由后端确定性策略控制,Critical风险还需回归、审计和事故响应。 | AI安全完整原理 |
| RAG文档注入是什么 | 攻击指令藏在知识文档中,模型检索后可能被诱导泄露上下文或调用外发工具。文档只能作为不可信事实,入库要做来源、Hash、版本和权限治理;运行时ACL前置,HTTP/邮件Tool使用目的地和字段允许列表。 | 间接注入、知识库投毒 |
| 什么是混淆代理 | 高权限后端被低权限用户通过模型诱导,替其访问无权对象或执行动作。根因通常是服务账号有权限且后端相信模型生成的tenantId/userId。修复是使用认证Principal、检查资源归属和字段权限,把模型参数视为不可信。 | 混淆代理 |
| AI工具怎样防SSRF | 默认不暴露任意fetch URL,改用业务化工具;允许协议、域名、端口和路径,DNS解析后拒绝回环、私网和链路本地IP,每次重定向重新验证,并通过出站代理、响应大小/时间限制且不自动携带内部凭据。 | SSRF与网络边界 |
| 模型输出为什么还会造成XSS、SQL或Shell注入 | 模型输出是不可信数据,交给浏览器、SQL、Shell、Markdown或模板解释器会产生第二次解释。应使用文本渲染和上下文编码、参数化SQL、允许列表参数与沙箱,不能直接拼接,也不能只让另一个模型检查。 | 输出到解释器的二次注入 |
| AI安全事故怎样处理 | 先分级止血,禁用Tool、切回Bundle、撤销Secret或隔离索引;保全Request、版本、检索、Provider、Tool和审计证据,确认数据与业务副作用;修复硬边界并对账补偿,将攻击及变体加入回归集后灰度恢复。 | 安全事故响应 |
| AI 应用为什么要做数据最小化 | 用户有权访问业务对象不代表整个对象都能发给模型。应用先确定Purpose,再按字段策略只保留完成任务必需且目标Provider允许的数据;无关手机号、地址、Token和成本应Drop,而不是等模型输出后再打星,因为那时数据可能已经进入Provider、日志和缓存。 | Purpose与最小化 |
| AI 数据安全怎么做 | 先建立用户输入、RAG、Tool、Prompt、Provider、日志、缓存、评估集和备份的数据流清单;按字段和自由文本分类分级,基于Purpose最小化;RAG前置ACL、Tool字段投影;Provider路由控制留存与区域;所有副本设置加密、访问审计、保留和删除传播。 | AI数据全生命周期安全 |
| 掩码、假名化、哈希、HMAC和加密有什么区别 | 掩码用于展示部分信息;假名化用受控Token替换身份并保留关联;低熵手机号裸哈希可被枚举,稳定关联更适合受控HMAC;加密持有密钥可恢复,用于传输和存储。它们都不替代最小化,假名化也不自动等于匿名化。 | 数据处理方式对比 |
| 为什么手机号不能只做SHA-256 | 手机号和身份证格式空间有限,攻击者可以枚举候选并计算哈希比对。若日志需要稳定关联,可用服务端秘密密钥HMAC并做好KMS、权限和轮换;若任务不需要该字段,最安全的是不采集或直接Drop,而不是换一种编码继续传播。 | 低熵数据与HMAC |
| 为什么不能把完整工具返回值给模型 | Tool Entity可能包含手机号、地址、内部成本、支付Token、异常栈和用户可控注入文本。后端应重新检查资源权限,按Purpose做字段允许列表、Drop、掩码或HMAC,限制条数和长度,并把结果标成不可信数据后再进入Prompt。 | Tool Result数据治理、Tool Calling |
| 第三方模型数据安全要评估什么 | 评估请求/响应留存、是否用于训练或人工审核、处理与备份区域、跨境和子处理者、加密与租户隔离、删除导出、事件通知和合同责任。模型路由要按数据级别限制Provider和Region,不能故障时自动降级到未批准Provider。 | Provider数据边界 |
| AI 日志为什么不能记录完整 Prompt | Prompt聚合用户输入、历史、RAG、Tool Result和系统规则,日志又会被索引、转发、备份并开放给更多人员。默认应记录requestId、版本、Chunk ID、Token和HMAC主体标识;内容调试要工单授权、采样、脱敏、加密和短期删除。 | 日志与Trace治理、LLMOps |
| AI缓存为什么必须带租户、权限和版本 | 相同Query在不同tenant、dataScope、Prompt、模型和知识索引下结果不同。Key只有问题文本会跨租户串数据或返回旧知识;至少包含tenantToken、ACL Hash、场景、Prompt、模型、索引和Embedding Revision,Value也只保存最小必要数据。 | AI缓存数据安全 |
| 评估集为什么也属于敏感数据 | 评估集常来自真实失败请求,包含用户问题、RAG片段、Tool参数和模型输出,并且保留时间比在线请求更长。入库前要确认用途、用合成值替换身份信息、按ACL保存;标注平台限权,使用LLM-as-Judge还会新增一个Provider副本。 | 评估与标注数据安全 |
| 为什么AI数据删除是分布式工作流 | 同一数据可能存在业务库、对象存储、RAG向量、关键词索引、会话、缓存、日志、评估集、Provider和备份。删除请求要枚举Target,先撤销检索使用,再异步删除并收集证据;备份到期销毁且恢复时重放删除清单,合法留存记录例外。 | 删除传播状态机 |
| Agent 是什么 | Agent 是让模型在目标驱动下进行规划、调用工具、观察结果并继续行动的应用模式。它适合多步骤任务,但要做好权限、审计和失败兜底。 | AI Agent、工具调用 |
| Agent和固定工作流怎么选 | 固定工作流的步骤和分支由代码或BPMN预先定义,稳定、可预测,适合支付、审批和状态流转;Agent根据当前State和Observation动态选择下一步,适合开放式分析。商业系统通常由固定工作流掌握关键状态,只把非结构化分析和候选建议交给局部Agent。 | Agent和工作流 |
| Agent一次执行循环怎么走 | 后端先创建包含目标、身份、预算和截止时间的State;Planner读取State提出结构化Action;应用校验工具Schema、权限和风险后执行工具,将脱敏Observation写回State并保存Checkpoint;再判断继续、完成、澄清、等待审批、拒绝或超限终止。 | Agent执行循环 |
| 为什么Agent状态不能只保存聊天记录 | 聊天消息适合给模型提供上下文,但不能可靠表达步骤版本、工具是否提交、幂等结果、预算和待审批计划。生产要把任务状态、业务事实、工具执行记录和Checkpoint结构化持久化,模型说“已完成”不能替代权威业务状态。 | Agent State与Observation |
| Agent为什么会死循环,怎么控制 | 常见原因是工具没有返回完成所需事实、State没有保存Observation、模型反复修正同一错误或验收条件不明确。除了最大步数,还要限制截止时间、工具次数、Token和金额、同类错误和重规划次数,并通过Action指纹检测无进展。 | Agent终止条件 |
| Agent写操作超时后能直接重试吗 | 不能。超时只说明调用方没有按时收到响应,下游可能已经成功提交。应把结果标记为UNKNOWN,使用服务端幂等键查询原执行结果;确认未执行后才按策略重试。业务表或工具执行表还要有数据库唯一约束。 | 超时但实际成功 |
| 多Agent一定比单Agent好吗 | 不一定。多Agent增加消息调用、状态同步、冲突解决、循环委派、权限和成本问题。只有不同角色确实需要独立工具权限或上下文、子任务可并行且每个角色能独立评估时才值得拆分。 | 多Agent选型 |
| Tool Calling 做什么 | 应用把当前场景允许的工具Schema发给模型,模型生成带tool_call_id的工具名和结构化参数;模型只提出调用意图,后端完成语法、Schema、业务、权限、风险和幂等校验后才执行,并把裁剪后的结果按原ID回传模型。 | Tool Calling完整原理 |
| Tool Calling 的底层流程是什么 | 请求先认证并按场景选择最小工具集,模型返回Tool Call;应用解析名称和参数并做四层校验,写操作生成不可变Plan等待确认,之后创建幂等执行记录并调用业务系统;结果记为SUCCEEDED、FAILED或UNKNOWN,裁剪脱敏后回传模型继续决策。 | 完整协议链 |
| tool_call_id为什么重要 | 一次模型响应可能包含多个Tool Call,结果完成顺序也可能不同。应用必须为每个调用独立保存状态、Deadline和审计,并用原tool_call_id回传对应Tool Result;丢失或错配ID会让模型把一个工具结果解释成另一个调用。 | tool_call_id关联原理 |
| 工具 Schema 怎么设计 | 名称要稳定具体,描述写清适用与不适用边界;参数使用object、required、enum、范围、格式和additionalProperties限制,避免自由SQL或万能text;同时记录schemaVersion、风险、权限、超时、幂等、确认和结果投影策略。 | 工具注册表、参数Schema |
| 为什么Tool参数要做四层校验 | JSON能解析只证明语法正确,Schema校验字段与类型,业务校验资源、状态和范围,权限校验当前用户是否能访问目标。tenantId、userId、roles和dataScope必须来自服务端认证上下文,不能相信模型生成参数。 | 四层校验、身份边界 |
| 写工具怎样做二次确认 | 后端先把模型参数校验成不可变Plan,记录工具/Schema版本、规范化参数、资源版本、用户、租户、风险、过期时间和planHash;确认Token绑定用户与planHash。确认后参数或目标变化会使旧Token失效,执行时还要重新鉴权和校验当前状态。 | 计划、确认与执行 |
| Tool Calling 为什么要做幂等 | 模型重试、网络超时、用户重复提交和Worker恢复都可能重复执行。应用使用稳定业务意图生成幂等键,执行表通过数据库唯一约束绑定planHash,下游也按同一Key去重并支持查询原结果;相同Key参数不同必须拒绝。 | 幂等完整原理 |
| 写工具超时后为什么不能直接重试 | 超时只表示调用方没收到响应,下游事务可能已提交。应记录UNKNOWN,使用原幂等键查询权威结果;查到后恢复SUCCEEDED,明确未执行后才按原Key重试,无法证明时继续后台对账或转人工,不能换新Key盲重试。 | UNKNOWN与对账 |
| 并行Tool Call怎样保证安全 | 只对无依赖、低风险的只读调用并发执行;每个tool_call_id独立记录参数、状态、权限和Deadline,结果按原ID回传。依赖调用必须串行,写操作即使模型并行返回也要按业务状态和审批顺序执行,部分成功不能总结成全部成功。 | 并行Tool Call |
| 为什么工具结果仍要当作不可信数据 | 结果可能含用户备注、网页、工单注入、内部异常栈和敏感字段。后端应按字段允许列表复核权限、裁剪、脱敏、限长和归一化错误,并在Prompt中标记为外部数据;不能把完整Entity、Header、Token或堆栈交给模型。 | Tool Result治理 |
| Agent工具调用怎么保证安全 | 模型只提出结构化意图;后端按注册表限制工具,使用认证Principal做对象级鉴权,校验Schema和业务状态。高风险写操作生成绑定用户、参数、资源版本和过期时间的planHash确认令牌,以幂等键执行并审计;UNKNOWN先查证。 | 工具安全分层、Tool Calling |
| AI 项目工程化关注什么 | 重点关注效果评估、延迟、成本、并发、缓存、限流、数据权限、提示词版本、日志审计、安全和回滚。 | LLMOps、AI应用架构 |
| AI 应用为什么要分层架构 | 因为生产 AI 不只是调用模型,还涉及入口鉴权、Prompt 编排、RAG、工具调用、模型网关、评估、安全、日志和成本。分层后每层职责清楚,模型可替换,Prompt 可回滚,RAG 和工具链路也能排查。 | AI应用架构 |
| 一次 AI 请求完整链路怎么走 | 请求先经过 API 鉴权、限流和参数校验,再由编排层判断场景,按需调用知识库检索和工具服务,然后通过模型网关调用模型,最后做引用校验、输出安全检查、记录 token/耗时/版本并返回。 | AI应用架构 |
| 模型网关有什么用 | 模型网关屏蔽不同供应商差异,统一请求格式、超时、重试、限流、fallback、模型路由、token 统计和调用日志,避免业务代码直接绑定某个模型 API。 | AI应用架构 |
| AI 应用同步、流式、异步怎么选 | 短问答适合同步;聊天和长文本生成适合流式,降低首 token 等待;文件解析、批量报告、复杂 Agent 适合异步任务,避免接口长时间阻塞并支持重试、取消和状态查询。 | AI应用架构 |
| 场景路由和模型路由有什么区别 | 场景路由决定业务处理链,例如直接问答、RAG、实时工具、写操作审批或异步任务;模型路由是在链路确定后,按Tool/JSON/多模态能力、上下文、质量、数据驻留、SLO和预算选择具体模型。两者不能混成“选一个模型”。 | 场景路由与模型路由 |
| AI请求Deadline怎样设计 | 先确定用户总Deadline,再为入口、RAG、Rerank、Tool、首Token和输出处理分配子预算;下游收到剩余Deadline,而不是每层重新获得完整超时。还要区分连接、TLS、首Token、空闲读取、总超时和写工具结果UNKNOWN。 | Deadline与超时预算 |
| 为什么AI限流不能只有QPS | AI请求耗时和Token差异很大,少量长请求也能占满连接、GPU槽位和预算。生产应同时限制请求速率、在途并发、Token和金额,调用前预留额度,按真实Usage结算并回收未使用额度。 | 四类限额 |
| SSE流式为什么可能最后一次性显示 | Provider可能已增量返回,但模型网关、应用、Nginx压缩/响应缓冲或前端读取方式可能把小块聚合。排查要逐跳记录事件时间和flush;客户端断连还要向上游传播取消,否则模型可能继续生成和计费。 | SSE流式链路 |
| 异步AI任务怎样防止永久RUNNING | 任务用状态机、version乐观锁、Worker租约和Heartbeat;执行中持续保存Checkpoint;后台扫描过期租约并重排或转人工。状态迁移要校验旧状态和版本,避免迟到Worker把已完成任务覆盖回RUNNING。 | 异步任务状态机、Worker租约 |
| Worker租约能否替代业务幂等 | 不能。Worker可能在工具成功后、Checkpoint提交前崩溃,租约过期后其他Worker会重领。查询和写工具仍需toolCallId、服务端幂等键和数据库唯一约束;超时结果不确定时先查证再重试。 | 租约与幂等、幂等与UNKNOWN |
| AI异步任务为什么需要Outbox | 任务状态改为SUCCEEDED和待发送事件在同一本地事务写入,避免数据库提交后MQ发送失败或先发MQ后数据不可见。Publisher至少一次发送Outbox,消费者按eventId幂等;它不自动原子提交两个独立数据库。 | AI任务Outbox |
| AI多Region有什么难点 | 除流量切换外,还要处理数据驻留、任务和会话复制、向量索引版本、全局配额、跨区幂等、Provider能力差异和会话粘性。高风险写操作通常需要单写Region或业务全局唯一约束。 | 多Region架构 |
| AI评估完整流程是什么 | 从业务任务定义样本单位、权威真值、错误代价和指标树,按真实流量与稀有风险构建分层、防泄漏数据集,通过盲标、双标和仲裁形成标签。按分类、抽取、RAG、生成、Tool或Agent选择指标,候选与基线同Case配对并设置安全硬门禁,最后用Shadow、Canary或A/B验证业务、性能和成本。 | AI评估完整原理 |
| 为什么分类Accuracy很高仍可能不可用 | 类别不平衡时全部预测为大类也能获得高Accuracy。例如风险只占1%,全预测正常有99% Accuracy但风险Recall为0。应看混淆矩阵、每类Precision/Recall、Macro F1和高风险FN,而不是一个总分。 | 混淆矩阵与指标 |
| Precision和Recall怎样选择 | Precision回答预测为正的有多少真实为正,Recall回答真实正类找回多少。漏掉风险代价高时优先Recall,人工容量有限时还要控制Precision;阈值结合FN、FP和审核成本以及硬约束选择,不能机械使用0.5。 | 阈值与错误代价 |
| 模型概率0.8就代表80%会发生吗 | 不一定,排序能力好不代表概率已校准。应在独立校准/测试集做可靠性分桶,比较每桶平均预测与真实发生率,并看Brier Score;Platt或Isotonic校准也不能在最终测试集上拟合。 | 概率校准 |
| RAG应该评估哪些层 | 依次评权威资料和版本、ACL可见性、Recall@K/Precision@K/MRR/nDCG、Rerank、最终Prompt上下文、答案正确性与Faithfulness、引用合法和引用蕴含、正确拒答。只看最终答案无法确定该修文档、检索、排序、Prompt还是模型。 | RAG逐层评估 |
| Agent为什么不能只评最终成功 | Agent可能完成任务却走了越权、重复写入或高成本路径。要同时评最终状态、每一步允许动作、工具顺序、状态不变量、循环、步数、Token、Deadline、Checkpoint恢复和副作用幂等。 | Tool与Agent评估 |
| 人工标注一致率高就说明标签可靠吗 | 不一定,类别极不平衡时全标大类也有高一致率。可用Cohen's Kappa扣除边际分布下的随机一致,但仍要看逐类混淆、高风险漏标和具体分歧;指南变更后应重标受影响样本。 | 真值与标注 |
| 离线分数提高为什么线上不一定有收益 | 数据集可能不代表真实流量,代理分数不等于任务完成,线上还有延迟、Provider抖动、用户学习和交互效应。A/B前要确定随机化单位、主指标和护栏,并先排查实际分流偏离计划的SRM。 | 线上A/B实验 |
| 用模型给模型打分可靠吗 | Judge适合语义初筛,但有位置、冗长、风格、自偏好和版本漂移。JSON、权限、引用集合等优先确定性规则;Judge用人工校准集验证并随机交换Pairwise顺序,高风险、低置信和分歧样本交给专家复核。 | 自动、Judge与人工组合 |
| 本地模型部署是什么 | 本地模型部署是把模型文件、推理运行时和模型服务部署在自己的服务器、内网或私有云里,由业务后端通过统一适配层调用。它适合数据隐私、离线可用、企业知识库和固定高频场景,但生产上还要关注硬件资源、量化、上下文长度、并发、流式输出、健康检查、日志监控、限流降级和版本回滚。 | 本地模型部署 |
| 本地部署和云模型 API 怎么选 | 云模型 API 上手快、能力强、弹性好,但数据会出内网且按 token 计费。本地部署数据可控,适合隐私和内网场景,但要自己承担硬件、运维、并发、监控和升级。实际项目常用混合架构:简单低风险走本地,复杂推理走强模型,敏感资料结合本地 RAG。 | 本地模型部署:本地部署和云模型 API 对比 |
| 本地模型为什么不能让前端直接调用 | 因为业务后端负责鉴权、限流、参数校验、Prompt 编排、RAG 权限过滤、日志审计和安全控制。前端直接调用模型服务会绕过权限和审计,也容易暴露内部地址、系统提示词和模型接口。 | 本地模型部署:后端适配层 Demo、AI应用架构 |
| 本地模型显存不足怎么办 | 可以换更小模型、使用量化模型、降低上下文长度、减少并发、减少 RAG 片段、关闭不必要服务,或者升级 GPU 和拆分部署。排查时要区分模型权重、KV Cache、并发请求和运行时开销。 | 本地模型部署:显存不足或 OOM、推理优化 |
| 模型制品从下载到接流量经历什么 | 从批准制品库下载到临时目录,校验文件清单、大小、Hash/签名、config、Tokenizer和全部权重分片,再原子发布不可变Revision;运行时加载权重、初始化GPU/通信组和KV池,执行预热与已知输出校验,Readiness通过后才能接生产流量。 | 模型制品加载全过程 |
| 为什么容器里有CUDA仍可能用不了GPU | GPU软件栈包含宿主机驱动、容器GPU Runtime、容器CUDA用户态库、框架/推理引擎、Kernel和通信库。容器不能替代宿主机驱动,镜像在另一GPU代际或驱动上也未必兼容;发布要记录并验证整个版本矩阵。 | GPU软件栈 |
| Startup、Liveness和Readiness有什么区别 | Startup允许长时间加载,避免Liveness过早重启;Liveness判断进程是否陷入不可恢复状态;Readiness判断是否应接新流量,要验证模型Revision、Worker、通信组、预热和过载状态。实例可以live但因加载、排空而not ready。 | 探针与预热 |
| 本地模型为什么需要预热 | 首请求可能触发文件页读入、GPU Context、显存池、Kernel/JIT、图捕获和通信组初始化,若直接接流量用户会承担冷启动。预热应覆盖典型Shape、流式和结构化路径,但它只证明基本链路,不替代容量压测。 | 预热原理 |
| 模型服务怎样优雅终止 | 先将Readiness设为false停止新流量,再等待在途Prefill、Decode和SSE到排空Deadline;超时则向Worker传播取消,标记部分响应,写Tool按幂等键确认结果,最后保存审计并释放KV和通信资源。 | 优雅终止和排空 |
| GPU模型为什么滚动发布容易失败 | 普通Rolling先起新Pod再停旧Pod,但旧模型占着显存时新模型可能无法加载。可根据冗余容量选择Rolling、Recreate、Blue/Green GPU池或独立Canary;新Revision加载、预热和评测后切路由,旧版本保留到排空和观察期结束。 | GPU滚动升级 |
| AI推理优化怎么做 | 先把Queue、RAG、Prefill、Decode、Tool和网络耗时拆开,分别看TTFT、TPOT、P95/P99、Token吞吐、KV占用和错误率。再针对瓶颈做Prompt裁剪、连续批处理、Paged Attention、量化、投机解码、并行/副本、缓存、限流和模型路由;所有方案在目标硬件并发压测并用评估集验证质量。 | 推理优化完整原理 |
| Prefill和Decode有什么区别 | Prefill并行处理全部输入并建立每层KV,输入越长TTFT通常越高;Decode每轮生成一个Token并反复读取权重和历史KV,更受内存带宽、Batch和调度影响。TTFT高查排队、RAG和Prefill,TPOT高查Decode批处理、并发和显存带宽。 | Prefill与Decode |
| KV Cache显存怎样估算 | 每Token KV字节约为layers×2×kvHeads×headDim×元素字节数,一个请求再乘输入加输出Token。使用kvHeads而非Query Heads,GQA/MQA可减少KV。总显存还包括权重、激活、工作区、Context和碎片,所以公式是容量上界,最终必须压测。 | KV容量计算 |
| Continuous Batching为什么提高吞吐 | 静态Batch等待整批且被最长请求和Padding拖累;连续批处理在Token迭代边界移除完成请求、补入新请求,提高槽位和GPU利用率。但长Prefill会干扰Decode,因此还需最大Batched Token、Chunked Prefill、优先级、公平和Deadline。 | 连续批处理 |
| Paged Attention解决什么问题 | 它把逻辑KV序列映射到固定大小、非连续的物理Block,按需分配并在请求结束后回收,减少按最大上下文连续预留造成的浪费和碎片。它提高显存利用率,但不减少每个有效KV元素的理论容量。 | Paged Attention |
| 量化为什么可能省显存却不一定更快 | INT8/INT4减少权重存储和带宽,但质量取决于权重、激活、KV的量化方式和校准;硬件或Kernel不支持时反量化开销会抵消收益。必须在目标硬件比较TTFT、TPOT、吞吐、显存和分场景质量。 | 量化原理 |
| Speculative Decoding为什么能加速 | Draft模型一次提议多个Token,Target模型并行验证并接受连续匹配部分,从而减少昂贵Target串行步数。收益取决于接受率、Draft成本和验证批大小;高温或复杂任务接受率低时可能无收益。 | 投机解码 |
| 流式输出能不能让模型变快 | 流式输出主要降低用户感知等待,让用户更快看到首 token,不一定减少总生成时间。它适合聊天和长文本生成,但如果输出必须完整校验 JSON 或经过高风险审核,就不一定适合直接流式返回。 | 推理优化:流式输出 |
| AI 缓存为什么要带权限和版本 | 因为同一个问题在不同租户、权限、知识库版本、Prompt 版本和模型版本下答案可能不同。如果缓存 Key 只有问题文本,可能把 A 用户有权限看到的答案返回给 B 用户,也可能把旧知识库答案返回给新版本用户。 | 推理优化:缓存设计、AI数据安全 |
| AI 请求慢怎么排查 | 先区分首 token 慢、总耗时慢还是排队慢,再拆入口、RAG、Rerank、工具、Prompt 和模型耗时。如果 RAG 慢看向量库、TopK、Rerank;Prompt 长看历史和 Chunk;模型慢看 TTFT、TPOT、并发和显存;成本高看 token、模型路由和缓存命中率。 | 推理优化:生产排查流程、AI应用架构 |
| LLMOps是什么 | LLMOps把代码、Prompt、模型、RAG索引、Embedding、Tool Schema、策略和评测报告组装成不可变Release Bundle,通过兼容校验、离线评测、审批、Shadow、Canary和Stable状态机发布;运行时记录实际Bundle、质量、延迟、成本和安全证据,并负责完整回滚和恢复。 | LLMOps完整原理 |
| LLMOps和DevOps有什么区别 | DevOps仍负责代码、镜像、基础设施和稳定性;LLMOps额外治理多资产共同决定的非确定性质量,包括Prompt、模型、知识索引、Judge、引用、拒答、Tool权限和Token成本。两者是叠加关系,LLMOps不能替代普通测试、事务和灾备。 | 三类工程体系 |
| Source、Revision、Bundle和Deployment有什么区别 | Source是可编辑源文件;Revision是构建后的不可变单资产;Bundle绑定一组兼容Revision和评测证据;Deployment控制Bundle在哪个环境、接多少流量。线上请求必须记录最终Bundle,不能只记随后会变化的stable别名。 | 五种对象 |
| Release Bundle为什么必须不可变 | 若同一Bundle ID内部资产可替换,评测报告、节点缓存、回滚和审计都失效。内容变化必须生成新Revision和Bundle,stable/canary只作为可变路由别名;Bundle用规范序列化和Hash验证,受控CI身份、签名与审批保证发布者可信。 | Release Bundle |
| Prompt为什么要版本管理 | Prompt会改变业务行为并与变量Schema、模型能力、RAG和Tool耦合。修改后生成不可变Revision,组装候选Bundle,执行配对评测和硬门禁,再Shadow/Canary;异常时切回验证过的整个Bundle,而不是只复制一段旧文本。 | Prompt发布流程 |
| RAG知识库为什么要发布和回滚 | 文档、切分、Embedding、ACL和Reranker都会改变召回。应从冻结快照构建独立候选索引,校验数量、维度和权限,运行评测后原子切换Alias;旧索引在观察期保留,异常时切回。新Embedding通常不能直接查询旧向量空间。 | 知识库发布和回滚 |
| LLMOps发布为什么需要状态机和乐观锁 | Built、Evaluated、Approved、Shadow、Canary、Stable等状态各有证据要求;状态迁移使用旧状态和version作为更新条件,受影响行为0就重新读取,防止两个发布器用过期快照覆盖彼此或同时产生两个Stable版本。 | 发布状态机 |
| 环境晋级为什么要Promote同一个Bundle | 若开发、测试、预发、生产各自从main重新构建,测试通过的内容可能不是生产内容。应一次构建不可变Bundle,在环境间晋级;数据库地址、凭据等环境差异通过受控引用注入,不能修改Bundle中的逻辑资产。 | 同包晋级 |
| AI回滚为什么不只是切回流量 | 路由切回只影响新请求,在途流、长会话、缓存和异步任务仍可能使用候选,已创建的工单和消息也不会自动撤销。回滚要处理取消、会话失效或迁移、版本化缓存、任务扫描、结果UNKNOWN确认和业务补偿。 | 完整回滚 |
| Provider模型漂移怎么发现 | 保存响应模型版本、Request ID和Usage,持续运行控制集,并按Bundle监控格式、拒答、Tool、输出长度、TTFT和TPOT分布。发现无代码发布但行为变化时,对比Provider、索引Alias和策略Revision,冻结晋级并切到最近验证路由。 | Provider漂移、生产Runbook |
| Spring AI 是什么 | Spring AI 是 Spring 生态里的 AI 应用工程化框架,用 Spring Bean、自动配置、ChatClient、Prompt、Advisor、VectorStore 和 Tool Calling 把模型调用、RAG、工具调用、观测治理接入 Java 后端系统。它不是训练模型的框架,而是把大模型能力稳定接入业务系统的框架。 | Spring AI 从零到生产级掌握、Spring AI 学习总览 |
| 怎么判断 Spring AI 是否真正学懂 | 不能只会写 ChatClient.prompt().user().call()。真正学懂要能讲清 ChatClient、ChatModel、Prompt、Advisor、EmbeddingModel、VectorStore、RAG、Tool Calling、结构化输出、权限过滤、评估、成本和排查的完整链路,并能说明每个环节为什么存在、不这样会出什么生产问题。 | Spring AI从零到精通验收清单 |
| Spring AI自动配置原理是什么 | Provider Starter把自动配置和实现放进Classpath,Spring Boot绑定spring.ai配置并通过Conditional检查类、属性和缺失Bean条件,创建Provider Client、ChatModel/EmbeddingModel及ChatClient.Builder。注入失败先查BOM、依赖树和Condition Report。 | Spring AI自动配置原理 |
| 为什么Spring AI版本不能混用 | 不同版本线的Starter名称、包、配置和API可能变化,例如旧1.x和新2.x风格Artifact不同。要选择与JDK/Spring Boot兼容的BOM统一模块版本,并用dependency tree确认只有一套依赖。 | BOM和版本边界 |
| Spring AI 的 ChatClient 一次调用怎么走 | Controller 接收请求后先做鉴权、限流和参数校验,再由 ChatClient 构造 Prompt,经过 Advisor 链补充记忆、RAG 上下文或安全规则,最后调用底层 ChatModel,拿到 ChatResponse 后做结构化解析、日志审计、Token 统计和异常兜底。 | Spring AI 商业生产场景、Spring AI 从零到生产级掌握、ChatClient |
| ChatClient和ChatModel有什么区别 | ChatModel是接受Prompt、返回ChatResponse的底层模型抽象;ChatClient是在其上组合默认/请求级Message、Template、Options、Advisor、Tool和输出转换的应用门面。统一接口减少协议耦合,但Provider能力差异仍需评估。 | ChatClient对象与调用原理 |
| call和stream有什么区别 | call等待完整响应,适合短任务和结构化输出;stream返回响应式流,主要降低TTFT,适合聊天长文本,但总计算时间不一定降低,还要处理取消、背压、SSE代理、中途错误和最终Usage缺失。 | 同步与流式 |
| Advisor顺序为什么重要 | Advisor会加入权限、Memory、RAG、安全和观测。权限必须在检索前生效,Memory裁剪影响问题改写,RAG加入后影响Token预算;顺序错误可能越权、重复上下文或让stream绕过安全。 | Advisor调用链 |
| Spring AI结构化输出怎样做 | 可以用Prompt格式说明、BeanOutputConverter、ChatClient entity或Provider原生JSON/JSON Schema映射Java对象。生产还要做Bean Validation、领域规则、权限和敏感校验,失败按语法、Schema、业务分类。 | Prompt与结构化输出原理 |
| 为什么结构化输出仍然会失败 | 模型可能返回Markdown、额外解释、截断JSON、缺字段、错误枚举或合法但业务错误的数据,不同Provider的Schema支持也不同。需要finish reason、三层校验、有限修复、评估和人工兜底。 | 结构化输出故障与校验 |
| Spring AI 怎么做 RAG | 离线解析、清洗、脱敏和语义切分文档,保存稳定ID、来源、版本、租户和ACL,用EmbeddingModel批量向量化后写VectorStore;在线从认证上下文构造权限Filter,召回、去重、Rerank并按Token预算组装上下文,再由ChatClient生成并校验引用和拒答。 | Spring AI RAG完整原理 |
| 为什么RAG权限必须在检索前生效 | 如果先全库召回再让模型过滤,越权Chunk已经进入应用内存、Prompt、日志或第三方模型,泄露已经发生。tenant、role和department必须来自服务端认证上下文,用metadata Filter在VectorStore召回阶段下推,缓存和Rerank也保持相同ACL。 | RAG权限过滤 |
| Spring AI生产接口怎样设计超时和重试 | 先设置请求总Deadline,再为检索、Rerank、模型和Tool分子预算。只对白名单瞬时错误有限重试;429尊重Retry-After并指数退避加抖动;401、参数错误不重试;读取超时和写Tool结果可能未知,要先按幂等键确认。 | 生产超时与重试 |
| 为什么AI限流还要看Token和并发 | AI请求耗时长且上下文差异巨大,只限QPS时少量超长请求仍能占满并发和预算。生产要同时限制请求速率、在途并发、Token和金额,先预留再按实际Usage结算,并处理崩溃未结算额度。 | 四类配额 |
| 模型降级为什么不能随便切小模型 | 备用模型必须满足场景能力和质量门槛,例如Tool Schema、结构化输出、多模态和安全策略。高风险医疗或支付场景更适合拒答/人工,而不是降到未验证模型。 | 模型路由与降级 |
| Spring AI Tool Calling 一次链路怎么走 | 后端把 @Tool 标注的工具方法、名称、描述和参数转换成模型可理解的工具定义;ChatClient 把用户问题和工具定义发给模型;模型返回工具名和结构化参数;Spring AI 映射到对应 Java 方法;工具方法在执行前做参数、登录、租户、数据权限和风险校验;执行后把最小必要结果返回给模型总结,并记录审计日志。模型只生成调用意图,不直接执行 Java 方法。 | Spring AI Tool Calling、工具调用 |
| Spring AI 工具方法为什么必须做后端鉴权 | 因为模型不是权限系统,用户可以通过自然语言或 Prompt 注入诱导模型传入越权参数,例如声称自己是管理员、要求查询其他租户数据。当前用户、角色、租户和数据范围必须来自 Spring Security 或后端权限系统,不能相信模型生成的 userId、tenantId。 | Spring AI Tool Calling:权限设计、AI安全 |
| Spring AI Tool Calling 写操作怎么保证安全 | 写操作要按高风险工具处理。模型先生成操作计划,后端校验参数、权限和风险,展示给用户二次确认;确认后携带幂等号执行,避免超时重试或 Agent 重复调用造成重复创建;最后记录操作者、工具名、参数摘要、业务单号和执行结果。删除、退款、改权限等极高风险操作通常不直接开放给模型。 | Spring AI Tool Calling:写操作工具、工具调用 |
| Spring AI 工具调用失败怎么处理 | 参数错误可以提示用户补充或让模型修正;权限不足必须拒绝并审计;业务不存在要返回可理解错误;下游超时要结合重试、降级或异步任务;写操作失败必须根据幂等号确认是否已经执行成功,不能简单重复执行。异常堆栈和敏感信息不能原样交给模型。 | Spring AI Tool Calling:生产排查、推理优化 |
| Spring AI Tool Calling 有什么风险 | 风险点不在“模型会不会调用工具”,而在模型可能传错参数、越权调用、重复调用或触发高风险操作。生产系统必须由后端定义工具 schema、校验用户权限和参数、限制工具范围、记录审计日志,并对写操作做二次确认或幂等控制。 | Spring AI 从零到生产级掌握、Tool Calling |
项目话术
text
在医疗数据采集与资产平台里,AI 更适合作为辅助能力,而不是替代核心业务规则。比如可以用 RAG 做数据标准、字段口径、接口文档问答;用模型辅助生成字段解释、资产摘要和采集异常排查建议。实现上要先做文档切片、Embedding、向量检索、权限过滤,再把召回资料交给模型回答,并通过评估、日志、限流和人工兜底保证稳定性。常见追问
| 追问 | 回答方向 | 跳转 |
|---|---|---|
| RAG 为什么仍然会答错 | 可能是切片差、召回错、排序差、上下文太长、资料冲突或模型没按资料回答。 | RAG流程、RAG数据治理 |
| 如何评估 AI 效果 | 建评估集,看准确率、召回率、引用命中、格式正确率、幻觉率、延迟和人工满意度。 | AI评估、Prompt评测 |
| 为什么不能把敏感数据直接发给模型 | 涉及隐私、合规和数据泄露风险,要做脱敏、权限控制、审计和模型调用边界管理。 | AI数据安全、AI安全 |
| 成本怎么控制 | 控制上下文长度、缓存相似问题、选择合适模型、流式响应、批量向量化、监控 Token 和失败重试。 | 推理优化、LLMOps |
面试回答模板
text
AI 应用我会按“模型能力如何变成业务能力”回答。大模型负责理解和生成,Prompt 约束任务和输出格式,Embedding 与向量库负责语义检索,RAG 把企业知识补充给模型,Tool Calling 让模型调用业务能力。生产落地时不能只看能不能回答,还要看效果评估、权限、安全、成本、延迟、日志审计和失败兜底。Spring AI 深度验收跳转
如果面试官追问 Java 后端如何把 AI 真正落地,不要停留在“我用 Spring AI 调过模型”。按 Spring AI 从零到精通验收清单 回到知识点页,把 ChatClient 调用链、Advisor、RAG 入库和问答、Tool Calling 安全、结构化输出、生产观测和排查讲完整。
AI 全链路深度验收跳转
如果面试官追问“你是不是真的懂 AI 应用原理”,不要只背 RAG、Prompt、Agent 的名词。按 AI 从零到精通验收清单 回到知识点页,把 Token、Transformer、Embedding、RAG 离线建库、在线问答、Tool Calling、Agent、评估、安全、推理优化和 LLMOps 的全过程讲完整。
本章小结
AI 面试页负责让你能讲清概念和项目落地。真正要深入理解为什么 RAG 能减少幻觉、为什么向量检索会召回错、为什么 Agent 有权限风险、为什么评估必不可少,要进入知识点页学习。
