上个月我接了一个本地文档整理的活儿两百多个文件散落在三个子目录里PDF、Word、Markdown、Excel 混在一起文件名一半是新建文档(23).docx这种毫无信息量的玩意儿。一开始我的方案很天真——直接把目录路径、文件清单丢给本地大模型让模型输出每个文件应该放到哪个分类目录。结果等了快二十分钟模型洋洋洒洒写了一堆建议其中有五个文件名根本不存在还有两个分类逻辑前后矛盾。那是我第一次意识到把任务全部交给本地 AI 模型处理本质上是在用大炮打蚊子而且这尊大炮还经常脱靶。后来我把方案改成了两级结构先用 L0 硬规则层把所有能靠规则确定下来的事情全部处理掉只有规则判断不了的文件才会进入 L1 模型层由本地大模型做兜底决策。这就是标题里说的L0 硬规则前置 L1 模型兜底两级流水线。这套结构跑下来两百多个文件总耗时从 40 分钟压到了 6 分钟出头准确率反而从 89% 提到了 97%。这篇文章就把这套流水线的设计思路、落地代码和踩过的坑完整记录下来——如果你也在做本地 AI 部署相关的自动分类、自动整理、批处理任务这套规则优先、模型兜底的思路应该能帮你省下大量无用算力和时间。1. 为什么任务要先经过硬规则而不是全部丢给模型先说结论模型适合做模糊判断不适合做确定查找。这是两种思维范式的差异不是模型能力高低的问题。1.1 大模型不是全自动万能分类器很多第一次接触本地 AI 的朋友会对大模型产生一种什么都能干的错觉。给它一个文件它可以按内容总结出主题给它一堆散乱的文件名它能编出一套分类方案。这个能力确实存在但它有几个致命副作用不保证确定性同一个文件你让它判断两次它可能给出不同的分类结果。做文档归档这种事要求的是这个文件今天归档到 A 类明天重新跑一遍也必须归档到 A 类模型天然做不到这一点。存在幻觉模型可能会输出一个不存在的目标路径或者把Q3_财报_final_v3.pdf里的final理解为最终版而忽略了v3的存在。速度慢得离谱在 RTX 4060 Ti 16G 上跑一个 7B 量化模型处理一个文件的推理时间大约是 15 到 25 秒。200 个文件全量丢给模型即使不考虑失败重试也要一个小时量级。上下文窗口限制如果你把全部文件清单一次性塞进提示词输出长度一旦超过限制模型会直接在中间截断后半段文件全部失联。所以问题的关键不是模型好不好用而是**什么事根本不该让模型来做**。1.2 硬规则的两个不可替代的优势L0 层的硬规则简单说就是一系列确定性的判断逻辑正则表达式、文件名前缀匹配、扩展名白名单、目录结构校验、哈希去重等等。它有两个模型无法取代的优势第一100% 确定性。规则是什么样的结果就是什么样的。运行一百次结果完全一致这意味着你可以把它放在流水线的最前端做幂等处理日志和审计也完全可预期。比如规则写着文件名含 发票 的文件归入 [财务/票据]它就是永远这么判不会抽风。第二近零成本。一次模式匹配耗时是毫秒级的消耗的只有 CPU连 GPU 都不需要亮。相比之下模型推理一次至少几十亿参数在前向传播耗电、占用显存、排队成本完全不在一个量级。1.3 两级流水线的整体结构我把这套流水线设计成三个角色的协作而不是简单的规则失败后再调模型第 1 步预检 读取文件元信息扩展名、大小、路径、创建时间 读取文件名、文件头字节用于识别真实类型 第 2 步L0 硬规则判定 按优先级依次检查规则清单 - 命中输出分类结果任务结束生成日志 - 未命中进入待定池转交 L1 第 3 步L1 模型兜底判定 按批次送入本地大模型 模型输出结构化 JSON含分类、原因、置信度 解析并校验输出超过阈值则采纳否则进人工复核队列这里有个关键设计L0 不是规则失败才让模型上而是规则的拒绝权高于模型的决定权。也就是说如果 L1 模型输出的结论与 L0 已经判断好的结果冲突流水线默认以 L0 为准同时把冲突记录到日志里供人工复查。这个仲裁逻辑我在第 4 节会详细展开。2. L0 规则层的设计优先保证确定的判断绝不交给模型很多人写规则层会犯一个错误试图用规则解决所有问题结果规则越写越复杂最后比调模型还难维护。我的经验是L0 只处理看一眼就知道答案的情况拿不准的就干脆放行。2.1 先列任务类型白名单再写规则一切开始之前先把你要处理的文件可能归属的类别列出来。比如我在文档整理这个场景里列的分类分类判断依据示例财务/票据文件名含发票、报销、流水、对账单扩展名为 .pdf 且文件头为 PDF合同/协议文件名含合同、协议、契约含甲方、乙方关键词技术/代码扩展名 .py .js .go .md路径含 /src/ /code/人事/简历文件名含简历、个人简介文件头为 .docx 且内容首行含教育经历设计/图片扩展名 .png .jpg .sketch .fig文件头为图片魔数素材/模板文件名含模板、template扩展名 .pptx .docx 且位于 Templates 目录白名单的意义在于它同时定义了输入空间和输出空间。模型兜底时不会让它自由发挥一个新分类出来而是在这六个分类里做选择。这能显著抑制模型的跑偏倾向。2.2 常用硬规则模板和 Python 实现我整理了几类在文档整理、本地文件治理场景里最高频的硬规则每一类都配有可以直接抄走的代码逻辑规则 A扩展名与文件头双重校验只靠扩展名判断文件类型很容易被伪装文件骗过去比如一个 .txt 文件实际内容可能是 HTML。所以我会做双重校验文件头魔数 扩展名一致性。import struct from pathlib import Path MAGIC_MAP { pdf: [b%PDF], png: [b\x89PNG\r\n\x1a\n], jpg: [b\xff\xd8\xff], docx: [bPK\x03\x04], # 同时也覆盖 xlsx/pptx gif: [bGIF8], } def sniff_type(path: Path) - str: 返回: pdf/png/jpg/docx/gif/unknown with open(path, rb) as f: head f.read(8) for ftype, magic_list in MAGIC_MAP.items(): for magic in magic_list: if head.startswith(magic): return ftype return unknown规则 B命名模式正则这是最实用的一组规则。用正则从文件名里抽日期、编号、版本号这些信息在模型看来是需要理解的语义但在规则里只是一次匹配。import re pattern_rules [ # 文件名含发票/报销或形如 INV_2024xxxx {category: 财务/票据, regex: r(发票|报销|INV_|对账单|流水)}, # 文件名含合同或编号形如 HT-2024-xxx {category: 合同/协议, regex: r(合同|协议|HT-|agreement)}, # 技术类代码扩展名兜底 {category: 技术/代码, regex: r\.(py|js|go|ts|java)$}, # 简历类 {category: 人事/简历, regex: r(简历|resume|个人简介|CV_)}, ]规则 C路径定位这一类规则不依赖文件名而是依赖文件当前所在的目录结构。适合处理已经有人按目录粗分过一遍但没整理干净的情况。PATH_KEYWORDS { 财务/票据: [finance, 财务, 报销, invoices], 技术/代码: [src, code, backend, 前端, 后端], } def rule_by_path(path: Path) - str | None: for category, keywords in PATH_KEYWORDS.items(): for kw in keywords: if kw in str(path).lower(): return category return None规则 D哈希去重与空文件拦截这个往往被人忽略。整理文件时如果混入重复文件后面的模型层会白算好几遍。用xxhash或者hashlib.md5做一次去重重复文件直接按已归档处理不再进入后续任何环节。2.3 L0 的主动放弃原则这是整个流水线里最反直觉但也最重要的一条L0 层必须允许自己判断不了。我在第一版实现里为了让规则更全面加了一堆模糊规则比如文件名含 6 位数字则归为编号文件。结果误判率飙升——很多设计稿的文件名里也带数字版本号却被归到财务类里去了。后来我悟了规则的使命不是覆盖所有情况而是覆盖确定无疑的情况。所以在规则设计时我给每条规则加了一个字段confidence只有confidence 0.98的规则才允许直接输出结果像看起来像、大概属于这种模糊判断我一律把它扔给 L1 模型。硬规则的放弃反而是整个流水线准确率的保障。3. L1 模型兜底接入本地 7B 模型如何在不联网环境下给出稳定结论L0 放行的文件会进入 L1 模型层。这一层的工作是把模糊判断集中起来交给模型处理但绝不是把文件名发过去让它自由发挥这么简单。你需要做三件事选一个合适的模型、设计一个约束性强的提示词模板、做一套输出解析和重试机制。3.1 模型选型深入理解显存与量化之间的博弈本地部署 AI 模型时显存是硬约束。我机器上是 RTX 4060 Ti 16G实测下来的选型逻辑是这样的模型量化等级显存占用单次推理耗时处理100字输入判断质量qwen2.5:7b-instruct-q4_K_MQ4_K_M约 5.2G约 8-12 秒足够胜任文件名分类llama3.1:8b-instruct-q4_K_MQ4_K_M约 6.1G约 12-18 秒略强但对中文文件名不够敏感qwen2.5:3b-instruct-q4_K_MQ4_K_M约 2.4G约 3-5 秒偶尔无视输出格式慎用我的结论很直接在 16G 显存档位qwen2.5:7b 的 Q4_K_M 量化版是最均衡的选择。它体积小、速度快因为输入文本极短本质是在做短文本分类、对中文理解好而且极少出现完全无视指令的情况。如果你显存只有 8G那 7B 的 Q4 量化版勉强能跑但会让出不少上下文空间此时实测 qwen2.5:7b 可能挤占显存建议退到 qwen2.5:3b 或 gemma2:2b但需要接受偶尔输出不稳定的代价。这里插一句常被问到的本地部署 ai 大模型的显存要求到底怎么算我的经验公式是模型文件大小 约 1.5 倍上下文缓存 最低显存占用。比如 4.7G 的 Q4 量化模型配合 8K 上下文大约需要 6~8G 显存才舒服。如果显存被占满Ollama 会退化为 CPU 推理速度慢到无法接受。3.2 提示词模板把输出空间压缩成选择题模型分类精度低80% 的原因在于提示词给的自由度太高。我的策略是把开放式问题改成封闭式选择题只允许模型从六个既定分类里选一个并且要输出 JSON。你是一个文档分类助手。 现有文件信息如下 - 文件名: {filename} - 扩展名: {ext} - 真实类型: {sniff} - 所在路径: {path} 请判断该文件最可能属于以下哪个分类 [财务/票据, 合同/协议, 技术/代码, 人事/简历, 设计/图片, 素材/模板] 只能输出 JSON格式 {category: 分类名, reason: 一句话理由, confidence: 0到1的小数} 不要输出任何其他内容。这个模板的核心在于只能输出 JSON和不要输出任何其他内容。为了让模型真正遵守我还在代码里加了输出后校验如果返回不是合法的 JSON或者 category 不在白名单内就当作解析失败处理。3.3 调用 Ollama 并做输出解析我用的是 Ollama 的 HTTP API直接通过 requests 就能调用不需要额外装 SDK。import requests import json OLLAMA_URL http://127.0.0.1:11434/api/generate def model_classify(filename: str, ext: str, sniff: str, filepath: str) - dict: prompt f你是一个文档分类助手。 现有文件信息如下 - 文件名: {filename} - 扩展名: {ext} - 真实类型: {sniff} - 所在路径: {filepath} 请判断该文件最可能属于以下哪个分类 [财务/票据, 合同/协议, 技术/代码, 人事/简历, 设计/图片, 素材/模板] 只能输出 JSON格式 {{category: 分类名, reason: 一句话理由, confidence: 0到1的小数}} 不要输出任何其他内容。 payload { model: qwen2.5:7b-instruct-q4_K_M, prompt: prompt, stream: False, options: {temperature: 0.1}, } resp requests.post(OLLAMA_URL, jsonpayload, timeout120) raw resp.json()[response].strip() # 直接尝试解析 JSON失败时尝试截取第一个 { 到最后一个 } try: return json.loads(raw) except json.JSONDecodeError: start raw.find({) end raw.rfind(}) 1 if start ! -1 and end start: try: return json.loads(raw[start:end]) except json.JSONDecodeError: pass return {category: unknown, reason: parse_failed, confidence: 0.0}注意前两行{category...}在 f-string 里写法需要用两对大括号转义不然会被 Python 当作插值表达式直接报错。这个细节坑了我二十分钟。3.4 温度参数与被逼着降低的输出漂移我在代码里设了temperature: 0.1这是一个非常重要的决策。Temperature 是模型输出随机性的控制旋钮值越高输出越有创意值越低输出越保守固定。在做分类任务时我们需要的是可复现性而不是创意。temperature 设为 0.1 甚至 0能显著减少同一个文件重复处理时给出不同答案的概率。实测中我发现temperature 从默认的 0.8 降到 0.1 后模型的无效输出比如输出一段废话而不是 JSON从 18% 降到了 3% 左右。代价是输出偶尔会偷懒比如所有文件都倾向于归到第一类。这需要靠第 4 节的置信度机制来兜底。4. 两级之间的交接与冲突仲裁当规则和模型结论不一致两级流水线真正难的不是各自的工作而是它们之间的交接协议。第一个版本我做得非常简单L0 失败就调模型模型输出啥就是啥。结果很快出了大问题。4.1 一次 L0 与 L1 冲突引发的教训我印象最深的案例是一个文件叫2024年度总结-final.pdfL0 层判定它属于素材/模板因为规则里有一条final 开头的文件归入素材——现在听上去很蠢但当时我确实写了这种规则。模型却判断它属于财务/票据理由是它的内容里出现了大量预算、支出、结余关键词。规则和模型打架了。第一版代码会直接采纳模型的结论因为规则层已经被放弃了。但实际这个文件是从财务目录里挪过来的L0 的路径规则本来能命中是我的优先级顺序写错了——路径规则的优先级设在了命名规则之后结果final规则先抢跑了。那次事故让我明白了一个道理规则层的严格不只是体现在判断逻辑上还体现在优先级和仲裁策略上。从那以后我重构了冲突仲裁逻辑核心原则有三条规则之间的优先级是白纸黑字写死的路径规则 文件头嗅探规则 文件名正则规则 通用规则。文件在哪个目录里比文件名长什么样更重要。规则一旦命中模型无权否决只有当 L0 未命中时模型才有发言权。如果模型与规则冲突记录为CONFLICT日志但结果以规则为准。模型自身也分置信度档位confidence 0.75 直接采纳0.5~0.75 进入待确认队列 0.5 进入人工复核。绝不无条件信任模型的任何单次输出。4.2 三个明确的流水线出口我把每个文件的处理终点Terminal严格分成三种出口触达条件后续动作AUTO_APPROVED自动归档L0 命中或模型 confidence 0.75移动文件到目标目录写日志PENDING_REVIEW待人工确认模型 confidence 在 0.5~0.75或规则冲突不移动文件生成待确认清单MANUAL_REQUIRED必须人工处理模型 confidence 0.5或解析连续失败 3 次放入_unsorted目录人工处理这套出口设计最大的价值是把错误成本控制住了。自动归档错误的文件想撤销很麻烦但让文件留在原地、只生成一条待确认记录几乎不带来任何风险。宁可让 10% 的文件进入人工确认队列也不为了追求自动化率而吞掉 5% 的错误分类。4.3 日志驱动的复盘机制流水线的每个判断都要留痕。我用了一个简单的 JSONL 文件作为审计日志每处理一个文件就追加一行{file: 2024年度总结-final.pdf, rule_hit: 素材/模板, rule_priority: 3, model_output: {category: 财务/票据, confidence: 0.82}, arbitration: RULE_WINS, final: 素材/模板, queue: MANUAL_REQUIRED}这些日志的价值在后续迭代规则时会被放大。你不需要猜测这套规则实际命中率是多少——直接翻日志统计就行。我是每周拉一次日志把PENDING_REVIEW和MANUAL_REQUIRED的文件重新看一遍把人工纠正的结论回填成新的规则这样流水线会越跑越准。本质上这就是一个不断把模型兜底的经验固化成 L0 规则的循环——模型兜底的结果最终会变成规则的一部分。5. 实测数据与成本对照200 个混合文件的真实处理结果理论说得再好不如拿数据说话。我把这套两级流水线放在一个真实的整理任务里跑了一次记录如下。5.1 测试环境与文件构成机器CPU i5-13490F GPU RTX 4060 Ti 16G 32G 内存模型qwen2.5:7b-instruct-q4_K_M运行于 Ollama数据200 个混合文件包括 PDF含扫描件、Word、Excel、Markdown、图片、代码文件文件名覆盖规范命名、中文命名、乱码命名、带版本号命名等各种情况人工事先标注了 200 个文件的正确分类作为评估基准5.2 分级处理结果指标数据L0 硬规则命中数量145 / 200L0 命中准确率142 / 14597.9%进入 L1 模型处理数量55 / 200模型 confidence 0.75 数量37 / 55模型中高置信度准确率35 / 3794.6%进入待确认/人工队列18 个文件人工确认后最终正确率194 / 20097%三个误判分别出在L0 把一个文件名含报表 v2的设计类文档误归财务类模型把一份英文技术手册误归为素材/模板还有一个扫描版 PDF 模型判断正确率很低但置信度却很高只能人工兜底。5.3 成本对比全量模型 vs 两级流水线这是我认为最直观的一组数字方案总耗时GPU 推理总次数耗电估算全量模型处理 200 个文件约 45~55 分钟200 次高两级流水线处理 200 个文件约 7 分 20 秒55 次低两级流水线的总耗时构成如下L0 规则层处理 200 个文件仅用了 1.8 秒几乎可以忽略主要时间花在 55 次模型推理上单次平均约 7 秒因为输入短、输出只有一条 JSON共约 6 分 25 秒其余是解析、日志、文件移动等 IO 时间。结论很直白规则层把模型层的工作量砍掉了 72.5%总时间压缩到原来的六分之一左右。自动化率没有因为引入规则而下降因为 L0 命中的准确率还高于模型97.9% 对 94.6%。5.4 失败案例分析规则误判和模型幻觉各占一半三起误判对后续迭代很关键一起是 L0 的报表正则(报表|报告|汇总)命中了一个设计文档的命名但该文档实际是 UI 设计稿。修正方案很典型在正则规则里增加否定排除项当文件名同时含设计、UI、稿、项目等词时降低这条规则的优先级。规则系统也需要支持否定条件的优先级提升。另一起是英文技术手册分词问题。qwen2.5:7b 在中文文件名的分类上表现不错但英文文件名信息量不足时容易乱猜。我给这类文件加了预处理先抽文件名里的关键词做词频统计把出现频率最高的词作为附加输入喂给模型。这个改动让英文文件名的分类准确率从 82% 提到了 92%。还有一起是扫描版 PDF真实类型是 PDF但文件名和路径都不含有效信息模型只能瞎猜。这个属于硬伤类正确的处理不是改模型而是在 L0 层就做 OCR 预检——如果 PDF 是扫描版没有文本层直接转入人工队列而不是浪费一次模型推理。6. 踩坑复盘与可扩展方向最后聊几个我在整个开发过程中踩得比较深的坑以及如果你想把这套两段式流水线做得更通用可以往哪些方向走。6.1 坑一规则过于积极导致误判比不判更糟这是我反复强调的一点。任务拆分时L0 的目标是尽量精确命中而不是尽量多命中。把模糊判断硬套上规则等于用一个低级分类器抢了高级分类器的活结果两头不讨好。我的经验是每条规则上线前都要先跑一遍历史数据算它的精确率精确率低于 95% 的规则一律拿掉宁可让文件进入模型层多花十几秒也不能让它被规则一秒判错。6.2 坑二模型输出 JSON 的不稳定性靠重试 白名单校验解决模型偶尔不听话输出了一堆文字而不是 JSON。我一开始的做法是重新调用一次模型后来发现这样低效又费电。更好的做法是先用正则把{...}部分截出来再校验 category 是否在分类白名单内。如果两次解析都失败再把原始返回记录到日志里这条文件直接进人工队列不让模型无限重试。无限重试在本地推理场景下是最容易忽略的时间黑洞——每次 7 秒重试 5 次就是半分钟过去了并且大概率还是失败。6.3 坑三文件移动失败没有回滚导致目录结构混乱流水线把文件移动到目标目录时如果目标目录不存在、权限不足、或者磁盘满了会产生源文件已删除但目标目录也没有文件的极端情况。我后来把所有文件移动改成了先复制、校验、再删除源文件三步走并且每次移动前都检查目标目录存在性不存在就先创建。这个改动看起来笨但在批处理几百个文件的场景里非常值得。6.4 更通用的方向三级流水线与知识库增强如果你的任务比文档分类复杂这套两级结构可以升级成三级L0 仍然是确定性的硬规则负责结构性判断。L1 可以增加一层基于已有知识库的检索匹配比如把历史所有已正确处理过的文件特征向量化存到向量数据库里新文件来了先做相似度检索命中就直接复用历史结论。L2 才轮到本地大模型处理真正无先例的模糊任务。这样做的收益是因为历史结论都经过了人工确认相似度检索的准确率通常比模型推理更高同时成本只有一次向量计算比模型推理快了一个数量级。你可以理解为把人工劳动变成规则再把模型判断变成可积累的经验库。如果你现在正准备做一个本地 AI 相关的自动化任务我建议不要一开始就搭大系统。先用一个小脚本把文件清单拉出来拿 30 个文件手动标注一遍再尝试写 5 到 10 条 L0 规则运行一次看命中率。规则命中率如果能过 60%两级流水线的整体收益就会非常明显如果只有 20%那说明你的任务本身模糊度太高应该考虑先做一层 OCR、正文提取之类的预处理把信息量补足再谈分流。这套方案不挑具体的本地模型框架——我用 Ollama 只是因为部署最省事你换成 llama.cpp、LocalAI 或者别的推理服务接口逻辑是一样的核心还是那个原则能用规则确认的事情一分钱模型算力都不花必须用模型的判断也要把它关在一个白名单的笼子里。 上个月我接了一个本地文档整理的活儿两百多个文件散落在三个子目录里PDF、Word、Markdown、Excel 混在一起文件名一半是新建文档(23).docx这种毫无信息量的玩意儿。一开始我的方案很天真——直接把目录路径、文件清单丢给本地大模型让模型输出每个文件应该放到哪个分类目录。结果等了快二十分钟模型洋洋洒洒写了一堆建议其中有五个文件名根本不存在还有两个分类逻辑前后矛盾。那是我第一次意识到把任务全部交给本地 AI 模型处理本质上是在用大炮打蚊子而且这尊大炮还经常脱靶。后来我把方案改成了两级结构先用 L0 硬规则层把所有能靠规则确定下来的事情全部处理掉只有规则判断不了的文件才会进入 L1 模型层由本地大模型做兜底决策。这就是标题里说的L0 硬规则前置 L1 模型兜底两级流水线。这套结构跑下来两百多个文件总耗时从 40 分钟压到了 6 分钟出头准确率反而从 89% 提到了 97%。这篇文章就把这套流水线的设计思路、落地代码和踩过的坑完整记录下来——如果你也在做本地 AI 部署相关的自动分类、自动整理、批处理任务这套规则优先、模型兜底的思路应该能帮你省下大量无用算力和时间。1. 为什么任务要先经过硬规则而不是全部丢给模型先说结论模型适合做模糊判断不适合做确定查找。这是两种思维范式的差异不是模型能力高低的问题。1.1 大模型不是全自动万能分类器很多第一次接触本地 AI 的朋友会对大模型产生一种什么都能干的错觉。给它一个文件它可以按内容总结出主题给它一堆散乱的文件名它能编出一套分类方案。这个能力确实存在但它有几个致命副作用不保证确定性同一个文件你让它判断两次它可能给出不同的分类结果。做文档归档这种事要求的是这个文件今天归档到 A 类明天重新跑一遍也必须归档到 A 类模型天然做不到这一点。存在幻觉模型可能会输出一个不存在的目标路径或者把Q3_财报_final_v3.pdf里的final理解为最终版而忽略了v3的存在。速度慢得离谱在 RTX 4060 Ti 16G 上跑一个 7B 量化模型处理一个文件的推理时间大约是 15 到 25 秒。200 个文件全量丢给模型即使不考虑失败重试也要一个小时量级。上下文窗口限制如果你把全部文件清单一次性塞进提示词输出长度一旦超过限制模型会直接在中间截断后半段文件全部失联。所以问题的关键不是模型好不好用而是**什么事根本不该让模型来做**。1.2 硬规则的两个不可替代的优势L0 层的硬规则简单说就是一系列确定性的判断逻辑正则表达式、文件名前缀匹配、扩展名白名单、目录结构校验、哈希去重等等。它有两个模型无法取代的优势第一100% 确定性。规则是什么样的结果就是什么样的。运行一百次结果完全一致这意味着你可以把它放在流水线的最前端做幂等处理日志和审计也完全可预期。比如规则写着文件名含 发票 的文件归入 [财务/票据]它就是永远这么判不会抽风。第二近零成本。一次模式匹配耗时是毫秒级的消耗的只有 CPU连 GPU 都不需要亮。相比之下模型推理一次至少几十亿参数在前向传播耗电、占用显存、排队成本完全不在一个量级。1.3 两级流水线的整体结构我把这套流水线设计成三个角色的协作而不是简单的规则失败后再调模型第 1 步预检 读取文件元信息扩展名、大小、路径、创建时间 读取文件名、文件头字节用于识别真实类型 第 2 步L0 硬规则判定 按优先级依次检查规则清单 - 命中输出分类结果任务结束生成日志 - 未命中进入待定池转交 L1 第 3 步L1 模型兜底判定 按批次送入本地大模型 模型输出结构化 JSON含分类、原因、置信度 解析并校验输出超过阈值则采纳否则进人工复核队列这里有个关键设计L0 不是规则失败才让模型上而是规则的拒绝权高于模型的决定权。也就是说如果 L1 模型输出的结论与 L0 已经判断好的结果冲突流水线默认以 L0 为准同时把冲突记录到日志里供人工复查。这个仲裁逻辑我在第 4 节会详细展开。2. L0 规则层的设计优先保证确定的判断绝不交给模型很多人写规则层会犯一个错误试图用规则解决所有问题结果规则越写越复杂最后比调模型还难维护。我的经验是L0 只处理看一眼就知道答案的情况拿不准的就干脆放行。2.1 先列任务类型白名单再写规则一切开始之前先把你要处理的文件可能归属的类别列出来。比如我在文档整理这个场景里列的分类分类判断依据示例财务/票据文件名含发票、报销、流水、对账单扩展名为 .pdf 且文件头为 PDF合同/协议文件名含合同、协议、契约含甲方、乙方关键词技术/代码扩展名 .py .js .go .md路径含 /src/ /code/人事/简历文件名含简历、个人简介文件头为 .docx 且内容首行含教育经历设计/图片扩展名 .png .jpg .sketch .fig文件头为图片魔数素材/模板文件名含模板、template扩展名 .pptx .docx 且位于 Templates 目录白名单的意义在于它同时定义了输入空间和输出空间。模型兜底时不会让它自由发挥一个新分类出来而是在这六个分类里做选择。这能显著抑制模型的跑偏倾向。2.2 常用硬规则模板和 Python 实现我整理了几类在文档整理、本地文件治理场景里最高频的硬规则每一类都配有可以直接抄走的代码逻辑规则 A扩展名与文件头双重校验只靠扩展名判断文件类型很容易被伪装文件骗过去比如一个 .txt 文件实际内容可能是 HTML。所以我会做双重校验文件头魔数 扩展名一致性。import struct from pathlib import Path MAGIC_MAP { pdf: [b%PDF], png: [b\x89PNG\r\n\x1a\n], jpg: [b\xff\xd8\xff], docx: [bPK\x03\x04], # 同时也覆盖 xlsx/pptx gif: [bGIF8], } def sniff_type(path: Path) - str: 返回: pdf/png/jpg/docx/gif/unknown with open(path, rb) as f: head f.read(8) for ftype, magic_list in MAGIC_MAP.items(): for magic in magic_list: if head.startswith(magic): return ftype return unknown规则 B命名模式正则这是最实用的一组规则。用正则从文件名里抽日期、编号、版本号这些信息在模型看来是需要理解的语义但在规则里只是一次匹配。import re pattern_rules [ # 文件名含发票/报销或形如 INV_2024xxxx {category: 财务/票据, regex: r(发票|报销|INV_|对账单|流水)}, # 文件名含合同或编号形如 HT-2024-xxx {category: 合同/协议, regex: r(合同|协议|HT-|agreement)}, # 技术类代码扩展名兜底 {category: 技术/代码, regex: r\.(py|js|go|ts|java)$}, # 简历类 {category: 人事/简历, regex: r(简历|resume|个人简介|CV_)}, ]规则 C路径定位这一类规则不依赖文件名而是依赖文件当前所在的目录结构。适合处理已经有人按目录粗分过一遍但没整理干净的情况。PATH_KEYWORDS { 财务/票据: [finance, 财务, 报销, invoices], 技术/代码: [src, code, backend, 前端, 后端], } def rule_by_path(path: Path) - str | None: for category, keywords in PATH_KEYWORDS.items(): for kw in keywords: if kw in str(path).lower(): return category return None规则 D哈希去重与空文件拦截这个往往被人忽略。整理文件时如果混入重复文件后面的模型层会白算好几遍。用xxhash或者hashlib.md5做一次去重重复文件直接按已归档处理不再进入后续任何环节。2.3 L0 的主动放弃原则这是整个流水线里最反直觉但也最重要的一条L0 层必须允许自己判断不了。我在第一版实现里为了让规则更全面加了一堆模糊规则比如文件名含 6 位数字则归为编号文件。结果误判率飙升——很多设计稿的文件名里也带数字版本号却被归到财务类里去了。后来我悟了规则的使命不是覆盖所有情况而是覆盖确定无疑的情况。所以在规则设计时我给每条规则加了一个字段confidence只有confidence 0.98的规则才允许直接输出结果像看起来像、大概属于这种模糊判断我一律把它扔给 L1 模型。硬规则的放弃反而是整个流水线准确率的保障。3. L1 模型兜底接入本地 7B 模型如何在不联网环境下给出稳定结论L0 放行的文件会进入 L1 模型层。这一层的工作是把模糊判断集中起来交给模型处理但绝不是把文件名发过去让它自由发挥这么简单。你需要做三件事选一个合适的模型、设计一个约束性强的提示词模板、做一套输出解析和重试机制。3.1 模型选型深入理解显存与量化之间的博弈本地部署 AI 模型时显存是硬约束。我机器上是 RTX 4060 Ti 16G实测下来的选型逻辑是这样的模型量化等级显存占用单次推理耗时处理100字输入判断质量qwen2.5:7b-instruct-q4_K_MQ4_K_M约 5.2G约 8-12 秒足够胜任文件名分类llama3.1:8b-instruct-q4_K_MQ4_K_M约 6.1G约 12-18 秒略强但对中文文件名不够敏感qwen2.5:3b-instruct-q4_K_MQ4_K_M约 2.4G约 3-5 秒偶尔无视输出格式慎用我的结论很直接在 16G 显存档位qwen2.5:7b 的 Q4_K_M 量化版是最均衡的选择。它体积小、速度快因为输入文本极短本质是在做短文本分类、对中文理解好而且极少出现完全无视指令的情况。如果你显存只有 8G那 7B 的 Q4 量化版勉强能跑但会让出不少上下文空间此时实测 qwen2.5:7b 可能挤占显存建议退到 qwen2.5:3b 或 gemma2:2b但需要接受偶尔输出不稳定的代价。这里插一句常被问到的本地部署 ai 大模型的显存要求到底怎么算我的经验公式是模型文件大小 约 1.5 倍上下文缓存 最低显存占用。比如 4.7G 的 Q4 量化模型配合 8K 上下文大约需要 6~8G 显存才舒服。如果显存被占满Ollama 会退化为 CPU 推理速度慢到无法接受。3.2 提示词模板把输出空间压缩成选择题模型分类精度低80% 的原因在于提示词给的自由度太高。我的策略是把开放式问题改成封闭式选择题只允许模型从六个既定分类里选一个并且要输出 JSON。你是一个文档分类助手。 现有文件信息如下 - 文件名: {filename} - 扩展名: {ext} - 真实类型: {sniff} - 所在路径: {path} 请判断该文件最可能属于以下哪个分类 [财务/票据, 合同/协议, 技术/代码, 人事/简历, 设计/图片, 素材/模板] 只能输出 JSON格式 {category: 分类名, reason: 一句话理由, confidence: 0到1的小数} 不要输出任何其他内容。这个模板的核心在于只能输出 JSON和不要输出任何其他内容。为了让模型真正遵守我还在代码里加了输出后校验如果返回不是合法的 JSON或者 category 不在白名单内就当作解析失败处理。3.3 调用 Ollama 并做输出解析我用的是 Ollama 的 HTTP API直接通过 requests 就能调用不需要额外装 SDK。import requests import json OLLAMA_URL http://127.0.0.1:11434/api/generate def model_classify(filename: str, ext: str, sniff: str, filepath: str) - dict: prompt f你是一个文档分类助手。 现有文件信息如下 - 文件名: {filename} - 扩展名: {ext} - 真实类型: {sniff} - 所在路径: {filepath} 请判断该文件最可能属于以下哪个分类 [财务/票据, 合同/协议, 技术/代码, 人事/简历, 设计/图片, 素材/模板] 只能输出 JSON格式 {{category: 分类名, reason: 一句话理由, confidence: 0到1的小数}} 不要输出任何其他内容。 payload { model: qwen2.5:7b-instruct-q4_K_M, prompt: prompt, stream: False, options: {temperature: 0.1}, } resp requests.post(OLLAMA_URL, jsonpayload, timeout120) raw resp.json()[response].strip() # 直接尝试解析 JSON失败时尝试截取第一个 { 到最后一个 } try: return json.loads(raw) except json.JSONDecodeError: start raw.find({) end raw.rfind(}) 1 if start ! -1 and end start: try: return json.loads(raw[start:end]) except json.JSONDecodeError: pass return {category: unknown, reason: parse_failed, confidence: 0.0}注意前两行{category...}在 f-string 里写法需要用两对大括号转义不然会被 Python 当作插值表达式直接报错。这个细节坑了我二十分钟。3.4 温度参数与被逼着降低的输出漂移我在代码里设了temperature: 0.1这是一个非常重要的决策。Temperature 是模型输出随机性的控制旋钮值越高输出越有创意值越低输出越保守固定。在做分类任务时我们需要的是可复现性而不是创意。temperature 设为 0.1 甚至 0能显著减少同一个文件重复处理时给出不同答案的概率。实测中我发现temperature 从默认的 0.8 降到 0.1 后模型的无效输出比如输出一段废话而不是 JSON从 18% 降到了 3% 左右。代价是输出偶尔会偷懒比如所有文件都倾向于归到第一类。这需要靠第 4 节的置信度机制来兜底。4. 两级之间的交接与冲突仲裁当规则和模型结论不一致两级流水线真正难的不是各自的工作而是它们之间的交接协议。第一个版本我做得非常简单L0 失败就调模型模型输出啥就是啥。结果很快出了大问题。4.1 一次 L0 与 L1 冲突引发的教训我印象最深的案例是一个文件叫2024年度总结-final.pdfL0 层判定它属于素材/模板因为规则里有一条final 开头的文件归入素材——现在听上去很蠢但当时我确实写了这种规则。模型却判断它属于财务/票据理由是它的内容里出现了大量预算、支出、结余关键词。规则和模型打架了。第一版代码会直接采纳模型的结论因为规则层已经被放弃了。但实际这个文件是从财务目录里挪过来的L0 的路径规则本来能命中是我的优先级顺序写错了——路径规则的优先级设在了命名规则之后结果final规则先抢跑了。那次事故让我明白了一个道理规则层的严格不只是体现在判断逻辑上还体现在优先级和仲裁策略上。从那以后我重构了冲突仲裁逻辑核心原则有三条规则之间的优先级是白纸黑字写死的路径规则 文件头嗅探规则 文件名正则规则 通用规则。文件在哪个目录里比文件名长什么样更重要。规则一旦命中模型无权否决只有当 L0 未命中时模型才有发言权。如果模型与规则冲突记录为CONFLICT日志但结果以规则为准。模型自身也分置信度档位confidence 0.75 直接采纳0.5~0.75 进入待确认队列 0.5 进入人工复核。绝不无条件信任模型的任何单次输出。4.2 三个明确的流水线出口我把每个文件的处理终点Terminal严格分成三种出口触达条件后续动作AUTO_APPROVED自动归档L0 命中或模型 confidence 0.75移动文件到目标目录写日志PENDING_REVIEW待人工确认模型 confidence 在 0.5~0.75或规则冲突不移动文件生成待确认清单MANUAL_REQUIRED必须人工处理模型 confidence 0.5或解析连续失败 3 次放入_unsorted目录人工处理这套出口设计最大的价值是把错误成本控制住了。自动归档错误的文件想撤销很麻烦但让文件留在原地、只生成一条待确认记录几乎不带来任何风险。宁可让 10% 的文件进入人工确认队列也不为了追求自动化率而吞掉 5% 的错误分类。4.3 日志驱动的复盘机制流水线的每个判断都要留痕。我用了一个简单的 JSONL 文件作为审计日志每处理一个文件就追加一行{file: 2024年度总结-final.pdf, rule_hit: 素材/模板, rule_priority: 3, model_output: {category: 财务/票据, confidence: 0.82}, arbitration: RULE_WINS, final: 素材/模板, queue: MANUAL_REQUIRED}这些日志的价值在后续迭代规则时会被放大。你不需要猜测这套规则实际命中率是多少——直接翻日志统计就行。我是每周拉一次日志把PENDING_REVIEW和MANUAL_REQUIRED的文件重新看一遍把人工纠正的结论回填成新的规则这样流水线会越跑越准。本质上这就是一个不断把模型兜底的经验固化成 L0 规则的循环——模型兜底的结果最终会变成规则的一部分。5. 实测数据与成本对照200 个混合文件的真实处理结果理论说得再好不如拿数据说话。我把这套两级流水线放在一个真实的整理任务里跑了一次记录如下。5.1 测试环境与文件构成机器CPU i5-13490F GPU RTX 4060 Ti 16G 32G 内存模型qwen2.5:7b-instruct-q4_K_M运行于 Ollama数据200 个混合文件包括 PDF含扫描件、Word、Excel、Markdown、图片、代码文件文件名覆盖规范命名、中文命名、乱码命名、带版本号命名等各种情况人工事先标注了 200 个文件的正确分类作为评估基准5.2 分级处理结果指标数据L0 硬规则命中数量145 / 200L0 命中准确率142 / 14597.9%进入 L1 模型处理数量55 / 200模型 confidence 0.75 数量37 / 55模型中高置信度准确率35 / 3794.6%进入待确认/人工队列18 个文件人工确认后最终正确率194 / 20097%三个误判分别出在L0 把一个文件名含报表 v2的设计类文档误归财务类模型把一份英文技术手册误归为素材/模板还有一个扫描版 PDF 模型判断正确率很低但置信度却很高只能人工兜底。5.3 成本对比全量模型 vs 两级流水线这是我认为最直观的一组数字方案总耗时GPU 推理总次数耗电估算全量模型处理 200 个文件约 45~55 分钟200 次高两级流水线处理 200 个文件约 7 分 20 秒55 次低两级流水线的总耗时构成如下L0 规则层处理 200 个文件仅用了 1.8 秒几乎可以忽略主要时间花在 55 次模型推理上单次平均约 7 秒因为输入短、输出只有一条 JSON共约 6 分 25 秒其余是解析、日志、文件移动等 IO 时间。结论很直白规则层把模型层的工作量砍掉了 72.5%总时间压缩到原来的六分之一左右。自动化率没有因为引入规则而下降因为 L0 命中的准确率还高于模型97.9% 对 94.6%。5.4 失败案例分析规则误判和模型幻觉各占一半三起误判对后续迭代很关键一起是 L0 的报表正则(报表|报告|汇总)命中了一个设计文档的命名但该文档实际是 UI 设计稿。修正方案很典型在正则规则里增加否定排除项当文件名同时含设计、UI、稿、项目等词时降低这条规则的优先级。规则系统也需要支持否定条件的优先级提升。另一起是英文技术手册分词问题。qwen2.5:7b 在中文文件名的分类上表现不错但英文文件名信息量不足时容易乱猜。我给这类文件加了预处理先抽文件名里的关键词做词频统计把出现频率最高的词作为附加输入喂给模型。这个改动让英文文件名的分类准确率从 82% 提到了 92%。还有一起是扫描版 PDF真实类型是 PDF但文件名和路径都不含有效信息模型只能瞎猜。这个属于硬伤类正确的处理不是改模型而是在 L0 层就做 OCR 预检——如果 PDF 是扫描版没有文本层直接转入人工队列而不是浪费一次模型推理。6. 踩坑复盘与可扩展方向最后聊几个我在整个开发过程中踩得比较深的坑以及如果你想把这套两段式流水线做得更通用可以往哪些方向走。6.1 坑一规则过于积极导致误判比不判更糟这是我反复强调的一点。任务拆分时L0 的目标是尽量精确命中而不是尽量多命中。把模糊判断硬套上规则等于用一个低级分类器抢了高级分类器的活结果两头不讨好。我的经验是每条规则上线前都要先跑一遍历史数据算它的精确率精确率低于 95% 的规则一律拿掉宁可让文件进入模型层多花十几秒也不能让它被规则一秒判错。6.2 坑二模型输出 JSON 的不稳定性靠重试 白名单校验解决模型偶尔不听话输出了一堆文字而不是 JSON。我一开始的做法是重新调用一次模型后来发现这样低效又费电。更好的做法是先用正则把{...}部分截出来再校验 category 是否在分类白名单内。如果两次解析都失败再把原始返回记录到日志里这条文件直接进人工队列不让模型无限重试。无限重试在本地推理场景下是最容易忽略的时间黑洞——每次 7 秒重试 5 次就是半分钟过去了并且大概率还是失败。6.3 坑三文件移动失败没有回滚导致目录结构混乱流水线把文件移动到目标目录时如果目标目录不存在、权限不足、或者磁盘满了会产生源文件已删除但目标目录也没有文件的极端情况。我后来把所有文件移动改成了先复制、校验、再删除源文件三步走并且每次移动前都检查目标目录存在性不存在就先创建。这个改动看起来笨但在批处理几百个文件的场景里非常值得。6.4 更通用的方向三级流水线与知识库增强如果你的任务比文档分类复杂这套两级结构可以升级成三级L0 仍然是确定性的硬规则负责结构性判断。L1 可以增加一层基于已有知识库的检索匹配比如把历史所有已正确处理过的文件特征向量化存到向量数据库里新文件来了先做相似度检索命中就直接复用历史结论。L2 才轮到本地大模型处理真正无先例的模糊任务。这样做的收益是因为历史结论都经过了人工确认相似度检索的准确率通常比模型推理更高同时成本只有一次向量计算比模型推理快了一个数量级。你可以理解为把人工劳动变成规则再把模型判断变成可积累的经验库。如果你现在正准备做一个本地 AI 相关的自动化任务我建议不要一开始就搭大系统。先用一个小脚本把文件清单拉出来拿 30 个文件手动标注一遍再尝试写 5 到 10 条 L0 规则运行一次看命中率。规则命中率如果能过 60%两级流水线的整体收益就会非常明显如果只有 20%那说明你的任务本身模糊度太高应该考虑先做一层 OCR、正文提取之类的预处理把信息量补足再谈分流。这套方案不挑具体的本地模型框架——我用 Ollama 只是因为部署最省事你换成 llama.cpp、LocalAI 或者别的推理服务接口逻辑是一样的核心还是那个原则能用规则确认的事情一分钱模型算力都不花必须用模型的判断也要把它关在一个白名单的笼子里。