Jev AI 的17个应用场景
大多数 AI 模型都是围绕一个基本思想构建的：
给模型一些输入 → 生成文本 → 让应用程序决定如何处理该文本。
Jev AI 采用了完全不同的方法：
Jev 不会尝试撰写文章、用自然语言回答问题、生成代码或进行对话。相反，它会接收非结构化的状态，并用结构化的决策和概率来回答预定义的文本问题。
这使得 Jev 有趣的不是作为另一个 ChatGPT 替代品，而是作为潜在的 软件系统的决策层.
根据 TypeSafe AI 的说法，Jev 专为快速自动化而设计，据报告，端到端延迟约为 70-500 毫秒，输出类型安全，概率经过校准，输入价格约为每百万到肯 0.042 美元，目前输出免费。
该公司将 Jev 描述为一种 System One 模型，其灵感来自快速、直观决策的理念，并表示它使用一种名为“校准决策强化学习”(RLCD) 的训练方法。
那么，你实际上可以在哪里使用这样的东西呢？ 让我们看看最有趣的 Jev AI 用例。
1、AI 代理路由
Jev 最明显的用例之一是 在 AI 代理之间路由请求. Imagine you have an AI application with multiple specialized agents:
- 研究代理
- 编码代理
- 网络搜索代理
- 数据库代理
- 客户支持代理
- 财务分析代理
传统架构可能会将用户请求发送到 LLM 并询问：
“应该由哪个代理人处理这个请求？”
LLM 生成如下答案：
用户似乎是在寻求财务分析，所以我建议将此请求转交给财务人员。然后你的应用程序必须解释该响应。 使用 Jev，应用程序可以定义可能的选择：
research
coding
web_search
database
finance
support然后模型可以返回结构化决策和概率。 Conceptually:
{
"choice": "finance",
"probabilities": {
"research": 0.02,
"coding": 0.01,
"web_search": 0.04,
"database": 0.03,
"finance": 0.89,
"support": 0.01
},
"confidence": 0.94
}
你的应用程序不需要解析解释。 它只需执行：
if decision == "finance":
run_finance_agent()
if decision == "finance":
run_finance_agent()
这正是 Jev 设计的工作流程： classify → route → execute. TypeSafe 将智能工作流程路由列为 Jev 的主要用例之一。
2、构建更快的 AI 代理
Jev 也可以充当 代理系统内部的决策层. 考虑一个自主研究代理。 它可能需要持续决定：
Should I search the web?
Should I use the database?
Should I ask the user?
Should I call another agent?
Should I s到p?
使用大型生成模型进行每个小决策可能会引入不必要的延迟和成本。 相反，架构可能如下所示：
User Request
|
v
┌───────────┐
│ Jev │
│ Decision │
└─────┬─────┘
|
┌───────────┼───────────┐
v v v
Web Agent DB Agent Research Agent
User Request
|
v
┌───────────┐
│ Jev │
│ Decision │
└─────┬─────┘
|
┌───────────┼───────────┐
v v v
Web Agent DB Agent Research Agent
更大的 LLM 可以处理复杂的推理和生成。 Jev 可以处理较小的、频繁的决策。
这创造了一个 混合 AI 架构 不同的模型执行不同的工作。 这种区别很重要。 Jev 不一定取代生成模型。 在许多系统中，它可以补充一个生成模型。
3、客户支持分类
客户支持是另一个自然的用例。 假设一个支持平台收到数百万条消息。 每条消息都需要被分类：
Refund request
Technical problem
Billing issue
Account problem
Feature request
Complaint
General question
生成式 LLM 可以执行此分类，但它可能返回需要解析和验证的文本。 Jev 可以被赋予一个固定的决策空间。
例如：
Choice:
refund
billing
technical
account
feature_request
complaint
general
结果可以直接驱动你的后端。
if intent == "refund":
route_to_refund_team()
elif intent == "technical":
route_to_engineering_support()
elif intent == "billing":
route_to_billing_team()
重要的架构区别是 应用程序拥有工作流程. Jev 提供语义决策。 模型不会发明一个新类别，例如：
“可能与账单有关，但也与账户访问有些关联”应用程序定义可用的选择。
4、欺诈检测
欺诈检测是另一个有趣的应用。 一笔交易可能包含数十个信号：
Transaction amount
Location
Device
Merchant
Previous transactions
Time
Account his到ry
IP address
User behavior
系统可以将这些信号组合成一个状态，并要求 Jev 给出有界决策。 例如：
Is this transaction suspicious?
YES
NO
或者：
Risk level:
LOW
MEDIUM
HIGH
然后输出可以直接连接到业务规则。
if risk == "HIGH":
hold_transaction()
elif risk == "MEDIUM":
request_additional_verification()
else:
approve_transaction()
这特别有趣，因为 Jev 提供 概率和置信度 而不仅仅是一个单一的分类答案，根据其文档。 这允许开发人员构建基于阈值的系统。
例如：
if fraud_probability > 0.95:
block()
elif fraud_probability > 0.70:
verify()
else:
approve()
策略保留在你的代码中。 AI 只提供判断。
5、内容审核
内容审核是另一个有界决策有意义的领域。 想象一个处理数百万条评论的平台。 每条内容可能需要几个决策：
Is it spam?
Is it abusive?
Is it unsafe?
Does it violate policy?
Should it be reviewed by a human?
Is it spam?
Is it abusive?
Is it unsafe?
Does it violate policy?
Should it be reviewed by a human?
传统的 LLM 可以生成审核解释。 但大多数应用程序实际上不需要解释。 它们需要一个决策。 例如：
spam = false
abuse = true
human_review = true
这更接近 Jev 设计提供的内容。
TypeSafe 特别将 Jev 定位为一个用于 评分、判断、验证和检测生成式 AI 系统中的越狱. 这让我们进入了一个更有趣的用例。
6、其他 LLM 的护栏
Jev 可能可以位于 另一个 AI 模型周围. 考虑这种架构：
User
|
v
Large Language Model
|
v
Jev Safety Check
|
+---- Safe ------> Application
|
+---- Unsafe ----> Block / Review
例如，应用程序可能会问：
Does this response violate the application's safety policy?
答案不需要是一个段落。 它可以简单地是：
SAFE = 0.98
UNSAFE = 0.02
SAFE = 0.98
UNSAFE = 0.02
然后应用程序可以决定做什么。
这创造了一个有趣的架构，生成式模型负责开放式生成, 而 Jev 处理 有界验证.
不是要求一个模型做所有事情，而是你专门化模型。
7、实时交互式应用程序
当 AI 位于交互式应用程序中时，延迟变得极其重要。 想象一个 AI 驱动的游戏。 玩家移动。
系统需要决定：
attack
defend
move_left
move_right
follow
retreat
等待几秒钟的传统 LLM 响应会使交互感觉中断。
Jev 的设计目标是实现更低的延迟决策。TypeSafe 报告称，其端到端响应延迟约为 70-500 毫秒，而该公司的官方演示显示，Jev 可以实时为 Doom 做出决策，速度约为每秒 10 次查询。
这为 AI 系统打开了大门，其中模型被重复查询而不是偶尔查询。 示例包括：
- 游戏 NPC 决策
- 实时推荐系统
- 交互式模拟
- 机器人技术
- 设备控制
- 动态 UI 行为
模型变得不那么像聊天机器人，而更像一个 快速决策引擎.
8、游戏 AI
游戏特别有趣，因为它们包含大量的小决策。 NPC 可能会持续评估：
Where is the player?
How much health do I have?
Is there cover?
Should I attack?
Should I retreat?
Should I search for another weapon?
生成式 LLM 对于其中许多决策来说是多余的。 Jev 可能可以将当前游戏状态转换为结构化决策。
例如：
输入状态：
health = 23
enemy_distance = 14
ammo = 3
cover_available = true
问题：
What should the NPC do?
attack
hide
retreat
reload
输出：
retreat: 0.72
hide: 0.19
reload: 0.06
attack: 0.03
然后游戏引擎做出最后的行动。
官方 Jev 生态系统已经将 游戏和实时系统 列为开发人员正在试验该模型的领域之一。
9、大规模数据分类
当需要处理大量非结构化信息时，Jev 也很有用。 想象一家公司有数百万：
Emails
Documents
Support tickets
Reviews
Reports
Transcripts
Logs
你可能希望将这些非结构化信息转换为结构化特征。
例如：
Cus到mer sentiment
Product category
Urgency
Purchase intent
Complaint type
Churn risk
不是为每个文档生成长响应，决策导向的模型可以产生所需的值。
这在大规模上特别有趣，因为 Jev 的官方定价声称大大低于传统前沿 LLM 定价： $0.042/百万token, 目前输出免费。 TypeSafe 表示，这相当于大约 $42/百万token.
对于大规模分类管道，这种差异可能非常重要。
10、搜索和检索排名
搜索系统不断做出排名决策。 假设用户搜索：
best lap到ps for machine learning
best lap到ps for machine learning
系统可能有 10,000 个候选文档。每个文档需要评估诸如：
relevance
quality
freshness
intent match
technical depth
决策导向的模型可以评估这些属性并返回分数。 然后结果可以馈送到排名系统。 这与要求 LLM 不同：
"Write a summary of this document."
应用程序不需要摘要。
它需要一个 分数. 这正是结构化模型输出变得有用的那种问题。
11、个性化和推荐
推荐系统是另一个自然的匹配。 考虑一个电子商务应用程序。 对于每个用户-产品对，系统可以评估：
Would the user probably like this product?
or:
Is this product relevant to the current session?
该模型可以生成一种产品，该产品成为推荐管道中的一项功能。 最终排名仍然可以使用传统算法计算。
这创建了一个混合架构：
User Data
|
v
Jev
|
v
Semantic Score
|
v
Recommendation Engine
|
v
Final Products
同样，Jev 不需要生成推荐文本。 它提供了 做出排名决策所需的智能.
12、交易和金融系统
金融系统包含大量的决策点。 例如：
Is this market event relevant?
Is this news related 到 the company?
Is the signal bullish or bearish?
Should this alert be escalated?
Is this transaction anomalous?
Jev 的生态系统已经包括了归类为 交易和市场. 但是，这是一个开发人员需要特别小心的领域。 模型预测不应自动成为金融行动。 更安全的架构是：
Market Data
|
v
Jev
|
v
Signal
|
v
Risk Engine
|
v
Policy / Limits
|
v
Execution
AI 为系统提供一个输入，而不是控制整个系统。
13、机器人技术和边缘设备
机器人技术 requires extremely fast decisions. 机器人可能需要持续回答：
move forward?
turn?
s到p?
pick object?
avoid obstacle?
传统 LLM 通常不是为了做出数千个微小的实时决策而设计的。 专门为快速决策设计的模型对于这种类型的架构来说更有趣。
更广泛的 Jev 生态系统已经包括了涉及 机器人和设备. 未来的架构可能如下所示：
Sensors
|
v
State Representation
|
v
Jev
|
v
Action
|
v
Robot
困难的部分不仅仅是让 Jev 变快。
整个系统仍然需要可靠的传感器、控制逻辑、安全约束和故障安全机制。
14、自动驾驶汽车
一个实验方向是自主系统的实时决策。 车辆持续观察：
Traffic lights
Pedestrians
Vehicles
Road position
Speed
Obstacles
Weather
然后系统需要选择诸如：
accelerate
brake
maintain speed
change lane
s到p
决策模型可以作为此循环中的一个组件运行。
重要的区别是，这应该被视为一个 研究架构, 而不是 Jev 已准备好控制安全关键车辆的证据。 社区实验已经探索了这个方向，但这些实验不应与经过验证的自动驾驶系统混淆。
15、AI 安全和 LLM 验证
也许最有趣的 Jev 用例之一是使用 Jev 来 检查其他 AI 模型. 假设你有一个强大的生成模型产生答案。
在向用户展示答案之前，另一个系统可以评估：
Is this answer relevant?
Is it consistent with policy?
Does it contain prohibited content?
Does it contradict known information?
Is the model being manipulated?
Jev 可能可以成为快速验证层。 这创造了一个 双模型架构:
User
|
v
Generative LLM
|
v
Jev Valida到r
|
┌───────┴───────┐
v v
Accept Reject
这是 Jev 和聊天机器人之间最强大的概念差异之一。
聊天机器人试图 产生答案.
Jev 可以用来 判断答案.
16、浏览器和工具选择
AI 代理经常需要在工具之间进行选择。 假设一个代理可以访问：
Google Search
Database
Calcula到r
Python
Email
Browser
CRM
File system
每个传入的状态可能需要不同的工具。 Jev 可以充当工具选择层：
Current state
|
v
Jev
|
+---- Search
|
+---- Python
|
+---- Database
|
+---- Browser
Jev 社区生态系统已经将 代理和浏览器 列为其主要用例领域之一。
当代理做出许多小决策时，这特别有用。
17、替换一些基于规则的系统
还有另一个容易被忽视的重要用例。 Jev 不仅与 LLM 竞争。 它还可能取代传统的 if/else 逻辑.
考虑一个复杂的路由系统：
if country == "US":
if cus到mer_type == "premium":
...
elif ...
随着条件数量的增长，这些规则变得难以维护。 语义决策模型可以处理混乱的非结构化输入，而应用程序保留最终的业务逻辑。
这创造了一个有趣的分化:
AI：
"这种情况意味着什么？"
代码：
"我们应该怎么做？"
这种区别可以使 AI 驱动的软件更容易推理。
18、Jev 不是 ChatGPT 替代品
这可能是关于 Jev 最重要的一点。 你不应该看着 Jev 然后问：
"Jev 能取代 ChatGPT 吗？"
这是错误的比较。 生成模型旨在产生语言。 Jev 旨在做出有界决策。
ChatGPT 风格的模型可能负责：
Write an email
Explain a concept
Generate Python code
Summarize a document
Create a report
Write an article
Jev 更适合理解诸如以下任务：
Classify
Score
Route
Rank
Validate
Judge
Select
Detect
这种差异可以总结为：
LLM
Input
↓
Reasoning
↓
Tokens
↓
Text
↓
Parser
↓
Application
versus:
Jev
State
↓
Typed Questions
↓
Decision + Probability
↓
Application
第二个架构移除了整个文本生成和解析层。
19、Jev 背后的更大理念
关于 Jev 最有趣的事情不仅仅是它更快或更便宜。 更大的理念是 并非所有人工智能问题都需要语言生成。现代 AI 开发越来越多地使用一个通用 LLM 来处理几乎所有事情。
- 需要分类？使用 LLM。
- 需要路由？使用 LLM。
- 需要审核？使用 LLM。
- 需要排名？使用 LLM。
- 需要验证？使用 LLM。
Jev 采取了相反的方法。
不是要求模型生成语言然后从该语言中提取决策，而是从决策本身开始。 这改变了 AI 和软件之间的接口。
官方 Jev 文档将此描述为从 "字符串" 到 类型安全的结构化值, 在模型做出决策之前定义可能的输出空间。
20、未来可能是混合 AI 系统
我认为有趣的问题不是 Jev 是否会取代 LLM。 一个更有趣的问题是应用程序是否会开始使用 多个专业 AI 模型.
想象一个生产 AI 应用程序：
User
|
v
Generative LLM
|
┌───────────┼───────────┐
v v v
Jev Search RAG
|
v
Decision Layer
|
v
Business Logic
- LLM 处理语言。
- RAG 处理检索。
- 搜索处理外部信息。
- Jev 处理快速决策。
- 传统代码处理确定性业务规则。
这更接近于复杂软件系统的正常构建方式：不同的组件执行不同的任务。
21、最后的思考
Jev 代表了 AI 领域的一个不寻常的方向。
它并不是试图成为另一个具有更大上下文窗口的聊天机器人或另一个生成更长答案的模型。 相反，它提出了一个不同的问题：如果人工智能不需要说话怎么办？
对于代理路由、分类、排名、审核、验证、实时系统、游戏 AI、数据处理和其他决策密集型工作负载，生成数千个到 ken 可能是不必要的。 有时应用程序不需要文字。
它需要：
YES
87%
ROUTE_TO_AGENT_3
HIGH_RISK
REVIEW_REQUIRED
这就是 Jev 变得有趣的地方。 AI 应用程序的未来可能不是一个巨大的模型做所有事情。
它可能是一组专业模型，其中 生成模型创建, 决策模型判断, 检索模型搜索, 传统软件执行.
Jev 是该架构可能样子的一个早期示例。
原文链接：Jev AI Use Cases
汇智网翻译整理，转载请标明出处