Home > Research

2011.08.25

JST戦略的創造研究推進事業「さきがけ」に研究課題が採択されました

昨日プレスリリースの通り,JST戦略的創造研究推進事業「さきがけ」の研究領域「情報環境と人」に,自分が申請していた研究課題が採択されました.研究課題名は「知識の自動獲得・構造化に基づく情報の論理構造とリスクの分析」です.研究の概要は次の通りです.

ウェブやソーシャルメディアなどの新しい情報環境により、情報の流通が加速する一方、偏った情報やデマなどの拡散による社会の混乱や不安が増大しています。本研究では、ネット上で言及されている物・事態に関する知識を計算機がロバストに獲得・活用する言語処理技術を基盤として、流通している情報の背後にある論理構造を解析し、その整合性を分析することで、安全・危険に関する多角的な判断材料を人や社会に提供します。

研究総括の石田亨先生の総評にもありますが,この研究は東日本大震災を強く意識したものになっています.世の中の状況に左右されず,研究者は自身の研究に邁進すべきという考え方もありますが,自分の研究を社会にどう役立てるか,高い意識を常に保ちたいと考えています.私も震災復興に関するシンポジウムやミーティング等に参加し,言語処理(さらには情報科学)をどのように役立てるか考えてきました.これらの場で,人命の救助や医療,建物や水道などの生活インフラの復旧,災害に強い情報通信インフラの整備,ソーラーやバイオマス発電などのエネルギー施策,ロボットによる原発対応などの報告を伺う度に,言語処理を役立てることの難しさを感じます(その点,GoogleのPerson Finder自動車通行実績情報マップANPI NLPは,スピード感があってすごく良いプロジェクトだと思います).

ただ,震災後の日本の混乱を見ていると,言語処理の重要性はむしろ増しているように思います.震災ではウェブやソーシャルメディアなどの情報環境が大活躍しましたが,一方で偏った情報の拡散による社会の混乱・不安を招いています.情報技術がどんなに進歩しても,人間の情報処理能力は向上しませんので,大量の情報を有効に活用できません.社会は高度に専門化されているため,そもそも情報の内容を理解できない場合もあります.このような状況では,各人が情報の内容を理解を伴なわず,情報の発信者や怖さといった周辺的情報に基づいて意思決定をしてしまうことになります.さらに悪いことに,Twitterなどで誰もが気軽に情報を発信できるようになると,周辺的情報のみに依存した反射的な情報伝搬が増え,デマや偏見・差別が助長される要因となります.

どの情報が正しいのか人間ですら分からない状況のなか,計算機に情報の正しさを検証してもらうのは不可能です.しかも,最終的に情報を活用して意思決定を行うのは人間です.私も震災後に身の回りの人の説得に失敗した経験があり,人間の意思決定のやり方を変えてもらうことの難しさを痛感しました.このような動機により,意思決定に参考になりそうな情報を自動的,もしくはインタラクティブに提示することで,ユーザの情報処理能力を高めるための支援をしてみよう,というのが本研究のテーマです.

具体的には,ネット上のコンテンツを自動的に分析し,人間が意思決定を行う際に参考となるリスク情報(目的の達成度合い,安全度,危険度)を多角的に集約することを目標としています.このとき,ネット上から自動的に獲得したエンティティに関する知識,イベント及びイベント間(含意関係や因果関係など)の知識を総動員することで,流通している情報の論理構造(例えば二つの文がだいたい同じ事を言っているとか,参考情報としての筋の良さ)を明らかに出来るかどうかが,言語処理研究としての課題となります.

震災後の社会の混乱を目の当たりにしつつ,乾さんの言論マップの現状などを聞きながら,研究の構想を練りました.今まで私が進めてきた研究をキーワードで表現すると,文書自動要約(~D2あたりまで),生命・医学文献からの知識獲得(NaCTeM以降)なので,獲得した知識をきちんと活用し,言語理解に一歩近づいた文書自動要約に挑戦することになるのだと思います.今の自分にはちょっと背伸びした研究テーマであるため,上手くいくのかどうか,不安とワクワク感でいっぱいです.

2011.08.12

CRFツールのベンチマーク

CRFsuite 0.12のリリースに合わせて,チャンキングタスクによるベンチマークを更新しました.見所は,0.11→0.12でどのくらい速くなったのか,高速だと謳っているWapitiがどのくらい速いかです.その他,各学習アルゴリズムによる性能(学習速度,精度)差も,興味深い点かと思います.比較したツールは,

実験では,L2正則化(C=1),L-BFGSの終了条件は直近10回の反復で目的関数の改善率が1e-5を下回ったとき,平均化パーセプトロンの反復回数は50に固定,という条件にしました.

まず,CRFsuite 0.12で実装された平均化パーセプトロン(AP)は,非常に高速でありながら,L-BFGSやSGDに迫るタグ付け性能を示しています.精度はL-BFGSやSGDと比較して0.1~0.3ポイントくらい低下するようですが,学習データを1回(iteration)処理するのに要する時間は,1.7-1.9倍高速です.1回の反復に要する時間が短くなるのは,各事例に対してViterbiアルゴリズムを適用するだけで学習を進めることができ,手間のかかる対数尤度や勾配の計算を省くことができるからです.さらに,今回の実験では8回の反復でピークの性能を示したので,反復の回数を開発データセットなどでうまく調整できれば,非常に有用な学習アルゴリズムと言えます.

比較したソフトウェアの中で後発のWapitiはなかなか速いですが,一回の反復に要する時間を比較するとCRFsuiteより遅いようです.Wapitiのデフォルトのパラメータでは,L-BFGSの収束判定が非常に甘いため,30回強の反復で最適化が終了してしまいます(このため収束判定条件を統一しました).L-BFGSのiteration回数と精度のグラフを見ていると,30回付近では精度の改善が続いているため,この段階で最適化を止めてしまうのは早すぎます.WapitiはML compで長い間最速を維持していると謳っていますが,収束判定が甘いのが主要因だとすると,利用には注意が必要かもしれません.

CRFsuiteもML compにエントリーしたいのですが,系列ラベリングタスクの素性生成は各ソフトウェアに任されており,しかも,各ソフトウェアはどのタスクのデータが来たのか分からないため,有益な比較がしづらい状況にあります.つまり,与えられたデータの各列の意味がソフトウェア側からは(トリッキーな方法を使わない限り)分からないので,品詞タグ付けやチャンキングで同じ素性セットを使うことになってしまいます.さらに,素性数や学習アルゴリズム,パラメータなどで学習時間は大きく変わるので,純粋な実装の「良さ」をML compの実験環境で見積もるのは難しいと思います.

CRFsuite 0.11と0.12の比較(L-BFGS学習時)では,sparse素性で1.38倍,dense素性で1.46倍の速度向上が見られました.大した速度向上ではないかもしれませんが,0.12ではソースコードの可読性・再利用性を劇的に改善したので,この結果には満足しています.

2011.08.11

CRFsuite 0.12 released

CRFsuiteのバージョン0.12をリリースしました.このバージョンは変更点がてんこ盛りです.張り切りすぎたせいで,ドキュメントの更新に手間取り,コードが出来てからリリースまで1年くらい経過してしまいました.変更点はChangeLogの通りですが,このブログではいくつか補足しながら紹介します.

ソースコードの大がかりな再構成を行いました.特に,グラフィカルモデルの処理に関する部分(対数尤度や勾配の計算など)と,学習アルゴリズムに関する部分を分離しました.今回のソースコードの再構成により,新しい学習アルゴリズムの追加や,異なる形状のグラフィカルモデル(例えば属性とラベルバイグラムに対する素性や二次マルコフ素性)を追加しやすくしました.ソースコードの再構成をやるモチベーションは前々からあったのですが,@yuutatさんの「Fast Newton-CG Method for Batch Learning of Conditional Random Fields」の研究に混ぜて頂いたのをきっかけに,コードの大がかりな修正を行いました.新しいグラフィカルモデルを追加したり,ヘッシアン・ベクトル積のDPによる計算を追加することには,まだ未着手ですが,そのための基礎を固めました.

ソースコードを綺麗にしたついでに,平均化パーセプトロンPassive-AggressiveAdaptive Regularization of Weights (AROW) の学習アルゴリズムを追加しました.学習アルゴリズムは,-aオプションで指定することになりました.学習アルゴリズム毎のパラメータの一覧は,-Hオプションで見ることができます.

ソースコードの見直しを行っているときに,「あー昔は理解が足りず無駄な計算をしているなぁ」と思うところがいくつかあったので,その部分を修正しました.日記で書いていたSSEのexp計算ルーチンも取り込まれています.これらの修正により,だいたい1.4~1.5倍速くなりました.新しいベンチマーク結果を載せておきました.

系列の開始(BOS)と終了(EOS)の素性を自動的に生成するのを廃止しました.以前のCRFsuiteでは,BOS,EOSという特殊なステートを定義し,そのステートから各ラベルへの遷移素性(バイグラム素性)を作っていました.考えてみたら,系列の先頭と末尾にEOS/BOSを表す属性を追加すれば十分だったので,BOS/EOSに対する特殊なコードを削除しました.BOS/EOS素性を作りたいときは,各インスタンスの先頭と末尾のアイテムに,”__BOS__”や”__EOS__”みたいな属性を追加してください.

いくつかの学習パラメータの名前が変更になりました.重要なところでは,”regularization.sigma”が”c1″及び”c2″になりました(c1 = 1.0 / regularization.sigma; c2 = 0.5 / regularization.sigma^2).これにより,L1正則化,L2正則化が同時に使えるようになりました.L1正則化,L2正則化をOFFにするときは,それぞれ”c1″,”c2″を0にセットしてください(sigmaによる設定だと無限大にする必要があったので,cによる設定に変更しました).

交差検定(cross-validation)やテストセットによる評価(holdout-evaluation)を,データセットにグループ番号を割り振ることで実装しました.学習と同時にテストセットで評価を行うには,複数のデータセットをCRFsuiteに入力し,どのデータセットで評価を行うのか,グループ番号を指定します.交差検定を行うときは,N個のデータセットを明示的に与えるか,-gオプションを使い入力されたデータセットを自動的にN分割すればOKです.

データセットのフォーマットに関するドキュメントを書きました.データフォーマットはCRFsuiteの特徴の一つでもあるのですが,ユーザからの質問が多いので,きちんと書くことにしました.

これまでは,#でコメントを書くことを許していたのですが,自然言語のテキストから属性を作るときにうっかりと”#”を使ってしまうトラブルが起きそうなので,廃止しました.

予測されたラベル系列の条件付き確率(-pオプション)や,各ラベルの周辺確率(-iオプション)を出力できるようにしました.これらの機能には多くの要望が寄せられました.

CRFsuiteのC言語APIを大幅に改訂しました.ライブラリの名前はlibcrfからlibcrfsuiteに変更になりました.ライブラリが公開している関数名は,”crfsuite_”という文字列から始まるようになりました.C言語のAPIドキュメントを書きました.

CRFsuiteのライブラリを簡単に使うために,C++のラッパー(crfsuite_api.hppcrfsuite.hpp)を書きました(C++/SWIGのAPIドキュメント).さらに,C++のAPIをSWIGを経由して他の言語から呼び出せるようにしました.手始めにPythonのモジュールを構築し,学習とタグ付けがPythonから行えるようになりました.モジュールのビルド方法はREADMEを参照してください.

CRFsuiteに与えるデータセットを生成するためのサンプルスクリプトを改良しました.チャンキングのサンプル(chunking.py)は,わかりやすい属性名を出力するようになりました.また,CRFsuiteのPythonモジュールを利用して直接タグ付けを行う機能も実装されました.CRF++互換のテンプレートを処理するためのスクリプト(template.py)を追加しました.その他,固有表現抽出(ner.py),品詞タグ付け(pos.py)のサンプルも追加しました.これらのサンプルを改変するだけで,CRFsuiteを新しいタスクに適用できると思います.

メモリリークを何点か修正し,メモリ使用量を若干削減しました.

モデルファイルが存在しないときに落ちる問題を修正しました.

2011.04.01

東北大学情報科学研究科に准教授として着任しました

本日、東北大学で辞令交付式があり、情報科学研究科の准教授に任命されました。今後は、乾健太郎さん、研究室の学生・スタッフさんと一緒に、自然言語処理や知識処理の研究を進めていきます。

辞令交付式の様子

この日を迎えられたのも、諸先生・先輩・同僚・学生・友人の皆様のお陰です。全員挙げるとキリがないくらい、いろいろな方にお世話になりました。これから約10年間が、自分にとって本当に大切な時期だと考えていて、これまで以上に研究と教育に打ち込んで行こうと思いますので、ご指導・ご支援をよろしくお願い致します。

2010.03.07

SimString (類似文字列検索ライブラリ) 1.0 released

SimStringという類似文字列検索ライブラリをBSDライセンスでリリースしました.類似文字列検索とは,文字列集合(データベース)の中から,クエリ文字列と似ているものを見つけ出す処理です.コンピュータは,正確に一致する文字列を探すのは得意ですが,表記揺れに出くわすと,途端に対応できなくなります.例えば,「スパゲティ」に対して,レストラン情報などを返すサービスにおいて,「スパゲッティ」や「スパゲティー」などの表記揺れが検索クエリに与えられると,通常のデータベースでは情報を提示することが出来ません.類似文字列検索を用いると,表記揺れが検索クエリに与えられても,「スパゲティ」という既知語を代替クエリとして提案したり,「スパゲティ」の情報をダイレクトに引き出すことができるようになります.

似てる語を探す技術って,文字列処理の基本中の基本で,自然言語処理では当たり前のように使われていてもおかしくないと思うのですが,研究ではほとんど見かけません.2つの文字列が与えられたときに,似てるか似てないかの識別する研究は,色々あるのですが,ある文字列が与えられたときに,どの文字列が近いかを高速に収集する方法は,あまり見かけません.検索エンジンを提供している会社では,検索クエリログに基づくクエリ訂正などを行っていますが,検索クエリログは誰でも入手できるわけではありません.類似文字列検索は,データベースやデータマイニングの分野で盛んに研究がされていますが,単語や用語レベルの文字列が簡単に扱えるツールが見つからなかったので,自分で作ってみました.

SimStringは,「文字列集合の中で,検索文字列との類似度がある閾値以上のものをすべて返す」という処理を高速に行えるように設計されています.類似度関数としては,コサイン係数,ジャッカード係数,ダイス係数,オーバーラップ係数をサポートしています.類似度を計算するときの文字列の特徴として,文字Nグラムを採用しています.

例えば,3グラム(N=3)を用いたとき,「スパゲティ」は「$$ス」「$スパ」「スパゲ」「パゲテ」「ゲティ」「ティ$」「ィ$$」と表現されます.このとき,文字列の先頭と末尾を表す特殊な記号「$」が挿入されていますが,これを用いるか用いないかはカスタマイズ可能です(デフォルトでは用いないことになっている).また,Nグラムの単位(すなわちNの値)も,自由に設定できます.また,日本語などのマルチバイト文字でも正確にNグラムが計算できるように,ユニコードをサポートしています.

SimStringは,類似文字列検索を正確に,かつ高速に行えるように設計されています.Google Web 1Tコーパス の英単語(13,588,391文字列)から,コサイン類似度が0.7以上の文字列を検索するのに必要な時間は,1クエリあたり平均 1.10 [ms] 程度です.

実装はC++で,ヘッダファイルをインクルードするだけで他のアプリケーションに組み込めるようになっています.また,PythonとRubyのSimStringモジュールも,ビルドできるようになっています.他言語のモジュールはSWIGを用いてラッパを自動生成しているので,Perlなどの言語にも対応できるはずです(ビルド報告,サンプルプログラムなど歓迎致します).Pythonで類似文字列が一瞬で検索出来るなんて,楽しい世界が広がると思いませんか?

$ python
Python 2.5.1 (r251:54863, Oct 15 2007, 23:38:19)
[GCC 3.4.6 20060404 (Red Hat 3.4.6-8)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import simstring
>>> db = simstring.reader('web1tuni/web1tuni.db')
>>> db.measure = simstring.cosine
>>> db.threshold = 0.9
>>> db.retrieve('approximate')
('approximat', 'pproximate', 'approximate', 'approximated', 'approximatel',
'approximates', 'approximatey', 'anapproximate', 'approximatelt', 'approxima
tely', 'reapproximate', 'toapproximate')
>>> db = simstring.reader('web1tja/unigrams.db')
>>> db.measure = simstring.cosine
>>> db.threshold = 0.7
>>> print(' '.join(db.retrieve('スパゲッティー')))
スパゲッティ スパゲッテー スパゲティー スパッティー スパゲッティー スパゲッ
ティーニ スパゲッティー・ スパッゲッティー スパゲッティーニ・ ・・スパゲッテ
ィー スープスパゲッティー スパゲッティーモンスター
>>>

いろんなクエリを入れながら遊んでいるだけで,研究ネタが浮かんできそうです.この例では,単にコサイン類似度で類似文字列を検索しているだけなので,表記揺れ,語尾変化,派生語,その他別の概念を指すものが混ざって獲得されます.ここからルールや機械学習を用いて,所望の語を選別するのは,別タスクになります.

アルゴリズムの詳細については,今週東大で開催される情報処理学会の全国大会で発表する予定です.学会初日の朝一番の発表(1C-1)ですが,興味のある方は,是非遊びに来て下さい.

2010.01.29

CRFsuite 0.10 released

CRFsuite 0.10をリリースしました.修正点は,以下の2点です.

  • タガー使用時にメモリリークがある問題を修正.この問題を修正するパッチは,株式会社高電社の真鍋宏史様から頂きました.(どうもありがとうございました)
  • タガーに-r (–reference) オプションを追加.このオプションは,入力データがラベル付きであると仮定し,各行に正解のラベルと予測されたラベルをタブ区切り形式で並べて出力します.

CRFsuiteのライブラリ・インタフェースは,タガーと学習器を分離しようと計画中です.タグ付けするだけなのにL-BFGSのライブラリとリンクするのは無駄だと思うので.現在,CRFsuiteを使ったあるソフトウェアを準備中で,カンファレンスシーズンが終わってそちらの開発が進めば,CRFsuiteのインタフェースに手を加えると思います.

タガーに新しく追加した-rオプションは,conlleval.plを簡単に使えるようにするためのものです.が,conlleval.plは正解のラベルの前に,何かのトークンがないと,大量のワーニングを吐き出すようです.仕方がないので,CRFsuite tag -rの出力に,

import sys

for line in sys.stdin:
    line = line.strip('\n')
    if line:
        sys.stdout.write('a\t%s\n' % line)
    else:
        sys.stdout.write('\n')

という,タグ付け結果の先頭に”a”を追加するアホなフィルタを通してからconlleval.plを使っています.conlleval.plを直すのがスジだと思いますが,Perlは読み書きが全くできないので….

libLBFGS 1.9 released

libLBFGS 1.9をリリースしました.すごく些細なミスの修正なので,最適化問題への影響はほぼ皆無かと思います.ミスの内容は,”ftol”と”wolfe”というパラメータが間違って指定されているかどうかをチェックするコードが間違っていたというものです.

この問題はKevin S. Van Hornさんに指摘していただきました.よっぽどlibLBFGSを使い込んでいたか,コードをじっくり読んで頂いたんですね.コンパイラが自動的に発見したという可能性も捨てきれませんが・・・.

2010.01.10

classias 1.1 released

昨年の話になりますが,Classias 1.1をリリースしました.ほとんどは,classias-tagのバグ修正,新しい機能の追加,使い勝手の改善が主です.

classias-tagには,失敗解析オプション(-f)を追加しました.失敗解析といっても,高度なことをやってくれるわけではなく,ラベル付け時に正解と食い違う事例のみを出力する機能です.classias-tagには,データ中のコメント行(#から始まる行)をそのままスルーして出力するオプション(-k)があるので,各事例を識別するような文字列をコメント行に入れておけば,どの事例で予測が失敗するのか調べることができます.

多クラス分類,もしくは候補選択ですべてのラベル付け候補に関する情報を出力するオプション(-a)を追加しました.ひとつの事例に対して,@boiと@eoiという行の間に,各候補がラベルとして予測されたかどうか(+もしくは-)が出力されます.タグ付けのスコアや確率を付与するオプション(-sもしくは-p)と併用すると,各ラベル候補がどのくらいの確信度だったのか確認することができます.

また,与えられていたデータに含まれていた正解ラベルをそのまま出力するオプション(-r)を追加しました.このオプションを使用しないと,classias-tagは予測されたラベルしか出力しませんが,-rを有効にすると,同じ行に正解のラベルと予測したラベルを並べて出力します.

[正解のラベル] [予測されたラベル]

正解のラベルと予測されたラベルが並ぶので,ラベル付けの評価(精度などの計算)を行うスクリプトが書きやすくなると思います.

classias-trainでは,候補選択において正しい候補が存在しない事例があるときに,データ読み込みでクラッシュする問題を修正しました.この問題は,東芝の若木さんに指摘していただきました.若木さんは,学習データの中でどの事例でクラッシュするのかを調べるために,二分法でクラッシュを再現しない事例を半分ずつ減らしながら,クラッシュを再現する事例を見つけ出したそうです.すごいです.

次は,新しい学習アルゴリズムをいくつか載せてみたいですが,もう少し先になると思います.

2009.10.21

Medlineから自動構築した略語辞書Acromine

私が昔所属していたNaCTeMで公開している,略語辞書サービスAcromineをひっそりと更新しました.以前のバージョンからの変更点は,以下の通りです.

  • 2009年版Medlineのアブストラクトで略語抽出をやり直した
  • 略語の完全形のクラスタリング方法を改良した
  • 略語の完全形の異表記を表示できるインタフェースにするため,辞書検索結果の表示を表形式からツリービューに変更した
  • 辞書引きサービスのAPIを,SOAPからREST/JSONに変更した

単に辞書の中身を新しくするだけではつまらないので,ツリービューをウェブブラウザ上で実装するときに,YUI Libraryを初めて使ってみました.ノード・ラベルの遅延ロードを行うツリービューが簡単に実装できて,便利ですね.

辞書引きサービスのAPIを使うには,登録手続きが必要になるようです(残念ながら私のコントロール範囲外).アカデミックな人たちは問題無く認可されると思いますが,コマーシャルな方は,相談していただければNaCTeMに取り次いでみます.また,手持ちの大量の文書セットに含まれるテキストから略語の定義をマイニングしたいというのも,相談して頂ければ対応できるかと思います.

2009.09.27

Classias 1.0 released

Classiasという分類のための機械学習アルゴリズムの実装を公開しました.今のところ,L1/L2正則化ロジスティック回帰(最大エントロピー法),L1/L2正則化L1損失線形カーネルサポートベクトルマシン(SVM),平均化パーセプトロンをサポートしています.学習アルゴリズムとしては,平均化パーセプトロン,L-BFGS法,OWL-QN法,Pegasos,Truncated Gradient(L1-FOLOS)を実装してあります.カーネルは使えませんが,線形識別モデルを高速に学習できるようになっています.二値分類,多クラス分類,候補選択(明示的に与えられた候補の中からスコア最大のものを選ぶタスク)をサポートしています(SVMは今のところ二値分類のみ).

このツールはもともと,最大エントロピー法を自分で使うために実装したもので,作り始めてからもう2年くらい経過しています.去年のColingやEMNLPの論文の機械学習の箇所は,このツールで実験しています.文字列による素性,自動分割交叉検定など,自然言語処理の実験に便利な機能に重点を置いて作ったつもりです.詳しくは,使い方を参照してください.

ソースコードも,インスタンスのデータ構造,損失関数,学習アルゴリズムなどのコンポーネントを,C++テンプレートクラスとして実装するという設計になっています.L-BFGS法を実装しているlibLBFGSを除けば,ヘッダファイルをインクルードするだけでClassiasを利用したプログラムが書けるようになっています.クラスリファレンスやサンプルコードはドキュメントを参照してください.新しい学習アルゴリズムも,簡単に追加できるようになっているのですが,ドキュメントをもう少し充実させていかなければなりません・・・.

LIBLINEARやLIBSVMと一緒にrcv1.binaryでパフォーマンスを測ってみました.まず,分類精度に関してはロジスティック回帰とL1損失SVMに大差がなく,平均化パーセプトロンはちょっと悪いという予想通りの結果で,Classias,LIBLINEAR,LIBSVMのどれも同程度の分類精度を出しています.

学習速度に関しては,LIBLINEAR速すぎです.L1正則化のロジスティック回帰ではそれほどスピードの差はありませんが,L2正則化のロジスティック回帰では,LIBLINEARの方が4倍くらい速くなっています.アルゴリズム的には,L-BFGS法と信頼空間ニュートン法の戦いで,後者はヘッシアンを使っているので,速くなるのも頷けます.ただ,収束の判定条件が違うと思うので,後できちんと検証してみようと考えています.

SVMに関しては,LIBLINEARの圧勝(LIBLINEARの方が10~20倍高速)でした.ClassiasのPegasosも健闘していますが,学習率や収束判定の調整で10~20倍の速度差を埋められるかは疑問です.Dual coordinate descentはやっぱり強いですね.こちらも後で実装して遊んでみたいです.

実装するといろいろ分かることがあるので,これからも実験しながら育てていきたいと考えています.

Next »