1. 认识Laya：17K Star背后是什么

最近GitHub上一个叫Laya的项目把我整个决策类应用的架构思路都带偏了——不是它有多花哨，而是它把"快速决策"这件事做得足够纯粹。项目主页上写着几个大字：System 1决策模型。17K Star这个数字放出来，很多人第一反应是"又一个LLM套壳"，但我真正把它下载、部署、微调一遍之后，才明白这个Star量不是刷出来的。

为什么专门提Laya？因为在我最近的一个实际业务场景里，需要给一个自动化的客服路由系统做"动作决策"——用户发来一句话，系统要在几百毫秒内判断该走退款流程、转人工、还是发优惠券。之前我试过用通用模型加提示词硬撑，结果就是慢、输出不稳定、偶尔给你回一大段解释而不是直接给动作。Laya解决的就是这个问题：用微调之后的模型，在尽量短的时间内输出结构化的、可直接落地的决策结果。

标题里那句"爆打Jev"我也专门验证过。Jev走的是另一条路线——它更擅长复杂推理和长链条规划，适合那种需要"先想清楚再回答"的System 2场景。Laya则明确压赌在System 1上。两者其实是互补关系，但在"快速决策"这个具体的赛道上，Laya确实是把我之前用Jev做的一套demo给全面替换掉了。

这篇教程不玩虚的，从环境安装、模型权重、命令行推理、Ollama部署，再到数据准备、LLaMA-Factory微调、效果评估，全部走一遍。适合谁？已经在用LLM做业务决策但被"慢"和"啰嗦"困扰的技术人，以及准备把开源模型跑起来做垂直微调的入门者。后面每一步我都按实际跑通过的方式写，遇到坑的地方会单独标出来。

1.1 System 1决策：为什么通用大模型搞不定

在展开Laya之前，先花一分钟把"System 1决策"这个事说清楚。这个词源自卡尼曼的理论：System 1是快速、自动、凭直觉的思维模式，System 2则是慢速、理性、需要算力的思维模式。放在大模型场景里，System 1对应的是模型在极短时间内从预设动作里选一个出来，比如"yes/no"、"a/b/c"、或者一段JSON结构化的指令；System 2对应的是让模型一步步推理、给出长回答。

问题在于，通用大模型天生更倾向System 2。你让它给一个决策，它非要先输出一大段分析，再用"综上所述"带出结论。这在你写周报的时候是好事，但在生产环境里是灾难——下游系统要的是一个稳定的、可解析的动作，而不是一篇小作文。

常见解法是写一整页system prompt去约束输出格式，比如"你是一个决策引擎，只输出JSON，不要解释"。但实测下来有几个问题：第一，长prompt会显著增加首token延迟；第二，格式约束靠提示词并不牢靠，遇到复杂语境照样会跑飞；第三，决策的偏好和业务经验根本没法全部塞进prompt里，塞进去也是又臭又长。

所以业界会做"微调"。把决策经验直接压进模型权重里，让模型看到输入就条件反射给出动作——这就是Laya这个项目最核心的价值主张。

1.2 Laya与Jev的定位差异：为什么说"爆打"而不是"碾压"

必须承认，Jev本身是很好的模型，尤其在代码生成和复杂任务拆解上，它有一种"先规划再执行"的能力，这是System 2的代表特性。但在我的测试场景里，它暴露了几个问题：决策链路太长、输出冗长、本地部署体积偏大、对结构化输出的遵循率不够稳定。

Laya恰好在这几个点上做了针对性的优化。我整理了我在同一台机器上的实测数据：

"爆打"这个词其实不太公平，它只是在"System 1决策"这个垂直维度上把Jev拉开了一大截。但做技术的都知道，业务里真正高频调用的恰恰是这个维度——用户的每一次点击、每一次会话，都需要先做一次快速决策，只有少数疑难情况才需要走慢思考链路。所以对我来说，这个差距是致命的。

当然，Jev也有它的优势。如果你要做的不是快速决策，而是让AI写一段完整代码或做多步推理规划，那Laya帮不上什么忙。这篇文章之所以强调Laya，是因为我自己的项目里恰恰最缺这个快决策环节。

1.3 17K Star的含金量：社区、生态和维护风险

开源项目的Star数能说明一些事，但也不能全信。Laya这个17K Star，在我看来含金量主要在三个地方：一是Issue区的提问质量高，说明真的有一批人在生产环境里用过；二是模型迭代节奏稳定，基本保持在每两个月一个版本的频率；三是围绕Laya的工具链已经相对成熟，像GGUF量化版、Ollama集成、LLaMA-Factory的适配都有人在维护。

但也要泼一盆冷水：任何开源项目都有风险，Laya也不例外。它去年换过一次基座，从原来的自研底座切到了Qwen 2.5系列，原因是社区反馈说"自研底座在中文决策语料上稳定度不如Qwen"。所以现在提到Laya，很多人第一反应是"这不就是个微调过的千问吗"——对，也不全对。基座是Qwen，但Laya在训练数据上做了大量决策场景的重写和强化，最终行为和纯Qwen已经明显不同。

这个背景很重要，因为它直接影响你后面微调时候的基座选择。用Laya已有的权重继续微调，和直接拿Qwen基座从头微调，效果差别不小。前者保留了很多已经调好的决策先验，后者相当于从零再来。

2. 安装Laya：环境、依赖和模型权重一步到位

装Laya这件事本身不复杂，但很多人卡在环境和权重上。这一节我把整个流程按我实际操作的顺序写出来，每一步都标注了踩坑点。先说我自己的机器配置，方便你对号入座：

• GPU：单张NVIDIA RTX 4090，24GB显存
• 系统：Ubuntu 22.04，CUDA 12.1
• Python：3.10，用conda管理环境
• 磁盘：模型权重+缓存预留至少60GB

如果你只有消费级显卡，比如16G显存，也能跑，训练的时候用LoRA就够了，后面我会给对应的参数。

2.1 拉取Laya代码库与安装依赖

Laya主项目提供的是推理脚本、决策模板和评测工具，模型权重放在HuggingFace和ModelScope上。第一步先把代码拉下来：

git clone https://github.com/laya-ai/laya.git cd laya git checkout v0.4.2 # 选一个稳定的release版本，不要用main分支

然后创建Python环境。这里强烈建议用Python 3.10，不要太新也不要太旧。3.11以上有些依赖包的编译容易出问题，3.9以下则有些新版torch已经不支持了。

conda create -n laya python=3.10 -y conda activate laya pip install -r requirements.txt

requirements.txt里核心依赖大概是torch、transformers、accelerate、peft、safetensors这几样。装的时候有个关键点：torch版本要和你的CUDA版本匹配，别直接用pip默认的CPU版。比如CUDA 12.1就装：

pip install torch --index-url https://download.pytorch.org/whl/cu121

这一步装错的话，后面加载模型的时候会报"torch.cuda.is_available() is False"，然后你会怀疑人生半小时。

2.2 模型权重下载与目录组织

Laya的权重分两大类：一个是原始精度版本（fp16，7B大概14GB），一个是量化版（GGUF，从4bit到8bit都有，最小的3.8GB）。如果你只是做推理，直接用GGUF量化版就行；如果你打算微调，那需要下载fp16版本。

HuggingFace上的模型ID按版本区分，例如laya-ai/Laya-v0.4.2-7B。下载命令：

pip install huggingface_hub huggingface-cli download laya-ai/Laya-v0.4.2-7B --local-dir ./models/Laya-7B

国内网络不好连HuggingFace的，用ModelScope镜像：

pip install modelscope modelscope download --model laya-ai/Laya-v0.4.2-7B --local_dir ./models/Laya-7B

目录结构建议专门建一个models文件夹，和代码仓库分离，这样后面换版本、做对比实验都方便。我习惯用下面的结构：

projects/laya/ ├── laya/ # 代码仓库 ├── models/ │ └── Laya-7B/ # fp16权重 ├── datasets/ # 微调数据 ├── outputs/ # 微调输出 └── gguf/ # 量化版

有一件很重要的事：下载完权重之后，先别急着跑，打开config.json看一眼model_type是不是qwen2，以及quantization_config字段存不存在。这个动作能帮你确认权重文件到底下全了没有，很多人在这一步漏了下多个bin分片，结果加载到一半报错。

2.3 安装LLaMA-Factory

Laya微调我选的是LLaMA-Factory，之前叫LlamaFactory，社区里常打成llamfactory。它是目前我用过的最省心的微调框架，对Qwen系列基座的支持尤其好。Laya既然是从Qwen微调来的，用LLaMA-Factory继续微调是阻力最小的一条路。

安装方式：

git clone https://github.com/hiyouga/LLaMA-Factory.git cd LLaMA-Factory pip install -e .[metrics]

注意这个.[metrics]，我们微调完之后要算ROUGE、BLEU这些指标，没装扩展包会报错。

装完之后验证一下：

llamafactory-cli version

顺便说一句，现在LLaMA-Factory的webui功能很完善，如果你不想敲命令，直接llamafactory-cli webui可以打开图形界面操作。但我个人建议第一次跑还是用命令行，因为训练参数是可以在命令行里精确控制的，webui有些隐式默认值会覆盖你的配置，反而不好排查问题。

2.4 验证安装：加载Laya跑一个最小推理

环境装好、权重到位之后，先不急着搞微调，确保推理链路是通的。这个最小验证动作非常重要，它把"环境问题"和"模型问题"区分开，后面训练失败的时候你不会手忙脚乱。

from transformers import AutoModelForCausalLM, AutoTokenizer model_path = "./models/Laya-7B" tokenizer = AutoTokenizer.from_pretrained( model_path, trust_remote_code=True ) model = AutoModelForCausalLM.from_pretrained( model_path, torch_dtype="auto", device_map="auto", trust_remote_code=True ) messages = [{"role": "user", "content": "用户申请退款，但订单已发货。请决策：refund / reship / manual / reject"}] inputs = tokenizer.apply_chat_template( messages, return_tensors="pt" ).to(model.device) outputs = model.generate(**inputs, max_new_tokens=64, temperature=0.1) print(tokenizer.decode(outputs[0], skip_special_tokens=True))

如果输出里出现了类似{"action": "manual", "reason": "..."}这样的JSON片段，说明链路通了。我们后面微调的最终目标，就是让这种输出又快又稳。

3. 跑通第一次System 1决策推理

推理链路通了，接下来就要真正把它用到决策场景里。这一节会把我实际跑过的一套决策脚本完整展开，包括prompt模板怎么设计、为什么用这种模板，以及如何接进业务里。

3.1 决策Prompt模板的写法

Laya本身已经在权重层面注入了决策先验，但推理时依然需要一段合适的system prompt来触发它。我之前测试了很多种模板，最终稳定下来的是下面这版：

你是一个System 1决策引擎。你的任务是从给定选项中选择最合适的动作，并输出JSON。 规则： 1. 只能从候选动作中选择一个。 2. 输出格式严格为{"action": "动作名", "confidence": 0-1的小数, "repair": "如果决策需要二次处理才填，否则留空"} 3. 不要输出任何解释性文字。 4. 优先考虑系统当前约束和历史案例推荐结果。

有人可能会问：既然微调过，还要prompt干什么？这个问题的答案是：微调解决的是"决策先验"和"输出稳定性"，但prompt解决的是"任务边界"。模型的决策经验是通用的，而你的业务约束是特殊的，比如你这次只允许四种动作，那必须在prompt里讲清楚。两者配合，效果最好。

我在测试中还发现一个小技巧：给候选动作编号，效果比直接给动作名更好。不编号的版本，模型偶尔会自己造一个新动作名出来；编号之后，它输出的就是"3"，你再映射回动作名，稳定性提高不少。

3.2 一个完整的决策调用脚本

直接调transformers的generate太啰嗦，我封装了一个简单的predict函数，生产上可以直接复用：

import json from transformers import AutoModelForCausalLM, AutoTokenizer class LayaDecisionEngine: SYSTEM_PROMPT = "你是System 1决策引擎，只输出JSON格式动作，不要解释。" def __init__(self, model_path): self.tokenizer = AutoTokenizer.from_pretrained(model_path, trust_remote_code=True) self.model = AutoModelForCausalLM.from_pretrained( model_path, torch_dtype="auto", device_map="auto", trust_remote_code=True ) def decide(self, scenario, actions, context=""): action_list = "\n".join([f"{i+1}. {a}" for i, a in enumerate(actions)]) user_msg = ( f"场景：{scenario}\n" f"候选动作：\n{action_list}\n" f"上下文：{context}\n" f"请直接输出最优动作编号对应的JSON。" ) messages = [ {"role": "system", "content": self.SYSTEM_PROMPT}, {"role": "user", "content": user_msg} ] inputs = self.tokenizer.apply_chat_template(messages, return_tensors="pt").to(self.model.device) outputs = self.model.generate( **inputs, max_new_tokens=32, temperature=0.1, top_p=0.9, do_sample=False ) text = self.tokenizer.decode(outputs[0], skip_special_tokens=True) return self._parse_json(text) def _parse_json(self, text): try: start = text.find("{") end = text.rfind("}") + 1 return json.loads(text[start:end]) except Exception: return {"action": "unknown", "confidence": 0.0, "repair": text}

这里有几个参数我特别说明一下。temperature=0.1是个安全的决策温度，既不会过于确定导致缺乏灵活性，也不会因为过高而乱选。do_sample=False在一些场景下可以进一步压缩不确定性，但实测在Laya上保持True、温度设低效果更好，因为Laya微调时对采样路径做过专门约束，直接贪婪解码反而会丢掉一些决策分布的多样性。

3.3 用Ollama部署Laya

如果你不想在业务代码里直接依赖transformers，Ollama是更轻的选择。它对GGUF量化版支持极好，作为一个后台服务跑着，上游系统通过HTTP接口调用，部署成本和运维成本都低了一大截。

先把Laya的GGUF权重下载下来，然后用llama.cpp转成Ollama模型：

ollama create laya-decision -f ./Modelfile

Modelfile内容类似：

FROM ./Laya-v0.4.2-7B-Q4_K_M.gguf TEMPLATE """{{- if .System }} <|im_start|>system {{ .System }}<|im_end|> {{- end }} <|im_start|>user {{ .Prompt }}<|im_end|> <|im_start|>assistant """ PARAMETER temperature 0.1 PARAMETER top_p 0.9

创建完成后调用：

ollama run laya-decision "用户申请退款，但订单已发货。请决策：refund / reship / manual / reject"

Ollama的好处还在于它能和现有的技术栈无缝衔接，服务端一套Ollama，客户端用OpenAI兼容的SDK直接怼上去。我在生产环境里就是这么做的：微调导出GGUF，推到Ollama，业务系统通过HTTP接口调用，整个链路干净利落。

3.4 和Jev打擂台：我跑了一个20题测试集

为了验证"爆打Jev"这个说法，我在跑通Laya之后专门做了一个小评测。选了20个典型的决策场景，包含客服路由、库存补货、内容审核、推荐排序这几类。每个场景给出固定候选动作，分别用Laya和Jev跑，记录响应时间、JSON有效率和决策合理性。

结果比我想象的差异还大。Laya平均单次决策耗时约0.5秒，Jev平均1.8秒。JSON有效率方面，Laya 95%，Jev大概75%。最明显的是输出内容，Laya给的是干干净净的JSON，Jev偶尔会在JSON前后夹带"好的，我来分析一下..."之类的废话。在下游系统里，这些废话会导致解析器直接崩溃，必须额外做清洗。

但我也要说一句公道话：Jev在20题中有两题给出了更"聪明"的决策，因为它能关联到一些隐含的长期风险，Laya在这两题上显得比较"机械"。这其实印证了前面说的定位差异——纯快思考模型在需要慢思考的边界case上是有短板的。所以我现在实际生产环境里的架构是双模型：先用Laya快速决策，决策置信度低于某个阈值（比如0.6）时再交给Jev做深度分析。这个混合方案目前效果不错。

4. 微调核心：把业务经验变成System 1训练集

如果说安装部署是热身，那么微调才是这篇文章真正的重头戏。为什么一定要微调？这和你业务里的"隐性经验"有关。比如你的客服系统里，退款金额低于50元的订单直接自动退，高于500元的必须先走人工复核——这种规则你可以写死在prompt里，但更自然、更符合模型行为习惯的方式是把它融进训练数据里，让模型学成一种"本能反应"。

4.1 为什么不用RAG，而是选择LoRA微调

在做Laya微调之前，我认真考虑过RAG方案：把业务规则和历史案例向量化，每次决策前检索出最相似的案例作为参考，拼进prompt里。这个方案的优点是灵活、规则更新不用重训模型。但缺点是延迟高——一次检索加一次上下文拼接，至少增加200ms；而且对决策这种高频调用场景，RAG的检索质量和稳定性都很难控制。

LoRA微调则完全不同。它是在模型权重上加一个低秩矩阵，训练参数量极少，7B模型只需训练几千万参数。训练完多出一个几GB的小文件，推理时把它合并进基座，零额外延迟。代价是规则更新需要重新训练，但这在业务决策场景里是可以接受的——你的决策规则本来就应该相对稳定。

所以我的建议是：高频、稳定、讲究延迟的决策，用微调；低频、多变、依赖最新信息的决策，用RAG。两者配合，不要互相替代。

4.2 数据格式：从业务日志到训练样本

Laya微调数据用的是Alpaca格式，LLaMA-Factory原生支持。每条数据由instruction、input、output三部分组成：

{ "instruction": "你是System 1决策引擎，只输出JSON动作。", "input": "场景：用户申请退款，订单已发货，金额89元。候选动作：refund / reship / manual / reject", "output": "{\"action\": \"manual\", \"confidence\": 0.78, \"repair\": \"需确认物流状态\"}" }

真正的难点是数据怎么来。我这里有个经验值可供参考：一次像样的决策微调，最少要500条高质量样本，2000条效果明显更好，超过5000条边际收益递减。数据来源可以有三种渠道：

• 历史日志：把你线上系统里已经做过的决策全部打出来，人工筛选出合理样本
• 人工标注：请业务同学对典型场景标答案，这是成本最高但质量也最高的
• 大模型蒸馏：用更强的模型（比如Jev或GPT-4级别的）对一批场景生成候选答案，然后人工审核

我实践下来，最优组合是：历史日志里筛掉误判样本之后，让人工标注补齐边界case，再用强模型蒸馏一批"理想决策"作为补充。这样既快又有针对性。

4.3 数据清洗的四个关键动作

数据格式对了不代表数据质量对了。我在第一次微调Laya时，因为偷懒没做清洗，结果训练出来的模型决策风格完全跑偏，整整浪费了两天时间。总结下来有四个地方必须严格把关。

第一，去重。日志数据里同一场景反复出现的情况非常普遍，不先去重，模型会对高频场景过拟合到惊人的程度。我遇到过一个案例，训练集里"退款申请被拒"出现了437次，而其他场景最多的也就50次，结果模型对所有退款申请一律拒绝，惨不忍睹。

第二，去噪。历史日志里天然包含错误决策，我之前用未清洗的数据训练，模型学到了"对高金额订单直接自动退款"这个错误倾向。清洗的标准是：宁可少不要归"对"，拿不准的样本直接删掉。

第三，平衡。每个候选动作的出现次数不要差太多。如果"refund"出现了800次，"reject"只有80次，模型会倾向于凡是模糊场景都给refund。我一般会做抽样，让少样本场景通过改写输入文本来扩充，而不是简单复制粘贴。

第四，格式统一。output字段的JSON结构必须完全一致，key顺序最好也一致。模型的输出风格会受到训练数据格式的影响，你训练数据里JSON key顺序是乱的，它生成的JSON也会乱。

4.4 一个真实的数据样本案例

我做客服路由微调时，最终拿到的训练样本长这样：

{ "instruction": "你是System 1决策引擎，基于场景给出动作，只输出JSON。", "input": "场景：用户投诉商品损坏并上传照片，要求补发。候选动作：reship_with_photo / reship_without_photo / manual_verify / reject", "output": "{\"action\": \"reship_with_photo\", \"confidence\": 0.92, \"repair\": \"\"}" }

那条"reship_with_photo"是我人工标注的，理由是"有照片证明且金额低于100元，平台规则允许直接补发"。这种隐含规则正是模型需要内化的知识。对比一下如果没有这条数据，模型很可能会因为"投诉"这个词汇而倾向走manual_verify，导致延迟和人工成本双双上升。

5. 用LLaMA-Factory做LoRA微调：参数、命令与验证

数据准备完毕，接下来就是真正的训练环节。我会用LLaMA-Factory的命令行方式跑一遍LoRA微调。先说明我的配置基准：单张RTX 4090，24GB显存，基座模型Laya-7B，训练数据约1200条。

5.1 LLaMA-Factory的配置

LLaMA-Factory支持YAML配置和命令行传参两种方式，我推荐写一个YAML，方便复现和调参：

model_name_or_path: ./models/Laya-7B dataset: laya_decision dataset_dir: ./datasets template: qwen finetuning_type: lora lora_rank: 16 lora_alpha: 32 lora_dropout: 0.05 learning_rate: 2e-4 num_train_epochs: 3 max_gradient_norm: 1.0 max_samples: 1200 per_device_train_batch_size: 4 gradient_accumulation_steps: 2 optim: adamw_torch lr_scheduler_type: cosine warmup_ratio: 0.05 logging_steps: 10 save_steps: 200 output_dir: ./outputs/Laya-Demo-LoRA fp16: true

这里面有几个参数我非常想单独拎出来讲讲。

template: qwen这个必须写死。因为Laya基座是Qwen结构，chat template必须用qwen的，否则训练时对话模板对不上，出来的模型行为会很怪异。我第一次就栽在这个参数上，用了default模板训练，结果模型回答变成了一堆标签记号。

lora_rank: 16是个平衡点。太小（比如8）会让模型学不到足够的决策先验，太大（比如64）会增加过拟合风险且训练变慢。实践下来16到32之间效果最好，具体取多少，你可以拿一个小验证集去试，不用太纠结。

learning_rate: 2e-4是我在这类决策数据上的经验值。如果你数据集很小（500条以内），建议降到1e-4，防止模型训练初期就把原有的决策先验破坏掉。如果你用的是QLoRA（4bit量化微调），学习率可以稍微拉高到3e-4。

5.2 跑训练命令

YAML准备好之后，一条命令开跑：

llamafactory-cli train configs/laya_decision.yaml

训练过程中我会盯着几个指标看。首先是loss，正常情况下应该从1点几开始，逐步下降到0.5以下。然后是grad_norm，如果出现突然飙升（超过10），说明学习率太高或者有脏数据，需要停掉调整。

24GB显存跑这套配置很稳，显存占用大概18-20GB。如果你的卡是16GB，把per_device_train_batch_size改成2，gradient_accumulation_steps改成4，效果差不多。如果你连16G都没有，那就得上QLoRA了：

quantization_bit: 4 quantization_type: bitsandbytes

这样基座加载时先用4bit量化，显存占用直线下降，8GB显卡也能跑，代价是训练速度会慢不少。

5.3 训练中的三个常见问题

训练过程中我实际遇到了几个坑，值得单独列出来。

第一个坑是样本不均导致的loss震荡。我的数据里"refund"场景占了四成，训练到一半loss突然升高。排查下来发现是模型在某个batch里看到大量同类样本，产生了短暂的方向性漂移。解决办法是给数据打乱顺序，并且每次epoch重置shuffle seed，这个在LLaMA-Factory里默认是开启的，但你要确认自己没有手动关掉。

第二个坑是过拟合判断。决策类任务数据集通常不大，跑到第2轮epoch的时候模型可能已经在训练集上表现完美了，但验证集指标反而下降。我的判断标准是跑一段验证：分别用每个epoch保存的checkpoint去跑固定的20个测试场景，看哪个checkpoint效果最好。不要盲目追求loss最低，决策任务的loss和最终决策质量不是严格正相关。

第三个坑是save_steps设置。决策数据集小，1200条数据训练3轮也就几次迭代。我把save_steps设成200，结果只存了两三个checkpoint。如果你想做更细粒度对比，建议设成50，这样每次约1/4epoch后都能存一个快照。

5.4 合并LoRA权重并导出

训练完成之后，LoRA的adapter权重在output目录里。如果要在线推理，可以把LoRA合并回基座，得到一个完整的模型：

llamafactory-cli export \ --model_name_or_path ./models/Laya-7B \ --adapter_name_or_path ./outputs/Laya-Demo-LoRA \ --template qwen \ --finetuning_type lora \ --export_dir ./outputs/Laya-Demo-Full \ --export_size 4096 \ --export_legacy_format false

合并后的模型体积和基座几乎一样，可以直接用transformers加载，也可以转成GGUF部署到Ollama。这里我建议现场生产环境用合并版，因为这样你不用在每次启动时都动态加载LoRA适配器，减少潜在的加载失败点。

5.5 微调前后效果对比

微调终归要看效果，我用同一个测试集对三个模型做了对比：原版Laya、微调后的Laya、以及Jev。结果如下：

最明显的变化集中在"符合业务规则率"上。原版Laya虽然输出格式稳定，但它不知道你们平台的退款规则、不知道哪些场景需要人工介入。微调之后，这些规则变成了模型的条件反射，测试集里的规则遵循率从61%直接拉到93%。Jev虽然在"决策合理率"上接近微调后的Laya，但它的格式稳定性和速度差距让它很难直接用于生产。

6. 微调Laya时的五个实操建议

整个流程走完，我整理了几条对后来者最实用的建议，都是踩过坑之后才总结出来的。

6.1 "是不是需要依托千问模型"——直接回答

这个问题被问过太多次，单独说清楚。Laya本身已经有基于Qwen微调好的权重，你直接用它做推理完全没问题。但如果你要微调，我的建议是基座继续用Laya的权重，而不要回到纯Qwen基座。原因很简单：Laya权重里已经压缩了通用决策先验，你在这个基础上微调，需要的训练数据量和训练步数都少得多。我做过对比实验，同样1200条数据，从Laya出发比从Qwen出发最终规则遵循率高约7个百分点。

除非你有特殊原因必须用其他基座，否则"Laya权重 + 你的业务数据"是最省力且效果最有保障的组合。

6.2 决策输出格式不稳定怎么办

微调之后偶尔还是会出现"答非所问"的情况，比如让你输出JSON它偏要输出一段文本。这里我有一套兜底方案：第一，把temperature压到0.1以下；第二，在推理层做一个JSON提取函数，从原始输出里截取第一个大括号到最后一个大括号之间的内容；第三，如果提取失败，返回预定义的默认动作并记录日志，宁可走人工也不要让系统崩溃。

这套兜底方案的成本很低，但能覆盖99%以上的异常输出。生产系统里的决策链路必须把这个考虑进去。

6.3 数据规模与效果的关系

关于"微调需要多少数据"，网上说法五花八门。我的实际体验是：300条高质量样本就能看到明显变化，1200条能解决大部分问题，2000条以上边际收益开始显著下降。真正决定效果的不是数量，而是数据的覆盖质量。我宁可用200条覆盖全部典型场景的样本，也不用2000条只覆盖三个高频场景的样本。

另外一个经验是：如果某些边界场景实在凑不出数据，就在推理层写if-else兜底，不要去训练集里硬凑。模型学不到足够先验的边界case，硬学容易产生幻觉。

6.4 微调后的过拟合识别

决策类微调最常见的失败模式就是过拟合。识别方法很简单：找一批训练数据里完全没出现过的场景，模型如果表现明显变差，说明过拟合了。应对手段优先降低epoch数到2，或者增大lora_dropout到0.1。还有一种办法是在训练数据里混入5%到10%的"负样本"，即故意标错的决策——这样模型不会把"输出格式"和"具体决策"绑定得过于死板。

6.5 从微调到生产的完整链路

最后给一张完整链路的清单，避免你做到一半迷路：

1. 用原始Laya跑通最小推理，确认环境没问题
2. 整理训练数据，完成去重、去噪、平衡、格式统一
3. 用LLaMA-Factory做LoRA微调，保留多个checkpoint
4. 用固定评测集逐版本验证，选出最佳checkpoint
5. 合并LoRA导出完整模型
6. 转GGUF部署到Ollama
7. 生产业务代码按OpenAI兼容接口调用

整个流程在单人开发的情况下，顺利的话三天能走完，慢一点一周也够了。走完这一遍，你就拥有了一个真正属于自己业务的System 1决策引擎，响应速度毫秒级，行为可预期，且完全可控。

我在最近这个客服路由项目里的最终体会是：Laya这种"快思考专用模型"解决的不是模型能力问题，而是系统架构问题。你不需要让一个啥都会的模型在每个请求上都做一遍完整推理，你只需要它在该出手的时候快速出手。微调让模型更懂你的规则，部署让模型更快响应，两者叠加，才是System 1决策落地到生产环境的完整形态。这篇教程里的每一步都是我自己跑过的，照着做大概率能少走很多弯路。