⚖️

デジタルゲーム特化の類似特許検索RAGを作った話

2025/01/22に公開

1. まえがき

今回、改めて記事に書き起こしたのは、直近この内容について社内でお話する機会があり、そこで話しきれなかった技術的詳細を補うための副資料及び、自分自身の開発の備忘録として残したいと考えた背景があります。

2. 開発の背景

今回このようなシステムを開発しようと決意した背景としては、単純に技術的な興味に加えて、自分が日ごろ良く遊んでいるデジタルゲームについて会社間の特許権侵害訴訟のニュースが度々取り沙汰されているのを見かけ、問題意識を持っていたという背景があります。
技術的な興味の背景について軽く触れると、私自身は本業でMLを活用した検索エンジニアとして従事していることと、9月頃に東大松尾研で開催されていた大規模言語モデル講座を履修する中でRAGについての座学から実装まで通しで学ぶ機会に恵まれ、いつか自分も取り組んでみたいという野望を持っていました。
RAGシステムの性能は「正解文章」を検索によって1つ見つけられるかで大きく左右されるという研究[1]が検索エンジニア的には興味を惹くポイントでした。

2.1 ゲーム会社と特許の問題

前述のゲーム会社間での特許権侵害訴訟のニュースについて、直近で話題になったものをまとめた画像を以下に示します。被告側は必ずしも資本力が乏しいというわけではありませんが、やはり会社の歴史やそれに伴って積み上げられた保有する特許権の量では両者の間に明確なパワーバランスがあることは明らかであるように思えます。

図1. 直近のゲーム会社間の特許権侵害訴訟事例記事[2][3][4][5]

この特許権侵害訴訟の悲劇が起こってしまう理由について、以下の動画では特に新興のゲーム会社においてゲーム企画案の類似特許調査が一般に時間的・金額的に困難であるため、おざなりになってしまうという旨が述べられていました。そこで、この類似特許調査タスクをRAGを用いて実現することで、新たな選択肢となりうるのではないかというのがもう1つの開発の背景です。

2.2 社会的意義

次に、類似特許調査の難しさについて定量的に検討してみます。以下の表はChatGPTの検索・対話機能を使いながら、類似特許調査のレベルごとに掛かる期間と金額についてまとめたものです。
この表から簡易調査ですら、少なくないコストが掛かることが分かり、Lv.1とLv.2の一部を人手を使わずにRAGシステムで代替できるようになれば、その社会的意義は大きいだろうと考えました。

調査タイプ 調査範囲・内容 費用目安 期間目安
簡易調査(Lv. 1) 国内特許データベースを中心にスクリーニング
大まかな類似特許をリストアップ
20~50万円程度 2~4週間程度
包括的調査(Lv. 2) 国内外の特許データベース、論文、関連会社の公開情報を確認
弁理士など専門家の詳細分析込み
100~300万円以上 1~2ヶ月以上
追加分析・回避策検討(Lv. 3, オプション) 調査結果を踏まえ自社の出願可否や回避策を検討
弁理士・開発チーム・経営陣との連携
追加費用 更に1~2ヶ月

3. 前提知識の整理

本システムの技術的詳細は以降の章で解説しますが、大前提として用語やドメインの定義がないと理解が難しいかもしれません。
よってこの章では、読み進めるうえで最低限持ち合わせておいて頂きたい基礎知識を整理します。

3.1 RAG (Retrieval Augumented Generation)

ここまでRAGという単語が度々登場してきましたが、RAGとは具体的には、ChatGPTに代表される大規模言語モデル(LLM)を補完して信頼性を高めることを目的としたシステムを指します。
そこでまずはLLMについて考えてみましょう。LLMの有名な性質として幻覚(Hallucination)というものがあります。これは、LLMが事実と異なることを回答として生成する現象を指し、LLMを組み込んだシステムを商業運用する場合に障壁となります。
Hallucinationが起こってしまう原因は、モデルの学習時に正しい回答についての文章データが含まれていないといった可能性が考えられます。これは例えば、会社の非公開データや、最新の時事ニュースについての質問で起こりやすいです。
さて、ここで以下に最もシンプルなRAGのアーキテクチャを示します。
下記のアーキテクチャ図において、ユーザーによる入力プロンプト(Query)をベクトルDBで検索し、その結果(Context)を入力プロンプトに付加したQuery+ContextをLLMに与えて回答を生成するのがRAGの基本的なワークフローであると言えます。
特にRAGにおいてベクトルDBを用いて検索するコンポーネントをRetrieverと呼び、LLMで結果を生成するコンポーネントをGeneratorと呼ぶことが多いです。

図2. 最もシンプルなRAGのアーキテクチャ
ここで、さらにQueryの視点で考えてみると、更に以下の図のようなイメージでLLMが補完されるのが理解できると思います。
このContextをwikipediaなどの確かなソース(一旦wikipediaの情報の信憑性は置いておいて)から取ってくることによって、LLMが学習していない情報についての質問に、根拠を示しながら回答できるようになるわけです。


図3. RAGによるLLMの補完のイメージ

最後に図2における「Embedding model → Vector store Index → Database」の流れについて見ておきましょう。
まず、Embedding modelとは文章を入力することでベクトルを出力する深層学習モデルを指します。これをベクトルDBに問い合わせるという流れなのですが、単純に考えれば、ある文章(Query)に類似する文章(Context)を検索するのはLLM単体ではできそうです。なぜEmbedding modelを介してベクトルに変換する処理を挟む必要があるのかというと、LLMによる回答が非常に遅いためです。
以下でも解説しているので、ざっくり説明するとベクトルに変換したことによる恩恵の1つとして、データ間の類似度の比較が非常に高速になるということが挙げられます。RAGでは大量の文書の中から、入力プロンプトに類似するものを高速に検索するという要件に応えるためにこのような手法をとるわけです。
検索に時間が掛かり過ぎてLLMから全く結果が返ってこないのは嫌でしょう。

3.2 特許権と著作権の違い

特許権に類似した概念である著作権にについても改めて違いを確認しておきましょう。最初に、ゲームの特許権侵害訴訟のニュース記事を見た方で、「これって著作権侵害じゃないの?」と思った方は少なくないのではないでしょうか。
以下に両者の比較をした表を示します。簡単なイメージとしては、ポケモンのデザインは著作権に該当し、モンスタボールを投げてポケモンを捕まえるというアイデアが特許権に該当すると言えます。

比較項目 著作権 特許権
保護範囲 文章・音楽・映像・プログラム等創作的表現全般 「新規性」「進歩性」など、法律で定められた要件を満たす技術的発明
有効期間 作者の没後70年 出願日から20年
権利の取得方法 創作時点で自動的に発生 特許庁への出願・審査を経て登録
侵害訴訟 デザインの類似性は細部まで似ていることを証明する必要があり、リターンのデザインの置き換えはコストに見合わない可能性が高い 侵害が認められれば、相手方に対して販売差止めや多額の賠償金といった高いリターンが見込まれる

類似しているゲームについて訴訟を起こす上で重要となるのは侵害訴訟の行です。
デザインの類似性の主張は一般に難しく、仮にデザインの類似性が認められたとしても、そのデザインのみを差し替えるだけで済まされてしまい、訴訟にかかる費用と比較してリターンが割に合わないケースが多いです。
デザインに関する著作権についての面白い企画として以下の画像に示す脱法ガチャピン(有吉弘行の脱法TV 2023-11-13放送回)で作成された著作権侵害として訴えられないギリギリのラインのデザインです。


図4. 脱法ガチャピン海賊版

3.3 特許文書の特徴

日本語で特許文書を調査する場合、J-PlatPatGoogle PatentsLens Patent Searchといったwebサービスが無料で利用できます。またGoogle PatentsなどはAPIが設けられており、CLIベースでもデータの収集が可能となっています。
以下の画像は、その中でもLens Patent Searchで特許文書を実際に検索した様子となっています。特許文書の主な構成要素は以下のものですが、中でもCPC分類コード請求の範囲については後述します。

  • 特許番号: 例. JP6030318B2
  • タイトル: 例. ゲームスステム、ゲーム処理方法、ゲームプログラム、およびゲーム装置
  • 登録日: 例. 2016-11-24
  • 出願人: 例. 任天堂株式会社
  • CPC分類コード: 例. A63F13/795, A63F13/58, A63F13/69, A63F13/847
  • 請求の範囲: (省略)

    図5. Lens Patent Searchで特許文書を検索した様子

3.3.1 CPC分類コード

CPC分類コードは特許文書を分類するための国際的な規格であり、階層構造で分類を定義しています。
例えば、今回の開発で対象とするデジタルゲームはCPCコードの上ではA63F13/00: ビデオゲーム、すなわち二次元以上の表示が出来るディスプレイを用いた電子ゲームに相当します。これ以外にもA23L2/00: 非アルコール飲料; その乾燥組成物または濃縮物などが例として挙げられます。
ここで/00はワイルドカードを表しており、A63F13/00の配下にはA63F13/58: Human Necessities ... by computing conditions of game characters, e.g. stamina, strength, motivation or energy levelなどが含まれるというイメージです。もし詳細が気になる方は特許庁が公開している分類対照表を参照して下さい。

3.3.2 請求の範囲

請求の範囲は特許文書のアイデアの有効範囲を定める文書であり、アイデアを構成する幾つかの文章(請求項)の集合として定義されます。
また本システムで最も重要な特許権侵害が成立するための要件は、基本的には請求の範囲に記載された請求項の全ての構成要素を満たす必要があります。
以下の図は、鉛筆という発明を特許として登録しようとしたらどのように請求の範囲とその請求項が記述されるかを示しています。

図6. EDEC2018でバンナムの知財部門の恩田氏が登壇した際の資料[6]

4. 解きたいタスクの整理

2章で具体的にどのような社会的課題が存在しているかを確認し、3章で本システムを理解するための最低限の道具を一通り紹介しました。
よって、この章では実際に課題を解くために、期待される入力と出力を整理し、システムで解ける形に課題を落とし込むことを考えます。

4.1 期待される入力

ゲームの企画文書
類似特許調査を検索するためには大前提として、ゲーム内のアイデア(例えば育成システムなどについて)具体的に記載されている必要があり、されているものと仮定します。

4.2 期待される出力

入力した企画文書に記載された各アイデアの中で既存の特許権と類似しているものを類似度順に列挙し、具体的にどの部分が抵触している恐れがあるかを通知します。

4.3 解きたいタスク

期待される入力と既存の特許文書間の類似性を評価し、その結果として導かれる類似度に基づいて特許権侵害リスクを定量化する必要があります。すなわち、各特許文書に対して算出されたリスク度合いを用い、その値の降順にn件の特許文書をRetrieverからContextとして返却すれば、LLMはそのContextと入力(Prompt)をもとにタスクを解決し、期待される出力を得られると考えられます。
そこで、RAGのRetrieverにおいて入力と各特許文書間の特許権侵害リスクを計算するためには、前述の3.3.2請求の範囲に関する項で示したように、各特許文書に紐づく全ての請求項を精査する必要があり、各特許文書のリスク度合いは、それぞれの請求項と入力との類似度の相加平均として定義されるものとします。

5. システムの設計紹介

本システムを理解して頂くために以下の流れで順を追って設計を紹介していきます。
まずは天下り的に提案アーキテクチャ図を示します。アーキテクチャ図内にはコンポーネントごとに番号が振られています。
次にコンポーネントごとの動作を説明する前に、RAGを開発するうえで重要となる言語モデルの選定と、最終的なアーキテクチャ決定に至った背景であるベースラインで分かった困難点についても説明します。
最後にアーキテクチャを構成するそれぞれのコンポーネントについて説明を説明します。

5.1 提案アーキテクチャ


図7. 提案アーキテクチャのイメージ

5.2 言語モデルの選定

本システムでは主に以下の2つの目的で言語モデルを利用します。

  1. 文章をベクトルに変換する ... コンポーネントの2部
  2. 文章を生成する / 文章を文章に変換する ... コンポーネントの6,7,8部

もしLLMを用いて何らかのシステムを作ろうと考えた場合、選択肢は幾つかあり、制約のもとでモデルの選定を行うことになるでしょう。例えば、セキュリティ要件などでデータを外部に持ち出せない場合にはローカルで動作するオープンなLLMをHugging Face経由で利用することが考えられますが、そのためにはGPUアクセラレーターなど一定水準の環境が必要となります。一方今回の開発では、そのような制約は存在せずスピード第一で開発を進めたかったため、ハードウェア環境が不要でAPI経由で全てが完結できるAzure OpenAI APIを利用しました。API経由でLLMを実行できる利点として、スレッディング実行により一度に大量のリクエストを捌くことが出来ることも挙げられます。
今回は目的.1のためにtext-embedding-3-large, 目的.2のためにGPT系列のモデルGPT-4o, GPT-4o-mini, GPT-o1を利用しました。
以下にAzure OpenAI APIを用いて、文章をベクトルに変換する例と文章を生成する例をそれぞれ示します。

import os
from openai import AzureOpenAI

# ベクトルエンコード用のAzure OpenAIクライアントの作成
vector_client = AzureOpenAI(
    azure_endpoint="https://example.openai.azure.com/",
    api_key=os.environ["AZURE_OPENAI_API_KEY"],
    api_version="2023-05-15" # ここは利用するモデルやバージョンによって異なります
)

embedding = vector_client.embeddings.create(
    input=[input_text],
    model="text-embedding-3-large", # ここは使いたいモデル名を指定します
    dimensions=512 # 次元数のオプション
).data[0].embedding
# 要約・生成用のAzure OpenAIクライアントの作成
chat_client = AzureOpenAI(
    azure_endpoint="https://example.openai.azure.com/", 
    api_key=os.environ["AZURE_OPENAI_API_KEY"],
    api_version="2024-08-01-preview" # ここは利用するモデルやバージョンによって異なります
)

completion = chat_client.chat.completions.create(
    model="gpt-4o", # ここは使いたいモデル名を指定します
    messages=[
        {"role": "system", "content": system_prompt}, # システムプロンプトは任意のものを記述します
        {"role": "user", "content": user_prompt}, # ユーザープロンプトも同様に任意のものを記述します
        temperature=temperature,
        ... # 各種パラメタを指定できます
    ]
)
response_message = completion.choices[0].message.content

5.3 ベースラインで分かった困難点

4.3解きたいタスクの節で定めた入力と各特許文書間のリスク度合いはナイーブに実装すると全件比較の必要が生じます。つまり、ベクトル検索の高速化を実現するためのANN(近似近傍探索; 詳細は省きますが、全件比較をせずに賢くベクトル検索を実現するための手法群の総称)計算が採用できず、時間コストが増加します。実際の数値を挙げると、本開発では特許文書量が9,641件、更にそれらに紐づく全ての請求項の文章を合計すると134,616件にも上ります。
加えて、文章のベクトル変換に用いたtext-embedding-3-largeはデフォルトで3072次元と非常に大きく更に時間コスト増に拍車を掛けます。
TIPSとしてtext-embedding-3-largeに並び立つAzure OpenAI APIのベクトルエンコーダーモデルは以下のようにcreateメソッドにdimensions引数を指定することで出力の次元数を指定できます。ベースラインでは3072次元を用いましたが、以降では512を指定しています。

response = azure_client.embeddings.create(
    input=[query],
    model='text-embedding-3-large',
    dimensions=512
)

5.4 各コンポーネント詳説

以降の項では、提案アーキテクチャのRAGを構成するコンポーネントの技術的詳細を見ていきますが、具体的な入出力が想像しづらい箇所も多々あると思うので、6.1巻末の結果の具体例を適宜参照しながら読み進めて頂くとスムーズな理解に繋がると思います。

5.4.1 データ収集

データ収集は、特許文書の特徴の節で触れたGoogle PatentsでCPCコードをデジタルゲームを表すA63F13/00配下の特許文書を対象としました。選定理由はAPIの利用が容易であったこと、Lens Patent Searchと比較してデータの欠損が最も少なそうであることでした。
またデータを収集する際にはデータの保持形式の検討も慎重に進めました。後続で利用する可能性のあるメタデータは取りこぼしたくなかったので、それらの選定と、特に特許権を核である請求の範囲という文章の集合をどのように扱うかに苦慮しました。
最終的には、メタデータを保持するcsvファイルと文章を保持するjsonファイルに分割して収集しました。
本開発では2024-10-09 ~ 2024-10-11時点で収集可能であった9,641件の文書を収集しました。以下にその結果の一部を示します。[1]

patents.csv
patent_id	title	assignee	granted_date	link	status
JP5595991B2	通信ゲームシステム	任天堂株式会社	2014-09-24	https://patents.google.com/patent/JP5595991B2/ja	Active
JP3734820B1	ゲームプログラム、ゲーム装置、および入力装置	任天堂株式会社	2006-01-11	https://patents.google.com/patent/JP3734820B1/ja	Inactive
JP6998286B2	情報処理プログラム、情報処理装置、情報処理システム、および、情報処理方法	任天堂株式会社	2022-01-18	https://patents.google.com/patent/JP6998286B2/ja	Active
JP5457146B2	サーバシステム、及びアイテム管理方法	株式会社バンダイナムコゲームス	2014-04-02	https://patents.google.com/patent/JP5457146B2/ja	Active
・・・
patents.json
[
    {
        "patent_id": "JP6998286B2",
        "cpc_codes": [
            "A63F13/352",
            "A63F13/358",
            "A63F13/5372",
            "A63F13/79",
            "A63F13/843",
            "A63F13/88"
        ],
        "claims": [
            {
                "claim_id": 1,
                "claim_type": "independent",
                "claim_text": "情報処理装置のコンピュータにおいて実行される情報処理プログラムであって、\nゲーム内のコンテンツからなるコンテンツ群から、複数のコンテンツを、ユーザによる選択が可能な対象コンテンツとして設定する対象コンテンツ設定手段と、\n複数の前記対象コンテンツの各々について、当該対象コンテンツとして設定された状態が終了するまでの残り時間を管理する残り時間管理手段と、\nユーザの指示に基づいて前記複数の対象コンテンツから少なくとも1つのコンテンツを選択コンテンツとして選択するコンテンツ選択手段と、\n前記選択コンテンツを前記ユーザに付与するか否かを判定し、付与すると判定した場合に当該選択コンテンツを当該ユーザに付与する付与手段として前記コンピュータを機能させ、\n前記対象コンテンツ設定手段は、\n前記対象コンテンツの前記残り時間がなくなったことを条件として、当該対象コンテンツに代えて、前記コンテンツ群からコンテンツを前記対象コンテンツとして新たに設定し、\n前記対象コンテンツが選択コンテンツとして選択されたこと、および、前記選択コンテンツが前記ユーザに付与されたことの少なくともいずれかを条件として、その直後または待機時間を経過した後であって、前記残り時間がなくなったことを条件として前記対象コンテンツが設定される場合とは異なるタイミングに、当該選択コンテンツに代えて、前記コンテンツ群からコンテンツを前記対象コンテンツとして新たに設定する、情報処理プログラム。"
            },
            {
                "claim_id": 2,
                "claim_type": "dependent",
                "claim_text": "前記対象コンテンツ設定手段は、前記コンテンツ群から抽選ルールに基づく抽選によって選出した前記コンテンツを、前記対象コンテンツとして設定する、請求項1に記載の情報処理プログラム。",
                "depends_on": 1
            },
・・・

5.4.2 ベクトル化

5.3ベースラインで分かった困難点の節でも述べた通り、text-embedding-3-largeから出力されるベクトルの次元は非常に大きいため、高速なコサイン類似度であっても時間が掛かり過ぎてしまうという問題がありました。
そこで工夫点として、埋め込み空間の幾何的構造は保持したままベクトルの次元を削減する次元削減を実施することを考えました。次元削減とはその名の通り、例えば1,000次元ある大きなベクトルを50次元に減らすようなイメージです。次元削減を実施すれば、当然メモリ使用量も計算量も圧倒的に減少しますが、一方で埋め込み空間の表現力が低下し、違いが判別できなくなってしまったりするため、やたらめたらに使って良い手法ではありません。そこで、埋め込み空間の幾何的構造を保持しているかという情報が重要になってきます。幾何的構造とはシンプルに言えば、次元削減前に近くにいたベクトルは次元削減も同じくらい近くにいて、遠いものは同様に遠くにいて欲しいというような性質です。
次元削減手法は有名どころとして、主成分分析(PCA)やt-SNEがありますが、今回は上述の性質を重視してUMAP[7]という手法とPCAを比較検討し、最終的にUMAPを採用するに至りました。以下にMNISTデータセットを用いた、PCAとUMAPの次元削減結果の比較図を示します。
右上の図がPCAで右下の図がUMAPでそれぞれ28×28=784次元のMNISTデータセットを2次元に削減した際の様子を示しています。PCAでは幾何的構造が破壊されて、ぐちゃぐちゃになっている反面UMAPはきれいにクラスごとに分割されていることが見て取れると思います。

図8. PCAとUMAPの次元削減結果の比較図

5.4.3 ベクトルDBの選定

ベクトルDBは3.1前提知識の整理におけるRAGの節でも扱った通り、膨大な文章データをベクトル化して保存し、高速に類似する文章を検索するための基盤となります。本開発では以下の要件からその選定を行いました。

  • セットアップが簡単であること ≒ ドキュメントが豊富であること
  • 日本語のtokenizerに対応していること
  • 全文検索(単語ベースでの一致度)とベクトル検索を組み合わせたハイブリッド検索が可能であること
    • ハイブリッド検索は先行研究[8]よりRAGの精度向上に寄与することが示されている

セットアップが簡単であるベクトルDBの代名詞としてRAGの解説記事で良く紹介されるのはChromaやFaissでしょう。これはローカル環境で利用することが出来るので、RAGを手元で試すには非常に都合が良いですが、一方でベクトル検索にしか対応しておらず、ハイブリッド検索はできません。
ハイブリッド検索が可能なベクトルDBは限定的ですが、有名どころだとElasticsearchやWeaviateが挙げられます。しかしながら、Weaviateは開発時点では日本語への対応は途上段階であり、セットアップはそこそこ大変で、日本語の解説記事も乏しい実情がありました。
一方で、Elasticsearchは検索エンジンとして老舗のサービスでドキュメントもナレッジも豊富でElastic Cloudというフルマネージドで利用できるサービスも存在するため、全ての制約を満たすソリューションでした。
Elasticsearchでは以下のクエリを実行することでハイブリッド検索が実現できます。

GET patents_index/_search
{
    "retriever": {
        # reciprocal rank fusion: 2つの異なるランキング結果(全文検索とベクトル検索)を混ぜる手法
        "rrf": {
            "retrievers": [
                {
                    "standard": {
                        "query": {
                            "bool": {
                                "must": [
                                    {
                                        # 全文検索: フリーワード文字列を要約文・特許のタイトルから検索
                                        "multi_match": {
                                            "query": query,
                                            "fields": ["abstract", "title"]
                                    }
                                    },
                                    { "term": { "assignee": assignee } }, # メタデータ絞り込み: 出願人
                                    { "term": { "status": status } }, # メタデータ絞り込み: 特許ステータス
                                    { "terms": { "cpc_codes": predicted_cpc_codes } },  # メタデータ絞り込み: CPCコード
                                ]
                            }
                        },
                        
                    }
                },
                {
                    # (knnと表記されているが)近似近傍探索(ann)手法の1つであるHNSWアルゴリズムで高速にベクトル検索を実行する
                    "knn": {
                        "field": "abstract_embedding",
                        "query_vector": query_vector,
                        "k": 10,
                        "num_candidates": 100
                    }
                }
            ]
        }
    }
}

5.4.4 indexの構成

5.3ベースラインで分かった困難点の節より、本システムをナイーブに実装しようとすると時間コストが大きすぎるという結果でした。
よって、本システムでは検索を効率的に実現するためベクトルDB内のindexを以下のように二段階構成を採用することによって問題を克服しました。

  1. 特許文書単位のindex ... レコード数: 9,641
  2. 請求項単位のindex ... レコード数: 134,616

つまり、入力のゲームの企画文書と1.特許文書単位のindexの間で検索(結果1)を行います。
次に結果1の特許文書に紐づく請求項集合についてのみ、入力のゲームの企画文書と2.請求項単位のindexの間で検索(結果2)を行います。結果2について、結果1に含まれる各特許文書ごとに相加平均を求め、最終的な各特許文書ごとのリスク度合いを算出します。
つまり、結果1にそもそも含まれなかった特許文書については自動的にリスク度合いが0と計算されてしまいまうため、何件まで結果1に含めるかは精度と速度のトレードオフとなります。
ところで、特許文書の特徴の節で触れたように、特許文書にはアイデア自体を代表するような1つの文章というものは必ずしも存在するとは限りません(一部abstractが含まれるものが存在します)。
よって実際にはLLMを用いて請求の範囲からabstractを生成する処理も本システム内には含まれています。

5.4.5 CPCコード推定

CPCコード推定は読んで字の如くではありますが、ユーザーから入力されたゲームの企画文章が特許として承認された場合にどのようなCPCコードが割り当てられるかを機械学習/深層学習モデルを用いて予測するというタスクです。
このようなコンポーネントを設ける理由として、5.3ベースラインで分かった困難点の節でナイーブに実装しようとすると時間コストが大きすぎるという課題について、事前に予測したCPCコードを用いて検索対象を絞り込むことで解決できるからです。
しかし、CPCコードを予測することは実際にはそんなに簡単なタスクではありません。なぜなら前述の例のように1つの特許文書に対して割り当てられるCPCコードは一般に複数です。加えて、CPCコードの種類はデジタルゲーム分野を表すA63F13/00の配下だけでも52種類存在します。
以下に実際に収集した9,641件の特許文書データをに存在するCPCコードの分布を示します。

図9. デジタルゲーム関連特許のCPCコード 分布

今回の開発期間中では、以下のように実験を行いました。
まず、解きたいタスクとしては52クラスのmulti class classificaitonであることから評価指標にはF1 macroを採用しました。その上で、比較対象としてはLightGBMやRandom Forestなどの機械学習モデル、深層学習モデルであるBERTに加えてベースラインとしてGPT-4oを採用しました。
GPT-4oは学習は行わずに、事前に作成したCPCコードごとに説明文を持つ対照表をシステムプロンプトとして与えて推定させました。
ベースラインの弱点として、学習を行わないため、特許文書と実際に付与されるCPCコードの傾向を知ることが出来ません。そのため、そこまで精度は振るわないと考えていましたが、実際には十分優秀で機械学習モデルに対しては精度で完全に上回っていましたが、日本語コーパスで事前学習済みのBERTをFine Tuningしたモデルには届きませんでした(F1 macroで0.31 vs 0.42という結果)。
よって本システムではBERTによるCPCコード推定を採用しています。

5.4.6 クエリ書き換え

5.4.1データ収集の節の実際の特許文書に目を通して頂ければ分かりますが、特許文書の体裁は独特で、一般的な感覚を持つ我々からすると読みづらいと感じると思います。一方で、本RAGシステムの利用者ペルソナを考えると、基本的には特許の専門家ではないユーザーが想定されるため、一般的な書き言葉の文章が入力されると考えられます。
ここからは仮説ですが、特許文書の読みづらさは言語モデルに対しても同様であり、似ている文章を似ていると判定できない懸念があると考えました。よって、入力として想定される一般的な書き言葉の文章を特許文書ライクな体裁に書き換えることで、このような懸念を払拭することができるのではないかと考えました。文章の体裁を書き換えるようなタスクはLLMにとっては得意分野であるため、Azure OpenAI APIを利用して、クエリの文章体裁の書き換えを実施するのがこのコンポーネントの役割です。
実際に、このコンポーネントの追加によって、コンポーネント5のCPCコード推定の分類精度の向上も確認できました。

5.4.7 検索結果並び替え

検索結果を並び替えるという取り組みはRAGのRetrieverに限らず、検索エンジンの枠組みでも広く議論されています。以下の画像に示すElastic search labsの画像では1st stageでは10万〜100万件あるドキュメントからBM25(全文検索のロジック)やANN(近似近傍探索)で精度より速度優先で絞り込んで、2nd, 3rdでは絞り込んだ見込みのあるドキュメントについて、今度は精度を優先して絞り込みをしていくことで、全体としては速度と精度のトレードオフをバランスしながら検索を行う様子を示しています。

図10. Elastic’s approach to hybrid search
また、ことRAGに関してもベクトルDBの検索結果について、LLMをRerankerとして検索結果の並び替えを実施することで性能が向上したという先行研究[9]が存在します。実際にベクトル検索は確かに、短い検索クエリに対しては、それらしい結果を返してくれますが、検索クエリが長くなって、今回のタスクのように文章がまるまる対象となると、その検索結果は人間が行った場合と比較して相関しないという肌感覚があります。一方で、LLMを用いた比較は、ベクトル検索に比べれば人目で判断した比較とある程度相関するという肌感覚もあり、実際に今回のタスクではクエリ書き換えと同様に効果的なオプションコンポーネントだったと考えています。

5.4.8 RAG結果生成

RAGの結果生成については、3.前提知識の整理の章でも触れたように、ユーザーが入力した文章(Prompt)にRetrieverの検索結果(Context)を足してLLMに回答を生成させるというだけのコンポーネントです。ただ、多少拘っている点としては、本システムによる類似特許調査タスクではRAGは飽くまでユーザーを補助するエージェントという立ち位置であり、実際の判断は法律の専門家などの判断を仰ぐべきであると考えています。他にもいくつか推奨事項が存在したり、Contextとして渡された各特許文書の出典を示す、回答のフォーマットを指定するなどといった制約は、Prompting手法であるFew Shotにより実現しています。
Few Shot自体はとてもシンプルなコンセプトであり、Promptの頭にLLMにこのように答えてほしいといという理想回答を1つ以上提示するというものです。これにより、実行の度に答え方のフォーマットが変わってしまったり、記載事項に漏れが生じる可能性を減らすことが出来ます。

6. おわりに

末筆ながら、最後に結果の具体例を示しながら本システムについての個人的な評価と今後の展望を考察します。

6.1 結果の具体例

付録として結果の具体例を以下に示しますが、紙面の都合上一部省略していることにご留意下さい。

## 入力クエリ:
Palworldは、プレイヤーが不思議な生き物「パル」を捕獲して育成し、共に生活しながらサバイバルを楽しむオープンワールドサバイバルクラフトゲームです。プレイヤーは食料や資源を集め、パルと協力して建築や農作業を進めながら広大なフィールドを冒険します。パルにはそれぞれ得意な作業や戦闘スキルがあり、プレイヤーはそれらを活用して、さまざまな活動を効率的に進めることができます。
パルの捕獲や育成システムが特徴的で、プレイヤーは「パルスフィア」というボール状のアイテムを使い、パルを捕まえて育成し、ボスとの戦いに挑んだり、パルの能力を強化していきます。さらに、パル同士を交配させ、新たなパルを誕生させる配合システムや、捕まえたパルに農作業や建設を自動で行わせる機能など、独自の要素が満載です。
・・・(略 本来は様々なゲーム記事を読み込ませています)
↓
## クエリ書き換え結果:
本発明は、プレイヤーがパルと称される生物と共に冒険を行うオープンワールドサバイバルクラフトゲームムに関するものである。該ゲームは、広大なオープンワールド環境下における探索、バトル、農業、建築等の多様なアクティビティを実行可能とし、さらに、プレイヤー間の対戦および協力プレイを実現するPvPモードを備える。プレイヤーは「スフィア」と呼ばれる球状のアイテムを投擲してパルの捕獲および育成を行う。
・・・(一部略)
↓
## CPCコード推論結果: 
['A63F13/30', 'A63F13/33', 'A63F13/55', 'A63F13/58', 'A63F13/80']
↓
## クエリ埋め込み生成結果: 
(50,), [0.23269695 0.14951622 0.1368714  0.12890238 0.1416229  0.13547102, ..., 0.15539369 0.10813911]
↓
## クエリ-特許間 検索結果: 
{'JP6442061B2': 52.571606, 'JP6691503B2': 50.386745, 'JP7545191B1': 49.530655, 'JP4756632B2': 46.982185, ..., 'JP7346513B2': 40.75664}
↓
## クエリ-請求の範囲間 検索結果:
[('JP6442061B2', 57.0275401904762),
 ('JP7518291B2', 55.885922),
 ('JP7545191B1', 53.406329)
 ('JP6691503B2', 49.7645025),
 ('JP6030318B2', 49.156599666666665)]
↓
## Reranker 並び替え結果:
JP7545191B1: 高
JP6442061B2: 高
JP6030318B2: 中
JP7518291B2: 低
JP6691503B2: 低
↓
## 最終的な出力結果
## 総合的なフィードバック
### 高リスクの特許権
JP7545191B1: 最も高い類似性を持つ特許権です。特に「捕獲アイテム」を用いたフィールドキャラクタの捕獲システムや、多人数プレイ、戦闘機能が入力クエリのゲームシステムと重複する可能性があります。 
出典: JP7545191B1 - Google Patents
JP6442061B2: キャラクタの育成およびマルチプレイ機能が類似しています。指標データの管理やキャラクタ強化機能が重複する可能性があります。
出典: JP6442061B2 - Google Patents
### 中リスクの特許権
JP6030318B2: マルチプレイヤー対応や攻撃・回復システムは関連性がありますが、「パル」の捕獲・育成機能との直接的な類似性は低いです。
出典: JP6030318B2 - Google Patents
JP7518291B2: オブジェクトの一体化や操作入力による制御機能は部分的に関連していますが、捕獲システムとの直接的な重複は限定的です。
出典: JP7518291B2 - Google Patents
### 低リスクの特許権
JP6691503B2: 主に対戦ゲームのオブジェクト制御に焦点を当てており、「パル」の捕獲・育成システムとの直接的な類似性は最も低いです。
出典: JP7518291B2 - Google Patents
## 推奨事項
特許調査の徹底: 特にJP7545191B1およびJP6442061B2に関して、詳細な特許請求の範囲を確認し、どの機能や要素が保護されているかを明確にすることを推奨します。
特許専門家への相談: 特許権侵害のリスクを正確に評価するため、特許弁護士や専門家に相談することを強くお勧めします。
独自性の強化: 既存特許と明確に差別化できる独自の機能やシステムを開発し、特許権侵害のリスクを低減させることを検討してください。
代替技術の検討: 捕獲や育成システムの実装方法を見直し、既存特許と異なるアプローチを採用することでリスクを回避できます。
継続的な特許監視: 開発プロセス全体を通じて、関連する新たな特許権の出願や公開情報を定期的に監視し、リスクを早期に察知する体制を整えることが重要です。

6.2 評価とまとめ

6.1結果の具体例では実際に特許権侵害が提起されたゲーム内容について、本RAGシステムで調査を行い、確かに人目で見ても類似しているように思える特許権への言及も散見されました。このことから、まだまだ荒削りながらRAGの特許文書への適用という可能性が示せたと言えるでしょう。
上記について、同人誌の執筆時点(2024-10-22)では任天堂からパルワールドへの特許権侵害として訴えた具体的な特許番号は言及されていなかったのですが、2024-11-08にパルワールドを開発するPOCKETPAIR社から正式にこの件に対するプレスリリースが発表され、本RAGシステムで提示した一部の特許文書が含まれていることが判明しました。

  1. 訴えの内容
    2024年1月19日に当社がリリースした『Palworld / パルワールド』が、原告の保有する以下3件の特許を侵害していると主張し、ゲームの差止め及び当該特許の登録日から本件訴訟の提起日までの間に生じた損害の一部を損害賠償として求めるものです。
  2. 対象特許
    ・特許第7545191号 特許出願日: 2024年7月30日 特許登録日: 2024年8月27日
    ...

6.3 今後の展望

前節で見たように、本開発で掲げた目標であるデジタルゲーム特化の類似特許検索RAGの実現可能性は十分示せたのではないかと考えています。本システムにおける今後の展望としては2つの軸で考えられるでしょう。

  1. 特許文書ドメインの拡張
  2. 特許検索性能向上の追求

1つ目に関しては、今回は時間の制約の側面から簡単のために特許文書ドメインをデジタルゲーム(CPCコード: A63F13/00)に絞った中で実現可能性が示されたということは、ドメインを移したりドメインを拡張してCPCコード: A63: スポーツ; ゲーム; 娯楽を対象にするなどしても、同様の機能を実現できるだろうというものです。
2つ目に関しては、今回の開発では検証や比較を深く行わなかった、ベクトルエンコーダー、CPCコード推定や次元削減についてです。ベクトルエンコーダーは簡便性を優先してAzureの多言語モデルを利用しましたが、当然ながら文書ドメイン・言語を絞って学習されたモデルを使ったり、少なくとも比較検討することでパイプライン全体の性能を向上する余地が残っていると言えます。CPCコード推定や次元削減についても、同様ほぼ定量的な評価は出来ていないので、これらの改善によりスループットとレイテンシを向上したり、検索性能を向上する余地があるでしょう。

7. 参考文献

[1] Toward Optimal Search and Retrieval for RAG, Alexandria Leto et al . https://arxiv.org/abs/2411.07396 . 公開日 2024/11/11 (最終閲覧日 2024/12/21)

[2] ついに動いた!任天堂vs.パルワールド訴訟の焦点, 東洋経済オンライン . https://toyokeizai.net/articles/-/829506 . 公開日 2024/09/25 (最終閲覧日 2024/10/20)

[3] 任天堂も動いた!変わるゲームの「特許事情」, 東洋経済オンライン . https://toyokeizai.net/articles/-/221979 . 公開日 2018/05/24 (最終閲覧日 2024/10/20)

[4] セガ、他社運営のゲーム「メメントモリ」に対し特許権侵害で提訴 10億円の損害賠償と差し止め請求, オタク総研 . https://news.yahoo.co.jp/articles/378b5922a031015bb72347e9de676f7619735d83 . 公開日 2024/10/22 (最終閲覧日 2024/12/20)

[5] コナミの主張判明、「ウマ娘40億円訴訟」の深刻度, 東洋経済オンライン . https://toyokeizai.net/articles/-/679752 . 公開日 2023/06/19 (最終閲覧日 2024/10/20)

[6]【CEDEC 2018】難解な”特許”の簡単な「読み方」と「探し方」…特許係争を起こさないための調べ方とは, gamebiz . https://gamebiz.jp/news/218889 . 公開日 2018/08/30 (最終閲覧日 2024/10/20)

[7] UMAP: Uniform Manifold Approximation and Projection for Dimension Reduction, Leland McInnes et al . https://arxiv.org/abs/1802.03426 . 公開日 2018/02/09 (最終閲覧日 2024/10/21)

[8] Blended RAG: Improving RAG (Retriever-Augmented Generation) Accuracy with Semantic Search and Hybrid Query-Based Retrievers, Kunal Sawarkar et al . https://arxiv.org/html/2404.07220v2 . 公開日 2024/08/04 (最終閲覧日 2024/10/21)

[9] Enhancing Q&A Text Retrieval with Ranking Models: Benchmarking, fine-tuning and deploying Rerankers for RAG, Gabriel de Souza P. Moreira et al . https://arxiv.org/html/2409.07691 . 公開日 2024/09/12 (最終閲覧日 2024/10/08)

[10] 従属項の作成理由, 小山特許事務所 . https://www.koyamapat.jp/2020/07/01/dependent_claim/ . 公開日 2020/07/01 (最終閲覧日 2024/12/08)

脚注
  1. patents.jsonのclaimsセクションの中にdepends_onという属性がありますが、これはこの請求項が従属請求項であることを示しています。従属請求項を付加する理由については[10]などを参照して頂きたいですが、後続のベクトルDBに登録する際は、従属先の独立請求項の文章に付加する形で登録を行っています。 ↩︎

Discussion