80单测试0错行：印度小店8GB笔记本离线读WhatsApp订单

印度小店的订单，很多是从WhatsApp上来的。一条消息里能混着印地语、英语和缩写，比如"red label adha kg 2 box"——adha kg是半公斤，box是盒。店主得把每一行重新敲进Tally、Busy或Marg这类记账软件里。敲错一行的代价不小：发错货、记错账、装上车。

ParchiMatch Lite想解决的就是这一步。它把每一行读成一条经过核对的账单行，跑在店主自己那台8GB笔记本上，Wi-Fi关掉也能用。核心规则只有一条：拿不准就问，绝不自己填一行错的。

它怎么拆一条订单

模型只负责一件事：猜这行说的是哪个商品。所有数字由代码来读——数量、单位词（petti是纸箱、ctn是箱、darjan是一打、bori是袋）、价格（5/-、10 rs）、包装规格（1 kg、500ml），还有印地语数字词（teen、paanch）。

大部分行靠模糊文本匹配就能瞬间搞定，根本用不到模型。只有当模糊匹配拿不定主意时，本地模型才会看到这一行加上最接近的8个商品，用严格JSON格式、温度0回答，而且只能从这8个里挑一个。

挑完之后，代码里还有16条安全规则来检查：价格对得上吗？包装规格对吗？这个商品是按这个单位卖的吗？任何一条不过，这行就变成琥珀色，而问题是由代码写的，不是模型写的。

选模型：测了五个，锁定一个

在一台8GB的MacBook上，作者用320条合成练习订单测了五个开放权重模型，让它们扮演"决策者"的角色。最终选了Gemma 4 E2B，原因是它拿不准的时候，给出的建议正确率明显更高，店主点一下确认就行，不用自己打字。

然后是一次性测试：在调参之前，先锁定了80条测试订单，CI会在它们被改动一个字节时报错。每种方法在这80条上只跑一次。结果是在这80条锁定测试订单上，填错了0行；在朋友手打的真实消息上，同样是0行。模型只在80行里的31行被用到，每行约1.5秒。

作者用Sentry追踪了一次评估运行，每条订单行一个trace，包含模糊匹配、模型调用和安全规则三个步骤。最典型的是Red Label那一行：adha kg是半公斤，应该对应500g装，模型却答了250g装，状态还是"ok"，自信且错误。安全规则没有信它——两种包装规格和订单里的词匹配程度一样，于是这行被转给了人工。模型建议，代码决定。

所有模型调用都指向127.0.0.1:11434，也就是笔记本自己，不是云端。320条练习订单累计113次模型调用、640次工具调用、5.8万token，花费0美元。

踩过的坑

第一版设计让模型包办商品、数量和单位，是作者测过的最差方案，最终测试里只和纯模糊匹配打平。这就是现在模型只挑商品的原因。

"1,500 bags"曾经变成1 bag，还标成了绿色。逗号把"aashirvaad atta 10 kg 1,500 bag"拆成了两行——一行错行被自动填了进去，这是这个应用最不能犯的错。现在印度式和西式数字分组（1,500、1,00,000）会被读成一个数，像"1,5"这种不清楚的会触发提问。

"记住"功能曾经会学错规格。"tata tea premium"变琥珀色只是因为订单没说规格，学会这个名字就等于永久自动接受某一个规格。现在只有目录里不认识的名字才能被学习，而且学到的名字只代表商品，绝不代表某个包装规格。

模型还曾因为一个荒唐的理由赢下接近的比分："lays 10 wala 2 ctn"没写口味，模型选的Classic Salted只领先0.074，仅仅因为它的别名短。现在模型的选择必须比订单自身的词至少领先0.08，和模糊匹配需要的差距一样。这是开发期最后一行错行。

作者还试过更大的模型：Gemma 4 E4B需要约6GB，在8GB机器上只有2.5GB能进GPU，最慢的一行花了37秒。在小店笔记本上，瓶颈是内存，不是硬盘。

还有一次差点信了朋友的第一批回复——那四条消息整齐得可疑，每条正好17行，商品顺序和清单完全一致，是ChatGPT写的。作者扔掉后重新要求手打，收到三条真实的、乱糟糟的消息，标出11个订单片段，锁定后只评一次：0行错填，80%不需要打字。有一处严格意义上的漏判："fortune oil 1 ltr ke 1 carton"没有触发提问，虽然它的行和标注完全一致，但按作者自己的严格规则仍要计入。

作者说得很清楚：这是3个人给的11个片段，是信号，不是证据。目前还没有付费用户，也没有真实店主用过。下一步是一家真实的店，和一周真实的订单。