模型选择、微调与数据集：AI工程落地的联动决策框架

干了这么多年AI工程落地，我越来越觉得，模型选择、微调和数据集这三件事，根本不是三个独立的环节，而是同一个问题的三个侧面。很多人把深度学习当“炼丹”，拿到一个新任务就跑个基线，数据不对就换模型，模型效果差就盲目加数据量，结果时间花了一大把，项目始终在原地打转。这篇深度篇，我不讲API调用，也不列论文公式，纯粹从项目落地的角度，把我踩过的坑、总结出的判断逻辑、以及可直接参考的实操流程拆开来讲。适合那些已经跑通过几个基础模型、正准备把自己的任务做得更扎实的工程师或研究人员，看完你应该能建立一套自己的选型与微调决策框架。

先说清楚这篇内容的边界。模型选择、微调、数据集，每一块单拎出来都能写一本书，我不会试图覆盖所有算法细节，而是围绕一条主线展开：你在拿到一个新任务时，怎么根据数据现状和算力预算，推演出最合适的模型，再决定要不要微调、怎么微调，最后用数据工程的手段把效果顶上去。这套方法在视觉、NLP、多模态场景里都适用，我尽量用具体案例来讲，保证你拿到手上能直接套用。

1. 模型选择：先想清楚约束条件，再谈排行榜

每次有同行问我“现在哪个模型最好”，我都得先反问一句：你的任务是什么？你的数据长什么样？你有多少GPU？你的推理延迟要求是多少？这些答案完全不一样，选出来的模型也完全不一样。

1.1 选型的第一步不是看榜单，而是梳理任务约束

我见过太多人一上来就盯着各种榜单的头部模型，觉得“最强的总没错”，结果要么部署成本高到没法上线，要么模型能力和自己的数据分布根本不匹配。实际上，模型选型的第一原则是约束驱动，而不是性能驱动。

你需要先回答四个问题：

第一，任务类型是什么。是分类、检测、分割、信息抽取，还是生成式任务？不同类型的任务，模型架构差异巨大，不是同一个大模型都能解决的。比如目标检测你有YOLO系列、DETR系列可选；语义分割有DeepLabV3、SegFormer；信息抽取在中文场景下，百度开源的UIE模型就非常轻量好用。

第二，推理环境是什么。是云端GPU、CPU服务器，还是边缘设备、手机端？这直接决定了模型参数量上限。云端可以用7B甚至70B的大模型，边缘设备可能连1B模型都跑不动，需要走量化或蒸馏路线。

第三，数据规模和分布是什么。你有多少标注数据？数据分布和预训练模型的训练分布是否接近？如果数据量很少，最好是选一个预训练分布已经覆盖了你目标场景的底座模型；如果数据量很大且有明显领域特色，就要考虑一个可以充分微调的模型。

第四，算力和时间预算。你手里有几张卡，能跑几天，这直接决定了你是做全参微调还是LoRA这类参数高效微调，也决定了你能否在合理时间内完成训练。

把这四个问题写在纸上，答案基本就能筛掉大半模型。剩下的候选再做横向对比测试，远比你盲目追新更高效。

1.2 评测数据集是模型选择的“照妖镜”

我强调一点：任何模型榜单都只是参考，真正能帮你做决策的，是你自己构建的评测集。这个评测集应该尽量贴近线上真实分布，包含典型场景、边界场景和噪声场景。当年我在做中文场景文字识别项目时，一开始基于通用OCR模型跑得很好，但一上真实数据就露馅了——复杂背景、艺术字体、低光照，全崩。后来我从实际业务里抽了几百张困难样本，手标了一个小评测集，每换一个模型就先拿这个评测集跑一遍，效果立竿见影。

对于视觉任务，COCO2017和KITTI这类公开数据集适合做基线评估，但你要清醒地认识到，公开数据集和你的业务数据一定存在分布差异。比如KITTI是自动驾驶场景的高清道路图像，你拿去做无人机航拍场景的评估，指标会失真很严重。DOTA数据集则是遥感旋转目标检测的标杆，如果是做航拍图像里的任意朝向目标检测，选择支持旋转检测的模型（比如mmrotate框架里的模型）就比常规水平框检测器更合理。

所以我的建议是：公开数据集用来做技术选型和消融对比，自建业务评测集用来做最终决策。两者结合，选型才能不出大偏差。

1.3 小模型优先与“够用就好”原则

大模型时代，很多人忽略了一个事实：许多任务用小模型就足够了。以信息抽取为例，百度的UIE（Universal Information Extraction）模型在实体抽取、关系抽取、事件抽取上效果相当能打，而且部署成本极低。我一个朋友做法律文书的信息抽取，一开始非要上几十B的大模型微调，后来换成UIE的base版本，在几千条标注数据上稍作微调，F1值完全不输大模型方案，推理成本却只有原来的几十分之一。

多模态场景也一样。很多人在刷榜之后才意识到，自己只需要一个能识别证照、票据的模型，根本不需要什么视觉大模型。Qwen-VL-4B这类中等规模的多模态模型，配合LoRA微调，在垂直领域往往表现足够好——我在实际项目中用4B量级模型微调后，识别准确率追平甚至超过了一些大模型的零样本效果，而显存占用和推理速度的优势是碾压级的。

选模型的黄金法则是：能用小模型解决的，绝不上大模型；必须上大模型的，也要先用最大性价比的方式做微调适配。

2. 微调的本质：不是让模型“学会新东西”，而是让模型“按你的方式输出”

很多人对微调有误解，觉得微调就是在业务数据上继续训练，让模型学会业务知识。这个理解在早期深度学习时代勉强成立，但在大模型时代完全不够准确。当底座模型已经通过海量预训练掌握了语言、视觉、推理的通用能力后，微调的核心作用是行为对齐——让模型的输出方式、输出格式、评判偏好与你的业务规范对齐，而不是重新教它知识。

2.1 从全参微调到LoRA：你需要改模型哪个部分

微调按参数更新范围，通常分成两大类：全参微调（Full Fine-tuning）和参数高效微调（PEFT）。全参微调让全部模型参数参与训练，表达能力强，但需要大量算力和显存。以7B模型为例，就算用bfloat16混合精度，单卡最起码也要40GB以上的显存才舒服。参数高效微调的代表是LoRA（Low-Rank Adaptation），它冻结底座模型，只训练注入的低秩矩阵，训练参数量通常只有原来的0.1%~1%，显存需求大幅下降，一张24GB的消费级显卡就能微调7B模型。

那什么时候该全参，什么时候该LoRA？我的经验是：如果任务和原始预训练任务差异极大，比如从通用对话改成写SQL、改成特定代码生成，全参微调的上限更高；如果任务相对接近底座模型已有能力，只是需要规范输出格式或注入少量领域术语，LoRA完全够用，而且可组合性极强——同一底座可以按业务场景训练多个LoRA插件，推理时动态切换，运维起来非常方便。

2.2 LoRA关键参数：前面踩过的坑，这里一次说清

LoRA看似简单，实际使用中有几个参数直接决定效果好坏，我逐个拆开讲。

第一个是秩（rank）。秩决定了低秩矩阵的表示能力，秩越大，可学习的参数量越大，模型表达能力越强，但过大的秩不仅增加显存和计算开销，还可能带来过拟合。实践经验是：先设8或16跑一版，在验证集上看效果，如果欠拟合就逐步增加到32、64，如果效果不升反降就是过拟合了。

第二个是alpha（缩放参数）。实际效果中，LoRA的最终更新幅度与alpha/rank 的比例呈正相关，通常设成rank的两倍（即alpha=16，rank=8）是一个稳妥的起点。这个比例调大，模型改动幅度加大，调小则更保守。在做通用对话模型微调时我习惯保守一些，alpha/rank 取1；但在领域术语密集的场景（比如医疗、法律），我会把比例提到2~4，让模型更快适应领域表达习惯。

第三个是target_modules（注入的模块）。这个参数决定LoRA注入到模型的哪些层。常见选择是注入注意力机制的q_proj、v_proj或全部q/k/v/o矩阵。我的经验是：轻量任务只注入q_proj和v_proj就足够，复杂任务把k_proj、o_proj也加上，效果更稳定。

下面是一个基于LLaMA-Factory框架微调Qwen2.5-7B的LoRA配置示例，lora.json里面几个关键参数可以直接参考：

{ "model_name_or_path": "Qwen/Qwen2.5-7B-Instruct", "template": "qwen", "stage": "sft", "finetuning_type": "lora", "lora_rank": 16, "lora_alpha": 32, "lora_dropout": 0.05, "lora_target": "q_proj,v_proj,k_proj,o_proj", "dataset": "your_sft_dataset", "cutoff_len": 2048, "per_device_train_batch_size": 4, "gradient_accumulation_steps": 8, "learning_rate": 2e-4, "num_train_epochs": 3.0, "lr_scheduler_type": "cosine", "warmup_ratio": 0.1, "bf16": true, "output_dir": "output/lora_qwen25_7b" }

这套配置我跑得很稳，learning_rate对于LoRA来说通常设在1e-4到3e-4之间，不要用全参微调的1e-5量级——因为只更新少量参数，学习率太小会收敛很慢，太大又容易震荡。bf16在A100/H100上能省不少显存，如果是V100等不支持bf16的卡，改成fp16即可。

2.3 多模态微调的最小单位：不是全模型，而是视情况而定

很多人做多模态微调时，习惯性地把所有模块全部解冻，其实没必要。以Qwen-VL-4B这类模型为例，它通常包含视觉编码器、投影层和语言模型三部分。视觉编码器已经在海量图文对上练过了，通用视觉特征提取能力很强，领域训练时解冻它容易破坏已有特征且计算开销极大。稳妥的多模态微调策略是：冻结视觉编码器，重点微调投影层和语言模型的LoRA部分。这样显存占用小，收敛也快，我实际做中文票据识别微调时，仅用几张消费级显卡就完成了训练，效果比全量微调差距不超过1%。

具身智能领域常见的OpenVLA等视觉-语言-动作模型也是同理，LoRA不仅适用于文本，在动作预测这类连续输出任务上同样有效。如果你想快速验证方案，完全可以从LoRA路线切入，不必一上来就全参微调。

2.4 指令微调与偏好对齐：让模型“懂规矩”

这里要特别区分两个概念：指令微调（SFT）和偏好对齐（如RLHF/DPO）。指令微调的目的是让模型学会“按照指令输出”，你的数据是“指令-回答”对；偏好对齐的目的是让模型输出的风格、价值观、安全性更符合预期，你的数据是“好回答-坏回答”的偏好对。在实际业务中，SFT是最常用的，偏好对齐则更多用于客服、内容生成这类对输出风格有严格要求的场景。

做SFT时，数据质量远比数据量重要。我用过一个通用规律：高质量人工标注的五千条SFT数据，效果胜过未经清洗的十万条网络爬取数据。原因很简单，大模型微调的本质是“示范”，你给的示范不干净，它学到的行为就不干净。如果你的数据集中有大量相似或低质量样本，模型不仅学不到新东西，反而可能把已有能力带偏。

3. 数据集：模型的下限是由数据质量决定的，而不是数量

有句话我特别认同：垃圾进，垃圾出。模型的上限由算法决定，但下限几乎完全由数据决定。很多项目做完模型选型和微调，效果还是不理想，回头一查，问题全出在数据上。这一章我讲讲数据集的构建、配比和工程细节，这些都是可以直接复用的一线经验。

3.1 数据配比与数据覆盖度：别光看数量

很多新手以为数据集越大越好，误把“数据量”当成“数据质量”的替代品。真实情况是，数据分布的覆盖度比数量重要得多。举个例子，我之前做施工安全检测模型时，第一次拿到两万张工地图片，里面80%是晴天白天的画面，雨天、夜间、逆光、遮挡的样本屈指可数。模型在验证集上指标不错，一上线就发现夜间漏检率剧增。后来我专门补充了一万多张低光照和恶劣天气样本，重训后夜间漏检率直接降了一半多。

所以做数据集规划时，先别急着堆量，而是要统计各类场景的样本分布，确保关键困难场景有足够的覆盖。对视觉任务来说，光照强度、拍摄角度、遮挡比例、目标尺度分布，这些都是必须统计的维度；对文本任务来说，语言风格、句式长度、领域术语密度则是核心维度。建一个分布清单，再按分布去补数据，效率远高于盲目采集。

3.2 开源数据集的结构与坑：COCO2017并不是拿来就能用

很多公开数据集看起来很好，但里面的坑不少。以COCO2017为例，它的目录结构分为train2017（约11.8万张）、val2017（约5000张）和test2017（约4万张，标签不公开），标注文件是JSON格式，包含images、annotations、categories三大部分。看起来很清晰，但实际使用中要留意几个细节。

第一，COCO的标注是polygon多边形格式，转YOLO或其它检测框架需要的txt格式时，必须自己写转换脚本。第二，COCO里很多小目标标注框非常小，如果直接缩放图片到统一尺寸训练，小目标信息几乎丢失，这个时候要评估是否需要原图训练或使用多尺度训练。第三，COCO的类别分布并不均匀，其中人和车占了很大比例，用通用类别训练模型没问题，但做长尾类别检测效果不佳，需要自己做类别均衡采样。

再看KITTI数据集，它是最经典的自动驾驶视觉数据集之一，包含图像、点云、雷达和GPS数据，目标检测任务只标注了车、行人、骑车人三类。下载后你会发现它的标注格式是KITTI自己的文本格式，物体在3D空间中还有旋转角信息。如果你只是做2D检测，需要把标注框从3D投影到2D，这个转换过程也有不少细节要处理。

遥感领域常用的DOTA数据集也是一样，它支持任意方向的旋转框标注，数据量巨大（2806张遥感图像、18万+实例），但初始版本就存在一些边界框标注抖动的问题，使用时需要仔细检查。我的经验是：任何公开数据集，拿下来后都要先花时间做可视化检查和清洗，而不是直接开训。花两三个小时看几百张图，能帮你避开很多训练后才发现的问题。

3.3 领域数据集的构建流程：从采集到标注的完整链路

当公开数据集不满足需求时，你就得自建领域数据集。我总结了一套完整流程，每一步都很重要。

第一步是数据采集。常见来源包括自有业务数据、网络爬取、开源数据集的组合、以及合成数据。采集时优先保证场景覆盖度，宁可数量少一点，也要把不同光照、角度、背景、噪声都覆盖到。比如做中文场景文字数据集，除了标准打印体，还要覆盖手写体、艺术字、背景纹理、透视变形这些情况。

第二步是数据清洗。这一步最容易被低估。以文本数据为例，网上爬取的数据里经常嵌入大量HTML标签、乱码字符、重复段落，不处理干净会把模型训练搞得一团糟。我通常的做法是：先做格式统一和字符清洗，再做去重（包括近似去重，用MinHash或SimHash），最后做质量过滤——比如长度过滤、语言过滤、敏感内容过滤。

第三步是标注与质检。标注规范要写得非常细，标注人员也要做一致性培训。比如目标检测任务，标注框是紧贴目标还是留一点边缘，遮挡目标要不要标注，模糊到何种程度的样本可以放弃，这些都要在规范里写死。再加上至少一层的交叉质检，确保标注一致性。对于文本指令数据，则要重点检查指令清晰度、回答正确性、格式统一性。

第四步是格式转换与划分。把标注结果转换成模型框架需要的格式，再按比例划分训练集、验证集和测试集。划分时要注意按场景分层采样，避免某个特殊场景的样本全部落在测试集里。

3.4 合成数据：补长尾场景的救命稻草

很多场景下，真实数据采集成本太高，或者某些极端情况现实中很难遇到，这个时候合成数据是极好的补充。我之前做危险场景识别，比如工人未戴安全帽、明火、烟雾等，真实样本不够，就通过3D渲染、图像合成、背景替换的方式生成了一大批合成样本，再配合域随机化（改变光照、材质、视角）来增加多样性。最终模型在真实场景上的泛化能力比只用少量真实数据训练的版本好了一大截。

文本任务也可以做合成数据，典型方法是利用大模型生成“伪指令-回答”对，再进行人工筛选和修正。我见过不少团队用GPT系列模型生成指令数据后，再经过规则过滤和人工抽检，作为SFT初版数据。这个方案省时省力，但要注意生成内容可能包含幻觉、偏见甚至错误信息，用于微调前必须做充分审查和修正。

3.5 数据集版本管理：很多团队忽视的工程化细节

数据集和代码一样，需要版本管理。你在项目迭代过程中，数据的标注规范会变，清洗规则会变，划分方式也会变。如果没有版本管理，很可能出现这种情况：模型训练到一半，发现评测数据跟一个月前用的不一样了，又不记得变化在哪里。这种混乱在大模型微调项目中非常致命，因为数据的微小变化都会导致模型效果波动。

具体做法很简单：每个数据集版本记录它的采集时间、来源、清洗规则、标注规范、样本统计信息，以及生成该版本数据集的代码或脚本版本。团队内部可以统一用数据版本管理工具，甚至简单到用一个带版本号的目录结构加一份CHANGELOG文件，都比没有强得多。数据版本要和模型版本一一对应，这样出了问题才能回溯复现。

4. 实操记录：一次基于LLaMA-Factory的SFT微调全流程

前面讲了很多原则，这一章我带着大家走一遍完整实操。我会以中文领域指令微调为例，展示从数据准备到模型评估的全过程，这个过程可以复用到其它任务上。

4.1 环境准备与工具选型

工具选择上，我推荐LLaMA-Factory，它对中文模型支持好，且封装了LoRA、QLoRA、全参微调、DPO等多种训练方案，开箱即用。首先创建虚拟环境并安装依赖：

conda create -n llama_factory python=3.11 -y conda activate llama_factory git clone https://github.com/hiyouga/LLaMA-Factory.git cd LLaMA-Factory pip install -e .

硬件方面，微调7B模型做LoRA，一张24GB显存的消费级显卡（如RTX 3090/4090）就能跑，如果显存不够，可以开启QLoRA，即把底座模型量化到4bit再训练，显存最低可以压到10GB以下。LLaMA-Factory的WebUI提供了很好的可视化界面，适合快速操作；但如果你想做自动化实验，用命令行更高效。

4.2 数据准备与格式说明

LLaMA-Factory支持多种数据格式，最常用的SFT数据是对话格式。以单轮对话为例，JSON格式如下：

[ { "instruction": "请解释什么是AI工程？", "input": "", "output": "AI工程是将机器学习模型落地为可靠、高效、可维护的软件系统的工程实践，涵盖数据管理、模型开发、部署运维等环节。" }, { "instruction": "翻译成英文：今天天气很好", "input": "", "output": "The weather is nice today." } ]

如果你的场景是多轮对话，数据格式要按对话列表组织。大多数框架对数据格式有严格要求，建议先用官方示例数据跑通流程，再替换成自己的数据，这样能少踩很多格式坑。

数据准备好之后，需要把它注册到LLaMA-Factory的配置文件里。打开data/dataset_info.json,按照模板添加一个条目：

"your_sft_dataset": { "file_name": "your_sft_dataset.json", "columns": { "prompt": "instruction", "query": "input", "response": "output" } }

这里的columns映射告诉框架你的JSON字段对应什么含义，注册完成后就可以在训练命令里通过--dataset your_sft_dataset引用了。

4.3 训练命令详解与效果评估

命令行启动训练的命令如下：

CUDA_VISIBLE_DEVICES=0 llamafactory-cli train \ --model_name_or_path Qwen/Qwen2.5-7B-Instruct \ --stage sft \ --finetuning_type lora \ --dataset your_sft_dataset \ --template qwen \ --cutoff_len 2048 \ --learning_rate 2e-4 \ --num_train_epochs 3.0 \ --per_device_train_batch_size 4 \ --gradient_accumulation_steps 8 \ --lr_scheduler_type cosine \ --warmup_ratio 0.1 \ --lora_rank 16 \ --lora_alpha 32 \ --lora_target q_proj,v_proj,k_proj,o_proj \ --output_dir output/lora_qwen25_7b \ --bf16

训练过程中的几个关键点：cutoff_len是输入序列截断长度，不要设太小，否则长文本信息会丢失；gradient_accumulation_steps乘上per_device_train_batch_size等于全局批次大小，通常全局批次大小设在32到128之间比较合适。我一般第一轮先用小批次跑通，确认loss正常下降后，再调大批次正式训练。

训练完成后，推理验证的方式如下，加载LoRA权重并合并回底座模型：

llamafactory-cli export \ --model_name_or_path Qwen/Qwen2.5-7B-Instruct \ --adapter_name_or_path output/lora_qwen25_7b \ --template qwen \ --export_size 4 \ --export_legacy_format false \ --export_dir merged_model

合并导出模型后，直接用原生模型框架做推理，就不需要额外加载LoRA模块了。在复用或部署时，合并后的模型也更容易配合标准推理框架使用。

效果评估方面，不要只看训练集loss，也不要只看几个阅读测试样例的主观感受。务必留出一部分模型没见过的数据做评测，如果评测数据里有像DEAP情感分析这种公开任务就更好了——但更关键的是用你自己的业务评测集。我在实际项目中，通常准备两套评测：一套是公开基准集，用来对比行业水平；另一套是业务实际样本集，用来判断上线效果。两套指标都过关，模型才敢上线。

4.4 多模态微调的实操差异：以Qwen-VL-4B-LoRA为例

多模态模型微调和纯文本模型微调在流程上相似，但有几个关键差异需要注意。首先是数据格式不同，多模态SFT数据要包含图片路径和文本对话内容；其次是显存占用更高，因为你同时加载了视觉编码器和语言模型。

以Qwen-VL-4B为例，一套可以直接跑通的数据格式如下：

[ { "id": "sample_1", "image": "path/to/image.jpg", "conversations": [ { "from": "human", "value": "<image>\n请描述这张图的内容。" }, { "from": "gpt", "value": "这是一张施工现场的照片，几名工人正在作业，其中一人未佩戴安全帽。" } ] } ]

训练时同样通过LLaMA-Factory，在超参数上要特别注意，多模态模型的学习率要比纯文本模型低一些，我常用1e-4作为初始值。因为视觉编码器和语言模型的学习率如果太高，容易破坏预训练特征。如果想要更低显存，可以加--quantization_bit 4参数启用QLoRA，效果通常下降很少，但显存需求大幅降低。在我做多个多模态微调项目中，4bit量化加LoRA是性价比最高的组合，没有之一。

5. 微调与数据集常见问题排查指南

做微调时间长了，你会发现80%的失败案例都集中在几个典型问题上。我整理了最常遇到的几类问题、原因和解决方案，做成速查表方便大家对照。

5.1 Loss值下降异常怎么定位

遇到loss不降，我的排查顺序是：先做小样本过拟合测试，拿几十条数据训练，看loss能不能降到接近0。如果几十条数据都学不进去，说明配置有问题，要么是学习率、要么是数据格式、要么是模板不匹配。如果小样本能过拟合，说明模型有学习能力，问题出在大数据集上，这时候要去看数据噪声和数据分布是否合理，逐条可视化检查标注质量。

一个小技巧：训练初期（前几十步）loss如果有明显下降，说明整体配置基本正常；如果loss完全不动还往上涨，大概率是learning rate过大或者数据格式有严重问题。这个判断方法帮我在不少项目里节约了排查时间。

5.2 数据端最容易忽略的三大隐形坑

第一是标签类别不均衡。一个目标检测数据集里，如果某个类别的实例数比另一个类别小两个数量级，模型训练就会严重偏向高频类别。解决办法是采样调整，低频类别过采样、高频类别降采样，或者给损失函数加类别权重。

第二是标签噪声。标注错误是不可避免的，但超过5%的错误标签就会明显影响模型效果。标注规范要写细，质检要到位，宁缺毋滥。我在团队里一直强调一个原则：标注质量优先级高于标注速度。

第三是数据泄露。数据预处理阶段如果不小心让验证集和训练集有交集，模型的评测指标会虚高，让你误以为效果很好，上线后立刻打回原形。这个坑最常见于做数据增强的时候，比如先把所有图片做了翻转，然后随机划分数据集，导致同一张原图同时出现在训练集和验证集里。正确的做法是先划分数据集，再做数据增强，确保验证集只包含原始、未增强的样本。

5.3 效果不佳时，先别急着换模型

最后说一个通用心法：当模型效果不理想时，先不要急着换更大的模型，而是按这个顺序排查——数据质量有没有问题？数据规模够不够？微调配置是否合理？评测指标是否贴合业务场景？排查完这些再考虑换模型。我见过太多团队，数据标注混乱没解决，换了个更大的模型，结果只是从一种“不理想”变成另一种“不理想”，白白浪费了时间和算力。

当然，如果以上都排查过了，且确认当前模型的容量确实不够支撑任务复杂度，再换模型也不迟。那时候换模型才有意义。

个人而言，这几年做AI工程，我最大的体会是：模型选择、微调和数据集这三个环节，从来不是孤立的决策，而是一个联动的系统。数据集决定了下限，微调决定了实际行为对齐程度，模型选型决定了上限与部署成本，三者要一起设计，反复迭代。最后分享一个小技巧：每一个实验跑完，务必记录下模型版本、数据版本、关键超参数和评测结果，哪怕只是一个简单的记录表格。这套记录在项目后期会救你无数次，也会让你的工作成果更加可信、可持续。

同样的方法论，如果你要在自己的业务里落地，我建议先从一个极小的端到端流程开始跑通，再逐步扩大数据和模型规模。用最小的成本验证整套流程的可行性，远比你一开始就搭建一个庞大但处处踩坑的系统要高效得多。