3 篇博文 含有标签「ml-engineering」

有数据时，微调模型很容易。残酷之处在于产品诞生之前的那个时刻：你需要个性化来吸引用户，但又需要用户才能积累个性化数据。大多数团队要么完全跳过微调（"以后再加"），要么花数周手工收集标注样本。两种方式都行不通。前者产出一个用户一眼就能看穿的通用模型，后者慢到等你有了数据，任务早已演变。

合成种子数据能解决这个问题——但前提是你必须清楚它在哪里会失效。

三年前，"AI 团队"意味着一群藏在组织架构角落里的专家，对产品工程师基本不可见。如今，一位金融科技公司的高级软件工程师，周一用微调模型上线欺诈评分功能，周三为客户支持搭建 RAG 管道，周五调试 LLM 延迟问题。专家并没有消失——但"AI 工作"与"产品工程"之间的边界，消失得比几乎所有人预想的都快。

大多数团队的应对方式是把新头衔贴在旧职位描述上，然后宣告完事。这是错误的答案，功能失调很快就会显现：所有权不清、工具重复，以及一个 ML 平台团队把半数时间花在解释"为什么产品团队不能直接调 OpenAI API"上。

本文探讨如何把结构搭对——不是抽象地谈，而是针对大多数工程组织实际经历的 AI 采用阶段。

你在合成数据上微调的模型在内部评估中得分 95%。然后你部署了它，它却自信地编造出不存在的药物相互作用，引用了案件编号错误的法律先例，并幻觉出名称听起来很合理的 API 端点。模型的流畅度没有退化——它以一种流畅度指标完全无法察觉的方式变得更糟。研究人员称之为知识崩溃 (knowledge collapse)：事实准确性下降，而表面连贯性完好无损。这是合成数据训练中较为隐蔽的失败模式之一，通常发生在工程师构建流水线却未考虑到这一点时。

对于在特定领域微调 LLM 的团队来说，合成数据生成已变得不可避免。大规模的人工标注不仅昂贵、缓慢，且对于需要专业知识的任务来说是不可能的。由能力强的教师模型生成的合成数据可以廉价地填补这一空白。但流水线并不只是“向 GPT-4 索要示例，然后训练你的模型”那么简单。细节决定了你得到的是一个在特定领域表现优于通用模型的专业系统，还是一个流畅但事实漏洞百出的系统。