大模型基础面试题总结

大模型面试的分水岭不在能否背出 Transformer 结构，而在能否把一次调用从 Token 化、采样生成到结构化返回的链路讲清，并解释幻觉、成本与稳定性背后的工程取舍。本篇按运行机制、采样解码、幻觉、选型、工具调用五条线整理高频题。

考察地图

Token 与上下文：Token 的计费逻辑、上下文窗口与 Lost in the Middle。考察成本与信息布置的基本功。
采样与解码：Temperature/Top-P/Top-K 的分工、温度归零后输出仍不一致的原因。考察对解码过程的理解深度。
幻觉治理：幻觉的根因与分层缓解。考察是否理解”概率续写”这一本质。
选型判断：长上下文 vs RAG、微调 vs 提示词。考察工程权衡能力而非名词解释。
工具调用与结构化：Function Calling 完整链路、JSON 输出的可靠性保障。考察生产落地经验。
建议自行查阅：SSE 流式协议细节、重试幂等与限流设计、输入输出 Token 计费公式、离线/线上评测体系——多为流程性工程题，沿调用链路自行梳理即可。

Token 与上下文

Token 是什么？为什么中文、英文、代码消耗的 Token 不一样？

结论：Token 是分词器切出的最小文本单元，也是计费与上下文占用的计量单位；各语言消耗不同，根源在分词器词表对不同语言的覆盖效率。

原理：主流模型用 BPE 类算法把高频片段整体收进词表。英文常见单词多能整块命中，1 个 Token 约合 0.75 个单词；中文常用字虽被收录，但标点与生僻字常触发字节级回退，整体接近”一字一 Token 多一点”；代码因符号与缩进密集，消耗通常高于等长自然语言。Token 数直接决定费用与窗口占用，估算成本必须用 tokenizer 实测，不能按字数折算。

延伸：同一段 Prompt 换一家模型，Token 数可能差出一成以上——词表是各家训练语料的产物。工程上用官方分词库（如 tiktoken）离线预估，上线后以响应里的 usage 字段为准做账单对账。

追问：如何低成本统计每次调用的 Token 消耗？提示：优先读 usage 字段，本地 tokenizer 只做预估兜底。

上下文窗口是什么？窗口越大效果一定越好吗？

结论：上下文窗口是单次调用可处理的 Token 上限，输入与输出共享；窗口变大只解决”放得下”，不保证”用得好”。

原理：注意力机制理论上允许模型关注窗口内任意位置，但实测呈 U 形利用曲线——开头与结尾的内容利用最充分，中段证据容易被忽略，即 Lost in the Middle 现象。同时成本与延迟随长度近似线性上涨，KV Cache 显存占用同步膨胀。因此长上下文场景仍需信息治理：关键证据放头尾、先检索过滤再塞入、控制历史轮次，而不是无脑灌满窗口。

延伸：预算是输入输出共享的——塞满输入时输出空间也被挤压。分配顺序建议：先保输出与格式约束，再保系统指令，剩余额度才轮到历史消息与检索证据。

追问：多轮客服对话持续变长，Token 预算怎么分配？提示：滑窗加关键业务状态的结构化摘要，别整段历史全带。

采样与解码

Temperature、Top-P、Top-K 分别控制什么？生产环境怎么设？

结论：三者都作用于解码采样：Temperature 调整概率分布的陡峭程度，Top-K 按候选数量截断，Top-P 按累计概率动态截断；生产上结构化任务压低温，创作任务适度调高。

原理：模型每步输出词表上的 logits，经 softmax 转为概率分布。Temperature<1 让分布变尖、高概率词更占优，趋近 0 时近似贪婪解码；>1 则拉平分布、增加多样性。Top-K 只保留概率最高的 K 个候选；Top-P（核采样）取累计概率达到 P 的最小集合，候选规模随分布形状自适应——尖锐时只剩一两个词，平坦时自动放宽。实践中常叠加使用：先靠温度整形，再用 Top-P 截尾。

延伸：经验法则是”先定温度，再微调 Top-P”，三个参数同时大改会让输出波动难以归因。抽取、分类、JSON 生成建议 temperature=0 或接近 0；文案创作可放到 0.7~1.0。

追问：Top-P 相比 Top-K 的优势是什么？提示：候选集随分布形状自适应，平坦分布下不会硬截断丢掉合理候选。

为什么 Temperature 设为 0，输出仍可能不完全一致？

结论：Temperature=0 仅表示每步取概率最大的词（贪婪解码），但”哪个词概率最大”在工程实现上存在数值抖动，跨调用无法保证逐位一致。

原理：根源有三。其一，浮点加法不满足结合律，GPU 并行归约顺序不固定，logits 可能差到小数点后几位，当 Top-2 候选概率接近时，这点抖动就足以翻转 argmax。其二，服务端为提吞吐做连续批处理，同一请求每次落入的批次组合不同，计算路径随之变化。其三，量化、推测解码等优化引入额外近似。长文本中任何一步分叉都会级联放大，最终输出明显不同。

延伸：部分厂商提供 seed 参数，能把随机性收敛到”同 seed 同输入大概率同输出”，但官方通常不承诺 100%。真正要求可复现时，应把确定性上移到工程层：结果落库、diff 回归、结构化校验，而不是指望模型恒定。

追问：业务要求”同一工单两次摘要完全一致”怎么实现？提示：首次结果缓存落库，重复请求直接返回，而非依赖模型复现。

幻觉

大模型为什么会产生幻觉？常见缓解手段有哪些？

结论：幻觉的根因是模型以”下一个 Token 概率最大化”为训练目标——它学到的是语言分布而非事实库，遇到知识盲区就用最像答案的模式补全。

原理：预训练语料对长尾知识覆盖稀疏，模型没见过的事实会按语义相似性”编一个合理的”；指令微调与 RLHF 让模型更愿意作答，副作用是不懂时也倾向硬答而非拒答。缓解分三层：输入侧用 RAG 注入权威证据并要求引用出处；生成侧降低温度、明确”不知道就拒答”、用结构化输出收窄自由度；输出侧用业务规则与工具核验兜底——金额查库、法条对源、引用可回溯。

延伸：评估时要区分内在幻觉（与给定证据冲突，可用 Faithfulness 指标量化）与外在幻觉（与客观事实冲突，需外部知识核验）。RAG 主要压制前者，后者要靠领域校验闭环。

追问：RAG 场景下模型仍无视检索结果自行发挥，怎么排查？提示：证据是否真进了上下文、位置是否被淹没、指令有无强制”仅依据证据作答”。

选型判断

长上下文窗口会取代 RAG 吗？

结论：不会。长上下文解决”一次看很多内容”，RAG 解决”从海量、动态、有权限边界的数据里精准取证”，二者是叠加而非互斥。

原理：对比四个维度。成本：全量灌入的 Token 费随调用量线性放大，RAG 只取 Top-K，成本可控；效果：Lost in the Middle 决定塞得越多未必越准，先过滤反而提高证据密度；时效：知识更新时 RAG 只改索引，长上下文每次都要重传；权限：企业数据的行级权限必须在召回前过滤，灌进上下文就失控了。长上下文真正适合的是小型、静态、全员可见的语料，例如一次性分析一份几百页的合同。

延伸：成熟架构是两者结合——RAG 负责取证，大窗口负责容纳更多候选片段与多轮历史；窗口越大，Top-K 可以设得越从容。

追问：百万级文档库纯用长上下文做问答，月度账单怎么粗估？提示：按”每次调用灌入量 × 调用次数 × 单价”，再对比 RAG 的 Top-K 成本。

微调和提示词工程怎么选？

结论：选型顺序是先提示词、再 RAG、最后微调——微调改变的是模型的行为风格与领域语感，不适合用来注入具体事实。

原理：提示词零成本、可天级迭代，适合表达任务格式与约束；RAG 解决知识时效与私有数据，知识变更只需更新索引；微调（SFT/LoRA）的价值在三类场景：输出风格与格式必须高度稳定、领域术语密集要求”内行化”表达、压缩超长系统提示以降时延降本。用微调注入事实既昂贵又不可靠：知识一变就得重训，还容易过拟合旧知识。口诀：教模型”怎么说话做事”用微调，告诉模型”现在的事实”用 RAG。

延伸：微调的隐性成本常被低估——训练集构建、基线评测、灾难性遗忘风险、基座升级后重训。成熟做法是”提示词加 RAG 打底，微调做格式收敛”，三者各司其职。

追问：客户要求”永远按固定模板回复”，先用什么验证？提示：先用 Few-Shot 提示词压测稳定性，大样本仍漂移再上 LoRA 微调。

工具调用与结构化输出

Function Calling 的完整链路是什么？

结论：Function Calling 是”模型决策、程序执行”的协议——模型只按 Schema 生成调用参数，真正的校验、执行、结果回传都发生在调用方代码里。

原理：标准链路五步：① 请求中注册工具清单（名称、描述、JSON Schema 参数）；② 模型理解意图后输出结构化调用参数，而非自然语言；③ 调用方校验参数（类型、枚举、权限、业务规则）后执行真实函数；④ 执行结果以 tool 消息追加回对话；⑤ 模型基于结果生成最终回复，复杂任务可多轮循环。要点是模型自始至终不接触执行环境，它表达的只是调用意图。

延伸：工具 description 的质量直接决定调用准确率——模型靠它判断”什么时候用我”，描述含糊会导致错调漏调。写操作的参数必须过业务校验与二次确认，模型生成的金额、账号不能直通下游。

追问：模型生成了退款工具的调用参数，业务系统还要做哪些校验？提示：权限、金额上限、幂等键、二次确认与审计日志。

为什么只写”请返回 JSON”不可靠？结构化输出怎么落地？

结论：自然语言指令对模型只是软约束，模型可能输出夹带解释文字的 JSON、缺字段或类型漂移；生产环境要”协议约束、解析校验、失败重试”三层兜底。

原理：第一层用协议约束：JSON Mode 保证输出是合法 JSON，但不保证符合你的字段约定；Structured Outputs 按 JSON Schema 在解码阶段约束采样，可做到 schema 级合规。第二层在代码侧用校验器（Pydantic、JSON Schema validator）解析，不合规立即捕获。第三层失败处理：把校验错误反馈给模型重试（self-repair），或降级到默认值与人工。还要防截断 JSON——max_tokens 太小会把输出拦腰切断，解析必挂。

延伸：JSON 漂移的典型症状是枚举值编造、数字变字符串、嵌套被拍平。Schema 设计时收窄字段（enum、取值范围、required）并给字段写 description，既能提示模型又能降低漂移率。