OpenAI APIを使用してヨーロッパの物流住所の検証を行った結果、人件費を32%削減することができました。また、2つの致命的な問題も回避することができました。

先週の「ブラックウィーク」セールが終わったばかりで、技術チームが振り返り会を開いたところ、今年の住所自動検証の合格率が昨年より41％向上していることがわかりました。以前は異常な住所を処理するために専門に3人のアルバイトを雇っていましたが、今年はそのうち1人だけを残せば十分になります。

しかし、先月に遭遇した429エラーの問題について話す人はいませんでした。それは大規模セールの初日に最も忙しい3時間の間に起こったのです。13%のアドレス解決リクエストが直接返されています。カスタマーサービスのバックエンドがダウンしてしまい、運営チームが私たちのデスクをひっくり返そうとしたところでした。

初めて触れる方に正直なところを言いますが、OpenAI APIとは一体何でしょうか？

あなたは自分で大規模なモデルを訓練する必要はなく、OpenAIが既に訓練済みのGPT-4oやGPT-3.5-turboなどのモデルのインターフェースを直接呼び出してリクエストを送るだけで結果を得ることができます。使用するトークンの量に応じて料金が計算され、単一のリクエストでは最大128kのコンテキストをサポートするバージョンがすでに完全に公開されています。

当初選んだ理由はとてもシンプルでした。ヨーロッパ各国の住所形式が非常に乱雑で、イギリスの郵便番号とドイツの形式が全く異なり、さらに様々な言語でのスペルミスも問題でした。以前自分で作成したルールベースでは半年間で8回も更新が必要でしたが、それでも漏れがありました。APIを使用して意味解析を行うと、正しいプロンプトを与えるだけで正解率が96％以上に直接向上しました。

実際に得られた3つのメリットです。嘘ではありません。

• アルゴリズムチームを雇ってモデルを調整する必要はなく、3つのバックエンドシステムを1週間でインターフェースを接続し終えました。リリースから1ヶ月で、以前の3人のアルバイトの人件費を32%節約することができました。
• 以前のルールベースでは識別できなかったスペルミスや略語のアドレスも、今では90％以上が自動的に修正されるようになりました。その結果、ユーザーが注文時に間違ったアドレスを入力した場合のキャンセル率が28％も減少しました。
• 複数の言語が混在して入力されることをサポートしており、ポーランドのユーザーがポーランド語で入力した住所やスペインのユーザーがスペイン語で入力した住所でも、別途ローカライズする必要なく、そのままインターフェースに送るだけで標準的な物流フォーマットに変換できます。

良い点だけを見ているわけにはいかないね。これら2つの問題には本当にひどく巻き込まれ、危うく大変な目に遭うところだった。

最初の問題は、デフォルトの単一モデルによるリミット設定でした。以前はGPT-4o-miniのみを使用していましたが、デフォルトの分単位のリミット設定では通常の使用には十分でした。しかし、大規模なセールの日にはリクエスト量が3倍に増加し、すぐにリミットが発動しました。その結果、リクエストの13%が429エラーを返しました。後に、オフピーク時のリクエストをGPT-3.5-turboに転送するダウングレードロジックを追加することで問題を解決しました。

二つ目の問題は、機密性の高い住所が誤って判断されたことです。あるユーザーが「軍事基地」に関連する言葉を含む住所を入力したところ、APIのコンテンツ審査によってその住所がブロックされてしまいました。私たちは失敗に対するフォールバック処理を行っていなかったため、その注文が2日間発送されず、ユーザーから悪評をもらってしまいました。

誰がそれを使うべきか？本当に無駄遣いしないでください。

もしあなたも私たちと同じように、多言語の意味処理や終わりのないルールの作成に関わるビジネスをしていて、例えば住所の検証、ユーザーからの自動応答、多言語コンテンツの生成などを行っているなら、チームに専門のアルゴリズムチームがいない場合、OpenAIのAPIを使用する方が自分でモデルを訓練するよりもはるかにコスト効率的です。

しかし、もしあなたが扱っているのが核心データであり、そのデータを外部に出すことが絶対にできない業務であれば——例えば、金融分野の核心データ処理や医療分野のプライバシーデータの解析、あるいはリクエスト量が非常に安定しておりルールが明確なシンプルなシナリオであれば——わざわざこの波に乗る必要はありません。自分でルールを作成したり、小規模なモデルをローカルにデプロイした方がコストが低く、より安全です。

初めて使う方のための3つのヒントです。これらは私たちが失敗した経験から得たものです。

• ただ一つのモデルだけを使用するのではなく、少なくとも2つの異なるレベルのモデルを用意しておくことでダウングレードが可能になります。高品質なリクエストには精度の高いモデルを、低品質なリクエストやピーク時のリクエストには安価なモデルを使用することで、コストを少なくとも40％削減できるだけでなく、単一モデルの限界による障害も避けることができます。
• すべてのリクエストに対しては、再試行やフォールバックロジックを強化する必要があります。コンテンツの審査、リミット制御、タイムアウトなどのケースについては、事前に対策を立てておくべきです。インターフェースがダウンした後で手動で対処するのを待ってはいけません。
• 最初から最も高性能なモデルを使う必要はありません。まずは最も安価なGPT-3.5-turboで効果を確認してみましょう。効果が不十分なら、その後でより高性能なモデルに切り替えればいいのです。ほとんどのシンプルなシナリオでは、小型モデルで十分対応できます。

最後に、皆さんがよく質問される2つの質問についてお話しします。

Q: ヨーロッパ地域からの呼び出しでは遅延が非常に高くなるのでしょうか？
答：私たちはフランクフルトノードを使用しており、ほとんどのリクエストは15ミリ秒以内に処理されます。ごくわずかな割合のリクエストだけが突然200ミリ秒を超えることがありますが、キャッシュを追加することで問題を解決できます。ビジネスには全く影響ありません。

質問：解析結果が正しくない場合があるのでしょうか？
はい、現在は信頼度が80％未満の結果を人の手で確認するようにしています。このルールを導入してから、エラー率はほぼ無視できるレベルになりました。