企业官网建设流程全解析

最近团队开放了几个大模型开发工程师的职位，简历收了不少，我也连续面了两周。筛简历时有个很直观的感受：技术名词写得满满的，但只要顺着名词往下追问，很多时候对方就接不住了。

很多人以为把招聘JD里出现过的词都堆到简历上，就能拿到面试机会。但实际上，面试官看技术名词，看的不是你有没有见过这个词，而是你懂不懂这个词背后那条完整的技术链路。大模型开发工程师岗位，本质上是在找能把模型训练、微调、部署、评估这一整条流水线跑通的人。每一个名词背后，都对应一个真实的工程环节或者一道坎。

这篇文章不打算写教科书式的名词解释，而是从招聘和面试的视角出发，把大模型开发工程师岗位上反复出现的核心技术名词拉通讲一遍。讲了什么、为什么面试官要问、问的时候到底在考什么，我都会说清楚。不管你是准备跳槽的候选人，还是想转行入局的新人，又或者是要搭建团队的技术管理者，应该都能从里面找到对自己有用的信息。

1. 从招聘JD看大模型开发到底在要什么

1.1 两类岗位，两套名词体系

大模型开发工程师这个职位，名字看上去是一个岗位，实际招聘市场上早就分化成两条线了。

算法向的岗位，JD里常见的关键词是预训练、SFT、LoRA、RLHF、DPO、对齐、评测。这类岗位更靠近模型侧，做的事情是把基座模型变成能完成特定任务的产品化模型。面试的时候，重点会考察你是否理解训练流程中每一步的动机，以及遇到模型效果不达标时是否有诊断思路。

工程向的岗位，JD里常见的关键词是vLLM、TensorRT-LLM、量化、蒸馏、推理优化、高并发服务、RAG、Agent。这类岗位更靠近应用侧，要做的是把一个大模型跑起来，跑得快，跑得稳，还要把它接进业务系统里。面试的时候，面试官更关心你是不是了解推理过程中的资源瓶颈，能不能设计出可复用的服务方案。

不少候选人两头都沾一点，但各自都不深入。这在初级岗位还行，到了高级岗位，两条线里至少得有一条是你能扛起来的。

1.2 技术名词的分层：基础、算法与工程

在筛选简历的时候，我习惯把候选人堆出来的技术名词分成三个层级看。

基础层，包括Transformer、Attention、Tokenizer、Embedding、上下文窗口、Softmax。这一层考察的是基本功。大模型虽然有各种花哨的名字，底层骨干依然是Transformer结构，这个结构里的任何一环有理解偏差，后面学什么都会飘。

算法层，包括预训练、微调、指令微调、参数高效微调、LoRA、QLoRA、人类反馈对齐、强化学习、DPO。这一层考察的是训练能力。候选人最好是能把训练一个模型的全流程讲明白，而不是只记得几个跑了多少轮的指标。

工程层，包括推理优化、KV Cache、PagedAttention、量化、蒸馏、分布式推理、模型服务化、RAG检索、向量数据库、评测回流。这一层考察的是落地能力。说白了，模型效果再好，不能上生产、不能支撑业务流量，一切还是白搭。

这三层不是平行的。基础层是底座，算法层是把模型调好，工程层是把模型用好。你在简历里写了哪些词，面试官就会按对应层级去追问。

2. 模型训练与架构名词：别只会说“Transformer”

2.1 Attention与多头机制：能画出计算图才算过关

几乎每份简历都会写Transformer，但能把这个词说透的人不多。

面试时我常问一个问题：给你一个句子，Transformer是怎么算出每个词的新表示的？很多候选人会说“用注意力机制算每个词和其他词的相关性”，这个回答方向对，但细节经不起追问。一追问Q、K、V到底从哪来，注意力权重是怎么归一化的，输出向量又经过了哪些线性变换，就开始含糊了。

这里还是得把链路理清楚。输入是一串token，每个token先经过Embedding得到向量，再和位置编码相加，得到模型的原始输入。然后进入多头注意力模块。每个头里面有三组可学习的权重矩阵，分别把输入向量映射成Query、Key、Value。Query和Key做点积，得到的是两个位置之间的相关度。相关度要除以向量维度的平方根，这是为了避免点积结果过大导致Softmax进入饱和区。Softmax归一化之后得到注意力权重，再和Value加权求和，就得到这个头在当前词上的输出。多个头的输出拼接起来，再过一次线性层，跟原始的输入做残差相加，再送往层归一化和前馈网络。

为什么要多头？我的理解是，单组QKV只能学一种“匹配模式”，多头相当于用多组不同的映射去捕捉不同类型的依赖关系。有的头专门关注相邻词，有的头关注远距离词，有的头关注语法角色。这个机制让Transformer能同时建模局部和全局信息，是大模型能吸住长文本语义的根本原因。

面试的时候，如果你能主动说出“多头注意力本质上是多种关系子空间的并行建模”，这句话会明显加分。

表：Transformer核心模块记忆速查

2.2 Tokenizer与上下文窗口：细节里藏着分水岭

Tokenizer这个词在招聘JD里出现的频率不算高，但面试官多半会问。原因是，tokenizer直接决定了模型接收输入的形式，也直接影响了计算成本和上下文窗口的利用率。

业界目前主流的是BPE这类子词切分方法。它会把常见的词保留成完整token，稀有词拆成子词，数字和罕见字符再降级成字符级片段。这套流程让词表大小可控，又比纯字符切分更能保留语义单元。实际用模型的时候，你会注意到“长度”有两种标准：一个是你肉眼看到的字符数，一个是模型实际处理的token数。平均一个汉字大概对应1到2个token，英文一个单词大致对应1到1.5个token。这个换算在估算成本时非常重要，很多新手写离线批量任务时，没换算token数，结果费用比预期翻倍。

上下文窗口是另一个被经常挂在嘴边的词，但理解层面往往停在“越大越好”。面试如果往深里问，通常会落在两个点上：一是长文本的注意力计算复杂度是平方级的，窗口翻倍，计算量可能涨三倍四倍；二是单纯把窗口加大，模型并不能自动学会充分利用长距离信息。解决思路里涉及到RoPE这类旋转位置编码，以及各种各样的注意力稀疏化方案。能聊到这一层的人，在工程理解上通常是有实操积累的。

2.3 预训练、微调与对齐：三步构成训练主线

大模型开发岗位的名词里，预训练、微调、对齐这三个词的关系，值得先说清楚。

预训练的目标是让模型学会“语言”。在这阶段，模型在海量文本上做自监督学习，任务是预测下一段文本。它学到的是词与词之间的统计规律、知识结构的编码方式、以及基本的推理雏形。预训练成本极高，绝大多数公司的实际业务场景接触不到完整预训练流程，最多是在已有基座模型上做增量预训练。

微调是让模型学会“任务”。常见的做法是指令微调（SFT），你把几千上万条“指令+期望回答”喂给模型，让它调整输出风格和行为方式。它的核心思想是让模型从“会说话”变成“听得懂指令、答得对问题”。

对齐是让模型的价值观和输出边界符合人的期望。早期的方案是RLHF，先训练一个奖励模型，再用强化学习去优化策略。现在更常说DPO，省掉奖励模型训练环节，直接用偏好数据优化。面试官问“RLHF和DPO有什么区别”，其实想听的是：RLHF需要显式训练奖励模型、训练过程不稳定；DPO直接基于偏好对计算损失，流程更简单、更适合小团队复现。

全套流程走下来，模型才能算是一个可用的、负责任的产品组件。这也是大家常说的训练流水线：预训练打底，微调适配，对齐兜底。

3. 微调与模型控制名词：从“会调参数”到“会调教模型”

3.1 LoRA、QLoRA与PEFT：小显存也能微调大模型

LoRA这个词，在当前的微调相关JD里几乎是必出现的。原因很现实：全量微调大模型要的显存不是一般团队能给得起的，而LoRA这类参数高效微调方法大幅降低了门槛。

LoRA的核心逻辑并不复杂。模型微调的时候，权重更新量通常可以视为一个低秩矩阵，意思是不需要修改所有原始参数，只需要在原始矩阵旁边添加一个低秩的旁路分支。训练的时候只更新这个很小的旁路，原始大参数保持冻结。这样一来，可训练的参数量常常只有总参数的百分之一以内，显存占用和训练时间都会显著下降。QLoRA更是进一步把底座模型量化成4bit来加载，让一张消费级显卡也有机会微调几十亿参数的模型。

我面试的时候会问候选人：用过LoRA，但你知道LoRA的低秩矩阵秩取多少，根据什么定的吗？很多人答不上来。实际经验是，秩选择需要在表达能力和资源占用之间寻找平衡。秩太小，模型学不进去；秩太大，又失去了参数高效的意义。常见的基线做法是先用8到16跑通流程，观察评估指标，再做拉伸实验。

提示：简历里写“熟悉LoRA微调”没问题，但最好同时能说清楚你用它在什么任务上省了多少显存、微调后指标提升了多少。没有具体数字支撑的名词，在面试官眼里和没写差不多。

3.2 RAG、Embedding与提示词工程：把知识和上下文交给外部

微调之外，另一条主流的技术路线是RAG（检索增强生成）。它的出发点很朴素：模型参数里存不了所有知识，而且知识会过期，那就把检索外部知识库的能力“接到”模型前面。业务上一旦有私有数据问答、企业知识库这类需求，RAG几乎是都会提到的方案。

RAG链路里有一串名词需要逐个理解。Embedding负责把文本块转换成向量，语义相近的文本在向量空间里距离也接近。向量数据库负责存储和检索，做相似度搜索时只需要在索引里找最近邻。Chunking是切分策略，直接决定检索单元的大小和质量。重排模型则是在粗召回之后，把真正命中问题的内容往前排。整条链路里，任何一个环节质量不够，都会影响最终回答效果。

很多候选人聊到RAG时，会把重点全放在vector search上面。但实际业务里，召回率低、上下文被无关内容污染、分块把语义切断，才是更常见的坑。面试官如果要考你这块，大概率会让你描述一个知识库问答系统的完整流程，并追问一句“如果检索结果不准，你会从哪些方向排查”。能脱口而出几个具体排查点的人，说明真的做过。

提示词工程和RAG经常一起出现。早期大家觉得给模型写几句很玄的提示词就能改善效果，现在更倾向于把它当成一种系统设计技术：System Prompt用来设定模型角色和输出边界，Few-shot示例用来教会模型输入输出格式，CoT思路则通过引导模型分步推理来提升复杂任务的准确率。这条线的发展其实也说明了一个趋势：调用现成模型做应用开发时，提示词和检索策略往往比重新训练一个模型更重要。

3.3 对齐、幻觉与安全防护：大模型落地前必须过的一道坎

大模型的应用有一个天然短板：它有可能一本正经地生成不真实的内容，也就是幻觉问题。招聘JD里出现“对齐”“安全防护”“幻觉治理”之类的词，往往就是为了应对这些问题。

对齐在这里是一个偏技术的概念。它要让模型的输出更符合人的偏好，并且减少有害内容。技术实现上包括偏好数据构建、反馈优化、输出侧过滤拦截等。如果模型要开放给大规模用户使用，这些基础设施基本都是一票否决项，做不到就不能上线。

面试中这个方向的提问通常有两种。一种偏原理：如何构建偏好数据、如何设计自动评测方案来发现坏案例。另一种偏工程实践：你怎么给模型加一层输出审核，如何设计兜底策略。能把技术措施讲清楚、又能结合具体产品来谈落地路径的人，在安全对齐这个话题上确实算有储备。

4. 推理部署与服务化名词：真本事都露在这一层

4.1 从GPU显存瓶颈到KV Cache与PagedAttention

训练好或者微调好的模型，总归要部署到服务里给用户用。这一步会突然冒出非常多工程向名词，也是“大模型开发工程师”和“只会调API的人”之间的分水岭。

先说显存估算。部署大模型时，权重本身就会占掉大量显存。以70B模型为例，FP16精度下权重就要占用大概140GB，单卡根本放不下，得用多卡推理或者走量化路线。这还没算推理过程中需要的中间激活值。所以“显存怎么算、怎么省”是部署面试的第一个问题。

推断过程中还有一个绕不开的概念是KV Cache。模型生成每个token时，需要把历史token对应的Key和Value缓存下来，避免重复计算。序列越长，Cache占用的显存越大。动态上下文的场景里，长时间运行的对话会让KV Cache持续膨胀，变相压缩了Batch Size和并发能力。业界标志性的解决方案是PagedAttention，思路是模仿操作系统的虚拟内存页来管理KV Cache，按需分配、按页存储，大幅提高显存利用率和批处理吞吐量。这个思想已经在很多主流推理框架里成为标配。

面试里如果能把这条链路讲清楚：显存不足→KV Cache膨胀→PagedAttention按需分页→吞吐量提升，那这题基本就稳了。

4.2 量化、蒸馏与推理加速：把大模型塞进普通机器

大模型上生产环境和普通模型最大的差异在于：模型太大、推理太慢、成本太高。所以推理加速和模型压缩相关的名词，必然出现在招聘JD里。

量化是降低模型权重或激活值精度的技术。把FP16精度降到INT8，能省接近一半显存，推理速度也明显提升；降到INT4，模型可以塞进更小规模的设备里。量化分为训练后量化和量化感知训练两类，前者像GPTQ、AWQ这种，实现起来相对简单；后者在训练过程中就让模型适应低精度，效果更好但流程更复杂。面试官常问的问题是：量化和微调能同时做吗？顺序怎么安排？一般经验是先微调后量化，因为微调会让权重分布有变化，量化精度是建立在你的目标权重之上的。

蒸馏是另一条常见路线。用能力强的教师模型生成高质量输出，让学生模型去模仿学习和收敛。它的优势在于直接产出一个更小的模型，推理和部署都比原始大模型更轻量。面试官如果看到你简历上有蒸馏经验，多半会追问一个问题：你是怎么衡量学生模型是否学到了教师模型能力的？能说出“不只看最终指标，还要分维度去对比采样的输出质量”的候选人，说明是真的做过工程评估的。

4.3 分布式并行、吞吐与延迟指标：面试中的量化考察

模型大到单卡显存放不下时，就涉及分布式并行。数据并行是每个卡上都放一份模型，大家处理不同batch的数据，适合模型较小的场景。张量并行是把一个层的矩阵切到多张卡上，适合模型较大到单卡放不下的情况。流水线并行是按层切分，前面卡算完传给后面卡。实际部署中往往混合使用。面高级工程师时，我一般会让对方估算一个案例：给你一定量GPU，怎么设计部署架构来满足业务压力。这时拼的就是对并行策略和显存计算的理解。

除了架构设计，服务和性能指标同样会被反复提及。首token延迟（TTFT)反映模型响应的快慢，生成速度（TPOT）是每个token的平均输出时间，总吞吐量则决定了服务能支撑多少并发。这三个指标在业务上就是用户体验和成本的化身。讨论优化方案时，常见的取舍是：优先保证TTFT时，可能会牺牲一部分吞吐；优先刷吞吐，又可能导致单路生成时间变长。

这一层是生产环境的真实压力测试。模型能力再强，部署方案不合理，线上照样崩。

5. 数据、评估与RAG应用：藏在名词后面的隐性门槛

5.1 模型评估：从Benchmark到人工反馈

很多岗位JD里都会写“熟悉模型评测”，但不少简历里只是带过，并没有真正展开。评估这件事，在大模型开发里的重要性并不低于训练本身。

基准评测集是最基础的一层。MMLU、C-Eval这类综合知识评测集，主要覆盖广泛的知识面和推理能力。代码类有专门的代码生成评测集，数学类有数学推理评测集。跑基准的时候有个陷阱：评测集本身可能出现在训练数据里，导致分数虚高。所以有经验的团队会自建一个与训练集隔离的评测集，这个细节也常被面试官拿来当作深挖点。

基准之上还需要人工评测和偏好评测。自动指标很难衡量回答是否流畅、是否礼貌、是否符合业务口径。常见做法是拿一批生产环境的真实问题，让标注人员从准确性、安全性、可用性等维度打分，再汇总成胜率。为了控制成本，也会把人工评测的样本量控制在合理范围内，而不是所有测试都用人。

面试如果问评测，默认想听的是：你会如何搭建一套评测方案？你如何设计评测维度？你有没有遇到基准分数高但实际体验差的案例？如果简历里只写了“跑过几个公开集”，这些追问都撑不住。

5.2 数据工程名词：训练数据的质量决定上限

数据工程在招聘JD里的位置比较微妙。有些JD明确要求候选人懂数据清洗与配比，有些JD则把它归到数据团队。但就大模型开发的全链路而言，不懂数据的大模型工程师是不完整的。

关键技术环节包括去重、清洗、敏感信息过滤。去重是为了防止模型产生记忆重叠，降低训练迭代的多样性衰减；清洗是为了去掉低质量、格式错乱、无意义反复的内容；过滤是为了让模型不接触到不应该出现在训练语料里的信息。数据的质量比例同样关键，不同来源的数据并非等比例混入就行，而是要按任务目标反复调配。

面试官考察数据能力时，往往会抛一个偏实战的问题：“喂给模型的训练数据里，如果发现某个类别的样本占了九成，你会怎么处理？”这题考的不只是技术，还有判断取舍。好的回答应该包含聚类分析、降采样、类别均衡、模型在过拟合类别上的表现诊断，而不是一句话说“直接删”。

5.3 RAG调优才是大模型应用开发的重头戏

现在大模型应用岗位的JD里，RAG几乎是个标配词。但很多人对RAG的理解仅止于“文档切块+向量检索+拼进提示词”。实际调优过程中，每一环节都有大量细节。

分块策略直接影响检索召回质量。块太小，可能会截断关键信息；块太大，又会把无关内容一并塞进提示词。分析文档结构、代码块、表格时，需要针对格式定制切分逻辑。检索阶段也经常要设计父子块结构：先用大块检索上下文，再返回精细的小块内容。重排阶段要考虑用轻量模型做初筛、再配合重排模型提升前几位相关度。最后还有上下文组装策略，要保留语义完整、又要控制长度预算，还得动态去重。

面试官在聊到RAG时，特别爱问“你做过哪些系统性的调优实验”。这个问题的底层逻辑是：你有没有把RAG当作一个动态系统去迭代，而不是搭完demo就当作完成。能答出几个有对比数据的实验方向，例如“从每召回5段降到3段，回答准确率提升了两个点”，在面试中的说服力会强很多。

6. 面试现场：高频问题与避坑指南

6.1 十个高频面试问题速查

结合我自己的面试经验，以及朋友团队的人力反馈，下面这些问题是招聘大模型开发工程师时反复出现的：

1. Transformer的注意力机制是怎么计算的？多头注意力的意义是什么？
2. 训练一个私有化模型时，你会选择全量微调还是LoRA？为什么？
3. 调参过程中发现模型在某个能力上有明显短板，你会优先怀疑哪个环节？
4. RAG链路里，检索不到相关内容时，你如何定位是切分问题还是检索模型问题？
5. 大模型部署的显存如何估算？KV Cache过大时你能想到哪些对策？
6. 为什么在产业场景里绿色量化比全精度推理更常见？量化后模型效果变差，你会怎么调？
7. 你做过哪些模型评估？评估结果和真实用户感受不一致时，你如何决策？
8. 项目中使用的训练数据是怎么清洗的？类别不均衡你会怎么处理？
9. 线上并发量突然涨了一倍，你会优先扩容还是先优化推理性能？判断依据是什么？
10. 如果只需要完成一个小型客服问答应用，你会选择提示词工程还是微调？为什么？

这些问题没有一个能靠背名词蒙混过去。它们考察的，是你是否在真实的模型开发循环里待过。

6.2 简历里技术名词的正确写法

很多简历最大的问题不是名词写少了，而是名词之间没有关联，也没有证据支撑。“熟悉Transformer”“了解LoRA”“掌握RAG”这种并列式写法，在筛选者眼里几乎等于没有有效信息。

比较好的写法是用“场景+动作+结果”来描述技术名词。比如，“基于LoRA对开源的7B级模型进行指令微调，用8张显示卡完成训练，在多轮对话任务上相对微调前提升12个百分点，单轮推理耗时可接受”。这种写法不仅带出了技术名词，还展示了工程量和成果。

再比如，“搭建了基于RAG的客服问答系统，采用父子分块和重排策略，在模拟业务数据集上召回命中率从72%提升到89%”。这种描述能立刻让面试官判断出你的技术深度和使用边界。

反过来，“深入理解Attention机制”“熟练使用PEFT进行训练”这类词如果没有数字支撑，面试官大概率不会继续深挖，而是会直接从另一个角度随机抛一个问题来试探你的下限。简历的最佳状态是一半名词能引出对话，一半数字能证明价值。

6.3 我的筛选习惯与真实体会

做这个岗位的招聘时间越长，我越会发现一个规律：简历名词和最终技术定级之间不是强相关。真正能区分水平的，是候选人能不能把这些名词通过逻辑串联起来，讲清楚“我为什么会在这个场景下选择这个方案”。

我自己在筛简历阶段有一个习惯。先看对方有没有在某个特定领域里连续布局，而非零散地接触各种工具链。一个只有“用过”经验的人，和一个“深挖过某一个方向、遇到问题自己兜回来”的人，简历呈现的气势完全不同。

另外，我也会留意候选人是否了解“为什么”的那部分。从能说“我用了LoRA”到能说“我为什么在对应场景里不选全量微调而选LoRA，最后效果和资源成本各是什么水平”，这段距离其实就是一到两年项目积累的差距。目前这个岗位的供给市场上，很多人在“术”的层面已经磨得很熟，但在“理”的层面还差着工夫。如果你能早点补齐这一层，面试的竞争力会明显上一个台阶。