大模型应用岗高频问答¶

导读：本文面向大模型应用算法、Agent（智能体）工程、RAG（检索增强生成）与 AI 产品技术岗位，强调方案设计与工程落地。题目按“RAG、Agent、Prompt 与评估、工程与部署、产品与方案”五组编排，共 65 题。每题给出考察点和 3 至 5 条回答要点，重点不是背定义，而是说明为什么这样选、怎么评测、出问题如何兜底。

核心要点

应用岗的核心能力是把模型能力拆成可观测的链路：检索、生成、工具、评估和兜底。
任何方案都要同时回答质量、延迟、成本、权限与合规五个约束。
面试中先澄清业务目标和数据边界，再谈模型与框架，避免直接堆技术名词。

一、RAG（20 题）¶

1. RAG 是什么，什么场景适合用 RAG？¶

考察点：基本链路、适用边界

RAG（Retrieval-Augmented Generation，检索增强生成）先从知识库检索相关片段，再把片段放入上下文让模型生成答案。
适合知识频繁更新、需要引用来源、企业私有数据和答案可追溯到文档的场景。
不适合纯创作、强推理但无外部知识、极低延迟或检索质量无法保证的场景。
基本链路包括文档解析、切分、向量化、索引、查询改写、召回、重排、生成和引用校验。

追问：RAG 能解决模型幻觉吗？只能降低“无依据回答”，检索错误、片段冲突和模型误读仍会导致幻觉，需要引用和拒答机制。

2. 文档解析和切分为什么决定 RAG 上限？¶

考察点：数据质量、结构保持

解析要保留标题、段落、表格、列表、页码和链接等结构，版式复杂的 PDF 常需要 OCR（光学字符识别）和版面分析。
切分应尽量以语义单元为边界，避免把一句话、一个表格或一组条件拆开。
低质解析会产生断句、乱码和错序，后续 embedding 和 rerank 再强也难以补救。
应建立解析质量抽检和失败样本回流机制，而不是只调生成模型。

追问：表格和图片怎么处理？优先结构化抽取为文本/键值对，保留原始页码；必要时用多模态模型生成表格摘要并附原图引用。

3. Chunk size 和 overlap 如何选择？¶

考察点：召回粒度、上下文完整性

chunk 太小召回精准但上下文不完整，太大则噪声多、embedding 语义被稀释、成本和延迟上升。
常见起点是 300 至 800 token，overlap（重叠）10% 至 20%，再按文档类型和问题类型调优。
法律、合同等需要完整条款的场景适合较大 chunk 或父子块；FAQ、API 文档适合较小块。
最终要用检索命中率、答案正确率和人工抽检决定，不能只凭感觉设一个固定值。

追问：父子块（parent-child chunk）有什么好处？用小块做检索提高命中，再把对应大块或整节送给模型，兼顾精度与上下文。

4. Embedding 模型如何选型？¶

考察点：语义表示、语言/领域、成本

先看语言覆盖、最大输入长度、维度、检索 benchmark 和部署方式，再看是否支持中文、代码或多语言。
通用模型未必适合医疗、法律、金融等术语密集领域，需要用业务数据做召回评估。
维度越高不一定越好，高维增加存储和计算；可评估 Matryoshka 截断或蒸馏版本。
还要考虑 API 稳定性、数据合规、批量吞吐和是否允许本地部署。

追问：如何快速比较两个 embedding 模型？固定语料和查询集，比较 Recall@k、MRR、nDCG 以及端到端答案正确率，而不是只看模型榜单。

5. Embedding 模型要不要微调，怎么做？¶

考察点：领域适配、对比学习

当通用模型对领域同义词、缩写、产品名或查询-文档不对称不敏感时，微调通常有价值。
常用对比学习：正样本来自真实问答对、点击日志或人工标注，负样本用 batch 内负例和难负例。
要防止训练集和评测集泄漏，保留领域外测试，监控过拟合和灾难性遗忘。
微调后必须重建索引，并同时评估召回和端到端生成，不能只看向量相似度。

追问：没有标注数据怎么办？可用弱监督构造查询-段落对、LLM 生成问题、点击日志挖掘，再做人工抽检和难负例挖掘。

6. 向量数据库和 ANN 索引如何选？¶

考察点：HNSW、IVF、过滤、运维

向量库负责存储 embedding 并做近似最近邻（ANN，Approximate Nearest Neighbor）检索，常见索引有 HNSW、IVF、PQ。
HNSW 召回高、延迟低但内存占用大；IVF/PQ 更省内存但需要训练和调参，召回可能下降。
选型要看数据规模、维度、更新频率、元数据过滤、多租户隔离、持久化和运维成本。
小规模场景用 pgvector 或本地索引即可，不必一开始就上专用分布式向量库。

追问：元数据过滤为什么会影响 ANN 效果？先过滤再检索可能缩小候选集，先检索再过滤可能召回不足，需支持过滤感知的索引策略。

7. 混合检索（Hybrid Retrieval）为什么有效？¶

考察点：稀疏+稠密、融合

稠密检索擅长语义相似，稀疏检索（如 BM25）擅长关键词、编号、专有名词和精确匹配。
混合检索并行召回两路结果，再用 RRF（Reciprocal Rank Fusion，倒数排名融合）或加权分数融合。
它能覆盖“意思相近但词不同”和“必须命中某个术语”两类需求，通常比单路更稳。
需要分别调 top-k、权重和归一化，避免某一路噪声淹没另一路。

追问：两路分数可以直接相加吗？通常不行，BM25 和余弦相似度量纲不同，需归一化、排名融合或学习融合权重。

8. BM25 和稠密检索各自适合什么？¶

考察点：稀疏检索、语义检索

BM25 基于词频和逆文档频率，可解释、无需训练、对精确术语和稀有词敏感，但不懂同义改写。
稠密检索用 embedding 表示语义，能处理改写和多语言，但可能忽略数字、代码标识和罕见实体。
查询含产品编号、法条号、错误码时优先稀疏；口语化、跨语言、概念性问题更适合稠密。
生产上常组合使用，并按 query 类型路由或动态调权重。

追问：中文 BM25 需要分词吗？需要，分词质量直接影响召回；也可用字符级 n-gram 缓解分词错误。

9. Query 改写有哪些方法，什么时候用？¶

考察点：查询理解、召回提升

常见方法包括指代消解、口语转书面语、补全省略、同义词扩展、拆分子问题和生成多个查询。
多轮对话中必须结合历史把“它”“这个”补全，否则检索会完全跑偏。
改写会引入语义漂移，需保留原始 query 并做并行召回或回退。
用检索指标和端到端正确率评估，避免改写模型“自作聪明”。

追问：改写和 HyDE 有什么区别？改写仍以原查询为中心做澄清/扩展，HyDE 则生成假设答案，用答案的语义去检索。

10. HyDE 的原理和风险是什么？¶

考察点：假设文档嵌入

HyDE（Hypothetical Document Embeddings，假设文档嵌入）先让模型生成一个假设答案，再对假设答案做 embedding 检索。
它把短查询扩展成更接近文档分布的文本，适合问题短、文档长、语义鸿沟大的场景。
风险是假设答案可能包含错误事实，导致检索被错误方向带偏；也可能增加延迟和成本。
常与原始 query 并行召回，并用 rerank 或投票融合，避免单一路径失效。

追问：HyDE 适合事实型问答吗？可以用，但必须保留原查询召回并校验引用，否则模型先验可能压过知识库事实。

11. Multi-Query 和查询分解如何提升召回？¶

考察点：多路召回、复杂问题

Multi-Query 对同一问题生成多个改写版本，分别检索后合并去重，提高覆盖率和鲁棒性。
查询分解把复杂问题拆成多个子问题，分别检索再综合，适合比较、多跳和条件组合问题。
需要控制查询数量，避免延迟和噪声线性增长；合并时可用 RRF、投票或 rerank。
子问题之间可能有依赖，第二跳查询要基于第一跳结果动态生成。

追问：多路召回结果如何去重？可用文档 ID、段落哈希、相似度聚类或最大边际相关（MMR）去冗余。

12. Rerank（重排）为什么重要，怎么选模型？¶

考察点：交叉编码器、精度/延迟

召回阶段追求高覆盖，常返回几十到几百条；rerank 用更精细的模型对 query-段落相关性重新打分。
Cross-encoder（交叉编码器）同时看 query 和文档，精度高但无法提前建索引，延迟随候选数增长。
常见做法是召回 top-50 至 top-200，再 rerank 到 top-5 至 top-10 送入生成。
选型看语言、领域、最大长度、吞吐和部署成本，并用 nDCG、MRR 和端到端答案评估。

追问：rerank 一定提升效果吗？不一定，若召回集没有正确文档，rerank 无能为力；候选太多也会增加延迟并引入难负例干扰。

13. 多跳问答（Multi-hop QA）如何设计？¶

考察点：迭代检索、推理链

多跳问题需要先找实体 A，再根据 A 找 B，单次检索往往缺少中间桥接信息。
可用迭代式 RAG：生成子查询、检索、抽取中间答案，再生成下一跳查询。
也可构建知识图谱或实体链接，把关系型知识显式建模，减少纯文本检索的断链。
评估要分别看每一跳的召回、最终答案和引用链，定位是检索错还是推理错。

追问：如何防止迭代检索越走越偏？设置最大跳数、置信度阈值和回退策略，并保留每跳证据供人工检查。

14. RAG 中如何做权限过滤和多租户隔离？¶

考察点：元数据、访问控制、安全

文档入库时写入 tenant_id、部门、密级、用户组等元数据，检索时在向量库层做强制过滤。
权限判断应在服务端完成，不能只依赖 prompt 让模型“不要泄露”；模型上下文里不应出现无权内容。
多租户可用独立 collection、命名空间或行级权限，按隔离强度和成本选择。
日志、缓存和引用链接也要做权限校验，防止通过缓存或 URL 旁路泄露。

追问：先检索再过滤有什么风险？无权文档可能占用候选名额，甚至被模型看到；应在召回阶段就做过滤感知的检索。

15. 如何评估 RAG 的检索质量？¶

考察点：Recall@k、MRR、nDCG

构造带标注的 query-相关段落集，评估 Recall@k（前 k 条是否包含正确证据）、MRR（Mean Reciprocal Rank，平均倒数排名）和 nDCG（normalized Discounted Cumulative Gain，归一化折损累计增益）。
还要看不同 query 类型、长度、语言和难度的分层表现，避免平均值掩盖短板。
没有标注时可用 LLM 辅助判定、点击日志和人工抽检，但要校准偏差。
检索评估应与生成评估分开，先确认“找得到”，再确认“答得对”。

追问：Recall@k 很高但答案仍错，问题可能在哪？正确片段排名靠后、上下文被截断、rerank 错误、模型忽略证据或片段本身相互冲突。

16. 如何评估 RAG 生成的可信度？¶

考察点：faithfulness、引用、人工评测

忠实度（faithfulness）看答案是否被检索上下文支持，可用 NLI（自然语言推理）模型、LLM 裁判和人工核验。
答案相关性看是否真正回答问题；引用准确率看引用片段是否支持对应句子。
还应评估拒答率、冲突证据处理、时效性和敏感内容，不能只看流畅度。
线上可用用户反馈、引用点击、追问率和人工抽检形成闭环。

追问：LLM-as-judge 评 RAG 有什么风险？裁判可能偏好长答案、被引用文本误导，或与人类标准不一致，需要人工校准和对抗样本。

17. 长上下文模型会取代 RAG 吗？¶

考察点：成本、更新、权限、召回

长上下文适合一次阅读少量长文档、跨章节总结和需要全局推理的任务。
RAG 更适合大规模、频繁更新、需要权限隔离和精确引用的知识库，成本也更可控。
长上下文仍有“lost in the middle”、KV Cache 昂贵和超长输入延迟问题，不能保证均匀利用。
实际方案常是混合：先用检索缩小范围，再把相关长文或章节放入长上下文。

追问：100 万 token 上下文能否装下整个企业知识库？理论上可以，但成本、更新、权限和注意力有效性问题使其不适合作为唯一方案。

18. 上下文如何组装，如何缓解“Lost in the Middle”？¶

考察点：上下文工程、排序

把最相关、最关键的证据放在开头或结尾，弱相关内容放中间或直接删除，减少干扰。
控制总 token 预算，保留来源、标题、时间和页码等元数据，方便模型引用。
对冲突信息显式标注来源和时效，要求模型说明依据，而不是默默选一个。
可用分段摘要、证据卡片或结构化字段替代整段原文，降低噪声和成本。

追问：为什么中间位置容易被忽略？长序列注意力分布不均，训练数据中关键信息也常出现在首尾，模型对中间证据的利用率较低。

19. 如何让 RAG 答案带可靠引用？¶

考察点：归因、引用粒度、校验

要求模型在生成时绑定片段 ID，输出句子级或段落级引用，而不是只给文档标题。
引用要能定位到原文页码/段落，并在 UI 中可点击核验；无依据时允许拒答。
生成后做引用一致性检查：引用片段是否真的支持该句，是否存在张冠李戴。
对多来源冲突，展示不同来源和更新时间，让用户判断。

追问：引用存在就等于可信吗？不等于，模型可能引用无关片段或过度解读，需要语义支持校验和人工抽检。

20. RAG 常见的失败模式有哪些，如何迭代？¶

考察点：全链路排障

解析错误、切分断裂、embedding 不适配、召回不足、rerank 错误、上下文超长和生成忽略证据是常见问题。
建立分阶段日志：query、改写、召回列表、rerank 分数、最终上下文、答案和引用。
用失败样本分类，优先修高频且影响大的环节，避免盲目换更大模型。
迭代时固定评测集和基线，做单变量对比，防止“感觉变好了”。

追问：答案错误时如何快速定位是检索还是生成问题？把人工标注的正确片段直接放进上下文，若模型能答对，优先排查检索；否则排查生成或数据本身。

二、Agent（15 题）¶

21. ReAct 的核心思想是什么？¶

考察点：推理与行动交替

ReAct（Reasoning and Acting，推理与行动）让模型交替输出思考、行动和观察，再根据工具返回继续推理。
思考用于规划下一步，行动调用工具，观察是环境返回，循环直到给出最终答案。
它把外部信息引入推理过程，适合搜索、计算、数据库查询和多步任务。
工程上要限制最大步数、解析工具调用、处理异常，并防止模型编造观察结果。

追问：ReAct 的“思考”一定要暴露给用户吗？不一定，可内部执行并只展示必要过程，避免泄露提示词或产生误导。

22. Function Calling（函数调用）是如何工作的？¶

考察点：工具 schema、参数生成、执行

开发者用 JSON Schema 描述工具名称、用途、参数类型和必填项，模型输出结构化调用请求。
运行时解析调用、执行工具、把结果作为观察返回模型，模型再决定继续调用或回答。
关键在 schema 清晰、参数校验、错误可读和幂等设计，不能信任模型生成的参数。
还要处理并行调用、超时、权限和多轮上下文。

追问：模型调用错工具怎么办？在 schema 描述中加入正反例和边界，运行时做参数校验与权限检查，并让错误信息可被模型理解后重试。

23. 如何设计一个好的工具（Tool）？¶

考察点：接口设计、可观测性

工具职责单一、命名明确、描述写清适用和不适用场景，参数尽量少且类型严格。
返回结构化、简洁、可操作的结果，包含错误码和修复建议，避免把整页 HTML 塞回模型。
工具要幂等、可限流、可审计，危险操作需二次确认或人工审批。
提供沙箱/测试环境和调用示例，降低模型误用概率。

追问：工具越多越好吗？不是，工具过多会增加选择困难和上下文成本，应按任务域分组并按需暴露。

24. MCP（Model Context Protocol）解决什么问题？¶

考察点：工具/资源协议、集成

MCP（模型上下文协议）提供模型应用与外部工具、资源、提示模板之间的标准化连接方式。
它把“提供能力的一方”和“使用模型的一方”解耦，减少每个应用重复对接不同工具。
常见能力包括 resources（资源）、tools（工具）和 prompts（提示模板），通过客户端/服务器架构通信。
工程上仍要处理鉴权、权限、超时、审计和工具返回内容的安全过滤。

追问：MCP 和普通 function calling 有什么区别？function calling 是模型输出调用意图的机制，MCP 更偏向工具与上下文如何被发现、连接和复用的协议层。

25. Agent 的规划（Planning）怎么做？¶

考察点：任务分解、重规划

先把目标拆成子任务，明确依赖、输入输出和成功标准，再逐步执行。
可用 ReAct、计划-执行、树搜索或先验工作流；简单任务不必上复杂 planner。
执行中根据观察重规划，处理工具失败、信息缺失和目标变化。
计划要可检查、可中断，避免一次性生成很长的不可验证步骤。

追问：为什么很多 Agent 不需要显式 planner？固定业务流程用工作流更稳定、便宜、可测试，Agent 更适合开放和不确定路径。

26. Agent 的记忆（Memory）如何设计？¶

考察点：短期/长期记忆、检索

短期记忆保存当前对话和任务状态，通常放在上下文窗口；长期记忆存用户偏好、历史事实和成功经验。
长期记忆需要写入策略、去重、时效、检索和遗忘机制，不能把所有日志无脑向量化。
记忆要区分事实、偏好和推测，冲突时以最新确认信息为准，并允许用户查看/删除。
多租户场景必须做隔离和权限控制，避免记忆串用户。

追问：记忆越多越好吗？不是，噪声和过时信息会干扰决策，还会增加隐私风险和 token 成本。

27. 多智能体（Multi-Agent）适合什么场景？¶

考察点：角色分工、通信、成本

适合可自然分工的任务，如“研究员检索、程序员实现、审查员测试”，或需要多视角辩论/投票的场景。
每个 Agent 应有清晰职责、输入输出和终止条件，避免无序聊天和重复劳动。
通信成本随 Agent 数量增长，且错误会级联，通常先从单 Agent 加工具开始。
需要统一状态、共享记忆、冲突解决和全局预算控制。

追问：多 Agent 一定比单 Agent 强吗？不一定，分工带来的协调开销和错误传播常抵消收益，除非任务确实可并行或需独立审查。

28. Agent 编排（Orchestration）有哪些常见模式？¶

考察点：工作流、路由、状态机

常见模式有顺序链、路由/分类、并行扇出再汇总、反思循环和层级委派。
固定流程优先用状态机或 DAG（有向无环图），保证可预测、可测试和可恢复。
开放任务可用 supervisor（主管）动态选择子 Agent，但要限制层数和总步数。
编排层应负责状态、重试、超时、日志和人工介入，而不是把控制逻辑都交给 prompt。

追问：什么时候该从 Agent 退回工作流？当任务路径稳定、错误代价高或需要严格审计时，工作流通常更可靠。

29. Agent 陷入死循环或反复调用工具，如何解决？¶

考察点：循环检测、预算、重规划

设置最大步数、最大工具调用次数、总 token/时间预算，超限后强制总结或转人工。
检测重复动作：相同工具、相同参数、相同观察连续出现时，提示换策略或终止。
在 prompt 中要求先检查已有观察，避免重复查询；工具返回要包含明确的状态和下一步建议。
记录轨迹做离线分析，判断是工具错误、目标不清还是模型能力不足。

追问：只加最大步数够吗？不够，它只能止损；要定位循环原因，否则只是把失败推迟到第 N 步。

30. Agent 的工具调用失败如何恢复？¶

考察点：错误处理、重试、降级

区分可重试错误（超时、限流、临时网络）和不可重试错误（参数错误、权限拒绝、资源不存在）。
可重试错误用指数退避和抖动，限制次数；参数错误应让模型修正参数或向用户澄清。
工具返回结构化错误码和人类可读说明，Agent 据此选择换工具、换参数或降级回答。
关键操作要幂等，避免重试导致重复下单、重复扣款。

追问：工具超时后能否直接重试？先确认操作是否已执行，非幂等操作需查询状态后再决定，不能盲目重试。

31. Agent 的沙箱和安全边界怎么设计？¶

考察点：最小权限、隔离、审计

工具按最小权限授权，读、写、支付、删除等能力分级，危险操作要求二次确认。
代码执行使用隔离沙箱，限制网络、文件系统、CPU/内存和运行时间，防止逃逸和资源滥用。
所有工具调用记录审计日志，包括谁、何时、用什么参数、返回什么、是否被批准。
对 prompt injection（提示注入）做内容隔离，外部文档和网页内容不能直接获得高权限指令。

追问：沙箱能完全防住 Agent 风险吗？不能，业务逻辑漏洞、越权 API 和社交工程仍存在，需要权限系统与人工审批共同兜底。

32. Human-in-the-loop（人工介入）应该放在哪些节点？¶

考察点：风险分级、审批

高风险或不可逆操作，如付款、删除、发邮件、改生产配置，必须人工确认。
低置信度、工具连续失败、涉及敏感信息或合规判断时，转人工复核。
人工介入要展示证据、建议动作和影响范围，降低审核成本。
记录人工修改，形成反馈数据用于评测和模型改进。

追问：人工介入会不会拖慢效率？会，所以应按风险分级，而不是所有步骤都审批；目标是风险可控下的自动化率。

33. 如何评估一个 Agent？¶

考察点：任务成功率、轨迹、成本

端到端指标包括任务成功率、平均步数、工具调用正确率、人工接管率、延迟和单任务成本。
过程指标看规划是否合理、参数是否正确、错误恢复和是否越权，不能只看最终答案。
用可重置环境、固定初始状态和确定性验证器做离线评测，再逐步引入真实流量。
测试集要覆盖成功、失败、歧义、对抗和工具异常，报告置信区间。

追问：最终答案对但过程违规，算成功吗？不算，Agent 评估要同时看结果与约束，越权、泄露或不可审计都应判失败。

34. Agent 轨迹数据如何用于训练？¶

考察点：轨迹 SFT、过程标注、RL

收集完整轨迹：用户输入、模型思考/动作、工具调用、观察、最终结果和成功标记。
先做轨迹 SFT 冷启动，教模型格式、工具选择和常见恢复策略；再用 RL 优化任务成功率。
过程标注成本高，可用规则验证、结果回传和关键节点人工审核；注意去除失败轨迹中的错误示范。
训练数据要多样化环境，防止模型记住特定 API 或页面结构。

追问：只训练最终答案可以吗？可以学到部分策略，但缺少动作级监督，模型容易“答对但过程不可执行”，复杂任务需要轨迹级数据。

35. Agent 的成本和延迟如何控制？¶

考察点：模型路由、缓存、并行

按任务难度路由模型：简单分类/抽取用小模型，复杂规划才用大模型。
缓存工具结果、检索结果和常见子任务；并行执行无依赖的工具调用。
限制上下文和轨迹长度，压缩观察结果，避免把整页内容反复塞入 prompt。
设置预算和超时，失败快速降级；用批处理和异步任务处理非实时需求。

追问：为什么 Agent 成本常远超预估？多轮调用会重复携带历史和工具结果，token 呈累积增长，且有重试和失败重跑。

三、Prompt 与评估（12 题）¶

36. Chain-of-Thought（思维链）什么时候有效？¶

考察点：推理提示、成本、风险

CoT 让模型先写中间推理再给答案，对数学、逻辑、多步规划等任务通常有帮助。
对简单事实问答、抽取和分类，CoT 可能增加成本甚至引入错误，应做对比实验。
提示中可要求分解步骤、检查假设和验证答案，但不要强迫冗长。
生产环境可隐藏中间过程，只展示结论和必要依据，降低泄露和误导风险。

追问：CoT 的内容一定是模型真实推理吗？不一定，它是生成的文本，可能事后合理化；不能把展示的思维链当作可靠解释。

37. Few-shot（少样本）示例如何选？¶

考察点：示例选择、格式、偏差

示例要覆盖任务边界、输出格式和常见失败模式，数量通常 3 至 8 个即可。
优先选与当前 query 语义相似、难度匹配的示例，可动态检索示例（few-shot retrieval）。
示例顺序和标签分布会影响结果，要避免全部正例或固定顺序造成偏差。
示例会占用上下文并增加成本，能用清晰指令和结构化输出解决时不必堆示例。

追问：示例越多越准吗？不一定，过多示例会增加噪声、长度偏差和过拟合，且边际收益递减。

38. 如何保证模型输出结构化 JSON？¶

考察点：JSON Schema、约束解码、校验

用 JSON Schema 或 Pydantic 定义字段、类型、枚举和必填项，并在 prompt 中给出最小示例。
优先使用支持 structured output（结构化输出）或约束解码的接口，从解码层保证语法合法。
生成后仍要做 schema 校验、类型转换和业务校验，不能假设模型输出一定正确。
失败时让模型基于错误信息修复，限制重试次数，并提供默认/降级路径。

追问：JSON 语法正确就够了吗？不够，还要验证字段语义、枚举合法性、数值范围和跨字段一致性。

39. Prompt Injection（提示注入）如何防御？¶

考察点：指令层级、内容隔离、权限

把系统指令、用户输入和外部文档分层，明确外部内容只是数据，不得覆盖高优先级指令。
对网页、邮件、PDF 等不可信内容做清洗和隔离，不让其中的“忽略之前指令”进入高权限决策。
工具调用做权限校验和人工审批，模型不能仅凭文本获得超出用户的权限。
用对抗测试、输出过滤和最小权限降低风险，但不要宣称可以完全消除。

追问：为什么单靠 prompt 防御不够？注入是数据与指令边界问题，模型无法可靠区分恶意文本，必须在系统和权限层兜底。

40. LLM-as-judge 有哪些偏差，如何校准？¶

考察点：自动评估、偏好偏差

常见偏差包括位置偏差、长度偏好、风格偏好、自我偏好（偏爱同族模型）和提示敏感。
可用成对随机交换、统一评分 rubric、多裁判投票和参考答案来降低偏差。
用人工标注集校准裁判，计算与人类的一致性（如 Cohen's kappa），并分任务报告。
对高风险场景不要完全依赖自动裁判，保留人工抽检和线上反馈。

追问：裁判和人类一致性多高才算可用？没有统一阈值，通常 70% 至 85% 可作辅助信号，但高风险决策仍需人工确认。

41. 如何设计大模型 A/B 测试？¶

考察点：实验设计、指标、显著性

明确假设和主指标（如任务完成率、采纳率、留存），同时设护栏指标（延迟、成本、投诉、安全）。
随机分流到 A/B 组，保证用户、流量和时间分布可比，避免污染和串组。
预先估算样本量和实验周期，关注置信区间和 p 值，不要看到波动就下结论。
分析分层效果和长期影响，防止短期指标提升但用户信任下降。

追问：离线评测涨了但 A/B 不涨，可能为什么？评测分布与真实流量不一致、用户不采纳、延迟变差或新能力没有被触发。

42. 如何构建高质量的离线评测集？¶

考察点：覆盖度、标注、版本

从真实用户请求、失败案例、边界场景和对抗样本中采样，覆盖任务类型、难度、语言和长度。
标注要有一致性规范，至少双人复核关键样本，记录答案依据和可接受变体。
训练/开发/测试严格分离，测试集定期更新并做污染检查，避免过拟合。
评测集要版本化，指标按子集报告，保留失败样本用于回归。

追问：评测集越大越好吗？不是，覆盖度和标注质量更重要；小而精的分层评测集通常比低质大集更有指导价值。

43. 大模型幻觉（Hallucination）如何检测和缓解？¶

考察点：事实性、RAG、拒答

幻觉包括事实错误、无依据编造、引用错配和逻辑自洽但前提错误，需要分类型处理。
缓解手段包括 RAG、工具查询、要求引用、答案自检、置信度阈值和允许拒答。
检测可用知识库核验、NLI、多模型交叉验证和人工抽检；自动检测仍有漏判。
高风险场景应展示来源、限制模型自由发挥，并提供人工复核。

追问：让模型“不要幻觉”有用吗？作用有限，模型无法可靠知道自己的知识边界，必须靠外部证据、工具和产品流程约束。

44. 如何避免评测集污染和过拟合？¶

考察点：数据隔离、动态评测

训练数据与评测集做 n-gram、嵌入和题目模板级去重，禁止用测试题做 SFT 或 prompt 调优。
保留私有测试集和动态生成的评测集，定期更新，减少公开榜单的记忆效应。
报告多个 seed、置信区间和分布外结果，避免只挑最好的一次。
对 prompt 调优也要有留出集，否则只是在测试集上过拟合。

追问：公开 benchmark 还有意义吗？有，适合作粗筛和横向参考，但不能替代业务评测和私有测试。

45. Pass@k 是什么，如何正确使用？¶

考察点：代码评测、采样

pass@k 表示对同一问题采样 k 个答案，至少有一个通过测试的概率，常用于代码生成。
估计时通常采样 n 个（n≥k），用组合公式无偏估计，而不是简单看前 k 个。
pass@k 会随 k 增大而上升，比较时必须固定 k 和采样预算，不能拿 pass@100 对比 pass@1。
生产更关心 pass@1、单位成本通过率和延迟，pass@k 只反映潜在能力。

追问：pass@k 高但实际部署效果差，为什么？真实任务没有测试用例、采样成本高、用户只接受一次回答，且分布与 benchmark 不同。

46. 模型置信度和校准（Calibration）如何评估？¶

考察点：概率可靠性、拒答

校准衡量模型给出的概率是否与真实正确率匹配，常用 ECE（期望校准误差）和可靠性图。
大模型常过度自信，尤其在分布外和长尾问题上；softmax 概率不等于事实可靠性。
可用温度缩放、集成、采样一致性和外部验证器改善，但很难完全校准。
产品上可结合阈值、引用和人工复核，而不是直接展示模型自报的“置信度”。

追问：模型说“我有 90% 把握”可信吗？通常不可直接信，语言化置信度容易受提示影响，需用标注数据验证其与正确率的关系。

47. Prompt 如何版本管理和回归测试？¶

考察点：工程化、可复现

把 prompt 当作代码管理：版本号、变更记录、负责人、适用模型和参数一起保存。
建立固定回归集，每次改动跑质量、格式、延迟、安全和成本指标，比较基线。
对模型升级做影子测试和灰度，避免供应商静默更新导致行为漂移。
记录失败样本和回滚方案，prompt 变更应可审计、可复现。

追问：为什么同一个 prompt 换模型后效果会变？不同模型的指令遵循、分词、训练分布和默认风格不同，prompt 需要重新评测。

四、工程与部署（10 题）¶

48. 流式输出（Streaming）如何实现，难点是什么？¶

考察点：SSE、增量解析、体验

服务端通过 SSE（Server-Sent Events，服务器发送事件）或 WebSocket 持续推送 token，前端增量渲染。
需要处理分句、Markdown 未闭合、结构化 JSON 不完整和工具调用中途插入等情况。
流式降低首字等待，但不降低总生成时间；要设置超时、断线重连和取消机制。
对结构化输出可先缓冲到合法 JSON 再展示，或采用增量解析器。

追问：流式输出会不会影响计费和质量？按实际生成 token 计费，质量通常不变，但中途取消和重试会产生额外成本。

49. 超时、重试和幂等如何设计？¶

考察点：可靠性、分布式系统

按阶段设置超时：连接、首 token、总生成、工具调用；不要用一个超时覆盖所有阶段。
只对可重试错误重试，使用指数退避和抖动，限制次数并设置总预算。
写操作必须幂等，用请求 ID 去重；重试前确认上一次是否已生效。
超时后给用户可理解的降级结果，并记录 trace 便于排查。

追问：模型生成超时后重试，如何避免重复扣费或重复副作用？把生成与业务写操作分离，使用幂等键和状态查询。

50. 如何做限流和配额管理？¶

考察点：QPS、 token 配额、公平性

限流维度包括请求数、token 数、并发数和用户/租户配额，避免只按 QPS 限制被长 prompt 绕过。
常用令牌桶、漏桶、滑动窗口；分布式环境用 Redis 等共享计数。
区分优先级和租户等级，给交互式请求保留容量，批量任务排队。
超限返回明确错误和重试时间，避免客户端风暴；同时监控被限流比例。

追问：只按请求数限流有什么问题？一个超长 prompt 可能消耗大量算力，必须同时限制 token 和并发。

51. 如何估算和控制大模型调用成本？¶

考察点：token 计费、缓存、路由

成本约为输入 token 数乘输入单价加输出 token 数乘输出单价，再叠加工具、检索和重试费用。
优化手段包括缩短 prompt、压缩历史、结果缓存、前缀缓存、小模型路由和批量调用。
分别统计每类任务、租户和模型的单位成本，设置预算告警和上限。
不要只看单价，延迟、失败重试和人工审核也计入总拥有成本。

追问：输出 token 为什么通常比输入贵？生成是逐 token 串行且受显存带宽限制，GPU 利用率低于并行 prefill，定价也反映算力成本。

52. 大模型应用有哪些缓存层次？¶

考察点：精确缓存、语义缓存、前缀缓存

精确缓存按规范化后的请求哈希命中，简单可靠，适合 FAQ 和确定性任务。
语义缓存用 embedding 找相似问题，能提高命中但有一致性和误命中风险，需阈值和人工抽检。
前缀缓存复用相同 system prompt 或长文档的 KV，降低 TTFT 和 prefill 成本。
缓存要考虑权限、时效、版本和失效策略，敏感数据不能跨用户共享。

追问：语义缓存最大的风险是什么？把相似但条件不同的问题当成同一个，返回错误答案，尤其是包含数字、时间或权限约束时。

53. 大模型服务需要监控哪些指标？¶

考察点：可观测性、质量/成本/延迟

延迟看 TTFT、TPOT、端到端 p50/p95/p99；吞吐看 tokens/s、请求数和并发。
质量看成功率、拒答率、引用准确率、用户反馈和人工抽检；安全看违规和注入告警。
成本看每请求 token、缓存命中、重试率和单位任务成本；资源看 GPU 利用率、显存和队列长度。
建立 trace（调用链）把检索、模型、工具和数据库串起来，便于定位问题。

追问：为什么平均延迟正常但投诉很多？尾延迟、特定租户/长 prompt 或流式中断可能被平均值掩盖，必须看分位数和分层指标。

54. 灰度发布（Canary Release）怎么做？¶

考察点：流量切分、回滚、指标

先小流量（如 1% 至 5%）接入新模型或新 prompt，按用户/租户稳定分流，避免同一用户来回切换。
同时对比质量、延迟、成本、错误率和安全指标，设置自动回滚阈值。
用影子流量（shadow traffic）在不影响用户的情况下先观察输出差异。
灰度期间保留旧版本和快速回滚能力，逐步扩大流量。

追问：模型灰度与普通代码灰度有什么不同？输出是概率性的，难以用单元测试判断对错，需要质量评测和人工抽检配合。

55. 模型或工具失败时如何降级？¶

考察点：Fallback、用户体验

设计多级降级：重试、换小模型、走缓存、返回检索原文、转人工或明确告知暂时不可用。
降级要保证格式和语义一致，避免前端解析失败或给出错误承诺。
对高风险任务宁可拒答/转人工，也不要让模型编造。
记录降级原因和比例，定期分析是否触发器过敏感。

追问：降级到小模型一定更安全吗？不一定，小模型可能更容易幻觉或漏掉安全约束，需要针对降级路径单独评测。

56. 并发和排队如何影响用户体验？¶

考察点：队列、调度、SLA

并发超过容量时请求排队，TTFT 上升；长请求会占用 KV Cache 和 batch 名额，拖累短请求。
可用优先级队列、最大并发、请求分片、chunked prefill 和动态 batching 平衡吞吐与延迟。
对超时请求及时取消并释放资源，避免无效计算继续占用 GPU。
按业务 SLA 设计容量，预留峰值和安全余量。

追问：为什么增加并发有时反而降低总吞吐？KV Cache 和显存压力增大、batch 过大导致调度和访存效率下降，甚至触发换页。

57. 如何做容量规划？¶

考察点：QPS、token、GPU 估算

估算峰值 QPS、平均输入/输出 token、并发会话数和延迟目标，换算成所需 tokens/s 和 KV 显存。
用压测得到单卡/单实例在目标 SLA 下的吞吐，再考虑冗余、故障切换和增长余量。
区分 prefill 与 decode 的资源需求，长 prompt 多时 prefill 压力更大。
定期复盘实际流量与预测偏差，保留弹性扩容方案。

追问：为什么按平均 QPS 扩容不够？峰值和长请求会造成排队，必须按分位数延迟和最坏情况做容量设计。

五、产品与方案（8 题）¶

58. 一个业务场景该不该用大模型，怎么判断？¶

考察点：场景选型、可行性

先判断任务是否能用规则/传统模型低成本解决，大模型是否真的带来语义理解或生成增益。
评估容错率、可解释性、数据可得性、延迟和单位成本；高风险场景需要更强人工兜底。
适合容错较高、文本非结构化、长尾多且难以穷举规则的任务。
先做小规模 POC（概念验证），用真实数据验证效果，再决定是否投入。

追问：什么场景不建议用大模型？答案必须百分百精确、极低延迟、强可解释或成本极敏感，且规则系统已足够好的场景。

59. 如何计算大模型应用的 ROI（投资回报率）？¶

考察点：成本、收益、TCO

成本包括模型调用、GPU、检索/存储、标注、人工审核、研发和运维，不能只算 token 单价。
收益包括人力节省、转化提升、响应提速、错误减少和新增收入，要量化到业务指标。
用单位任务成本、自动化率、人工接管率和回收周期评估，做保守/中性/乐观情景。
持续监控实际使用率和收益，避免“demo 很好但无人使用”。

追问：为什么很多大模型项目 ROI 算不过来？长尾请求需要人工兜底、评测和维护成本高，实际自动化率低于预期。

60. 大模型应用需要关注哪些合规问题？¶

考察点：隐私、版权、内容安全

收集和处理个人数据要有合法性基础、最小必要和明确告知，敏感信息做脱敏和访问控制。
训练/检索数据注意版权和许可，生成内容要避免侵权、诽谤和泄露商业秘密。
内容安全包括违法有害信息过滤、未成年人保护、深度伪造标识和行业监管要求。
建立数据保留、删除、审计和供应商数据使用条款审查机制，按地区法规调整。

追问：调用第三方 API 就合规了吗？不一定，数据可能出境、被用于训练或留存，需审查合同、区域部署和数据处理协议。

61. 什么时候必须转人工（Human Handoff）？¶

考察点：风险分级、体验

高风险决策（医疗、法律、金融交易）、低置信度、用户明确要求、连续失败和敏感投诉应转人工。
转人工要携带上下文、已尝试方案和证据，避免用户重复描述。
设计排队、超时和回呼机制，明确告知用户当前状态。
统计转人工率和原因，反推模型、知识库或流程改进。

追问：转人工率越低越好吗？不是，该转不转会损害信任和合规，关键是风险匹配下的合理分流。

62. 如何从 POC 走到生产？¶

考察点：工程化、评测、运营

POC 验证可行性和用户价值，生产要补齐数据 pipeline、权限、监控、评测、灰度和回滚。
定义清晰的验收指标和失败标准，先在受控用户群试点，再逐步放量。
建立 bad case 回流、prompt/模型版本管理和人工审核流程。
评估峰值容量、供应商依赖和灾难恢复，避免 demo 与生产脱节。

追问：POC 效果很好，上线后却很差，常见原因是什么？真实流量更脏、更长尾、对抗性更强，且延迟/成本约束改变了产品形态。

63. 自研模型、开源模型和调用 API 如何选择？¶

考察点：Build vs Buy、TCO

API 上线快、维护少，适合验证和通用能力；但数据出境、供应商锁定、价格和限流需评估。
开源自部署可控、可微调，适合数据敏感和定制需求，但要承担 GPU、推理优化和运维成本。
自研基座成本最高，只有在数据、算力和团队都具备时才合理，多数团队应做应用层或领域微调。
用总拥有成本、迭代速度、合规和差异化需求综合决策，可混合使用。

追问：什么时候值得微调开源模型？通用 prompt 无法解决、领域风格/格式要求高、数据充足且能持续维护时，才值得投入。

64. 如何设计大模型产品的交互体验？¶

考察点：预期管理、可纠正性

明确告知能力边界和不确定性，展示引用/依据，允许用户查看和纠正。
流式输出、停止生成、重新生成、编辑和反馈按钮能显著改善可控感。
对长任务展示进度和中间状态，失败时给出可执行的下一步。
不要让用户误以为模型全知全能；高风险建议要提示咨询专业人士。

追问：为什么“更像人”不一定是好体验？过度拟人可能让用户高估可靠性，在医疗、金融等场景造成误导。

65. 如何评估和选择模型供应商？¶

考察点：评测、SLA、锁定

用业务评测集比较质量、延迟、吞吐、上下文、结构化输出和多语言能力，而不是只看公开榜单。
审查 SLA、限流、价格、数据留存/训练条款、区域部署和故障历史。
评估 API 兼容性、迁移成本和多供应商切换能力，避免单点锁定。
上线前做压测和灰度，合同中明确服务可用性、数据保护和退出机制。

追问：只选榜单第一的模型有什么问题？榜单任务与业务分布不同，且价格、延迟、稳定性和合规可能不适合生产。

使用建议¶

应用岗回答要先讲业务约束和链路，再讲模型与框架；只报技术名词很容易被追问落地细节。
准备 2 至 3 个真实项目，按“问题、方案、指标、失败与改进”组织，能量化就量化。
RAG 重点练检索评估和权限，Agent 重点练工具设计、循环与安全，产品题重点练成本与合规。
遇到开放方案题，先澄清用户、数据、延迟、预算和风险，再给分阶段方案与验收指标。

本文档为面试复习资料，公式与数字建议结合原始论文复核。