大模型基础面试题

这一类题考的不是数学推导，而是你有没有正确的工程直觉：模型为什么会贵、为什么会慢、为什么会答错、为什么需要检索和工具。

答题主线

把一句“请把会议纪要压缩成三条”想成把积木装进有限大小的盒子：系统提示、历史对话、工具定义和文档都会占位置。盒子快满时，模型可能先丢掉最早的上下文，成本和答案稳定性也会一起变。

回答大模型基础题时，建议按这条线展开：

文本先被切成 token -> token 进入上下文窗口 -> 模型按概率生成下一个 token
-> 采样参数影响稳定性和创造性 -> embedding 把文本变成向量
-> 缓存、截断、长上下文、RAG 都是在管理成本和信息密度

面试官通常不是想听一堆名词，而是想确认你能把这些概念和工程问题连起来：

• token 决定成本、上下文上限和延迟。
• 采样决定输出稳定性和多样性。
• embedding 决定检索、聚类、去重、推荐的基础质量。
• 缓存决定重复请求能不能省钱、省时。
• 幻觉说明模型不是数据库，事实性任务要接证据。

一、Token 与上下文

Q1：token 是什么？为什么大模型 API 按 token 计费？

考察点

考察你是否理解 token 是模型计算、容量、计费和延迟的共同单位，而不是简单的字符数。

回答脉络

先说明 token 的定义，再讲它对工程的影响：计费、上下文窗口、截断、延迟。

参考答案

token 是模型处理文本的基本单位。它不是固定等于一个字，也不固定等于一个英文单词。英文里一个单词可能被拆成多个 token，中文里一个字或几个字也可能对应不同 token，代码和标点也会被单独切分。

API 按 token 计费，是因为模型计算基本围绕 token 展开：输入 token 越多，模型要读的上下文越长；输出 token 越多，模型生成的步数越多。工程上我关心 token，主要是因为四件事都和它有关：

• 成本：输入、输出、缓存命中通常分别计价。
• 上下文窗口：一次请求能放多少历史、工具结果和检索片段，受 token 限制。
• 截断风险：超过窗口后，前面的内容可能被裁剪，模型看不到关键事实。
• 延迟：长输入和长输出都会让请求更慢。

所以我不会只把 token 当成“分词概念”，而会把它当成 Agent 系统里的成本和容量单位。

常见追问

• 中文一个字是不是一个 token？
• 为什么同一段文字，不同模型 token 数可能不同？
• 为什么 Agent 多轮对话成本比单轮问答高很多？

容易扣分

• 说 token 就是一个字或一个词。
• 只讲计费，不讲上下文和延迟。
• 不知道输入 token 和输出 token 通常价格不同。

常见追问及答案

• 问：中文一个字是不是一个 token？ 不是固定关系，取决于 tokenizer 词表；中文、英文、数字、代码和标点的切分效率都可能不同。
• 问：为什么 Agent 多轮对话成本比单轮高？ 每轮通常会重新携带部分历史、系统提示、工具定义和工具结果，输入 token 累积；还可能有多次规划、调用和重试。

容易扣分

• 只说 token 是“一个字”或“一个单词”。
• 只讲价格，不会把 token 和上下文、延迟、截断联系起来。

Q2：context window 和 max output tokens 有什么区别？

考察点

考察你能否区分模型总容量、输入预算和输出上限，并把它们落到截断和成本问题上。

回答脉络

把“模型最多能看多少”和“这次最多生成多少”分开。

参考答案

context window 是模型一次请求可处理的总 token 容量，通常包括 system prompt、开发者指令、用户消息、历史对话、工具结果、检索证据和本次输出预算。max output tokens 是本次调用最多允许模型生成多少 token。

两者的关系可以理解成：

输入 token + 输出 token <= 模型上下文窗口

如果输入已经很长，留给输出的空间就会变少。比如一个 Agent 把大量历史消息、工具返回结果和 RAG 片段都塞进去，即使模型支持很大的上下文窗口，也可能出现输出被截断、成本升高、注意力被噪声稀释的问题。

面试里可以这样说

context window 是总容量，max output tokens 是本次生成上限。
做 Agent 时不能只看模型支持多大窗口，还要控制每轮放进去的信息密度。

常见追问

• 上下文窗口越大，是不是就越不需要 RAG？
• 为什么输出有时突然中断？
• 长上下文为什么仍然可能答错？

常见追问及答案

• 问：输入已经用了 12000 token，窗口是 16000，还能设置 max_output_tokens=8000 吗？ 参数可能被服务端拒绝、自动裁剪，或实际只能生成约 4000 token，取决于 API。工程上应先估算输入，再按 window - input - safety_margin 设置输出预算。
• 问：截断历史时优先删什么？ 先删低价值的旧闲聊和重复工具结果，保留系统约束、当前任务、关键事实和未完成的工具状态；必要时对历史做摘要并保留原始消息索引。

容易扣分

• 把 max output tokens 说成窗口之外的额外容量。
• 只说“超长就截断”，却不说明截断策略和关键信息保护。

Q3：为什么长上下文不等于“把所有东西都塞进去”？

考察点

考察你是否理解上下文工程的核心是信息密度，而不是单纯追求窗口大小。

回答脉络

讲清长上下文的价值和代价，再指出 RAG/context engineering 的作用。

参考答案

长上下文能减少一些外部记忆和检索工程，让模型一次看到更多材料。但它不等于可以无脑塞全文，原因有四个：

• 贵：长输入会增加 prefill 成本，多轮 Agent 还会反复携带上下文。
• 慢：模型读长输入需要更多计算，响应延迟会上升。
• 噪声大：无关内容越多，模型越可能抓错重点。
• 不好评估：所有材料都混在 prompt 里，难追踪哪条证据支持了哪个结论。

更合理的做法是：稳定指令放前面，历史对话做摘要，工具结果做裁剪，知识材料用 RAG 按需取片段。长上下文适合“确实需要整体阅读”的任务，RAG 适合“从大量资料中找相关证据”的任务。

常见追问

• 长文档总结该用长上下文还是 RAG？
• 多轮对话历史越来越长怎么办？
• 工具结果很长怎么办？

常见追问及答案

• 问：长文档总结该用长上下文还是 RAG？ 如果目标是通读全文、保留全局结构，优先长上下文或分层总结；如果目标是回答局部事实，优先检索相关片段。两者也可以结合：先检索定位，再对命中的章节做完整阅读。
• 问：多轮对话历史越来越长怎么办？ 采用滑动窗口、摘要记忆和结构化状态三层策略，并设置 token 预算；不要把“模型自己记得”当成持久化方案。
• 问：工具结果很长怎么办？ 工具返回机器可读字段，服务端先过滤、分页、聚合或摘要，只把与当前决策相关的字段传给模型；原始结果落库，便于审计和重放。

容易扣分

• 认为长上下文可以完全替代检索、数据库和状态管理。
• 只谈成本，不谈噪声、证据可追踪性和信息丢失。

二、生成、采样与不确定性

Q4：大模型为什么是逐 token 生成？这对工程有什么影响？

考察点

考察你是否能从自回归生成机制推导出流式输出、首 token 延迟、吞吐和幻觉风险。

回答脉络

不用讲复杂数学，只讲“基于上下文预测下一个 token”，以及这带来的流式输出、截断、幻觉和成本问题。

参考答案

大模型生成文本时，本质上是在已有上下文基础上预测下一个 token，然后把新 token 加回上下文继续预测。这个机制带来几个工程影响：

• 可以流式输出，因为模型是一段一段生成的。
• 输出长度越长，生成步数越多，成本和延迟越高。
• 前面生成错了，后面可能沿着错误继续展开。
• 模型生成的是“看起来最合理的文本”，不是直接查数据库。

所以事实性任务不能只依赖模型内部知识，要结合检索、工具和引用来源。

常见追问及答案

• 问：为什么首 token 很慢，后续 token 相对快？ 首 token 前要先对整段输入做 prefill，建立注意力状态；之后主要是逐 token decode。长 prompt 往往拉高 TTFT，长输出则主要拉高 TPOT 和总时延。
• 问：前面生成错了为什么后面容易错？ 后续 token 会把前面生成的内容当作条件，错误会进入上下文并被继续扩写。因此高风险任务要在工具调用、结构化校验或中间步骤设置检查点。

容易扣分

• 说模型是在一次计算中直接生成整段答案。
• 只讲“能流式”，不理解 prefill/decode 和错误累积。

Q5：temperature 和 top_p 有什么区别？怎么选？

考察点

考察你是否理解解码参数改变的是概率分布和候选范围，而不是直接控制事实准确率。

回答脉络

说明它们都影响采样随机性，但控制方式不同；再结合场景给建议。

参考答案

temperature 会改变概率分布的尖锐程度。temperature 越低，模型越倾向选择高概率 token，输出更稳定；temperature 越高，低概率候选也更容易被选中，输出更发散。

top_p 是核采样。它不是调整所有 token 的概率，而是从概率最高的候选开始累加，直到累计概率达到 p，只在这个候选集合里采样。top_p 越小，候选范围越窄；top_p 越大，候选范围越宽。

工程上我通常这样选：

• 分类、抽取、工具参数生成：低 temperature，强调稳定。
• 代码生成和技术问答：偏低到中等，减少胡乱发挥。
• 文案、创意、头脑风暴：可以适当提高。
• 评估和回归测试：尽量固定参数，减少随机性。

面试里不要说“temperature 控制准确率”。更准确的说法是它控制生成分布的随机性，准确率还取决于任务、上下文、证据和模型能力。

常见追问及答案

• 问：temperature 和 top_p 可以同时大幅调高吗？ 可以配置，但不利于定位问题，通常先固定一个、调另一个。生产回归应固定参数和随机种子能力（若服务支持），并用多次采样估计波动。
• 问：temperature=0 能保证 JSON 合法吗？ 不能。应使用结构化输出或 JSON Schema 约束，再做解析、字段校验和失败重试。

容易扣分

• 说 temperature 越低准确率必然越高。
• 把 top_p 解释成“取概率最高的 p 个 token”。

Q6：为什么同一个问题问多次，模型回答可能不同？

考察点

考察你能否区分随机采样造成的不确定性与上下文、检索、服务版本变化造成的不一致。

回答脉络

从采样、上下文、模型服务、工具结果四个层面解释。

参考答案

主要原因是生成过程包含采样。同一个上下文下，如果 temperature、top_p 允许随机性，模型可能选择不同 token，于是后续文本也会分叉。即使把采样参数调低，真实系统里仍可能因为以下因素产生差异：

• 上下文不完全一样，比如历史消息或工具结果顺序变了。
• 检索结果不同，比如向量库更新或 rerank 结果变化。
• 外部工具返回不同，比如实时搜索、价格、库存。
• 模型服务端版本或推理策略变化。

如果业务需要稳定输出，要用结构化输出、低随机参数、固定上下文、评估回归、业务规则校验，而不是只靠一句 prompt。

常见追问及答案

• 问：temperature=0 是否保证完全一致？ 不一定。实现可能仍有并列候选的非确定性，服务端批处理、模型版本、工具结果和浮点计算也可能变化。需要固定模型版本、输入、工具响应和解码设置，并用容差或语义指标评估。
• 问：生产中如何处理必要的随机性？ 对创作保留采样，对分类和工具参数使用低随机性及 schema 校验；记录 prompt、模型版本、参数、检索证据和 request id，保证问题可回放。

容易扣分

• 把不稳定全部归因于 temperature。
• 认为 temperature=0 就等于确定性证明或高置信度。

Q7：为什么模型会幻觉？工程上怎么缓解？

考察点

考察你是否能把幻觉拆成知识缺失、证据错误、推理错误和系统约束不足，并设计可验证的缓解链路。

回答脉络

先承认这是生成式模型的天然风险，再讲触发原因和工程方案。

参考答案

幻觉是指模型生成了看似合理但不符合事实、证据或业务状态的内容。它出现的根本原因是模型在生成下一个 token，而不是在数据库里验证事实。常见触发条件包括：

• 问题超出模型知识范围。
• 上下文没有提供足够证据。
• 检索片段不相关或互相冲突。
• prompt 要求模型必须回答，导致它不敢说不知道。
• 多轮对话里历史信息污染了当前任务。

工程上可以用几层方法降低风险：

• RAG：把外部知识作为证据放进上下文。
• 工具调用：实时状态交给 API 查询。
• 引用来源：每个关键结论绑定证据。
• 无答案策略：证据不足时允许回答“不确定”。
• eval：用测试集统计幻觉率和无答案识别率。
• guardrails：对高风险输出做规则或模型复核。

常见追问

• RAG 能完全消除幻觉吗？
• 为什么有引用也可能答错？
• 模型不知道时为什么不直接说不知道？

常见追问及答案

• 问：RAG 能完全消除幻觉吗？ 不能。检索可能召回错误片段，模型也可能误读、拼接或超出证据推断。应评估检索召回、答案与证据的一致性，并允许证据不足时拒答。
• 问：为什么有引用也可能答错？ 引用只证明模型放了一个链接，不证明结论被该片段支持。应要求引用粒度与结论绑定，并用规则或评审模型检查结论是否被证据支持。
• 问：模型不知道时为什么不直接说不知道？ 训练目标偏向生成合理续写，且用户常要求必须回答；需要在 prompt、检索置信度阈值、工具校验和业务拒答策略中显式定义“不确定”。

容易扣分

• 把幻觉说成单纯“训练数据过时”。
• 认为加一句“不要胡说”或接入 RAG 就能根治。

三、Embedding、向量与聚类

Q8：embedding 是什么？它和普通关键词搜索有什么区别？

考察点

考察你是否理解 embedding 的空间语义、检索边界，以及为什么实际系统经常采用混合检索。

回答脉络

说明 embedding 是语义向量，再讲它适合语义相似，不擅长精确约束。

参考答案

embedding 是把文本、图片或代码等对象映射成一组数字向量。向量空间里距离越近，通常表示语义越相似。RAG 里的向量检索，就是把用户问题和文档 chunk 都转成 embedding，再按相似度找相关片段。

它和关键词搜索的区别是：

• 关键词搜索擅长精确匹配，比如编号、错误码、人名、专有名词。
• 向量检索擅长语义匹配，比如“怎么报销差旅”和“差旅费用报销规则”。
• 向量检索可能错过必须逐字匹配的内容。
• 关键词搜索可能错过表达不同但意思相近的内容。

所以真实 RAG 里经常用混合检索，把向量检索和 BM25/关键词检索结合起来。

常见追问及答案

• 问：为什么向量相似但不是正确答案？ embedding 主要表达整体语义相近，不保证包含用户要求的数字、权限、时间和版本条件；需要 metadata filter、关键词约束、rerank 和最终答案校验。
• 问：RAG 的检索指标看什么？ 先看带标注问题集上的 recall@k、MRR 或 nDCG，再看最终答案的 faithfulness、answer accuracy、延迟和成本；只看向量距离不够。

容易扣分

• 说 embedding 是“把文本压缩成摘要”。
• 认为向量距离越近就一定是事实正确或可直接回答。

Q9：embedding 常见维度是多少？常见模型有哪些？

考察点

考察你能否从模型系列、维度、语言/领域匹配和离线指标来回答选型，而不是背一个固定数字。

回答脉络

不要背一个固定数字，要讲“维度范围 + 模型系列 + 选择标准”。

参考答案

embedding 维度取决于模型，不同模型差异很大。常见维度大致有这些区间：

维度区间	常见场景	例子
384 / 512	轻量检索、端侧、小规模语义匹配	MiniLM、小型 BGE 类模型
768	通用文本向量、成本和效果折中	BGE-base、E5-base、一些多语言模型
1024	更强的通用或多语言检索	BGE-large、E5-large、Cohere Embed 常见配置
1536	OpenAI 早期和部分通用 embedding 常见维度	text-embedding-ada-002、text-embedding-3-small 常见默认维度
3072	高质量通用 embedding 常见维度	text-embedding-3-large 常见默认维度
4096 及以上	特定大模型或领域模型	质量可能更高，但成本和索引压力也更大

常见模型系列可以按用途记：

• OpenAI embedding：通用、多语言、API 易用，适合快速做 RAG。
• BGE 系列：中文和中英检索里很常见，开源部署选择多。
• E5 系列：通用检索常见，常配合 query/passage 前缀使用。
• Cohere Embed：商业 API 常见，多语言和企业检索场景较多。
• Jina Embeddings：多语言、长文本和开源生态里常见。
• 领域 embedding：代码、法律、医学、电商等场景可能需要专门模型。

面试里我会强调：维度不是越大越好，最终要用自己的评测集比较 recall@k、MRR、延迟、存储、成本。

常见追问及答案

• 问：embedding 模型可以随时替换吗？ 不建议直接替换。新旧模型的向量空间通常不兼容，应新建版本化索引，双写或离线重建后用同一评测集和灰度流量切换。
• 问：中文知识库怎么选 embedding？ 先用中文/中英业务问题做标注集，比较 recall@k、rerank 后命中率和成本；模型名只是候选，不能替代业务评测。

容易扣分

• 把 embedding 维度当作模型质量排名。
• 不验证语言、领域、query/document 指令和索引兼容性。

Q10：embedding 维度越高越好吗？

考察点

考察你能否同时考虑表示能力、索引成本和真实业务指标，而不是追求单一参数最大化。

回答脉络

先否定“越高越好”，再讲效果和成本的平衡。

参考答案

不一定。更高维度可能表达能力更强，但不保证在你的数据上效果更好，而且会带来明显代价：

• 向量存储更大。
• 内存和索引占用更高。
• 检索延迟可能上升。
• 构建索引和重建索引更慢。
• 同样预算下能放进缓存或内存的数据更少。

选择 embedding 维度时，我会先用小样本评估不同模型和维度配置，看 top-k 是否能召回正确文档，再比较延迟和成本。如果低维模型已经满足业务指标，没有必要为了“看起来更强”上更大维度。

常见追问及答案

• 问：1536 维 float32 向量单条大约占多少原始空间？ 约为 1536 × 4 = 6144 bytes，即 6 KiB；100 万条仅原始向量就约 5.7 GiB，还未计入索引、元数据和副本。若用 float16，大约减半，但要验证召回变化。
• 问：能不能直接截断向量维度？ 只有模型明确支持 Matryoshka 或维度裁剪时才建议这样做；任意截断会破坏训练好的空间结构，必须重新评估。

容易扣分

• 只拿维度高低代替模型效果评估。
• 忽略索引和元数据带来的额外存储。

Q11：向量相似度常用哪些算法？cosine、dot product、L2 怎么选？

考察点

考察你是否理解相似度、归一化和索引配置之间的关系，能避免入库和查询使用不一致的度量。

回答脉络

先说它们都是衡量向量距离或相似度的方法，再讲归一化的影响。

参考答案

常见向量相似度有三类：

• Cosine similarity：看向量夹角，关注方向相似度，文本语义检索很常见。
• Dot product：点积，受向量方向和模长共同影响。很多向量库和模型推荐用它。
• L2 distance：欧氏距离，看空间里的距离大小。

如果向量做了归一化，cosine 和 dot product 的排序结果通常会非常接近。实际选择时要看 embedding 模型文档和向量数据库索引配置，不要随便混用。最重要的是：入库和查询必须用同一个 embedding 模型、同一种预处理、同一种距离度量。

常见追问

• 为什么换了相似度算法，召回结果变差？
• 向量需要归一化吗？
• embedding 模型升级后可以只替换新文档吗？

常见追问及答案

• 问：向量需要归一化吗？ 取决于模型训练目标和向量库配置；若采用 cosine，通常会归一化，若模型推荐 dot product，则应按其文档执行。入库和查询必须一致。
• 问：embedding 模型升级后可以只替换新文档吗？ 通常不可以。新旧向量空间可能不可比，应版本化重建索引，或在查询侧按版本分别召回再合并验证。

容易扣分

• 只背算法名，不知道归一化会影响排序。
• 混用不同模型生成的向量或不同距离度量。

Q12：聚类是什么意思？embedding 聚类有什么用？

考察点

考察你是否能区分聚类、分类和检索，并说明聚类结果如何服务于数据治理和产品决策。

回答脉络

先解释聚类是“无监督分组”，再讲它和检索、标签、去重、数据探索的关系。

参考答案

聚类就是在没有人工标签的情况下，把相似的数据自动分到一组。放在 embedding 场景里，就是先把文本变成向量，再根据向量距离把语义相近的文本聚成簇。

它常见用途包括：

• 知识库整理：发现重复文档、相似 FAQ、主题簇。
• 用户问题分析：把大量客服问题聚成常见问题类别。
• RAG 优化：看哪些主题召回差，哪些 chunk 重复太多。
• 异常发现：找离群文档、奇怪问题或低质量内容。
• 推荐和分群：按语义相似度做内容推荐或用户意图分组。

聚类不是分类。分类通常有固定标签，比如“退款问题/物流问题”；聚类是让算法自己从数据分布里发现分组，分完以后还需要人给簇命名和解释。

常见追问及答案

• 问：聚类结果如何验证？ 用轮廓系数等内部指标发现异常，但最终要人工抽样检查簇内一致性、簇间差异和业务可解释性；客服意图还应与人工标签或后续处理成功率对照。
• 问：一个簇很杂怎么办？ 检查文本清洗、embedding 模型和距离度量，尝试重新切分、增加簇数或分层聚类；不要只靠调算法参数掩盖主题本身混杂。

容易扣分

• 把聚类直接当成有监督分类。
• 只报算法名称，不说明结果如何验收和落地。

Q13：embedding 聚类常见算法有哪些？怎么选？

考察点

考察你是否能根据簇数量、密度、噪声和规模选择算法，并意识到高维 embedding 的距离会退化。

回答脉络

按“是否知道簇数量、是否有噪声、数据规模”来讲。

参考答案

常见算法有：

算法	适合场景	注意点
K-Means	已知大概簇数量，数据规模较大	需要指定 k，对异常点敏感
MiniBatch K-Means	数据量很大，需要更快聚类	质量可能略低，但速度快
层次聚类	想看主题层级、小中规模数据	大数据下成本较高
DBSCAN	想发现噪声点，不想预先指定簇数量	参数 eps/min_samples 敏感，高维效果不一定稳
HDBSCAN	簇密度不均、想自动发现簇	比 DBSCAN 更灵活，但参数和解释成本更高
GMM	假设数据来自多个概率分布	需要指定或选择成分数，对假设有要求
谱聚类	非凸形状、小规模复杂结构	计算成本高，不适合超大规模

做文本 embedding 聚类时，我通常会先降维可视化，比如 UMAP/t-SNE/PCA，再用 K-Means 或 HDBSCAN 做初版。真正上线前还要人工抽样看每个簇是否可解释，因为聚类结果“数学上近”不一定“业务上有意义”。

常见追问

• 怎么给每个簇自动命名？
• 聚类后发现一个簇很杂怎么办？
• 聚类能直接替代人工标签吗？

常见追问及答案

• 问：为什么先降维再聚类有风险？ 降维可能丢失局部距离和簇边界；可视化用 UMAP/t-SNE 不等于应在二维坐标上直接做生产聚类。应在原空间或经过验证的降维空间分别评估。
• 问：怎么选 K-Means 的 k？ 可结合轮廓系数、肘部法、稳定性和业务可解释性，但不存在只靠数学指标确定的唯一 k。

容易扣分

• 默认所有 embedding 都适合欧氏距离和 K-Means。
• 把二维可视化图上的分组当成最终业务结论。

四、缓存、推理 token 与成本直觉

Q14：KV Cache 和 Prompt Caching 是一回事吗？

考察点

考察你是否能区分单次生成内部的 KV 状态复用与多次请求之间的 prompt 前缀复用。

回答脉络

这是高频混淆点。一定要分清“单次生成内部缓存”和“多次请求复用前缀”。

参考答案

不是一回事。

KV Cache 是模型在一次生成过程中缓存 attention 里的 key/value 状态。它主要用于避免每生成一个新 token 都从头计算全部历史，从而提升推理效率。它通常发生在服务端推理内部，开发者不一定直接控制。

Prompt Caching 是 API 层面对多次请求里相同前缀的复用。如果很多请求都有相同的 system prompt、工具定义、长文档前缀或稳定上下文，服务端可以复用这部分计算，cached input token 的价格可能更低，延迟也可能更好。

简单说：

KV Cache：一次请求内部，生成时复用历史计算。
Prompt Caching：多次请求之间，复用相同 prompt 前缀。

常见追问及答案

• 问：KV Cache 为什么能降低 decode 成本？ 每生成一个新 token，只需计算它与历史的注意力，并复用历史 token 的 K/V；如果不缓存，就要重复计算整段历史。代价是缓存随序列长度和并发增长，占用显存。
• 问：Prompt Caching 命中率怎么提高？ 把稳定的 system prompt、工具 schema 和公共文档放在前面，把用户问题、时间戳和随机 request id 放在后面，并保证序列化、模型版本和前缀完全符合服务商的命中规则。

容易扣分

• 把 cached_tokens 解释成 KV Cache。
• 以为只要 prompt 看起来相似就一定命中缓存。
• 不知道动态字段放在前面会破坏缓存前缀。

Q15：reasoning tokens 是什么？算成本时要注意什么？

考察点

考察你是否能区分可见输出、内部推理消耗和供应商 usage 口径。

回答脉络

说明它通常属于输出侧的内部推理消耗，不要和普通输出重复计算。

参考答案

一些推理模型会在内部生成不可见的 reasoning tokens，用于规划、推导或检查。这些 token 用户看不到，但通常会体现在 usage 的 output details 里，并计入输出成本。

算账时要注意：

• 不要只看最终可见文本长度，推理模型可能还有不可见输出消耗。
• 不要把 reasoning tokens 在总 output tokens 之外重复计费。
• 对复杂任务要限制最大输出、最大轮数和预算。
• 用 trace 记录每轮 usage，找出哪一步推理消耗最高。

面试里可以这样说

reasoning tokens 更像输出侧的内部思考预算。它能提升复杂任务表现，但也会增加成本，所以要配合任务难度、预算和评估来用。

常见追问及答案

• 问：reasoning tokens 越多一定越准确吗？ 不一定。复杂推理可能受益，但过高预算会增加延迟和成本，也可能让模型在简单任务上过度思考；应按任务分级并以“成功任务成本”评估。
• 问：如何发现 reasoning 成本失控？ 按模型、任务、轮次记录总 output、reasoning、失败重试和工具调用，观察 P95 成本与成功率，而不是只看平均可见答案长度。

容易扣分

• 把 reasoning tokens 当成用户可见答案 token。
• 把不同供应商的 usage 字段和计费口径强行等同。

Q16：面试中如何快速估算一次 LLM 调用成本？

考察点

考察你能否建立可核对的成本模型，并把单次调用扩展到 RAG、Agent、多租户和失败重试。

回答脉络

按 token 类型拆，不要把 total_tokens 乘一个单价。

参考答案

我会先拆成输入、缓存输入、缓存写入、输出几类 token，再分别乘对应单价。粗略公式是：

uncached_input = input_tokens - cached_input_tokens - cache_write_tokens

cost =
  uncached_input      * input_price
+ cached_input_tokens * cached_input_price
+ cache_write_tokens  * cache_write_price
+ output_tokens       * output_price

这只是字段互斥且价格已知时的简化模型。实际面试回答要补充：不同服务商可能把缓存写入计入普通输入、把 reasoning tokens 包含在 output tokens 中，或者使用不同的 usage 字段名；因此先查清计费口径，再由按供应商配置的计费适配器计算，不能把这条公式硬编码成所有模型都适用。

如果是 RAG 或 Agent，还要额外加：

• embedding 成本。
• rerank 成本。
• 搜索 API 或第三方工具成本。
• 多轮调用的累计成本。
• 重试和失败请求成本。

面试官问成本，本质上是看你有没有工程运营意识，而不是只会调用模型。

常见追问及答案

• 问：一个用户请求平均触发 4 次模型调用，单次成功率 92%，怎么估算？ 先算各步骤的期望调用次数和失败重试上限，至少用 总成本 = 各步骤调用次数 × 平均 token 成本 + embedding/rerank/工具成本，再用线上 usage 校准；不能只拿最后一次回答计费。
• 问：如何避免成本优化损伤质量？ 每次优化都固定离线评测集，联合看任务成功率、事实性、结构化合法率、P95 延迟和单成功任务成本；通过灰度与回滚阈值发布。

容易扣分

• 直接用字符数乘单价。
• 忽略失败请求、重试、缓存、embedding 和工具成本。

五、Tokenizer、上下文与解码细节

Q17：Tokenizer 是怎么把文本变成 token 的？BPE、WordPiece 和 Unigram 有什么概念区别？

考察点

考察你是否理解 token 不是按字符或单词硬切出来的，以及不同 tokenizer 为什么会影响成本、上下文利用率和跨语言表现。

回答脉络

先说明 tokenizer 的输入输出，再说明子词算法的基本思想，最后落到实际工程中如何统计和验证。

详细参考答案

Tokenizer 的作用是把原始字符串转换成模型词表中的 token id 序列，模型处理的是 token id 经过 embedding 后的向量，而不是直接处理字符串。一个 token 可以是一个字符、一个常见词、词的一部分、标点、空格，也可能是代码中的一段固定片段。

以子词 tokenizer 为例，它希望在“词表不要无限大”和“常见片段尽量不要拆太碎”之间取得平衡。BPE 通常从较小的符号单元开始，反复合并高频相邻片段；WordPiece 也使用子词词表，但训练目标和合并准则不同；Unigram 可以理解为从许多候选切分中选择概率更高的一种切分。面试时不需要死背训练公式，但要知道它们最终都会把文本映射为模型固定词表里的离散 id。

Tokenizer 有几个很实际的影响：

• 中文、英文、数字、表情、代码和混合文本的 token 密度不同，同样的字符数不代表同样的 token 数。
• tokenizer 和模型是绑定的，换模型后不能沿用原来的 token 估算结果。
• chat API 还可能把 role、消息边界、工具定义和特殊标记编码进 token，手工数文本字符通常会低估真实用量。
• 对代码、JSON、长数字和低资源语言，切分过碎会同时增加成本、延迟和上下文压力。

工程落地

上线前我会使用目标模型对应的 tokenizer 或官方 usage 字段统计真实 token 分布，而不是用“字数乘一个经验系数”。离线评估至少记录平均值、P50、P95 和最大值，并分别看用户输入、系统提示词、工具 schema、检索片段和输出。做模型迁移时，要重新统计 token 密度并重新检查上下文预算。

常见追问及答案

• 问：tokenizer 只是影响计费吗？ 不是，它还影响上下文容量、训练样本长度、生成速度，以及中文和代码任务的有效信息密度。
• 问：同一个汉字一定对应一个 token 吗？ 不一定。不同模型的词表和特殊编码不同，一个字可能是一个 token，也可能和相邻字符组成 token，或者被拆成多个片段。
• 问：为什么 API 自己统计的 token 和 tokenizer 工具算的不完全一致？ 可能因为 chat template、特殊 token、工具定义、系统字段或服务端版本不同。最终计费应以服务端返回的 usage 为准。

容易扣分

• 把 tokenizer 说成“按空格切词”。
• 只会背 BPE 的名字，却讲不出它如何影响 token 密度。
• 用字符数代替真实 token 数，并据此承诺成本。

Q18：一条对话请求的 token 到底怎么计费？cached tokens、cache creation tokens 和 reasoning tokens 怎么区分？

考察点

考察你是否能从 API usage 账单还原真实成本，并分清输入、缓存输入、缓存写入和推理输出之间的关系。

回答脉络

先列 usage 组成，再给公式，最后讲多轮 Agent 如何累计和审计。

详细参考答案

一次调用的总 token 通常可以拆成输入 token 和输出 token。输入侧可能继续拆成未命中缓存的 input tokens、命中缓存的 cached input tokens，以及首次写入缓存的 cache creation tokens；输出侧可能拆成用户可见 output tokens 和 reasoning tokens。不同厂商字段名称和计费规则并不完全相同，所以必须以具体模型的 pricing 和 usage schema 为准。

在一个简化且不重叠的计费模型中，可以写成：

uncached_input = input_tokens - cached_input_tokens - cache_creation_tokens

cost = uncached_input * input_price
      + cached_input_tokens * cached_input_price
      + cache_creation_tokens * cache_creation_price
      + output_tokens * output_price

如果服务商把 cache creation 视为普通输入、或者把 reasoning tokens 包含在 output_tokens 中，就不能再次相加。关键是先确认字段是否互斥，再按“每百万 token 的价格”换算：

分项成本 = token 数 / 1,000,000 * 该分项单价

Agent 的一次用户请求往往不是一次模型调用。规划、检索改写、工具决策、工具结果总结和最终回答都可能各调用一次模型，因此任务成本应该是所有 span 的分项成本之和，还要加 embedding、rerank、搜索 API、重试和失败调用成本。一个只看最终回复长度的成本统计会严重低估真实成本。

工程落地

我会在每次模型调用结束后持久化 request_id、model、input_tokens、cached_input_tokens、cache_creation_tokens、output_tokens、reasoning_tokens、单价版本、重试次数和业务 task_id。账单看板按租户、接口、模型、任务类型和成功/失败状态聚合，同时展示“每次成功任务成本”，而不仅是“每次 API 调用成本”。

常见追问及答案

• 问：total_tokens 乘一个单价对不对？ 只有输入和输出同价且没有缓存等细分时才近似成立。真实 API 通常输入、输出和缓存输入价格不同，不能直接这么算。
• 问：reasoning tokens 用户看不到，是否不收费？ 不能这样推断。很多推理模型会把它计入输出侧用量，是否收费和如何展示取决于服务商。
• 问：失败请求算不算成本？ 已经实际执行并返回 token 的调用通常仍会产生费用，重试也可能重复收费，因此要单独统计失败和重试成本。

容易扣分

• 把 cached input tokens 当成“没有消耗 token”。它仍然是输入，只是通常享受不同的计价或计算路径。
• 把 reasoning tokens 在 output tokens 之外无条件再加一次。
• 只会计算单次调用，不会计算一次 Agent 任务的累计成本。

Q19：上下文窗口具体包含哪些内容？为什么 max output tokens 不能简单理解成额外空间？

考察点

考察你对上下文预算、聊天消息序列和输出截断关系的理解。

回答脉络

从“总预算”开始，列举实际组成，再说明预算策略。

详细参考答案

上下文窗口是模型一次请求能够处理的 token 总容量。它通常包括 system/developer 指令、用户输入、历史消息、工具定义、工具调用消息、工具返回结果、检索证据，以及模型本次要生成的输出。可以用下面的预算关系理解：

system + history + user + tools + retrieved_context + output_budget
<= context_window

max output tokens 是输出上限，不是脱离上下文窗口之外的独立容量。输入已经很长时，服务端可能拒绝请求、自动截断输入，或者实际可生成的长度变短。即使没有超过硬上限，过大的输出预算也会造成资源预留、输出跑题或成本不可控。

还要注意三个边界：第一，模型厂商对上下文窗口的定义可能不同，有的把输出也算在窗口里，有的文档会分别描述最大输入和最大输出；第二，工具 schema 和多模态内容可能有额外编码成本；第三，Agent 每一轮都可能重新发送部分历史，所以“任务总 token”会远高于“当前窗口 token”。

工程落地

我会为每类请求分配预算，例如固定指令预算、历史预算、检索预算和输出预算，并在发送前估算 token。超过阈值时按优先级处理：删掉重复工具结果，压缩历史，降低检索 top-k，保留结构化状态和关键证据，最后才考虑截断用户原始问题。输出接近上限时，要识别 finish_reason，不能把不完整答案当成成功结果。

常见追问及答案

• 问：上下文窗口越大，是不是就不需要 RAG？ 不是。窗口解决一次能放多少，RAG 解决从大量外部资料中找什么、如何更新和如何引用。
• 问：输出被截断怎么发现？ 检查服务端返回的 finish reason、usage 和结构化结果是否闭合；JSON 未闭合、步骤未完成都应触发续写或降级。
• 问：能不能把历史全部摘要掉？ 不能无脑摘要。摘要可能丢失数字、条件和否定关系，关键事实应保留结构化字段或原始证据，并在评估中验证摘要损失。

容易扣分

• 认为 max output tokens 不占 context window。
• 只谈模型宣传的窗口大小，不谈工具、历史和 RAG 也会占预算。
• 不检查输出是否因为达到上限而不完整。

Q20：上下文中的“lost in the middle”是什么？怎么缓解？

考察点

考察你是否理解长上下文中的位置偏差，以及为什么“把证据放进去”不等于“模型有效使用证据”。

回答脉络

先描述现象，再讲上下文编排、检索和评估办法。

详细参考答案

“Lost in the middle”指的是：当上下文很长时，模型对开头和结尾的信息利用往往相对好，而位于中间的证据更容易被忽略。它不是每个模型、每个任务都必然出现的固定规律，但在多段文档、长对话和大量工具结果里很常见。

缓解方式不是简单地把窗口换大，而是减少无关信息并优化上下文编排：

• 先检索和 rerank，减少低相关片段。
• 把最关键的事实、约束和用户问题放在清晰的位置。
• 对证据做编号、标题和来源标注，要求结论绑定证据编号。
• 把长工具结果先结构化筛选，只回传下一步真正需要的字段。
• 对超长任务分阶段处理，让每个阶段只看当前所需上下文。

工程落地

我会做位置扰动评估：将同一条关键证据分别放在上下文开头、中间和结尾，比较答案正确率、引用命中率和无答案率。如果中间位置显著变差，就需要减少上下文长度或调整证据编排，而不是只提高 temperature 或要求模型“认真阅读”。

常见追问及答案

• 问：把重要内容重复三遍是不是最好的办法？ 一般不是。重复会增加成本和冲突风险；应先减少噪声、明确结构和做分阶段总结。
• 问：RAG 能解决这个问题吗？ 能降低无关上下文的比例，但如果 top-k 太大、证据冲突或排序不对，RAG 仍会把中间噪声送给模型。

容易扣分

• 把它解释成“模型完全看不到中间内容”。这是概率上的利用偏差，不是硬性不可见。
• 只说“增加上下文窗口”，却没有减少噪声和评估位置影响。

Q21：除了 temperature 和 top_p，还有哪些解码参数？结构化输出如何做到可控？

考察点

考察你是否能把随机生成和业务级可控输出连接起来。

回答脉络

先解释解码参数，再说明结构化输出不能只靠 prompt，最后给出不同任务的配置思路。

详细参考答案

常见解码策略和参数包括：

• Greedy decoding：每一步选最高概率 token，确定性强，但容易保守。
• Temperature：调整概率分布的尖锐程度，越低越偏向高概率候选。
• Top-p：只在累计概率达到 p 的候选集合中采样。
• Top-k：只保留概率最高的 k 个候选，部分本地推理框架常用。
• Repetition penalty / frequency penalty：抑制重复，但设置过强会损害术语和代码中的必要重复。
• Presence penalty：鼓励谈论新主题，适合部分创意生成，不适合所有事实任务。
• Stop sequence：遇到指定序列后停止，适合控制段落或协议边界。
• Seed：部分服务支持固定随机种子，但它通常只能提高可复现性，不能保证跨版本、跨硬件完全一致。

需要严格 JSON、函数参数或分类标签时，我会优先使用 JSON Schema、structured output、函数调用或语法约束解码，再配合低随机参数和业务校验。prompt 只负责说明语义和边界，不能代替 parser、schema validator、枚举校验和重试。

工程落地

分类和抽取通常固定较低随机性，并在回归测试中记录模型版本、参数和 seed。创意写作才提高随机性，并把结果多样性作为指标。对 JSON 输出，先解析再校验；解析失败时只重试一次并缩短错误反馈，连续失败则降级为人工或模板流程。

常见追问及答案

• 问：temperature=0 就绝对确定吗？ 不一定。服务端实现、并列概率、批处理、模型版本和硬件计算差异都可能导致微小变化。
• 问：top_p 和 temperature 要同时调吗？ 通常先固定一个调另一个，避免无法判断效果。具体仍要以模型服务支持和评估结果为准。
• 问：beam search 为什么在聊天模型里不常用？ 它计算开销更高，且可能产生重复、保守文本；开放式对话通常更依赖采样或约束解码。

容易扣分

• 把 temperature 当成“准确率开关”。
• 认为固定 seed 就能保证完全一致。
• 用“请输出合法 JSON”代替结构化协议和业务校验。

六、Embedding 的边界与模型选择

Q22：embedding 能做什么，不能做什么？它和生成模型的边界在哪里？

考察点

考察你是否知道向量表示适合相似性计算，不是万能的知识库、推理器或事实验证器。

回答脉络

先讲输入输出和常见任务，再讲不能替代的能力，最后讲系统如何组合。

详细参考答案

Embedding 模型把对象映射为向量，使系统可以用相似度近似“语义相关”。常见用途有语义检索、聚类、去重、推荐、相似问匹配、异常检测和分类前的特征表示。

它不能直接保证以下事情：

• 不能保证返回最新事实。
• 不能替代精确关键词、数字、日期、ID 和权限过滤。
• 不能仅凭距离完成复杂逻辑推理或多条件比较。
• 不能保证两个近邻文本在业务上等价，尤其是“可以”和“不可以”这类否定条件。
• 不能自动生成最终答案，通常还需要生成模型或业务代码。

因此 RAG 里更合理的分工是：embedding 做候选召回，关键词和 metadata 做精确约束，reranker 做更细的相关性排序，生成模型基于证据组织回答，业务代码负责权限和事实校验。

工程落地

我会把向量相似度当成召回信号，而不是最终判定。对订单号、政策版本、时间范围、租户 ID 等条件先做结构化过滤；对 top-k 结果记录相似度分布和人工相关性，必要时设置拒答阈值和 rerank。

常见追问及答案

• 问：相似度最高的文档就是正确答案吗？ 不是。它只是当前向量空间中最相似的候选，仍需看关键词、时间、权限、版本和内容是否真的回答了问题。
• 问：embedding 能理解否定吗？ 有一定能力，但不能假设稳定。涉及合同、权限、金额和条件否定时必须保留原文并做验证。

容易扣分

• 把 embedding 说成文本压缩或数据库索引本身。
• 认为向量距离高就代表答案一定正确。

Q23：为什么 query embedding 和 document embedding 有时需要不同的提示前缀？

考察点

考察对双塔检索模型训练目标和输入约定的理解。

回答脉络

先说明 query/document 的角色不同，再讲遵循模型训练格式的重要性。

详细参考答案

检索模型通常分别把“用户正在寻找什么”和“文档能够提供什么”编码成向量。某些 E5 类模型会要求使用类似 query: 和 passage: 的前缀，原因是训练时模型已经学习了这种角色信息，前缀能帮助它区分查询和文档。另一些模型可能不需要前缀，或者规定了不同的 instruction。

如果把一个模型要求的前缀省略、写错或 query/document 两边用法不一致，向量空间的分布可能改变，召回质量会下降。不是所有模型都要照抄同一套前缀，正确做法是看目标模型的输入约定，并用业务数据验证。

工程落地

我会把 embedding 模型名称、版本、预处理模板、是否归一化、距离度量和维度写进索引元数据。离线重建索引时先跑固定评估集，确认 query 与 document 的编码方式一致，再逐步切换线上流量。

常见追问及答案

• 问：为什么查询和文档必须用同一个 embedding 模型？ 因为相似度计算默认它们在同一向量空间；换模型会改变坐标含义，不能直接混用。
• 问：能不能只给新增文档换更好的模型？ 通常不行。新旧向量不在同一空间，应该建立新索引并通过双写、双检索或离线对比切换。

容易扣分

• 认为所有 embedding 模型都必须加 query:。
• 只记录维度，不记录模型版本和预处理配置。

Q24：什么时候用关键词检索、向量检索、混合检索或 rerank？

考察点

考察你能否根据查询类型选择检索链路，而不是把向量检索当成唯一答案。

回答脉络

按查询特征说明四种组件的职责，最后给组合方案。

详细参考答案

• 关键词/BM25 适合错误码、SKU、合同编号、函数名、专有名词等必须命中的词。
• 向量检索 适合表达变化大但语义相近的问题，例如用户口语和制度标题不一致。
• 混合检索 同时利用 lexical 和 semantic 信号，适合企业知识库这种既有自然语言又有编号术语的场景。
• Rerank 通常在初步召回后对几十条候选做更精细的 query-document 相关性判断，用更高计算成本换排序质量。

一个常见链路是：metadata 过滤 -> BM25 和向量并行召回 -> 合并去重 -> rerank -> 证据裁剪 -> 生成。对强实时、低延迟接口可以减少 rerank 或使用轻量模型；对高价值问答则可以接受更高延迟换取更好的证据排序。

工程落地

评估时分别记录 BM25 recall@k、向量 recall@k、混合 recall@k、rerank 后 MRR/nDCG 和最终答案准确率。不要只看最终回答，因为最终错误可能来自召回、排序、上下文拼接或生成中的任一环节。

常见追问及答案

• 问：向量检索效果不好，是不是换更大 embedding 就够了？ 不一定。先检查切分、元数据过滤、查询改写、语料质量和评估集；检索链路问题可能比模型维度更关键。
• 问：rerank 为什么不一开始就对全库做？ Cross-encoder 类 rerank 通常需要同时阅读 query 和候选文档，计算成本高，先召回一小批候选更经济。

容易扣分

• 只会说“向量检索比关键词高级”。
• 不知道召回和 rerank 是两个不同阶段。

Q25：训练、微调、RAG 和提示词工程怎么选？

考察点

考察你能否根据问题来源选择解决方案，避免“遇到问题就微调”。

回答脉络

先判断问题是知识、行为、能力还是流程问题，再给决策顺序。

详细参考答案

我会先判断问题来源：

问题	优先方案	原因
知识经常变化、需要引用和权限	RAG/工具	外部数据可更新、可追溯
输出格式、语气、固定流程不稳定	Prompt、structured output、少量 SFT	解决行为和格式问题
领域术语、任务模式长期稳定且有标注数据	SFT/LoRA	让模型形成稳定任务习惯
需要改变偏好排序，例如更重视简洁或拒绝越权	DPO 等偏好优化	学习成对偏好，而不只是模仿答案
模型本身不会某种复杂能力	换模型、工具或专门程序	微调不一定凭空创造可靠能力
业务流程、权限、计算和实时状态	代码与工具	这些需要确定性执行

通常的顺序是先改 prompt 和上下文，再补 RAG/工具，建立评估集后再判断是否需要微调。微调不能替代实时检索，也不能替代权限控制；把不断变化的业务知识硬写进参数，会增加更新和审计成本。

工程落地

我会用同一套离线集比较 baseline、prompt、RAG、LoRA 版本，并拆分知识正确率、格式遵循、工具选择、拒答和成本指标。只有当问题在大量稳定样本上表现为“行为模式学不会”，且有足够高质量数据时，才进入微调。

常见追问及答案

• 问：RAG 效果不好，为什么不直接 SFT？ 先确认是召回问题还是行为问题。若模型根本没拿到正确证据，SFT 不能稳定替代实时检索；应该先修召回和上下文。
• 问：微调后还要 RAG 吗？ 很多生产系统仍需要。微调负责行为和格式，RAG 负责外部、最新、可引用知识，两者可以组合。

容易扣分

• 看到领域知识就建议把知识全部灌进模型。
• 把微调当成解决幻觉、权限和实时性的万能方案。

Q26：如何判断一个模型是否适合做工具调用和结构化输出？

考察点

考察模型选型是否超越“参数量”和公开榜单，能否贴近业务协议。

回答脉络

从能力、协议遵循、失败恢复和运营指标四层评估。

详细参考答案

工具型模型至少要评估：

• 能否在需要时选择正确工具，以及不需要时保持不调用。
• 参数名、类型、枚举、嵌套结构是否稳定。
• 多工具调用能否表达依赖关系，是否会重复调用或漏调用。
• 工具失败后能否根据结构化错误修正，而不是编造成功。
• 是否支持可靠的 JSON Schema、函数调用、流式事件和停止原因。
• 在中文、代码、长上下文和高并发下，延迟、成本和稳定性是否可接受。

我会构造包含正常样本、边界参数、缺失信息、权限拒绝、工具超时、重复请求和恶意输入的评估集。工具调用成功率不能只看 JSON 是否合法，还要看工具是否选对、参数是否业务正确，以及最终任务是否完成。

工程落地

线上为每次 tool call 记录模型选择、参数校验结果、工具耗时、错误码、重试次数和最终任务状态。模型切换时先做 shadow traffic 或小比例灰度，确认工具选择和高风险动作指标没有回退。

常见追问及答案

• 问：参数格式正确是不是就算工具调用成功？ 不是。格式正确只代表解析成功，业务 ID、权限、范围和动作语义仍需校验。
• 问：模型榜单高就一定适合工具调用吗？ 不一定。通用推理榜单和工具协议遵循是不同能力，必须用目标工具集评估。

容易扣分

• 只看模型大小或公开 benchmark。
• 把 JSON 合法率当成任务成功率。

七、缓存、可复现性与成本控制

Q27：Prompt Caching 的命中条件是什么？如何提高 token 缓存命中率？

考察点

考察你能否从请求组织方式解释缓存，而不是把缓存命中归因于“语义相似”。

回答脉络

先讲缓存的是稳定前缀，再讲如何组织消息和工具定义，最后讲如何验证。

详细参考答案

Prompt Caching 通常复用多次请求中完全相同或满足服务商规则的 prompt 前缀计算。它不是向量缓存，不是“意思差不多就命中”，也不是把最终答案永久保存。服务端可能按 token 前缀、模型、租户、区域、版本和 TTL 维护缓存，具体命中阈值和价格以厂商规则为准。

提高命中率的核心是让前缀稳定：

1. 把版本固定的 system/developer 指令放在最前面。
2. 工具定义、schema 和工具顺序保持稳定。
3. 把长期不变的 few-shot、公共规则和文档前缀放在前面。
4. 把用户问题、时间戳、随机 request id、实时状态和本轮工具结果放在后面。
5. 不要每次动态拼接或排序 system prompt，避免前面一个字符变化导致后缀全部失效。
6. 通过版本号管理 prompt，修改稳定前缀时接受缓存自然失效。

缓存命中不应以“感觉变快”为准，而要检查 usage 中的 cached input 字段、命中率、命中 token 数、P50/P95 延迟和成本下降。缓存还有 TTL、容量淘汰和最小前缀长度等现实约束，不能把理论命中率当成账单承诺。

工程落地

我会把 prompt 拆成 stable_prefix 和 dynamic_suffix 两部分，在 trace 中记录 prefix hash、版本、输入 token、cached token 和请求延迟。发布 prompt 新版本时单独观察缓存命中率，避免把动态用户内容错误地放进共享缓存前缀，造成隐私或隔离风险。

常见追问及答案

• 问：把两段相似文档放进缓存会命中吗？ 通常不会。Prompt Caching 主要依赖精确前缀一致，不是语义相似匹配。
• 问：缓存命中就一定省钱吗？ 不一定。要看服务商是否对 cached input 使用更低价格，以及缓存命中是否带来额外存储或写入费用。
• 问：KV Cache 能由应用层直接跨请求复用吗？ 通常不能直接当作 API 层 prompt cache 使用，两者由不同层负责，生命周期和接口也不同。

容易扣分

• 把 prompt cache 说成 Redis 答案缓存。
• 把“相似 prompt”当成命中条件。
• 把动态内容放在稳定前缀前面，却还期待高命中率。

Q28：除了缓存，如何系统性降低 LLM 成本？如何防止优化把质量打坏？

考察点

考察你是否能把成本优化拆成输入、输出、模型、调用次数和基础设施，而不是只建议“换便宜模型”。

回答脉络

先拆成本构成，再给优化杠杆，最后讲质量护栏。

详细参考答案

成本优化可以分五层：

• 减少输入：裁剪历史、压缩工具结果、降低无效 top-k、去除重复 system prompt、使用结构化状态替代冗长叙述。
• 减少输出：设置合理的 max output tokens、使用结构化字段、明确回答长度和终止条件，避免无意义长解释。
• 减少调用次数：能用代码完成的判断不调用模型，独立工具并行，合并可以合并的步骤，避免失败重试造成倍增。
• 模型路由：分类、抽取和简单改写使用小模型，复杂推理才使用大模型；必要时设置升级和回退条件。
• 复用计算：使用 prompt cache、检索结果缓存、embedding 批处理、离线预计算和批量推理。

优化必须由评估集守住质量。我的做法是先建立按任务类型分层的质量基线，再一次只改变一个成本杠杆，比较任务成功率、事实正确率、工具成功率、P95 延迟和单成功任务成本。不能只看单请求 token 下降，因为如果小模型导致重试更多，整体成本可能反而上升。

工程落地

给每个租户、接口和任务设置预算和熔断阈值：单次最大 token、单任务最大模型调用次数、单日预算和超预算降级策略。成本异常时通过 trace 定位是输入膨胀、输出失控、缓存失效、路由错误还是重试风暴。

常见追问及答案

• 问：把 temperature 调低能省 token 吗？ 不一定。它可能减少发散，但 token 数主要由输出内容和上限决定，不能把它当成本控制开关。
• 问：压缩上下文会不会损失事实？ 会有风险，所以要保留关键约束、数字、否定和来源，并对摘要后的任务成功率做回归。
• 问：用小模型失败后再升级，是否一定比直接大模型便宜？ 不一定，要计算小模型调用、失败重试和大模型升级的总成本，并用真实成功率验证。

容易扣分

• 只提“换便宜模型”，不谈质量、重试和成功任务成本。
• 把 token 减少当成业务成本一定减少。
• 没有预算、限流和异常监控方案。

Q29：如何判断一次生成结果“不确定”？logprobs 能代表模型置信度吗？

考察点

考察你是否能区分概率信号、事实可信度和业务风险。

回答脉络

先讲 token 概率的局限，再讲多信号判断和高风险兜底。

详细参考答案

logprobs 反映模型在生成某些 token 时的相对概率，但它不等于事实正确率，也不等于经过校准的置信度。模型可能以很高概率生成一个听起来合理但事实错误的答案，尤其是上下文缺证据时。因此不能简单设置“平均 logprob 高就自动通过”。

更可靠的做法是组合信号：是否检索到高质量证据、答案是否能被证据蕴含、多个候选是否一致、结构化校验是否通过、工具返回是否明确、问题是否属于高风险领域，以及模型自身的不确定表达。对金融、医疗、权限和写操作，应该优先依赖确定性数据源和人工确认。

工程落地

我会为系统定义三种结果：自动通过、需要补充信息/再次检索、转人工或拒答。阈值不直接从理论推导，而是在带标签的验证集上校准，并持续观察线上误放行和误拒答。trace 中记录证据质量、校验结果和最终决策，便于复盘。

常见追问及答案

• 问：多次采样答案一致是不是就正确？ 一致只能说明生成稳定，不能证明事实正确；如果共享了同一个错误先验，多个答案仍可能一起错。
• 问：有引用就代表可信？ 不代表。要检查引用是否真的支持结论、版本是否有效、是否越权使用了不应见到的资料。

容易扣分

• 把模型概率直接当事实置信度。
• 只靠“让模型自我检查”作为高风险场景的唯一保障。

Q30：常见的向量数据库有哪些？选型时看什么？

考察点

考察你是否知道向量数据库不只是“能存向量”，还涉及过滤、索引、更新、可运维性和生态。

回答脉络

先按产品形态分类，再讲选型维度，最后说明如何避免被产品名带偏。

详细参考答案

常见向量数据库或向量检索方案包括：

• Milvus：开源向量数据库，适合较大规模向量检索和独立部署。
• Zilliz Cloud：Milvus 的托管服务，减少基础设施运维。
• pgvector：PostgreSQL 扩展，适合已有关系型数据库、数据规模中等且希望事务与向量一起管理的团队。
• Weaviate：提供向量检索、过滤和较完整的应用层能力。
• Qdrant：开源向量数据库，过滤和开发体验较好，适合独立服务或云部署。
• Pinecone：托管向量数据库，接入简单，适合不希望自己维护集群的场景。
• Elasticsearch/OpenSearch：在已有全文检索体系中增加向量能力，适合混合检索和运维体系已经成熟的团队。
• FAISS：检索库而不是完整的数据库服务，适合离线实验、单机索引和原型验证，需要自己补持久化、过滤、权限和高可用。

选型时我会看向量规模和增长速度、写入与更新频率、过滤条件、混合检索、索引类型、查询延迟、集群扩展、备份恢复、租户隔离、权限、安全合规、云成本和团队运维能力。对企业 RAG，metadata 过滤和文档版本管理往往和纯向量召回同样重要。

工程落地

先建立与产品无关的检索接口，例如 query、top_k、metadata_filter、namespace 和 score，再用真实语料做基准测试。迁移数据库时验证向量距离、过滤语义、删除与更新的一致性、备份恢复和冷启动，而不是只比较一个 top-k 结果。

常见追问及答案

• 问：PostgreSQL 加 pgvector 能替代所有向量数据库吗？ 不一定。它很适合已有 PostgreSQL 和中等规模场景，但超大规模、高吞吐或专门索引能力可能需要独立向量服务。
• 问：FAISS 能直接上生产吗？ 可以作为检索组件，但持久化、并发、权限、更新、分片、监控和高可用都需要应用自己补齐。
• 问：向量数据库会自动解决 RAG 效果吗？ 不会。切分、embedding、查询改写、过滤、rerank 和生成仍然决定大部分效果。

容易扣分

• 只背产品名字，不会按规模和约束选型。
• 把 FAISS、向量数据库和全文搜索引擎当成完全相同的东西。

Q31：HNSW、IVF 和 PQ 是什么？向量索引的召回率和速度如何取舍？

考察点

考察你是否理解近似最近邻索引为什么能加速，以及索引参数如何影响召回、内存和延迟。

回答脉络

先说明 ANN 的必要性，再分别介绍 HNSW、IVF、PQ，最后讲线上调参方法。

详细参考答案

如果每次查询都把 query 和全库每个向量计算距离，数据量大时成本接近线性扫描，因此向量数据库常使用 ANN，也就是近似最近邻索引，在可接受的召回损失下减少比较数量。

• HNSW：把向量组织成多层近邻图，查询时从高层快速接近目标，再在低层精细搜索。常见参数包括构图连接数和查询时搜索范围；搜索范围越大，召回通常越高，但延迟和 CPU 消耗也会上升。
• IVF：先训练聚类中心，把向量分到不同倒排桶，查询时只搜索最相关的若干桶。搜索桶数越多，召回越高但计算越多；桶数量和数据分布会影响构建与查询。
• PQ（Product Quantization）：把向量分段并用较短编码近似存储，显著节省内存和磁盘，但会引入量化误差，常与 IVF 组合。

小规模数据可以使用精确搜索作为基线；数据增长后再选择 ANN。调参不能只看单次查询速度，我会同时观察 recall@k、P95 延迟、索引内存、构建时间、更新成本和过滤后的有效召回。不同数据集、向量维度和过滤条件下最优参数可能不同。

工程落地

上线前用人工标注的相关文档集建立 exact search 基线，再测试不同索引参数的召回损失。新索引构建完成后进行 shadow query 或双读比较，确认版本切换、增量写入、删除和重启恢复没有改变结果分布。

常见追问及答案

• 问：HNSW 一定比 IVF 快吗？ 不一定。它们对数据规模、内存、更新方式、过滤条件和硬件的敏感性不同，必须基准测试。
• 问：PQ 只是压缩存储吗？ 主要用于压缩向量和降低距离计算成本，但近似误差可能降低召回，常需要 rerank 补回精度。
• 问：为什么线上召回比离线低？ 可能使用了 ANN、metadata 过滤、索引未更新、分片不均或 query 预处理不一致，不能只看 embedding 模型。

容易扣分

• 把 ANN 说成“完全精确的最近邻”。
• 只谈 QPS，不谈召回损失和 P95。

高频追问汇总

追问 1：大模型是不是数据库？

不是。模型参数里有训练阶段学到的统计规律和知识，但它不会像数据库一样保证事实最新、精确和可查询。需要最新事实、强一致状态、权限数据时，应该调用工具或数据库。

追问 2：为什么模型有时连简单数学都算错？

因为它不是按传统程序一步步执行算术，而是在生成文本。简单题可能学会了模式，复杂精确计算仍可能出错。工程上应把计算交给 calculator、代码或数据库聚合。

追问 3：为什么同一个 prompt 换模型后效果变了？

不同模型的训练数据、指令遵循能力、工具调用能力、上下文长度、tokenizer 和安全策略都可能不同。上线前要做回归评估，不能假设 prompt 能无缝迁移。

追问 4：模型越大一定越好吗？

不一定。大模型通常能力更强，但成本和延迟更高。分类、抽取、简单路由可以用小模型；复杂推理、长上下文、多工具任务再考虑更强模型。最终看任务成功率、成本、延迟和稳定性。

本节常见扣分点

• 把 token 说成固定的字或词。
• 把长上下文当成万能方案。
• 把 embedding 说成“压缩文本”，但讲不出向量相似度。
• 不知道聚类是无监督分组。
• 把 Prompt Caching 和 KV Cache 混为一谈。
• 一谈成本就只说 total_tokens * 单价。
• 把幻觉归因成“模型偶尔抽风”，不讲证据、工具和评估。