为什么我们打造 Jev:TypeSafe 联合创始人兼 CEO Diogo Almeida 访谈

在这场 Latent Space 访谈中，TypeSafe 联合创始人 Diogo Almeida 将 Jev 描述为机器原生模型：输出是给代码使用的。他用“系统一”和“大型可编程模型”描述方向，也表示公司并不执着于最终的类别名称。

区别在于优化的任务。对话回答需要让阅读的人觉得有用；软件内部的组件则需要稳定地提供程序能够消费的结果。Almeida 希望智能成为应用深处的依赖，而不是在基本未变的软件旁边加一个聊天框。

他把 Jev 的商业目标概括为每美元智能。低成本和速度之所以重要，是因为它们让更多调用变得可行，但开发者真正购买的是有用的智能。他对领先前沿的判断属于创始人的评估，并非本文独立复现的基准结果。

Almeida 认为，后台依赖突然拒绝处理，不只是一次令人不快的对话回答。下游用户可能根本不知道模型参与其中，而软件需要为这个事件定义应对方式。

因此，他倾向于在应用层实现规则，而不是把限制放在认知组件里。主持人以战争等有害用途追问。Almeida 说自己希望技术用于好事，也愿意支持这些用途，但不想在那个技术层实现这些偏好。

这是关于责任和控制应放在哪里的分歧，并不是安全问题已经解决的证明。带类型的接口不会消除下游应用对权限、后果和失败处理的责任。访谈中的规则主张，不应被悄悄改写成技术保证。

Almeida 强烈批评公开基准，因为一个可见目标会影响数据收集，并奖励那些看起来出色、却未改善目标任务的行为。他主张把模型放进真正要使用它的工作流来评估。

他后来澄清，公司有内部评估。他并不反对衡量，而是担心自我欺骗和优化代理目标的激励。沿着智能与成本前沿比较模型，仍然需要测量，也需要严格判断测试究竟代表什么。

这同时限定了发布演示能够说明什么。吸引人的例子可以揭示可能性，却不能说明常见和异常输入上的失败率。他希望开发者能依赖一个组件，不必反复怀疑它是否会正常工作，但也承认达到这种可靠性仍是漫长过程。

Almeida 说，数据形状取决于任务：指令跟随所需的反馈，与可验证奖励任务中的环境并不相同。他把 RLCD 解释为可编程智能的新任务或北极星，而不是在访谈中公开一套算法。

他认为，简单收集当下用户请求，会过度强调今天常见的用法。其数据团队试图找出能力不平整的地方，再以能够泛化的方式处理。这是他对公司路线的解释；访谈没有公开足够细节，让外部复现训练系统。

他对对话训练和模式丢弃的批评，也属于这套论点。他认为，为有说服力的字符串优化，可能扭曲软件需要的概率信息。这些是嘉宾提出的技术论证，并不证明所有对话模型都因同一个原因失败，也不证明 Jev 已经完美校准。

主持人问，同样输入是否总会得到同样输出。Almeida 区分了确定性与鲁棒性：相同输入得到相同输出是一种性质，语义相近的输入得到相近判断，是另一种性质。

他举出添加无关标识符或随机字串的扰动测试。如果底层问题没变，结果却大幅变化，就值得警惕。这是在检验偶然的表面细节是否改变判断，而不只是看固定种子能否重复一个答案。

他认为确定性可能有用，包括用于测试，但也说它可能与公司的成本目标冲突。主持人预计，开发者无论如何都会要求它。讨论留下的是权衡和开放的产品问题，而不是宣布确定性已经可用，或在所有场景都没必要。

主持人还问，容量压力会不会让提供方在同一个名称背后更换模型。Almeida 表示不会这样改动已部署的模型，同时解释公司预计会迅速推出新版本。

他另外拒绝承诺对每个版本长期支持。他考虑过某个版本的支持安排，也谈到未来想法，但没有承诺无限期保留所有精确模型。服务大量版本会分散算力容量。

这两种表态需要分开。版本不变有助于可复现，但前提是它仍然可用；支持政策决定应用能依赖它多久。这场访谈记录的是创始人当时的承诺与不确定性，不能替代对当前服务合同的检查。

API 讨论集中在 choice、nool 和 score。Almeida 说，采用不同寻常的名称，是为了避免开发者把它们误认成普通编程语言类型。尤其是 score，并不只是要求文本模型打印一个整数。

Choice 类似选择枚举分支，可以接到 switch；nool 被描述为连续的、类似伯努利判断的输出，关联 if 决策；score 可以用于排序或阈值判断。共同思路是把程序能够使用的信息，包括不确定性，显露出来，而不是把决策藏在一段文字里。

本文描述这些概念对应关系，不虚构当前 SDK 的函数签名。主持人与嘉宾谈到的文档还在变化，重要边界在于输出是什么意思，以及程序如何据此作决定。

60:00查看原图

Almeida 强调，状态、指令和判断标准都可以是结构化对象。如果程序已经拥有嵌套数据，再把所有内容压进一大段文本模板，可能丢掉有用边界，也让代码更难检查。

他的比喻是一个 AI 函数：明确哪些可用状态与问题有关，显式传入，再提出定义清楚的问题。把所有指令装进巨大的系统消息，类似一个承载了不相关事项的全局变量。

他也承认，理解更深层的嵌套结构很难，仍需要继续改进。结构化输入让接口更明确，并不证明模型正确理解了每一层。

Almeida 建议提出许多小问题，每个都是能够评估的语义单元。应用再用显式代码组合输出，而不是让一个大模型生成整套规则，再自行检查。

主持人补上必要的反例：在此前的系统里，把一个流程拆成一百次调用，可能更慢、更贵，也更不准确。Almeida 同意重复信息与编排会很麻烦。这种提案依赖组件的性质和经济机制，并不存在“调用越多系统越好”的定律。

潜在的工程收益是可观察性。开发者可以检查问过什么、哪个结果越过阈值、最终执行哪个分支。目录访问或密钥释放这类权限，应由模型周围的程序强制执行。概率判断本身不是访问控制保证。

被问到怎样拆解时，Almeida 建议找最小的有意义问题，并精确指向被判断的对象。他偏好明确结构和清楚措辞，让模型知道究竟在判断什么。

他的例子是包含若干独立条件的拒绝规则。如果遗漏一种情况，团队可以补上相应问题，用真实例子选择阈值，再把案例留下作为回归测试。相比期待大提示词里新增的一段话永远有效，这更容易检查。

模型仍然会有能力不足的时候。他以复杂客户情境中的不确定性说明何时需要交给人。测试可以永久保留在代码中，但模型在该案例及相似案例上的错误率，仍然需要测量。

主持人追问现有控制手段：如果某个局部区域的概率就是错的怎么办？只改阈值或重写问题，未必能解决模型判断错误的问题。

Almeida 明确否认自己声称过完美校准。他承认模型会错很多次，欢迎用户报告，并表示“足够好”取决于具体应用。解释此前的可靠性愿景时，这个承认不可缺少。

微调、模型级联和动态选择，在这里是可能性或愿望，并非发布承诺。上层应用仍需决定什么时候接受结果、花更多成本、交给人，或暂时不把该任务上线。

后面的讨论转向哪些任务适合模型。主持人描述，单跳任务表现强，但随着推理步骤增加，结果开始变差。Almeida 将边界看成经验问题：公司在尝试暴露已有模型中有用的性质，并不知道最终所有限制。

他讨论推理、视觉和更长上下文，却没有承诺具体方法或功能。在某些任务上表现不错的模型，仍可能在其他任务退化。类别名称不能代替对真实问题的测试。

这保留了访谈中的张力：愿景是广泛基础设施，而发布时的能力更窄。创始人希望扩展软件能够做到的事，但未来方向不应被当成开发者现在就能依赖的能力。

Almeida 把机会分为几类：过去不值得付出分析成本的大量数据、实时应用、对其他模型调用的验证，以及内在更智能的软件。他建议为共享状态中的片段加标识，让多个问题分别指向具体项目。

经济上的设想，是让过去不现实的检查或分支变得负担得起，而不是无差别增加调用。他说，希望系统能用更少花费解决问题，包括在适当场景减少昂贵的推理调用。

计算机操作和语音演示让他兴奋，但他也要求找出弱点并修复。发布流量和惊艳演示不能替代持续的工作流表现。他还说，发布前许多人不理解产品、收入很少，这使“需求从一开始就显而易见”的简单叙事站不住脚。

访谈接近结尾时，Almeida 提问：如果代理设计不再主要围绕只追加上下文及其 KV 缓存成本，会是什么样？他设想显式子任务、带标签的状态、相关历史检索，以及读写者之间更好的共享。

子任务也许只需返回所需结果，而不是全部过程；另一个进程也许可以检查相关状态片段，不必重建整段对话。这些想法把模型接口连接到抽象、内存与协调等常见软件问题。

他明确说，这些研究方向没有成功保证。它们不证明分布式锁可以安全交给概率模型，也不证明一种新的多代理架构已经解决。

Almeida 将项目追溯到指令跟随模型之后的一个问题：如果 AI 通过 API 成为通用经济投入，大部分调用究竟来自人，还是代码？他判断软件会成为主要调用者，而很多优化仍围绕面向人的体验进行。

这个创业故事解释了为什么他强调概率、控制流、结构化状态与开发者控制。它不能证明访谈中关于经济增长、就业或模型提供方未来竞争位置的宽泛预测。

检验愿景的实际问题更窄，也更严格：一个明确的工作流能否使用输出、测量失败、守住边界，并在提供方变化时保持可维护？访谈给出的是设计问题与承认的限制，并不是可以跳过这些工作的理由。