算法工程师

人工智能与数据
└─ 模型与策略侧
    ├─ 机器学习工程（MLOps）      ← L2-人工智能与数据-02-机器学习工程MLOps
    ├─ AI 应用与提示工程          ← L2-人工智能与数据-03-AI应用与提示工程
    ├─ 算法工程师                 ← ← 本篇
    ├─ 推荐与搜索算法             ← L2-人工智能与数据-06-推荐与搜索算法
    └─ 大模型应用工程师           ← L2-人工智能与数据-07-大模型应用工程师

领域树分支为本库自建的组织结构，非官方分类；官方职业分类中与本篇最近的是「人工智能工程技术人员」（职业编码 2-02-10-09）。

一句话定位：算法工程师是模型与策略侧的通用岗——它不绑定某一类具体业务方向，凡是以「把业务问题建成可部署、可度量的模型」为主要交付物的位置，都落在这个岗名下。方向细分（推荐与搜索、大模型应用等）在领域树中单列，本篇只讲公共底座，以及与各细分岗的边界。

本库之所以把这个通用岗与几个细分岗并列建页，是因为求职时最容易出错的一步就是把"算法工程师"当成一个具体岗位去投：招聘方说的算法工程师，可能在做搜索排序，可能在做风控评分，也可能在做大模型应用——名字一样，能力要求与工作内容差得很远。本篇的作用是先把这个公共底座讲清楚，遇到具体岗位时再对照细分页判断。

一句话定义：算法工程师是以统计学习、优化理论和工程化能力，把业务问题建模为可部署、可衡量、可迭代的模型服务的岗位；日常用 Python 与机器学习框架完成数据理解、特征工程、模型训练与评估、效果迭代与线上监控，并把模型效果转化为业务指标的提升。

先说清楚这个岗位的三种叫法。 国内招聘市场上，同一件事至少有三个名字：算法工程师（偏工程与落地）、机器学习工程师（偏训练与部署，与 MLOps 有交叠）、数据科学家（偏研究与洞察，见附一第 18 条美国劳工部职业库口径）。三者的实际分界不在名字，而在交付物：交付能上线的模型 → 偏算法工程；交付模型流转的基础设施 → 偏 MLOps；交付结论与决策建议 → 偏数据科学。面试时把交付物问清楚，比看岗位名可靠。

职责边界（五类日常）

一、数据理解与特征工程

这一环决定模型效果的上限，也决定算法岗与数据岗的分野。数据治理与 BI 岗位交付的是数据资产——干净的、有标准、可被多方使用的数据；算法工程师交付的是特征——从数据里提炼出对预测有信息量的变量。同一份用户行为日志，数据工程侧关心它有没有丢、有没有重复、字段口径对不对；算法侧关心的是「从这份日志里能造出什么能提高点击率的信号」。

特征工程里真正难的不是造变量，而是判断哪些变量不能造。目标变量如果通过某个特征间接泄漏进了训练集，模型在离线评估上会漂亮得不真实，上线后一落千丈——这类事故叫标签泄漏，它比模型选错更常见，也更难发现，因为所有指标都指向"这个模型很好"。另一类高频问题是训练与线上不一致（training-serving skew）：离线算特征用的是昨天全量数据，线上算特征用的是此刻的部分数据，两边口径不同，模型看到的输入分布就不一样。Google 的《Rules of Machine Learning》把这条列为 ML 工程初期最重要的规则之一（附一第 8 条）。

• 动作：数据探索与质量核对、定义与实现特征、处理缺失与异常、构造训练／验证／测试切分、设计特征上线的计算口径。
• 产出：可复现的特征集与特征定义文档；训练数据的切分方案。
• 常见分歧：特征该在离线造还是在线上实时算。判据是时效性与一致性成本：变化慢的特征（用户画像、历史统计）离线算好存起来更省；变化快的（实时行为、会话状态）必须在线算，但两边口径要能对得上。所有"离线造、线上查"的特征，都要提前想清楚回填与更新怎么保证一致。

二、建模与训练

这是外人以为算法工程师"全部工作"的部分，实际占比远低于想象，但门槛确实在这里。

建模的第一件事不是选最先进的模型，而是先跑通一条最简的基线。Google 的 ML 规则第一条就是这个意思：在确认基础管线可用之前，不要上复杂算法；因为此时出问题，你分不清是数据、管线还是模型的问题。《Rules of Machine Learning》把它概括为三个阶段——先有第一条端到端的管线，再做特征工程，最后才是模型精修（附一第 8 条）。CRISP-ML(Q) 提供的六阶段标准过程（业务与数据理解 → 数据工程 → 模型工程 → 应用质量保证 → 部署 → 监控与维护）同样把"理解"排在建模之前（附一第 9 条）。

训练本身是工程活：超参数怎么搜、要不要交叉验证、正负样本怎么平衡、训练损失曲线怎么读、过拟合与欠拟合各自对应什么处置。工具层面，scikit-learn 提供的是估计器的统一接口（拟合、预测、预处理、模型选择与评估），适合中小规模表格数据的快速迭代（附一第 11 条）；PyTorch 提供的是完整训练循环所需的积木（张量、数据集与 DataLoader、变换、模型、自动微分、优化循环、模型存取），适合需要自定义网络结构的场景（附一第 12 条）。选哪个不是技术品味问题，是问题规模与迭代速度的权衡——能用简单模型解决的业务问题，上深度模型往往只是增加了维护成本。

• 动作：基线搭建、算法选型与对比、超参数搜索、交叉验证、训练与诊断、模型版本管理。
• 产出：可复现的训练脚本与模型产物；模型对比与选型说明。
• 常见坑：把离线指标的提升当成业务效果的提升。离线评估用的历史数据里没有"模型上线后用户会怎么反应"，而推荐、风控这类场景的效果恰恰取决于这个反事实——必须靠线上实验来补，离线指标只能用来筛掉明显不行的方案。

三、评估与可解释性

评估环节最容易被做假的是指标选择。同一个模型，用准确率看很好，用召回率看很差——这不是模型的问题，是指标没选对。分类问题常见 AUC、精确率／召回率、F1；排序问题用 NDCG、MAP；回归问题看 MAE、RMSE；而业务指标（转化率、通过率、坏账率）与模型指标之间没有自动的换算关系，必须逐案对齐。

可解释性在两类场景里不是加分项而是硬门槛。一类是合规与审计场景（金融风控、医疗辅助诊断、涉及个人权益的自动化决策），监管与业务方都要求能解释"为什么给这个人这个结果"；另一类是策略调优场景——如果模型是个黑箱，业务方无法基于它做人工干预与规则叠加，模型就只能做端到端的自动决策，适用面大幅收窄。

• 动作：定义模型指标与业务指标的映射、做离线与在线评估、输出特征重要性与模型解释、做公平性与偏差检查。
• 产出：评估报告（含指标定义、数据口径、结论与限制）；可解释性说明。
• 常见分歧：效果与可解释性怎么取舍。经验判据是看这个决策能不能被申诉——不能被申诉、且影响个人权益的，可解释性优先；纯效率类决策（推荐排序、库存预测），效果优先。

四、部署与线上迭代

模型上线不是"把文件传上去"。一个可用的模型服务至少要回答：推理在哪跑（离线批量算好、在线实时算、还是端上）、多久更新一次（定时重训、触发式重训、还是人工发布）、效果怎么监控（预测分布偏移、特征缺失率、效果指标衰减）、出问题怎么回滚。

这一层与 MLOps 的分工是最需要说清楚的边界。MLOps 交付的是模型流转的基础设施——可复现的流水线、可复用的环境、模型注册与打包、部署与血缘追踪、生命周期事件通知（附一第 5、7 条），其目标是让"从数据到线上模型"这件事可自动化、可审计。算法工程师交付的是模型本身——它长什么样、为什么这样设计、效果如何。实际协作中，算法工程师在 MLOps 提供的平台上注册模型、发起部署；平台的质量决定迭代速度，模型的质量决定业务价值。

一个必须记住的事实：ML 代码在真实系统里只占很小一部分。2015 年的经典论文《Hidden Technical Debt in Machine Learning Systems》指出，围绕模型的数据采集、验证、配置、资源管理、监控、元数据管理等组件体量庞大，且 ML 系统有独特的维护成本来源——边界侵蚀、熵纠缠、隐藏反馈环、未声明的消费者、数据依赖不稳定、配置债等（附一第 13 条）。不理解这一点的求职者会把"建模"当成全部，入职后才发现大半时间在处理数据和管线。

• 动作：模型服务化、A/B 实验设计与分析、监控指标建设、重训练策略、灰度与回滚预案。
• 产出：可用的模型服务与其监控；实验结论与迭代记录。
• 常见坑：只监控"服务是否活着"，不监控"模型是否还有效"。业务在变、用户行为在变、上游数据口径也可能变，模型不重训就会慢慢失效，而这种失效不会报错，只会静默地把效果拖下去。

五、业务对齐与策略转化

这一环决定算法工程师的价值能不能被看见。业务方提出的通常是"帮我提高复购率"，模型需要的是一句可优化的目标——预测什么、优化什么、在多长周期内、用什么指标衡量。把业务语言翻译成学习问题，是这个岗位区分度最高、也最容易被低估的能力。

翻译过程中经常要做取舍：预测复购的模型，是优化点击概率、还是优化长期留存？前者短期指标好看，后者才对应业务的真实目标。Google 的 ML 规则明确要求目标必须对齐可度量的产品目标、并优先长期用户满意度（附一第 8 条）——因为短期指标一旦被模型"学会"，就会出现各种形式的目标扭曲。

• 动作：参与需求定义、设计可优化目标、约定评估口径、向业务方解释模型能力与限制、推动策略落地。
• 产出：与业务共识的目标定义与评估口径；模型效果的定期复盘。
• 常见分歧：业务方想要"更好"，算法方说"做不到"。处理方式不是争论可行性，而是把边界量化——当前方案在哪个指标上到了多少、再提升需要什么代价（更多数据、更长工时、更大算力、业务规则让步）。把不可见的边界变成可讨论的数字，是这一环的核心技巧。

一个迭代周期里的实际工作流

把上述五类日常放进一次真实的模型迭代，路径大致是：

1. 问题定义与可行性判断——把业务目标转成学习问题：是分类、回归还是排序？有标签吗？标签怎么来的？数据量够不够？很多算法项目在这一步就该被否掉，因为问题本身无法被数据回答。
2. 数据探索与质量核对——看数据分布、缺失与异常、标签分布是否倾斜、有没有时间上的泄漏。这一步的产出通常是一份"数据能不能支撑这个模型"的判断，而不是模型。
3. 基线建模——用最简方法跑通端到端：简单特征 + 简单模型 + 离线评估。基线的价值是给出一个可比较的起点，之后所有改进都相对它衡量。
4. 特征与模型迭代——在基线上做特征工程与模型优化，逐项验证增量是否真实（每次只改一处，否则分不清是哪个改动起了作用）。
5. 离线评估与实验设计——确认指标口径，设计线上实验方案：分几组、看什么指标、跑多久、什么情况下判定为负。
6. 上线与实验——灰度发布、观察服务指标与效果指标、收集实验结论。实验跑出负结果也是产出，它排除了一条路径。
7. 全量与复盘——全量后继续监控效果衰减与数据漂移，评估是否需要重训；把本次的判断与踩的坑记下来。

一个容易被忽略的事实：算法工程师的时间有相当一部分花在**读数据、查口径、和业务方对齐目标、以及排查"上周还好的模型为什么这周不行了"**上。真正从零设计新模型的比例远低于外界想象。不能接受这一点的人，会把大量时间视为"被打断"，从而严重误判这份工作的日常。

相邻岗位辨析

三组最容易混的场景：

• 算法 vs 推荐与搜索算法：两者技术栈几乎重合，区别在是否绑定场景。判据是看工作对象的边界：为"所有需要预测的业务问题"提供服务的是通用算法岗；只为"用户看到什么内容／搜出什么结果"负责的是推荐搜索岗。反过来看，推荐搜索岗通常还有一层通用算法岗没有的东西——候选集、召回率、物品侧特征、冷启动这一整套场景特有概念。
• 算法 vs MLOps：这两个岗在招聘市场上经常互相渗透，分界在交付物。判据是问一句"如果模型本身不变，你还能做什么"——能做流水线、部署、监控优化的是 MLOps；答不上来、必须改模型才有工作内容的是算法。现实中两者常在同一团队，谁是主责取决于团队处在"把模型跑起来"还是"把模型跑稳"的阶段。
• 算法 vs 数据科学家：都做建模，分界在产出形态与决策位置。算法岗的产出会进生产系统，直接作用于用户；数据科学家的产出是分析报告与建议，作用于决策者。一个偏"造能力"，一个偏"给判断"——两者也会互相转，但从数据科学转算法岗需要补的是工程化与线上意识，从算法转数据科学需要补的是研究深度与表达能力。

判断口诀：把业务问题建成能上线的模型 → 算法；把模型流转做成可复用的流水线 → MLOps；为内容分发场景建召回排序链 → 推荐与搜索；用大模型（含提示、微调、检索增强）做应用 → 大模型应用；用结论影响决策而不进生产 → 数据科学／分析。

不同业务形态下的重心差异

同一个岗位名，在不同行业里做的事情差别很大，求职时值得留意：

• 互联网（推荐、广告、增长）：数据量最大、迭代最快、指标最敏感。特征是"什么都能 A/B"，模型上线以周为单位，效果衰减也快，需要持续重训与策略迭代。
• 金融（风控、反欺诈、量化）：合规与可解释性压倒一切。模型必须能解释、能审计、能追溯，上线前要过监管与内控流程；数据时效性要求高（实时反欺诈），但模型更新反而谨慎。
• 制造（质检、预测性维护、工艺优化）：样本量小、异常样本极稀缺、因果关系比相关性更重要。模型常需要与物理机理结合，可解释性是刚需——产线上不能接受"模型说这个件要报废"而说不出为什么。
• 医疗（辅助诊断、影像、临床）：数据标准不统一、标注成本高、伦理与合规要求最严。这里的算法岗往往需要与临床、法务、伦理委员会反复沟通，技术只占工作的一部分。
• 教育（自适应学习、内容推荐、学情预测）：样本量有限且受隐私约束，公平性与可解释性的优先级高于效果提升。涉及对学生的评价与分组时，"模型为什么这样判断"必须说得清。
• 政务与公共部门（城市治理、公共安全）：数据敏感、采购周期长、项目制交付。技术方案要适配既有信息系统，算法岗常需同时承担方案沟通与项目管理。

这个差异对求职者的含义是：同一个岗位名，在不同行业里对能力的要求排序完全不同。互联网看重迭代速度与工程效率，金融看重可解释与合规，制造看重与领域机理的结合。投简历前先判断目标行业把哪一项排在第一，比多背几个模型名有用。

入行与转出（公开口径）

• 背景：计算机、数学、统计、自动化、物理等理工科背景最常见；学历门槛在技术岗中偏高，硕士是多数研究与应用型岗位的默认起点。官方职业标准对「人工智能工程技术人员」的受教育程度要求起点为大学专科，但同时给出数学、编程、数据处理、软件工程与机器学习等多类基础知识要求（附一第 1 条）——标准写的是起点，市场实际要求通常高于起点。
• 前置知识：数学（线性代数、概率统计、微积分与最优化）、编程（Python 为主，能读能写工程代码）、机器学习（回归／分类／损失函数／梯度下降／正则化／过拟合的成因与处置）、数据处理（SQL 与数据清洗）。缺了数学，模型选择只能靠套用；缺了工程，模型只能停在 notebook 里出不来。
• 常见入口：
  1. 校招进入算法团队——最主流路径，从团队内的一个具体问题做起。前半年通常在做数据与特征，而不是建模，这是正常节奏。
  2. 数据／开发岗转算法——大数据开发、后端、数据分析转算法的路径最顺，复用点不同：开发岗强在工程与系统能力，分析岗强在业务理解与指标体系，两者都需要补数学与建模的系统训练。
  3. 研究背景直接落地——博士或研究型硕士进入企业算法岗，需要补的是工程规范、代码质量与协作方式，而不是建模能力。
• 适配画像：能接受"大部分时间在数据和验证上、只有小部分时间在建模"；对不确定性有耐心（模型效果不会立刻显形，需要靠数据和实验推断）；愿意反复核对口径与边界，而不是急于上更复杂的模型。
• 三个常见认知误区：① 以为算法岗就是"调模型、刷榜"——实际的区分度在问题定义、特征与评估口径；② 以为模型上线就结束了——线上的效果衰减、数据漂移与重训是长期工作；③ 以为技术好就够了——业务对齐与边界量化能力，往往决定同一个模型能不能被认可。
• 职业特点：岗位总量远小于开发岗，但能把模型稳定地做成业务成果的人始终稀缺。职业天花板取决于两件事：一是能否从"实现一个模型"走到"定义该不该建这个模型、怎么衡量它成功"；二是能否把工程化能力补齐——只会建模不会上线的人，在任何规模的公司都会遇到天花板。
• 转出方向：转算法管理或技术专家路线、转 MLOps 与平台工程、转数据科学或商业分析、转行业解决方案与技术咨询、转技术型产品经理（尤其在有明确行业纵深时）。