TypeSafeのJev 1.14が画像に対応 新しいBox型と、写真15枚で試した結果

1週間前、OpenAIのDecisions APIを試した記事を「文章はJev、画像はDecisions API」で締めました。決め手は、TypeSafe AIのJevが画像を受け取れないことでした。その前提が、8日で変わりました。

TypeSafe AIは米国時間10月14日(日本時間15日朝)、Jev 1.14を発表しました。新しいモデルと一緒に、画像の入力、画像のどこに何があるかを返す新しい質問の型「Box」、より長いコンテキストの3つを開放しています。ただし3つとも、同社が「本番に使えると保証できる水準にはまだない」とする実験機能です。

そこで、Decisions APIのときと同じ写真15枚、同じ8つの質問をJevに投げてみました。1枚あたりの費用は約半分、応答は2倍以上速く、正解を付けて数えた誤りの数はほぼ同じでした。違ったのは、どこで間違えるかです。

3つの新機能はどれも、自己責任で使う実験機能

まず全体像です。

	何ができるか	使える条件
画像	文章を置けた場所に、画像も置ける	リクエストに専用のヘッダーを付ける。1.13と1.14の両方
Box	画像の中の対象を、四角い枠の位置で返す	画像と同じヘッダー。1.14のみ
長いコンテキスト	1回に渡せる量が約4倍になる	別の専用ヘッダー。1.13と1.14の両方
Jev 1.14本体	全体の小さな改良。いちばん伸びるのは多言語の見込み	jev-preview で指定。約1週間後に jev-latest も1.14へ

新しい3つの機能は、使うたびにリクエストへ「Danger Zone(危険地帯)」と名の付いたヘッダーを足さないと動きません。本番の仕組みを作る人には社内で限界まで試したものだけを出し、試作を楽しむ人には、将来も残るがまだムラの残る機能をヘッダーの奥で先に開ける。発表文はそう説明しています。

小さな驚きもありました。創業者のDiogo Almeida氏は、今のJevも最初から画像を読めるモデルだったと明かしています。文章以外では賢さが落ちる傾向があるため、あえて止めていたそうです。今回、それを1.13でも使えるようにしました。

1.14本体は地味な更新です。同社の社内評価では総合60.0(1.13は58.9)と小幅で、同社自身が「全面的には信じないでほしい」と添えています。日本の読者にとって気になるのは、いちばん伸びるのは多言語だと見込んでいる点でしょう。

すでにJevを使っている会社が知っておくべきなのは、別名の切り替えです。jev-latest という名前で呼んでいると、約1週間後に中身が1.14へ変わります。1.13は当面残り、正式に非推奨にする60日前には知らせる予定だと発表文にあります。公式ドキュメントも、確率のしきい値を特定の版で調整したなら、その版の名前に固定せよと書いています。

私たちの問い合わせフォームの営業メールの仕分けも、jev-latest で動いています。しきい値は1.13で測ったものなので、評価用の合成データ73件を1.14でも流してみました。正規の問い合わせに営業やスパムのタグが付く誤りは0件、営業とスパムを何らかのタグで拾えた割合も全件で、1.13と同じです。確率の値は少しずつ動き、正規の問い合わせ1件が「要確認」の帯に入った回もありました。日本語の本文に対して、この73件では目に見える改善も悪化もない、というのが今の答えです。

画像は文章と同じ場所に置け、見本の写真を基準にできる

画像の入れ方は、公式のImagesのページにまとまっています。特徴は、画像を置ける場所が3つあることです。

• 判定する材料(state): 判定したい写真そのもの。複数の写真や、数秒分のカメラのコマを並べることもできる
• 質問文の中: 「photo に写っている人は、この社員証の写真の人と同じか」のように、比べる相手の画像を質問に埋め込む
• 選択肢の基準: 選択肢ごとに見本の画像を付ける。手のジェスチャーを、見本の写真で定義した選択肢から選ばせる例が載っている

3つ目が、いちばん面白い使い方だと思います。「正しく組み立てられている」を見本の写真で、「部品が足りない、位置が違う」を文章で定義して、はい/いいえで答えさせる例もあります。言葉で書きにくい基準を、写真で渡せるわけです。公式の例はほかに、玄関カメラに人がいるか・何を持っているか、迷子の犬の写真と貼り紙の写真が同じ犬か、直近数コマでドアが開いたか、などです。

制約もあります。受け取れるのはPNGとJPEGの静止画だけで、各辺は256〜1,568ピクセル(後で書くとおり、私たちの検証ではこの範囲内でも弾かれた大きさがありました)。写真の向きの情報は使われないので、スマホの写真は画素ごと回してから送る必要があります。料金は文章と同じ入力トークンの単価で、画像専用の料金はありません。ただし1枚が何トークンになるかの目安は「近日公開」で、まだ出ていません。

TypeSafe自身も「どのモデルも、画像では文章より成績が落ちる。質問をできるだけ単純に分けると、かなり改善する」と書いています。最初は小さい画像で聞き、必要なときだけ大きい画像や切り抜きで聞き直す、といった型も示されています。Jevの基本である「判断を小さな質問に分ける」が、画像ではなおさら大事になります。

Boxは判定ではなく「どこにあるか」を返す

Boxは、Jevで初めての、判定ではない型です。「photo の中のコーヒーカップ」のように対象を書くと、それを囲む四角の上下左右の位置を、画像の幅と高さに対する割合(0〜1)で返し、確信度を添えます。割合なので、画像の大きさが変わっても同じ答えが使えます。

使い方にはいくつか癖があります。

• 対象が写っていなくても、必ず枠を返す。 「見つからない」という答えはありません。同じ呼び出しで「写っているか」をはい/いいえで聞き、低ければ枠を捨てる、が公式の勧める組み方です
• 1つの質問に、枠は1つ。 同じものが複数あるときは「シンクにいちばん近いカップ」のように1つに絞れる書き方にする
• 大きな画像の小さな対象は見落としやすい。 先に区画を選ばせてから、その区画で聞く

枠が対象を切っていないかは、切り抜いた画像に上下左右それぞれ「対象はこの辺の外まで続いているか」を聞いて確かめます。同社の試験では、この方法で36枚中30枚の切れを見つけ、「全部が枠に収まっているか」と1問で聞くより多く拾えたそうです。

用途として分かりやすいのは書類です。Xでは、書類の記入欄の位置を取るには、これまで文字の読み取り(OCR)で全単語の位置を記録し、目的の欄の単語を選び、座標をつなぎ直す、という2〜3段の仕組みが要ったが、それが1回で済むという指摘がありました(本人によれば1ページ約0.25秒)。署名欄に署名があるかを、位置を取ってから切り抜いて確かめる、といった組み合わせも考えられます。

長いコンテキストは約4倍に広がるが、勧められてはいない

Jevが1回に受け取れる量には、1リクエスト全体で64k、1つの質問あたり32kトークンという上限があります。専用のヘッダーを付けると、どちらも262kトークンに広がります。単価は変わりません。

ただ、公式は「遅くなり、精度も下がる。必要なリクエストにだけ使え」と書いています。上限は性能の限界ではなく、長いほど信頼性が落ちるので、わざと絞っていたそうです。1.13の弱点の一覧には「判定に関係ない材料が多いと精度が落ちる。先にコードで絞り込み、質問に要る部分だけを渡せ」とあります。

公式の例は、長い契約書を丸ごと渡して「どちらかの当事者が早期に契約を終えられる条項があるか」を聞くものです。会議の書き起こしや、長い対応履歴も同じ形になります。とはいえ、筆者は中小企業の日常の判定で上限に当たる場面は多くないと思います。上限を外す前に、条項や発言を区切って、必要な部分だけを渡せないかを先に考えるほうが、速さと精度の両方で得をするはずです。

写真15枚では、Decisions APIの半額・2倍以上速く、間違え方が逆だった

ここからは私たちの検証です。使ったのは、Decisions APIの記事と同じ15枚です。Googleマップなどへの投稿を想定した美容関連の店舗の画像に、文字やぼかしを加えた確認用の画像を混ぜています。質問も同じ8つで、人の顔がはっきり写っているか、個人が分かる文字があるか、言い切りや効果をうたう文字があるか、ビフォーアフターの写真か、写りの品質、写真の種類、などです。文言は同じ日本語で、画像は長い辺1,024ピクセルに縮めて送りました。

費用は半分、応答は0.2秒

	Jev 1.14	Decisions API(10月7日)
1枚あたりの入力(8問)	約3,000トークン	約2,300トークン
1枚あたりの費用	約0.019円	約0.034円
応答(日本から、画像の送信込み、中央値)	約0.2秒	約0.45秒

費用は1ドル150円で計算しています。Decisions APIは10月7日に測った数字で、通信の状態は同じではありません。トークン数はJevのほうが多いのに、単価が安いので、1枚あたりは約半分です。1,000枚でも20円かかりません。1.13と1.14で、費用と速さはほぼ同じでした。

公式がまだ出していない、画像1枚のトークン数も測りました。画素数にほぼ比例し、1,024×768で約2,100トークン、512×384で約560トークン。上限の1,568ピクセル四方でも約6,500トークンなので、1枚あたり0.05円に届きません。

誤りの数はほぼ同じ、間違える場所が違う

今回は、すべての画像に私たちが正解を付けました。はい/いいえで答える6問について、確率0.5以上を「はい」とみなして数えると、判断の分かれる2件を除いた88件のうち、誤りはDecisions APIが5件(見逃し1件)、Jev 1.14が4件(見逃しなし)、Jev 1.13が5件(見逃しなし)でした。この件数では、どちらが上とは言えません。面白かったのは、間違え方が逆だったことです。

Jevが強かったのは、文字の拾い方と、崩れた画像への落ち着きです。 Decisions APIが見落とした、車の写っていない画像に重ねたナンバープレート風の文字を、Jevは個人が分かる文字として拾いました(確率0.60〜0.72。Decisions APIは0.15)。強くぼかした画像でも、Decisions APIは顔やビフォーアフターを高い確率で「ある」と答えましたが、日本語で聞いたJevはどれも低いままで、品質だけを「使えない」と返しました。

Jevが弱かったのは、文字への反応しすぎです。 雰囲気を伝えるだけのキャッチコピーや、比較を言い切る文字を、効果をうたう表現として拾うことがありました。メニュー名の入ったビフォーアフターを、商品と前後の写真の組み合わせと取った例もあります。Decisions APIは逆で、文字は1件見落とし、残りの誤りはぼかした画像や紛らわしい画像での取り違えでした。文字には鈍く、見た目には引っ張られる。Jevとはちょうど逆の外れ方です。

1.14と1.13の差は、どちらの向きにもありました。キャッチコピーへの過剰な反応が下がった画像もあれば、上がった画像もあります。一方、質問を英訳して聞くと、誤りは日本語より増えました(1.14で5件、1.13で7件)。公式は英語が主言語だと書いていますが、この15枚では日本語のまま聞くほうがよかった、という結果です。

Xでは、ホットドッグの写真かどうかを、あえて紛らわしくした40枚で試した人が、1.13は38枚、1.14は37枚、Decisions APIは35枚正解だったと報告しています。こちらも、1.14が画像で一律に良くなったわけではない、という点で私たちの結果と重なります。

Boxは文字の行を正確に囲み、「ないもの」で迷う

同じ画像で、名札、言い切りの文字、効果をうたう1行、料金の表示、商品のボトルの位置をBoxで聞きました。返ってきた枠を画像に描いて確かめると、どれも文字の行や物の輪郭に沿った枠でした。応答は0.2秒前後です。試した文字やボトルについては、広告の文字を自動で塗りつぶす、名札だけをぼかす、といった加工の前段に使える手応えがありました。

気になった点が2つあります。1つは、「左側の人の顔」を頼むと、顔ではなく髪や文字まで含めた人物の領域全体を囲んだこと。顔だけを切り出す用途には大きすぎます。

もう1つは、写っていないものを頼んだときです。名札のない画像で名札の位置を聞くと、Boxはロゴを囲み、確信度0.56を返しました。同時に聞いた「名札は写っているか」は0.18だったので、組み合わせれば捨てられます。枠の確信度だけでは「ない」を見分けられない、という公式の注意どおりでした。逆に、ナンバープレート風の文字は、枠は正確なのに「車のナンバープレートは写っているか」には0.06と答えています。車がない画像なので答えとしては筋が通りますが、絞り込みの質問と枠の質問で、対象の言い方をそろえないと、正しい枠まで捨てることになります。

小さく縮めると弾かれることがある

細かい点ですが、ドキュメントの条件(各辺256ピクセル以上、総画素数78,400以上)を満たしているはずの512×272や320×256の画像が、「画像の大きさが不正」として弾かれました。280×280や512×300は通っています。正確な条件は分かりませんが、横長の画像を小さく縮めると弾かれることがあるので、短い辺に余裕を持たせて縮めるのが無難です。

なお、TypeSafeは顧客のリクエストと応答をモデルの学習に使わないと公式に書いています。ただ、保存しない設定(ZDR)は企業顧客向けです。人の顔や氏名が写る画像を送る前には、画像の権利と同意、社内の取り扱いを確かめてください。

最後に 試すならJev、本番の画像判定は実験扱いが外れてから

1週間前の「文章はJev、画像はDecisions API」を、今日の時点でどう考えるか。筆者の答えは、試すならJev、本番に入れるのは実験扱いが外れてから、です。

今回の15枚・8問では、費用も速さもJevが上で、誤りの数は互角でした。文章の判定と同じAPI、同じ請求で写真も見られるので、すでにJevを組み込んでいる会社ほど試しやすいと思います。それでも本番を待つのは、TypeSafe自身が、画像のリクエストの形も精度もリリースごとに変わりうると書いているからです。Decisions APIもベータ版ですが、公式ガイドには数週間以内に正式版にする見込みとあります。業務の流れに組み込むなら、提供元が本番向けとして出そうとしている側を選ぶのが順当だと筆者は思います。

すでにJevを使っているなら、先に jev-latest の行き先を確かめてください。公式は10月14日の発表から約1週間後に1.14へ切り替えるとしているので、そのままでよいか、1.13の版名に固定するかを決める必要があります。

画像を試すなら、人が目で見て数秒で決めている判断を1つ選び、正解を付けた写真10〜20枚で確かめるところからです。API代は1円にも届きません。そのとき決めておきたいのが、誤検知と見逃しのどちらが痛いか。今回、Jevは文字に反応しすぎる側に外れ、Decisions APIは文字を1件見落とし、ぼかした画像などの見た目に引っ張られました。投稿前に注意を出すだけで、出た注意を人が無理なく見られる件数なら、Jevの外れ方は扱いやすいと思います。誤検知が業務を止めるような自動で弾く用途なら、まずは弾く候補を人が確かめる形で始め、自社の写真で確率の帯ごとの誤りを測ってから、自動に任せる範囲を決めるほうが安全です。

次に見るのは3つです。画像とBoxから「Danger Zone」の札が外れる時期、1枚あたりのトークン数の公式な目安、そしてBoxが返す枠の確かさについて第三者の検証がどこまで出てくるか。札が外れたときに同じ条件で比べ直せるよう、今回の質問と結果は手元に残してあります。