一、大模型基础与 API 应用

这一章是所有 LLM 应用岗面试的地基。考法上通常不深挖数学原理，而是检验你有没有真正"用过"模型 API：参数怎么调、流式怎么接、Token 怎么算钱。答不出这些，后面的 RAG、Agent 都会失去可信度。

1. 什么是 Token？为什么大模型按 Token 计费？中英文的 Token 效率差异有多大？

必刷 · 基础

参考答案

Token 是大模型处理文本的最小单位。模型不直接读字符，而是先经分词器（主流是 BPE 及其变体）把文本切成子词序列，每个条目就是一个 Token，对应词表中的一个 ID。一个 Token 可能是完整单词、词根词缀，也可能是半个汉字或一个标点。

按 Token 计费的根本原因是：Token 是计算成本的计量单位。模型的显存占用（KV Cache）、计算量（Attention 随序列长度增长）、延迟都和序列长度正相关，Token 数量直接对应消耗的算力，所以计费跟着 Token 走。

中英文效率差异（量级参考）：

• 英文：约 4 个字符 ≈ 1 个 Token，一个常见单词约 1.3 个 Token；
• 中文：取决于分词器。老分词器（如 cl100k）下常见汉字 1 字 ≈ 1~2 个 Token；新分词器（如 o200k、Qwen 系）对中文做了专门优化，约 0.6~0.7 字/Token；
• 结论：同等信息量下，中文在旧分词器上的成本可能比英文高，新分词器已基本拉平。

面试官可能追问

• 上下文窗口、输入 Token、输出 Token 的关系？为什么输出 Token 单价更高？（自回归逐位生成，Decode 阶段算力利用率低）
• 线上怎么预估一次请求的 Token 消耗？（用 tiktoken 或对应分词器库离线估算，接口账单里对齐校准）

2. temperature 和 top_p 分别控制什么？什么场景该调高、什么场景该调低？两个一起调会怎样？

必刷 · 基础

参考答案

两者都作用于模型输出分布的采样环节，但位置不同：

• temperature：在 softmax 里除以温度系数。温度低 → 分布更尖，倾向选最高概率词，输出稳定保守；温度高 → 分布更平，低概率词也有机会被选中，输出更多样、有创意，也更不可控。
• top_p（核采样）：先对候选词按概率排序，只从累积概率达到 p 的最小集合里采样，截掉长尾。它限制的是"候选池宽度"，对分布形状本身不改写。

调参经验：

• 抽取、分类、结构化输出、代码生成：temperature 0~0.3；
• 常规对话、总结：0.5~0.8；
• 创意写作、头脑风暴：0.8~1.0，可配合 top_p 0.9 左右；
• 两个一起调会难以归因：官方一般建议固定一个、只调另一个。工程上更常用"固定 top_p，调 temperature"。

面试官可能追问

• temperature=0 输出就完全确定吗？（多数服务下近似确定，但批处理、浮点舍入、集群路由仍可能引入抖动；且采样不是唯一随机源）
• 有了 temperature 为什么还需要 top_p / top_k？（高温时长尾概率被放大，需要截断兜底）

3. 什么是上下文窗口（Context Window）？输入超长会发生什么？工程上怎么处理？

高频 · 基础

参考答案

上下文窗口是模型单次请求能处理的 Token 上限，输入（system + 历史消息 + 当前问题 + 检索内容）和输出通常共享这个额度。

输入超长的表现因实现而异：多数 API 直接报错（400 上下文超限）；自己部署的开源模型则可能触发滑窗截断——悄悄丢掉最前面的内容，用户感知是"模型失忆"，这比报错更危险。

工程上的处理手段，按优先级：

1. 源头控制：历史消息裁剪（保留 system + 最近 N 轮），检索内容做 top-k 限制；
2. 压缩：对早期对话做滚动摘要，用摘要替代原文；
3. 外置化：把长文档问题转成 RAG，按需取片段而不是整篇塞入；
4. 分治：超长文档的总结、分析用 map-reduce（分段处理再汇总）。

注意：窗口大 ≠ 应该用满。长上下文意味着更高成本、更高延迟，还有 Lost in the Middle 问题——中间位置的信息利用率明显下降。

面试官可能追问

• 现在有 128K 甚至百万级窗口的模型，还需要 RAG 吗？（需要：成本、召回精度、知识时效、Lost in the Middle，RAG 依然是主流）
• 怎么给一次请求做 Token 预算分配？（system + 检索片段 + 历史 + 输出预留，各设上限，超了先裁历史）

4. KV Cache 的作用是什么？为什么它是推理显存和延迟的关键瓶颈之一？

高频 · 中等

参考答案

Transformer 自回归生成时，每生成一个新 Token，Attention 都要访问之前所有 Token 的 Key 和 Value 向量。KV Cache 把已算过的 K/V 存起来，避免每步重算前文，是典型的空间换时间：没有它，生成长度为 n 的序列计算量是 O(n²) 级别，有了它降为每步 O(n)。

为什么成为瓶颈：

• 显存占用大：与层数、KV 头数、头维度、序列长度、批大小成正比。估算公式：2 × 层数 × KV头数 × 头维 × 序列长 × batch × 每元素字节数。长上下文下 KV Cache 甚至可能超过模型权重本身；
• 制约吞吐：显存装不下更多并发序列，batch 上不去，单卡吞吐被锁死；
• 引出的优化方向：PagedAttention（vLLM，分页管理减少碎片）、GQA/MQA（减少 KV 头数）、量化 KV Cache、滑动窗口注意力等。

面试官可能追问

• Prefill 和 Decode 阶段的瓶颈有什么不同？（Prefill 算力密集、可并行；Decode 访存密集、串行，所以两者需要分别优化，如 chunked prefill、continuous batching）
• GQA 为什么能省显存？对效果有损吗？（多个 Q 头共享一组 KV 头，牺牲少量精度换大幅压缩，主流模型已标配）

5. 什么是幻觉（Hallucination）？产生幻觉的原因有哪些？工程上有哪些缓解手段？

必刷 · 基础

参考答案

幻觉指模型输出流畅自信但与事实不符的内容，包括捏造事实、编造引用、张冠李戴的参数。

产生原因：

1. 生成机制本质：模型做的是"下一个 Token 的概率预测"，训练目标是拟合语料分布，不是校验真伪，"像真话"和"是真话"在目标函数上没有区别；
2. 知识边界模糊：模型不知道自己不知道什么，训练数据覆盖不到的问题也会"硬答"；
3. 训练目标诱导：SFT/RLHF 阶段奖励"完整、有帮助"的回答，变相惩罚了"我不知道"，模型学会编；
4. 解码与提问方式：高温采样、诱导式提问（"请列出 XX 的三个优点"，哪怕不存在）都会放大幻觉。

工程缓解手段（分层）：

• 接地：RAG 提供事实依据，要求"仅根据给定资料回答"；
• 约束：降低温度、结构化输出、明确允许拒答的指令；
• 校验：输出后做引用比对、规则校验（如日期、库存）、二次模型事实核查；
• 表达：让模型对低置信内容加限定语，把"幻觉"降级为"不确定性披露"。

要点：幻觉无法根除，只能收敛，治理目标是把它控制在业务可接受阈值内。

面试官可能追问

• 怎么量化幻觉率？（抽样人工标注 + LLM as Judge 辅助，忠实度指标如 RAGAS faithfulness）
• RAG 就一定没有幻觉吗？（检索不准、模型不忠实于上下文都会幻觉，RAG 只是必要条件）

6. 流式输出（SSE / Streaming）是怎么实现的？服务端和前端各自要处理什么问题？

高频 · 基础

参考答案

原理：模型 API 是 HTTP 长连接 + 增量返回。调用方传 stream: true，服务端在生成过程中持续推送增量片段（delta），主流协议是 SSE（Content-Type: text/event-stream，基于 chunked transfer），每个事件是一小段 JSON，最后带 finish_reason 和 usage。

服务端要处理的：

• 代理转发：Nginx 等反代要关闭缓冲（proxy_buffering off），否则流会被攒成一坨；
• 超时与断连：读超时要大于生成总时长，断连要及时取消上游请求，避免白烧 Token；
• 中途错误：流跑到一半报错，无法再改 HTTP 状态码，只能约定错误事件格式；
• 计费与日志：usage 在最后一个 chunk，要在连接结束时落日志。

前端要处理的：

• 用 fetch + ReadableStream（EventSource 不支持 POST 和自定义 header）；
• 增量 Markdown 渲染：半截 Markdown（未闭合代码块）要容错渲染，否则界面抖动；
• 打字机平滑、停止生成按钮、断线重连策略。

面试官可能追问

• SSE 和 WebSocket 怎么选？（LLM 场景单向推送即可，SSE 更轻、天然过 HTTP 基础设施；需要双向低延迟如语音才上 WebSocket）
• 首 Token 延迟（TTFT）为什么是核心体验指标？（用户感知"开始回答了"主要看 TTFT，而不是总时长）

7. 如何让模型稳定输出符合 Schema 的 JSON？说说 JSON Mode、Function Calling 和约束解码的区别。

高频 · 中等

参考答案

这是工程必考题。手段按"保证强度"递进：

1. 提示层：Prompt 里给 Schema + Few-shot，输出后用 Pydantic/jsonschema 校验，失败则把校验错误回传让模型修复。成本低，但只是"概率保证"；
2. 接口层 JSON Mode：API 保证输出是合法 JSON，但不保证符合你的 Schema（字段可能缺、多）；
3. 接口层 Function Calling / Structured Output：把目标 Schema 作为参数结构传给 API，模型按 Schema 填参，主流厂商的 structured output 已做到语法级保证（个别对复杂嵌套、oneOf 有限制）；
4. 解码层约束解码：自部署时用约束采样（llama.cpp GBNF 语法、Outlines、xgrammar），在每步采样时屏蔽不合法 Token，从根上保证格式，代价是引擎耦合和少量吞吐损失。

落地建议：API 方案用 Structured Output + 校验兜底；自部署用约束解码；两者都要处理语义合法性（格式对但值错，如日期超范围），这层只能靠业务校验。

面试官可能追问

• 为什么 temperature 调低有帮助但还是不够？（采样只影响选词倾向，不构成语法约束）
• 输出被 max_tokens 截断导致 JSON 不完整怎么办？（预留足够输出预算、分段生成、校验失败重试）

8. system / user / assistant 三种消息角色分别怎么用？system prompt 的编写有哪些最佳实践？

中频 · 基础

参考答案

• system：全局设定，定义"模型是谁、边界是什么、输出什么格式"。在指令优先级上通常最高，适合放稳定不变的规则；
• user：用户输入，任务的具体指令和上下文也从这里给；
• assistant：模型历史回复；同时可以用于预填（prefill）——把 assistant 消息的最后一条留成半句，引导模型接着写，是控制输出开头格式的利器（部分 API 支持）。

system prompt 最佳实践：

1. 结构化分段：角色定位 → 能力边界（必须做 / 禁止做）→ 输出规范（格式、长度、语言）→ 兜底策略（不知道怎么办、遇到攻击怎么办）；
2. 正向指令优于负向："用简体中文回答"好于"不要用英文"（负向指令容易被忽略）；
3. 关键规则放前面或显式编号：长 Prompt 中段信息容易被忽略；
4. 给拒答出口：明确"资料中没有依据时回答'未找到'"，降低编造动机；
5. 版本化管理：system prompt 是代码资产，要能回滚、diff、A/B。

面试官可能追问

• 用户能通过 user 消息覆盖 system 规则吗？（能，这正是 Prompt 注入的入口，敏感规则要在应用层再卡一道）

9. 开源模型和闭源 API 怎么选型？从效果、成本、数据安全、可控性几个维度对比。

高频 · 基础

参考答案

给一个四维对比再给决策建议：

• 效果：闭源旗舰在复杂推理、长上下文、指令遵循上仍有代差；开源 70B 级（Qwen、DeepSeek、LLaMA 系）已能覆盖大多数业务任务，简单任务差距更小；
• 成本：低量级用 API 零成本启动；高并发稳定负载下自持 GPU 的 TCO 更优，拐点要按 QPS × 平均 Token 数 × 单价 vs GPU 租金+运维估算；
• 数据安全：金融、医疗、政务等合规场景（数据不出域）基本只能私有化部署；一般业务确认 API 厂商的数据不留存条款即可；
• 可控性：开源可微调、可审计、可离线、无厂商锁定；闭源升级可能带来行为漂移，且无法干预内部。

决策框架：起步用闭源 API 快速验证（迭代快、无基建），跑通后按"数据合规 → 成本拐点 → 定制需求"三条线评估是否迁到开源自部署；主流做法是混合——简单任务路由到自部署小模型，难任务走旗舰 API。

面试官可能追问

• 怎么估算自部署的成本？（按目标 P95 延迟和峰值 QPS 算需要的并发实例数 × 单实例 GPU 成本，加上运维和冗余）
• 开源模型升级换代快，怎么避免频繁迁移成本？（抽象模型接入层，评测集回归驱动升级决策）

10. max_tokens、stop、presence_penalty、frequency_penalty 这些参数分别在什么场景下使用？

中频 · 中等

参考答案

• max_tokens：输出长度上限，防失控、控成本。注意它是"硬截断"——超了答案戛然而止，JSON 会被截成非法格式，要预留余量；
• stop：停止序列，命中即停且不包含停止串。经典用法：多轮格式控制（如 "Human:" 防模型自问自答）、只要列表第一项、截取固定格式段；
• presence_penalty：对已出现过的 Token 施加固定惩罚，鼓励引入新话题、新词，缓解车轱辘话；
• frequency_penalty：按出现次数递增惩罚，主打压复读机行为。

使用场景：

• 客服话术要短 → max_tokens + "回答不超过 N 句"的指令配合；
• 摘要任务复读严重 → 先升 frequency_penalty（0.3~0.6），仍不行再考虑换模型或降温度；
• 结构化抽取 → stop 限定字段结束。

注意：penalty 是全局作用于所有 Token 的（包括专有名词），调太高会出现强行换同义词、专名写错等副作用，优先靠 Prompt 解决，penalty 只做微调。

面试官可能追问

• 为什么模型会复读？（训练分布、解码偏差、长上下文自增强，多因叠加；严重复读通常是任务或 Prompt 设计问题，不是参数能根治的）

11. Embedding 模型和生成模型的 Tokenizer 不一致，会带来什么工程问题？

中频 · 较难

参考答案

典型场景：RAG 系统里用 A 模型算向量、B 模型做生成，两边分词器不同。问题主要出在计量和预算失真：

1. Token 统计口径混乱：分块按生成模型 Token 数切片，但 Embedding 模型有自己的 max_seq_len（常见 512），两套计数不一致，块可能在向量侧被静默截断——尾部内容没进向量，检索永远召不回；
2. 上下文预算算错：以为塞得下的检索片段，换模型计数后超限；
3. 截断位置不可控：截断发生在向量侧，业务无感知，表现为"明明库里有的内容搜不到"，极难排查；
4. 成本估算偏差：账单按各自 Token 计费，预估模型混用导致成本对不上。

工程处理：

• 分块长度以两侧约束的交集为准（min(生成模型预算, Embedding 模型上限)再打折）；
• 建立统一的 Token 计量工具，明确每个环节用哪个分词器计数；
• 对 Embedding 输入做显式长度检查，超限报警而不是静默截断。

面试官可能追问

• BPE 和 BBPE 的区别？（BBPE 在字节级做 BPE，天然覆盖任意 UTF-8 字符、无 OOV，但子词语义完整性差一些，中文场景需要更大词表补偿）

12. 同一份 Prompt 换模型后表现差异很大，迁移适配和回归验证怎么做？

中频 · 中等

参考答案

差异来源：各家模型的指令遵循习惯、聊天模板（chat template）、system 消息尊重程度、停止符约定、默认采样参数都不同，Prompt 是强模型绑定的资产。

标准迁移流程：

1. 建评估集：从线上日志抽 100~300 条真实请求，覆盖典型场景 + 历史 bad case，人工标注或确认期望输出；
2. 跑基线：原模型过一遍评估集，记录分数；
3. 差异分析：新模型跑同套 Prompt，逐类对比失败模式（格式不守、语言不对、拒答过度、幻觉增加），针对性改写——常见修改点：指令更显式、格式要求后置加重申、few-shot 换成新模型风格；
4. 回归验证：新旧分数对比 + 线上灰度（小流量切流），盯关键指标（采纳率、人工接管率、投诉率）；
5. 沉淀 Prompt 资产库：Prompt 按版本管理，绑定"已验证的模型 + 采样参数"，禁止裸改线上。

面试官可能追问

• 有没有让 Prompt 尽量可移植的写法？（少用模型特有的小聪明技巧，用"角色 + 显式规则 + 格式示例"的标准结构，复杂约束靠结构化输出接口而不是纯文字）