Jev接入踩坑复盘：判重可用，审核需换DeepSeek及五个拷问

当所有人都在吹捧 Jev 快 193 倍、便宜 444 倍时，作者把它接进真实审核流程，结果 30 场面试复盘无一自动通过，不到 20 小时便撤下。本文复盘这次踩坑经历，拆解 Jev 作为「判断题专用零件」的边界，并给出接入新模型前的五个关键拷问。

一、先说结论

最近一直在讲课，终于闲下来了。闲下来以后，我把刷屏的 Jev 接进了自己的产品，结果不到二十个小时，又把它从审核流程里撤了下来。

不过没有彻底删掉。审核换成了 DeepSeek，判重继续让 Jev 跑。后来又复测了几天，我对它的判断是：

Jev 不是一个更强的生成式 AI，它是一个只做判断题的专用零件。放对位置能省事，放错位置只会添麻烦。

前些天 TypeSafe 发布了 Jev，首页写着最高比前沿大模型快 193.6 倍、便宜 444.6 倍，还说不会出现幻觉。我刷到的内容，几乎都在说这个模型有多牛逼。

我只关心一件事：这些卖点放进真实流程里，还能剩多少？

我拿 30 场真实的面试复盘去测，让它判断每一场合不合格。

按我当时定的 0.9 自动放行线，30 场里，一场都没自动通过。

分数最低掉到 0.3。我改了问法，也只爬到 0.4 到 0.55。当时我脑子里就一句话：

这他妈到底是个啥玩意儿？

我不信邪，自己造数据，换问法、换语言、换题型接着测，前前后后折腾了好几天。最后审核还是没跑通，判重倒是留了下来。

回头看，锅不全是模型的。我照搬了官方案例里的阈值，还把三个条件塞进了同一道题。更要命的是，什么叫「合格」，我自己都没想清楚。

这几天折腾下来，我整理出五个问题。下次再有新模型刷屏，我会先拿它们挨个问一遍。

二、我亲手测了一遍：过程和结果

我想让它做什么

我手上正好有个现成的场景。

这个产品要把学员的面试复盘汇总成题库。每篇复盘进来，要过两道判断：

• 判重：这道题和题库里已有的，是不是同一道？
• 审核：这场复盘合不合格，能不能直接入库？

两道都是判断题，看着就是 Jev 的主场。我把它写进了产品需求文档，当时的理由是这么写的：

输出是校准过的概率，可以直接按阈值分档（≥ 0.9 自动、0.5–0.9 人工、< 0.5 否），且单次判定比 LLM 快、便宜一到两个数量级。

我想得很简单：Jev 判合格的自动入库，我只看中间那一小撮拿不准的。

现在回头看，这段话里的判断全是从官方材料里搬来的，没有一条来自我自己的数据。0.9 这条自动放行线，也是直接照抄的官方案例。还有一处我当时没分清：Jev 的是非题给的是「是」的概率，选择题和打分题给的是置信度，这是两种不同的分数，我却把它们当成了一回事。

结果：审核几乎全卡住了

判重这边，我拿同义题反复试，它一般能给到 0.93 左右，所以我把它留在流程里接着跑。不过我没专门测过它会漏掉多少重复题、又会误杀多少不同的题，所以这只能算一个正向信号，还算不上准确率。

审核那边，完全是另一回事。

30 场真实面试复盘试跑下来，0 场自动通过，30 场全部转人工。开头那句脏话，就是这时候骂出来的。我接 Jev 本来是为了少看几篇，结果一篇没少。

回头排查，问题不全在模型，有一部分出在我自己的接法上：一道题里，我塞了三个条件。

我写给 Jev 的审核题目是这样的：

这是一场被正确解析的真实面试：公司名是一家真实公司（不是题库、话术这类文档标题），轮次合理，题目是面试官实际会问的问题（不是备考清单、不是文档标题的碎片）。

公司名是真的、轮次合理、题目是面试官问的，三个条件同时满足才算合格。

可学员复盘里的公司名，经常没清洗干净。比如多了个下划线的「红熊AI_ 」，或者公司名、业务、岗位拼成一长串。这种人扫一眼就能改的小毛病，把好几场完全正常的面试拉到了 0.30 到 0.45。

官方文档其实写得很清楚：一道题只问一件事。我就是这么踩进去的，先露馅的是我的接法。

我改了什么

我把题目改成只问一件事：

这些题目是不是面试官真实问的。

公司名脏不脏、轮次对不对，本来就是审核页上人工一眼能修的事，不该决定一场面试能不能入库。

重新测了 10 场，分数集中在 0.40 到 0.55。其中一场有 26 道题，我人工一道道核过，确实都是面试官真问出来的，Jev 给了 0.42。

这 10 场，还是没有一场够到 0.9。

当时 Claude 给了我一个解释，我觉得说得通，但还没验证过，只能先当个猜想：

它对「这是不是真的」这类开放判断天然保守，很少给出 0.9 以上。而 0.9 这个阈值是为「两道题是不是同一道」这种有明确答案的判断定的，那类判断 Jev 确实能给 0.93。

是非题的 0.5 跟抛硬币差不多，Jev 给我的 0.40 到 0.55，全挤在是和否的分界线附近。拿这种分数去自动放行肯定不行，它更像是在提醒我，题目、材料和阈值这三样都还没调通。

我的决策

我回了 Claude 一句：

那还是交给大模型来自己判断吧，怎么样？

当天晚上，代码提交：判重继续用 Jev，审核换成 DeepSeek。 从凌晨想到接 Jev，到晚上把它从审核里撤下来，不到二十个小时。

为什么是 DeepSeek？考虑很简单，它比 Jev 贵一点，但也够便宜。在我这个量级下，这点价差不值得我继续跟 Jev 在审核上死磕。

后来审核定成了三层：先过规则，比如有没有公司名、轮次认没认出来；再看 DeepSeek 打分；两边都达标的，我在后台一键确认。我没做严格统计，只说体感：通过的那批整体质量不错，没通过的大多也能看出明显问题。最难啃的那部分活，这套流程确实替我扛下来了。

下面是那一天两条流程的实际账单。两边干的活、样本和输入都不一样，不能当成模型对比来看。我只想算清一件事：落到这个产品里，到底省了多少钱。

两万五千多次判重，Jev 一共花了大约 3 块钱；按 DeepSeek 的单价粗算，同样的量大约是 6 到 12 块钱。至于官方说的 193.6 倍和 444.6 倍，跟这组数据不是一个测法，没法放在一起比。

省下来的，就是几块钱。

我不信邪，又复测了一遍

撤下来之后，我还是想弄清楚：到底是模型不行，还是我不会用？

于是又做了一次小样本复测。我造了两份材料：一份是真实风格的面试记录，公司名故意写成带下划线的「红熊AI_」；另一份是备考题库，公司名就写「题库」。两种问法各问一遍，再拿 DeepSeek 当参照。材料就这么两份，只能看看之前的现象会不会再出现，算不上严格的对比测试。

先看问法。同一份真实面试风格的材料，一道题塞三个条件时是 0.33，只问一件事就升到了 0.54。项目里遇到的情况，又出现了一次。

更意外的是，在这两份材料上，Jev 的排序其实是对的。不管怎么问，真实面试的分数都比题库高。它没把两份材料搞混，只是两边都够不到我照搬来的 0.9。反倒是 DeepSeek，在塞三个条件的问法下，给一份明明写着「题库」的材料打了 0.72。

如果当初我按题去调阈值，而不是照搬 0.9，结果可能完全不一样。

三、Jev 到底是什么

为了写这一节，我读了官方一百多页文档和 18 个案例，也把创始人两个多小时的播客听完了。

读完之后，我给它的定义还是那句：

Jev 是一台只做判断题的机器。

你给它一段材料，再给它几道题，它直接告诉你每道题选什么，以及对每个选项有多大把握。

它不聊天，不写文章，不写代码。你让它说一句「你好」，它都做不到。

听起来像个很弱的模型。但官方在发布博客里专门写了一句：

Jev is neither small nor an LLM. Jev 既不是小模型，也不是大语言模型。

打个极端点的比方。假如今天有人发布一个模型，速度比普通大模型快 1 万倍，完全没有幻觉，永久免费，但它只能做一件事：两个数的加法。

你会觉得这个模型颠覆吗？不会，你只会觉得发布它的人在耍你。

话糙理不糙。判断这件事，大模型本来也能干。Jev 只是把它单独拎出来，往快、便宜、带概率、能让代码直接用这几个方向做到了头。 你要是需要又快又稳地做一大堆判断，可以考虑它。但它的速度和价格，只在这一小块任务里成立，推不出它比大模型更聪明。

不过判断和加法不一样。加法可以写死成一段代码，判断写不死。「这条消息紧不紧急」，你没法用 if-else 穷举。所以 Jev 还是得读懂自然语言，只是回答被限制在你事先给定的几个选项里。至于它内部到底是什么结构，官方没公开。

写作文的考生，和涂答题卡的考生

想象两个考生，做同一道阅读理解。

第一个考生习惯写作文。读完材料，一个字一个字往下写：「根据材料第二段，客户提到集成失败了三天，这说明问题属于技术类，因此我认为答案是……」写了三百字，答案藏在第三百零一个字里。

你想知道他选了什么，得把作文读完，再从里面把答案抠出来。

第二个考生只涂答题卡。读完材料，直接把 B 涂黑，旁边标一句：B 有八成把握，A 有一成五，C 基本不可能。

生成式大模型更像第一个考生，Jev 更像第二个。当然这个比方只是个大概，现在的大模型也能按要求只交一张格式正确的答题卡。

如果从技术逻辑来说：

大语言模型是自回归的，一个 token 接一个 token 往外生成，每一步都依赖前面写过的内容。开了严格的结构化输出，它也可以只吐一个选项或者一小段 JSON，只有你让它解释理由时，才会越写越长。Jev 的不同在于，它天生只返回你定义好的类型，外加每个选项的概率。

Jev 不生成文字。一份材料加所有题目放进一次请求，它会并行给出每道题的答案和概率分布。

TypeSafe 把这类模型叫 System One Model，名字来自卡尼曼的《思考，快与慢》：系统一是快的、凭直觉的判断，系统二是慢的、一步步推理。

官方很清楚这个名字有风险，自己在博客里写了：

‘System 1 thinking’ has also implied error-prone.

「系统一思维」这个说法，也暗示着容易出错。

他们的回应是，相信 System One 模型能比替代方案更可靠。这句话对不对，我的测试回答不了。我能回答的只是：它放进我的流程以后，实际发生了什么。

只涂答题卡，带来三个后果

最直接的一个：它不可能答出选项以外的东西。

你给它三个选项，它只会在这三个里选。不会冒出第四个，不会输出一段格式错误的 JSON，也不会回你一句「作为一个 AI 模型，我无法……」

这就是 TypeSafe 这个公司名的来历：类型安全。你的代码要一个三选一的值，它就一定给你一个三选一的值。

如果你是让大模型用普通文本自己拼 JSON，这一点确实很珍贵。官方博客列过一组数据：在 OpenRouter 上，主流大模型的结构化输出错误率从 0.58% 到 45.5% 不等。不过也得说句公道话，现在不少模型 API 已经支持严格的 JSON Schema，格式正确早就不是 Jev 独有的本事了。Jev 真正不一样的地方，是它从接口到训练目标，都奔着「在固定选项里做判断」这一件事去设计。

第二个：一次问十道题，和问一道差不多快。

官方原话：

Every question is evaluated in parallel and in isolation against the same state in one go. Adding questions barely changes the response time.

所有问题针对同一份材料，一次性、并行、互相隔离地作答。多加几道题，响应时间几乎不变。

官方做过一个测试：一篇五万多字符的 GDPR 文章，挂 13 道题。一次性发送，比 13 道题分开发便宜 12.2 倍、快 10 倍，答案还不变。

不过互相隔离也有代价：第一道题的答案，第二道题是看不到的。如果第二道题要依赖第一道的答案，就只能拆成两次请求。

第三个：每个答案都自带把握程度。

你用普通聊天接口问大模型，它给你一个答案，不会顺手附上一组「每个选项各有几成把握」的概率，更别说是专门为判断任务训练和校准过的。Jev 的选择题和打分题会返回完整的概率分布，是非题直接返回「是」的概率。

这个概率，是 Jev 最核心的卖点，也是我栽得最狠的地方。

三种题型：选择题、打分题、是非题

Jev 只支持三种题型。

是非题叫 Noul，名字取自伯努利（Bernoulli）的后半截。

创始人 Diogo Almeida 在播客里把这三种题型和编程结构一一对上了：

Choice maps into a switch statement on an enum. Noulli’s mapped to if statements. And scores map to sorting or thresholding.

选择题对应枚举上的 switch，是非题对应 if，打分题对应排序或阈值。

Jev 从一开始就是给代码用的。

看一个官方示例。一条客服消息进来：

「我这三天一直在尝试连接 Stripe 账户，集成一直失败，我在损失销售额。请尽快帮忙。」

一次请求，同时问三道题：该给哪个团队？客户有多生气？紧不紧急？请求写起来很简单：state 放材料，questions 放题目，每道题写清两件事，instructions 写你要判断什么，criteria 写可能的答案有哪些（完整代码在后面「往下挖一层」里）。

返回结果：

“department”: { “choice”: “technical”, “confidence”: 0.78,”probabilities”: { “technical”: 0.85, “billing”: 0.15, “sales”: 0.0 } },”frustration”: { “score”: 1.0, “confidence”: 1.0 },”is_urgent”: { “noul”: 1.0 }

翻译人话：

• 归技术团队，85% 的把握；也可能是账单问题，15%；
• 客户在「有情绪但还算礼貌」这一档；
• 紧急，确定。

整个请求 392 个 token，官方说大多数请求 100 毫秒左右就能返回。

置信度到底是什么

上面的结果里，技术团队的概率是 0.85，置信度却是 0.78。这两个数有什么区别？

概率说的是每个选项各占几成，置信度说的是这组概率有多集中。

三个选项，如果是 0.33、0.33、0.33，模型完全拿不准，置信度是 0。如果是 1、0、0，模型非常确定，置信度是 1。

官方文档的演示里给过一个近似公式：

三个选项时，置信度约等于（3 × 最大概率 − 1）÷ 2。代进去算：（3 × 0.85 − 1）÷ 2 = 0.775，四舍五入就是 0.78。

还有两个数，我都踩了坑。

是非题的 0.5，不是「程度中等」，是「是和否一样可能」。

官方文档专门提醒过：你问它「这个候选人 Python 强吗」，它给 0.5，意思不是「一般强」，而是「我不知道，像抛硬币」。想问程度，得用打分题。我审核里拿到的那堆 0.4 到 0.55，就是这种情况。

另一个是「校准」。所谓校准，意思是模型说有 0.2 概率的事，放进一大堆判断里看，大概真有 20% 会发生。它说的是一大批判断的整体表现，不保证单个答案。

官方原话是：

These rates describe groups of predictions, not a guarantee about any single answer.

这些比率描述的是一批预测，不是对任何一个答案的保证。

官方给开发者的说明文档里，还有一句更直白：

Typed output guarantees the interface, not truth.

类型化的输出保证的是接口，不是真相。

往下挖一层：从代码看，它到底省掉了什么

我又把这点差异放到代码里对比了一下。

同一个任务：一条客服消息进来，判断该交给哪个团队。

如果用普通文本接口，自己解析 JSON，代码大概长这样：

prompt = f”””判断这条客服消息该交给哪个团队，只能从 billing / technical / sales 里选一个， 再给出 0 到 1 的把握程度。只输出 JSON，例如 {{“team”: “technical”, “confidence”: 0.8}}。 消息：{message}”””for attempt in range(3): # 格式错了就重试，最多三次 text = llm.chat(prompt) # 模型逐 token 生成回答try: result = json.loads(text) # 它可能多说了一句「好的，以下是结果」，解析失败if result[“team”] in (“billing”, “technical”, “sales”): break # 它也可能编出一个不存在的团队except ValueError: continue

这种接法里，真正在做判断的只有一行，剩下的都在对付文本格式。开了严格结构化输出以后，这部分能少一大截，所以也不是所有大模型调用都得背这么多防错代码。

还有个更隐蔽的问题：这里的 confidence，只是模型在文本里顺手写出来的一个数字。它写 0.8，不代表它打 0.8 的那些答案真有八成是对的。

用 Jev 做，代码长这样：

resp = requests.post(“https://api.typesafe.ai/v1/systemone”, headers=headers, json={ “state”: message, “model”: “jev-latest”, “questions”: {“team”: { “type”: “choice”, “instructions”: “Which team should handle this”, “criteria”: {“billing”: “付款或订阅问题”, “technical”: “故障或集成问题”, “sales”: “价格或账户咨询”}, }}, }) team = resp.json()[“answers”][“team”] team[“choice”] # 一定是三个之一，不用从自由文本里提取 team[“probabilities”] # 接口直接返回每个选项的概率分布

不用自己从一大段文本里抠选项，也不用为了 JSON 格式手写重试。

Jev 真正卖的就是这些：原生的类型化判断、概率分布，还有一次并行回答多道题。至于能帮你省掉多少防错代码，得看你原来用的是普通文本接口，还是已经开了严格结构化输出。

官方自己承认的边界

中文那一条，官方原话是：

Other languages, including CJK scripts, are handled but not equally well. 包括中日韩文字在内的其他语言，能处理，但没那么好。