5条标注样本追平Jev，换成Tanglish就崩了

一条退款请求，用Tanglish（泰米尔语混英语）写成，就像很多人真的会发给银行的那样。余弦相似度把它归进了supported_cards_and_currencies。一个按意图训练、每类35条英文样本的分类器，3次运行错了2次。TypeSafe的Jev——一个从给定选项列表里挑一个的模型——把它归进了request_refund，置信度0.98。

本以为Jev会全面碾压。结果没有。干净的英文上，每类5条标注样本，一个免费分类器就能追平Jev。换成Hinglish、Tanglish和陷阱题，35条英文样本也补不上这个差距，即便换上了多语言嵌入模型。

测试任务是把银行客户消息路由到Banking77的77个意图之一，比如card_arrival、declined_card_payment、request_refund。可以想象两个柜员：一个又快又免费（余弦、投票、分类器），另一个很仔细，Jev，把每个选项都读一遍。问题是，快的那个什么时候够用？

Jev返回的是一个选项加每个选项的概率，不是文本，所以没什么要解析的。每次调用会把全部77条描述发过去，大约2400个输入token。

第一轮：干净英文，5条样本追平

零样本时，Jev在1001条测试消息上比余弦高10个点。在嵌入上跑逻辑回归分类器，每类5条样本——总共385条标注消息——就能追平Jev。它那0.9个点的优势落在Jev的误差范围内，算平手。余弦投票需要10条。

一条样本还不如一句话。每类一条标注消息得分63%，一行描述得分73%。把消息和描述一起读的交叉编码器，表现没比余弦好。把同样的5条样本贴进Jev的描述里，在249条消息上达到90.4%：对分类器是微弱领先，代价是3.7倍的token。

干净英文上，快的柜员靠5条样本就追上了。然后换了语言。

第二轮：Hinglish和Tanglish，嵌入崩了

用户不会按你的测试集来打字。Hinglish混印地语和英语，Tanglish混泰米尔语和英语，都用拉丁字母。Claude agent把144条测试消息（覆盖全部77个意图）改写成各自语言的自然聊天口吻，card、top up、PIN这类词保留英文，就像人们平时打字那样。另有agent检查了每一处改写；目前还没有母语者参与。

“这不就是你的纯英文嵌入模型的问题？”有道理：bge-small-en是纯英文的。于是用bge-m3——一个大约大17倍的多语言模型——重跑了余弦投票和分类器。它帮上了忙，提升3到6个点。Jev在Hinglish上依然明显领先；在Tanglish上，144条消息让差距变得接近临界。还没测的是用Hinglish或Tanglish样本训练，那是下一步。

第三轮：陷阱题，更多样本也没用

接下来是105条专门用来骗关键词匹配的新消息。三个agent写，另外三个agent各自盲标；105条全部通过，这可能意味着检查偏宽松。

Jev全对。这些题本来就是为骗过表面匹配而写的，所以100%应该读作“Jev不吃这套”，而不是“Jev完美”。分类器在每意图5条或35条样本时都停在64%，换上多语言bge-m3后到76.5%。余弦踩了23次埋好的坑。

最喜欢的细节：bug在我的描述里

Jev在英文上最差的类别是get_physical_card：13条里0条对。余弦也一样。

作为公平规则，每条描述我只根据标签名来写。我写的是：“客户询问如何拿到实体卡。”然后我读了那些消息：

• “我的PIN码在哪里？”
• “PIN是单独寄送的吗？”
• “我刚拿到新卡，但不确定怎么查PIN。”

在Banking77里，get_physical_card实际意思是“我的PIN在哪？”（它106条训练消息里有105条提到PIN）。Jev把13条全送去了change_pin，其中9条置信度在0.95以上。修好之后还没重跑：余弦、交叉编码器和Jev的数字都带着这个bug，而投票和分类器从不读描述。

你的描述就是你的prompt。写之前，先读每类5条训练消息。

什么时候信答案，什么时候问Jev

置信度可以当过滤器用。英文上，Jev置信度1.0的答案（占一半）有98%是对的，分类器自己的概率同样好用。但在Hinglish和Tanglish上，只有大约十分之一的分类器答案能过0.9：它知道自己输了。于是让快的柜员先答，把个别信件转给仔细的那个：

让分类器回答。置信度低于0.7时，问Jev。

在第二轮144条和第三轮105条消息上实测，每意图35条样本。英文那一列是144条原文，所以Jev在那里是86.1%，不是83.3%。

在英文和混合语码文本上，它保持在更优单一方法的约1个点以内，在Tanglish上还更高。这样在英文上省掉86%的Jev调用，但在Hinglish和Tanglish上只省约四分之一，因为分类器很少确定。陷阱题是例外：分类器对自己错误的Google Pay答案有86%到91%的把握，0.7的门槛就放它过去了。

0.7不是我调出来的，它是固定0.9/0.7/0.5网格的中间值。你的分类器概率会不一样，所以在几百条留出消息上扫0.5到0.9。还有一个更简单的规则（投票和分类器一致时就信），在干净英文上赢，在Hinglish上崩。

那到底该用哪个？

每意图标注消息少于5条：用Jev（必须免费的话，用描述上的余弦）。5条或更多：只处理干净英文的话，用嵌入上的分类器；不是，或者不确定，就先分类器、低于0.7再问Jev（按每意图35条实测）。Jev的答案低于0.95？转人工（单靠Jev：英文十次里三次，Tanglish十次里六次）。

规模参考：分类器在笔记本CPU上7毫秒出答案（用bge-m3是43毫秒），成本为零。Jev每条消息0.76秒，从印度出发的中位往返时间，按TypeSafe每百万输入token 0.042美元的标价，每1000条约0.10美元。

老实说，缺什么

• 分类器只见过英文样本；用混合语码样本训练还没测。
• 探针集很小：105到144条消息，大约±6到±9个点。
• Banking77是公开的，Jev可能在训练中见过。
• 只测了一个为搜索训练的交叉编码器；更大的重排模型可能好得多。
• Jev走的是免费第三方路由：对照过TypeSafe公开答案但不保证完全一致，每天上限约250次调用，10月下旬宕了大约四天。我查看时TypeSafe自家注册已暂停。延迟来自印度的一台笔记本。

拿去跑

需要Python 3.12或更新版本；安装会拉进PyTorch。仓库克隆下来后跑triage，不需要key、不发API调用。每个Jev答案都已提交，报告可以免费重建。要自己调Jev，.env.example指向OpenCode Zen的免费路由，一个第三方，会在你消耗配额前对照TypeSafe公开答案校验。只装官方的typesafe-sdk；有仿冒包。

如果只带走三件事：

1. 用真实消息写描述，别用标签名。一句写错，整个类别归零。
2. 按用户真实的打字方式测试。英文说5条样本够了，Tanglish不同意。
3. 按置信度路由，阈值在自己的数据上选。让便宜的模型答它有把握的，其余升级给Jev或人。

拿你自己用户的消息跑一遍，告诉我Jev在哪里崩。如果你说印地语或泰米尔语，觉得某处改写读着不对，我是真的想要那个issue。