1. 为什么我用本地AI跑任务老是翻车

我一开始是在本地部署了一个7B的开源模型，想让它全自动处理一批文档分类和摘要的任务。跑起来之后发现问题特别多：分类结果经常漂移，同样是“报销单”这个关键词，上午还能准确识别，下午就开始把“报销明细”分到另外一个类别里；摘要任务更夸张，模型上下文一长就开始自我发挥，摘要里凭空出现原文档里根本没有的内容。最后统计了一下，单纯靠模型一把梭的准确率只有61%。后来我把这个问题拆开了看，发现根子不在模型本身，而在任务结构上。

1.1 本地模型和API模型在长链任务上的差距

先坦白说，本地模型和API模型在单次对话里完成多步推理的能力是有差距的。API模型参数量大、训练数据丰富，在长链任务上表现相对稳定；本地模型受显存和参数量限制，指令跟随能力在复杂场景下会更脆弱。这不是说本地模型不能用，而是说我们在设计任务流程时，要尊重模型的能力边界。

一个特别直观的现象：当我在一条提示词里同时要求做“提取关键词、判断类别、生成摘要、输出结构化JSON”四件事时，本地模型经常只完成前两件就草草收场，JSON输出也经常多一个逗号或少一个花括号。我做了一个压力测试，连续跑50条，只有12条是完全符合JSON格式的，成功率24%，基本不可用。这不是模型笨，而是任务太重，推理路径太长，概率性错误被叠加放大了。

1.2 任务拆分不是玄学，是工程

很多人一提“任务拆分”就想到让模型自己拆，比如用一条提示词说“请把以下任务拆成子任务”。这个思路在交互式场景里还行，但在批处理流水线里是灾难。因为模型拆任务本身就要消耗一次推理，拆完之后子任务的质量又是随机的，等于把不确定性翻倍了。

后来我换了思路：把拆分规则从“模型判断”改成“程序判断”。也就是先写一层程序化的规则来做任务拆分，模型只负责拿拆分好的小块去执行。这个改变让整体稳定性一下子提高了，因为规则是确定的、可穷举的、可以单元测试的，模型的不确定性被压缩到了最小的执行单元里。

1.3 两级流水线是怎么想出来的

所谓两级流水线，就是一条自动化任务链上，第一级L0只做分流和校验，完全不调用模型；第二级L1拿到L0分出来的干净子任务，再调用本地模型执行真正的内容处理。这个想法不是一开始就有的，是我在一次误路由事故之后才想明白的：当时一批发票扫描件的识别任务全部进了闲聊通道，模型的返回完全没法用，浪费了整整一个上午。后来我在L0层加了几个正则规则，彻底堵死了这类误路由，才意识到L0应该是“硬规则”，不是模型提示词能替代的。

2. 两级流水线的整体设计与落地

两级流水线听起来抽象，但落地就两个渠道代码块的事。L0很多时候只是一个路由函数，跑一遍关键词和正则，几毫秒就返回；L1则是一个模型调用函数，把文本和系统提示词打包给本地模型，拿回结构化结果。

要说清楚这个设计，我用一个实际场景来演示：本地知识库文档分类。任务输入是一份文本，需要判断它属于技术方案、测试报告、会议纪要还是其他，并且输出对应的摘要和标签。

2.1 L0层：不靠模型靠规则

L0要干的事包括三块。

第一块是格式预处理：比如去掉多余的换行、控制字符、HTML标签，把全角符号转成半角。这步不做，后面的正则容易漏。

第二块是路由判断：用关键词表和正则表达式判断文档类型。比如“测试报告”关键词加“用例通过率”正则，基本可以锁定测试报告；“会议时间”“参会人”加“决议事项”锁定会议纪要。关键词表是从历史数据里统计出来的高频词，这是经验值，前期可以先粗一点，后面按失败样本逐步扩充。

第三块是质量校验：对L1的输出做硬校验——JSON是否能解析、字段是否齐全、值的类型是否正确。校验不合格就退回重跑，最多重试两次。这块很重要，因为本地模型偶尔会输出非常离谱的JSON。

代码层面L0的核心逻辑大概是这样的：

def l0_route(text: str) -> str: text = normalize_text(text) for rule in RULES: # 按优先级顺序匹配 result = rule.match(text) if result: return result.channel return CHANNEL_FALLBACK # 兜底通道

RULES这里我按优先级排了一个列表，每个规则对象包含正则、关键词权重和对应通道。规则匹配不是完全命中才算，而是算一个累计分数，超过阈值就放行。这样能避免某个单一正则因为文本微调而失效。

注意：L0做成纯规则还有一个附带好处——它可以做单元测试。我在项目里维护了一个带标注的测试集，每次改L0规则都会批量跑一遍，确保不会因为新增规则把历史案例打乱。这个习惯后面救了我好几次。

2.2 L1层：让模型只做它擅长的事

L1层的设计原则很简单：一次调用只做一件事。比如分类通道里，系统提示词就只写“你是文档分类助手，只能输出JSON，字段为category、confidence”，不要再让它顺便生成摘要。摘要通道同理，只做摘要输出，不做分类判断。

这样做的好处有三个。第一，上下文更聚焦，模型不用在多个任务之间切换注意力，输出质量更稳；第二，提示词模板可以独立优化，分类效果不好只改分类模板，不影响摘要模板；第三，并发调度更方便，不同的通道可以用不同的上下文长度和温度参数。

我实际的配置是：分类通道temperature设到0.1，几乎接近确定性输出；摘要通道temperature设到0.3，保留一点文字多样性；关键词提取通道temperature设到0。本地模型在低温下表现稳定很多，特别是结构化输出场景，温度一高就容易在JSON里乱加内容。

提示词模板拿分类通道举例，大概长这样：

你是文档分类助手。请阅读下面文本，判断它属于：tech_solution / test_report / meeting_minutes / other。 只输出一个JSON对象，不要输出任何解释和多余内容。 格式: {"category": "类别", "confidence": 0到1之间的小数}

这个模板看着简单，但实际测试下来，加上“不要输出任何解释”这句话，JSON解析成功率能从60%拉到85%以上。如果配合低温参数，能稳定在95%以上。

2.3 通道配置与分发策略

通道分发的核心是“量体裁衣”。同样是本地模型推理服务，不同的通道可以走不同的模型实例。我机器是双卡配置，一张卡跑的是通用对话模型，另一张卡跑的是精调过的结构化输出模型。L0路由之后，技术方案类走通用模型，测试报告类走结构化模型，这样能把负载切开，避免所有任务挤在同一个模型进程里争显存。

还有一个容易被忽略的点：队列和超时。批处理场景里，如果业务方用同步方式等待结果，L1模型一旦推理超时就会连带阻塞一批任务。我后来改成了异步队列加超时降级：L0把任务丢进队列，L1的消费进程慢慢跑，超时的任务标记失败，进入重试队列。改完之后，单批处理时间从18分钟降到了11分钟，吞吐提升很明显。

3. L0硬规则的踩坑实录

L0听起来简单，但真正写起来坑特别多。这些坑大多是我在真实任务里撞出来的，每一个都对应过一次线上事故。下面挑几个典型的说。

3.1 规则优先级冲突

第一个坑是规则优先级冲突。一开始我把技术方案的关键词“方案”放在了前面，测试报告的关键词“报告”放在后面，结果遇到一篇标题叫《XX系统测试方案》的文档，L0毫不犹豫地进了技术方案通道。后来在排优先级的时候我就长了个心眼，把“测试”和“报告”组合词提到前面，把包含“测试方案”这种双重身份的文档用组合规则单独处理。

这个坑的教训是：L0规则不是越多越好，而是优先级排序要能覆盖组合场景。我后来给每条规则加了一个权重值，命中不是走“第一个命中的规则”，而是累计权重，哪个通道权重最高走哪个。这样即使组合词同时命中多个规则，也能按权重得到合理的路由。

3.2 正则过宽引发误路由

第二个坑是正则表达式写得太宽。我曾经为了匹配日期格式，写了一个\d{1,2}[月/]\d{1,2}的正则，结果把“3/8节促销方案”这种文本也匹配成了会议纪要，因为会议纪要通道里就有日期正则。整整一批营销文案被错误路由，后续处理全部废掉，重跑了一次。

后来我的做法是：正则只用于强特征，比如“测试报告编号：TEST-\d{4}”这种带固定前缀的，而不是通用日期。通用弱特征靠关键词权重累加，强特征才用正则。这是L0设计里非常核心的一条经验。

注意：新增L0正则前，先拿10条真实历史样本跑一遍，看看误命中情况。别觉得正则灵活就随手往上加，误路由的代价往往比漏路由大得多。

3.3 分词与编码的坑

第三个坑跟编码相关。本地文档经常有中文全角符号和奇怪的编码，如果不在L0做归一化，后面全部都会乱。有一次一个PDF转出来的文本里全是\u3000空格和乱码符号，正则匹配全部失败，任务全部落到了兜底通道，兜底模型又被这些乱码干扰，输出的摘要直接不忍直视。

解决办法是在L0最前面做一层文本清洗：把全角转半角、把多个连续空格压缩成一个、去掉控制字符和零宽字符。写了个normalize_text()函数，实测下来很多“诡异问题”直接消失。这个函数我建议每个人都提前写好，别等踩坑再补。

def normalize_text(text: str) -> str: text = text.replace('\u3000', ' ') text = re.sub(r'[\x00-\x1f\x7f]', '', text) text = text.replace('\u200b', '').replace('\ufeff', '') text = re.sub(r'[ \t]+', ' ', text) text = re.sub(r'\n{3,}', '\n\n', text) return text.strip()

3.4 兜底策略不能省

第四个坑是关于兜底通道的。最开始我以为L0能覆盖绝大多数场景，兜底通道只是随便放了个通用提示词。结果业务方陆续丢进来一批完全没有预料到的文档类型，比如“操作手册”“安全巡检表”“需求变更单”。这些文档要么进入兜底后输出质量很差，要么被强行匹配到一个接近的规则但处理结果完全不合适。

后来我把兜底通道也做成了一种“半硬规则”：先对兜底样本做统计，抽取出几个高频特征词，形成一个“软分类”逻辑，至少能区分“文档类”“表格类”“代码类”这三种大方向。这样兜底通道至少能给出一个粗粒度的分类，而不至于把操作手册当做代码块去解析。

4. 调优实战：从0.6到0.92的准确率提升

我这一套系统最终的目标准确率是0.92。从最初的0.61一路调上来，实验记录挺多，我把关键步骤整理一下，这套思路在别的任务上也大概率能复用。

4.1 先在L0上做文章

第一步就是优化L0规则本身。我维护了一个每天更新的误路由样本库，收集当天识别失败的案例，然后分析失败原因。原因分几类：

这一步做完，准确率从0.61提升到了0.78。不要小看规则层，它是最确定的杠杆，改一次就能全局生效。

4.2 L1侧参数怎么调

第二步调L1侧的推理参数。我重点调了三项：temperature、repeat_penalty、max_tokens。

• temperature从默认的0.7降到0.1~0.3之间，结构化输出场景降到0。
• repeat_penalty从1.0往上加，文本一长模型容易陷入重复，配合max_tokens限制来压制。
• max_tokens不要给太少，否则模型会在输出一半的时候截断；也不要给太多，否则多余token会被模型用来填充废话。

另外一个关键点是提示词的输出格式约束。我发现，与其让模型自由输出再解析JSON，不如在提示词里给一个极其明确的模板示例，甚至可以说“只输出一个JSON对象，不要任何解释”。本地模型对“不要解释”的理解比API模型要弱一些，所以输出后必须做一次程序化校验，不合格就重试或降级。

4.3 性能数据对比

调优之后我做了一次对比测试，同样是1000条混合文档，结果如下：

时长下降也很有意思，原因是任务被正确路由后，模型的上下文和任务类型更匹配，无效推理少了，重试也少了。这也能说明任务拆分本身就在节省算力。

4.4 一套可以复用的调优模板

调优工具这块，我固定了一套流程，每次拿到一批新任务都会跑一遍：

1. 用当前L0规则跑一遍历史样本，记录误路由。
2. 按误路由原因分类，优先修占比最大的那类。
3. 每修完一轮，跑一次回归测试集，确保整体准确率不下降。
4. L1侧先不做大改，等L0稳定后再去动temperature和提示词模板。
5. 每次实验都记录日志，沉淀成一条可对比的实验记录表。

这套流程看着简单，但是坚持下来收益很大。我现在的模型没变，只是把路由和提示词调顺了，效果就已经完全是两个量级。

5. 常见问题排查速查表

最后整理一个速查表。这张表是我踩过坑之后的固定查表工具，每次遇到问题先对照一遍，能省很多排查时间。

我个人在实际使用中最深的体会是：本地AI任务拆分的核心不是模型本身，而是流程设计。买再好的显卡、部署再大的模型，如果任务一股脑地塞给模型处理，效果都会打折扣。反而是在源头把任务结构拆清楚，让模型每次只做一件事，整套系统才能又稳又省。

最后再分享一个小技巧：L0规则列表可以按周复盘一次。我每周五下午会拉出一周内所有走兜底通道的样本，快速过一遍，发现有明显规律的，就追加一条规则进去。刚开始每周都要加两三条，到后面就越来越少，系统也就越来越省心。

再补一句：这套两级流水线的思路不局限于文档分类，任何需要本地模型批量处理的场景都可以套用。核心就一句话——能用规则解决的事，就别让模型去猜。拿这句话去做所有流程设计的出发点，很多坑是可以提前避开的。