Gorse レビュー: Go 製の推薦エンジンが備える古典と LLM の二刀流

推薦システムを「部品」ではなく「エンジン」で用意する

多くのサービスでは、レコメンド機能を実装しようとすると、協調フィルタリングの行列分解から始まり、類似度計算、キャッシュ、API 化までを自前で積み上げることになります。Gorse はこの積み上げを省略し、アイテム、ユーザー、インタラクションのデータを投入するだけで、モデル学習から推薦 API の公開までを一貫して担うことを目的としています。対象となるのは、ニュースサイト、EC、動画配信、GitHub リポジトリの探索など、ユーザーごとに異なるアイテムを提示したいオンラインサービス全般です。単一のアルゴリズムに固定せず、最新アイテム、ユーザー間類似、アイテム間類似、協調フィルタリングなど複数の推薦ソースを組み合わせられる点が、このプロジェクトの基本設計です。

シングルノード学習と分散推論を分けた構成

Gorse のアーキテクチャは、マスターノード、ワーカーノード、サーバーノードの3種類で構成されます。マスターノードはモデル学習と非パーソナライズ推薦、設定管理、メンバーシップ管理を担当します。サーバーノードは RESTful API とオンラインのリアルタイム推薦を公開し、ワーカーノードは各ユーザー向けのオフライン推薦を計算します。ここで注目したいのは、トレーニングはシングルノードで行い、推論は分散させるという非対称な設計です。学習フェーズは1台に集中させることで、分散学習の複雑さを避け、推論フェーズだけをスケールさせるという割り切りが見えます。データストアは MySQL、MariaDB、MongoDB、Postgres、ClickHouse に対応し、中間結果のキャッシュには Redis、MySQL、MariaDB、MongoDB、Postgres を使います。つまり、既存のデータベース資産をそのまま利用できる一方で、Redis をキャッシュに使わない構成も選択可能です。

Docker 一発で始める playground モード

クイックスタートは Docker イメージを一つ実行するだけです。README に記載されたコマンドは次の通りです。

docker run -p 8088:8088 zhenghaoz/gorse-in-one --playground

この playground モードは、GitRec からデータをダウンロードして Gorse にインポートします。ダッシュボードは http://localhost:8088 で開けます。データ投入後に「Generate item-to-item recommendation」タスクが完了すれば、API 経由で推薦を取得できます。README の例では、Bob というユーザーが LLM 関連のリポジトリに star を付けたというフィードバックを投入し、その後 curl で /api/recommend/bob?n=10 を呼ぶと、LLM 関連のリポジトリが推薦される様子が示されています。フィードバックの形式は JSON で、FeedbackType、UserId、ItemId、Value、Timestamp の5つのキーを持ちます。この形式がシンプルなのは、既存のインタラクションデータを変換して投入する際の負担を減らすためでしょう。

古典ランカーと LLM ランカーの同居

Gorse の特徴として、古典的な推薦アルゴリズムと LLM ベースのランカーの両方をサポートしている点が挙げられます。古典側は協調フィルタリングや item-to-item などの定番手法で、学習と推論のコストが比較的低いのが利点です。一方で LLM ベースのランカーは、より文脈を理解した推薦が期待できますが、外部の LLM への依存と推論コストが増えます。README には LLM ランカーの具体的な実装詳細やモデル指定方法は記載されていません。そのため、実際にどのモデルを使うのか、API キーやエンドポイントの設定がどこで行われるのかは、公式ドキュメントを確認する必要があります。この情報の薄さは、LLM ランカーを本番投入する前に検証すべき項目です。

マルチモーダル対応の実態と埋め込みの扱い

テキスト、画像、動画などのマルチモーダルコンテンツを、埋め込み（embedding）経由で扱えるとされています。これは、アイテムのメタデータをベクトル化して類似度計算に使うという方式です。ただし、どの埋め込みモデルを使うのか、事前学習済みモデルを自前で用意するのか、それとも Gorse が内部で何らかのモデルを呼び出すのかは、README の記述からは判別できません。画像や動画を扱う場合は、前処理としての特徴量抽出が別途必要になる可能性が高いです。この部分は、導入を検討する際にドキュメントの該当箇所を丁寧に追う必要があります。

データベース選択の自由度とキャッシュの関係

本番運用で最初に決めるのは、データストアの選択です。MySQL、MariaDB、MongoDB、Postgres、ClickHouse のいずれかを選べます。中間結果のキャッシュも Redis だけでなく、MySQL や Postgres などでも可能です。これは、Redis を追加で運用したくないチームにとっては利点です。ただし、キャッシュをデータベースで代替する場合、性能特性が変わります。特にオンライン推薦の応答時間は、キャッシュ層の性能に依存するため、Redis を使わない構成では負荷テストが必須になるでしょう。ClickHouse は分析用途に強い一方で、オンラインの書き込み性能は他のデータベースと異なる特性を持ちます。推薦システムのデータフローが書き込み主体なのか読み取り主体なのかを、選択前に整理する必要があります。

ライセンスとリリースサイクル、運用コスト

ライセンスは Apache-2.0 です。商用利用、修正、再配布が比較的自由で、特許条項も含まれるため、企業での採用ハードルは低いと言えます。リリースは v0.5.9 から v0.5.11 まで、約1か月の間隔で公開されています。v0.5.10 は 2026-06-19、v0.5.11 は 2026-07-14 です。短いサイクルで改善が続いている一方で、バージョン番号が 0.5.x であることから、API の互換性が安定していない可能性があります。アップグレードのたびにマイグレーションや設定変更が発生する可能性を考慮し、テスト環境での検証工程は必須です。また、ドキュメントは英語が中心で、日本語の情報は限られています。チーム内で英語のドキュメントを読めるメンバーがいるかどうかも、運用コストの一部です。

代替案との比較: 自前実装とフルマネージドの間

Gorse と比較されるのは、自前で協調フィルタリングを実装する方法と、商用のフルマネージド推薦サービスです。自前実装は、アルゴリズムの選択肢が無限にある一方で、データパイプライン、モデル更新、API 公開、監視まで全てを自分たちで作る必要があります。Gorse はこの中間に位置し、学習と推論の基盤を提供しつつ、データベースは自分たちで用意するという分担です。フルマネージドサービスと比べると、インフラの管理は自分たちで行うため、運用負荷は残ります。一方で、データが外部サービスに送信されない点や、データベースを自由に選べる点は、データガバナンスの観点で有利です。このトレードオフを理解した上で、自前実装のコストとフルマネージドの制約のどちらが許容できるかを判断するのが良いでしょう。

編集部の結論

Gorse は、自前で推薦ロジックを書かずに、アイテムとユーザーとフィードバックを投入するだけで推薦 API を立ち上げたい開発者に向いています。特に、MySQL や PostgreSQL など既存のデータベース資産を活かしつつ、古典的な協調フィルタリングと LLM ベースのランカーを両方試したい場合は有力な選択肢です。一方で、リアルタイム性が極端に高い要件や、大規模なクラスタ運用を最初から想定している場合は、シングルノードのトレーニングと分散推論という構成の違いを先に確認すべきです。導入前に確認すべきは、データベースの種類と Redis のキャッシュ構成、そして LLM ランカーを使う場合の外部モデルへの依存関係です。Apache-2.0 ライセンスのため商用利用のハードルは低いですが、ドキュメントの記載が英語中心である点と、リリースサイクルが短い点は運用計画に織り込んでください。

公式情報源

1. Official documentation
2. Official README
3. Project repository
4. Release notes