オープンソースの全文検索ソフト

オープンソースの全文検索エンジン全般を扱うスレッドです。

ソフトウェアによっては固有のスレッドが立てられている場合もあります。
それらについては適宜リンクを張ります。

Namazu http://www.namazu.org/
Glimpse http://webglimpse.org/
SWISH++ http://homepage.mac.com/pauljlucas/software/swish/
ht:/Dig http://www.htdig.org/

Comparing Open Source Indexers
http://www.infomotions.com/musings/opensource-indexers/

関連スレッド
全文検索ユーティリティ統一スレッド
http://pc.2ch.net/test/read.cgi/bsoft/1006680403/
　ビジネスソフト板のスレッドです。
　主に Windows のパッケージソフトについてのようです。

Microsoftの全文検索ソフト(Indexing Service等)
http://pc3.2ch.net/test/read.cgi/win/1035387243/

「全文検索」の「全文」は、grepが対象とするところの、いわゆるプレーンテキスト
の「全文」とは、抽象度が異なるものでしょう。

>>113-114
warata

>>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

富豪的というか大富豪だな(w

>>133 なんで find なの? 普通は grep -r では?

>>135
それはGNU grep 2.3以降の機能。

Freya を DeleGate の中の人が改造してる模様。
http://www.delegate.org/freyasx/index-ja.shtml

N-gram をつかったフリーの全文検索ソフトはありませんか？
検索対象のファイル数は数千ファイルです。

試してないけど lucene
http://d.hatena.ne.jp/adon/20040719

ウホッ、NutchもASF入りか？
http://wiki.apache.org/incubator/NutchProposal

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

関連スレ

全文検索エンジンNamazu
http://pc5.2ch.net/test/read.cgi/unix/1009715036/

全文検索エンジンEstraier
http://pc5.2ch.net/test/read.cgi/unix/1100221699/

gonzui
http://pc5.2ch.net/test/read.cgi/tech/1102086148/

こんなの発見した
http://tech.yappo.jp/

Rast 0.0.0 released

朱雀、v2 リリース
ttp://hoshizawa.no-ip.com/suzaku/

ruby ML 検索 powered by Rast
http://shugo.net/ruby/mlsearch.rbx

Senna 組み込み型全文検索エンジン
http://dev.razil.jp/project/senna/

gonzui 1.0 released

全文じゃないのですが、イメージ検索できるエンジンってないでか？
相当ググったんですが･･･やはりないんですかね？

>>149
試したことないけど

GNU Image-Finding Tool
http://www.gnu.org/software/gift/gift.html

イメージサーチャ for Java
http://www.sra.co.jp/people/m-asada/Isr4Java/

>>150
ありがとうございます。

心無いこと言うなよ。

Namazuだと、全然文字が引っ掛からない（INDEX作成にはkakashi, chasen,
どちらも使ってみました）のです…
INDEX自体はまともに作成されてるようなのですが、
そもそも、適切に分ち書きできてないみたいです。

何か設定を変更することで上手く行くようになりますでしょうか。

mknmz -L jaでインデックス作るとどうよ。

>>154 LANGUAGE とか LC_ALL の環境変数が ja になってないと
日本語keyword 正しく生成しないんだが、その話しか？

GETAって説明見るかぎりではよさげだけど

>>156
知識が古い

>>158
そうなの？今はどうなの？

>>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

gdestraierの使用レポきぼんぬ。

luceneってむちゃくちゃよくね？
小規模なら、何も考えずに使えるし、
日本語もそのまま通る。

俺何か見逃してるかなぁ。

>>165
昔、日本語が使用できなかったとか、Javaベースだからとかじゃない？

使用することに限ればnamazuやHyper Estraierでもいいと思うけど。

>>165
小規模ならいいけど、大規模（10万件以上）だとめちゃくちゃ遅い

>>167 何か設定やらチューンやらできないの？

>>168
自分で下層のDBを用意する

Nutchってその辺どうしてるんだろ？

なまずがもうすぐバージョンアップするって本当？

>>171
きたよ

>>166
LuceneはC#へのポーティングがあるな。

で、世の中 Google Desktop Search とか Spotlight が当たり前になってる今、
みなさん最近は何使ってんの？

>>174
> が当たり前になってる今
なってねーよ。

ご存知の方おられたら教えてください。
Nutchは、AnalyzerにデフォルトでNutchAnalyzerを使っていて、
日本語はインデックス作成時に（クエリー処理時も）１文字ずつに
分解されてしまいます。そこで、bigramでインデックスを張れる
CJKAnalyzerを利用しようかと思ったのですが、nutchのソース修正が
必要でしょうか？

pluginをいじるだけでできるかと調べたのですが、
なにぶんドキュメントが少なくて、よくわかりませんでした...。

ttp://wiki.apache.org/nutch/MultiLingualSupport
ttp://mail-archives.apache.org/mod_mbox/lucene-nutch-dev/200606.mbox/%[email protected]%3E

Google や Yahoo! がやっているような、表記揺れの展開をやってみたいのですが、
全文検索ソフトと併用できるような便利な表記揺れ展開用の辞書かライブラリってあるのでしょうか。
それとも自分で辞書を作らなければならないのでしょうか。

代用漢字、異体字、カタカナ語、送り仮名、検索ワードの誤り、略称、関連語など、
考え出すときりがないとも言えるのですが…
企業向けの商用ソフト（の形態素解析ソフトのおまけ？）にはあるらしいことは一応わかってきました。

なにかアドバイスください。

>>179
どこかの国立の日本語研究所が表記揺らぎ辞書を公開してたよ。

国立国語研究所の「表記統合辞書」ですね。ありがとうございます。

kokken.go.jp がつながりにくいようですが…
必要に応じて電話で問い合わせしてみようかしら。

風博士ではRastが死亡認定された模様。

html内で、コメントを使わずにスタイルシートのhiddenを使ってコメントアウトしているページがあり
NAMAZUはもちろん対応していないのですが、対応できる検索エンジンってあります？

多分ない。

>>184
そうですよね。googleでも引っかかってしまうし。

対応ってどういう意味だろう。
そこが検索でヒットされて欲しくないってこと?
そんなエンジンはないだろうな。

対応できるってどういう意味だろう。
「作ればあるもん」だと思うのだが。

rastって死亡? なんか実質1年くらい動きがなさそうなんだけど。
matzがいるような会社でも、IPAから金めぐんでもらってやってただけで
それがなくなったら後は野となれ山となれなのかね? もしそうだったら寂しいね。

>>188
長い目で見れば、死亡させた方が金になるんだよ。

Hyper Estarierは未踏で開発が加速して、今はまったりとしつつも
きちんと続いている。
SennaもMySQL連携が効いたのか、じわじわと利用が進んでいる。

Rastはなあ... 構造を複雑にしすぎて、金が切れてからのメンテナンスが
難しくなったんじゃないかという気がする。あとは外部からの開発者を
集められなかったことが敗因か。

H.E. も個人開発だけどね

>>190
> 難しくなったんじゃないかという気がする。あとは外部からの開発者を
> 集められなかったことが敗因か。

いや〜
金をもらって作られたブツの世話を引き継いで、タダで作業するのって、惨めだぞ〜
特に多大な金が投入されたことをみんなが知っていると、いろいろあって鬱病になりそうになる。

もう2度とやりたくない。

>>191
作者はじつにいい会社に転職したよね。今後も安泰かというと不安だけど...
>>192
気持ちはよくわかる。最低限、「自分が使うから」ぐらいのモチベーションが
ないとやっていけないよなあ。

>>181
これの固有名詞版ってないのかしらん？

USA、米国、アメリカ、U.S.→アメリカみたいな

人少ないみたいだからアゲますね。

ちょっとダサい質問なんですが、インデックスを作成するタイプの全文検索で
そのものがインストールされていないレンタル鯖で使えるものってありますか？
PerlもしくはRubyから検索したいと思って
Namazu、HyperEstraierを試したんですが、
前者はPerlモジュールのインストールを断られ、
後者はインデックスがQDBMの形式だからどの道無理かと思いました。
(方法があればHEの方は使ってみたいけど）

頻繁に更新されるような対象じゃないので、MySQLのFULLTEXTでも・・・
と思ってはいるんだけど、
なにか方法(ソフト)があればおしえてください。

http://rubyforge.org/projects/ferret/

pure rubyでこんなのがあるよ。日本語が使えるかどうかはわからないけど。
Luceneにinspreされたとかいてあるから、UTF-8なら使えそうな気もする。

>>196
少し触ってみたところ使いやすい感じで好感触でした！
完全かどうかはわかりませんが、日本語も大丈夫でした。
とりあえずレン鯖での動作も確認できました。
まだ不明な点もありますが、しばらく使ってみようと思います。
ありがとうございました！

gonzuiみたいなのでVB6検索できるエンジンありませんかね？

VB6病発病したソースコードを手術しないといけないので
頼みます。

こんなん出てた。
全文検索エンジンLux
http://luxse.sourceforge.net/

ToDo のところに
# 削除・更新
# 全角半角かなの同一視
とか書いてあるあたり見ると、まだ全然未完成みたいだけど。

apacheのluceneがeclipseのヘルプ?で使われていたことを知った。

InfoCrawlerとOmniFindってどう？


今研究室の文書管理システムを作らなきゃいけないんだが,ユーザビリティを損なわず文書管理したい．
ファイルドラッグできるフリーなシステムは見つからない．
⇒Sambaフォルダに適当にぶち込んで後から見るときは検索でおｋ

と言う風に今は考えてるんだが、間違ってないよな？
doc,pdf,ppt辺りを読み込んでくれる素敵なエンジンはない物か…

保守

http://www.jieks.com/2ch/

ど素人の質問で申し訳ないんですが、
ひらがな/カタカナのどちらでも検索可能にしたい場合、
「検索時に、両方のキーワードで検索する」案と、
「インデックス自体を、両方作っておく」案の、どちらが検索時間が短くすむのでしょうか？
（検証しろと言われれば、それまでなんですが）

私の事情的には、「大差はない」というのが理想ですが、
どうなんでしょうか？

ちなみに、使ってるのはLucene（2.3.2かな)で、すでに運用開始している状態です。

常にひらがな/カタカナのどちらでも検索していいなら、
インデックス作るときに、どっちかにまとめてしまうな。
あとは、検索時に指定されたのを同じルールで処理してから検索。

データが小さくなるし、analyzerでこの処理をさせれば、
本文はそのままだから、取り出し可能にもできるし。

あと、データ量と同時検索数次第な気がするけど、
両方のキーワードで検索した方が速いと思うよ。
インデックスを小さくしておいた方が速いと思う。

ひらがな/カタカナ混じりだったらどうするとか考えると、
統一しちゃう方が簡単だと思うんだよなー。

検索用フィールドをいくつか作るのはありかもね。
平仮名片仮名を無視する検索用はどちらかに統一して、
そうじゃない方はそのまま入れておく。

>>206
レスありがとうございます。

やはり「INDEXも検索も統一」というのが良さそうですね。

ただ、すでに運用してるシステムでして、
根本から作り直すことになると、コストやリソースの関係で、
お客様の希望する時期に出せそうになかったもので、
質問のような小手先の対応を考えていました。

dpkgとzeitgeistがXapianっていう全文検索ソフトを使っているけれどあれは何？
対応言語に日本語は入っていないみたい

「俺の全文検索」のソースをアップロードした。

http://www.ne.jp/asahi/sun/patagonia/fulltext/fulltext.html

うまく全文検索できないときには掲示板に書きこんでくれ。

postgresql 使ってるのか。
Hyper Estraier でいいと思うけどなあ。ずっと楽だし

>>209
NOT FOUNDだよ

半年も前かぁ・・・(´・ω・`)

Fessというソフトなんですけど、
検索されたファイルの名前に、スペースが含まれている場合に、
一覧から開くことができません。
対策ってありますでしょうか。

>>212
FessのMLがあるからそっちで聞けば？

聞こう聞こうと思っているうちに、
どなたかがメーリングリストで質問してくださっていました。
今、その回答町です。

全裸変換ソフトって読んでしまった。
寝てくるﾉｼ