こんにちは、LINEヤフー株式会社で自然言語処理の開発を担当している牧野です。
今回はYahoo!デベロッパーネットワークのテキスト解析 Web API で使えるテクニック「バッチリクエスト」について紹介します。
少し前ですが、テキスト解析 Web API は、すべて V2 への移行を実施し、新インターフェースになりました。この新インターフェースには JSON-RPC 2.0 を採用しています。また日本語形態素解析、キーフレーズ抽出、ルビ振りなど、どの Web API も入出力仕様を共通化しています。
この共通化については、下記の記事でも紹介しています。
今回の記事では、まず Web API で言語処理機能を提供するメリット・デメリットを説明し、その後、デメリットをカバーするバッチリクエストについて紹介します。このバッチリクエストは今回の新インターフェース移行に伴い、利用できるようになったものです。
言語処理機能を Web API で提供するメリット・デメリット
2007年6月に日本語形態素解析 Web API を公開し、現在では7つの異なるテキスト解析 Web API を提供しています。これらの API は多くの方々から活用され、日々大量の解析リクエストを処理しています。 ここでは言語処理機能を Web API で提供するメリット・デメリットについて説明します。
Web API 形式の解析では、主に以下のメリットが得られると考えています。
- インストールなしで使える
通常、形態素解析など言語解析ツールを利用したい場合、利用者側でインストールや設定が必要ですが、 Web API 形式でのテキスト解析ツールでは、とくにこれらは必要なく手軽に使えます。 また利用者は解析にかかる計算リソースも意識しなくても良くなり、ローカルのコンピューティングリソースを節約できます。 - とくに意識しなくても最新のモデルが使える
Web API 側でモデルのアップデートやメンテナンスを行うため、利用者はとくに更新を気にせずに、常に最新版を利用できます。 - 柔軟な組み込みができる
Web API 形式で提供されており、他のアプリケーションやサービスに柔軟に組み込めます。ネットワークにつながる環境であれば利用できるため、スマートフォンアプリなどからでも利用可能です。また利用者側のプラットフォームやプログラミング言語も、どのようなものでも構いません。
メリットがある一方で、 Web API の場合、クライアント側が HTTP 接続する際に一定のオーバーヘッドが生じます。これがデメリットの一つです。 しかし、テキスト解析 Web API は新インターフェースでバッチリクエストをサポートしており、複数の呼び出しを一つの HTTP リクエストに結合可能になりました。これにより、効率的に処理できます。
ここからは、バッチリクエストについて具体的な利用方法を紹介します。
リクエストをまとめて送信「バッチリクエスト」
バッチリクエストは、Yahoo!デベロッパーネットワークのテキスト解析 Web API の全ての Web API （日本語形態素解析、キーフレーズ抽出、ルビ振りなど）で利用可能です。
通常、複数の文章を解析したい場合、複数回リクエストをなげるのが一般的かと思います。すると毎回のリクエストごとにHTTPのオーバーヘッドが生じるため、パフォーマンスが下がると 考えられます。
バッチリクエストとは？
バッチリクエストには以下のような特徴があります。
- 1つのリクエストに Web API への複数の呼び出しをまとめられます
- Web API への各呼び出しは独立して実行されるため、一部の呼び出しが失敗しても、他の呼び出しは影響を受けずに実行されます
- Web API への各呼び出しの順序に制約がないため、レスポンス結果の順序は入力の順序と変わることがあります
- Web API への各呼び出しに対するレスポンスは、リクエスト時に指定した id で対応がとれます
リクエスト/レスポンスは？
リクエストやレスポンスについてのポイントは、以下の通りです。 日本語形態素解析をバッチリクエストでリクエストする例も載せていますので、あわせてご覧ください。
- リクエストのポイント
- HTTP ヘッダーやリクエスト URL は、（バッチリクエストではない）通常時と同じです
- リクエストJSON を Array 形式 にします
- リクエストJSON の Array の各要素内の id は、他の要素の id と被らない、ユニークな値にしておきます(※)
- レスポンスのポイント
- HTTP ステータスコードの仕様は、（バッチリクエストではない）通常時と同じです
- レスポンスJSON は Array 形式で返却されます
- どのリクエストに対するレスポンスなのかは、 id で判断します
(※) JSON-RPC 2.0 の仕様では id が他の要素の id と重複しても問題ありません。しかし、同じ id を複数回使用すると、呼び出し側がどのリクエストに対するレスポンスなのか区別することができなくなってしまいます。そのため、 id はユニークにしておくことがポイントになります。
具体例
ここではテキスト解析 Web APIの「日本語形態素解析」をバッチリクエストでなげるサンプルを紹介します。
通常のリクエスト例
まず下記は通常のリクエスト、レスポンスの例です。
バッチリクエストの例（リクエストを1つにまとめる）
バッチリクエストで2つ入力を1つのリクエストにまとめてみます。下記のようにArray形式で複数の入力をまとめられます。
- リクエスト：id = "1", "2" で別々の文章（
params/q）を指定しています - レスポンス：id = "1", "2" それぞれに対して解析結果が返却されます
バッチリクエストの例（まとめたリクエストの一部がエラーの場合）
次はバッチリクエストで2つの入力を1つのリクエストにまとめる例ですが、一部がエラーの場合のレスポンスを見てみましょう。
- リクエスト：id = "2" は誤ったmethod名を指定しています
- レスポンス：id = "1" は正常に処理され、 id = "2" のみエラーが返却されます
バッチリクエストはこのように複数の入力を1回のリクエストにまとめられます。またレスポンスは入力の id それぞれに対応したもの（エラーの場合も）が返ってきます。
注意点
バッチリクエストでのリクエストボディの最大サイズは、各 Web API で許可している最大値です。具体的な最大サイズの値は、各 Web API の仕様ページにてご確認ください。各 Web API の仕様ページは下記となります。
おわりに
今回は テキスト解析 Web API の新インターフェースで可能となったバッチリクエストを紹介しました。よりパフォーマンスの高いリクエスト方法ですので、ネットワーク上の遅延を気にしていた方や、複数回の処理をまとめたい場合など、ぜひご活用いただければと思います。今後もテキスト解析 Web API についての記事を公開していく予定ですので、ぜひご覧ください。