CreateField Blog

オープンソースを使って個人でWebサービスを開発・運営していたブログ

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

おまけ: 出力サンプル例

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

  • 審査官による拒絶理由

 下記引用文献1には、「本発明の電源回路装置は、MOSFET1と、制御I C4と、絶縁層3とから構成される。」([0014])、「制御用IC4は、 その基板の電位がGNDになるように設計され、MOSFET1のソース電極2 上に導電性接着剤6により直接固着されている。MOSFET1の表面、つまり ソース電極2はNチャネル型の場合その電位はGNDであるので、制御用IC4 裏面とMOSFET1表面が同電位となる。また、制御用IC4表面の他の制御 端子はボンディングワイヤ7によりMOSFET1のゲートパッド電極9、また はリード端子と固着され、外部へ導出される。」([0016])、「絶縁層3 は、MOSFET1のソース電極2上に設けられたポリイミドまたは窒化膜など の表面保護膜であり、制御用IC4との固着部分は開口され、MOSFET1の ゲート端子Gおよびソース端子Sへの電極の取り出し部も開口される。」([0 017])、等と記載されている。  本願の請求項1に係る発明と、引用文献1に記載された発明とを比較すると、 両者に実質的な構成上の差異は認められない。

  • 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]]
  • [判定の理由: 明細書には「絶縁層3は、MOSFET1のソース電極2上に設けられたポリイミドまたは窒化膜などの表面保護膜であり」と記載されており、パッシベーション領域に相当する構成が含まれている。]

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

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

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

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

  • 構成要素: 第一のダイ

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

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

  • gpt-4-0125-preview
構成要素 含まれている/含まれていない 出現位置 判定の理由
パッシベーション領域 含まれていない 出現位置なし 明細書中にパッシベーション領域に関する記載が見当たらないため
少なくとも一つの伝導性ボンドパッド領域 含まれている 0015, 0016 「ゲートパッド電極9」が伝導性ボンドパッド領域に該当すると考えられるため
少なくとも第二のダイを受容するサイズの広い伝導性領域 含まれている 0015, 0016 「ソース電極2」が第二のダイ(制御用IC4)を受容するサイズの広い伝導性領域に該当すると考えられるため
第一のダイを具備する半導体デバイス 含まれている 0014, 0015, 0016 「MOSFET1」と「制御用IC4」がそれぞれ第一のダイと第二のダイに該当し、これらが半導体デバイスの構成要素として記載されているため

出現位置の配列: 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日に入籍いたしました。 会社、個人ともに引き続き邁進してまいりますのでよろしくお願いします。 f:id:naoa_y:20220405202022j:plain

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

はじめに

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

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

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

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

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

運用ルール

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

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

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

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

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

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

上記のような運用ルールを守ってブランチに滞在するようにしておけば、例えば、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の記事を書きます。

意味的に類似するドキュメントを検索するために活用される技術の1つとして、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より精度が良い結果が得られているそうです。

f:id:naoa_y:20191224213003p:plain
Spherical Text Embedding https://arxiv.org/pdf/1911.01196.pdf より抜粋

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

f:id:naoa_y:20191225122227p:plain
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

HerokuでWordPressを動かす方法

はじめに

WordPressはずいぶん前から流行っているPHP製のCMSで、ちょっとしたコーポレートサイトやブログサイトを非技術者でもある程度管理しやすいように作るにはいまだに便利です。

ただ、Ruby on RailsなどモダンなWeb開発手法に慣れていると、FTPでデプロイとかサーバー上のファイルを直接更新みたいなことはできるだけしたくないもんです。

2018年2月現在で、さくっとHerokuで動かせてGitHubで管理できるWordPress開発環境を構築する方法をまとめておきます。

なお、以下はmacOS Sierraでの作業手順です。

使えそうなものを探す

何事も何かを実装する前には、まず、GitHubで、最近の環境で、参考にできそうなもの、利用できそうなものを探します。

下記のものがよさげなので、こちらを使って作業を開始します。

GitHub - PhilippHeuer/wordpress-heroku: This project is a template for installing and running WordPress 4.9.x on Heroku.

WordPressをモダンな開発環境でいい感じにできる Bedrockっていうものがあるんだ、ふーんって思っておきます。

roots.io

ローカル開発環境構築

  • Composerのインストール
brew install homebrew/php/composer
  • MySQLのインストール
brew install mysql
mysql.server start
mysql_secure_installation # 適当にrootのパスワードを設定などする
sudo ln -s /usr/local/opt/mysql/homebrew.mxcl.mysql.plist /Library/LaunchAgents/
  • Redisのインストール
brew install redis
 ln -sfv /usr/local/opt/redis/*.plist ~/Library/LaunchAgents
 launchctl load ~/Library/LaunchAgents/homebrew.mxcl.redis.plist

基本的に以下を見てやればいいだけです。

https://github.com/PhilippHeuer/wordpress-heroku/wiki/Deployment

git clone https://github.com/PhilippHeuer/wordpress-heroku
cd wordpress-heroku
composer install
mysql -uroot -p

some_databaseは適当に変えます。

mysql > create database `some_database`;

https://roots.io/salts.htmlEnv Formatのキーをコピーして、.envというファイルに以下を設定します。 passwordsome_databaseは、適当に変えます。

# DB Connection
CUSTOM_DB_URL=mysql://root:password@127.0.0.1:3306/some_database

# Redis
REDIS_URL='redis://127.0.0.1:6379'

# WP Settings
WP_ENV=development
WP_HOME=http://localhost:8080
WP_SITEURL=${WP_HOME}/wp

# Generate your keys here: https://roots.io/salts.html
AUTH_KEY='generateme'
SECURE_AUTH_KEY='generateme'
LOGGED_IN_KEY='generateme'
NONCE_KEY='generateme'
AUTH_SALT='generateme'
SECURE_AUTH_SALT='generateme'
LOGGED_IN_SALT='generateme'
NONCE_SALT='generateme'
  • 起動

macOSでは80番ポート使うのにroot権限が必要そうだったので8080で立ち上げます。

php wp-cli.phar server --host=0.0.0.0 --port=8080 --path=web

http://localhost:8080にアクセスして、適当にサイト名やパスワードを入れるとローカルでwordpressの画面にアクセスできるようになります。

Herokuにデプロイ

Herokuのアプリを作成します。ダッシュボードからでも良いです。

heroku create ${APP_NAME}

上記と同じようにhttps://roots.io/salts.htmlからキーをコピーして、herokuの環境変数に設定します。

heroku config:set \
AUTH_KEY='generateme' \
SECURE_AUTH_KEY=''generateme \
LOGGED_IN_KEY='generateme' \
NONCE_KEY='generateme' \
AUTH_SALT='generateme' \
SECURE_AUTH_SALT='generateme' \
LOGGED_IN_SALT='generateme' \
NONCE_SALT='generateme' \
--app ${APP_NAME}

アドオンを追加していきます。

heroku addons:create sendgrid:starter --app ${APP_NAME}
heroku addons:create scheduler:standard --app ${APP_NAME}
heroku config:set DISABLE_WP_CRON='true' --app ${APP_NAME}
heroku addons:open scheduler --app ${APP_NAME}
heroku addons:create jawsdb:kitefin --app ${APP_NAME}
heroku addons:create papertrail:choklad --app ${APP_NAME}
heroku addons:create heroku-redis:hobby-dev --app ${APP_NAME}

Herokuのファイルシステムではdynoが再起動されると、更新されたファイルが消えます。そのため、画像などのメディアは、Amazon S3のクラウドストレージにアップロードさせます。S3へのアクセス権限を持つアクセスキーをAWS_S3_URLの環境変数に指定します。

AWS_S3_URLは、s3://${アクセスキー}:${シークレットキー}@s3-${リージョン}.amazonaws.com/${バケット名}の形式を想定しているようです。

2018年2月1日現在のソースでは、シークレットキーにスラッシュが含まれている場合、parseに失敗したので、例えば、 https://github.com/PhilippHeuer/wordpress-heroku/pull/27/files のようにして回避しました。*1

heroku config:set \
AWS_S3_URL='s3://${アクセスキー}:${シークレットキー}@s3-${リージョン}.amazonaws.com/${バケット名}' \
--app ${APP_NAME}

これでHeroku側の設定は終わったので、gitのremoteに登録してプッシュすれば、デプロイは完了です。

heroku git:remote -a ${APP_NAME}
git push heroku master

後は、https://${APP_NAME}.herokuapp.com/ にアクセスして、初期インストールすれば、データベースが構築されます。

この状態だとcloneしてきた元のリポジトリのままなので、適当に自分たちのアプリ用に管理しやすいように整えてGitHub管理しましょう。

あと、composerがとても遅いので以下などを参考にして整えたほうがいいと思います。

qiita.com

最後に

次はプラグインあさったり、独自テーマを作ったりしていこうと思います。

ところで、私は、知的財産の商業化に関するスタートアップ IP Nexus(https://www.ipnexus.com)に関連するプロジェクトや特許の検索・分析プラットフォーム(https://patentfield.com)の開発などをしています。

今回のようなWebっぽいことからデータベース、検索、言語処理や機械学習などオールラウンドにしていますが、もっと検索、言語処理や機械学習などの方の作業の比重を大きくしたいです。

ということで、Web開発を手伝ってくれる人がいたら嬉しいです。データ分析や機械学習の方に興味があるという方でも有りです。ただし、現状、Web開発の比重の方がかなり大きいです。

興味があれば、Twitter(@naoa_y)かメール(naoya at patentfield.com)までご連絡ください。

*1:なお、今思うとS3が独自ドメインだとパースできない気がしますが、まあ必要になったら適宜対応すればよさそうという感じです。

JSでWebに注釈をつけるAnnotatorで専用のサーバープログラムを使わなくてもannotationを保存、復元する方法

Webページにコメントなどの注釈をつけることができるJavascriptのライブラリannotatorがあります。

こちらの注釈の保存は、基本的には以下のPython製のバックエンドを利用することが想定されています。

https://github.com/openannotation/annotator-store

他には、ブラウザのローカルストレージに保存するプラグインもあります。 https://github.com/aron/annotator.offline.js

しかし、別サーバーを立てて管理はしたくなく、自前のWebサーバーでユーザーごとに紐付けて管理したいことがあると思います。

以下のようにannotationCreatedイベントのannotationからhighlightsのDOMを除外してどこかに保存し、@annotator.loadAnnotations(annotations)すれば、annotationを復元できそうだなぁってところまで調査しました。

    Annotator.Plugin.StoreLogger = (element) ->
      pluginInit: ->
        annotation = Cookies.get("annotator_test")
        if annotation?
          annotation = JSON.parse(annotation)
          @annotator.loadAnnotations([annotation])
        @annotator.subscribe('annotationCreated', (annotation) ->
          storable = jQuery.extend({}, annotation)
          delete storable.highlights
          Cookies.set("annotator_test", JSON.stringify(storable))
          console.info 'The annotation: %o has just been created!', annotation
        ).subscribe('annotationUpdated', (annotation) ->
          console.info 'The annotation: %o has just been updated!', annotation
        ).subscribe 'annotationDeleted', (annotation) ->
          console.info 'The annotation: %o has just been deleted!', annotation

    content = $('.target').annotator()
    content.annotator('addPlugin', 'StoreLogger')

後は適当に調整して、RailsにCRUD生やせば、ユーザーごとのannotationを管理できそうです。

が、デザインの変更やコンテンツの変更などでDOMがずれるとannotationを復元できなそうなので、今のところ、採用は見合わせることにしました。

一応のメモ書きで残しておきます。