大模型算法岗面试复盘：从RAG设计到70B模型部署的10个实战问题

刚经历完美团大模型算法岗的第三轮技术面试，感觉比预想的要硬核许多。这一轮面试官完全跳过了传统的“八股文”，问题全部聚焦于线上真实场景中会遇到的问题和挑战，考察的是实打实的工程与架构能力。

我把被问到的问题和自己的回答思路系统地复盘了一遍，如果你也在准备类似岗位，或许能从中得到一些启发。

自我介绍 + 最有技术含量的项目

问题难点分析：这虽然是个开场问题，但其实是面试官为你后续技术讨论定下的基调。他在听你介绍项目时，已经在评估你的技术深度和结构化表达能力。

面试官考察点：

• 能否在一分钟内清晰提炼项目的核心价值。
• 对技术方案的选型是否有深入思考，而非简单的“调包”实现。
• 是否有数据驱动的意识，能用量化结果证明方案的有效性。

标准回答思路：我选择介绍一个结合了RAG与Agent架构的项目，我负责了整体设计。项目的核心目标是解决复杂多跳问答准确率低下的问题。通过引入查询改写模块和动态检索策略，我们将准确率从78%提升至92%，同时将端到端响应延迟成功控制在1.2秒以内。回答的重点在于解释“为什么选择这个方案”，而不是“做了什么”，这能让面试官看到你的决策过程。

问题衍生：如果让你重新做这个项目，你认为哪个环节可以采取不同的方案进行优化？

1. 让你把当前项目迁移到大众点评场景（评论、探店、推荐），你会如何设计？

问题难点分析：这个问题考察的是场景迁移与架构适配能力。面试官希望看到你能否将通用的大模型技术，灵活地落地到“点评”这个具体的、充满复杂性的业务场景中。

面试官考察点：

• 对点评业务（UGC内容、商户信息、推荐逻辑）的理解深度。
• 能否识别出新场景带来的特殊挑战（如数据异构、真实性要求）。
• 架构设计是否具备足够的灵活性以应对不同需求。

标准回答：我会从三个层面来设计这个迁移方案：

1. 数据层：点评场景的数据是混合形态的，包括短文本（用户评论）、长文本（探店文章）和结构化数据（商户信息）。我会构建多模态索引：评论使用稠密向量进行语义检索；商户信息利用结构化字段（如菜系、人均价格）进行高效过滤；探店文章则采用稀疏（如BM25）与稠密向量混合检索的策略。
2. 检索层：用户的查询往往隐含多层意图，例如“找一家适合带娃的川菜馆”。这需要实体识别（川菜）、属性提取（带娃）和隐式意图理解（可能意味着需要环境安静、有儿童座椅）。我会设计一个意图解析模块，将复杂查询拆解，并行进行多路检索后再进行结果融合。
3. 生成层：在点评场景下，生成内容的真实性至关重要，模型绝不能捏造商户的评分、价格或服务细节。我的策略是强制所有事实性信息必须通过API检索获取，并在最终答案中附带引用来源。同时，针对“探店”类内容的生成，需要调整风格为更口语化、更具画面感的叙述方式。

问题衍生：当用户提出“附近有什么好吃的”这类非常模糊的意图时，你的系统会如何处理？

2. 如何优化LLM推理延迟？

问题难点分析：这是一个基础但极其高频的优化问题。关键在于必须从端到端的全局视角来回答，而不能仅仅罗列“使用vLLM”这样孤立的点。

面试官考察点：

• 对主流推理引擎（如vLLM， TensorRT-LLM）核心特性的了解。
• 能否系统性地将延迟问题分层拆解。
• 是否有过真实的线上调优经验与数据。

标准回答：我会从四个层面来系统性优化推理延迟：

1. 模型层：在满足效果的前提下，优先考虑使用更小的模型（如7B参数），或采用蒸馏后的模型。如果必须使用大模型，则应用量化（INT8/FP8）和剪枝技术来减小模型体积、加快计算。
2. 引擎层：采用vLLM或TensorRT-LLM等高性能推理引擎，并开启PagedAttention和Continuous Batching功能。根据实测，vLLM相比原生Hugging Face的generate函数，吞吐量通常能有3-5倍的提升。
3. 请求层：实施动态批处理（Dynamic Batching），将不同时间到达的请求合并计算以提高GPU利用率。同时，采用流式输出（SSE），让用户能尽快看到首个生成的字词，从而感知上降低延迟。
4. 架构层：对高频或热门的查询结果进行缓存，避免重复的模型计算。在长文本对话场景，利用前缀缓存（Prefix Caching），让拥有相同对话历史的请求共享KV Cache。

问题衍生：如果业务要求的延迟目标是500ms，但仅模型单次推理就需要800ms，你会从哪些方面着手解决这个矛盾？

3. 什么是KV Cache？它解决什么问题？

问题难点分析：这是理解Transformer模型推理优化的核心概念之一。需要清晰地阐述其工作原理和带来的工程价值。

面试官考察点：

• 对Transformer模型自回归解码过程的底层理解。
• 能否说清楚“空间换时间”这一优化本质及其代价。

标准回答：KV Cache是Transformer模型在推理阶段的一种用空间换时间的关键优化技术。
在自回归生成过程中，每生成一个新的token，都需要基于所有已生成的历史token来计算注意力分数。如果不进行任何优化，每个生成步（step）都需要为所有历史token重新计算其Key和Value矩阵，这导致计算复杂度达到O(n²)。
KV Cache的机制是：在第一个生成步（Prefill阶段）计算历史token的Key和Value时，就将它们存储（缓存）下来。在后续的解码（Decode）步中，只需计算当前新token的KV，然后将其与缓存的历史KV拼接，再进行注意力计算。这样，每个step的计算复杂度就降到了O(n)，从而极大降低了推理延迟。
代价是显存占用会随着生成序列长度的增加而线性增长。这也正是vLLM中PagedAttention等技术要解决的核心问题——高效管理不断增长的KV Cache。

问题衍生：KV Cache在Prefill阶段和Decode阶段分别是如何工作的？

4. 如何在高并发场景下降低GPU成本？

问题难点分析：这个问题考察的是工程师的成本意识与资源规划能力。面试官希望看到你不仅关注效果和性能，还具备“帮公司省钱”的商业思维。

面试官考察点：

• 对GPU资源利用率指标的理解和优化思路。
• 能否设计出高性价比的弹性架构。
• 是否有过实际的降本增效项目经验。

标准回答：在高并发场景下降低GPU成本，核心在于最大化GPU的利用率。我会采取以下策略：

1. 动态批处理：使用vLLM的Continuous Batching，让请求可以动态加入计算批次，无需等待固定批大小，从而将GPU利用率从传统的30%左右提升至80%以上。
2. 模型量化：应用INT8或FP8量化技术，可以在精度损失极小的情况下将模型显存占用减半，使得同一张GPU卡能够同时处理更多的并发请求。
3. 弹性伸缩：基于Kubernetes和Horizontal Pod Autoscaler（HPA），根据实时请求队列长度或GPU利用率指标自动扩缩容实例。在流量波谷时缩减至最小规模，波峰时快速扩容。
4. 混合部署：将在线推理服务与离线批处理任务（如模型微调、数据预处理）混合部署在同一GPU集群上，利用其不同时段的工作负载特征，实现资源的“错峰使用”，榨干GPU算力。
5. 按需分级：对非核心或对效果要求不高的场景，降级使用更小的模型，甚至用规则或检索系统来替代，避免所有请求都“无脑”调用昂贵的大模型。

问题衍生：如果线上流量在短时间内突然增长10倍，你的架构如何保证服务不崩溃？

5. 如果线上模型服务出现延迟突然升高，你如何排查？

问题难点分析：这是一个典型的线上故障排查题，旨在考察你的系统思维、应急响应能力以及对运维监控体系的熟悉程度。

面试官考察点：

• 是否有真实的线上运维和问题定位经验。
• 排查路径是否系统化、有章法，而非盲目试错。
• 能否结合监控数据快速定位到问题根因。

标准回答：我会遵循一个系统化的路径进行排查：

1. 观察监控大盘：首先确认是整体服务延迟升高，还是某个特定模块（如推理引擎、检索服务、数据预处理）的问题。观察延迟曲线是瞬时飙升还是缓慢爬升，这有助于判断问题类型（如流量突增 vs 内存泄漏）。
2. 检查资源指标：查看GPU利用率、显存使用量、CPU负载、内存和网络I/O。如果GPU利用率突降至0，可能是上游请求异常中断；如果利用率飙至100%且持续，可能是遭遇了请求洪峰或模型计算卡死。
3. 分析请求日志：检索最近时段的请求日志，观察是否有新的请求模式（例如，大量超长文本输入），或者是否出现大量特定的错误码（如超时、OOM内存溢出）。
4. 查看引擎日志：检查vLLM或TensorRT-LLM等推理引擎的日志，寻找警告或错误信息（例如，“KVCache内存不足”、“Batch size超限”）。
5. 执行快速止血：根据初步判断采取应急措施。如果是流量突增，立即启动扩容或实施流量熔断/降级。如果是某个异常请求模式导致，可临时添加过滤规则。如果怀疑内存泄漏，则重启有问题的服务实例。
6. 进行事后复盘：问题解决后，必须进行根因分析，并完善相应的监控告警策略，编写事故复盘报告，避免同类问题再次发生。

问题衍生：对于那种偶发性、难以复现的延迟抖动（比如每几个小时出现一次几十毫秒的尖刺），你会如何着手排查？

6. 项目上线后用户反馈效果不好，你如何定位问题来源？

问题难点分析：这个问题考察的是数据驱动和用户导向的优化思维。你需要展示如何将模糊的负面反馈，转化为可分析、可行动的技术改进点。

面试官考察点：

• 是否有一套处理用户反馈、将其转化为技术问题的流程。
• 能否将“效果不好”这类模糊问题，拆解到具体的技术模块。
• 是否有利用A/B测试进行效果验证的经验。

标准回答：我会通过四个步骤来定位和解决问题：

1. 收集与归因：首先对“效果不好”的反馈进行精细化分类。是答案事实错误（准确性问题）？是答非所问（意图理解问题）？还是回答冗长啰嗦（生成质量问题）？为不同类型的反馈打上标签。
2. 模块化拆解：以RAG系统为例，问题可能出在检索侧（没找到相关文档），也可能出在生成侧（找到了文档但没用好）。我会利用系统的全链路追踪（Trace）日志，回放问题query，检查每个中间环节的输出结果。
3. 构建评估集：将用户反馈的典型case整理成一个离线评估测试集。任何针对性的优化（如调整检索参数、改进prompt）完成后，都先在这个测试集上跑分，量化评估优化效果。
4. 小流量验证：将优化后的版本通过小流量A/B测试的方式上线，对比核心业务指标（如用户满意度、答案采纳率、平均对话轮次）是否有显著提升，确保优化是正向的。

问题衍生：如果用户的反馈非常主观，例如“感觉回答得不好”，但无法提供具体原因，你如何将这种主观感受进行量化分析？

7. 在构建知识库时如何做文本切分？如何解决RAG召回不足问题？

问题难点分析：这是RAG（检索增强生成）系统中的两个核心痛点。面试官想考察你对数据预处理和检索优化等底层细节的掌握程度。

面试官考察点：

• 对不同文本切分（Chunking）策略的优缺点理解。
• 面对召回不足这一常见难题，能否设计出多层次、互补的兜底方案。

标准回答：

文本切分策略：

• 按语义切分：优先根据自然段落、句子等语义边界进行切分，避免在句子中间或实体中间切断，破坏信息的完整性。
• 引入重叠（Overlap）：在相邻文本块之间设置10%-20%的重叠区域，防止关键信息恰好落在两个块的边界上而被割裂。
• 按类型适配：不同文档类型采用不同策略。例如，代码按函数或类切分，表格保持行或列的完整性，问答对则作为一个整体保留。

RAG召回不足的解决方案：

1. 查询改写（Query Rewriting）：当用户query过于简短或模糊时，使用一个轻量级模型生成多个语义相似的改写版本，并行进行检索，然后合并结果。
2. 多路召回（Multi-retrieval）：结合多种检索器，如向量检索（语义相似）、BM25（关键词匹配）、知识图谱检索（结构化关系），将各路结果融合去重。
3. HyDE（Hypothetical Document Embeddings）：让大模型根据用户问题“假设”一个理想的答案文档，然后用这个生成的“假设文档”的向量去检索真实知识库，有时能发现语义更相关但表述不同的材料。
4. 重排序（Re-ranking）：采用“粗排+精排”策略。先用向量检索召回一个较大的候选集（如Top 50），再使用计算更精细但更耗时的交叉编码器（Cross-Encoder）对候选文档进行精排，选出最相关的Top 3。
5. 主动询问（Agent）：当检索系统对当前query的置信度较低时，可以设计让Agent主动反问用户，以获取更明确的信息，再进行二次检索。

问题衍生：如果检索系统成功召回了文档，但该文档本身包含错误或过期信息，导致生成答案错误，这个问题该如何处理和规避？

8. 如果点评评论数据非常长，如何设计高效检索策略？

问题难点分析：这聚焦于长文档检索这一具体挑战，需要你在检索精度和计算效率之间做出聪明的权衡。

面试官考察点：

• 对长文本带来的检索难题（如信息稀释、计算开销大）是否有清晰认知。
• 能否设计出分层、分级的检索架构来应对。

标准回答：对于像“探店长文”这类超长评论，直接用整篇文章做一个Embedding进行检索会导致大量细节信息被平均掉，效果很差。我的设计策略是：

1. 分层索引：建立文档级和段落级（或句子级）的两层向量索引。先通过文档级Embedding快速筛选出相关文章，再在这些文章内部通过段落级Embedding精确定位到最相关的具体段落。
2. 结构化切分：利用长文本身的结构（如小标题、自然段落）进行切分，为每个语义相对完整的“块”生成独立的Embedding。检索时直接返回相关块的内容，而不是整篇文档。
3. 摘要增强：为每篇长文档自动生成一个高质量的摘要。将摘要的Embedding也加入索引。用户查询可能先命中摘要，我们再据此定位并返回全文中的相关部分。
4. 滑动窗口：对于询问具体细节的查询（如“毛血旺辣不辣”），可以在被初步选中的长文档内部，使用一个固定大小的滑动窗口，结合BM25或小型模型，快速扫描定位到提及该细节的精确位置。
5. 缓存热点：对于访问频率极高的热门商户或“爆款”探店文章，可以将其向量或甚至部分检索结果预热到缓存中，显著降低高频请求的检索耗时。

问题衍生：如果用户的评论不仅包含长文本，还附带了图片（例如菜品实拍），你如何设计一个支持“图文混合”查询的多模态检索系统？

9. Agent系统如何避免错误调用工具？

问题难点分析：工具调用的可靠性是构建实用Agent系统最大的挑战之一。这个问题考察你对Agent行为边界控制和异常处理机制的设计能力。

面试官考察点：

• 对Agent可能产生的错误调用类型（参数错误、无效调用、死循环）是否有预见性。
• 能否设计一个包含多层校验和防护的“安全网”。

标准回答：为了最大程度减少错误工具调用，我会构建一个多层防护策略：

1. 置信度过滤：要求大模型在决定调用工具时，输出一个置信度分数（0-1）。设置一个阈值（如0.7），低于此阈值则不执行调用，转而回复“我目前无法确定”或主动向用户提问以澄清意图。
2. 参数校验层：在模型输出工具调用参数后，增加一个基于规则的校验层。例如，调用“查询天气”工具时，检查城市名是否在支持的白名单内；调用“查询商品价格”时，验证商品ID的格式是否有效。校验失败则拒绝调用，并要求模型重新思考或生成。
3. 调用次数限制：为单次对话设置工具调用的最大次数上限（如3次），防止Agent陷入无意义的调用循环或“思考循环”。
4. 结果验证：在工具返回结果后，让大模型对结果做一个简要评估，判断“这个结果是否真正回答了用户的问题”。如果判定为无效，则触发后续逻辑：是尝试调用其他工具，还是基于已有信息给出一个保守的回答。
5. 熔断与降级：监控每个工具的健康状态。如果某个工具连续多次调用失败或超时，则暂时将其熔断，并切换到一个备用工具（如有），或直接降级为纯模型生成回答。

问题衍生：如果工具调用本身成功了，返回了格式正确的结果，但这个结果的内容实际上是错误的（例如，天气API返回了错误的气温），你的Agent系统有办法检测到这种情况吗？

10. 需要你部署一个70B模型在线服务，你会如何设计推理架构？

问题难点分析：这是一个大型模型线上部署的综合系统设计题，要求你全面权衡性能、成本、稳定性和可运维性。

面试官考察点：

• 对大模型服务端到端部署的全栈认知。
• 在资源约束下进行技术选型和架构权衡的能力。
• 是否有过大规模模型服务上线的实际经验或深入的思考。

标准回答：部署一个70B参数模型，我会设计一个分层的、稳健的推理架构：

1. 模型与计算层：
   • 70B模型在FP16精度下约需140GB显存，单卡无法装载。我将采用模型并行（Tensor Parallelism），将模型切分到多张GPU（例如4张A100 80GB）上协同计算。
   • 为节省显存，会启用FP8量化，这有望将显存需求减半，或许能用更少的卡（如2张）来部署。
2. 推理引擎层：
   • 使用 vLLM 作为推理引擎，启用其核心特性：PagedAttention（高效管理KV Cache）和 Continuous Batching（连续批处理），以最大化GPU利用率和吞吐量。
   • 启用前缀缓存，使拥有相同对话历史或系统提示词的请求能够共享计算。
3. API服务层：
   • 使用 FastAPI + Uvicorn 构建RESTful/WebSocket网关，提供标准化的API接口，并原生支持流式响应（Server-Sent Events）。
   • 在网关前设置请求队列，对瞬时涌入的流量进行缓冲和平滑，防止直接冲击后端有限的GPU实例。
4. 调度与资源层：
   • 整个服务基于 Kubernetes 进行容器化部署和管理。
   • 配置 Horizontal Pod Autoscaler (HPA)，根据GPU利用率或请求队列长度等指标，自动对推理实例进行扩缩容。
   • 部署负载均衡器，将请求智能地分发给后端多个推理实例。
5. 降级与容错层：
   • 对高频或标准的查询，建立缓存机制，直接返回预先生成好的答案，绕过模型推理。
   • 为非核心或对响应速度要求极高的场景，设计降级链路，可快速切换到一个小型模型（如7B）或规则引擎，确保服务的可用性。
6. 可观测性层：
   • 建立完善的监控仪表盘，核心指标包括：GPU利用率、P99/P95延迟、每秒查询数（QPS）、错误率。
   • 设置告警规则，例如当P99延迟超过3秒或错误率超过1%时，自动触发告警并可能联动扩容操作。

问题衍生：如果业务同时要求首字延迟（Time to First Token）必须小于500毫秒，且整体吞吐量要达到100 QPS，面对70B这样的大模型，你的架构设计会做哪些特别的调整或妥协？

11. 代码题：二叉树最近公共祖先

问题难点分析：这是LeetCode 236题，一道经典但边界条件容易出错的题目，重点考察对递归（DFS）的理解和代码的严谨性。

面试官考察点：

• 数据结构（二叉树）的基础。
• 递归算法的设计与实现能力。
• 能否写出简洁且无bug（Bug-free）的代码。

标准回答：核心思路是后序遍历（深度优先搜索），从底向上回溯。如果当前节点是p或q，则向上返回这个节点。如果左右子树分别找到了p和q，那么当前节点就是它们的最近公共祖先（LCA）。

class Solution:
    def lowestCommonAncestor(self, root: 'TreeNode', p: 'TreeNode', q: 'TreeNode') -> 'TreeNode':
        # 递归终止条件：遇到空节点，或者直接找到了p或q
        if not root or root == p or root == q:
            return root

        # 后序遍历：先查左子树，再查右子树
        left = self.lowestCommonAncestor(root.left, p, q)
        right = self.lowestCommonAncestor(root.right, p, q)

        # 如果左右子树都非空，说明p和q分布在当前节点两侧，当前节点即为LCA
        if left and right:
            return root

        # 否则，LCA存在于左子树或右子树中，返回非空的那一侧
        return left or right

问题衍生：如果题目给定的不是普通的二叉树，而是二叉搜索树（BST），是否有更优的解法？另外，如果这棵树的深度非常大，递归解法可能导致调用栈溢出，如何优化？

写在最后

美团的这次技术面试，问题全部围绕线上真实会遇到的坑、架构设计中的权衡点、以及故障发生后的排查思路展开。没有任何一道题能靠死记硬背“八股文”来回答，考察的都是解决实际问题的“真功夫”。

如果你也在备战大模型算法或相关人工智能岗位，建议你以这些问题为蓝本进行模拟练习，重点是能否将你的技术决策讲清楚、讲深入，并展现出你独特的思考过程。扎实的项目经验和清晰的系统思维，是这类面试通关的关键。希望这份复盘能对大家的面试求职准备有所帮助。