讨论

TypeSafe 的 System One 文档把输入描述为状态，把输出描述为受约束的类型化答案和概率。文档同时明确：这种接口不负责撰写回复、生成代码或解释推理过程。它方便程序消费结果，但符合输出格式与判断符合业务事实，是两件需要分别验证的事。 可争论的点 编辑建议先画出业务流程，再挑模型。例如工单系统可以把“属于哪个团队”交给 Choice，把“是否需要补充证据”变成独立判断；订单是否存在、是否重复执行，仍由数据库和代码检查。若要给

Kev 的原始仓库提供预训练权重、本地服务启动方式，以及兼容 TypeSafe System One 调用形状的示例。它是社区项目，不能因为接口相似就视为官方 Jev 的同一模型。README 也展示了作者的评测方法与限制；本帖没有复现这些结果，不据此宣布哪一个方案更好。 可争论的点 编辑建议先确定约束，再比较模型大小或榜单分数。数据能否发送到外部服务、已有硬件是什么、峰值并发多大、能否承担升级维护，都会影响选择。本地部署需要计算设备

Triton 文档说明，动态批处理会把多个请求合并，通常有助于提高吞吐；它也允许请求等待其他请求加入批次。官方建议在延迟预算内逐步测试批大小和等待时间，而不是只追求最大的批次。该机制面向其支持的推理服务，不能假定任意 Jev 服务都具备同样配置。 讨论切口 对交互式决策来说，网络往返、队列等待、推理和结果处理共同决定用户感受到的时间。编辑建议分别记录空载、稳定并发和突发流量下的端到端分位延迟，以及超时率、成功请求吞吐。平均值好看时，少

treg 的 jev-memory 在回答完成后逐句判断用户提示词，把达到阈值的长期偏好写入项目记忆，并提供查看、删除入口。文档特别说明：模型每次只看到一句话，缺少完整对话；临时要求若写得像规则，可能被误存。该流程还会把提示词送到远程服务，记忆文件存本地并不等于整个判断过程离线。 工程上的难点不是多存几条，而是错误偏好会影响多少后续动作。编辑建议把原始句子、适用项目、写入时间和撤销记录视为记忆的一部分，同时区分用户明确要求保存与模型推

scikit-learn 官方文档把概率预测与采取行动分成两个问题：模型给出分数，业务再根据错误代价选阈值。改变阈值可以改变最终分类，却不必改变模型的原始概率输出；阈值调优还需要独立验证，不能拿训练样本反复找最优点。 讨论切口 如果用决策模型给交易做风险分流，误拦一个正常用户、漏掉一个异常事件、送人工复核，成本并不相同。编辑建议先列出这三类结果的代价和复核容量，再比较“直接通过／人工复核／拦截”的策略，而不是先定一个看起来漂亮的置信度

Mobile Jev 把观察、选择、执行再观察串成循环。执行器校验目标是否过期，遇到结果不确定的设备写操作不会直接重试；文本输入后能读取字段时，会核对完整值。它的深色主题演示还检查实际开关状态，文档明确说明模型的 DONE 不是独立成功证明，另一段叫车演示也只到支付选择页。 这种边界同样适用于浏览器自动化。点击按钮只证明尝试过动作，页面跳转也未必证明业务提交成功。编辑建议把成功条件写成可观察事实，并区分已发送、已接受、已完成与已验证。

ThoughtDAG 为本地会话和画布建立索引，可选 Jev 层识别主题、排序相关片段，回答则交给用户配置的语言模型。它把加入请求的资料和片段显示在上下文面板中，用户能查看来源或排除条目。文档把选择阶段的计时与完整检索、回答耗时分开，关闭决策模型时也有规则回退。 这让记忆系统的评估从“想起来了没有”变成“为什么带进来、是否应该带进来”。更多召回可能提高覆盖，也可能把过期决定或已纠正内容混入新任务。编辑建议分别记录检索候选、最终入选和用

TypeSafe 官方说明，Choice 与 Score 的 confidence 是根据返回的概率分布计算出的统计量，并非另一轮独立验证。两类问题的计算方式也不同：Choice 关注最高概率相对均匀分布的突出程度，Score 还考虑概率落在有序等级上的距离。因此，字段名字相同，不代表它直接等于业务数据上的正确率。 可争论的点 编辑建议把“模型的分布有多集中”和“这类预测实际有多准”分开记录。前者来自一次返回值，后者需要一批带可靠标签

Google 在 2024 年的 LearnLM 技术研究介绍中，把适合学习者水平的解释、有效提示、互动引导和主动参与作为教育能力的重要部分。文章举出的做法包括拆分复杂内容、用引导性问题帮助学习；这是作者的研究介绍，不是本站做过的课堂实验。 讨论切口 给教育产品加一个决策层，可以先研究有限的动作：追问缺失信息、给一级提示、解释概念、展示完整解法。但“多追问”不自动等于“教得好”：反复兜圈也会让学生挫败。编辑建议在授权的学习测试中同时记

Numenta 的 NAB 是面向实时流式异常检测的公开基准，包含真实和人工构造的时间序列，并提供针对实时场景的评分机制。仓库分别展示标准、偏重低误报、偏重低漏报的评分配置，提醒我们：同一个检测器在不同业务目标下，名次可能不同。 讨论切口 把 System1 决策接到设备告警后，单条“异常／正常”准确率可能掩盖真正的问题：报警是否及时、是否连续刷屏、是否压过更紧急的故障。编辑建议把故障当成事件评测，记录第一次有效告警、重复告警和漏掉的

Guo 等人在 2017 年的原始论文中研究了神经网络概率与实际正确率的匹配，并在其实验设置中评估温度缩放等方法。这不是对今天 Jev 的验证。社区工具 jev-eval 的 README 则提供按问题与数据切片查看校准、比较结果和保留独立样本的工作流；这里仅核验其文档，没有运行工具。 可争论的点 编辑建议先定义标签含义，再谈校准。例如“该转人工”可能混合了模型不确定、业务政策禁止自动处理、证据缺失三种情况。若标注人员理解不同，漂亮的

CUAD 由 The Atticus Project 维护，官网说明它包含 510 份商业合同、超过 13,000 条标注以及 41 类条款，标注工作在有经验的律师监督下完成。它支持合同条款识别研究，数据集描述本身并不证明某个系统具备完整法律判断能力。 讨论切口 如果决策模型只输出“高风险”，读者仍不知道它看到了哪一段、漏了哪些例外。一个可讨论的工程方案是：先定位条款并保留原文与位置，再由模型选择检查类别，最后交给具备资质的人判断影响

Jev × WebMCP 从网页暴露的工具描述和参数约束生成问题：工具名和枚举变成选择题，布尔值变成是否判断，自由文本则从用户原话片段中选择。缺失参数可以留给用户补充。扩展区分只读、改状态和高后果操作，模型信心高也不会取消后两类所需的确认。 这种设计减少了自由生成参数的空间，但工具描述仍来自页面，不能因此当成可信指令。编辑提出的权衡是：候选约束能减少格式错误，却无法保证工具描述真实、参数语义正确或权限充分。描述筛查可作补充，执行前的权

Geifman 与 El-Yaniv 的选择性分类论文研究了允许分类器拒绝作答时，预测风险与覆盖率之间的关系。其研究对象与实验并非 Jev。TypeSafe 的置信度路由文档则给出了根据判断结果和阈值，把任务交给自动处理或进一步确认的集成模式。 可争论的点 编辑建议讨论自动化系统时，同时报告“自动处理了多少”和“自动处理的部分错了多少”。只留下最容易的一小部分输入，准确率可能很好看；但剩余工作仍由人承担，不能在成绩单里消失。同样，接口

行知把机械臂控制拆成观察、模型选择、动作执行与独立结果判定。它同时提供预设技能、逐步方向和分层子目标等接口；Jev 接收结构化状态，原始图像由支持视觉的另一类模型处理。文档明确区分规则基线、模型调用和物理验证，没有把程序提供的动作能力算成模型学会的能力。 这提出一个常见工程问题：候选越细，模型自由度越高，但调用次数、延迟和失败机会也可能增加；候选越粗，系统容易运行，却可能主要依靠人工设计的技能。编辑建议讨论时固定感知、动作集合、预算和

Vowpal Wabbit 的情境老虎机教程描述了一个关键限制：系统选择一个动作后，只能看到这个被选动作的反馈，而不是所有候选动作的真实结果。因此，如何在已知较好的选项与探索新选项之间分配机会，是推荐决策的核心问题。 讨论切口 如果用 System1 给商品、内容或客服策略打分，模型的高分并不意味着已经验证了长期效果。编辑建议把“候选打分”和“探索策略”分开设计，保留候选集合、选择概率和实际反馈，便于后续分析；这也不意味着把一个决策

TypeSafe 的 Models 文档明确区分模型别名和版本化标识：别名会在新版本发布时移动，响应中的 model 字段可以记录实际作答的版本。文档建议，对某一版本调过置信度门槛的应用，应使用该版本标识，并在准备好后再切换。 可争论的点 编辑建议把一次决策的可复查记录设计成整体：实际模型版本、问题措辞、候选及其描述、输入处理版本、阈值规则、原始返回值，都可能影响最终动作。只记录“调用成功”或一个标签，通常不足以解释后来出现的差异。输

TypeSafe 把 Noul 定义为“是”的概率。接近 0 表示倾向“否”，接近 1 表示倾向“是”，接近中间才表示难以区分两种结果。它不另外返回 confidence。官方还区分了概率与程度：询问某种属性有多强，通常应该设计等级型问题，而不是把 Noul 当强度分数。 可争论的点 编辑建议先固定问题的正向语义。例如“是否需要人工检查”比反复嵌套否定更容易让开发、标注和运营人员保持一致。然后分别讨论错误放行和错误拦截的代价，而不是看

TypeSafe 的 Composite scoring 文档提出：把复杂判断拆成独立维度，分别评分，再在代码中归一化并组合权重。这个模式让开发者能够看到综合分数的组成。它说明的是一种构建方法，不是多个评分相加就必然提升准确率的实验结论。 可争论的点 编辑建议用一个内容推荐场景来讨论：相关性、可操作性、时效性可以分别定义，再明确如何组合。如果把它们全部塞进“这篇文章值不值得推荐”一个问题，团队可能很难知道排名变化来自哪项标准。 不过，

官方 Choice 文档说明，它从预先给定的选项中返回一个选择，并附上概率分布。选项名称与描述会进入模型判断；文档也提醒，“其他”或“以上皆非”不一定工作得好，可以增加一个 Noul 问题判断候选是否适用，再决定是否读取 Choice 的结果。 可争论的点 编辑建议把候选集合当作产品规则来维护。例如“退款”“配送”“账单”可能同时适用于一封邮件：如果业务要求主责任团队，就要说明优先级；如果需要多个标签，单个 Choice 的问题定义可