求职指南 · 转行大模型指南
大模型系统设计和编码环节怎么准备
大模型岗的系统设计不是让你背架构图,而是看你能不能把一个模糊需求(比如"做一个企业知识库问答")拆成可落地、可评估、可控成本的系统。面试官要的是权衡:数据怎么切、检索怎么召回、效果怎么评、成本和延迟能不能扛、模型挂了怎么降级。编码环节反而轻,多是基础数据结构/算法加一小段工程实现,不必刷到竞赛难度。这一页给你系统设计的答题框架和编码环节的准备重点。
作者:吴师兄 | 适合:准备大模型岗系统设计与编码环节的转行者 | 前置:知道 RAG/Agent 是什么,最好做过一个项目
先给结论:考的是"把模糊需求拆成能落地、能评估、能控成本的系统"的能力,不是让你把组件画满一张图。
大模型系统设计题和传统后端系统设计的最大不同,在于多了三条你必须主动说清的链路:检索/召回怎么设计、效果怎么评估、成本和延迟怎么控。传统后端设计里"高可用、可扩展"你已经熟,但一个 RAG 系统里"答得准不准、幻觉多不多、一次问答花多少钱、模型超时了返回什么"这些,才是面试官真正想听的。下面这张清单表以"设计一个企业知识库问答系统(RAG)"为主线,把该说清的步骤串起来。
学习内容与项目面试，在同一条路上。
| 步骤 | 要说清什么 | 常见失分点 |
|---|---|---|
| 澄清需求与规模 | 文档量级(几千还是几百万)、用户并发、更新频率、准确性要求、有没有权限隔离 | 不问就动手,默认一个自己想当然的规模 |
| 数据与索引 | 文档怎么解析、按什么粒度切块、元数据怎么带、索引多久重建、增量更新怎么做 | 只说"存进向量库",说不清切块策略和更新机制 |
| 检索/召回方案 | 向量检索 + 关键词(BM25)混合、召回多少、要不要重排、多路召回怎么融合 | 只上单路向量检索,答不上召回不全怎么办 |
| 模型与 Prompt | 选什么模型、上下文怎么拼、引用怎么带、幻觉怎么约束、要不要 function calling | 把 Prompt 当细节略过,不提引用和防幻觉 |
| 评估怎么做 | 检索命中率、答案准确性、幻觉率怎么测,离线评估集 + 线上抽样,用不用 LLM 打分 | 完全不提评估,或只说"人工看一眼" |
| 成本与延迟 | 一次问答的 token 成本、检索+生成的延迟拆解、缓存怎么加、长文档怎么省 token | 报不出量级,一句"用大模型就行"糊过去 |
| 降级与兜底 | 模型超时/限流/挂了返回什么、检索为空怎么办、敏感问题怎么拦 | 只画正常链路,答不上任一环失败怎么办 |
| 监控与迭代 | 埋点哪些指标、bad case 怎么回收、怎么形成"发现问题→补数据→再评估"的闭环 | 上线即完事,没有迭代闭环 |
这张表的用法:面试时按这个顺序推进,每一步先给方案再说权衡。真正拉开差距的是评估、成本、降级三块——大部分人能把前四步的组件说出来,但一被问"你怎么证明它答得准""一次问答多少钱""模型挂了怎么办"就卡壳。把这三块讲扎实,你就已经赢过多数候选人。
结论:题型不多,核心是 RAG 问答、Agent 工作流、高并发推理服务这三类,以及在它们之上的评估和成本变体。
不同题型考察重点不同,准备时对号入座,把每类的关键权衡点和对应的站内深挖章节过一遍。
| 题目 | 考察重点 | 站内承接 |
|---|---|---|
| 设计一个企业知识库问答系统(RAG) | 切块/检索/重排、防幻觉、引用、评估闭环 | RAG 系统怎么从零搭起 |
| 设计一个多步 Agent / 工作流(如深度调研助手) | 任务拆解、工具调用、记忆、循环终止、失败重试 | Deep Research 这类 Agent 怎么设计 |
| 设计一个高并发大模型推理服务 | 批处理、KV Cache、并发调度、显存、限流降级 | 服务化章 和 推理优化题库 |
| 设计一个带评估的内容审核/分类系统 | Prompt 分类 vs 微调、评估指标、误报漏报权衡 | 模型架构题库 |
| 设计一个低成本的长文档摘要/问答 | 长上下文 vs 分段检索、token 成本、缓存 | RAG 系统怎么从零搭起 |
准备策略:RAG 问答和 Agent 工作流是应用开发岗的绝对高频,必须能白板画出来还能扛住追问;高并发推理服务偏平台/推理工程岗,应用岗知道大致方案和瓶颈即可,不用深到会写 kernel。
结论:大模型岗的编码环节普遍比纯算法岗轻,多是基础数据结构/算法加一小段工程实现,不必刷到竞赛难度,但基础不能空。
编码环节大致分两种:一种是常规的算法题,但难度多在 LeetCode 中等及以下,考数组、哈希、双指针、二叉树、简单 DP 这类基础,极少出竞赛级难题;另一种更贴岗位,给你一小段工程化实现,比如手写一个简单的检索打分函数、实现一个带重试和超时的 API 调用、写个滑动窗口做文本分块、算两个向量的余弦相似度。后一种考的是"你平时是不是真在写这类代码",生疏不了。
给准备建议:算法基础按 LeetCode 中等题过一遍高频类型即可,别为大模型岗去啃 hard 专题;把时间更多花在能手写小段工程实现上——检索打分、重试封装、分块、相似度计算这些,面试时能不查资料写出来,比多刷十道 hard 有用。
结论:算法编码和系统设计,这两类人的强弱项正好相反,补的方向也相反。
| 人群 | 相对强项 | 该重点补什么 |
|---|---|---|
| 研一/研二在校生 | 算法编码通常是强项,刷题手感好、基础扎实 | 补系统设计里的工程视角:评估怎么设计、成本怎么估、降级兜底怎么想。这些学校里不教,却是面试拉分点,拿自己做过的项目往这个框架上套着练 |
| 3 年 Java/后端 | 系统设计是主场,高可用/扩展/数据管线是你多年的肌肉记忆 | 把大模型特有的链路补进你熟悉的高可用设计里:检索召回、效果评估、token 成本、模型降级。编码环节别荒废,把基础算法手感捡回来,大模型岗不难但会考 |
关键差异:在校生要把"系统能跑"升级成"系统可评估、可控成本、可降级";在职后端则是把已有的系统设计能力"翻译"到大模型场景,你缺的不是设计能力,而是检索、评估、成本这几个大模型专有词汇和它们的权衡。分别可以对照 研究生怎么转大模型 和 Java 后端转大模型的路径。
最常见的翻车:系统设计一开口就往白板上堆组件,向量库、缓存、网关、消息队列全画上,图画得很满,却说不清怎么评估效果、一次问答多少钱、模型挂了怎么降级。
这种答法看着专业,实则暴露短板。面试官画框图不是目的,他要的是听你在每个选择点上的权衡:为什么用向量检索还要加 BM25,召回多少条是省成本还是保召回,重排值不值那份延迟,模型超时了是返回缓存、降级到小模型还是直接报错。你把组件堆满但答不上这些,给面试官的判断是:这人见过架构图,但没真正对一个大模型系统的效果和成本负过责。
正确的打开方式是慢下来:先花一分钟澄清需求和规模,再顺着数据→检索→模型→评估→成本→降级的主线走,每一步给方案的同时主动说出取舍。宁可组件少画两个,也要把评估和降级这两块讲透——那才是加分项。
主要多了三条必须主动讲清的链路:检索/召回怎么设计、效果怎么评估、token 成本和延迟怎么控。传统后端的高可用、可扩展你照样要谈,但一个 RAG 或 Agent 系统里"答得准不准、幻觉多不多、一次问答多少钱、模型挂了返回什么"才是大模型岗特有的拉分点。后端出身的人设计能力是主场,缺的是这几个大模型专有环节。
按主线推进:先澄清文档规模和准确性要求,再依次讲数据切块与索引、检索召回(向量+关键词混合、要不要重排)、模型与 Prompt(引用、防幻觉)、评估(命中率/准确性/幻觉率怎么测)、成本与延迟、降级兜底、监控迭代。每步先给方案再说权衡,重点把评估、成本、降级三块讲扎实,那是多数人卡壳的地方。
普遍比纯算法岗轻。算法题多在 LeetCode 中等及以下,考数组、哈希、双指针、二叉树、简单 DP,极少竞赛难题;另一类是小段工程实现,比如手写检索打分、带重试的 API 调用、文本分块、余弦相似度。基础算法过一遍高频类型即可,别啃 hard;更该练的是能不查资料手写这些小段工程代码。
评估、成本、降级这三块。"你怎么证明它答得准"考评估,你得说得出检索命中率、答案准确性、幻觉率怎么测,离线集加线上抽样;"一次问答多少钱、延迟多少"考成本,得报得出量级和优化手段;"模型超时或挂了返回什么"考降级,得有兜底方案。组件谁都会画,这三问答不上就露怯。