TadaoYamaokaの開発日記

個人開発しているスマホアプリや将棋AIの開発ネタを中心に書いていきます。

将棋AIの進捗 その32(MCTSの探索にAND/OR木を導入する)

dlshogi コンピュータ将棋 MCTS

Leela Chess Zeroの状況を定期的にウォッチしないとなと思って、issueを眺めていたら"Exact-Win Strategy for Overcoming AlphaZero" #799という投稿がされていた。
Leela Zeroのissue#2276にも同様の投稿がある。
ざっくり説明すると、子ノードが勝ちの場合、そのノードを再度探索しないという探索のアイディアである。

元の論文「Exact-Win Strategy for Overcoming AlphaZero」では、この方法によりLeela Zeroのオリジナルに対して61%の勝率になると報告されている。

元の論文は有料だが、Leela Zeroのissueに抜粋が掲載されている。
f:id:TadaoYamaoka:20190810094745p:plain

要約すると、

  1. 子ノードに1つでも確定した勝ち(囲碁の場合2回のパス)、負け、引き分けがあると、そのノードは選択しない。
  2. 子ノードに1つでも確定した負けがあると、その親ノードを勝ちとマークする。すべての子ノードが勝ちの場合、負けとマークする。すべて引き分けの場合、引き分けとしてマークする。

ということだ。

MCTSの探索に、負けが確定した局面を探索しないという枝刈りと、AND/OR木による詰み探索を導入するアイディアと解釈できる。

dlshogiでは、MCTSの探索中に短手数(7手)の詰み探索を導入している。
終盤では勝敗が確定するノードが現れやすいため、この探索の導入には効果があると思われる。
例えば、ノードが8手詰みの局面で、子ノードに詰み探索に勝ちが確定した局面あったとしても無駄な探索を行ってしまう。
この方法によって探索が効率化できる。
また、8手以上の詰みでも、探索によりAND/OR木を成長できるので、MCTSでも確実な詰みの判断ができる。

dlshogiでは、すでに詰み探索を導入しているため、論文のノードに確定した勝ち負けをマークするという部分はすでに実装されているため、論文の探索方法を容易に実装できるため、試してみた。

次のような10手詰め(後手負け)の局面で、
f:id:TadaoYamaoka:20190810210934p:plain
sfen lnS+N5/6Gg1/p1pp+R3p/4ppS2/1p1sk4/2P1LlP2/PP1P1+p2P/1KGS2+b2/LN1r1+n2+b w G4P 96

試したところ、探索の改良前は、3秒の探索で、27483ノードの探索して評価値-2956だったが、改良後は、230ノードの探索で詰み(負け)が確定できた。

終盤では、このような局面がゲーム木の途中に多数現れるため、探索の効率化につながると予測できる。

実際に勝率に効果が表れるかは、別途連続対局で効果を確認したい。

なお、Leela Zeroでは、勝敗が確定する局面はそれほど多くないという理由で保留されている。
Leela Chess Zeroは、効果を検証中のようだ。

2019/8/12追記

技巧2と1手3秒で100回対局して勝率を比較した。

勝敗数 勝率 信頼区間(95%)
改善前 35勝61負4分 36% 46.4%～27.5%
改善後 38勝58負9分 41% 52.0%～32.2%

勝率は高くなっているが、信頼区間95%では強くなったとは言えなそうだ。
さらに対局数を増やして確認する必要がある。

信頼区間の計算方法
import math
def UCB(X, N, Z):
    return (X+Z*Z/2+Z*math.sqrt(X*(N-X)/N+Z*Z/4))/(N+Z*Z)
def LCB(X, N, Z):
    return (X+Z*Z/2-Z*math.sqrt(X*(N-X)/N+Z*Z/4))/(N+Z*Z)
UCB(35, 100-4, 1.96)
LCB(35, 100-4, 1.96)
UCB(38, 100-9, 1.96)
LCB(38, 100-9, 1.96)

参考：Wilson score interval を使う。 - 中野智文のブログ

AlphaStarについて

AlphaStar

次回の技術書典に、参加している強化学習の勉強会のメンバで合同誌として頒布を行うべく執筆を行っている。
自分は、ネタとしてAlphaStarについて選んだのだが、書く内容がまとまらないのでブログにもアウトプットすることにする。

AlphaStarについて

Google DeepMindが開発した、StarCraft IIで初めて人間のトッププロに5-0で勝利したAI。

StarCraft IIについて

StarCraft IIは、ブリザード・エンターテイメントが開発した1対1で対戦を行うリアルタイムストラテジー(RTS)ゲーム。
日本語版が発売されていないため、日本ではあまり知名度が高くないが、海外（欧米、アジア）ではeスポーツ大会が開かれるくらい人気*1。
f:id:TadaoYamaoka:20190804150945p:plain

AlphaStarの技術情報

現時点では、まだ論文は公開されていないが、査読付き論文誌に向けて準備されている*2。

現時点での情報源

AlphaStarのブレークスルー

従来のAIの課題

従来のAIは、以下のような課題に対処できなかった。

  • じゃんけんのような単一の戦略がないゲーム
  • 不完全情報（部分観測）
  • 長期的なプランニング
  • リアルタイム
  • 広い行動空間

StarCraftを、これらの課題に対処するためのAI研究の「グランドチャレンジ」と位置づけた。
ブリザードの協力のもとオープンソースのStarCraftの学習環境PySC2(人間のゲームのリプレイを含む)をリリースした。
AlphaStarは、そこでの研究からの複数のブレークスルーを組み合わせることによって生み出された。
f:id:TadaoYamaoka:20190804150427p:plain

AlphaStarのアーキテクチャ

（ゲーム画面ではなく）ゲームの内部情報（ユニットリストとそれらのプロパティ）を入力として受け取り、行動（一連の命令）を出力する。
f:id:TadaoYamaoka:20190804154718p:plain

ニューラルネットワークの構成

以下の要素を組み合わせている。

一つ一つの詳細を理解するには、論文を読み込む必要がある。
f:id:TadaoYamaoka:20190804150322p:plain

エージェントの学習アルゴリズム

はじめに匿名の人間のリプレイデータから、基本的なミクロ戦略とマクロ戦略を模倣した。
それにより、ゲームに実装されている"エリート"レベルAI（人間のゴールドレベル相当）に95%勝つようになった。

その後、マルチエージェント強化学習により訓練する。
マルチエージェントをリーグ戦で戦わせて、自分とは異なるエージェントから学べるようにする。
既存のエージェントから分岐して新しいエージェントが動的にリーグに追加される。
population-based trainingとmulti-agent reinforcement learningのアイディアを取り入れている。

リーグが進み新しいエージェントが作成されるとそれに対抗する新しい戦略が出現する。
いくつかの新しいエージェントが単に前の戦略を改良した戦略を実行する一方で、他のものは全く新しいビルドオーダー、ユニット構成、およびマイクロ管理計画からなる劇的に新しい戦略を発見する。
f:id:TadaoYamaoka:20190804162129p:plain

リーグの多様性を促進するために、各エージェントは個別の学習目標を持っている。
あるエージェントは特定の敵を倒すという目的を持っているが、他のあるエージェントは全体的に戦いを行い、別のエージェントはユニットの建築を行う。
f:id:TadaoYamaoka:20190804154001p:plain

パラメータの更新

ニューラルネットワークの重みは他のエージェントとの対戦から、強化学習によって更新され、自分自身の学習目標を最適化する。
重み更新則は、以下のアルゴリズムを使用する。

訓練環境

訓練は、分散環境で行われ、何千ものエージェントが並列で訓練された。
リーグは、エージェントにつきTPU v3を16個使用して、14日間行われた。
実時間では 200年に相当する。
最後のエージェントは、リーグのナッシュ分布（最も効果的な戦略の組み合わせ）の構成要素により選ばれた。
対戦は1GPUのデスクトップPCで行われた。


引用されている、それぞれの論文を理解するとなるとかなり大変そうです。
技術書典までには間に合いそうにもないので、上記の内容を肉付けして執筆することにします。
AlphaStarと同様にRTSで成果を出しているOpenAI Five(詳細、Model Architecture)は、5対5の対戦に対応しています。
ユニットを埋め込み表現にしたり、LSTMを使ったり共通点はありますが、学習則はAlphaStarとは異なっておりそちらも気になっています。

*1:eSportsアジア競技大会競技選出で注目度アップ！ 『StarCraft』シリーズの楽しみ方指南 | Alienware Zone | PCゲーム＆eスポーツで勝ち抜くためのメディア

*2:AlphaStar: Mastering the real-time strategy game StarCraft II | DeepMind

Visual Studioを使わずにNuGetのパッケージを検索する

.NET Core NuGet

Microsoft系のプログラミング言語では、NuGetを使用するとパッケージインストールが楽にできる。
しかし、NuGetは基本的にVisual Studioから使うことが前提になっている。
.NET Coreは、Visual Studioを前提としていないため、Visual Studio使わずにNuGetの管理ができるとよい(特に、MacOSやLinuxで使う場合)。
プロジェクトへのパッケージの追加は、「dotnet add package」で可能だが、ここのissueを見ると現時点でVisual Studioを使わずにコマンドラインからNuGetのパッケージを検索する方法は提供されていないようだ。

パッケージを検索する方法が他に方法がないか探したところ、「dotnet-search」という.NET Core 2.1に対応したツールが見つかった。
GitHub - billpratt/dotnet-search: Search for Nuget packages using the .NET Core CLI.
これを使えば、MacOSやLinuxでも使用できる。

「dotnet tool install」を使用してインストールすることで、コマンドラインから「dotnet search」コマンドを使用できるようになる。
（dotnet tool installは.NET core グローバル ツールをインストールするコマンド）

インストール
>dotnet tool install --global dotnet-search
使用例
>dotnet search Grpc

結果

Name                    Description                 Authors            Version   Downloads   Verified
_____________________________________________________________________________________________________
Grpc                    Metapackage for gRPC C#     The gRPC Authors   1.22.0    1.60M          *
-----------------------------------------------------------------------------------------------------
Grpc.Core               C# implementation of        The gRPC Authors   1.22.0    3.98M          *
                        gRPC based on native
                        gRPC C-core library.
-----------------------------------------------------------------------------------------------------
Grpc.Auth               gRPC C#                     The gRPC Authors   1.22.0    1.75M          *
                        Authentication
                        Library
-----------------------------------------------------------------------------------------------------
Grpc.Core.Api           gRPC C# Surface API         The gRPC Authors   1.22.0    578.60K        *
-----------------------------------------------------------------------------------------------------
Grpc.Tools              gRPC and Protocol           The gRPC Authors   1.22.0    1.33M          *
                        Buffer compiler for
                        managed C# and
                        native C++ projects.
                         Add this package to
                        a project that
                        contains .proto
                        files to be compiled
                        to code. It contains
                        the compilers,
                        include files and
                        project system
                        integration for gRPC
                        and Protocol buffer
                        service description
                        files necessary to
                        build them on
                        Windows, Linux and
                        MacOS. Managed
                        runtime is supplied
                        separately in the
                        Grpc.Core package.
-----------------------------------------------------------------------------------------------------
Grpc.HealthCheck        gRPC C# Health              The gRPC Authors   1.22.0    185.71K        *
                        Checking (for
                        Grpc.Core)
-----------------------------------------------------------------------------------------------------
Grpc.Reflection         gRPC C# Server              The gRPC Authors   1.22.0    170.65K        *
                        Reflection (for
                        Grpc.Core)
-----------------------------------------------------------------------------------------------------
Grpc.Core.Testing       Miscellaneous code          The gRPC Authors   1.22.0    68.49K         *
                        for testing
                        Grpc.Core
-----------------------------------------------------------------------------------------------------
Grpc.Core.NativeDebug   Debug symbols for           The gRPC Authors   1.22.0    4.35K          *
                        the native library
                        contained in
                        Grpc.Core
-----------------------------------------------------------------------------------------------------
Bond.Grpc.CSharp        This package                Microsoft          8.1.0     18.35K
                        contains bindings
                        for using Bond with
                        gRPC. The
                        Bond-generated gRPC
                        code depends on
                        types in this
                        assembly.
                        Bond is an open
                        source,
                        cross-platform
                        framework for
                        working with
                        schematized data. It
                        supports
                        cross-language
                        serialization/deserialization
                        and powerful generic
                        mechanisms for
                        efficiently
                        manipulating data.
                                 Bond is
                        published on GitHub
                        at
                        https://github.com/Microsoft/bond/
                                   The C#
                        documentation is
                        available at
                        https://microsoft.github.io/bond/manual/bond_cs.html                                            

1 - 10 of 113 results

gRPCでC#とPythonを連携する

gRPC C# Python

C#のプログラムから機械学習などの処理をPythonで実装したい場合がある。
C#とPythonの連携方法について調べたところいくつか方法があったが、gRPCが良さそうだったので試してみた。

調べた方法

Python for .NET

C#とPythonを直接連携させるには、「Python for .NET」があるが、リリースされているバージョンは最新のPythonと.NETのバージョンに追従できていないようなので、自分でビルドが必要になる（.NET Coreで動かそうと試したがうまくいかずあきらめた）。

リダイレクト

プロセスをリダイレクトで連携するという方法もあるが、受け渡すデータの構造が複雑な場合、データのシリアライズとデシリアライズの処理の作りこみが必要になる。
また、C#から起動したPythonプログラムのデバッグが行いにくいという課題がある。

ソケット通信

ソケット通信で連携する場合は、Pythonのサーバプログラムをデバッガで起動することができるが、データのシリアライズとデシリアライズの処理の作りこみは必要になる。

RESTサービス

RESTサービスにして連携する場合は、バイナリデータをテキストで渡すためオーバヘッドが大きくなり、呼び出し頻度によってはパフォーマンスが課題になる。

gRPC

gRPCを使用した場合、これらの課題をすべて解消できる。

gRPCについて

gRPCは、Googleが標準化を主導しているHTTP/2をベースにしたオープンソースのRPCライブラリだ。
様々な言語に対応しており、C#とPythonにも対応している。
インターフェースは、protobufで定義する。

プログラミング言語で使用できる標準的なスカラ型、配列や構造体など複雑なデータ構造が定義できる。
シリアライズとデシリアライズのコードは、使用するプログラミング言語向けに自動生成されるため、自分で作りこむ必要がない。

サンプルプログラム

C#とPythonの連携を行うサンプルプログラムを作成した。
GitHub - TadaoYamaoka/gRPCSample

公式でC#とPythonそれぞれのサンプルが提供されており、C#のクライアントとPythonのサーバを連携しただけなので、詳細は公式の説明を参照。
https://grpc.io/docs/quickstart/csharp/
https://grpc.io/docs/quickstart/python/

C#側(gRPCSample)

C#側の.NETのバージョンは、.NET Core 2.1を使用した。
Visual Studioで.NET Coreのコンソールアプリを作成して、NuGetで、「Grpc」(gRPCのAPI)と「Grpc.Toos」(protocを含む)と「Google.Protobuf」(protobufに必要なクラス)を参照に追加する。
Visual Studioを使用しないでCLIから追加するには以下の通り実行する。

>dotnet add package Grpc
>dotnet add package Grpc.Tools
>dotnet add package Google.Protobuf

作成した.protoファイルをVisual Studioで、右クリックしてプロパティを表示して、Build Actionを「protobuf compiler」に設定すると、プロジェクトをビルドすると自動で.protoからC#コードが生成される。
namespaceやクラスのプロパティなどの先頭は大文字になるため注意が必要。

クライアントの処理は、Program.csに実装している。
ほぼ公式のサンプル通りのため説明は割愛。

Python側(PyServerSample)

Python向けgrpcはpipからインストールする。

>pip install grpcio
>pip install grpcio-tools

.protoからPythonコードの生成は、手動でコマンドを実行して生成した。

python -m grpc_tools.protoc -I../gRPCSample --python_out=. --grpc_python_out=. ../gRPCSample/Sample.proto

サーバの処理は、PyServerSample.pyに実装している。
ほぼ公式のサンプル通りのため説明を割愛。
max_workersで、スレッド数を指定できるが、PythonにはGILがあるため、並列化のパフォーマンスはあまり期待できそうにない。
並列化する場合は、マルチプロセス構成にして、負荷分散の仕組みを検討した方がよさそうだ（詳しくないがNginxでHTTP/2の負荷分散ができるようだ）。

2019/8/7 追記

.porotoから生成したクラスに、C#のオブジェクトから値を詰め込む際に、JavaでいうDozerのような機能が欲しくなる。
C#では、AutoMapperというライブラリがデファクトのようだ。
フィールド名が一致する場合は、自動でフィールドの値をコピーしてくれる。
ただし注意点がいくつかある。

名前規則

.protoで単語間をアンダーバーで区切っている場合、C#ではキャメルケースで区切る規則に変換される。
そのため、名前が一致せずコピーされなくなる。
その際は、以下のように設定すればよい。

    Mapper.Initialize(cfg =>
    {
      cfg.CreateMap<Class1, Class2>();
      cfg.SourceMemberNamingConvention = new LowerUnderscoreNamingConvention();
      cfg.DestinationMemberNamingConvention = new PascalCaseNamingConvention();
    });

参考：c# - Automapper naming convention with underscore/PascalCase properties - Stack Overflow

repeated

.porotoで、repeatedとして定義したフィールドは、readonoyのコレクションとして生成される。
そのため、値がコピーされない。
AfterMapでカスタマイズする必要がある。
例：https://gist.github.com/TadaoYamaoka/7791fcfe274b9bb2fc5a4318e2f4dd15

Visual Studio 2017に.NET Core 2.1を追加する

Visual Studio .NET Core

ほぼ自分用のメモです。

Visual Studio 2017がサポートしている.NET Coreのバージョンは2.1.508だが、先により新しいバージョン2.1.801をインストールしていたため、アンインストールしてから、Visual Studio Installerから「.NET Core クロスプラットフォームの開発」を追加したところ、.NET Coreのプロジェクトの作成はできるが、ターゲットフレームワークに.NET Core 2.1が表示されないという問題が起きた。

解決方法

こちらのissuesを見て解決できた。
DotNet SDK Found, DotNet.DLL not.... but its there · Issue #6180 · dotnet/sdk · GitHub

コマンドラインで

>dotnet --info

を実行すると、

Found dotnet SDK, but did not find dotnet.dll at [C:\Program Files\dotnet\sdk\2.1.801\dotnet.dll]

と表示される状態になっていた。

C:\Program Files\dotnet\sdk\2.1.801
はフォルダのみ残っていて中身は空になっていた。
アンインストーラで、完全にアンインストールができていなかったようだ。
2.1.801フォルダを削除すると、ターゲットフレームワークに表示されるようになった。

BERTで日本語の単語埋め込みを試す

BERT NLP Juman++

京都大学が公開している日本語のWikipediaから学習したBERTのモデルを使って、単語の埋め込みを試した。

Googleが公開しているBERTのextract_features.pyを使って、Juman++v2を使って文を分かち書きして入力すると、文中の単語の埋め込みベクトルが得られる。

以下に、手順と実行結果を示す。

Juman++v2のインストール

先日の記事を参照
Juman++v2をWindowsでビルドする - TadaoYamaokaの開発日記

BERTのソースclone

BERTのソースをgit cloneする。

git clone https://github.com/google-research/bert.git

事前学習済みモデルダウンロード

ku_bert_japanese - KUROHASHI-CHU-MURAWAKI LAB
Japanese_L-12_H-768_A-12_E-30_BPE.zipをダウンロードして、適当な場所に展開する。
以下では、BERTのソースディレクトリのmodelディレクトリに展開したとする。

入力文の作成

入力する文をテキストファイルに記述して、UTF-8で保存する。

sample.txt
機動戦士ガンダムは、サンライズ制作のロボットアニメです。
ザクは、ガンダムシリーズに登場するモビルスーツです。
赤い彗星はシャア専用ザクです。
彗星は、氷や塵などでできています。
赤いイチゴは甘い。

分かち書き

入力文をJuman++v2で分かち書きする。

jumanpp_v2 --config=H:\src\jumanpp-2.0.0-rc2\model\jumandic.conf --segment r:\sample.txt -o r:\sample_s.txt

以下のように分かち書きされる。

機動 戦士 ガンダム は 、 サンライズ 制作 の ロボット アニメ です 。
ザク は 、 ガンダム シリーズ に 登場 する モビルスーツ です 。
赤い 彗星 は シャア 専用 ザク です 。
彗星 は 、 氷 や 塵 など で できて い ます 。
赤い イチゴ は 甘い 。

BERTのソース修正

BERTのソースは、そのままでは日本語の単語が1文字になってしまうため、ここの説明の通りtokenization.pyを修正する。

# text = self._tokenize_chinese_chars(text)

文と単語の埋め込みベクトルを得る

BERTのextract_features.pyを使用して、分かち書きした入力文から、文と単語の埋め込みベクトルを得る。

python extract_features.py --input_file=r:\sampel_s.txt --output_file=r:\output.json --vocab_file=model\vocab.txt --bert_config_file=model\bert_config.json --init_checkpoint=model\bert_model.ckpt --do_lower_case=False --layers=-1

引数の--layers=-1で、最終の中間層のみ出力するようにしている。
この記事によると、最後から4層までのベクトルを連結した場合が、F値が最も高くなるようだが、とりあえず最終層のみとした。
f:id:TadaoYamaoka:20190728162020p:plain

出力結果は、引数の--output_fileで指定したパスにjson形式で保存される。

output.json
{"linex_index": 0, "features": [{"token": "[CLS]", "layers": [{"index": -1, "values": [-0.593731, 0.536862, 1.262189, ...
{"linex_index": 1, "features": [{"token": "[CLS]", "layers": [{"index": -1, "values": [-0.33602, -0.053047, 0.694587, ...
{"linex_index": 2, "features": [{"token": "[CLS]", "layers": [{"index": -1, "values": [1.365805, 0.30302, 0.562358, ...
{"linex_index": 3, "features": [{"token": "[CLS]", "layers": [{"index": -1, "values": [1.169213, -0.522374, -1.460554, ...
{"linex_index": 4, "features": [{"token": "[CLS]", "layers": [{"index": -1, "values": [0.952905, 1.600134, -1.115922, ...

単語の埋め込みベクトルを取り出す

出力されたjsonファイルを読み込む。

with open(r'r:\output.json', 'r') as f:
    lines = f.readlines()

objs = []
for l in lines:
    objs.append(json.loads(l))

変数objsに各行のjsonデータが格納される。

jsonデータから文中の単語と埋め込みベクトルを抽出する。

単語の確認

単語は、jsonデータのfeaturesの単語に対応する位置の['token']に格納されている。
単語の位置の0番目は必ず[CLS]になるため、1番から始まる。

objs[0]['features'][3]['token']

Out: 'ガンダム'
すべての文の各単語埋め込みベクトルを取得

埋め込みベクトルは、featuresの単語に対応する位置の['layers'][0]['values']に格納されている。

import numpy as np

words = []
for o in objs:
    dic = {}
    for feature in o['features']:
        token = feature['token']
        dic[token] = np.array(feature['layers'][0]['values'])
    words.append(dic)

変数wordsに各行の各単語の埋め込みベクトルが格納される。

埋め込みベクトルの表示
words[0]['ガンダム']

Out: array([-9.618200e-01,  3.335200e-02,  1.011132e+00, -6.614870e-01, ...

単語のコサイン類似度の比較

BERTで取得した単語の埋め込みベクトルを使用して、単語同士の類似度を計算する。

コサイン類似度の定義

コサイン類似度を計算する関数を定義する。

def cos_sim(v1, v2):
    return np.dot(v1, v2) / (np.linalg.norm(v1) * np.linalg.norm(v2))


以下に、いくつかの単語同士のコサイン類似度を計算した例を示す。

例1
cos_sim(words[0]['ガンダム'], words[1]['モビルスーツ'])
cos_sim(words[1]['ザク'], words[1]['モビルスーツ'])
cos_sim(words[0]['ロボット'], words[1]['モビルスーツ'])
cos_sim(words[4]['イチゴ'], words[1]['モビルスーツ'])

Out: 0.49544412522207004
Out: 0.5251044756373676
Out: 0.46859541657644055
Out: 0.15821825000954565

関連のある単語の類似度が高くなっている。

例2

BERTは文脈に依存した単語の意味を表現することができるので、同じ単語でも異なる文では埋め込みベクトルも異なる。

cos_sim(words[2]['彗星'], words[2]['シャア'])
cos_sim(words[3]['彗星'], words[2]['シャア'])

Out: 0.45199096516452764
Out: 0.2708140096663009

(0番から数えて)2番目の文の「彗星」の方が期待通り「シャア」と関連が高くなっている。

例3

単語の埋め込みベクトルの演算を試してみる。

cos_sim(words[1]['ザク'] + words[4]['赤い'], words[2]['シャア'])
cos_sim(words[1]['ザク'] + words[4]['甘い'], words[2]['シャア'])

Out: 0.417671520432263
Out: 0.4171861580830552

あまり期待した結果にならなかった。
単語が文脈に依存するので「甘い」が「赤い」と同じような意味になってしまったのかもしれない。
BERTの単語埋め込みベクトルは、単語の演算には適さなさそうだ。

参考

BERT Word Embeddings Tutorial · Chris McCormick

Juman++v2をWindowsでビルドする

NLP Juman++ Windows

BERTの日本語Pretrainedモデルを試してみたくなったので、その準備として、Juman++v2のWindowsでのビルドを行った。
ほぼ公式通りなので、あまり記事にする意味はないが手順をメモしておく。

Juman++v1はWindowsに対応していなかったが、v2は公式でWindowsにも対応している。
現在rc2がリリースされているが、ビルド済みバイナリは配布されていないため自分でビルドする必要がある。

rc2のダウンロード

GitHubのリリースからv2.0.0-rc2をダウンロードして適当なディレクトリに展開する。
jumanpp-2.0.0-rc2.tar.xzの中にソースと学習済みモデルが含まれている。

Visual Studio 2017のインストール

ビルドにはVisual Studio 2017 Communityを使用する。

CMakeのインストール

ビルドツールにCMakeを使用する。CMakeのWindows版をインストールして環境変数PATHを設定する。
（Visual Studio 2017 CommunityのオプションでCMakeをインストールしている場合は不要）

ビルド

スタートメニューから「VS 2017用 x64 Native Tools コマンドプロンプト」を起動して、jumanpp-2.0.0-rc2.tar.xzを展開したディレクトリで以下の順にコマンドを実行する。

mkdir cmake-build-dir
cd cmake-build-dir
cmake -G "Visual Studio 15 2017 Win64" ..
MSBuild jumanpp.sln /t:build /p:Configuration=RelWithDebInfo;Platform="x64"

src\jumandic\RelWithDebInfoに実行ファイル「jumanpp_v2.exe」が生成される。

テスト

Juman++v2が対応している文字コードはUTF-8のため、コマンドプロンプトのコードページをUTF-8に変更してテストする。

chcp 65001
cd src\jumandic\RelWithDebInfo
echo 魅力がたっぷりと詰まっている| jumanpp_v2 --model=..\..\..\..\model\jumandic.jppmdl

以下のように表示される。

魅力 みりょく 魅力 名詞 6 普通名詞 1 * 0 * 0 "代表表記:魅力/みりょく カテゴリ:抽象物"
が が が 助詞 9 格助詞 1 * 0 * 0 NIL
たっぷり たっぷり たっぷりだ 形容詞 3 * 0 ナノ形容詞 22 語幹 1 "代表表記:たっぷりだ/たっぷりだ"
と と と 助詞 9 格助詞 1 * 0 * 0 NIL
詰まって つまって 詰まる 動詞 2 * 0 子音動詞ラ行 10 タ系連用テ形 14 "代表表記:詰まる/つまる ドメイン:料理・食事 自他動詞:他:詰める/つめる"
いる いる いる 接尾辞 14 動詞性接尾辞 7 母音動詞 1 基本形 2 "代表表記:いる/いる"
EOS

別の例

echo 外国人参政権| jumanpp_v2 --model=..\..\..\..\model\jumandic.jppmdl
外国 がいこく 外国 名詞 6 普通名詞 1 * 0 * 0 "代表表記:外国/がいこく ドメイン:政治 カテゴリ:場所-その他"
人 じん 人 名詞 6 普通名詞 1 * 0 * 0 "代表表記:人/じん カテゴリ:人 漢字読み:音"
@ 人 じん 人 名詞 6 普通名詞 1 * 0 * 0 "代表表記:人/ひと カテゴリ:人 漢字読み:訓"
参政 さんせい 参政 名詞 6 サ変名詞 2 * 0 * 0 "代表表記:参政/さんせい ドメイン:政治 カテゴリ:抽象物"
権 けん 権 名詞 6 普通名詞 1 * 0 * 0 "代表表記:権/けん カテゴリ:抽象物 漢字読み:音"
EOS


Juman++v2は、v1に比べて250倍速くなっているようなので、未知語を多く含む場合MeCabに代わる形態素解析として使えそうな気がします。それでもMeCabよりは1桁以上遅いようです。

2019/7/28 追記

モデルは、モデルファイルを直接渡さずに、jumandic.confを引数に指定する方が良い。
jumanpp-2.0.0-rc2.tar.xzに含まれるmodel/jumandic.conf.inをmodel/jumandic.confにリネームして、--modelの行にモデルファイルのパスを設定する。
jumanpp_v2の引数には、

--config=H:\src\jumanpp-2.0.0-rc2\model\jumandic.conf

のようにjumandic.confのパスを指定する。