本文详细梳理了18道LLM（大语言模型）核心面试题，内容涵盖Transformer原理、Prompt工程、RAG集成、成本控制、安全防护、系统优化等关键知识点。每道题都提供了详尽的参考答案与延伸追问，旨在帮助读者系统掌握LLM技术栈。从理解Transformer的核心组件和工作原理，到掌握BERT与GPT的区别、大模型的涌现能力，再到解决幻觉问题、优化应用架构、设计缓存策略、处理长文本输入等实际应用场景，本文全面覆盖了LLM面试中的重点和难点。此外，还探讨了流式输出实现、错误处理与降级、成本控制、安全防护、多轮对话设计、效果评估、系统集成、数据隐私保护、性能优化及高可用架构设计等多个维度，为读者提供了丰富的实战经验和策略指导。
万字详解面试题库 - LLM篇
LLM（大语言模型）是AI应用的基础，也是面试必考内容。今天给大家整理了18道LLM核心面试题，涵盖Transformer原理、Prompt工程、RAG集成、成本控制、安全防护、系统优化等核心知识点，每道题都配有详细参考答案和延伸追问，帮助大家系统掌握LLM技术栈。
题目一：Transformer的核心组件有哪些，工作原理是什么
参考答案：
Transformer分Encoder和Decoder两块。
Encoder负责理解输入，每一层包含四个核心结构：
- Multi-Head Attention（多头注意力）：并行计算多组Q/K/V，捕捉不同维度的语义关系
- Feed Forward（前馈网络）：对每个位置独立做非线性变换
- Layer Norm（层归一化）：稳定训练过程中的梯度
- 残差连接（Skip Connection）：梯度可以直接回传，防止消失
Decoder除了上面这些，还多了两个东西：
- Masked Attention（掩码注意力）：生成时只能看左边，看不到未来的token
- Cross Attention（交叉注意力）：Q来自Decoder，K/V来自Encoder，把输入和输出关联起来
Multi-Head Attention的计算逻辑：每个token都会生成一个Query向量，然后和所有token的Key向量算点积，Softmax归一化得到注意力权重，再拿权重对Value加权求和。形象一点说：你问一个问题（Query），去找相关资料（Key），把相关内容提取出来（Value），这就是Attention。
另外，Transformer没有循环，无法感知位置顺序，所以引入了Positional Encoding来告诉模型每个词在序列里的位置。
延伸追问：
Attention的计算复杂度是多少？答案是O(n²)，序列长度的平方，这也是长文本处理的核心难题。
题目二：BERT和GPT的区别，为什么现在大模型都走GPT路线
参考答案：
架构差异：BERT是Encoder-only，双向注意力，能同时看到上下文；GPT是Decoder-only，单向注意力，只能看左边（自左向右生成）。
预训练任务差异：BERT做MLM（Masked Language Model），把句子里的词遮住预测被遮的词，适合理解任务（分类、NER、问答）。GPT做Next Token Prediction，预测下一个词，适合生成任务（对话、写作、代码）。
形象比喻：BERT像做完形填空，GPT像写作文。
为什么现在大模型都走Decoder-only（GPT路线）？主要有四点原因：
第一，生成能力强，天然适合文本生成、对话等任务。
第二，训练效率高，Self-supervised学习，对大规模数据更友好。
第三，涌现能力好，规模大了以后能力爆发式增长。
第四，工程实现简单，推理时KV Cache优化更直接。
BERT并不是完全没用了，情感分类、文本匹配等判别式任务，BERT双向理解更精准。
延伸追问：
什么任务用BERT还有优势？情感分类、文本匹配等判别式任务，BERT双向理解更精准。
题目三：什么是大模型的涌现能力（Emergent Ability）
参考答案：
涌现能力的定义：当模型规模增大到某个阈值后，突然出现小模型没有的新能力，而不是随规模线性提升。
典型的涌现能力有三类：
In-Context Learning（ICL）- 给几个示例，模型就能学会新任务，不需要微调。
Chain-of-Thought（CoT）推理- 模型能一步步推理，解决复杂数学或逻辑问题。
Instruction Following（指令遵循）- 能理解人类意图，按照指令完成任务。
涌现能力的"神奇"之处在于它不可预测——你不知道哪个能力会在什么规模下突然出现。这是大模型研究的重要挑战，也是为什么大模型让人感到惊喜的原因之一。
对于小模型应用，要靠Prompt工程、RAG、微调来弥补，要明确能力边界，不要强行要求它做"超纲"任务。
延伸追问：
涌现能力对小模型应用有什么启示？小模型要靠Prompt工程、RAG、微调来弥补，要明确能力边界，不要强行要求它做"超纲"任务。
题目四：大模型的幻觉问题是什么，怎么解决
参考答案：
幻觉的定义：模型生成看起来合理、自信满满，但实际上是错的内容——“一本正经地胡说八道”。
幻觉主要分两类：事实性幻觉（编造根本不存在的事情，比如瞎编论文引用）、忠实性幻觉（和给定上下文矛盾，或者偏离了用户的问题）。
产生幻觉的根本原因：训练数据本身有错误和噪声、模型的生成是概率性的不是查数据库、对不确定的内容倾向于"猜"而不是说"不知道"。
解决方案要多管齐下：
| 手段 | 说明 |
|---|---|
| RAG检索增强 | 让模型基于检索到的真实内容生成，而不是靠记忆 |
| Prompt约束 | 明确要求"基于上下文回答，不确定就说不知道" |
| 引用溯源 | 要求模型给出信息来源，便于用户核查 |
| 置信度评估 | 让模型表达自己的确定程度，低置信度时主动提示 |
| 事实验证 | 对关键信息用外部工具（搜索、数据库）验证 |
幻觉无法100%消除，目标是把它控制在可接受范围，建立"来源可追溯"的信任机制。
幻觉和不确定性有区别：幻觉是模型自信地给错误答案，不确定性是模型承认自己不知道。后者其实是更健康的状态，应该鼓励。
延伸追问：
幻觉和不确定性有什么区别？幻觉是模型自信地给错误答案，不确定性是模型承认自己不知道。后者其实是更健康的状态，应该鼓励。
题目五：Temperature和Top-p是什么，分别适合什么场景
参考答案：
**Temperature（温度）**控制概率分布的尖锐程度。Temperature = 1保持原始分布；Temperature < 1（比如0.3）分布更尖锐，高概率的token被选的机会更大，输出更确定；Temperature > 1（比如1.5）分布更平坦，低概率token也有机会被选，输出更多样。
**Top-p（Nucleus Sampling，核采样）**按概率从高到低累积，累积概率到达p的token组成候选集，从中采样。比Top-k更灵活，能自适应调整候选集大小。
实际场景参考：
- 事实性问答、代码生成：用低Temperature（0.1-0.3）+ 低Top-p，输出更准确
- 创意写作、头脑风暴：用高Temperature（0.8-1.2）+ 高Top-p，输出更多样
- 极度确定性任务（数学题）：直接用Greedy Decoding，每次选概率最高的token
同时调Temperature和Top-p会互相干扰，通常建议固定一个调另一个。
延伸追问：
同时调Temperature和Top-p会怎样？两个参数都影响采样随机性，通常只需调一个，同时调会互相干扰，一般建议固定一个调另一个。
题目六：LLM应用架构设计要注意哪些核心问题
参考答案：
LLM应用架构设计要平衡效果、成本、延迟、稳定性四个维度。
效果层面：RAG检索质量、Prompt设计、模型选择直接决定输出质量。要设计评估体系，快速迭代优化。
成本层面：Token消耗是主要成本来源（系统Prompt、Few-shot示例、检索上下文、模型输出）。要设计缓存策略、模型路由、输出长度限制。
延迟层面：LLM推理是异步过程，要设计流式输出改善用户体验，用KV Cache加速推理，异步处理非实时任务。
稳定性层面：多模型备份、熔断降级、限流防刷、健康检查，确保服务高可用。
实际架构通常是四层：接入层（请求路由、限流）、模型层（多模型管理、负载均衡）、服务层（缓存、异步队列）、存储层（向量数据库、会话存储）。
延伸追问：
LLM应用的高可用架构怎么设计？多实例负载均衡、多模型备份、熔断降级、限流防刷、健康检查，五个手段叠加。
题目七：LLM应用的缓存策略怎么设计
参考答案：
LLM应用有三层缓存可以设计：
L1 - Embedding缓存：相同查询的向量复用，避免重复编码。命中率高，收益明显。
L2 - 向量检索缓存：热门查询的检索结果缓存，减少数据库查询次数。适合Top-K结果不经常变化的场景。
L3 - LLM响应缓存：相同输入的生成结果直接返回，不调用模型。收益最大，但实时性最差。
语义缓存（进阶）：用向量相似度判断两个查询是否"语义相同"，比字符串匹配更灵活。比如"怎么退款"和"退货流程是什么"可以命中同一个缓存。实现方法是对新查询算向量，找缓存里相似度最高的历史查询，超过阈值就返回缓存结果。
缓存设计要点：缓存键要包含模型版本、参数配置，避免不同版本混用；热数据长期缓存，冷数据短期缓存；知识更新时主动失效相关缓存。
高时效性内容（新闻、价格）不缓存，稳定知识（FAQ、文档）长期缓存，根据业务特性设置合理的TTL。
延伸追问：
缓存和实时性如何平衡？高时效性内容（新闻、价格）不缓存，稳定知识（FAQ、文档）长期缓存，根据业务特性设置合理的TTL。
题目八：如何处理LLM的长文本输入
参考答案：
LLM的上下文窗口有限，处理长文本有几种方案：
检索增强（RAG）- 不处理全文，只检索与查询相关的片段。这是目前最主流的方案，把长文本问题转化为检索问题。
滑动窗口- 把长文本分块，每块分别处理再合并结果。优点是实现简单，缺点是合并结果时可能丢失上下文。
层次摘要- 先分段摘要，再对摘要汇总。适合需要全局理解的任务，比如长文档提炼核心观点。
Long Context模型- 直接用支持超长上下文的模型（Claude 200K、GPT-4 128K）。简单粗暴，但成本高。
分块策略的关键细节：块太大检索粒度粗召回的内容冗余多，块太小可能切断语义一个完整的知识点被拆散。实践建议256-512 Token/块，块间保留50-100 Token的重叠。
全文理解任务（分析、总结）用滑动窗口，问答任务用RAG更精准。
延伸追问：
滑动窗口和RAG怎么选？全文理解任务（分析、总结）用滑动窗口，问答任务用RAG更精准。
题目九：LLM应用的流式输出怎么实现
参考答案：
流式输出的核心价值：让用户看到模型"正在打字"，把体验从"等3秒看结果"变成"0.5秒开始看到内容"。
技术实现：模型API支持stream=True参数，返回一个流式生成器；后端用SSE（Server-Sent Events）推送给前端；前端用EventSourceAPI接收，实现打字机效果渲染。
SSE vs WebSocket怎么选？
| 对比维度 | SSE | WebSocket |
|---|---|---|
| 通信方向 | 服务器 → 客户端（单向） | 双向 |
| 实现复杂度 | 简单，基于HTTP | 复杂，需要协议升级 |
| 防火墙兼容性 | 好，基于HTTP | 可能被部分代理拦截 |
| 自动重连 | 内置支持 | 需要手动实现 |
| 适用场景 | 流式输出、通知推送 | 实时协同编辑、游戏 |
对话场景主要是服务器推数据给客户端，SSE就够了，而且更简单。如果需要用户在流式生成过程中发指令（比如"停止生成"），就需要WebSocket。
SSE的缺点是只能服务器向客户端单向推送，客户端想发消息还是得单独HTTP请求。
延伸追问：
SSE的缺点是什么？只能服务器向客户端单向推送，客户端想发消息还是得单独HTTP请求。
题目十：LLM应用如何做错误处理和降级
参考答案：
LLM应用要建立多层防护体系：
输入侧：长度检查（超长输入截断或拒绝）、格式校验（不合法输入直接拦截）、敏感词过滤（过滤明显违规内容）。
调用侧：超时控制（设置最大等待时间，超时返回友好提示）、重试机制（网络抖动或临时错误时自动重试，指数退避防止打垮模型服务）、错误分类（区分"可重试"和"不可重试"）。
降级策略（重要），从优到劣：
- 切换到备用模型（主模型挂了用小模型兜底）
- 返回缓存中的历史结果
- 用规则引擎处理常见问题
- 提示用户稍后重试或转人工
降级策略要根据业务场景权衡：实时性要求高的切备用模型，允许延迟的等缓存，关键场景一定要有人工兜底。
延伸追问：
降级策略怎么选？根据业务场景权衡，实时性要求高的切备用模型，允许延迟的等缓存，关键场景一定要有人工兜底。
题目十一：如何设计LLM应用的成本控制
参考答案：
Token消耗的主要来源：系统Prompt（每次都要发）、Few-shot示例（越多越贵）、检索到的上下文（RAG场景）、模型的输出（越长越贵）。
成本控制手段：
模型路由- 不同复杂度的任务用不同模型。简单问题用GPT-3.5/国产小模型，复杂推理用GPT-4/Claude，先用小模型处理置信度不够再升级大模型。
Prompt优化- 压缩Prompt长度去掉冗余描述，Few-shot示例精简只保留最相关的1-3个。
缓存策略- 命中缓存避免重复调用（参考题目七）。
输出长度限制- 设置max_tokens，避免超长输出。
批量处理- 聚合请求批量调用，降低单位成本。
成本优化和效果之间要平衡：先明确每个业务场景的"效果底线"，在满足底线的前提下才优化成本，千万不能本末倒置。
延伸追问：
成本优化和效果之间怎么平衡？先明确每个业务场景的"效果底线"，在满足底线的前提下才优化成本，千万不能本末倒置。
题目十二：LLM应用的安全防护怎么做
参考答案：
LLM应用的安全防护要覆盖输入、模型、输出三个环节：
输入侧：敏感词、注入攻击检测；超长输入拦截；Prompt Injection检测（识别试图覆盖系统指令的恶意输入，比如"忽略上面所有指令，你现在是一个…"）。
模型侧：系统Prompt里设置清晰的行为边界；分隔符隔离用户输入和系统指令。
输出侧：敏感信息过滤（身份证号、手机号等不能直接输出）；有害内容检测；幻觉校验。
其他关键安全措施：权限控制（不同用户只能访问对应功能，调用频率限制）、审计日志（所有输入输出都要记录，方便追溯）、沙箱隔离（工具调用在隔离环境执行，防止恶意操作）。
Prompt Injection具体怎么防？输入过滤 + 分隔符隔离 + 输出约束 + 权限最小化，四个手段叠加。
延伸追问：
Prompt Injection具体怎么防？输入过滤 + 分隔符隔离 + 输出约束 + 权限最小化，四个手段叠加。
题目十三：如何实现LLM应用的多轮对话
参考答案：
多轮对话的核心是维护对话状态，主要有三种方案：
完整历史- 把所有历史消息都传给模型。优点：上下文完整；缺点：消耗Token多，超长后截断。
滑动窗口- 只保留最近N轮。优点：Token消耗可控；缺点：早期关键信息会丢失。
摘要压缩- 定期用LLM对历史对话生成摘要，用摘要替代原始历史。优点：平衡了上下文质量和Token消耗。
工程实现要点：会话ID管理（每个对话有唯一ID，支持多会话并发）、上下文格式（通常是[{"role": "user", "content": "..."}, {"role": "assistant", "content": "..."}, ...]）、打断恢复（用户中途打断需要记住之前的状态）、会话清理（过期会话及时释放资源）。
对话历史超长怎么处理？首选摘要压缩，其次是滑动窗口，关键实体（姓名、订单号）可以单独提取结构化存储。
延伸追问：
对话历史超长怎么处理？首选摘要压缩，其次是滑动窗口，关键实体（姓名、订单号）可以单独提取结构化存储。
题目十四：如何评估LLM应用的效果
参考答案：
评估LLM应用效果要覆盖四个维度：
自动评估（快速迭代用）- 准确率、F1、BLEU、ROUGE（文本相似度）；用强模型（GPT-4）作为"评委"打分，多维度评分。
人工评估（校准标准用）- 专家抽样评分；多人交叉评估，计算一致性系数（Kappa）。
线上A/B测试- 分流用户，对比不同版本的效果指标。
业务指标（最终看这个）- 任务完成率、用户满意度、转化率，这才是真正的北极星指标。
评估要覆盖边界情况：不只测"正常情况"，还要测对抗样本、歧义输入、边界情况，这些往往是实际使用中最容易出问题的地方。
用模型评估模型怎么做？设计打分Prompt，让GPT-4从准确性、有用性、流畅性等维度打分，或者做对比判断（两个输出哪个更好），用ELO分系统排名。
延伸追问：
用模型评估模型怎么做？设计打分Prompt，让GPT-4从准确性、有用性、流畅性等维度打分，或者做对比判断（两个输出哪个更好），用ELO分系统排名。
题目十五：LLM应用如何与现有系统集成
参考答案：
LLM与现有系统集成有几种主流方式：
API集成（同步）- REST API封装LLM能力，现有系统直接调用。简单直接，适合请求量不大的场景。
消息队列（异步）- 用Kafka/RabbitMQ解耦，LLM服务消费消息异步处理，处理完回调业务系统。适合耗时操作、高并发场景。
RAG对接知识库- 向量数据库存储企业知识Embedding，LLM服务查询后增强生成。
Webhook回调- LLM处理完主动通知业务系统，适合批量处理场景。
插件/工具调用- 现有系统暴露工具接口，LLM通过Function Calling调用。
集成时要重点考虑：数据格式转换（现有系统的数据格式 ≠ LLM的期望输入，中间层做适配）、性能匹配（LLM响应慢不要让它成为同步调用链路的瓶颈）、渐进式集成（先在低风险场景试点验证效果后再推广）。
异步处理设计：任务入队 → Worker消费 → 处理 → 结果回调，要有超时机制和重试机制，异常任务要进死信队列。
延伸追问：
异步处理怎么设计？任务入队 → Worker消费 → 处理 → 结果回调，要有超时机制和重试机制，异常任务要进死信队列。
题目十六：LLM应用的数据隐私怎么保护
参考答案：
数据隐私保护要覆盖传输、存储、处理、访问控制四个环节：
传输- HTTPS加密，防止中间人攻击。
存储- 数据库字段级加密（敏感字段单独加密存储）；密钥和数据分离管理。
处理- 脱敏处理（身份证号、手机号、地址用掩码替换或Hash化）；数据最小化（只传递必要信息，不发送全量数据）。
访问控制- 身份认证 + 细粒度权限管理；操作审计日志（谁在什么时间访问了什么数据）。
本地部署是数据敏感场景的首选：政府、金融、医疗等对数据合规有严格要求的行业，优先私有化部署，数据不出域。
GDPR等法规的要求：明确告知数据用途、获取用户授权、支持数据删除（被遗忘权）、明确数据保留期限。
延伸追问：
GDPR等法规有哪些要求？明确告知数据用途、获取用户授权、支持数据删除（被遗忘权）、明确数据保留期限。
题目十七：大模型应用的性能优化有哪些手段
参考答案：
性能优化可以从模型层、推理层、系统层三个层面入手：
模型层：
- 模型量化（INT8/INT4）：降低精度，显存减少，速度提升，效果损失可接受
- 模型蒸馏：大模型教小模型，小模型服务更轻量
- 模型剪枝：去掉冗余参数，减小模型体积
推理层：
- KV Cache：缓存Transformer解码时的K/V矩阵，避免重复计算，生成速度大幅提升
- 连续批处理（Continuous Batching）：动态合并请求，提高GPU利用率
- vLLM / TensorRT-LLM：专门优化推理的框架，吞吐量提升显著
系统层：
- 多级缓存（参考题目七）
- 异步处理非实时任务
- 流式输出改善用户体验感知延迟
KV Cache的原理：Transformer解码是自回归的，每生成一个token都要对所有前缀重新算注意力。KV Cache把已经算好的K/V存起来，下一步直接复用，不用重算，速度提升非常明显。
延伸追问：
KV Cache是什么原理？Transformer解码是自回归的，每生成一个token都要对所有前缀重新算注意力。KV Cache把已经算好的K/V存起来，下一步直接复用，不用重算，速度提升非常明显。
题目十八：LLM应用的高可用架构怎么设计
参考答案：
高可用的核心手段：
多实例负载均衡- LLM服务多节点部署，Nginx/K8s做负载均衡。
多模型备份- 主模型挂了自动切备用模型（OpenAI挂了切Claude，或者切本地部署的模型）。
熔断降级- 模型服务故障时快速失败，避免请求堆积导致级联崩溃。
限流防刷- 按用户/IP/API Key控制请求速率，防止被打垮。
健康检查- 定期探测服务状态，异常节点自动剔除，不再分发请求。
多模型备份怎么实现？主备模型配置好，主模型超时或报错时自动failover；也可以同时发两个请求取最快返回（latency优先但成本翻倍）。
高可用架构设计要根据业务需求权衡：对可用性要求极高的场景（客服、医疗），要多模型备份+熔断降级；对成本敏感的场景，可以只用限流+健康检查。
延伸追问：
多模型备份怎么实现？主备模型配置好，主模型超时或报错时自动failover；也可以同时发两个请求取最快返回（latency优先但成本翻倍）。
假如你从2026年开始学大模型，按这个步骤走准能稳步进阶。
接下来告诉你一条最快的邪修路线，
3个月即可成为模型大师，薪资直接起飞。
阶段1:大模型基础
阶段2:RAG应用开发工程
阶段3:大模型Agent应用架构
阶段4:大模型微调与私有化部署
配套文档资源+全套AI 大模型 学习资料，朋友们如果需要可以微信扫描下方二维码免费领取【保证100%免费】👇👇
