Jev 1.14版本更新概览与Box功能介绍

大家好，我是小木头。Jev最近更新至1.14版本，官方列出的变化包括多项小幅改善和多语言能力的提升。在功能层面，Jev现在可以处理图片和更长的上下文。1.14版本新增了一种回答类型叫Box，也称为边界框，这是本次更新中最值得分享的特性。它不只是返回一个固定选项或概率值，还会直接给出目标在图片里的具体位置。这个结果还可以通过技术方式在原图中画出来，因此框的准不准、目标不存在时会返回什么，都能通过可视化结果直接看到。

需要明确的是，图片输入和长上下文支持在Jev 1.13中已经加入，并非本次新增。目前官方仍把这些图片能力标记为了实验性的功能，调用时需要在请求头里明确开启图片功能。并且还不建议直接用于生产环境。此外，图片也有格式和尺寸的限制：目前只接受静态PNG或JPEG，宽和高都要在256到1568像素之间。因此需要声明的是：今天的结果只能说明这几组固定样本发生了什么，还不能代表模型在所有图片上在定位方面的准确率。

"这次版本的更新官方列出的变化包括多项小幅的改善和多语言能力的提升"

Box功能的API响应机制与使用警告

Box类型会返回上下左右四条边，API响应里的字段分别叫top、bottom、left和right。这些数值都在0-1之间，把上下边乘以图片的高度、左右边乘以图片的宽度，就能把这个框重新画回到原图中。结果里还会附带一个置信度，用来表示模型对这次位置回答的把握。

这里有一个关键的行为特征：Box只回答目标在哪里，并不回答目标有没有。官方文档明确说明它不会返回"没有找到"这么一个语义。即使图片里不存在这个目标，它还是会给出4条坐标。因此，官方建议在同一个请求里另外询问目标是否存在。程序不能看到一个格式正确的边界框就直接使用，而是要先看存在概率，再结合位置的置信度和自己的判断标准决定要不要接受Jev画出的这个框。

"即使图片里不存在这个目标它还是会给出4条坐标"

测试环境设置与评估维度定义

我的测试使用了一张1280乘850的自然照片，画面里有笔记本、台灯、多肉植物和窗户。运行之前我固定了6个目标：3个清晰目标，一个小目标，一个含糊的目标，再加一个图片里并不存在的自行车。每个目标都同时询问是否存在和在哪里。模型固定使用Jev 1.14.0，通过TypeSafe官方接口连续运行三次，三次结果全部保留。

为了验证API调用过程，我在现场执行了一次官方请求。在终端里使用的是命令行工具curl，API密钥只通过环境变量传入。图片的编码内容按照API的要求传递。请求正常结束，返回的模型是Jev 1.14.0。对于图片里不存在的自行车，存在概率是0.03，位置的置信度是0.06，但下面仍有完整的上下左右坐标。curl的退出状态是0，这次请求正常结束，返回结构完整。但这并不代表图片中真的存在这个目标。

有了返回数据后，我把每组坐标重新画回到图片，并把目标名称、存在概率、位置置信度和3次运行结果放在一起。这样就能同时从四个方面来评估Jev的表现：模型认为目标是否存在、目标在哪里、这个位置是否稳定，以及它对这个框有多大的把握。

"对于图片里不存在的自行车存在概率是0.03位置的置信度是0.06但下面仍有完整的上下左右坐标"

清晰目标与小目标的定位表现测试

首先看最清晰的目标笔记本。连续三次返回的框几乎重叠，位置置信度都是0.90。把坐标画回原图以后，框覆盖了整个笔记本，没有明显跑到桌面或旁边的物体上。这是这一组里面三次位置最接近的结果。

再看看多肉植物，三次框的位置同样比较接近。置信度比笔记本略低一些，在0.74到0.77之间。它的面积比笔记本小很多但目标边界清楚，模型仍然能够把花盆和植物主体放在一个合理的框里。

台灯的结果开始出现一些差异。框覆盖了灯罩、灯杆和底座，从画面上看是一个完整的台灯。但三次的置信度只有0.52到0.56。把它和笔记本放在一起看可以发现框的位置看起来合理不代表置信度一定会很高。

然后再把目标缩小，窗把手在整张图里只占了非常小的一块，而且颜色接近背景。模型三次都找到了窗户上方的小把手但横向边界会有变化。这里不能只放大最后那个框，还要回到整图来看一眼才知道它面对的是多么小的一个目标。

"把它和笔记本放在一起看可以发现框的位置看起来合理不代表置信度一定会很高"

含糊目标与控制组实验分析

最后是含糊的目标窗户。画面里有窗框、窗扇和多个区域，什么范围才算完整的窗户呢？本来就没有一个唯一的答案。3次调用都选择了右侧主要的窗户区域，这个结果可以说稳定也可以说定位到了合理区。但不能只凭稳定性宣布它完全的正确，因为在问题发送之前实际上就没有定义一个唯一的边界。

为了减少自然照片里其他内容的影响，我还做了一张控制图。里面只有红色的圆形、蓝色的方块和绿色的三角形。这里可以把0-1之间的坐标换算成图片上的像素位置，再一条边一条边画到图片里。三个图形的坐标都落在正确的位置和图形边界基本吻合。

但三个目标的置信度分别是0.89、0.44和0.23。红圆的位置正确分数也高，蓝方块的位置同样正确分数呢只有0.44。绿色三角形的边界没有明显的错误，分数进一步降到0.23。三个目标放在一起以后这个差异就会很直观。至少在这组结果里面，置信度不能直接当做边界框的准确度衡量预测框和目标边界重合程度的常用指标是IoU，但这里返回的置信度并不是IoU。

"至少在这组结果里面置信度不能直接当做边界框的准确度"

不存在目标的异常行为与官方文档一致性验证

接着看不存在的目标。自然照片里并没有自行车，重复三次以后存在概率是0.02、0.03、0.03，位置的置信度是0.06、0.06、0.07。两组数值都很低，但三次仍然全部返回了坐标。

把三个框同时画出来会看到它们落在不同的区域，有的靠近窗户，有的覆盖了画面里的其他细节。没有一个对应真实的自行车。图片里没有自行车但Box仍然按照接口约定返回了位置。控制图里的紫色星星也有同样的情况，图片中没有紫色星星，存在的概率是0.02，位置置信度是0.04。但坐标呢仍然存在而且框落到了已有图形的附近。

即使画面里只有几个简单图形，不存在目标仍然会得到一个边界框。这就和官方文档的描述的行为是一致的：目标不存在时Box仍然返回坐标。存在概率回答目标是否存在，位置置信度表示模型对位置回答的把握。四条坐标只描述位置。

"图片里没有自行车但Box仍然按照接口约定返回了位置"

实际使用建议与容错机制设计

调用程序如果把这三类的结果混在一起，就可能把返回格式正确理解成目标真实存在。这次样本里存在概率和位置置信度都很低，但少量的这样的样本不能够证明以后每一次的错误都会是低分。也不能直接得出一个适用于所有图片的分数界限。

实际使用时，可以先根据存在的概率排除一部分结果。再结合位置置信度、出错代价和人工检查决定是否使用坐标。

"也不能直接得出一个适用于所有图片的分数界限"

结论

回到最开始的问题，Jev 1.14的Box到底怎么样呢？这几组测试没有给出一个统一的答案。对清晰的目标它可以给出稳定而且看起来合理的框。对于小目标、含糊目标和不存在的目标，目标描述位置置信度和不接受结果的条件都需要分别的处理。

如果Box只是帮助人工审核员预先圈出可能的区域，偶尔调整一下错误代价可能不高。如果它负责自动裁切商品图框大一点或者小一点就会影响结果。如果它用于安防触发，就必须先判断目标是否存在不能直接使用返回的坐标。

所以这次的测试留下的是一组使用条件而不是对这个版本好坏的结论。目标要定义清楚，是否存在要单独判断位置置信度要用自己的图片验证。至于Jev能不能放进你的产品呢，取决于框错以后会有什么影响以及你准备了怎样的检查和容错机制。完整请求原始响应和测试图片我都会放在视频的描述中，你也可以用自己的图片跑一跑再决定Jev 1.14的Box对你的场景有没有用。