一、项目背景

某行业客户想用大模型做内部的业务术语问答和单据初筛，但他们手里的标注语料只有几百条，远不够全量微调。通用模型在他们的专业词汇上经常答偏，把行话解释成字面意思，闹过几次笑话。客户一开始的期望是"把模型训成我们行业的专家"，我们评估完数据量后明确说全量微调既不现实也不划算，烧卡还过拟合。最后定的路线是轻量适配器，用 LoRA 思路在原有底座上挂一小层，既能吃领域知识又不伤通用能力。客户半信半疑，直到看到效果才改观，这也让我们后来在小样本项目里更敢早期就坦诚沟通技术边界，而不是顺着客户预期承诺做不到的事。

二、落地场景

我们在微调工具链层做了 LoRA/QLoRA 轻量微调，把客户的几百条语料做质量过滤后作为训练集，另拆出一份评估集专门测领域任务准确率。领域词表单独做术语注入，让模型先认得这些词再学怎么用。训练出的适配器做版本管理，线上出问题能一键回滚到上一版。底座本身不动，适配器像插件一样挂上挂下，多个客户可以共用一个底座各挂各的适配器，这对我们私有化交付的多租户场景很关键，不用每人一套大模型。

三、关键技术挑战与解决思路

少样本过拟合是头号坑。我们第一版直接拿几百条语料硬训，评估集准确率虚高，一上真实提问就露馅，典型的背答案。后来加了数据增强和术语约束，让模型学的是术语关系而不是 memorize 样本，过拟合率明显下来。领域术语注入方式也踩过坑，最早只往词表里硬塞，模型还是按通用语义理解，后来改成在训练样本里显式给术语定义加上下文，注入才生效。评估集构建最容易被糊弄，客户给的"评测题"和他们真实问题分布差很远，我们坚持自己从真实日志里抽评估集，否则线上效果没法信。适配器版本管理则是用哈希锁定，回滚靠换挂载点而非重训，切换秒级不影响底座其他适配器。

训练数据的质量过滤比模型结构更影响结果，这点我们踩过。客户给的几百条里混了十几条标注错的，初版没过滤直接训，评估集上那几个错例被牢牢记住，怎么调都下不来。后来加了一轮人工抽检加交叉验证，把脏样本剔掉，准确率立刻稳了。还有个细节：LoRA 的目标层不能只挂注意力，我们试过只挂 query 层，领域术语的注入明显弱，挂上 value 层后术语理解才上来。这些经验看着琐碎，但少一步就多一轮返工，小样本项目里数据和时间都金贵，每一轮都该省在刀刃上。

案例片段（已脱敏）： 某客户领域任务初版全量微调因数据不足放弃，改用 LoRA 后关键配置如下：lora_config:  r: 16  alpha: 32  dropout: 0.05  target_modules: [ "q_proj", "v_proj" ]  lr: 2e-4  train_samples: 640  eval_from: production_log上线后领域任务准确率从通用模型的约六成提升到八成七，训练算力较全量微调下降约九成，适配器体积不到两百分之一，回滚到上一版耗时秒级。

四、效果数据

领域任务准确率从通用模型约六成提升到八成七，专业术语问答不再闹笑话。训练算力较全量微调下降约九成，几百条语料也能跑出像样的效果，客户不用为这点数据专门扩卡。过拟合率压到低位，评估集和真实日志的准确率差从初版的二十多个点缩到五个点以内。适配器体积小，挂载切换秒级，某次新版本在真实提问上表现退化，我们十分钟内回滚到稳定版，没影响业务。多租户共用底座后，单台机器同时挂三四个适配器也不互相拖累，资源利用率比每人一套模型高了一大截。

适配器上线后客户提了个新需求：想在不动底座的情况下，给不同部门挂不同侧重的适配器，比如客服部门偏术语、研发部门偏代码。我们验证过多适配器并行挂载，靠路由按调用方身份选适配器，互不干扰，这下底座真正成了共享资产。评估集从真实日志抽这个做法后来成了标配，我们还加了定期回流，线上真实提问里被判错的样本自动进下一轮评估集，评估分布跟着业务走，不会再和实际脱节。客户一度想把适配器也拿去微调别的任务，我们拦了，提醒他适配器是轻量插件不是万能，跨任务还是得新建，这个边界讲清楚后反而少了很多返工，双方预期对齐了效率反而高。

五、可复用经验总结

少样本别硬上全量微调，这是这个项目最值钱的一条经验。数据不够时加术语约束比堆参数管用，我们初版背答案的教训够深刻。评估集一定要从真实日志抽，客户给的"考题"往往是挑过的，看着漂亮线上翻车。适配器做版本管理不是锦上添花，是保命手段，线上退化能秒回滚比任何预防都实在。那个术语只塞词表不生效的坑，让我们此后默认在样本里显式给术语定义，注入才稳。这套轻量适配路线现在是我们小样本客户的默认方案，但 LoRA 的秩和注入层得按任务调，术语密集的活和逻辑推理的活参数点不一样，别一套配置打天下。