为什么同一个问题有时答得很好，有时答得很差
1️⃣ 考察意图
面试官想考察你对 LLM 输出不稳定性的系统性理解，而非简单归因于“随机性”。这是典型的工程取舍 + debug 类问题，刁钻点在于：候选人往往只想到解码参数（如 temperature），却忽略输入敏感性、模型状态、系统环境等更隐蔽的根源。答好了能展示你从算法到工程的完整流程能力——不仅知道“为什么”，还能给出可落地的稳定性保障方案，比如确定性解码、prompt 模板化、A/B 测试框架。
2️⃣ 标准答
这个问题本质是 LLM 推理的非确定性叠加输入敏感性导致的。从四个层面拆解：
1. 解码策略的随机性
- 核心来源：temperature、top-p、top-k 采样。temperature > 0 时，softmax 输出概率分布被缩放，采样引入随机性；top-p 截断累积概率后随机选 token，进一步放大波动。
- 工程取舍：temperature=0 并不绝对确定——如果模型使用 dropout（如训练时未冻结的推理 dropout），或 beam search 中 beam 间分数相同，仍可能产生不同结果。实际落地中，设置 temperature=0 + 固定随机种子（如 seed=42）+ 禁用 dropout 才能达到 99%+ 可复现性。
- 坑：API 调用时，许多服务（如 OpenAI）默认 temperature=1，且不暴露种子控制。解法：本地部署模型，或使用 vLLM 等推理框架的
--seed参数强制确定性解码。
2. 输入敏感性
- Prompt 措辞：同义改写（如“解释一下” vs “请说明”）会改变 token 序列，导致 attention 分布偏移。实验显示，BERTScore 在 prompt 微调后下降 5-10%。
- 上下文长度：长上下文下，RoPE 位置编码的衰减效应导致尾部 token 注意力权重降低。例如，8K 上下文时，前 2K token 的注意力分数比后 6K 高 30%+，导致对同一问题在不同位置回答质量波动。
- 示例顺序：few-shot 中示例排列顺序影响模型对模式的提取。论文《The Power of Scale》证明，改变示例顺序可导致准确率波动 10-20%。
- 解法：使用模板化 prompt（如 Jinja2 模板），固定示例顺序和措辞；对长上下文，用滑动窗口或分块检索（如 RAG 中的 chunking 策略）控制输入长度。
3. 模型状态与推理机制
- KV cache：推理时 KV cache 的缓存策略影响结果。例如，FlashAttention 的块大小不同会导致浮点运算顺序差异，产生微小数值误差，累积后改变采样结果。
- 量化误差：INT8/FP4 量化后，相同输入在不同 batch 或硬件上可能因量化 scale 计算顺序不同产生差异。实测显示，FP16 推理的确定性比 INT8 高 2-3 个数量级。
- 解法：使用确定性 FlashAttention（如 vLLM 的
--enforce-eager模式），或禁用 kernel fusion 以牺牲性能换取可复现性。
4. 系统与环境因素
- API 负载：高并发下，负载均衡可能将请求路由到不同模型副本（如不同 GPU 或不同版本），导致输出差异。例如，字节跳动内部测试显示，同一 prompt 在 100 次 API 调用中，有 15% 因路由到不同副本而结果不同。
- 版本差异：模型更新（如从 GPT-4-0613 到 GPT-4-1106）可能改变行为。OpenAI 官方文档承认，即使相同参数，不同版本输出可能不同。
- 解法：固定模型版本（如使用
gpt-4-0613而非gpt-4），或自建推理服务；对 API 调用，增加重试机制和一致性校验（如编辑距离阈值）。
总结：稳定性问题不是单一原因，而是解码随机性、输入敏感性、模型状态、系统环境四层叠加。工程上，通过固定种子 + 温度=0 + 模板化 prompt + 确定性推理 + 版本锁定，可将同一问题的答案一致性从 60% 提升到 95%+。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从四个层面回答：第一，解码策略的随机性，比如 temperature 和 top-p 采样；第二，输入敏感性，包括 prompt 措辞、上下文长度和示例顺序；第三，模型状态，如 KV cache 和量化误差；第四，系统环境，比如 API 负载和版本差异。总结一句：稳定性是算法、输入、模型、系统四层叠加的结果，工程上通过固定种子、温度=0、模板化 prompt 和确定性推理来缓解。”
4️⃣ 高频追问 & 应对
追问 1：你提到 temperature=0 不能保证绝对确定，那实际中怎么做到 100% 可复现？
100% 可复现在当前硬件和框架下几乎不可能，因为浮点运算的 non-associativity（如 FlashAttention 的块大小不同导致加法顺序不同）会引入微误差。工程上，我们追求 99.9% 可复现：设置 temperature=0、seed=42、禁用 dropout、使用确定性 CUDA 内核（如 PyTorch 的
torch.use_deterministic_algorithms(True)），并固定 batch size 和硬件拓扑。如果仍需要绝对一致，可以后处理：对输出做哈希校验，不一致时重试。
追问 2：如果用户反馈同一个问题在不同时间回答质量差异很大，你怎么排查？
第一步，检查 API 参数：是否固定了 temperature 和 seed？第二步，对比 prompt 是否被用户或系统修改（如自动添加的上下文）。第三步，查看模型版本和推理框架版本是否一致。第四步，做 A/B 测试：对同一 prompt 重复 100 次，计算编辑距离和语义相似度（如 BERTScore）。如果波动 > 10%，优先排查解码参数和 prompt 模板；如果波动 < 5%，可能是系统负载导致的 KV cache 差异。实际案例中，字节跳动团队曾发现是负载均衡将请求路由到不同 GPU 型号（A100 vs H100）导致输出差异，解法是绑定 GPU 类型。
追问 3：在 RAG 系统中，检索结果不稳定也会导致回答波动，你怎么处理？
是的，RAG 的稳定性是双重挑战。检索层：使用确定性检索（如 BM25 固定参数，或 embedding 模型固定 batch size），并缓存检索结果（如 Redis 缓存 query 和 top-k 文档的哈希）。生成层：将检索结果按固定顺序拼接到 prompt，并设置 temperature=0。如果检索结果本身有噪声（如不同 chunk 策略），可以增加 reranker（如 Cohere rerank）来过滤低质量文档。实测显示，这种方案可将 RAG 回答一致性从 50% 提升到 85%+。
5️⃣ 避坑 · 常见错误答法
- ❌ 只回答“因为 temperature 不为 0，所以有随机性” → ✅ 需要扩展到输入敏感性、模型状态、系统环境，并给出具体工程解法（如固定种子、模板化 prompt）。
- ❌ 说“设置 temperature=0 就完全解决了” → ✅ 指出 temperature=0 仍可能因 dropout、浮点误差、KV cache 等导致波动，并给出确定性推理方案。
- ❌ 把稳定性问题归因于“模型能力不足” → ✅ 强调这是推理非确定性 + 输入敏感性的工程问题，而非模型能力问题，并给出可复现的测试框架。
6️⃣ 简历呼应
- 如果你有 RAG 项目：从检索稳定性切入，展示你如何通过缓存检索结果、固定 chunk 策略、使用 reranker 来提升回答一致性，并给出具体指标（如编辑距离降低 30%）。
- 如果你只做过传统 NLP：用传统 NLP 的确定性推理（如 beam search 固定 beam 数）类比 LLM 的稳定性问题，强调从“概率模型”到“确定性工程”的迁移思路，并提及你如何用 PyTorch 的
deterministic模式复现结果。 - 如果你是校招无项目：聚焦论文复现 demo，比如复现《The Power of Scale》中示例顺序影响准确率的实验，并设计一个稳定性测试脚本（重复 100 次 + 计算 BERTScore），展示你对问题的系统化理解。
- 《The Power of Scale for Parameter-Efficient Prompt Tuning》—— 示例顺序对 few-shot 性能的影响
- 《FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness》—— 确定性 FlashAttention 的实现细节
- vLLM 官方文档：
--seed参数和--enforce-eager模式的使用 - PyTorch 文档：
torch.use_deterministic_algorithms和torch.backends.cudnn.deterministic - 《RAG 系统稳定性最佳实践》—— 字节跳动技术博客（内部资料，可搜索类似公开文章）