Gemma で実現するデータ拡充のリアルタイム アーキテクチャ: Trustpilot の事例

※この投稿は米国時間 2026 年 6 月 2 日に、Google Cloud blog に投稿されたものの抄訳です。

厳しいレイテンシとコストの制約のもとで、数百万件のユーザー レビューをリアルタイムに処理するのは簡単なことではありません。Trustpilot は、大規模言語モデル（LLM）が注目を集めるはるか前から、カスタム ML を活用してこの課題に取り組んできました。そして現在、同社はコアスタックを生成 AI へと移行しています。ここでは、Google と Trustpilot が協力して、ファインチューニング済みの Gemma モデルを活用する大量処理向けストリーミング パイプラインをどのように構築したのかをご紹介します。

大規模で高度なレビュー インテリジェンスを実現

Trustpilot のコアビジネスは、実用的で深いレビュー インテリジェンスを提供することにあります。透明性と信頼できるフィードバックを重視するプラットフォームとして、データの完全性を守り、その価値を最大限に引き出すことが欠かせません。そのためには、受信するレビューからあらゆるメタデータを抽出する必要があり、このタスクには LLM が最も適しています。

LLM は、人が書いた雑多なテキストを解析し、固有表現抽出（NER）、ビジネス ドメインの分類、感情スコアリング、顧客意図の特定を行うことに優れています。しかし、数件のレビューを LLM に処理させるのは簡単でも、コストを膨らませずに数百万件のレビューをリアルタイムで処理するとなると、エンジニアリング上の大きな課題になります。

オープンモデルをファインチューニングする理由

このような大規模なタスクに取り組む場合、Gemini のような強力な既製のフロンティア モデルに接続するだけでは、なぜ十分ではないのでしょうか。レビュー処理は Trustpilot のコアビジネスを支える重要なパイプラインであるため、クローズド モデルが最適な選択肢になることはほとんどありません。代わりに、Gemma のようなオープン ウェイト モデルをファインチューニングすることで、Trustpilot は AI 戦略を自社で主体的に管理できます。具体的には次のとおりです。

• モデルの完全な独立性: Trustpilot はモデルを自社で管理することで、再トレーニングのライフサイクルを自ら制御できます。これにより、サードパーティ ベンダーの更新スケジュールや突然の API 変更に左右されなくなります。

• 予測可能なコスト構造: トークン単位の変動料金モデルから、固定的なインフラストラクチャ コストに移行することで、数百万件の予測処理を財務面で現実的かつ最適化可能なものにできます。

• MLOps 機能の拡張: これらのモデルを社内で構築することで、Trustpilot はオープン ウェイト モデルに関する専門性を高めながら、レビュー インテリジェンスにおける独自のノウハウをモデルに組み込むことができます。

• アーキテクチャの継続性: オープン ウェイト モデルの系統に標準化することで、ベースモデルの将来のイテレーションも活用し続けられます。これにより、エンジニアリングの負担を最小限に抑えながら、パフォーマンス向上を取り込むことができます。

Trustpilot は、1 つの巨大なモデルをデプロイするのではなく、軽量な google/gemma-2-9b をベースに、高度に特化したモデル群を構築しました。

小さなフットプリントで高いパフォーマンスを実現するため、Trustpilot は自社のレビュー コーパスから層化サンプリングしたデータに対し、Gemini 2.0 / 2.5 Pro / Flash ファミリーから選定した教師モデルを使用して、コンセンサス アノテーションを行いました。このプロセスにより、トピック分類、NER、感情抽出などの専門タスクに対応する高品質なトレーニング データセットが生成されました。

その後、これらのデータセットを使用して、目的別に設計されたカスタムモデル群をファインチューニングしました。その結果、従来のソリューションを大幅に上回る精度を達成し、教師モデルのコンセンサスと比べても、わずか数ポイント低い程度の精度を実現しました。

システム アーキテクチャ

このアーキテクチャは、Dataflow と Gemini Enterprise Agent Platform エンドポイントの上に構築されています。VertexAIModelHandlerJSON をそのまま使用できるため、両者は非常にスムーズに連携します。

ビジネス ロジックと LLM 推論そのものを分離するため、2 つのエンドポイントを作成しました。

1. 分類器: FastAPI ベースのエンドポイントで、前処理 / 後処理、プロンプト テンプレート、チェーンなどの複雑な処理を担います。

2. LLM: vLLM 経由で Gemma モデルをサービングすることに特化した独立型の Agent Platform エンドポイントです。

このアプローチにより、Dataflow ジョブをシンプルに保ちながら、LLM エンドポイントを得意分野であるテキスト生成に専念させることができます。さらに、分類器と LLM エンドポイントを、トラフィックに応じて個別にスケールできます。

パフォーマンス チューニング

vLLM ベースの Agent Platform エンドポイントを最大限に活用するため、Trustpilot はパイプライン全体のパフォーマンスを可能な限り引き出すことに注力しました。特に、A100 GPU を搭載した A2 VM の性能を最大限に活かすことを重視しています。また、Gemini Enterprise Agent Platform が管理するカスタマイズおよび最適化された vLLM バージョンも活用しました。

パフォーマンス チューニングでは、処理のボトルネックを防ぐため、vLLM バックエンド構成の最適化に重点を置きました。エンジン パラメータを慎重に調整し、適切なデータ型を選択したうえで、プレフィックス キャッシュなどの有用な設定を有効にすることで、大量のストリーミングをモデルがスムーズに処理できるようにしました。

さらに、vLLM 推論サーバーの最適なサービング容量を見極め、パフォーマンス特性を把握するために、再利用可能な負荷テスト フレームワークも共同で作成しました。これにより、必要なインフラストラクチャのベースラインを設定し、リクエスト数ベースの指標を使用して自動スケーリング設定をチューニングできるようになりました。加えて、vLLM で待機中のリクエスト数を使用する新しい指標のほうが、この用途にはさらに適している可能性があります。

課題

この構成を構築するにあたり、Trustpilot はいくつかの大きな課題に直面しました。

• プライベート ネットワーキング: このアーキテクチャでは、プライベート エンドポイントと Private Service Connect を使用して完全に分離された構成を目指していました。しかし、別個のエンドポイント間で直接プライベート通信を行うためのネイティブ サポートがなかったため、実現には至りませんでした。

• デプロイのオブザーバビリティと信頼性: エンドポイントのデプロイは時間がかかる場合や、内部の状態が見えにくい場合があります。そのため、正常でない状態になった際には、追加のトラブルシューティングが必要になることがあります。Trustpilot は現在も Gemini Enterprise Agent Platform のプロダクト チームと緊密に連携し、今後のオブザーバビリティ機能やプラットフォームの改善に取り組んでいます。

• GPU の不足: EU リージョンで A100 GPU を確保するのは難しく、オンデマンド VM は多くの場合、現実的な選択肢になりません。そのため、予約の活用が望ましいものの、開発、本番環境、トレーニング、推論、試験の間で予約をどのように配分するかは非常に難しい課題です。

結果

Trustpilot は Google Cloud と協力し、Gemini Enterprise Agent Platform 上で Gemma の可能性を最大限に引き出すことで、1 日に数百万件のレビューをほぼリアルタイムで処理できるようになりました。その結果、Gemini に近いパフォーマンスをわずかなコストで実現しました。これにより、Trustpilot Business Platform は、日々寄せられる何百万件もの顧客レビューを、即座に活用できるインサイトへと変換できるようになりました。詳しくは、Trustpilot の Medium ブログ投稿をご覧ください。

^{このブログ投稿は、2025 年末に実施された共同プロジェクトの成果に基づき、Assulan Nurkas 氏（Trustpilot）、Subu Ramasubramanian 氏（Trustpilot）、Konrad Stanek 氏（Trustpilot）、Dario Banfi（Google）、Michael Cohen Hjertén（Google）が執筆しました。}

- Google、フォワード デプロイド エンジニア、Dario Banfi

- Trustpilot、スタッフ ML エンジニア、Assulan Nurkas 氏