联想AI工程师笔试复盘:大模型/RAG/Agent考点全解析

联想AI工程师笔试复盘:大模型/RAG/Agent考点全解析 1. 先说说这场笔试到底考什么秋招投了联想的AI工程师岗从简历筛选到收到笔试通知中间隔了不到一周。这里需要先解释一个背景联想这两年把AI岗位拆得很细有做端侧推理的、有做企业级RAG落地的、还有偏算法研究的。不同方向的笔试侧重点会有差异但都共用一套基础筛选逻辑。我这场笔试在线完成总时长90分钟题量不算大大约40道题但含金量集中在最后两道编程题和一道场景设计题。前面30多道是选择题覆盖机器学习、深度学习、大模型基础、Python编程细节。单选多选混排多选少选会扣分。先说结论如果准备过常规算法岗笔试第一反应是题目不算偏但它考得很细专门挑那些“以为自己会、其实没吃透”的知识点。而且联想的笔试有个特点比重明显偏向工程落地——它不怎么问你经典的纯理论推导而是把所有理论都包装成工程场景来考。另外有个值得注意的趋势这是我见过最早把LLM应用能力大规模放进笔试的国内大厂之一。大模型相关的题目大概占到了选择题的三分之一涉及Prompt技巧、RAG检索流程、Agent工具调用的实现细节。如果你是奔着纯传统机器学习去的这部分容易失分。这篇文章我不打算复述原题而是把所有考点重新梳理归类结合我在笔试现场的真实感受、和一些同学考后对答案的讨论给出一份能直接用于复习的复盘。还没考的同学可以当备考指南已经考完的也可以对照一下自己的薄弱点。2. 整体内容设计与思路拆解它想筛什么样的人2.1 从题型比例看联想对AI工程师的能力预期先把我在考场上见到的题型分布整理出来帮助还没考的人建立宏观认知。整体印象是机器学习基础占20%深度学习占20%大模型与LLM应用占30%编程能力占20%工程与场景设计占10%。这和很多互联网公司的算法笔试有区别——传统大厂更偏数学推导和模型细节联想则明显在向“能落地的大模型应用工程师”倾斜。选择题里机器学习和深度学习部分难度中规中矩比如交叉熵损失函数在分类任务里为什么比MSE更合适、BatchNorm在训练和推理阶段行为差异、1x1卷积的作用。这些问题只要系统学过一遍深度学习一般都能答对。真正拉开差距的是大模型题和应用场景题。比如它问到RAG流程中chunk size设置过小会带来什么影响、LangChain里Agent执行工具调用的机制、模型上下文窗口和检索结果数量怎么匹配。这些不是靠死记硬背能答出来的需要真的做过类似项目踩过相关坑才写得出来。所以我的整体判断是联想这场笔试想筛的人不是纯理论型选手也不是只会调包的工具人而是既懂模型原理、又做过实际AI应用开发、能理解工程链路的人。2.2 为什么很多“刷题型选手”反而翻车考后我和几个在群里对答案的同学交流发现一个共同现象越是按传统算法岗题库刷题的人这次越觉得“使不上劲”。因为大量传统八股题被包装成了“实际开发中你会怎么选”的形式而不是“请写出公式”的形式。举个例子传统笔试题可能是“请写出softmax的公式”而联想会问“推理阶段如果直接对logits做softmax后发现输出概率始终非常接近均匀分布可能是什么原因”。表面是在考softmax实际是在考验你对温度参数、logits尺度、数值稳定性、甚至是训练不收敛导致的logits趋同这些工程问题的理解。这种考法对只记公式不理解原理的人很不友好。另外多选少选扣分的设计也在倒逼你“不确定的不要乱选”这和实际工作中“不确定的技术选型不要乱拍板”是一个逻辑。这种细节一定程度上体现了出题人的风格要的是严谨和判断力而不是赌徒心态。2.3 结合热词看联想AI的战略方向我在准备阶段研究过联想的AI布局所以看笔试题目时有一种“它的出题方向是有战略意图”的感觉。联想的企业级AI服务、AI PC、混合式AI这些业务都依赖于将模型在特定场景中做工程化落地。这不是单纯做研究发论文的岗位而是要面对真实客户需求、解决实际问题的工程师岗。所以笔试里出现这么高比例的大模型应用题目其实是必然的。它需要的人才是能理解RAG怎么设计、Agent怎么规划、端侧模型怎么部署、效果怎么评估的综合型工程师。从热词里也能看出“AI Agent”“AI应用开发”“AI模型部署”这些方向是当前行业最热的技能点。如果你正在准备联想或其他大厂的AI岗位建议把这些关键词作为复习的核心线索而不是只盯传统机器学习算法。3. 核心考点解析与实操要点我把考点拆成三层3.1 底层基础层机器学习与深度学习高频考点先说传统部分。机器学习这一块选择题里出现频率最高的是模型评估与偏差方差、正则化、树模型与集成学习。有个印象很深的题给出一组训练集和验证集的表现问你判断模型处于什么状态应该怎么调整。这类题其实是在考察你对“模型在训练集表现好、验证集差”这类现象的敏感度。如果理论基础不扎实很容易被选项里的干扰项带偏——比如混淆了“增加数据量”和“降低模型复杂度”各自的作用场景。实际上当训练集和验证集表现差距大时优先考虑正则化或降低复杂度而训练集本身表现也差时才去考虑特征工程或换模型。深度学习部分比较典型的是考了Skip Connection为什么能缓解梯度消失以及Transformer里多头注意力机制的“头”到底在做什么。Transformer相关的基础概念这次至少考了四道题这个信号很明确即使不做纯NLP方向Attention机制也是AI工程师的基本功。我的建议是准备阶段要把下面几个概念做到能画图、能推演、能举例反向传播过程中的梯度流、BatchNorm和LayerNorm的区别、CNN的感受野计算、RNN梯度消失原因、Transformer的QKV计算流程。这些是选择题里最容易出也是最好拿分的部分。3.2 核心热力层大模型与LLM应用这些题是重头戏这一部分我单独拉出来说因为它是这次笔试里最不传统、也最值得展开的板块。我先说几个印象深刻的考察角度。第一个是Prompt工程。题干给了一个客服场景要求模型从用户对话中抽取订单号、退款原因、用户情绪三个信息然后问你下面哪种Prompt设计最合理。这题看似简单但选项里埋了很多细节坑比如是否告诉模型输出JSON格式、是否给出few-shot示例、是否在Prompt里重复系统指令。真正做过大模型应用的人会知道输出格式约束和示例质量往往比措辞华丽更重要。第二个是RAG。这道题问的是“当检索到的文档片段和用户问题语义不完全匹配时以下哪种做法最有助于提升回答质量”。选项包括调整embedding模型、增大chunk size、增加重排序环节、换更大模型。这里有个明显的干扰项是把所有问题都抛给“换个更大的LLM”但正确答案的思路应该落在检索质量优化上——重排序、查询改写、混合检索这些才是RAG链路里对症下药的方案。第三个是Agent。题目描述了一个多工具调用的场景问你Agent在决定调用哪个工具时主要依赖什么以及工具返回结果后如何处理。这题考察的是对ReAct框架和Function Calling机制的理解。这里如果只是知道概念、没写过代码很难准确把握“先推理再行动、根据观察再推理”这个循环逻辑。我对这部分备考的建议是不要只看科普文章一定要亲自动手写一个小项目。哪怕只是做一个10行代码的LangChain调用或者用OpenAI的Function Calling写一个查询天气的Agent都能让你对这些概念的理解产生质变。笔试里那些“让你判断哪个方案最优”的题本质上是考你有没有相关的“手感”。3.3 纯工程层Python细节与手撕代码编程题部分有两道一简一难。简单的那道是给定一个整数列表找出所有和为target的三元组这是经典的Two Pointer问题。另一道稍微复杂一些要求实现一个带过期时间的LRU缓存并且要支持并发读。为什么说第二道有区分度因为它把数据结构设计、时间复杂度和并发安全三个维度放在了一起。传统LRU用HashMap加双向链表就能实现但“支持并发读”意味着需要考虑线程安全问题——ReadWriteLock是一个合理的选择读操作可以共用写操作互斥。笔试环境里限定了语言为Python所以我实现时用一个OrderedDict加一个锁把逻辑尽量写清晰关键注释也写了。在代码题上我的经验是不要只追求通过样例要把边界条件写清楚——比如过期时间设置为0或者负数时的处理逻辑并发场景下缓存命中和过期检查的原子性这些才是区分度所在。4. 实操过程与核心环节实现我的笔试复盘4.1 时间分配策略我如何用90分钟稳住节奏先说一个很多人在笔试里容易犯的错——在前面的选择题上纠结太久。35道选择题建议时间控制在40分钟以内留出至少30分钟给两道编程题和最后一道场景设计题。我见过有同学在某个多选题上和选项较劲结果编程题只写了第一道第二道直接空白交卷这是最亏的。我的策略是先快速过一遍选择题遇到没把握的标记跳过不恋战。第一轮先把所有会做的选完第二轮再回来处理标记的难题。实际执行下来我第一轮用了25分钟第二轮处理难题用了15分钟。这个节奏保证了我后面有充裕的时间写代码。编程题我按“先写思路注释、再写代码、最后补边界”的顺序处理。第一道Three Sum我比较熟练大概8分钟写完并通过了测试用例。第二道带过期时间的LRU我花了18分钟虽然不完美但核心逻辑都写到位了。最后还有15分钟留给场景设计题刚好吃完这部分分值。4.2 编程题详解Three Sum的漂亮解法与边界处理这道题是经典题很多人会觉得“太简单了”但笔试里往往简单题更容易因为细节失分。我先给一个标准的双指针解法def three_sum(nums, target): nums.sort() res [] n len(nums) for i in range(n - 2): if i 0 and nums[i] nums[i - 1]: continue left, right i 1, n - 1 while left right: s nums[i] nums[left] nums[right] if s target: res.append([nums[i], nums[left], nums[right]]) while left right and nums[left] nums[left 1]: left 1 while left right and nums[right] nums[right - 1]: right - 1 left 1 right - 1 elif s target: left 1 else: right - 1 return res代码本身不复杂但有几个细节值得注意。排序后的去重逻辑是最容易被忽略的如果不跳过头尾重复元素会出现重复三元组笔试判题时会算错。另外target是变量而不是传统的0所以不能写死判断条件。有些同学在刷题时只写过返回所有和为零的三元组看到target变量就懵了其实原理完全一样。4.3 编程题详解带过期时间的并发LRU缓存这道题我要多说几句因为它综合考察的层次比第一道高很多。先看一个完整的参考实现import threading from collections import OrderedDict class TimedLRUCache: def __init__(self, capacity: int, default_ttl: int 60): self.capacity capacity self.default_ttl default_ttl self.cache OrderedDict() self.lock threading.RLock() def _is_expired(self, key): value, expire_at self.cache[key] return time.time() expire_at def _evict_if_needed(self): while len(self.cache) self.capacity: oldest_key, _ self.cache.popitem(lastFalse) def get(self, key: int): with self.lock: if key not in self.cache: return -1 if self._is_expired(key): self.cache.pop(key) return -1 value, _ self.cache.pop(key) self.cache[key] (value, time.time() self.default_ttl) return value def put(self, key: int, value: int, ttl: int None): with self.lock: if ttl is None: ttl self.default_ttl if key in self.cache: self.cache.pop(key) self.cache[key] (value, time.time() ttl) self._evict_if_needed()这个实现里我用了OrderedDict来保证LRU顺序用RLock来保证并发安全。关键点在于get操作时命中后要把节点移到末尾——OrderedDict里就是先pop再重新赋值。过期检查要放在命中检查之后、返回值之前否则可能出现已经读到过期数据的情况。其实笔试环境不要求代码能直接运行但逻辑完整和注释清晰会显著加分。我在代码开头写了一句话说明设计思路在关键函数上方写了时间复杂度和并发策略这样看起来就像一个有工程经验的工程师写出来的代码而不是题库背出来的答案。4.4 场景设计题RAG问答系统的优化方案最后那道场景设计题很有意思题目大意是一个企业知识库问答系统基于RAG搭建用户反馈回答质量不稳定有时答非所问。请给出你的排查思路和优化方案。这种开放式问题没有标准答案但考察的是系统化解决问题的能力。我从三个方面展开先查检索质量再查生成质量最后查链路设计。检索质量方面我提到先检查文档切分策略——chunk过大容易引入噪声过小容易丢失上下文。检查embedding模型和企业文档领域的匹配度可以用一组人工标注的query-document对来评估召回率。另外增加重排序比如用cross-encoder对召回的top文档重新打分能显著提升准确率。生成质量方面我提到Prompt中是否给出了充分的指令约束比如“如果检索结果与问题无关请直接说明无法回答”。再一个是答案是否忠实于检索片段这可以通过对比生成内容和检索内容的语义重合度来做自动化评估。如果发现模型经常“自由发挥”考虑降低temperature或者换用更强调指令跟随的模型。链路设计方面我提到查询改写、HyDE、多路召回这些进阶手段。特别是查询改写很多用户提问是口语化的、指代不清的直接拿去检索效果很差。先让LLM把口语化query改写成适合检索的关键词组合再走embedding召回会有立竿见影的效果。这种题目没有唯一正确答案但要让面试官看到你有完整的思考框架而不是想到什么说什么。我在答的时候先列了一个“检索-生成-链路”的三层框架再在每一层下面填具体措施这样条理性就出来了。5. 常见问题与排查技巧实录这些坑我亲眼见过5.1 笔试中的“雷区”与避坑判断考完复盘时我把几个最容易踩的坑整理了一下这里直接给出一张速查表方便大家对照自查。风险点典型表现避坑策略时间分配失衡选择题纠结太久编程题空着先做会的难题标记后跳过最后再处理多选题因少选扣分不确定的选项乱选导致倒扣不选不确定的选项保住基础分RAG概念停留在科普层只知道“检索增强生成”六个字动手搭一个RAG理解切分、召回、重排全流程代码题只写主逻辑边界条件未处理判题失败写完核心代码后专门检查空值、重复值、边界值场景题想到哪说到哪答案零散没有框架先给框架再填细节体现系统思考关于多选题少选扣分这个问题我想展开说一下。联想的规则是少选得一半分多选、错选不得分甚至倒扣。这意味着最安全的策略是“拿不准的选项绝不选”。我在考场上遇到一道关于BatchNorm的题一个选项表述比较模糊我判断出题人可能的意图后还是不选最后那道题我只选了最有把握的两个选项。虽然没拿满分但至少没丢分这种策略在笔试里是划算的。5.2 考前复习重点推荐别只盯着题库很多人准备笔试会陷入一个误区就是大量刷题。但针对联想这类把“工程能力”放在高权重的笔试我的建议是刷题和项目实践两手抓。选择题的机器学习深度学习部分市面上的经典题库仍然有效但不要机械背答案要把每个选项为什么对、为什么错搞清楚。大模型应用部分最好的复习方式是动手做一个完整的RAG对话系统哪怕是很简单的版本。你不需要多复杂的代码关键是整个过程里你会碰到问题——切分粒度怎么定、embedding效果不好怎么办、检索结果怎么排序这些亲身踩过的坑才是笔试里最能帮你的东西。编程题部分建议重点练三类题双指针与滑动窗口、设计数据结构LRU、LFU、图或树的遍历。这些在联想的笔试里出现概率很高。另外有条件的话在笔试前熟悉一下在线编程环境有些平台不支持断点调试代码要一次写对这对“思路清晰再下手”的要求更高。5.3 场景题的隐藏考察点你是否理解RAG全链路前面说了场景设计题的答题框架这里再补充一个更深层的理解。这种题目表面考RAG实际也在考察你对“系统效果”这个概念的理解。很多候选人一上来就提“换个更好的大模型”这个思路恰恰是最不符合工程实践的——因为RAG系统的答非所问根因往往不在生成端而在检索端。我在这类题上比较有底气是因为过去半年我做了两个RAG项目亲身体会过检索质量对最终效果的影响。有一次我把PDF文档按固定500字切块结果大量技术术语被拦腰截断导致检索召回的相关度很差。后来改成按章节和段落边界切分效果立刻提升。这种对技术细节的体感是看多少篇文章都换不来的。所以如果你还有时间准备我强烈建议花一个周末做一个最小的RAG项目加载几篇文档做切分和embedding存入向量库写一个检索函数再接入大模型生成回答。整个过程不需要超过200行代码但做完之后你对RAG的认知会和之前完全不一样。6. 关于岗位匹配度的一些体会考完笔试最大的感受是联想的AI工程师岗不是那种“只要你算法功底强就可以”的岗位它对端到端工程能力的要求很高。从笔试题目来看它默认你已经具备基本的机器学习深度学习基础更关注你能不能把这些基础用到LLM应用开发中去。如果你现在还有时间准备我建议你按这个优先级来先把Transformer和大模型的原理搞透再动手做一个RAG项目然后刷一些数据结构和算法题保持手感。三者做好联想的笔试至少不慌。最后分享一个我自己的仪式感笔试前几天我会把过去做过的项目从需求到实现整个在脑子里过一遍尤其是踩过的坑和最后怎么解决的。这比临时抱佛脚刷题有用得多。因为笔试里最有含金量的那些题考的就是你面对真实问题时的判断力而这种判断力只来自实践积累。希望这份复盘能帮到正在准备秋招的你。