# FDE 为什么应该先学评测，再学微调

> 对比几份 FDE 招聘启事，只有一家 AI 基础设施公司要求精通微调，而是否微调通常要先看评测集。

原文: https://fdetimes.net/zh/analysis/fde-learn-evals-before-fine-tuning/

Together AI 一则名为 FDE, Post-Training 的招聘启事，列出了一串足以让读者直奔课程报名页的缩写：SFT、LoRA、DPO、GRPO、PPO。公司希望候选人在 LLM 的微调或强化学习（RL）方面具备专家级的实战经验。

匆匆一读，这则启事似乎在说：微调是 AI 时代进入前线部署工程师（FDE）行业的入场券。但把它和另外几份 FDE 岗位描述放在一起看，这个结论就站不稳了。在下文涉及的招聘启事和一线经验中，对深度微调能力的要求只来自一家 AI 基础设施公司，而且即便在那里，微调也不是孤立的要求。

对于有几年经验、准备转型 FDE 的工程师来说，现实的问题不是要不要学微调，而是什么时候学、之前先学什么，以免花六个月去钻研一项客户可能根本不会问到的技能。

## 在 Together AI，微调不是孤立的要求

Together AI 有两个 FDE 岗位涉及微调，两者都把微调和别的能力绑在一起。Post-Training 岗位在列出那串算法的同时，还要求有直接与客户带领复杂技术项目的经验。

第二个岗位 FDE Strategic Inference 把招聘对象描述为推理优化、微调流水线和生产环境部署方面的资深专家。启事点名了具体工具：vLLM、TensorRT-LLM 和 SGLang 等推理引擎。日常工作是根据硬件、模型架构和负载特征来选择、配置和优化引擎。

从这两份启事的写法看，微调只是生产链条上的一环，而不是终点。微调好的模型仍然要跑在特定的 GPU 上，承接特定的流量模式，服务特定的客户。能打通整条链路的人，才是 Together AI 需要的人。

## 基础设施客户问的是延迟，不是 DPO

推理平台 Baseten 一位 FDE 的讲述，把这一点说得更透。这位工程师说，主要目标是帮客户把开源模型、微调模型或定制模型部署到 API 端点之后。

注意“微调”一词在这句话里的位置：微调模型是客户带来的，FDE 的工作是让它跑起来。文中举的典型问题是：如何在成本不变的情况下，把推理服务的延迟降低到十分之一。

把这个问题当成一道题来解。如果一次请求现在要 2 秒，客户希望在同样的 GPU 账单下降到 200 毫秒。DPO 或 GRPO 很难解决这个问题；答案在于选择与模型架构匹配的引擎、配置和硬件，这正是 Strategic Inference 岗位所描述的工作。

## 一个应用层案例：真正的工作是检索和评测

在向企业销售模型的公司这一侧，有一个案例值得细看。在与 Morgan Stanley 的合作项目中，OpenAI 的 FDE 团队需要开发检索调优技术，让研究报告能被准确找到并获得用户信任。他们调的是检索环节，而不是模型。

团队还把评测视为必需：一个基于 LLM 的应用，如果没有能证明其有效的评测集，就不算完成。

OpenAI 关于优化 LLM 准确率的指南，把同一观点表述成了一个顺序：提示词工程通常是最好的起点；在此基础上，需要一套可靠的评测集作为基线，然后再考虑检索增强生成（RAG）或微调。

从这两侧可以看出两类 FDE：职位名称相同，技能组合却不同。右栏只基于 Morgan Stanley 这一个项目加上 OpenAI 的通用指南，应视为对照用的案例，而非整个应用层的规律。

| 维度 | AI 基础设施 FDE | 一个应用层案例 |
|---|---|---|
| 案例来源 | Together AI、Baseten | OpenAI 的 FDE 团队与 Morgan Stanley |
| 客户带来的问题 | 降低延迟、控制成本、运行微调模型 | 找到的报告是否准确、可信？ |
| 主要工作 | 选择和配置推理引擎、微调流水线 | 调优检索、构建评测 |
| 微调的位置 | 明确列出的技能，与推理服务搭配 | 按 OpenAI 的指南：在提示词之后、有评测基线时再考虑 |
| 点名的工具 | vLLM、TensorRT-LLM、SGLang | 作为基线的评测集 |
| 需要证明什么 | 带领过客户技术项目 | 应用有评测证明其有效 |

两栏的共同点不是微调，而是衡量系统好坏的能力，以及把系统交付到客户生产环境的能力。

## 什么时候才轮到微调

假设你是一家银行的 FDE，银行想要一个内部助手来回答关于分析师报告的问题。你准备了 100 道带参考答案的题目，只用提示词跑一遍，比如答对 62 道。这就是你的基线。

接下来仔细看那 38 个错误答案。假设其中 25 个错在系统检索到了错误的报告，8 个内容正确但格式不对，5 个是模型不理解内部术语。前 25 个属于检索问题，正是 OpenAI 团队在 Morgan Stanley 做的那类工作；后 8 个通常用提示词就能解决。

只有处理完这两组、最后一组错误依然存在时，微调才成为合理的候选方案。而到了这一步，按照 OpenAI 的说法，训练数据的质量比数量更重要。所以决定成败的技能，是从系统答错的那些问题里挑选、清洗出几百条好样本，而不是背下 DPO 的损失函数。

**要点:** 对 FDE 来说，微调是最后的答案，而不是第一个问题。

## 给想入行者的学习顺序

从这些岗位描述中，可以梳理出一个合理的顺序。先学评测和提示词，因为它们是之后所有决策的基线。接着是检索和数据能力：检索是 OpenAI 团队在 Morgan Stanley 必须做的工作，数据质量则是 OpenAI 在微调时看得比数量更重的因素。

第三步是推理服务：在 vLLM 或 SGLang 上运行一个开源模型，测量延迟和成本，调整配置后再测一次。

这正是 Strategic Inference 岗位点名的技能，也是 Baseten 那段讲述的核心。在此之后，如果目标是基础设施公司，再深入学习 SFT 和 LoRA，然后是 DPO 以及 GRPO、PPO 等强化学习方法。

阅读招聘启事时，可以把上面的表格当作粗筛工具。点名推理引擎和后训练算法的启事，很可能是基础设施层岗位；在那里，值得尽早投入微调。

以企业客户的准确性和可靠性为核心的启事，可能更接近 Morgan Stanley 的案例；在那里，一个扎实的评测项目大概比一张微调证书更有分量。

简历上不要只写一行“有微调经验”。把它变成一个有数字的故事：基线是多少，错误分成了几类，修复检索后分数提高了多少，以及你为什么决定微调或不微调。如果目标是基础设施层，再加一行：调整推理服务配置前后的延迟。

别忘了 Together AI 紧挨着算法列表放的另一半要求：与客户一起带领技术项目。那串缩写也许是启事里最唬人的一行，但真正告诉你客户是否需要其中任何一项的，是评测集。

**本周动手试试:**

- 为手头的一个 LLM 任务构建一个小型评测集，跑一遍只用提示词的基线并记录分数。
- 在考虑微调之前，先按原因给每个错误答案分类（缺少文档、检索到错误文档、格式错误）。
- 重读三份你感兴趣的 FDE 招聘启事，标出哪些点名了推理引擎：这些很可能是基础设施层岗位。

## 信源

- [Forward Deployed Engineer, Post-Training (Together AI)](https://jobs.generalcatalyst.com/companies/together-ai-2/jobs/97989008-forward-deployed-engineer-post-training)

- [Forward Deployed Engineer, Strategic Inference (Together AI)](https://refresh.cv/jobs/together-ai/45566a30-07a9-45b3-bb3e-ab5bda7e800e)

- [What I Learned As A Forward Deployed Engineer Working At An AI Startup](https://www.baseten.co/blog/what-i-learned-as-a-forward-deployed-engineer-working-at-an-ai-startup/)

- [Optimizing LLM Accuracy (OpenAI API docs)](https://developers.openai.com/api/docs/guides/optimizing-llm-accuracy)

- [Forward Deployed Engineering: Bringing Enterprise LLM Applications to Production (ZenML LLMOps Database)](https://www.zenml.io/llmops-database/forward-deployed-engineering-bringing-enterprise-llm-applications-to-production)