Fastino、情報抽出のスパン列挙を排除したGLiNER2.5を公開

Fastinoが情報抽出モデルGLiNER2.5を公開。スパン列挙を廃止し、境界予測方式で長文対応と性能向上を実現。

投稿者 central
GLiNER2.5はスパン列挙を排除し、長文コンテキスト処理と線形計算量を実現。
ハイライト
  • GLiNER2.5はスパン列挙を廃止し、境界予測方式に移行した。
  • 最大幅制限が撤廃され、4,096ワードの長文コンテキストが処理可能になった。
  • XNLIベンチマークで24.75ポイントの大幅改善を達成した。

情報抽出の分野では、小さなエンコーダーモデルは低コストだが柔軟性に欠け、大規模言語モデルは柔軟だが文書あたりのコストが高いというジレンマが常につきまとう。このトレードオフを解消するため、Fastinoは新たな情報抽出モデル「GLiNER2.5」を公開した。最大の変更点は、従来の「スパン列挙」方式を廃止し、「境界予測」方式へと移行した点にある。これにより、エンティティの最大幅制限が撤廃され、4,096ワードという長文コンテキストが処理可能になっただけでなく、計算量がシーケンス長に対して線形に抑えられる。さらに、エンティティと関係性の同時抽出、クロスタスクのラベル制約、エンティティごとの属性付与といった高度な機能が、単一のアーキテクチャで実現された。Hugging Face上では、Apache 2.0ライセンスのもと、74M、194M、287Mパラメータの3種類のチェックポイントが公開されている。

GLiNER2.5とは——スパン列挙を排除した理由

従来のGLiNERモデルは、エンティティを特定する際に、すべての開始位置と可能な幅の組み合わせを列挙し、それぞれをスキーマに対してスコアリングする方式を採用していた。この「スパン列挙」方式は、計算量がエンティティの最大幅(W)に依存するという本質的な制約を抱えていた。たとえば、最大幅を12ワードに設定した場合、13ワード以上の長いエンティティは評価対象にすらならず、構造的に見逃される。そして、最大幅を広げれば広げるほど、評価すべき候補スパンが爆発的に増加する。

GLiNER2.5はこのアプローチを根本から見直した。共有エンコーダーがテキストとスキーマクエリを一度に処理する点は変わらないが、その後はスパン全体を評価するのではなく、トークンの境界における「開始スコア」と「終了スコア」、さらにトークン内部のスコアを予測する。疎な提案段階で、クエリごとに最も有望な開始点と終了点を選び出し、距離の制限なしにペアリングする。その後、リランキングヘッドが境界情報とスパン内容を考慮して各候補を評価する。関係性の候補も、別経路ではなく同一のプールから抽出される。

この設計により、計算量は固定スキーマと候補予算に対してシーケンス長に線形となる。過去に不可能だった40ワードの契約条項であっても、2ワードの固有名詞と同じコストで正確に抽出できる。

スパン列挙廃止がもたらした5つの実用的能力

このアーキテクチャ変更は、単なる効率化にとどまらず、実運用において重要な複数の新機能を可能にした。

1. 長文コンテキスト抽出(4,096ワード対応)

明示的なスパン表現を排除したことでメモリ使用量が削減され、最大4,096ワードのシーケンスで学習が可能になった。公開されたチェックポイントはmax_len=4096で出荷され、ライブラリにはextract_entities_longやextract_longといったネイティブのチャンキング補助機能が用意されている。これらの関数は、分割されたセグメントのスパンを元の文書の文字位置に自動的に再マッピングする。

2. 無制限のスパン長

GLiNER2ではスパンは固定幅(通常12ワード程度)までしか列挙されなかったため、それより長いエンティティは評価の対象外だった。GLiNER2.5では、スパンは最初のトークンで開かれ、最後のトークンで閉じられる。長大な契約条項も、短い固有名詞とまったく同じコストで処理される。

3. エンティティと関係性の同時抽出(ジョイントIE)

ユーザーはエンティティタイプ、型付き関係、構造ルール(unique_head=True、no_self_loops()など)を宣言するだけで、ビームサーチがグローバルに一貫した知識グラフを組み立てる。不正な組み合わせは最初から考慮されないため、出力は構造的に妥当性が保証される。

4. 制約付き分類(クロスタスクラベル制約)

C.implies(論理含意)とC.excludes(排他的制約)というルールにより、デコード中にラベル間の制約を課すことができる。たとえば、Fastino自身が開発したガードレールモデル「GLiGuard」のユースケースでは、「安全」と「プロンプトインジェクション」が同時にラベル付けされるような矛盾を防止する。実行可能なラベル割り当てが存在しない場合、デコーダーはエラーを返す。

5. スパン属性の付与

特定のエンティティタイプに対してapplies_toで紐付けた属性グループ(例:感情分析のラベル)を、スパンごとに同一フォワードパス内でデコードする。エンティティはフラットなラベルではなく、属性情報を含んだ構造化データとして返される。

ベンチマーク結果——XNLIで24.75ポイントの大幅改善

Fastinoは、16の公開データセットを用いたゼロショット評価を実施し、同等サイズのGLiNER2とのマクロF1スコアを比較している。

全体平均では、GLiNER2.5 Multi(多言語版)が56.17を記録し、GLiNER2 Multiの56.09をわずかに上回った。GLiNER2.5 Baseは54.87で、53.34のGLiNER2 Baseから改善している。特に注目すべきはXNLIにおける結果で、Multi版は37.55から62.30へと24.75ポイント</strongもの大幅な向上を示した。Few-NERDでもBase版が47.22から55.14へと改善。さらに、学習データに含まれていないルーマニア語のRONECデータセットにおいても、両バージョンでスコアが向上しており、言語横断的な汎化性能の高さが示された。

デプロイ方法——セルフホスティングが基本

GLiNER2.5は、Apache 2.0ライセンスのオープンソースモデルとしてHugging Faceで公開されている。ローカル推論はPython 3.10以上の環境でpip install "gliner2[local]"を実行することで、CPU、CUDA、MPS(Apple Silicon)上で動作する。現時点では、外部の推論プロバイダーがチェックポイントをホストしていないため、デプロイパスは事実上セルフホスティングとなる。

74Mパラメータと194Mパラメータのチェックポイントは標準的なCPUボックスでも実行可能なため、GPU予算のない少人数チームでも情報抽出パイプラインを構築できる。大規模組織にとっては、トークン単位でコストがかかるLLM抽出に代わる、ファインチューニング可能で完全にプライベートな代替手段として位置づけられる。

適した産業分野としては、法務・契約業務、ヘルスケア・臨床文書、金融サービス、保険請求、カスタマーサポート、AIセーフティツールなどが想定されている。具体的なアプリケーションとして、PII(個人識別情報)の検出とマスキング、契約条項の抽出、エージェントメモリ用の知識グラフ構築、エージェントおよびモデルのルーティング、ガードレール分類、否定表現や投与量といった属性付きの臨床エンティティ抽出などが挙げられる。

3つのチェックポイント——アーキテクチャは同一

公開された3つのチェックポイントは、すべて同一の公開APIを持つ。ロードにはレガシーなGLiNER2用のGLiNER2ローダーではなく、AutoExtractorを使用する。

実用性と拡張性——情報抽出の新しいスタンダードへ

GLiNER2.5のアプローチは、小規模エンコーダーモデルと大規模言語モデルの間に存在した性能とコストのギャップを、アーキテクチャの工夫で埋めるものだ。特に「境界予測」への移行は、単なる効率化ではなく、抽出可能なエンティティ長の制限撤廃やジョイントIEの実現など、質的な飛躍をもたらした。コスト面での優位性は明らかであり、GPT-4などのLLMで全文書を処理するコストと比較すれば、セルフホスティング型の専用モデルは圧倒的に低コストで運用できる。

一方で、LLMが持つ圧倒的な汎用性や、複雑な推論を要するタスク(感情分析とエンティティ抽出の融合など)においては、依然としてLLMに分がある領域も存在する。GLiNER2.5は、これらのLLMを完全に置き換えるものではなく、定型化された抽出パイプラインにおいて、より安価で高速、かつプライベートな選択肢として機能する。今後の展開として、このアーキテクチャがさらに大規模なモデルに適用されるのか、あるいは特定ドメイン向けのファインチューニングが容易になることで、業界特化型の情報抽出基盤として標準化されるのか、注目が集まる。

この記事をシェア