オープンソースの全文検索ソフト
インデックス作るのが面倒なんでインデックス作らないソフトでのお勧めは何ですか？ Snatcherの掲示板より
> とりあえず、QDBMの全文検索機能を日本語化しただけのものを作ってみました。
> 以下の場所に置いてあります。
>
> http://estraier.sourceforge.net/
全然気がつかなかったけど、キテタ━━(ﾟ∀ﾟ)━( ﾟ∀)━( ﾟ)━( )━( )━(ﾟ )━(∀ﾟ )━(ﾟ∀ﾟ)━━!!!!! うへ、QDBMもEstraierもリリース頻繁杉…
いや、まあいいことなのかもしれないけど、人柱になるのも大変だな。 とか言ってる間にもまた新しいバージョン出てるし。
ハングルの需要とかあんのか？ > ハングルの需要とかあんのか？
少なくとも日常的にハングルの読み書きをしている人たちには
需要はあるんじゃない？ Estraierに移行するからSnatcherの保守は停止するって掲示版に書いてあった。
それはいいとして、代わりにできたMLが英語だけっぽいのがどうにもこうにも。 msearch使ってるひといる？
namazuより導入簡単だしカスタマイズも簡単だし。 >1 は、「全文検索」と「Index検索」を間違えてないか？
namazuは全文検索じゃないぞ。
スレタイ見たときに、「grepの話か？」と思ったんだが。 >>91は日経Linuxのアレな記事を鵜呑みにしているアフォ。
平河町の書き換えも困ったものだ。 >>93
で、全文検索の正確な定義って何？
俺は当時あの記事みて考え込んだYO 記事のことは知らんけど、
ファイル名や更新日などから特定のファイルを見つけ出すのと違って、
ファイルの内容からキーワードを拾ってファイルを探すのが全文検索。
全文検索にとってINDEX検索とは、検索の一手段ということになる。
って感じか。
>>96
その定義だと「全文」の言葉を使うのはおかしいんでねーの？
むしろ「ファイル検索」というのがふさわしいと思う
あくまでテキストすべて（全文）を検索するから「全文検索」じゃないの？
だったらやっぱりINDEX検索だけだと全文検索の要件を満たさないと思うなー
NamazuがINDEX検索だけなのかどうかは分かりませんが インデックスを作るにあたって記事の全文を対象にしてるわけだから、全文検索と言えるでしょ。
やたら狭義に解釈してもしょうがない。 >>99
INDEX作成はNamazuだと自立語だけしか対象にしないんじゃない？
それって全文対象と本当に言えるのかね
例えば「萌え語INDEX」を作って検索したとしても全文検索？ >>100よくわからんが grep なら全文検索なのか?namazuは中身を区切ってindex作って検索するから全文検索ではないと? 語の境界を無視するような検索がしたいときに悲しいとか、そういう話かな…
Namazu は二語のフレイズ検索には対応してて、三語以上は誤認識が入るってことみたいだけど。 >>101
とりあえずgrepは全文検索だよね。指定したファイルについては
全文をだーっとナメてるわけだから
だけどそれだと検索時間がかかるから、いわゆる全文検索ソフトは色々工夫をしてる
そのひとつがINDEX作成なわけですよね
で、私が思ったのは、その工夫によって「全文をナメる」のと違う結果（検索洩れとか）
が出るようなのは「全文検索ソフト」とは言えないんではないかってことです
先に挙げた「萌え語INDEX」は極端な例に見えるかもしれないけど
俺としては「自立語INDEX」（かどうかは知らんですが）も「全文をナメるのとは違う」
って意味では同じだと思う
>>102
フレイズ検索云々を意識しなければならない点で変な気がします
もちろん実用的には問題ないと思っていますし、Namazuは良いソフトとも思いますが
grepで検索するときって、フレイズ検索とか意識しませんよね？
>フレイズ検索云々を意識しなければならない点で変な気がします
日本語で分かち書き処理しないでどうやって処理するの？ >>104
分かち書きは全文検索に必須ではないですよ
N-gramとか他にも方法はあるかと
それを検索に使うと効率が悪いように思えるんだが、どうよ？
ttp://www.ya.sakura.ne.jp/~moro/resources/ngram/ N-gramって海外ではむしろ言語及び文字セットの判別の方で
よく使われているような気がする。mnoGoSearchのところの
mguesserとか。 >>106
N-gramだとノイズが増えるのは確かだよ。だけどそのリンク先にあるように検索洩れが少ない利点がある
どっちを使うかは用途次第で一慨に効率が良いとか悪いとかは言えないと思う
だけど今問題にしてるのはそういうことではなくて
検索洩れが生じるような検索方式は全文検索ではない、というのは結構的を射ている指摘じゃないかってことです
もちろん全文検索でなくても有用ならそれで言い訳だし、そもそも全文検索の定義が曖昧なら
どっちでも良いってことだろうけどね
>>109
特許検索とか、洩れが許されない用途での全文検索だとN-gramも結構あると思うよ
何にしても海外とはテキストの性質が全然違うので用語にしても同じ扱いをするのはマズいのかもね
>>94氏が指摘している対立点は、全文を対象としているかいないか、ではなく、
あらゆる検索パターンを検索できるかできないかだと思う。
「全文全パターン検索」ではないと言いたいんでしょ。 >>111
うーん。それよりも「なぜ全パターン検索できないの」→「全文を対象にした検索じゃないからでしょ」
という感じでしょうか。つまり検索対象がfull textならば、全パターン検索できて当然
できない理由はINDEXから情報が欠落しているから、つまりfull text searchではない、という考え方です
結局は「全文検索」って何よ？という定義の問題になるわけですが…
そんなに全文検索がいいなら おれが書いてやるよ。
#! /bin/sh
grep $1 / >>113
乙!
使ってみたYO!
$ ./search.sh gorua
grep: /: Is a directory 文書の編者が意識的に選んだキーワードを頼りにして検索する「キーワード検索」との対比で、
対象文書のテキスト全体を操作して抽出した語やフレーズを頼りに検索する手法を総称して
「全文検索」と呼んでいるのだと思われ。
とすると、必ずしも再現率が100%である必要はないんじゃない？ 「全文検索」の「全文」は、grepが対象とするところの、いわゆるプレーンテキスト
の「全文」とは、抽象度が異なるものでしょう。 >>115
キーワード検索ってそういう意味なのかな
単に「キーワードを使った検索」じゃなくてですか？
初めて聞いたんで、そういう用例のWeb文書とか示してくれると嬉しい
>>116
説明が抽象的すぎて分からん
抽象度がどういう風に異なるのか説明してけれ まぁ、定義は馬場さんのページに書いてあるのが
わかりやすいんでないの？
おれは辞書を使わない，わかち書きしないタイプの
インデクス作成型検索エンジンを使ってるけど。 「全文検索」を細分化して概念化しておくことには意味はあるだろうね。
「完全全文検索」とかさ。 >>119
馬場さんのページってこれですよね
http://www.kusastro.kyoto-u.ac.jp/~baba/wais/
http://www.kusastro.kyoto-u.ac.jp/~baba/wais/other-system.html
私の見落としかもしれませんが、ここには全文検索システムの定義は
無いように思います。定義部分を教えてくれませんか
ちなみに「全文検索とは」でぐぐったらこんなのがありました
「漏れなく」なんてあるから私の見方に近いかも
http://www.rosei.or.jp/ISearch/help/user/japanese/is-us02/is-us007.htm
>>115さんの言うキーワード検索の用例もありました
つーか一般的な用法みたいですね失礼しました
http://www.ftsanet.com/dbtokyo02/Db02.htm
http://magazine.fujitsu.com/vol48-3/3-2.html
http://panasonic.biz/it/patlics/faq_1.html
つまり全文検索＝フリーワード検索ってことでFA？
ん？それってやっぱりINDEX検索単独じゃ全文検索じゃないってことか？
詳しい方、スパっと疑問を解決してくだされ 例えば「走る」について知りたい時は、「走った」とか「駆ける」といった単語を含む文書も
ヒットしてほしいわけです（そうではない場合もあるでしょうが）。
そのために、形態素解析、ステミング、シソーラス展開といった手法を応用している全文検索
システムも多くあります。
それらはもはやパターンの厳密な一致を探すのとは違う領域にある技術ですよね。
どっちが上とか下とか言うわけではないですが、、、 >>122
そういった要望がありそれを実現するための技術があるのは分かります
で、その技術で検索幅が広がるのはいいんです。ブレるのは検索パターンの方であって検索対象はfull textですから
ただ、ここで問題にしてるのは、そういった工夫によって検索漏れが生じるようなシステムが「全文検索」の名に値するかってこと
しかも検索漏れの原因が「INDEXに検索パターンがのってない」ってことにあるなら
「それって検索対象がfull textじゃないじゃん」つまり「全文検索ではない」と思う人がいてもおかしくない
まぁ、ここ数日で「全文検索」という用語がかなり曖昧に使われているのが分かって来たんで
厳密性を求めるのは野暮ってもんでしょう。そして日経Linuxが嘲笑されたのは、まさしくこの「野暮」が原因でしょうな
実は私もあの記事を読んで最初カチンと来た。馬鹿じゃねーのとも思った
だけど上で書いたように「全文検索」をgrepと同様、検索漏れのないシステムと考える人もいるとした場合、
野暮をおしてああ書くのは親切というか、良心的なんじゃないかと思い返したわけです でさ、>>122氏が言うように私の言う狭義の全文検索システムであろうがなかろうがどっちでもいいわけです
実用上は、ユーザーが特性を理解して、目的に合わせて使えば良いわけです。Namazuが有用ってことにも異義はないし
でもだったらさ「全文検索システム」と言わなくてもいいわけじゃん。「語句検索システム」とか誤解のない言い方はあると思う
（この用語はあくまで例で最適とも誤解がないとも言いませんが）
「全文検索」という用語には、そんなに魅力があるんすかねぇ 閑話提供
ttp://www.jepa.or.jp/ken/Ken_00.html
繰り返しになりますが、全文検索は、
「属性やキーワードを改めて付与するなどの手間をかけずに、機械的にテキスト全体をスキャンし、
ユーザが所望の文書を捜し出す技術」
の総称なわけです。
grepの文字列探索は、全文検索を実現するにあたって実装方法の一つであることは確かです。
もちろん、予め文字列から単語を切り出してインデックスを作成する手法も、実装方法の一つです。
インデックス型の弱点として、単語の切り出し方がユーザの想定するものと違う場合に期待通りに
検索できないということがありますが、それは速度と精度のトレードオフを考えて実装上の選択を
した結果に過ぎません。つまり、「全文検索」は目的であって、実装については言及していないという
わけです。
そもそも、全文検索という語に定着した意味や用法が、自分の想定したニュアンスと違うから
といって、「お前ら間違ってるよ」的な事を言っても仕方のないことです。 >>126
繰り返しとか言ってるけど、そういう定義をまとめてくれたのはこのスレでは初めて聞いたよ
定義してくれたのは感謝するけど、一応
つまりあなたの定義だと「萌え語辞書」を使った「萌え語INDEX」を使ったテキスト全体をスキャンする検索システムは
何の注釈もなく全文検索システムと言っていいわけですね。何か一般に想定する全文検索システムと違う気がするけど、いいんですか？
それともこういう仕組みは「属性を改めて付与」することになるので違うってこと？
だったら何で「自立語」という属性は付与していいの？
>>「お前ら間違ってるよ」的な事を言っても仕方のないことです。
何だかんだ言ってるけど、私も全文検索システムの解釈にブレがあるのは理解してるわけよ
だったらさ誤解がないように、より厳密な用語を使って行こうという気はないの？
結局、誤解して困るのはユーザーなんだし
ああ勘違いしてた。Namazuでは付属語を捨てたりはしてないのか
「自立語」というのは「形態素」におきかえてくだされ。それでも文意は変わらんと思う
> 何だかんだ言ってるけど、私も全文検索システムの解釈にブレがあるのは理解してるわけよ
> だったらさ誤解がないように、より厳密な用語を使って行こうという気はないの？
> 結局、誤解して困るのはユーザーなんだし
例えるなら「スポーツカー」に厳密な定義ができないように、「全文検索」にも厳密な定義は
できないと思います。乗る人がスポーティだと思ってくれるような車はスポーツカーでいいと
思います。同じように、ユーザが対象文書の全体をスキャンしているような気分で検索できる
システムは全文検索システムと呼んでいいと思います。
もちろん、あなたの感じ方と私の感じ方は違ってあたりまえですから、私があなたの定義を
否定したりはしませんが。 >>129
>同じように、ユーザが対象文書の全体をスキャンしているような気分で検索できる
>システムは全文検索システムと呼んでいいと思います。
やっぱそんなぐらいの曖昧な用語だってことですかね。「気分で」という表現いいなw
>>130さんの言うように俺定義の話を続けてもアレなんでこの辺で私は終了にしますわ
形態素解析方式の全文検索エンジンは実用にならないってのは一般的な見解ですか？
俺的には、シビアなユースケース（特許検索とか）でなければ十分使えるというか、
大抵のケースではn-gram方式より使いやすいと思うのですが。 #! /bin/sh
find / -print | xargs grep $1
>>133 なんで find なの? 普通は grep -r では? >>135
それはGNU grep 2.3以降の機能。
N-gram をつかったフリーの全文検索ソフトはありませんか？
検索対象のファイル数は数千ファイルです。 gonzui: ソースコード検索エンジン
http://gonzui.sourceforge.net/
Rast - N-gram based full-text search system
http://www.netlab.jp/rast/
Estraierの中の人の開発メモ。Hyper Estraierを作るらしい。
http://qdbm.sourceforge.net/mikio/rbbs.cgi 朱雀、v2 リリース
ttp://hoshizawa.no-ip.com/suzaku/ 全文じゃないのですが、イメージ検索できるエンジンってないでか？
相当ググったんですが･･･やはりないんですかね？ 4 名前：仕様書無しさん[] 投稿者：2005/04/12(火) 00:17:42
blogWatcher
http://www.lr.pi.titech.ac.jp/blogwatcher/blog/
が検索エンジンを情報処理振興事業協会（ＩＰＡ）が実施した
「独創的情報技術育成事業」の研究成果であるGETAから
オープンソースで開発されているLuceneに変更したのは
GETAが税金を無駄にしただけの糞で鈍間で役立たずの
ポンコツだと言うことですか？
Namazuだと、全然文字が引っ掛からない（INDEX作成にはkakashi, chasen,
どちらも使ってみました）のです…
INDEX自体はまともに作成されてるようなのですが、
そもそも、適切に分ち書きできてないみたいです。
何か設定を変更することで上手く行くようになりますでしょうか。 mknmz -L jaでインデックス作るとどうよ。
>>154 LANGUAGE とか LC_ALL の環境変数が ja になってないと
日本語keyword 正しく生成しないんだが、その話しか？ >>159
> そうなの？今はどうなの？
…… (あきれている) >>154
あるねぇ、あれは酷い。
まぁ、FAQには書いてあったからいいけど。
さっさと捨てるべきだとおもったよ。 rast ML 発見
http://www.netlab.jp/rast/index.html.ja#label-12
rast 0.3.0 もリリースされてます
http://www.j96.org/w3ml/rast-ja/msg/2
あと matz 氏の morq もついに公開されたようですが…
debian sid な環境ですが動かすことはできず。orz luceneってむちゃくちゃよくね？
小規模なら、何も考えずに使えるし、
日本語もそのまま通る。
俺何か見逃してるかなぁ。 >>165
昔、日本語が使用できなかったとか、Javaベースだからとかじゃない？
使用することに限ればnamazuやHyper Estraierでもいいと思うけど。
>>165
小規模ならいいけど、大規模（10万件以上）だとめちゃくちゃ遅い >>166
LuceneはC#へのポーティングがあるな。 で、世の中 Google Desktop Search とか Spotlight が当たり前になってる今、
みなさん最近は何使ってんの？ >>174
> が当たり前になってる今
なってねーよ。 ご存知の方おられたら教えてください。
Nutchは、AnalyzerにデフォルトでNutchAnalyzerを使っていて、
日本語はインデックス作成時に（クエリー処理時も）１文字ずつに
分解されてしまいます。そこで、bigramでインデックスを張れる
CJKAnalyzerを利用しようかと思ったのですが、nutchのソース修正が
必要でしょうか？ 
