AI 工程师概述
本文用 AI 工程师泛指所有与机器学习，深度学习和 LLM 等领域相关的工程师，三者在概念上的包含关系为：LLM < 深度学习 < 机器学习（不是指岗位的包含关系）。在 LLM 爆发之前，粗略讲在 2012 年左右的深度学习革命之后，AI 工程师开始流行，国内习惯叫算法工程师，国外则习惯称为机器学习工程师（MLE：Machine Learning Engineer）或 AI 工程师，每家公司的称谓不一样，像 Apple 在今年的 WWDC 之前就一直不说 AI，只说机器学习。
互联网企业中比较常见的 AI 工程师有以下 3 类：
自然语言处理工程师（NLP）：专注于开发能理解、解释和生成人类语言的应用程序的工程师。常见任务包括不限于文本分类、文本生成、信息抽取、机器翻译、问答系统、情感分析以及现在的大语言模型；
计算机视觉工程师（CV）：这类工程师开发算法来帮助计算机“看”和理解图像和视频数据。应用领域包括不限于图像分类、目标检测、实例分割、语义分割、图像生成、人体肢体检测和 VQA 图像问答等；
搜推广算法工程师（Recommend/Search/Advertisement）：这类工程师专注于开发和优化搜索/推荐/广告引擎算法，改进搜索/推荐结果的相关性和精确性，还可能参与开发用于广告定位和优化的算法。搜索/推荐/广告这 3 者之间本质是实现 query 与 result 的精准匹配，只不过约束条件和相关优化指标会有不同，因此工程师的技术栈是相似可迁移的。
此外，还有语音识别、路径规划、自动驾驶和机器人等领域的 AI 工程师。每种类别的算法工程师都有其专业技能和应用领域，但他们之间的界限并不总是非常清晰，因为许多技术和方法在不同的领域之间是共享的。
机器学习即代码
现在的机器学习工程师，或者叫 AI 工程师（但我不喜欢单纯叫算法工程师，因为不同领域的算法还是挺不一样的，比如搜广推与路径规划），已经不能只局限在某一种模态当中了，多模态是确定的趋势。从 bert 统一 nlp 各种任务开始，到 transformers 叠加 scaling law，从 nlp 到 cv，再到 audio，一种模型结构逐渐统一了各种模态的任务。
借助 transformer 模型，机器学习世界正逐渐从“ 好！！让我们从头开始构建和训练我们自己的深度学习模型 ” 转变为“*让我们选择一个经过验证的现成模型，用我们自己的数据对其进行微调，然后早点回家吃晚饭 ”。
在 huggingface 倡导的「Machine Learning As Code」的时代，基于工程与成本等因素，没有最好的模型，只有最合适的模型，工程师应该把各种模型像 plugin 一样根据不同任务进行组合拔插，必要的时候需要对其进行微调或者优化改造等。
因此，机器学习工程师最好能理解不同模型原理、模型训练、模型评估、模型应用与模型部署，用尽量少代码的方式实现功能。现在，模型即工具，服务，软件，APP…
随着 ChatGPT、Claude、Cohere、Llama、Mistral、Qwen、ChatGLM 和 Deepseed等大语言模型的推出，闭源的开源的 LLM 都有很多选择，并且使用成本在逐渐降低，开发者可以很容易的接入闭源模型的 API 或者本地下载开源模型，然后愉快地 create features powered by AI。
于是，提示词工程师的概念先火了起来，然后 AI 工程师（LLM 工程师）的概念也火了起来。Langchain、Ollama、RAGFlow、Llama Factory、vLLM 和 MetaGPT 等各种各样的开源框架如雨后春笋层出不穷，涉及模型 API 交互、量化模型本地运行、RAG 流程搭建、模型微调、模型推理和 Agent 搭建等 LLMops 的各个环节。借助 LLM 和 LLMops 开源框架，就算不懂 AI，开发者也可以较为容易的开发出基于本地知识库的 RAG、chatbot 和个人助手等 AI Native 的应用。
与 LLMs 共舞
搜推广
在推荐/搜索/广告领域，需要深刻理解机器学习/深度学习原理和公司业务的工程师，因为相关业务（内容、电商和广告）需要公司内部的人去运用推荐/搜索/广告领域的算法进行建模，整个系统的工程化包括的数据采集、数据流预处理、模型训练与部署、AB 实验指标评估等环节深度绑定公司业务，模型需要深度适配，也不太可能外包出去，像阿里云或亚马逊云机器学习平台上抽象出来的模型上手应用简单，但是进入业务深水区是不是还是需要业务方自己来做更好？
搜推广算法工程师区别于其他研发工程师或者 NLP/CV 工程师的点在于，搜推广算法工程师要为业务指标负责，如点击率，转化率和订单数等，而 NLP/CV 工程师为机器学习指标负责，如 accuracy，mse 和 bleu 等。其他研发为工程的各个环节更好更快更稳实现负责。算法工程师不能不懂工程，得先是工程师，才能是算法/机器学习工程师。
搜推广算法更像是“多模态”的算法工程师，多模态既是字面意义上的多模态，也是象征意义上的多模态。搜推广各种场景下会接触各种模态的内容数据：文本，图片，音频和视频等等，那除了协同过滤这一大类依赖行为数据的推荐算法外，也有必要做内容理解，那 NLP 和 CV 等模型也就避不开。
搜推广系统向来很容易从 NLP 领域的发展得到灵感，在大模型时代，估计有很多人在想如何将 LLM 融入现有的搜推广系统，比如说推荐/广告系统当中的内容理解环节，是可以直接用类 LLM 做文本/图像/视频/音频的理解，然后在根据理解后的“向量”进行精准推送。再或者是参考 perplexity 的问答式搜索，更大胆的想法是考虑用 LLM 直接来做 user 与 item 的匹配，直接输入 user 与 item 的特征，让 LLM 推荐给 user 相关 item。但是可解释性感觉更弱了，当然效果好无视可解释性也行，但是需要优化时感觉不好下手。
NLP/CV/Audio
另一方面，如果只是单纯做 NLP 或 CV 或 Audio 的话，那 benchmark 几乎都变成了相关的 LLMs，不仅限于 GPT4o，多模态的“大模型”还有类似 CLIP 和 FLAVA 这些，都可以很好的完成文本和视觉相关的小任务，比如 VQA 或者图片搜索。
ChatGPT 的推出，令各大高校的 AI 院系意识到了差距，因此相关的研究方向在之后都转向了 LLM，工业界的 NLP/CV/Audio 也必然不能脱离 LLM 的应用。
可能会涉及开发训练多模态的 LLM ，但是训练通用的 LLM 目前的门槛较高，同时需要大量计算资源，因此目前这种需求与要求基本只在大厂才会有。但是随着计算资源的普及以及技术的扩散，中小公司也会慢慢使用自己的数据训练或微调自己领域的 LLM，相关的招聘岗位也在逐渐增多。
目前看来调 API 与结合开源模型微调预训练是最可行的。比如说搜推广系统中会有专门负责内容理解的团队，那文本/图片/视频/音频的多模态理解与融合可在原本系统上结合 LLM 进行专门的优化，一些相关的业务需求，比如 TTS 方面的文本转语音，客服机器人等聊天机器人，或者图像文本生成，再或者 RAG，可直接调相关的 API。当简单调用 API 或者使用开源的模型在日益复杂的场景中开始表现不佳的时候，这时候可能就得考虑基于自身场景与数据，微调调用的模型或者训练公司自己的模型。
自动驾驶
这里提一下自动驾驶，以下内容来自收听播客后整理的嘉宾观点。
特斯拉最近在北美发布并部署了 V12 的 FSD（Full Self-Driving） 自动驾驶，超过 180 万辆车具备该功能，并且已有超过 100 万辆车下载并尝试使用，在驾驶体验上有很大提升，甚至被称作自动驾驶的“GPT 时刻”。这与其采用了端到端的算法，由神经网络自主完成驾驶体验的感知到规划的纯视觉的解决方案有很大的关系。
自动驾驶领域的端到端技术，与使用激光雷达的技术路径不同，端到端意味着类似 GPT4o 的语音输入语音输出一样，没有中间层的 TTS。特斯拉的 FSD 将视频做输入，输出车辆的规划控制信号，将感知和控制规划两个模块完全连接，实现数据自由流动。其背后很可能是一个具备多模态的类 LLM，且应该是首次实现视觉输入，车辆控制信号输出的端到端 LLM。
那目前只要是 LLM，将会面临一个问题，那就是模型的不可解释性问题，尤其对于高安全要求的自动驾驶行业而言，这种不可解释性是硬币的另一面。此外，端到端模型对传感器敏感度较高，换车需要重新训练模型，给工程带来了麻烦。然而，对于特斯拉这样布局早且道路上有很多车辆的公司来说，这条路径可能是可行的，但对于其他公司来说可能不现实。
LLMs
AI 界鲁迅 LeCun：如果你是对构建下一代 AI 系统感兴趣的学生，请不要从事 LLM 方面的工作。这是大公司的事情，你们无法对此有所贡献，人们应该开发能够克服大型语言模型局限性的下一代 AI 系统。
LLMs 是一个匝道。数以千计的工程师正在利用巨大的计算资源研究 LLMs。您唯一可能做出贡献的方法就是分析现有的 LLMs 并展示它们的功能和局限性。但是，提出新的想法和新的架构，并证明它们可能有效，即使是在小问题上，也会更有趣、更有影响力。
LLM 的开发需要大量的计算资源与高密度的人才，这些不是普通公司能参与的，那么除了探索当前 LLMs 的边界，有能力的话探索新的架构外，应用端还该关注什么确定性的趋势？
第一是成本下降，第二是多模态改变交互，第三是端侧。
LLM 推理的 token 成本在持续下降，未来毫无疑问还会继续下降，很多现在 token 消耗巨大成本昂贵的场景比如斯坦福小镇或者游戏里的 AI NPC，在未来成本可控的情况下，自然而然就具有可行性了。
Scaling Law 加持下的 LLM 能否通往 AGI 还有分歧，但是多模态是短期内清晰可见的趋势。
在「模型即代码」的时代，从开发者开始，能够轻而易举的调用大模型 API 或者开源模型构建应用层产品，紧接着机器学习/AI 会开始更多的走进大众的生活。从 APP 和 Web 开始，逐渐渗透进 PC 与手机，在不远的将来，借助多模态的深度理解，逐渐改变人机交互，当现有 GUI（Graphical User Interface，即图形用户界面）一点一点被颠覆掉之后，完整的 LLMOS（基于 LLM 的操作系统） 将会浮出水面。
那么，作为 LLMOS 载体的手机与 PC（或者眼镜），将会需要一个能在设备上运行的小 LLM，因此模型除了越变越大之外，越变越小也是趋势之一。
最后，agentic 多智能体反思，规划和工具使用的发展趋势也一样值得关注。
模型即产品吗？
大模型时代，AI 产品的构建需要 AI 工程师这个角色，最基本的要知道现在的 LLM 不是确定性的计算，而是基于概率的不确定输出（参与产品的人应该都要知道）；此外，从 prompt engineering 到 fine-tunning，从 fine-tunning 到 evaluation，再到 deploy，最后数据收集与分析，整个 LLMOps 的 pipeline 需要 AI 工程师参与建设。
不过，AI engineers are not all you need，但不是说 AI 工程师不重要，而是说整个系统不仅仅只包含模型这部分，而是还包含了数据、工程化、模型评价和 LLM 输出不稳定时的兜底方案等等。
另一方面，从 WWDC24 看，LLM is not all you need。特定场景能用特定小模型解决的就用小模型，这里的小模型不一定是参数量小的 LLM ，而是 NLP 或者 CV 的其他小模型，不一定是 LLM 。而需要用到 LLM 的场景大部分可能是涉及到逻辑推理能力，外部知识问答或者多模态等，那这里再去考虑 LLM 。
最终一个 AI 系统应该是由多个大大小小的模型（agent）各司其职组成的，未来仅有模型可能并不能构成产品，而只是一个个 feature，很多产品都可以轻松集成 LLM 实现同样的 feature，围绕各个模型搭建起来的 LLMOps 系统，或许才是最终的 AI 产品。这个系统中有很多细节需要打磨，而不是仅仅换用不同模型厂商的 API 那么简单。
前期可以简单直接调用大模型厂商的 API 进行 PMF 的验证，前期 AI 工程师对于产品原型以及能力边界的理解比较重要，知道哪些可以做，哪些做不了，并且配合其他工程师与 UI 快速搭建起产品雏形。一旦验证成功，越往后期将越需要一个稳定运行的系统，此时需要更多的 AI 工程师（或者称为机器学习工程师）、后端工程师与数据加入，围绕已有的产品雏形构建稳定的系统，努力解决用户需求与提升用户体验。
至此提到的 AI 产品可能都是偏向于致力打造有较大影响力的产品，可能需要较大的团队和投入。但是并不是只有大众的生意才是好生意，小而美的团队针对特定需求和用户打造的产品也同样值得尝试，比如对订阅友好收钱容易的 iOS 应用，或者是浏览器插件，这并不需要太多人，甚至厉害的只需要一或两个人，尤其是在现在的大模型时代，AI 也大大提高了生产力。如果做 iOS 应用，订阅友好与方便调用 Apple Intelligence 开放的 API（比如 App intent 与 Core ML）是硬币的一面，另一面则是如果构建的产品 feature 是 iOS 顺手就可以做掉的，那可能比较危险。
无论是想做影响力大的产品还是小而美的产品，接入 LLM 实现 AI 能力仅仅是开始，伴随着推理成本下降，多模态演进与端侧模型的发展，可能在不久的将来，AI 产品将迎来真正的大爆发，很多现在不成立的或者成本高昂的场景，在将来可能稀松平常。
暂无评论内容