エンドポイントがない理由
モデル、ランタイム、分析のすべてがブラウザにダウンロードされて実行されます。これはフラグ操作で覆せるようなデプロイの選択ではなく、アーキテクチャ全体に関わるものです。だからこそ、チェック対象のデバイスから画像が離れることはないのです。
APIはその逆を行います。誰かがサーバーに画像を送信し、サーバーがスコアを計算して数値を返します。画像は一時的であれ、また相手の意図がどれほど善良であれ、他人が管理するインフラ上に存在することになります。
何もアップロードされないことを唯一の提案とするツールにとって、アップロード用エンドポイントを提供することは製品の自己矛盾となります。そのため、このページはロードマップを説明するものではなく、限界とそれに対する対処法を説明するものです。
あえて明確にする必要があるのは、そうしないほうが悪い結果を招くからです。存在しないエンドポイントを暗示するページはエンジニアの午後を無駄にし、このサイトの料金ページには有料枠もAPIもないことが既に記載されています。
自動化の真の目的
エンドポイントを検討する前に、業務を正確に定義してください。自動化の意図の大部分は、別の方法で解決したほうが良いためです。
| サービスが必要 | ブラウザツールで機能する | 人間のステップがより適している | |
|---|---|---|---|
| ユーザーアップロードの大量スクリーニング | Yes 量とレイテンシ | No | No |
| サプライヤー納品のチェック | No | Yes 25件のバッチで十分 | Partly |
| 請求書類一式のレビュー | No | Yes 提出ごとに1バッチ | Yes 判断そのものが仕事 |
| 自社サイトの監査 | Partly 膨大な場合のみ | Yes 抽出してバッチ処理 | No |
これら4つのうち3つは、担当者がバッチを実行することで解決します。エンジニアがコードを書く前に、この点を確立しておく価値があります。最初の項目は本質的に異なり、ホスト型サービスが必要となるものです。
自動化が本当に必要な場合
3つの誠実なルートがあり、それぞれ異なるトレードオフがあります。そうでなければ誰の助けにもなりません。
| オプション | トレードオフ | 対象ユーザー |
|---|---|---|
| 商用API | 画像が自社インフラから離れる | 大量、低機密性 |
| オープンモデルの自己ホスト | エンジニアリングとハードウェアの時間 | 機密データ、社内能力あり |
| 管理下のブラウザで実行する | 手間はかかるがプライバシーは守られる | 中規模な量、厳格なプライバシー保護 |
| すべてではなくサンプルチェック | 部分的なカバレッジ | 現実的なワークロードの大部分 |
| 人による確認ステップ | 時間はかかるが、より的確な判断 | 人に影響を与えるあらゆるもの |
3行目が利用されにくい理由は説明に値します。自身のマシン上でヘッドレスブラウザを実行し、ローカルで解析を行うページを動かすことは、画像をどこにも送信せずに自動化を実現する正当な方法です。地味ですが、有効です。
4行目は多くのチームが選ぶべきでありながら、検討されることがほとんどない方法です。すべての画像をスクリーニングするのはコストが高く、通常は不要です。サンプルとして10パーセントを抽出し、さらに過去に問題を起こしたソースからの画像を含めることで、重要なもののほとんどを低コストで検出できます。
セルフホストの場合
この分野の研究モデルの多くは公開されているため、これは人々が想定するよりも実現可能です。許可されたライセンスで公開されたチェックポイント、推論ランタイム、そして控えめなサーバーがあれば、商用サービスが販売しているものの大部分を再現できます。
あなたが引き受けるのは、モデル周辺のすべてです。生成ツールの進化に合わせたモデルの更新、自社素材に合わせたしきい値の調整、独自の誤検知率の測定、そして結果が異議を申し立てられた際に説明できる人員の確保が必要です。
最後のポイントが隠れたコストです。組織内の誰もが十分に理解し守れない検出機能は、それに基づいた決定が疑問視された瞬間に負債となります。そして、その問いは常にいずれ訪れます。
何を構築するにしても、これを組み込んでください
2つの設計判断は、どのモデルを使用するかよりも重要であり、どちらもスコアが出た後の対応に関するものです。
スコアによって人に関する決定を自動で行わせないでください。フラグは人間に回し、モデルが何と言ったかではなく、人間が何を決定したかを記録し、影響を受ける人に対してなぜ問い合わせが行われたのかを説明できるようにしてください。
そしてスコアではなく、結果を保存してください。特定のユーザーやサプライヤーに紐付いた数値の検索可能な履歴は、それ自体の正当化を必要とし、運営上の価値を生まず、誰かが自身のデータの開示を求めた瞬間に問題となるプロファイリング記録です。
現実的な出発点
自動化を求めてここにたどり着くほとんどのチームにとって、最も賢明な最初のステップはエンジニアリングを一切行わないことです。1人の担当者が、受信した提出物を1バッチごとに確認し、見つけたものをファイルにメモするだけです。
これにより、1週間以内に価値あるもの、つまり自社の素材がどの程度のスコアになるかという感覚が得られます。開始当初は誰もこれを持っておらず、これなしではコードで設定するしきい値は、一度も測定したことのない分布に対する推測に過ぎません。
画像がどの位置にあるかがわかれば、自動化の必要性は理論ではなく具体的なものになります。週に何件の提出物が実際に確認を必要とするかがわかり、多くの場合、それによってエンジニアリング自体が不要であるという結論に至ります。
不要でない場合でも、少なくとも公開された基準ではなく、測定されたベースラインに基づいて自動化することになります。これは、他人のベンチマークではなく、自社のデータに有効な制御を行うための違いです。
構築前に何を測定すべきか
3つの数値が曖昧な意図を仕様に変えます。これらすべては、2週間にわたって手作業でバッチ処理を行うことで得られます。
自社素材の分布：通常のソースからの本物の画像が実際にどのスコアになるか。ほぼすべてのチームが、自分の入力画像が想像以上に加工されていることに驚きます。
独自の誤検知率：誰かが調査した際に、フラグが単なる通常の加工であったと判明する頻度。これは制御が実運用に耐えうるかを決定する数値であり、ベンダーのページに載っている数値ではありません。
実際にフラグが立つ量：人間が週に何件確認する必要があるか。その数が少なければ、計画していた自動化はスプレッドシートと運用の習慣に置き換えられます。