什么场景适合用 LLM，什么场景不适合

1️⃣ 考察意图

面试官想看的不是你能背出 LLM 的优缺点，而是你能否在真实业务中做出有依据的工程决策。这是一道典型的系统设计 + 边界判断题，刁钻点在于：很多人会给出“LLM 适合文本生成，不适合数学计算”这种教科书式回答，但面试官真正关心的是——当任务边界模糊时（比如客服场景中既有开放对话又有固定流程），你如何设计混合架构？ 答好了能展示你对 LLM 概率本质、成本模型、延迟约束的深度理解，以及从“能用”到“好用”的工程取舍能力。

2️⃣ 标准答

适合场景：LLM 的甜蜜区

开放域语义理解与生成：如客服对话、创意写作、文本摘要。LLM 基于 Transformer 的注意力机制能捕捉长程依赖，适合没有固定 schema 的任务。实际落地坑：客服场景中，LLM 容易“过度共情”导致偏离业务目标（如主动给折扣）。解法：在 prompt 中嵌入系统级约束（如“禁止主动提供优惠”），并配合输出校验（正则匹配关键词）。
代码生成与解释：如 GitHub Copilot、代码 review。LLM 能理解自然语言描述并生成多语言代码，但工程取舍：生成代码的准确率在 60-80%（基于 HumanEval 基准），不能直接用于生产。解法：结合静态分析工具（如 ESLint、PyLint）做后处理过滤，或使用 RAG 检索项目内已有代码片段作为上下文。
多模态理解：如图文问答、文档解析。LLM 配合视觉编码器（如 CLIP）能处理非结构化数据，但成本 trade-off：调用 GPT-4V 的 API 成本是纯文本的 3-5 倍，且延迟增加 2-3 倍。解法：先用轻量模型（如 YOLO）做目标检测过滤，只对关键区域调用 LLM。

不适合场景：LLM 的禁区

高精度数值计算与确定性规则：如金融交易计算、税务申报。LLM 本质是概率模型，输出有随机性，且对数字的 tokenization 不敏感（“123456”可能被切分成多个 token 导致计算错误）。实际落地坑：某公司用 LLM 做发票金额合计，发现 5% 的案例有 1-2 元误差。解法：改用符号计算引擎（如 SymPy）或硬编码规则，LLM 只做字段提取。
实时低延迟推理：如广告实时竞价、自动驾驶决策。LLM 推理延迟通常在 500ms-2s（基于 7B 模型 + 单卡 A100），远高于传统规则引擎的 10ms。工程取舍：若必须用 LLM，可考虑蒸馏模型（如 TinyLlama）或量化（INT4），但会牺牲 10-20% 的准确率。更优方案：用传统 ML 模型（如 XGBoost）做第一层过滤，LLM 只处理边缘 case。
隐私敏感数据处理：如医疗病历、金融交易记录。LLM 的训练数据可能包含敏感信息，且 API 调用时数据会传输到云端。解法：使用本地部署的开源模型（如 Llama 3 8B），配合差分隐私（DP-SGD）训练，或采用联邦学习架构。但注意：本地部署的模型能力通常比云端 API 弱 20-30%（基于 MMLU 基准）。
需要严格逻辑链的推理：如法律合同审核、医疗诊断。LLM 的推理过程不可解释，且容易产生“幻觉”（如编造法律条款）。实际落地坑：某律所用 GPT-4 审核合同，发现 15% 的案例中 LLM 遗漏了关键条款。解法：引入 Chain-of-Thought（CoT）提示 + 外部知识库（如法律数据库）做验证，或使用专门训练的模型（如 Legal-BERT）。

决策框架：三步判断法

任务是否依赖语义理解？ 是 → 考虑 LLM；否 → 用规则引擎或传统 ML。
是否容忍 5-10% 的错误率？ 是 → LLM 可接受；否 → 需要混合架构（LLM + 规则校验）。
延迟要求是否 < 100ms？ 是 → 用蒸馏模型或传统方法；否 → 可用全量 LLM。

3️⃣ 答题模板（30 秒电梯版）

“这个问题我从三个层面回答：第一，LLM 适合开放域语义理解、代码生成、多模态理解等场景，因为其概率模型能处理非结构化数据，但需要配合输出校验和成本控制；第二，不适合高精度计算、实时低延迟、隐私敏感和严格逻辑推理场景，因为存在幻觉、不可解释性和高延迟；第三，给出一个决策框架：看任务是否依赖语义、是否容忍错误、延迟要求如何。总结一句：LLM 是强大的辅助工具，但永远不要让它做唯一决策引擎。”

4️⃣ 高频追问 & 应对

追问 1：你说 LLM 不适合高精度计算，那如果业务必须用 LLM 做财务对账，你怎么设计系统？

我会采用混合架构：第一层用 LLM（如 GPT-4）提取发票中的字段（金额、日期、供应商），输出为结构化 JSON；第二层用符号计算引擎（如 SymPy）做数值校验和合计；第三层用规则引擎（如 Drools）做业务逻辑验证（如金额是否超过预算）。关键点：LLM 只做非结构化到结构化的转换，不参与任何数值计算。实际落地时，需要设计 fallback 机制：如果 LLM 提取的字段置信度低于 0.8（基于 logprobs），则转人工处理。

追问 2：你提到 LLM 有幻觉问题，那在客服场景中如何降低幻觉率？

三个方法：第一，RAG（检索增强生成），从知识库中检索相关文档作为上下文，限制 LLM 只能基于检索结果回答，幻觉率可降低 30-50%（基于 KILT 基准）。第二，输出校验，对 LLM 生成的回答做实体识别（如 NER），与知识库中的事实做交叉验证，不一致时拒绝回答。第三，温度参数调低，将 temperature 设为 0.1-0.2，减少随机性。但注意：温度过低会导致回答重复或过于保守，需要根据业务场景做 trade-off。

追问 3：如果业务要求延迟 < 50ms，但任务需要语义理解，你怎么选？

这种情况下全量 LLM 不可行。我会考虑两个方案：方案一，用蒸馏模型（如 DistilBERT 或 TinyLlama），推理延迟可降到 20-50ms（基于单卡 T4），但准确率会下降 10-15%。方案二，用传统 ML 模型（如 FastText + XGBoost）做分类或匹配，延迟 < 10ms，但只能处理固定类别。实际落地时，我会先用传统 ML 模型处理 80% 的高频请求，剩下的 20% 边缘 case 再路由到蒸馏模型，这样整体延迟可控制在 30ms 以内，同时保持 90% 以上的语义理解能力。

5️⃣ 避坑 · 常见错误答法

❌ “LLM 适合所有文本任务，不适合数学计算。” → ✅ “LLM 适合开放域语义理解，但即使是文本任务，如果对格式有严格要求（如生成固定模板的报表），也需要配合规则引擎做后处理。”
❌ “LLM 不适合实时场景，所以不能用。” → ✅ “LLM 不适合毫秒级实时场景，但可以通过蒸馏、量化、混合架构（传统 ML + LLM）来满足亚秒级延迟要求，关键是要做延迟和准确率的 trade-off。”
❌ “LLM 有幻觉，所以不能用于医疗领域。” → ✅ “LLM 不能直接用于医疗诊断，但可以作为辅助工具做病历摘要或文献检索，前提是配合外部知识库和人工审核，形成人机协作完整流程。”

6️⃣ 简历呼应

如果你有 RAG 项目：从“LLM 适合开放域问答，但需要 RAG 解决知识更新和幻觉问题”切入，结合你的项目经验（如检索召回率提升 20%），展示对 LLM 边界的实际理解。
如果你只做过传统 NLP：用“传统 NLP 模型（如 BERT）适合分类和序列标注，LLM 适合生成和开放域理解”做类比迁移，强调你理解两种技术的适用边界，并举例说明如何用传统模型处理 LLM 不擅长的任务（如高精度实体抽取）。
如果你是校招无项目：聚焦“LLM 的决策框架”和“混合架构”的论文复现 demo，比如用 LangChain 搭建一个客服系统，展示你如何用规则引擎处理高频请求、用 LLM 处理复杂问题，并给出延迟和准确率的对比数据。
《RAG vs Fine-tuning: When to Use Which》—— 理解 LLM 在知识密集型任务中的边界
《Chain-of-Thought Prompting Elicits Reasoning in Large Language Models》—— 了解 CoT 如何提升逻辑推理能力
《The Cost of Intelligence: A Cost-Benefit Analysis of LLM Deployment》—— 分析 LLM 的成本模型和工程取舍
《TinyLlama: An Open-Source Small Language Model》—— 蒸馏模型在低延迟场景的应用
《Differential Privacy for Language Models》—— 隐私敏感场景的解决方案

—— 本场面试完 ——