さて、FreyaSX/0.99.13 から、デフォルトでは形態素辞書を使わないことにしました。
これは、実は昨年の開発当初から気付いていたのですが、これまでのFreya(SX)では
「行政」とか「法人」で検索ができない(ことがある)という問題があったからです。
この問題は、形態素辞書を使うことによって生じます。

それでも、これまで一年間実際にDeleGateのML検索用に使ってきて、ほとんど問題を
感じることもなかったので実用上構わないんじゃないか、ということと、形態素辞書
を使うことによってたぶん大きなメリットがあり、使わないと罰があたる？のでは
ないかと思い込んでいたので、気にしないことにしていました（黙っててゴメン
なさい:p）。

もともと、昨年の 0.99.10 から形態素辞書無しでも索引が作成できるようになって
はいました。これは移植・インストール面や非日本語用の利用の観点からそうした
ものだったと思いますが、その時点では(通常の環境で)日本語文書に対して辞書の
使用を省くという利用法は考えてなかったような気がします。

今月、0.99.12で（2ギガバイト超の）比較的大きめな索引への対応を行ったのですが、
その索引作成テストは高速化のために、この辞書をはずして行いました。その際、
辞書を使用しない場合、索引の作成は30%程度高速になることがわかりました。
一方、その場合の索引ファイルのサイズ増大は、日本語文書に対しても10%程度の
ようです（日本語を含まない場合は不変）。
そんなわけで、辞書のメリットは、デメリットより小さいだろうということで、
この際公式リリースでも辞書を切っちゃえということになったのでした。


辞書問題について若干詳しく
￣￣￣￣￣￣￣￣￣￣￣￣￣
この問題は、単語辞書を使って単語の単位で索引を作ると、文字列(複合語)の途中に
ある検索語への検索がヒットしたりしなかったりする状況が起こるというものです。
（この分野に素人なので、正確にはどう表現するのか知りません）

この問題の原因は、形態素辞書を用いて単語を切り出して作られる索引の内容に
あります。例えば、(オリジナル)Freyaでは「独立行政法人」は、「行政法」が
ICOT辞書にあるため、「独立」「立行」「行政法」「人」のように分解されて索引化
されます。このため、このように分解された文字列を「行政」でひっかけるには
「行政*」で検索する必要があり、「法人」ではひっかけようがありませんでした。
（検索時の工夫で、たとえば「*法人」のように検索をできるようにすれば、対処
できるだろうとは思います。このような検索もいずれ入れたいとは思っていますが、
実装は多少複雑になるでしょうし、今回この問題の解決のためには、やる気が
起こりません）

一方、辞書を使わないことにすると、「独立行政法人」は「独立」「立行」「行政」
「政法」「法人」と、一様に分解されます。これで検索時のモレは無くなるわけ
ですが、単語数・参照数ともに増加するので、索引が大きくなることは想像される
通りです。ですが、憶えている限りでは、昨年 0.99.10 の時点で、辞書を使った
場合とそうでない場合の索引ファイルサイズの差を比較した記憶がありません。
それで、今回実際に日本語版DeleGate-MLの13100件の記事を索引化して比較みた
ところ、辞書を使う場合に較べて、使わない場合では索引ファイル群のサイズの
総計が約10%強大きくなりました。一方、索引の作成速度は、25%ほど高速化し
ました。

測定の詳細は最後に添付しますが、要約すると次のようになります。処理速度は、
MacOSX 10.2 + 1GHz PPC G4 (iMac) でのものです。

  (1) 辞書有りでの索引作成
  ・処理速度は、約150メール/秒、95万語片/秒
  ・作成される索引群のサイズは元データとほぼ同等

  (2) 辞書無しでの索引作成
　・処理速度は、約200メール/秒、150万語片/秒
　・辞書有りの場合に較べて、約25%の処理時間短縮
　・作成される索引群は、元データより1割強の肥大

やけにぴったりの数字ですが実測値です(^^)。(any2fdifによる)前処理の速度が
やはり、約200メール/秒（1Mバイト/秒）程度なので、逐次的に処理した場合、
ちょうど100メール/秒という数字になります（昨年までは、ちょっとサバ読ん
でました:p）
iMac/1GHz というのは、昨今のパソコンとしても、遅めの部類に入ると思います。
実際、0.99.12 の開発はデュアルCPUの PowerMac（MacOSX 10.4 + 2×2GHz PPC G5）
で行いましたので、これより2倍ほど高速でした。


FreyaSX と DeleGate
￣￣￣￣￣￣￣￣￣￣￣￣￣
昨年の9月に 0.99.10 をリリースしてFreyaSXの開発は休眠状態に入り、一年以上
が過ぎていましたので、ソースを眺めながらFreyaSXの何がどうできているのか
感覚を取り戻すのに2,3日かかりました。
この間佐藤は、DeleGate v8 - v9 の開発に専念していました。
昨年9月以降は、まず、バッファオーバフロー問題の根本的・ほぼ完全な解決を
行いました。その手始めに、DeleGate v8 を K&R C から、ANSI-C / C++ に
全面的に書き直したのですが、その際には、FreyaSX での C++ の経験が大いに
役立ちました。

C++ への書換えから、バッファオーバフローの根絶まで、結局3ヶ月近くを要し
ました。その後、DeleGate v9 の IPv6 対応やら、SSL関係の拡充やらで今年の
前半を終えました。最近では１ヶ月ばかり、フォームを使ったDeleGateの
ビジュアル管理機能にのめっていました。これも10年来の懸案だったのですが、
FreyaSX での検索フォームの作成の経験が役立ちました。それを少し一般化した
形で、ちょとしたフォーム処理記述言語を作ったので、これを FreyaSX にも
フィードバックできると思います。

0.99.12 以降、今回の一連の開発作業は、FreyaSX-En フィードバックのほうに
ドイツ方面から（はじめて）投稿のあった、

  <URL:http://www.delegate.org/mail-lists/freyasx-en/3>
  [FreyaSX-En] FreyaSX problem with files > 2GB / compiling on AMD64
  29 Aug 2005 10:05:58 GMT Stefan Grothkopp

での、"I'm trying to build an index of around 1.2 million web pages."
に触発されて、再開したものです。自分では、DeleGate-ML程度の小規模の索引
しか実用には使っていないので、このような使い方の例は良い刺激になります。
ちょうどDeleGateのビジュアル管理機能の開発にのめった疲れが出ていた時
だったので、気分を変えたくなっていた時でもありました。

おわりに
￣￣￣￣￣￣￣￣￣￣￣￣￣
形態素辞書の使用をやめると、日本語DeleGate-MLの例では、索引ファイルの
サイズが1割強大きくなりますが、これはひきかえに高速化する索引作成速度と、
検索精度(というのかな？)の向上で、十分引き合っておつりが来ると思います。
検索速度にはほとんど影響がないと思いますし。

そういえば原作者の原田さんから昨年のFreyaSX開始時に頂いたメールの中で、
「形態素辞書を一切使わないものも作ってみたい」と書かれてました。
お墨付きですね:)

なにより、FreyaSX の最大のウリは、索引作成速度にあると思っています。自分
でも利用者としての立場から、find+grep みたいなノリで使えるインスタントな
簡便索引作成＋検索インターフェイスが欲しいと思っています。
既にFreyaSXは性能面では、find+grepとコンパラと言える索引作成速度です。
あとは、DeleGateのCGI経由で索引作成から検索までを、一連のフォームの中で
できるようにすれば、このようなインスタントでアドホックな検索にツカエル
と思います。

もちろん、コマンドライン・インターフェイスでも簡便にできると良いのですが、
コマンドラインでの日本語の扱いが非常に環境依存ですし、多少複雑な設定の
繰り返し使用にはフォームによるインターフェイスのほうが向いていると思い
ますし、索引をリモートから検索できるという点ではHTTPベースが良いと思います。

今回の形態素辞書の(デフォルトでの使用の)廃止で、辞書を実現している
原田さん作のパトリシア木の処理コードを使用しないことになりました。自分と
してはこの部分の移植にも、それなりに手間をかけもしたので、虚しい気も
しないでもありません。ですが、これはまたこれで別の用途に活用できるかも
知れません。

また、この変更により若干ですが、検索の面にも影響があります。というのは、
単語辞書を使わないために、索引が単語の先頭から作られることがなくなり、
暗黙的に単語の先頭にマッチすることを期待した検索、特にカタカナ語の検索が、
余計なものをひっかけやすくなりました。そのため、0.99.13 で「＾カタカナ」
検索オペレータというのを導入しました。これについては、またあらためて
書きます。

　　　　　　　 　　　        D G　　
┌─┐┬┌──┬┐ ／／＼^^ ( - ); {Do the more with the less -- B. Fuller}
├─┤│└─┐│ ／　877m＼_<   >_ <URL:http://www.delegate.org/delegate/>
┴　└┴──┘┴──────────────────────────────
佐藤豊＠情報技術研究部門.産業技術総合研究所(独立行政法人)


性能測定の詳細
----------------------------------------------------------------------------
OS/CPU: MacOSX10.2 / PowerPC 1GHz
any2fdif: DeleGate/9.0.6-pre8
findex: FreyaSX/0.99.13

(0) 元データとFDIF
------------------

  % any2fdif
  Any2fdif on DeleGate/9.0.5-pre8 (October 11, 2005)

  % cd /tmp/mail-lists/delegate; ls */*|wc; time wc */*
   13170   13170   92358

→元データは13,170ファイル（メール）あります。

   1380816 4872868 67333860 total
   2.330u 5.510s 0:39.41 19.8%     0+0k 0+107io 0pf+0w

→全体で67メガバイト(平均で5Kバイト/メール)。

  % time any2fdif -q -b dgmlja -r /tmp/mail-lists/delegate
  ...
  Indexed: 13172 (with Author: 13170+0)
  18.110u 22.460s 1:07.31 60.2%   0+0k 0+774io 0pf+0w

→any2fdif は wc の2倍程度の速度です(^^)

  % ls -l bank/dgmlja
  -rw-r--r--  1 yutaka  wheel   0000000 0X Oct 16:09 dgmlja.desc
  -rw-r--r--  1 yutaka  wheel  46177080 12 Oct 16:09 dgmlja.fdif
  -rw-r--r--  1 yutaka  wheel   0000000 0X Oct 16:09 dgmlja.summ

★any2fdif の処理速度は、約200メール/秒、1Mバイト/秒
（やけにぴったりの数字ですが実測値です）

(1) 辞書有りでの索引作成
-------------------------

  % cd /tmp; mkdir bank; time findex -b dgmlja -cNBW=256 -D

→索引ファイルを /tmp/bank に作ります
→開始時の語バッファサイズを256K語に拡大します
（デフォルトの64Kだと、一時分割索引＋索引併合処理が加わって15%ほど処理時間増大）

  #00     73.735 ... Lex 42.1% ( 220730/ 000000) 00.X% coll.(4106000/000000X)
  #00     73.748 scanned  13172 docs ( 175/s)  8662311 words (115497/s).
  #00     73.755 found 220734 words ... build index
  #00     81.553 registered 8662311 words occurrences (9571751 registered).

→約220K語彙 × 8.6M回参照
  ...
  13172 Documents.
          91.428 Ctx literal=5802310 / position=8662311 (67.0%)

  ConTextFile    34649244 bank/dgmlja/dgmlja.ctx
  XMapFile          52688 bank/dgmlja/dgmlja.map
  DescFile        3372032 bank/dgmlja/dgmlja.dsc
  LexiconFile     4526468 bank/dgmlja/dgmlja.lex
  IndexFile      24341033 bank/dgmlja/dgmlja.idx
  SumFile         1014402 bank/dgmlja/dgmlja.sum
  NumFile          318944 bank/dgmlja/dgmlja.num
  total          00000000 X files
  #### [dgmlja] bank/index.lst
  70.580u 9.060s 1:31.83 86.7%    0+0k 2+39io 0pf+0w

★辞書有り findex の処理速度は、約150メール/秒、95万語片/秒
★作成される索引群は約 68メガバイトで、元データとほぼ同等


(2) 辞書無しでの索引作成
-------------------------

  % cd /tmp; mkdir bank; time findex -b dgmlja -cNBW=256
  ..
  #00     47.901 ... Lex 42.3% ( 221600/ 000000) 00.X% coll.(5842500/0000000X)
  #00     47.914 scanned  13172 docs ( 263/s)  9865950 words (197319/s).
  #00     47.920 found 221601 words ... build index
  #00     55.909 registered 9865950 words occurrences (10775390 registered).

→約200K語彙 × 10M回参照

  13172 Documents.
          67.183 Ctx literal=7467052 / position=9865950 (75.7%)
  ...
  ConTextFile    39463800 bank/dgmlja/dgmlja.ctx
  XMapFile          52688 bank/dgmlja/dgmlja.map
  DescFile        3372032 bank/dgmlja/dgmlja.dsc
  LexiconFile     4521269 bank/dgmlja/dgmlja.lex
  IndexFile      27624722 bank/dgmlja/dgmlja.idx
  SumFile         1014402 bank/dgmlja/dgmlja.sum
  NumFile          318944 bank/dgmlja/dgmlja.num
  total          00000000 X files
  #### [dgmlja] bank/index.lst
  47.380u 9.870s 1:07.52 84.7%    0+0k 44+37io 0pf+0w

★辞書無し findex の処理速度は、約200メール/秒、150万語片/秒
（やけにぴったりの数字ですが実測値です）
★辞書有りの場合に較べて、約25%の処理時間短縮
★作成される索引群は約 76メガバイトで、元データより1割強の肥大
----------------------------------------------------------------------------