Cohere Command R+とGPT4, Claude3, Gemini1.5の引用段落抽出精度を比較してみた

はじめに

先日、2024/4/4 CohereからCommand R+という新たなLLM(大規模言語モデル)が発表されました。

Cohereは、Transformerモデルを提唱した論文共同執筆者の人が立ち上げたカナダのAIベンチャー企業のようです。 https://ascii.jp/elem/000/004/192/4192907/

Command R+とは、最大で128Kトークンが処理が可能で、コストはGPT4Turboの3~5倍ほど安いモデルです(Claude3 Sonnetと同等)。

先日、以下の記事にてGPT, Claude3, Gemini別に審査官による特許引用文献段落の再現率の検証を行いました。

ChatGPT, Claude3, Gemini別に審査官による特許引用文献段落抽出の再現率を検証してみた - CreateField Blog

Gemini 1.5 Pro APIを使って特許引用文献段落抽出の再現率を検証してみた - CreateField Blog

今回は、同一データでCohereのCommand R, Command R+の再現率と適合率を検証してみました。 なお、CohereのCommand R, Command R+にはRAG特化の引用元抽出の機能がありますが、今回はそちらを使わず、プロンプトベースで検証しています。

テスト対象

先日と同様、以下の引用文献の条件を満たす過去の特許文献を100件抽出しました。

• 拒絶理由通知引用(審査官による引用)がある
• 請求項1のみでXカテゴリーで引用されている（単⼀の⽂献のみで発明の新規性⼜は進歩性がないと判定されたもの）
• 特許公開公報
• 引用している文献の記載箇所の段落数が1-5以内（あまりに範囲が広いとピンポイントで記載箇所を正しく抽出できているかを評価できないため）
• 図面を引用していない
• 引用している明細書が5万文字以下

再現率・適合率検証手順

APIを使って各モデルに、テスト対象の特許文献のトップクレームの技術構成要素が引用文献のどの段落に記載されているかを生成してもらい、以下の3つの観点で評価しました。

• 全段落±2再現率: 審査官が引用した全ての段落のうち、AIが±2の範囲で一致する段落を正しく抽出できている割合
• 全段落±2適合率: AIが生成した引用段落のうち、AIが±2の範囲で一致する段落を正しく抽出できている割合
• 全段落±2F値: 再現率と適合率の調和平均

段落一致は、必ずしも審査官が引用した段落と完全に同一の段落でなくても周辺の記載内容でも十分正しい引用と考えられるため、前後±2の周辺段落でも正解と取り扱っています。

また、「下手な鉄砲も数撃てば当たる」可能性もあるので再現率だけでなく、適合率・F値も算出しています。 「再現率」はお手つき関係なしにどれだけ漏れなく正解できたかを判定する指標で、「適合率」はどれだけ誤った生成なしに正解できたかどうか(ノイズが少ないか)を判定する指標です。

審査官の引用段落は文書中の1つのサンプルを引用しているだけにすぎないことが多く、 審査官が挙げていない他の複数の段落を当てても正解と取り扱っても実質的に問題ないことがあります。 今回は、機械的に実際の審査官の段落との一致率だけをみているので、適合率は体感精度より低めに出ています。

性能評価結果

モデル	全段落±2再現率	全段落±2適合率	全段落±2F値
gpt-4-0125-preview	0.346 (79/228)	0.202 (79/391)	0.255
claude-3-haiku-20240307	0.408 (93/228)	0.15 (93/620)	0.219
claude-3-sonnet-20240229	0.496 (113/228)	0.134 (113/844)	0.211
claude-3-opus-20240229	0.456 (104/228)	0.216 (104/481)	0.293
gemini-1.5-pro-latest	0.465 (106/228)	0.143 (106/740)	0.219
command-r	0.754 (172/228)	0.103 (172/1671)	0.181
command-r-plus	0.789 (181/228)	0.033 (180/5507)	0.063

この精度検証では、実際の審査官の引用段落は228個に対し、Command R+は5507個も段落を挙げてしまっており、適合率が極めて小さい結果となりました。

実際の出力サンプル

実際の出力での定性評価としては、今回の日本語でのプロンプトでは、Command R, Command R+は審査官が引用していない異なる技術の文献のケースでうまく比較できていないようでした。

審査官引用文献ケース

「含まれている」が正解。

• gpt-4-0125-preview

構成要素	含まれている/含まれていない	出現位置	判定の理由
パッシベーション領域	含まれていない	出現位置なし	明細書中にパッシベーション領域に関する記載が見当たらないため
少なくとも一つの伝導性ボンドパッド領域	含まれている	0015, 0016	「ゲートパッド電極９が設けられ、ボンディングワイヤ等によりリードフレームのゲート端子Ｇに接続して電極の取り出しを行う」などの記載があるため
少なくとも第二のダイを受容するサイズの広い伝導性領域	含まれている	0015, 0016	「制御用ＩＣ４は、その基板の電位がＧＮＤになるように設計され、ＭＯＳＦＥＴ１のソース電極２上に導電性接着剤６により直接固着されている」などの記載があるため
第一のダイを具備する半導体デバイス	含まれている	0014, 0015, 0016	「ＭＯＳＦＥＴ１は、出力用トランジスタであり、その中に多数のＮチャネル型ＭＯＳトランジスタのセルを設けた実動作領域を有する」などの記載があるため

この表に基づいて、対象特許の内容について、指示された判定対象の記載内容が含まれているかを判定しました。パッシベーション領域に関する記載は含まれていないものの、他の構成要素については明細書中に記載が見られます。

• claude-3-sonnet-20240229

構成要素	含まれている/含まれていない	出現位置	判定の理由
パッシベーション領域	含まれている	段落[0017], [0019]	明細書の段落[0017]と[0019]に、表面保護膜となる絶縁層3がポリイミドまたは窒化膜などで形成されていることが記載されており、これがパッシベーション領域に相当する。
少なくとも一つの伝導性ボンドパッド領域	含まれている	段落[0015], [0016]	段落[0015]にゲートパッド電極9、段落[0016]に制御用IC4の制御端子がボンディングワイヤ7で接続されることが記載されており、これらがボンドパッド領域に相当する。
少なくとも第二のダイを受容するサイズの広い伝導性領域	含まれている	段落[0015], [0016]	段落[0015]にMOSFET 1のソース電極2が記載されており、段落[0016]に制御用IC 4がソース電極2上に導電性接着剤6で固着されることが記載されている。したがってソース電極2が第二のダイ(制御用IC 4)を受容する広い伝導性領域に相当する。
第一のダイ	含まれている	段落[0015]	段落[0015]にMOSFET 1が記載されており、これが第一のダイに相当する。

• claude-3-opus-20240229

構成要素	含まれている/含まれていない	出現位置	判定の理由
パッシベーション領域	含まれている	【0014】【0017】	「絶縁層３は、ＭＯＳＦＥＴ１のソース電極２上に設けられたポリイミドまたは窒化膜などの表面保護膜であり」と記載されており、表面保護膜がパッシベーション領域に相当すると判断できるため。
少なくとも一つの伝導性ボンドパッド領域	含まれている	【0015】	「実動作領域の外部には、ＭＯＳトランジスタのセルのゲート電極と接続されるゲートパッド電極９が設けられ、ボンディングワイヤ等によりリードフレームのゲート端子Ｇに接続して電極の取り出しを行う。」と記載されており、ゲートパッド電極が伝導性ボンドパッド領域に相当すると判断できるため。
少なくとも第二のダイを受容するサイズの広い伝導性領域	含まれている	【0015】【0016】	「ソース電極２には制御用ＩＣ４の裏面が導電性接着剤６により固着される。」「制御用ＩＣ４は、その基板の電位がＧＮＤになるように設計され、ＭＯＳＦＥＴ１のソース電極２上に導電性接着剤６により直接固着されている。」と記載されており、ソース電極が第二のダイ（制御用IC）を受容するサイズの広い伝導性領域に相当すると判断できるため。
表面を有する第一のダイ	含まれている	【0014】【0015】	「ＭＯＳＦＥＴ１は、出力用トランジスタであり」「ＭＯＳＦＥＴ１のドレイン電極８はリードフレームのドレイン端子Ｄとなるヘッダーに固着し、パッケージ外部へ導出する。」と記載されており、MOSFET1が第一のダイに相当し、その表面にソース電極等の領域を有していると判断できるため。

• gemini-1.5-pro-latest

構成要素	含まれている/含まれていない	出現位置	判定の理由
パッシベーション領域	含まれている	段落番号0015, 0017, 0019, 0020, 0025	表面保護膜としてポリイミドや窒化膜が例示されており、これがパッシベーション領域に該当すると考えられるため。
少なくとも一つの伝導性ボンドパッド領域	含まれている	段落番号0015	ゲートパッド電極が明示されており、これが伝導性ボンドパッド領域に該当すると考えられるため。
少なくとも第二のダイを受容するサイズの広い伝導性領域	含まれている	段落番号0015	ソース電極が明示されており、これが第二のダイ（制御IC）を受容するサイズの広い伝導性領域に該当すると考えられるため。
第一のダイ	含まれている	段落番号0015	MOSFETが明示されており、これが第一のダイに該当すると考えられるため。
半導体デバイス	含まれている	段落番号0001	電源回路装置が明示されており、これが半導体デバイスに該当すると考えられるため。

• command-r

構成要素	含まれている/含まれていない	出現位置	判定の理由
パッシベーション領域	含まれていない	出現位置なし	明細書に「パッシベーション領域」という記載は含まれていない。
伝導性ボンドパッド領域	含まれている	[0015]-[0016], [0018]-[0019]	「ゲートパッド電極」が「伝導性ボンドパッド領域」に対応。 「ゲートパッド電極9が設けられ、ボンディングワイヤ等によりリードフレームのゲート端子Ｇに接続して電極の取り出しを行う」とあり、ゲートパッド電極が伝導性ボンドパッドとして機能していると判定。
第一のダイ	含まれている	[0014]-[0020]	「ＭＯＳＦＥＴ１」が「第一のダイ」に対応。半導体素子であり、ダイとして機能していると判定。
表面	含まれている	[0014]-[0020]	「ＭＯＳＦＥＴ１の表面」という記載があることから、第一のダイに表面が存在するものと判定。
パッシベーション領域を含む表面	含まれていない	出現位置なし	明細書に「パッシベーション領域を含む表面」という記載は含まれていない。
少なくとも一つの伝導性領域	含まれている	[0015]-[0016], [0018]-[0019]	「ソース電極2」が「少なくとも一つの伝導性領域」に対応。 「ソース電極2上に制御用ＩＣ４の裏面が導電性接着剤により固着される」とあり、ソース電極が伝導性領域として機能していると判定。
第二のダイを受容するサイズの広い伝導性領域	含まれている	[0014]-[0020]	「ＭＯＳＦＥＴ１のソース電極２上に制御用ＩＣ４の裏面が導電性接着剤により固着される」とあり、ソース電極が広い伝導性領域として機能し、第二のダイである制御用ＩＣ４を受容すると判定。

全体として、明細書には発明の実施形態として、複数のダイを積層した電源回路装置が記載されており、その構成要素が要求事項に記載の内容と対応していると判定した。

• command-r-plus

構成要素	含まれている/含まれていない	出現位置	判定の理由
パッシベーション領域	含まれている	[0015], [0017]	明細書の段落[0015]には、「ＭＯＳＦＥＴ１のソース電極２上に設けられたポリイミドまたは窒化膜などの表面保護膜」と記載されており、段落[0017]には、「絶縁層３は、ＭＯＳＦＥＴ１のソース電極２上に設けられたポリイミドまたは窒化膜などの表面保護膜」と記載されている。これらの「表面保護膜」は、一般的な半導体デバイスにおいてパッシベーション領域として知られるものに相当するため。
少なくとも一つの伝導性ボンドパッド領域	含まれていない	出現位置なし	明細書には、伝導性ボンドパッド領域に相当する構成要素は明記されていない。
少なくとも第二のダイを受容するサイズの広い伝導性領域	含まれている	[0015], [0016], [0017]	明細書の段落[0015]には、「ＭＯＳＦＥＴ１のソース電極２上に制御用ＩＣ４の裏面が導電性接着剤６により固着される」と記載されており、段落[0016]には、「制御用ＩＣ４裏面とＭＯＳＦＥＴ１表面が同電位となる」と記載されている。段落[0017]には、「制御用ＩＣ４とＭＯＳＦＥＴ１がＡｇペースト又は半田等の導電性接着材６により直接固着されている」と記載されている。これらの記載から、制御用ＩＣ４を固着するための広い伝導性領域が存在することが示唆されているため。

審査官が引用していない他分野の文献ケース

「含まれていない」が正解。

• gpt-4-0125-preview

構成要素	含まれている/含まれていない	出現位置	判定の理由
パッシベーション領域	含まれていない	出現位置なし	対象特許は半導体デバイスに関するものではなく、幹細胞の製造方法に関するものであるため、パッシベーション領域に関する記載は含まれていない。
少なくとも一つの伝導性ボンドパッド領域	含まれていない	出現位置なし	対象特許は半導体デバイスに関するものではなく、幹細胞の製造方法に関するものであるため、伝導性ボンドパッド領域に関する記載は含まれていない。
少なくとも第二のダイを受容するサイズの広い伝導性領域	含まれていない	出現位置なし	対象特許は半導体デバイスに関するものではなく、幹細胞の製造方法に関するものであるため、伝導性領域に関する記載は含まれていない。
第一のダイ	含まれていない	出現位置なし	対象特許は半導体デバイスに関するものではなく、幹細胞の製造方法に関するものであるため、ダイに関する記載は含まれていない。

対象特許は、半導体デバイスではなく、幹細胞の製造方法に関するものであるため、判定対象の記載内容に関する記述は含まれていません。したがって、パッシベーション領域、伝導性ボンドパッド領域、伝導性領域、およびダイに関する記載は含まれていないと判定されます。

• claude-3-sonnet-20240229

以下のように構成要素ごとに判定します。

構成要素	含まれている/含まれていない	出現位置	判定の理由
パッシベーション領域	含まれていない	出現位置なし	明細書中に記載がない。
少なくとも一つの伝導性ボンドパッド領域	含まれていない	出現位置なし	明細書中に記載がない。
少なくとも第二のダイを受容するサイズの広い伝導性領域	含まれていない	出現位置なし	明細書中に記載がない。
第一のダイを具備する半導体デバイス	含まれていない	出現位置なし	明細書は幹細胞の培養方法に関するものであり、半導体デバイスについての記載はない。

この特許は幹細胞の培養方法に関するものですので、半導体デバイスの構成要素は含まれていないと判断されます。

• claude-3-opus-20240229

以下の表に、判定結果を示します。

構成要素	含まれている/含まれていない	出現位置	判定の理由
パッシベーション領域	含まれていない	出現位置なし	明細書中にパッシベーション領域に関する記載が見当たらない
少なくとも一つの伝導性ボンドパッド領域	含まれていない	出現位置なし	明細書中に伝導性ボンドパッド領域に関する記載が見当たらない
少なくとも第二のダイを受容するサイズの広い伝導性領域	含まれていない	出現位置なし	明細書中に第二のダイを受容するサイズの広い伝導性領域に関する記載が見当たらない
表面を有する第一のダイ	含まれていない	出現位置なし	明細書中に第一のダイに関する記載が見当たらない
半導体デバイス	含まれていない	出現位置なし	明細書中に半導体デバイスに関する記載が見当たらない

• gemini-1.5-pro-latest

構成要素	含まれている/含まれていない	出現位置	判定の理由
パッシベーション領域	含まれていない	出現位置なし	明細書および図面において、パッシベーション領域に関する記載は確認できませんでした。
少なくとも一つの伝導性ボンドパッド領域	含まれていない	出現位置なし	明細書および図面において、伝導性ボンドパッド領域に関する記載は確認できませんでした。
少なくとも第二のダイを受容するサイズの広い伝導性領域	含まれていない	出現位置なし	明細書および図面において、第二のダイや伝導性領域に関する記載は確認できませんでした。
第一のダイ	含まれていない	出現位置なし	明細書および図面において、ダイに関する記載は確認できませんでした。
半導体デバイス	含まれていない	出現位置なし	明細書および図面において、半導体デバイスに関する記載は確認できませんでした。

対象特許は、アテロコラーゲンを含有する足場材料を用いた幹細胞の製造方法に関するものであり、半導体デバイスの構成要素に関する記載は確認できませんでした。

• command-r

構成要素	含まれている/含まれていない	出現位置	判定の理由
パッシベーション領域	含まれている	[明細書] 多能性幹細胞の製造方法 など	本文中に「パッシベーション」という用語は登場しないが、多能性幹細胞の製造方法、あるいは、多能性幹細胞の増殖方法が記載されており、多能性幹細胞の製造・増殖に関連する記載であることから、パッシベーション領域が含まれていると判定した。
伝導性ボンドパッド領域	含まれている	[明細書] アテロコラーゲン など	本文中に「伝導性ボンドパッド」という用語は登場しないが、アテロコラーゲンに関する記載が複数登場しており、アテロコラーゲンは伝導性物質であることから、伝導性ボンドパッド領域が含まれていると判定した。
第二のダイを受容するサイズの広い伝導性領域	含まれている	[明細書] マイクロキャリア など	本文中に「第二のダイ」や「サイズ」という用語は登場しないが、マイクロキャリアに関する記載が複数登場しており、マイクロキャリアは複数の細胞を受容するサイズであることから、第二のダイを受容するサイズの広い伝導性領域が含まれていると判定した。

• command-r-plus

構成要素	含まれている/含まれていない	出現位置	判定の理由
パッシベーション領域	含まれている	[0015], [0016], [0017], [0018], [0019], [0020], [0021], [0022], [0023], [0024], [0025], [0026], [0027], [0028], [0029], [0030], [0031], [0032], [0033], [0034], [0035], [0036], [0037], [0038], [0039], [0040], [0041], [0042], [0043], [0044], [0045], [0046], [0047], [0048], [0049], [0050], [0051], [0052], [0053], [0054], [0055], [0056], [0057], [0058], [0059], [0060], [0061], [0062], [0063], [0064], [0065], [0066], [0067], [0068], [0069], [0070], [0071], [0072], [0073], [0074], [0075], [0076], [0077], [0078], [0079], [0080], [0081], [0082], [0083], [0084], [0085], [0086], [0087], [0088], [0089], [0090], [0091], [0092], [0093], [0094], [0095], [0096], [0097], [0098], [0099], [0100], [0101], [0102], [0103], [0104], [0105], [0106], [0107], [0108], [0109], [0110], [0111], [0112], [0113], [0114], [0115], [0116], [0117], [0118], [0119], [0120], [0121], [0122], [0123], [0124], [0125], [0126], [0127], [0128], [0129], [0130], [0131], [0132], [0133], [0134], [0135], [0136], [0137], [0138], [0139], [0140], ... (省略) ... [0646], [0647], [0648], [0649], [0650], [0651], [0652], [0653], [0654], [0655], [0656], [0657], [0658], [0659], [0660], [0661], [0662], [0663], [0664], [0665], [0666], [0667], [0668], [0669], [0670], [0671], [0672], [0673], [0674],

最後に

今回の検証の評価方法では、Command R, Command R+の日本語での精度はGPT4, Claude3 Sonnetより適合率の観点で芳しくありませんでした。 特にCommand R+は含まれていないものを含まれていないと判定する能力が弱そうです。

ただ、これはGPT,Claude3,CommandR+で同じプロンプトで検証しており、Command R, Command R+向けにプロンプトエンジニアリングをすれば改善する可能性があります。 また、Command R, Command R+は、他のLLMとは異なり、BingチャットのようなAIが生成した結果はどの文献のどの箇所に基づいたかという引用元・参照元を合わせて生成させるようなRAG特化の機能もあります。

https://docs.cohere.com/docs/retrieval-augmented-generation-rag

今後はこの機能を活用したり、Command R+向けのプロンプトエンジニアリングなどをして、有用性を検証してみたいと思います。

Gemini 1.5 Pro APIを使って特許引用文献段落抽出の再現率を検証してみた

はじめに

本日、2024/3/27に Gemini 1.5 Pro APIのアクセスが付与されました。

Gemini 1.5 Proとは、2024/2/15にGoogleが発表した最大で1Mトークン(100万トークン)を処理可能で、コストが低く、精度が良いとされる大規模言語モデルです。

先日、以下の記事にて、GPT, Claude3, Gemini別に審査官による特許引用文献段落の再現率の検証を行いましたので、 早速、同一データ・同一条件でGemini 1.5 Proで精度比較検証してみました。

blog.createfield.com

テスト対象

先日と同様、以下の引用文献の条件を満たす過去の特許文献を100件抽出しました。

• 拒絶理由通知引用(審査官による引用)がある
• 請求項1のみでXカテゴリーで引用されている（単⼀の⽂献のみで発明の新規性⼜は進歩性がないと判定されたもの）
• 特許公開公報
• 引用している文献の記載箇所の段落数が1-5以内（あまりに範囲が広いとピンポイントで記載箇所を正しく抽出できているかを評価できないため）
• 図面を引用していない
• 引用している明細書が5万文字以下

再現率検証手順

APIを使って各モデルに、テスト対象の特許文献のトップクレームの技術構成要素が引用文献のどの段落に記載されているかを生成してもらい、以下の3つの観点で再現率を評価しました。 なお、今回、段落一致再現率は、必ずしも審査官が引用した段落と完全に同一の段落でなくても周辺の記載内容でも十分正しい引用と考えられるため、前後±2の周辺段落でも正解と取り扱っています。

• 記載有無再現率: 段落の一致までは問わず、少なくとも審査官が引用した文献のどこかに一致する記載があることをAIが正しく抽出できている割合
• 部分一致再現率(1引用段落±2): 審査官が引用した文献の段落と±2の範囲で一致する段落を、AIが少なくとも1つ正しく抽出できている割合
• 全一致再現率(全引用段落±2): 審査官が引用した全ての段落のうち、AIが±2の範囲で一致する段落を正しく抽出できている割合

再現率性能評価結果

モデル	ベンダー	記載有無再現率	部分一致再現率(1引用段落±2)	全一致再現率(全引用段落±2)
gpt-4-0125-preview	OpenAI	89%	52%	38.16%
gpt-3.5-turbo-0125	OpenAI	42%	18%	12.72%
gemini-1.0-pro	Google	70%	15%	8.77%
gemini-1.5-pro	Google	95%	64%	48.68%
claude-3-opus-20240229	Anthropic	96%	72%	56.14%
claude-3-sonnet-20240229	Anthropic	93%	70%	58.33%
claude-3-haiku-20240307	Anthropic	85%	49%	42.98%

大規模言語モデル別 特許引用文献段落抽出 再現率比較

この精度検証では、Gemini 1.5 Proは、Claude 3 Sonnetまではいかないものの、GPT4 Turboを上回るパフォーマンスを見せました。

コスト vs 再現率のパフォーマンス

コストの正式な発表はまだですが、以下の記事によるとGemini 1.5 ProはGemini 1.0 Proと似たようなものとなるとのことですので、 横軸を部分一致再現率、縦軸をコストとすると以下のようなグラフになります。

https://mspoweruser.com/gemini-1-5-could-be-20x-cheaper-than-gpt4/

We can reasonably expect that pricing for 1.5 Pro should be similar to 1.0 Pro. Pricing for 1.0 Pro is $0.000125 / 1K characters.
—
Compare that to $0.01 / 1K tokens for GPT4-Turbo. Rule of thumb is about 4 characters / token, so that’s $0.0005 for 1.5 Pro vs $0.01 for GPT-4, or a 20x difference in Gemini’s favor.
—
So Google will be providing a model that is arguably superior to GPT4 overall at a price similar to GPT-3.5.
—
If OpenAI isn’t able to respond with a better and/or more efficient model soon Google will own the API market, and that is OpenAI’s main revenue stream.

コストがGemini 1.0 Proと同等と想定すると、Claude 3 Haikuよりも精度がだいぶよく、コストが抑えられていることがわかります。

2024/4/2料金発表があり、$7/1M, $21/1Mとわかりました。Claude3 Sonnetより高いみたいですね。

Gemini API の料金  |  Google AI for Developers

最後に

今回の検証では、Gemini 1.5 Proは以前のGemini 1.0 Proよりは随分使えそうなことがわかりました。

Gemini 1.5 Proは、GPT4 Turbo 128K, Claude 3 200Kに対し、1Mトークンという長大なコンテキスト長もあるので、 この精度でコストもだいぶ抑えられるとするとかなり使い勝手のいいものになるかもしれません。

ただ現在のAPIのレート制限は、1 分あたり 2 クエリ、1 日あたり 1, 000 クエリしかないので、サービスに組み込んでユーザーに提供するのはもう少し先になりそうです。 https://ai.google.dev/models/gemini?hl=ja#model-variations

GPT3.5、GPT4がだいぶ世代遅れ感がでてきましたが、この数ヶ月でOpenAIがどういうモデルを出してくるか楽しみですね。

ChatGPT, Claude3, Gemini別に審査官による特許引用文献段落抽出の再現率を検証してみた

はじめに

近年、ChatGPT、Claude、Geminiなどの大規模言語モデルの性能が向上しています。 今回、過去の特許審査で引用された特許文献の記載箇所・段落を、これらのモデルがどの程度正確に抽出できるかを検証しました。

テスト対象

以下の引用文献の条件を満たす過去の特許文献を100件抽出しました。

• 拒絶理由通知引用(審査官による引用)がある
• 請求項1のみでXカテゴリーで引用されている（単⼀の⽂献のみで発明の新規性⼜は進歩性がないと判定されたもの）
• 特許公開公報
• 引用している文献の記載箇所の段落数が1-5以内（あまりに範囲が広いとピンポイントで記載箇所を正しく抽出できているかを評価できないため）
• 図面を引用していない
• 引用している明細書が5万文字以下

再現率検証手順

APIを使って各モデルに、テスト対象の特許文献のトップクレームの技術構成要素が引用文献のどの段落に記載されているかを生成してもらい、以下の3つの観点で再現率を評価しました。 なお、今回、段落一致再現率は、必ずしも審査官が引用した段落と完全に同一の段落でなくても周辺の記載内容でも十分正しい引用と考えられるため、前後±2の周辺段落でも正解と取り扱っています。

• 記載有無再現率: 段落の一致までは問わず、少なくとも審査官が引用した文献のどこかに一致する記載があることをAIが正しく抽出できている割合
• 部分一致再現率(1引用段落±2): 審査官が引用した文献の段落と±2の範囲で一致する段落を、AIが少なくとも1つ正しく抽出できている割合
• 全一致再現率(全引用段落±2): 審査官が引用した全ての段落のうち、AIが±2の範囲で一致する段落を正しく抽出できている割合

再現率性能評価結果

モデル	ベンダー	記載有無再現率	部分一致再現率(1引用段落±2)	全一致再現率(全引用段落±2)
gpt-4-0125-preview	OpenAI	89%	52%	38.16%
gpt-3.5-turbo-0125	OpenAI	42%	18%	12.72%
gemini-1.0-pro	Google	70%	15%	8.77%
claude-3-opus-20240229	Anthropic	96%	72%	56.14%
claude-3-sonnet-20240229	Anthropic	93%	70%	58.33%
claude-3-haiku-20240307	Anthropic	85%	49%	42.98%

大規模言語モデル別 特許引用文献段落抽出 再現率比較

検証の結果、claude-3-opus-20240229が最も高い再現率を示し、人の審査官が引用した段落と少なくとも1つは7割以上の精度で一致させることができました。 また、Sonnetモデルもopusとほぼ同等の結果を残しています。さらに、GPT3.5Turboよりも低コストのHaikuモデルでも、比較的良好な性能を示しています。 Claude3シリーズは、Haikuでも思ったよりも複雑なタスクでも頑張ってくれそうですね。

審査官による引用文献の記載段落は1例であり他の段落でも一致させられることを勘案すると、 Claude3 Opus/Sonnet、GPT4は十分、参考に利用できる程度の精度を示していると感じられます。

最後に

現時点で、特許のクレームという抽象的な表現と、特許明細書の記載内容の一致がこのレベルでできるようになっていることは、 今後、大規模言語モデルの更なる改善により、特許審査における引用文献の抽出をはじめ様々な特許調査業務の自動化が期待できます。

特許検索・分析プラットフォームPatentfieldでは、上記のような大規模言語モデル・生成AIを組みわせたサービスを開発しており、 2024/3/22(金)に生成AIサービスを活用した特許査読支援の新サービスに関する発表を行います。

申し込み期限は3/20(水)までとなりましたが、もしご興味ございましたら、オンラインでも参加可能なのでご参加ください。

https://prtimes.jp/main/html/rd/p/000000045.000025380.html

おまけ: 出力サンプル例

審査官による拒絶理由と各モデルの実際の出力例は以下のようなものになります。

• 審査官による拒絶理由

　下記引用文献１には、「本発明の電源回路装置は、ＭＯＳＦＥＴ１と、制御Ｉ Ｃ４と、絶縁層３とから構成される。」（［００１４］）、「制御用ＩＣ４は、 その基板の電位がＧＮＤになるように設計され、ＭＯＳＦＥＴ１のソース電極２ 上に導電性接着剤６により直接固着されている。ＭＯＳＦＥＴ１の表面、つまり ソース電極２はＮチャネル型の場合その電位はＧＮＤであるので、制御用ＩＣ４ 裏面とＭＯＳＦＥＴ１表面が同電位となる。また、制御用ＩＣ４表面の他の制御 端子はボンディングワイヤ７によりＭＯＳＦＥＴ１のゲートパッド電極９、また はリード端子と固着され、外部へ導出される。」（［００１６］）、「絶縁層３ は、ＭＯＳＦＥＴ１のソース電極２上に設けられたポリイミドまたは窒化膜など の表面保護膜であり、制御用ＩＣ４との固着部分は開口され、ＭＯＳＦＥＴ１の ゲート端子Ｇおよびソース端子Ｓへの電極の取り出し部も開口される。」（［０ ０１７］）、等と記載されている。 　本願の請求項１に係る発明と、引用文献１に記載された発明とを比較すると、 両者に実質的な構成上の差異は認められない。

• claude-3-opus-20240229

以下の表に、判定対象の構成要素ごとに、[対象特許]の明細書中に含まれているか否かを判定した結果を示します。

構成要素	判定結果	出現位置	判定の理由
第一のダイを具備する半導体デバイス	含まれている	[0014], [0015], [0018], [0019]	明細書には、MOSFET1と制御IC4を重ね合わせた半導体デバイスが記載されている。MOSFET1が第一のダイに相当する。
第一のダイは表面を有する	含まれている	[0015], [0018], [0019], [0020]	明細書には、MOSFET1の表面（ソース電極2）が記載されている。
表面はパッシベーション領域を含む	含まれている	[0017]	明細書には、MOSFET1の表面に絶縁層3（ポリイミドまたは窒化膜などの表面保護膜）が設けられていることが記載されている。この絶縁層3がパッシベーション領域に相当する。
表面は少なくとも一つの伝導性ボンドパッド領域を含む	含まれている	[0015]	明細書には、MOSFET1の表面の実動作領域の外部にゲートパッド電極9が設けられていることが記載されている。このゲートパッド電極9が伝導性ボンドパッド領域に相当する。
表面は少なくとも第二のダイを受容するサイズの広い伝導性領域を含む	含まれている	[0015], [0016], [0018], [0019]	明細書には、MOSFET1の表面のソース電極2上に制御IC4が導電性接着剤6により固着されることが記載されている。このソース電極2が第二のダイ（制御IC4）を受容するサイズの広い伝導性領域に相当する。

[0014], [0015], [0016], [0017], [0018], [0019], [0020]

• claude-3-sonnet-20240229

構成要素の分解と判定結果は以下の通りです。

構成要素	判定	出現位置	判定の理由
パッシベーション領域	含まれている	0015, 0017	絶縁層3がパッシベーション領域に相当する。
少なくとも一つの伝導性ボンドパッド領域	含まれている	0015, 0016	ゲートパッド電極9が伝導性ボンドパッド領域に相当する。
少なくとも第二のダイを受容するサイズの広い伝導性領域	含まれている	0015, 0016	ソース電極2が広い伝導性領域に相当し、制御用IC4を受容している。
第一のダイ	含まれている	0015	MOSFET 1が第一のダイに相当する。
半導体デバイス	含まれている	0014-0019, 0022-0025	電源回路装置が半導体デバイスに相当する。

出現位置の配列: 0014, 0015, 0016, 0017, 0019, 0022, 0023, 0024, 0025

本発明の電源回路装置は、MOSFET 1(第一のダイ)上にソース電極2(広い伝導性領域)、ゲートパッド電極9(伝導性ボンドパッド領域)、絶縁層3(パッシベーション領域)を有し、ソース電極2上に制御用IC 4(第二のダイ)を固着する構造を開示している。このように、全ての構成要素が明細書に記載されている。

• claude-3-haiku-20240307

以下の表形式で判定結果を出力します。

• 構成要素: パッシベーション領域
• [含まれている]
• [出現位置: 段落[0017]]

• [判定の理由: 明細書には「絶縁層３は、ＭＯＳＦＥＴ１のソース電極２上に設けられたポリイミドまたは窒化膜などの表面保護膜であり」と記載されており、パッシベーション領域に相当する構成が含まれている。]

• 構成要素: 少なくとも一つの伝導性ボンドパッド領域

• [含まれている]
• [出現位置: 段落[0015]]

• [判定の理由: 明細書には「ＭＯＳＦＥＴ１のゲートパッド電極９が設けられ、ボンディングワイヤ等によりリードフレームのゲート端子Ｇに接続して電極の取り出しを行う」と記載されており、伝導性ボンドパッド領域に相当する構成が含まれている。]

• 構成要素: 少なくとも第二のダイを受容するサイズの広い伝導性領域

• [含まれていない]
• [出現位置: 出現位置なし]

• [判定の理由: 明細書には、第二のダイを受容するサイズの広い伝導性領域に相当する構成は記載されていない。]

• 構成要素: 第一のダイ

• [含まれている]
• [出現位置: 段落[0014], [0015], [0016]]
• [判定の理由: 明細書には「ＭＯＳＦＥＴ１は、出力用トランジスタであり、その中に多数のＮチャネル型ＭＯＳトランジスタのセルを設けた実動作領域を有する」と記載されており、第一のダイに相当する構成が含まれている。]

出現位置の数字の配列: 0017, 0015

• gpt-4-0125-preview

構成要素	含まれている/含まれていない	出現位置	判定の理由
パッシベーション領域	含まれていない	出現位置なし	明細書中にパッシベーション領域に関する記載が見当たらないため
少なくとも一つの伝導性ボンドパッド領域	含まれている	0015, 0016	「ゲートパッド電極９」が伝導性ボンドパッド領域に該当すると考えられるため
少なくとも第二のダイを受容するサイズの広い伝導性領域	含まれている	0015, 0016	「ソース電極２」が第二のダイ（制御用IC4）を受容するサイズの広い伝導性領域に該当すると考えられるため
第一のダイを具備する半導体デバイス	含まれている	0014, 0015, 0016	「ＭＯＳＦＥＴ１」と「制御用ＩＣ４」がそれぞれ第一のダイと第二のダイに該当し、これらが半導体デバイスの構成要素として記載されているため

出現位置の配列: 0015, 0016

約2.5億画像の類似特許・意匠図面検索を開発しました

特許検索・分析サービス Patentfieldでは、これまで文書で特許を類似検索できる機能を提供してきましたが、今回、新たに日本、アメリカ、ヨーロッパ、台湾の特許・意匠の全図面、約2.5億枚の画像に対しても類似検索が可能になりました。

この機能により、例えば自動運転技術の特許図面を検索して、類似する技術の特許を図面から簡単に見つけ出すことができます。 https://prtimes.jp/main/html/rd/p/000000043.000025380.html

類似画像検索に用いた技術

類似画像検索を作るには、画像データを特徴量に変換する必要があります。 今回利用したものは、Swin Transformer v2という技術を用いました。 https://arxiv.org/abs/2111.09883

Swin Transformerは昨今、大規模言語モデル等自然言語処理分野で大きな成果が得られているTransformer技術を画像に適用したVision Transformer系の技術です。

これまで画像解析で主流だったCNN系の技術よりも左向きや右向きの違いや部分的な一致など図面全体では違っても比較的似た概念の特徴が捉えられている傾向があります。（まだまだ完全ではありませんが。）

Swin Transformer v2を使ってImageNetと呼ばれる大規模なカラー画像で事前学習させられたオープンソースのモデルを基に、独自にグレースケール入力に特化するようネットワークを修正し、特許図面および意匠図面をGPUを使って大量に転移学習させました。

今回、画像特徴量は1024次元であり、そのままだと2.5億枚の画像を特徴量抽出すると約1TiB近くのデータ量になります。 このデータを高速に検索でき、且つ、 既存データベースの検索・集計などの操作を組み合わせてできるようにFaissという近似近傍探索用のライブラリを検索エンジンGroongaに組み込んでいます。 これにより文書や画像など、様々な特徴量をオンディスクで検索でき、柔軟性の高いデータベース操作を実現しています。

また、類似画像検索は複数画像の同時入力もサポートしています。外観図+内部構造や、意匠の6面図単位での類似画像検索も可能です。

https://support.patentfield.com/portal/ja/kb/articles/%E9%A1%9E%E4%BC%BC%E7%94%BB%E5%83%8F%E6%A4%9C%E7%B4%A2

終わりに

今回、意匠図面でなく、日本、アメリカ、ヨーロッパ、台湾の電子化されている全特許図面を類似検索できるようになりましたので、特許調査時に文書だけでなく図面からも効率的に情報を得られます。具体的には、新製品の開発において競合する特許を早期に発見したり、研究段階での新技術の特許可能性を調査する際に役立ちます。また、意匠の先行調査を特許図面にも広げて調べられたりすることを期待しています。

創業して5年が経ちます。そして入籍しました。

私が特許事務所で働いていたときに業務時間外に個人的に開発していた特許検索データベースを元に2017年4月に正式サービスhttps://patentfield.comをローンチし、2017年4月20日に京都でPatentfield株式会社を立ち上げてから5年が経ちます。

2017年4月に立ち上げた後、2018年11月に特許情報フェア出展してからは特許情報ベンダとして認知されるようになり、企業知財部、研究開発部を中心に様々な企業に導入・利用していただけるようになりました。 2020年〜2021年はコロナ渦の中も、徐々に企業へのサービス導入が進みつつも、特許情報での情報検索・言語処理を活用したサービス開発成果から大手企業から言語処理・機械学習関連の開発なども相談いただくようにもなりました。 2020年以降社員制度の整備をすすめ、コーポレート部門、営業部門、開発部門の組織体制を構築し、2021年度は十分な売上成長と黒字を達成することができました。投資家、取引先、役員、社員、その他弊社事業に関係していただいたすべての方々に感謝いたします。

2022年度は、これまでに培ってきたサービス運営と技術開発の知見を活かし、より日本の特許・技術情報、知財を活用できる社会にできるよう、特許情報・知財情報サービスの機能強化、新規開発を進めてまいります。また、個人的に特許事務所時代に行っていたオープンソースや技術コミュニティでの活動やIT技術情報発信なども再開していければと考えています。

そして、最後に私事ですが、2022年1月15日に入籍いたしました。 会社、個人ともに引き続き邁進してまいりますのでよろしくお願いします。

Gitブランチの総滞在時間を使ってタスク毎の総作業時間を計算する

はじめに

開発現場ではRedmineやBacklogなどチケット管理システムを使ってタスク管理することがよくあると思います。

ただ、一挙手一投足で作業時間をタイマーで図るといったことは手間ですし、そういったルールには不満もでるかと思います。

そこで、タスクの作業実績時間を管理するために、極力新たな手間をかけずに時間を計算できないかと検討したところ、Gitのブランチの滞在時間=タスク時間とざっくりみなすのはどうかと考えました。

私の感覚では、Gitのコミット単位ですと粒度的には細かすぎますが、Gitのブランチとチケットであれば、対応づけるのにちょうどいいサイズかなという感覚です。

ローカル単位ですので、レビュアーのチェック時間もこれで推定することができそうです。

運用ルール

Gitコマンドではreflogを使うことによってチェックアウトのブランチ移動時間を取得することができますので、新たに時間計測ツール等を導入しなくとも、以下を運用ルールとすれば、ざっくりとしたタスク毎の作業時間の計測が可能になります。

• タスク単位でブランチを切って、タスク作業中はブランチに滞在すること
• 日を跨ぐ作業など、作業から長時間離れる場合はmasterや一時的に子ブランチを作って作業ブランチから移動すること

１点目は、タスク単位でブランチを切るのはチーム開発では、普通に行われることだと思いますので、さほど適用にハードルはなさそうです。

２点目は、作業ブランチにいる=作業中であるということを意識づけることにより、メリハリがつくメリットがありそうです（かもしれません）。

ただ、今の所、ちょっとした離席などは、あまり厳密にやりすぎないほうがいいのかなと考えています。

ブランチの総滞在時間計算スクリプト

上記のような運用ルールを守ってブランチに滞在するようにしておけば、例えば、Gitコマンドのreflogから以下のスクリプトのようにブランチ毎の総滞在時間を簡単に計算することができます。

#!/bin/bash

# License: Public domain.
# You can copy and modify this script freely.

reflog=$(git reflog --date=iso --pretty='%gd %gs' --date=format:'%Y-%m-%d %H:%M:%S' | grep checkout:)

branch_times=""
branch_dates=""
last_line=""
while read line
do
  if [ "$last_line" != "" ]; then
    set ${line}

    datetime="$(echo ${1} | cut -b 7-16) $(echo ${2} | cut -b 1-8)"
    from=${6}
    to=${8}

    set ${last_line}
    last_datetime="$(echo ${1} | cut -b 7-16) $(echo ${2} | cut -b 1-8)"
    last_from=${6}
    last_to=${8}

    if [ $last_from = $to ] && [ $to != "master" ]; then
      last_date="$(echo ${last_datetime} | cut -b 1-10)"
      if [ "$(uname)" == 'Darwin' ]; then
        elapsed_sec=$(expr `date -j -f "%Y-%m-%d %H:%M:%S" "${last_datetime}" +%s` - `date -j -f "%Y-%m-%d %H:%M:%S" "${datetime}" +%s`)
      else
        elapsed_sec=$(expr `date -d"${last_datetime}" +%s` - `date -d"${datetime}" +%s`)
      fi
      elapsed_hour="$(awk "BEGIN {print ${elapsed_sec}/3600}")"
      branch_times="${branch_times} ${to} ${elapsed_hour}"
      branch_dates="${branch_dates} ${to} ${last_date}"
    fi
  fi
  last_line=${line}
done < <(echo "$reflog")

if [ "${branch_times}" != "" ]; then
read -d '' scriptVar << EOF
BEGIN {
  times_length = split("${branch_times}", times, " ");
  split("${branch_dates}", dates, " ");
  split("", counter);
  for (i = times_length; i > 0; i--) {
    if (i % 2 == 0) {
      counter[times[i-1]] += times[i];
      branches[dates[i-1]] = dates[i];
    }
  }
  for (i in counter) {
    print branches[i]" "i" "counter[i]
  }
}
EOF
fi

awk "$scriptVar" | sort

% bash  git_branch_time_calc.sh
...
2020-08-17 work-group-default 1.59944
2020-08-24 excel-macro 2.71694
...

git reflogの保持期間

git reflogの保持期間はデフォルトでは、90日となっています。 以下のコマンドを設定しておけば、個別設定がなければ無制限とすることも可能です。

git config --global gc.reflogExpire never

長時間離席時

長時間離席時は以下のように、作業ブランチの子ブランチを作って移動するか、コミットしておいてmasterに戻っておくようにします。

#作業中断時
git checkout -b tmp

#作業再開時
git checkout work-branch && git branch -D tmp

#作業中断時
git add ./*
Git commit -m "tmp"
Git checkout master

#作業再開時
Git checkout work-branch
Git reset HEAD^

特許データで学習させたSpherical Text Embeddingの結果を眺める

はじめに

これは、情報検索・検索エンジン Advent Calendar 2019 の 22日目の記事です。

かなり遅れてしまいましたが、Advent Calendar 2019の記事を書きます。

意味的に類似するドキュメントを検索するために活用される技術の１つとして、Word Embeddingがあります。 今回は、Word Embedding系の技術で最近提案されたSpherical Text Embedding - JoSE(Joint Spherical Embedding)を特許データで試してみます。

• 論文

https://arxiv.org/pdf/1911.01196.pdf

• スライド

https://yumeng5.github.io/files/Spherical-Text-Embedding.pdf

Spherical Text Embedding について

Spherical Text Embeddingは、周囲の単語だけでなく、段落/文書全体とも意味的に一貫しているべきという理論にもとづき、球面埋め込み空間を利用して学習して、単語、文書の分散表現を得る手法のようです。

以下は、論文中より単語類似度の精度比較です。Word2VecやfastTextより精度が良い結果が得られているそうです。

Spherical Text Embedding https://arxiv.org/pdf/1911.01196.pdf より抜粋

学習時間も早くリーズナブルそうです。

Spherical Text Embedding https://arxiv.org/pdf/1911.01196.pdf より抜粋

GitHubに実装が公開されています。文ベクトルの出力オプションもありそうです。

github.com

$ ./src/jose
Parameters:
        -train <file> (mandatory argument)
                Use text data from <file> to train the model
        -word-output <file>
                Use <file> to save the resulting word vectors
        -context-output <file>
                Use <file> to save the resulting word context vectors
        -doc-output <file>
                Use <file> to save the resulting document vectors
        -size <int>
                Set size of word vectors; default is 100
        -window <int>
                Set max skip length between words; default is 5
        -sample <float>
                Set threshold for occurrence of words. Those that appear with higher frequency in the
                training data will be randomly down-sampled; default is 1e-3, useful range is (0, 1e-3)
        -negative <int>
                Number of negative examples; default is 2
        -threads <int>
                Use <int> threads; default is 20
        -margin <float>
                Margin used in loss function to separate positive samples from negative samples; default is 0.15
        -iter <int>
                Run more training iterations; default is 10
        -min-count <int>
                This will discard words that appear less than <int> times; default is 5
        -alpha <float>
                Set the starting learning rate; default is 0.04
        -debug <int>
                Set the debug mode (default = 2 = more info during training)
        -save-vocab <file>
                The vocabulary will be saved to <file>
        -read-vocab <file>
                The vocabulary will be read from <file>, not constructed from the training data
        -load-emb <file>
                The pretrained embeddings will be read from <file>

Examples:
./jose -train text.txt -word-output jose.txt -size 100 -margin 0.15 -window 5 -sample 1e-3 -negative 2 -iter 10

試行結果

30万件約20GBの特許データで学習させてみました。

単語ベクトルの類似結果を見てみます。

query: 自動車
---
('乗用車', 0.8404606580734253), 
('車両', 0.8378781080245972), 
('車輌', 0.7979249358177185), 
('自動二輪車', 0.7885137796401978), 
('自転車', 0.782609224319458), 
('オートバイ', 0.7789096236228943), 
('航空機', 0.7780036330223083), 
('電気自動車', 0.7770860195159912),
('二輪車', 0.7740814685821533),
('乗り物', 0.7717453837394714),
('車載', 0.7691519260406494),
('鉄道車両', 0.7605024576187134), 
('乗物', 0.7498664855957031)
...
]

query: プリンタ
----
[
('印刷装置', 0.8641186952590942),
('画像形成装置', 0.8083310723304749),
('印刷', 0.7867810726165771),
('プリント', 0.7860059142112732),
('MFP', 0.7771070599555969),
('画像形成', 0.7665582895278931),
('複写機', 0.7597976922988892),
('インクジエツト記録装置', 0.7596516609191895),
('画像形成部', 0.7595673203468323),
('スキヤナ', 0.7568787932395935),
...
]

query:  レーザ
[
('レーザ光', 0.7883974313735962),
('レーザビーム', 0.7772529721260071),
('フアイバーレーザ', 0.7631707191467285),
('CO2レーザ', 0.7576791048049927),
('レーザー装置', 0.7439086437225342),
('レーザー光', 0.7391970753669739),
('レーザービーム', 0.7351175546646118),
...
]

query: 携帯電話
-----
[
('スマートフオン', 0.9211865663528442),
('携帯情報端末', 0.8552143573760986),
('携帯電話機', 0.8257875442504883),
('テレビ', 0.8204030990600586),
('タブレツト端末', 0.8194489479064941),
('ノートパソコン', 0.8147341012954712),
('タブレツトPC', 0.8041720986366272),
('携帯', 0.7919098138809204),
('スマートウオツチ', 0.7867792844772339),
('スマートホン', 0.7841475009918213), 
...
]

[
query: アルコール
----
('グリセリン', 0.7986409664154053),
('エタノール', 0.7715713977813721),
('脂肪酸', 0.7600075006484985),
('エステル', 0.7566314935684204),
('エーテル', 0.7565040588378906),
('脂肪族アルコール', 0.7549535036087036),
('プロピレングリコール', 0.7479276061058044),
('多価アルコール', 0.7424640655517578),
('アルキルエーテル', 0.7266831994056702),
...
]

単語ベクトルとしては、それなりの結果がでているように見えますが、過去に試した他のWord embeddingsに比べると、感覚的には、若干いまいちのように感じます。（試したときの学習量の違いかもしれません）

また、文書ベクトルの類似結果を見てみます。今回は何も考えず、全文を入力させています。なお、特許の全文はかなり長いです。

query: 自動車 要約 課題 ポート噴射弁 筒内噴射弁 燃料 供給 する 燃料供給装置 振動 大きく なつ 音 発生 する の 抑制 する 解決 手段 燃料供給装置 燃料タンク 燃料タンク 燃料 ポート噴射弁 接続 さ れ 通路 供給 する ポンプ 通路 設け られ 逆止弁 通路 逆止弁 ポート噴射弁 側 燃料 加圧 し 筒内噴射弁 接続 さ れ 通路 供給 する ポンプ 有する ポート噴射弁 供給 する 燃料 燃圧 目標 燃圧 なる よう ポンプ 制御 する エンジン 運転開始時 目標 燃圧 所定 燃圧 設定 し その後 エンジン 回転数 燃料供給装置 共振 領域 外 なつ とき 目標 燃圧 所定 燃圧 低い 所定 燃圧 切り替える 選択 図 図3
----
0.8253768086433411, 自動車 要約 課題 エンジン ポート噴射弁 筒内噴射弁 燃料 供給 する 燃料供給装置 振動 し 音 発生 する の 抑制 する 解決 手段 燃料供給装置 燃料タンク 燃料タンク 燃料 ポート噴射弁 接続 さ れ 通路 供給 する ポンプ 通路 設け られ 逆止弁 通路 逆止弁 ポート噴射弁 側 燃料 加圧 し 筒内噴射弁 接続 さ れ 通路 供給 する ポンプ 有する ポート噴射弁 供給 する 燃料 目標 燃圧 基づく 目標回転数 ポンプ 回転 する よう ポンプ 制御 する もの 目標 燃圧 低下 応じ ポート噴射弁 供給 する 燃料 燃圧 ポート 側 燃圧 低下 し いる 際 ポート 側 燃圧 脈動 程度 所定 程度 以上 とき 所定 程度 未満 とき 目標回転数 大きく する 選択 図 図3...
0.8230206966400146,  ハイブリツド自動車 要約 課題 粒子状物質除去フイルタ 再生 行なう 機会 多く する 解決 手段 排気 系 粒子状物質 除去 する 粒子状物質除去フイルタ 有する エンジン 走行 用 >動力 出力 する モータ 所定 車速 未満 エンジン 間欠 運転 許可 し 運転者 要求 する 要求 パワー 走行 する よう エンジン モータ 制御 する 制御装置 備える ハイブリツド自動 車 粒子状物質除去フイルタ 粒子状物質 堆積量 堆積量 以上 推定 し とき 車速 所定 車速 小さい 所定 車速 以上 所定 車速 未満 状態 所定 時間 継続 し とき エンジン 間欠 運>転 禁止 する 選択 図 図2
0.8182553648948669, 車両用制御装置 要約 課題 モータ 温度 許容上限温度 超える こと 抑制 し モータ 走行 走行 する 機会 多く する 解決 手段 エンジン 停止 さ れ モータ 回転数 所定回転数 以下 モータ 出力 さ れる トルク 所定トルク 以上 状態 時間 以上 経過 し とき モータ モータ ロツク状態 判定 し 時間 長い 時間 以内 モータ モータ ロツク状態 判定 さ れ 回数 所定 回数 以上 なつ とき エンジン 始動 する これ モータ 温度 許容上限温度 超える こと 抑制 し モータ 走行 走行 する 機会 多く する こと できる 選択 図 図4 ...

query: プリンタ 要約 課題 同じ プリンタメカ 形成 さ れ 幅 異なる 記録 紙 対応 し プリンタ 各々 記録 紙 印刷 さ れ いる 黒 マーク 検出 する こと できる プリンタ 提供 する 解>決 手段 印字ヘツド 記録 紙 印字 なさ れる プリンタ 搬送 さ れる 前記 記録 紙 案内 する ガイド 前記 記録 紙 検出 する センサ 前記 センサ 実装 さ れる 基板 有し 前記 ガイド 前記 センサ 露出 さ せる ため 複数 穴 設け られ おり...
----
0.762130081653595,  電子機器 要約 課題 コスト プリント基板上 回路素子 発生 さ せる ノイズ 伝搬 効果 的 抑える こと できる 電子機器 提供 する 解決 手段 表面 グラウンドパターン 形成 さ れ プリント基板 プリント基板 表面 対向 する よう 配置 さ れる シールド部材 備える シールド部材 グラウンドパターン 対向 し プリント基板 側 突出 し 帯状 領域 有し 当該 帯>状 領域 内 設け られ 複数 ねじ 穴 それぞれ 通る ねじ プリント基板 締結 さ れ シールド部材
0.7610459327697754, 画像形成装置 要約 課題 発光素子 受光素子 迷光 抑制 し 発光素子 受光素子 配置 自由度 高める こと 目的 する 解決 手段 光センサ 被検知領域 光 出射 する 発光素子 被検知領域 反射 さ れ 光 受光 する 受光素子 被検知領域 拡散反射 さ れ 光 受光 する 受光素子 素子 設け られる 基板 備える 基板 被検知領域 対向 する 面 当該 面 被検知領域 反対 側 面 B 面 面 B 貫通 する 貫通 部 C 有する 素子 うち 2つ 素子 基板 面 配置 さ れ...
0.7596758604049683.  プリント 基板接続構造 要約 課題 実装 面積 極小 し プリント基板 間 任意 トポロジ 安定 接続 する こと できる プリント 基板接続構造 提供 する 解決 手段 プリント 基板接続構造 接触 型 コネクタ 接触 型 コネクタ 挟ん 配置 さ れ 接触 型 コネクタ 接続 さ れる プリント基板 接触 型 コネクタ 挿入 さ れ 接触 型 コネクタ 高さ 対応 する 厚み 有>する フレーム 有し いる 選択 図 図1 請求項 接触 型 コネクタ 前記 接触 型 コネクタ 挟ん 配置 さ れ 前記 接触 型 コネクタ 接続 さ れる プリント基板 前記 接触 型 コネクタ 挿入 さ れ 前記 接触 型 コネクタ 高さ 対応 する 厚み 有する フレーム 有する プリント 基板接続構造 請求項 前記 フレーム 

多少の類似性はとれていそうですが、長文として特徴を捉えられているかというと微妙な感じですね。もう少し検証が必要そうです。

おわりに

今回は時間がなかったのでテスト的に30万件20GBのデータで試しましたが、今後、1000万件以上、600GB以上の全特許データに適用させて、もうちょっとちゃんとした検証をしたいと思います。 現在、その他には、BERTの特徴量抽出ベースでの類似検索も検討しています。

検証して精度が出るようであれば、今後、私が個人で開発し、事業化した自社サービス https://patentfield.com に適用していきます。

弊社のPatentfieldのサービスでは、全文検索エンジンにGroongaを採用しており、ベクトル検索エンジンや機械学習エンジンも独自に内部に組み込んで、大量のデータであっても全てをメモリに乗せる必要なく、高速且つ柔軟に検索に組み合わせて利用できるようにしています。

Patentfieldでは、創業から3期が経過し、顧客法人数100社を超え、売上もだいぶ立ち上がってきました。来年はさらに加速度的に大きくしていきます。弊社での開発に興味があれば、お気軽にご連絡下さい。

お問合せ・お申込み | Patentfield