WASS (Wikipedia Axis-Specified Search) (Wikipedia の検索エンジン)
]]>
これまでの方法ではひとつの項目のどこかに 「アイ」，「イド」，「ドル」 というつづりがあらわれれば，すべて候補とみなしていた． そのため，項目内のはなれた 3 つの位置にこれらがあらわれていれば，候補とみなしていた． あたらしいアルゴリズムでは，これらがちかくの段落にあらわれるばあいにかぎって候補としている． (N グラムの全文検索アルゴリズムにおいては，さらに段落内の位置までインデクス内にもつが，メモリ量はさらにふえる.)
ほんとうは同一の段落にあらわれるときだけ候補としたかったが，すべての段落の情報を (ビット・ベクタとして) 表現すると可変長になって処理速度がかえっておちてしまう． この方法もためしたが，これまでの方法で 2 秒で検索できる 「漱石」 の検索に 400 秒かかるようになってしまったので断念した． 段落情報を 32 bit にとどめるために，段落数がおおいときは，ちかくの段落をくべつしないようにした．
この方法で，これまで候補しぼりこみに約 0.8 秒，「アイドル」 の逐次検索に約 9 秒かかっていたのが，それぞれ 1.2 秒，6.6 秒となった． 候補数でいうと，これまで 393 万だったのが，243 万まで減少した． 予想していたほどはへらなかったので，検索時間も劇的には短縮されていないが，一応，効果はあった (へらない原因のひとつは結果数がおおい (約 12 万個) ことであり，これは表示するページを分割しなければ解決しない)． そのかわり，インデクスがしめるメモリ量は約 2.4 GB から約 4.5 GB に増加した． それでも，なんとか 10 GB のメモリのなかにおさまっている． メモリを増設しないかぎりはこれが限界だ．
]]>検索語から 2 文字ずつサブストリングをもとめていくと，最後に 1 文字あまる． いままではこの文字のインデクスも検索していたが，これは必要ないのではぶくことにした． これによって最後がこれらの文字種でおわる検索語に関しては画期的な高速化をはかることができた． たとえば，これまで 「アイドル」 の候補しぼりこみに 4 秒弱かかっていたのが，0.8 秒以下でできるようになった． 最後の 1 文字の検索にいかに時間がかかっていたかがわかる．
ただし，検索時間全体としては 10% 以下の改善でしかない． これをおおきく改善するには，しぼりこみをつよめる必要がある．
]]>
年代軸で検索すると，1920 年代から 2040 年までの年代表記がみつかる (図は講義資料からの抜粋)．
1910 年代以前も表示されるが，それは情報抽出のまちがいのためだ．
2040 年とか 1941 年とかに現代のアイドルが登場するが，それは仮想的な年代だ．
現代のアイドルも生年などで順序づけられて，それなりに意味がある結果になっている． 昔の 「アイドル」 については歴史的な意味はあるが，現代の学生にとってはあまり興味はないだろう．
検索結果にふくまれる年代表記のところに正規化された年代がタグとしてうめこまれているのをみせたかった． しかし，もちこんだ PC でインターネットにつなぐことができず，そなえつけの PC にはふるいインターネット・エクスプローラしかはいっていないため，abbr タグの内容がマウス・ポインタをおいても表示されず，意図したデモ効果がえられなかった．
検索時間が 23 秒もかかっているが，これについては現在，最適化中だ．
もっとおもしろいのは地域軸である．
北海道から沖縄まで，ご当地アイドルがならぶ (図は講義資料からの抜粋)．
ローカルなアイドルは学生たちも知らないだろうが，名のうれたアイドルももちろん，ふくまれている．
地域軸検索の結果からは Google Map もひらけるようにしたのだが，デモするのをわすれてしまった．
講義の相手は 2 部 (夜間) の学生であり，人数は 10 数人しかいない． URL も紹介しておいたが，ほとんどアクセスしていない． (でも，0 ではなかったようだ.)
]]>
my $indexVec = $index{$s};
for (my $i = 0; $i < bytes::length($indexVec); $i++) {
$count{vec($indexVec, $i, 32)}++;
}
しかし，vec 関数は 1 ビットごとのアクセスが可能な汎用の関数であり，そのぶんオーバヘッドがあるとかんがえられる． pack 関数を使用して，あらかじめデータを通常の配列にしておくほうが効率的なのではないかとかんがえて，ためしてみた． つまり，つぎのようなプログラムにする．
my @indexVec = unpack('N*', $index{$s});
foreach my $index (@indexVec) {
$count{$index}++;
}
このプログラムも配列への変換という，けっしてかるくない操作をふくんでいるのだが，それでもこのほうが 5 割ほどはやいことがわかった． ただし，通常はこのあとの操作のほうがおもいので，全体としての高速化は 3 割，あるいはそれ以下にとどまっている．
なお，unpack するときに 'N' つまり network-byte-order を指定しているのは，vec によってアクセスするときは network-byte-order になるからである． これによって，インデクスに格納されたデータは vec, unpack のどちらでもアクセスできるようになる．
]]>世界地名に関してはもともと GeoNames を使用しているため，それがふくんでいる緯度・経度をそのまま使用した．
いずれにおいても地図を表示する際にはズームの指定が必要だ． ズームは適当にきめているが，うまくいっていないばあいもある． つまり，地図が拡大されすぎていて，なにを表示しているのかがわかりにくいことがときどきある． また，逆に表示するべき地域がちいさすぎることもある．
すこしはずれた場所が表示されることもあるが，これはデータベースの緯度・経度がまちがっているからだろうか? まだ原因をしらべていない．
2009-12-20 追記:
東京都と北海道については，ついにプログラム上に手で情報をかきくわえることにした．
他の府県や市に関しては，だいたいもとのデータベースにあるものは表示できるようになった．
しかし，まだ地図に表示できない市がかなりある．
これは，GeoNames にそれが登録されていないためだ．
また，東京の区は地名抽出でサボっていて，タグすらつけられていない．
東京以外は 「区」 というと市の下位にあるからまあよいが，東京 23 区は市に属していないからすっかり情報がおちてしまう．
2009-12-20 追記:
上記の東京 23 区が検索されないという問題もきょう修正した．
地名リストをつくるプログラムに 1 文字 「区」 という文字をくわえて，テキストを生成しなおしただけである．
これでほぼ Wikipedia のテキストはメモリ上に保持されるようになり，検索性能が維持されるようになった．
]]>
中略
まだ課題がいろいろあるので，あまり宣伝してはいません． 課題としては，まだ検索がおそいこと，PC 1 台でサービスしているので一度にひとり (かつ 1 分に数人) しか検索できないこと，まだバグがおおいことなどがあります． 一応 24 時間サービスしようとはしていますが，サーバがダウンしてもすぐに回復できる体制にはなっていないので，しばらくとまってしまう可能性もあります．
関連ページ (2009-12-19 追記):
]]>タグが挿入された HTML ファイルは Web ブラウザによって通常どおりに表示することができ，かつタグがうめこまれた場所にマウスポインタをおくことによって，タグの内容が表示される． また，Web ブラウザとして Firefox を使用したときは，タグがうめこまれた場所に下線が表示されるので，タグの有無を容易にみてとることができる．
検索・整列サブシステムにおいては検索用のテキストをメモリにロードし，逐次検索によって検索している． 逐次検索は原始的なアルゴリズムであり大規模な検索システムには適さないが，この検索システムは 1 人または少人数による使用を前提として設計しているため，また現在のパソコンでは世界大百科事典程度のテキスト量の検索のためには逐次検索でも実用になるため，このような方法をとっている．
また，検索・整列サブシステムにおいては，単純な全文検索だけでなく，タグの情報を利用して特定の範囲の年代や特定の地域の情報をふくむ段落を検索することができる． また，検索結果を年代や地域によって整列して表示することができる． すなわち，検索結果を年表のような形式で表示したり，(日本の地域に関するものは) 北から南へ順に表示したりすることができる． さらに，検索結果の各段落はそれがふくむ文ごと (正確には 「句」 ごと) に自動的にスコアが付与され，その結果を使用して段落ごとにランクづけされる． スコアにしたがって段落のなかの重要な部分だけを表示するようにしたり，ランキングによって結果を順序づけたりすることができる．
年代表記の抽出と正規化
地名の抽出と正規化
候補とされた段落は逐次検索によって検索されるので，このアルゴリズムはもっとも効率的なアルゴリズムだとはいえない． しかし，テキスト全文をメモリにおくことによって，単純なわりには高速に検索することができる．
日本地名のデータベース (area-parent.txt) を生成するには，c:\wikipedia\areacode-jp というディレクトリにおいて市町村名のリスト (AllJapan.txt) とともに都道府県名のリスト (prefectures.txt) を使用し，area-list-japan.pl というプログラムを使用して地名とその上位地名との対応表 (area-parent-japan.txt) を生成する． つぎのコマンドを実行することによって，この表が生成される．
run.bat
この表においては，たとえば南部町という地名に対してはつぎのようなレコードがあたえられている．
これは，南部町の上位地名として 「青森県.三戸郡」，「山梨県.南巨摩郡」，「鳥取県.西伯郡」 の 3 つがあり，よみはいずれも 「なんぶちょう」であり，コードが 015458, 193666, 313891 であることをあらわしている． 世界地名のデータベース (area-parent-world.txt) を生成するには，c:\wikipedia\areacode というディレクトリにおいて主要 1000 都市のデータ (cities1000.txt) とともに国名とコードのリスト (country-Code.txt) を使用し，area-list-world.pl というプログラムを使用して地名とその完全地名 (上位地名 + その地名) との対応表 (area-parent-world.txt) を生成する． すなわち，つぎのコマンドを入力することによって area-parent-world.txt を生成することができる．
run.bat
生成された表においては，たとえばフィラデルフィアという地名に対してはつぎのようなレコードがあたえられている．
フィラデルフィア:アメリカ合衆国.ペンシルベニア州.フィラデルフィア:-Philadelphia:39.952335,-75.163789:4560349
これは，フィラデルフィアの上位地名が 「フィラデルフィア:アメリカ合衆国.ペンシルベニア州」 であり，つづりが Philadelphia，緯度, 経度が 39.952335, -75.163789 であり，コードが 4560349 であることをあらわしている．
]]>検索結果はほかにもいろいろな内容をふくんでいますが，それらは使用の手引やこのブログで説明することにします．
中略
もうひとつの検索結果を図にしめします． これも 「慶喜」 に関する検索結果の一部ですが，こちらは地名によって整列しています． くわしい説明はここでははぶきます．
