Jev 的 state

整理供 Jev 判断的材料:字符串、对象或文本数组。

State 是你要求 System One 模型评估的内容。它可以是支持消息、文本段落或应用的当前快照。你需要将其放在问题旁的 state 字段中传入。每个请求会针对一个或多个问题评估一个 state。所有问题读取同一个 state,并彼此独立运行。该映射中可以混用 Choice、Score 和 Noul。不要把问题写入 state,并移除判断不需要的所有内容。

有效结构

最简单的 state 是纯字符串:“我的银行卡被扣了两次款。”当案例只有一段文本时使用字符串;如果包含具名字段、关联记录或应用 state,例如消息加订单 ID,则使用 JSON 对象;消息或记录序列则使用文本数组。在 Python 中,将对应的 string、dict 或 list 传给 client.system_one(state=...)。

TypeSafe 的 state 页面建议多数请求使用对象,以便为每个部分赋予描述性名称。一段支持对话、一笔被扣款两次的订单和一项退款政策可以放在同一个对象中,而这仍是一个 state。当决策需要比较各部分时,应将相关信息放在一起。不要把第二个问题隐藏在字段名中。

Jev 仅接受文本。State 必须是字符串、JSON 对象或文本值数组,不支持图像、音频和视频。英语是主要训练语言;包括中日韩文字在内的其他语言也可接受,但准确率较低。相关语言说明请参阅模型卡;像素内容应先转换为字段,再发送请求。

Jev state shapes: string, named object, or array of text; no pixels
有效的 Jev state 结构:字符串、具名对象或文本数组;不接受像素内容。

将内容与问题分开

State 用于保存内容和支撑事实,问题则用于定义判断。将退款请求和政策放入 state,再询问客户是否申请退款,以及政策是否支持退款。如果把问题粘贴到 state 内容块中,Jev 仍会回答 instructions 字段,而你会在占用“state 加最长问题”32k 预算的位置重复提示词。

充斥无关细节的大型 state 是 jev-1.13 已记录的故障模式。无关内容会形成干扰,导致准确率下降;臃肿的内容块也更难判断究竟是哪个字段引发了错误答案。请先在代码中过滤,只发送问题所需的字段。无法过滤时,可先用 Noul 评估段落相关性,再执行主要判断,具体可参考 TypeSafe 的 RAG 段落分类教程。

上下文长度有上限。Jev 1.13 允许整个请求使用 64k tokens,同时 state 加上最长问题不得超过 32k。推测式 fan-out 会针对精简的 state 打包大量短问题。若只需要客户的最后一条消息和两行收费记录,这种方式比附上完整工单历史更便宜,也更准确。

将支持记录用作state

文档中的对象包含 ticket.subject、由 from/text 键值对组成的 ticket.messages、order.id、带 amount 和 status 的 order.charges,以及用一句话表示的 refund_policy。这样,重复扣款案例就会转化为针对该对象的一组 Nouls 和 Choices,而非必须重复陈述政策的聊天。金额已由你的代码掌握;Jev 负责判断文本是否要求退款,以及政策条款是否适用。

对于 Doom 这样的游戏循环,state 是世界状态的结构化文本,而非画面帧。TypeSafe 的演示约以每秒查询 10 次的速度输入该文本。对于 Wikiracing,state 是页面及其候选链接。对于智能家居助手,state 是用户话语,加上内存中已有的设备列表。这些演示都不会向 Jev 发送像素。

如果数据库中的字段是数值,而判断任务关注的是语义(如“这种颜色看起来像警告色吗”),请发送有名称的分桶或计算后的数值,并在代码中处理十六进制运算。与英文颜色名称相比,jev-1.13 对 RGB 三元组和十六进制值的理解较差。日期同理:先用Choice提取各部分,再在代码中比较。

预算与语言

64k 的请求窗口涵盖state及所有问题。32k 窗口则涵盖state与单个最长问题。若将 20k 的政策 PDF 全部塞入state,问题映射就几乎没有空间,还会触发无关细节导致的失败。应先检索,再只发送判断所需的两个段落。

目前英文的准确率最高。如果工单使用日语或韩语,请先运行样本,绘制Noul和Choice的置信度分布,并保留人工复核,直到这些直方图与英文数据相近。模型仍会接受这些文本,不会在不提示的情况下拒绝处理中日韩文字。

文本数组用于表示序列,不应拿来偷塞第二套结构。如果需要具名部分,请使用对象;如果只需要一整块内容,请使用字符串。把图片 URL 混进字符串不会让 Jev 获得视觉能力,只会让 Jev 多出一个可能被误读的 URL 词元。应由工作进程获取并描述图片,再发送描述文本。

如果某个字段只用于日志,就不要把它放进state。问题 ID 已经可以充当关联键。State应只包含人工评审组会查看的证据。工单对话很长时,遵守这项原则也有助于将state与最长问题的总量控制在 32k 预算内。

具名字段胜过花哨的编码。order_id、charges[].status、refund_policy 对你和 Jev 都清晰易读。将相同事实拼接成单个字符串虽然可用,但效果更差。文档中的支持工单对象就是模板:ticket、order、policy,然后是引用这些名称的问题。

删除判断时不需要的个人身份信息。Jev 不会使用客户请求进行训练,但你自己的日志仍会记录这些信息。缩短 state 既是解决 jaggedness 问题的方法,也是良好的隐私习惯。

文本数组表示序列,而非一组具名槽位。如果需要名称,请使用对象。

来源