トップページ⇒unix
987コメント301KB

全文検索エンジンEstraier

■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。NGNG
個人用途向けの全文検索エンジンEstraierに関する話題を扱う
スレッドです。

http://estraier.sourceforge.net/
0233名無しさん＠お腹いっぱい。2005/05/10(火) 16:40:20
>>231
軽量高速な更新検出手段の探求/実現が必要ですねッ!!
0234名無しさん＠お腹いっぱい。2005/05/10(火) 16:47:45
>>233
ガンバレー！！
0235名無しさん＠お腹いっぱい。2005/05/10(火) 17:44:25
高速じゃなくてもいいなら、適当にsleepして軽量にすることは可能だろう。
明示的に更新を通知する手段と、更新頻度が高い場所は巡回頻度も高めると
いった工夫を併用すればかなり使いやすくなるんじゃない?
0236名無しさん＠お腹いっぱい。2005/05/10(火) 17:54:10
>>232
そうカリカリすんなよ。歯痛にでもなったか?
0237名無しさん＠お腹いっぱい。2005/05/10(火) 23:44:55
あとOracleのFull-Text Searchは専用のデーモンを立ち上げて監視させる
仕組みになってたと思う。
0238名無しさん＠お腹いっぱい。2005/05/11(水) 18:00:03
ファイルシステムから作ればいいんだっ！！
0239名無しさん＠お腹いっぱい。2005/05/11(水) 18:20:12
>>238
わかった。全部お前にまかすわ。あとはよろしくな。
0240名無しさん＠お腹いっぱい。2005/05/11(水) 18:24:58
あと重要なのは、特定の格納形式/更新形式を持つファイル群を
ハンドリングするプラグインを扱う枠組みだな。
0241名無しさん＠お腹いっぱい。2005/05/11(水) 18:29:16
>>240
わかった。そっちはお前にまかすわ。あとはよろしくな。
0242名無しさん＠お腹いっぱい。2005/05/11(水) 18:53:11
APIがあるからアプリケーション主導で開発できるわけで、
プラグイン機構は不要だと思われる。
それよりPerlかRubyのバインディングを早く出してほしい。
0243名無しさん＠お腹いっぱい。2005/05/11(水) 19:57:37
>>242
いや、じゃなくて、新しい文書扱いシステムを作った側が、
検索エンジンがそれを効率良く扱えるように
一連の設定やプログラミングを行なう枠組みが
いるのではないかという話だ。
02442422005/05/11(水) 22:48:38
なるほど。
更新処理をトリガとして関数が呼ばれる仕組みが大抵のDBには備わっているけど、
一般的な文書扱いシステムではどうなんだろう。
0245名無しさん＠お腹いっぱい。2005/05/12(木) 11:45:47
監視対象のディレクトリがわかっているなら、そのディレクトリに対して
select() かけることで対応できないかなあ｡
0246名無しさん＠お腹いっぱい。2005/05/12(木) 12:18:15
それだとcreatとunlinkは検出できるけど、writeが検出できなくない?
0247名無しさん＠お腹いっぱい。2005/05/14(土) 02:55:39
日本製全文検索が開発中のもよう
Rast: A full-text search system
ttp://www.netlab.jp/rast/

●検索対象となる文書の分野や言語を選ばない
テキストデータを n 個の文字の並びである N-gram に分割して検索を行うため，「検索漏れが生じない」，「辞書の整備が必要ない」という特徴がある N-gram 方式を選べます．
これにより，検索対象となる文書の分野や言語を選ばずに広く利用することができます．

●多様なファイル形式への対応
HTML や Microsoft Word といった多様なファイル形式の文書からテキストデータやタイトルや作成日などの属性情報を抽出し，検索対象にできます．

●全文検索ライブラリの提供
C 言語と Ruby で利用可能な全文検索ライブラリを提供することにより，本ソフトウェアを利用した全文検索を行うアプリケーションを開発することができます．
さらに，ライブラリの利用例として，過去のメールを全文検索できる電子メールソフトを開発します．

●インクリメンタルな文書の追加登録
作成したデータベースに対して，インクリメンタルに文書の追加登録ができます．このため，一度作成したデータベースを作成し直す必要がありません．


誰か試して
0248名無しさん＠お腹いっぱい。2005/05/14(土) 03:58:31
精度とかはまだまだ。euc-jpだとutf-8にくらべてバグが多い気がする。
C APIを提供してるわりにクライアントライブラリまでGPLなのはちょっと痛い。

せめてXMLRPCの仕様を公開してほしいが、だったらEstraierのノードAPIを
待った方が幸せになれそう。

Matzのお膝元のnetlabで開発してるので、Rubyを使ったアプリケーションが
いろいろ出回ってきたら面白くなるのかもしれない。
0249名無しさん＠お腹いっぱい。2005/05/14(土) 17:02:09
Rubyがどうしたとかテストにはtcl使ってね
とか言われた時点でもう、センスつうか趣味
つうか合わないを思いますわ、パスですわ
>>247
0250名無しさん＠お腹いっぱい。2005/05/14(土) 17:18:49
>>249 Perlだったらいいわけか?
0251名無しさん＠お腹いっぱい。2005/05/14(土) 19:50:07
Javaだったらよかったのにね。
0252名無しさん＠お腹いっぱい。2005/05/14(土) 20:45:23
>>251 lucene
0253名無しさん＠お腹いっぱい。2005/05/14(土) 22:58:21
hyperestraier 0.3.8 コンパイルしないな。
ML archive も落ちてる。
0254名無しさん＠お腹いっぱい。2005/05/14(土) 23:58:14
「QDBMのバージョンが古い」に一票 >> 253
02552532005/05/15(日) 07:59:47
その通りだった。トンクス >>254
02562542005/05/17(火) 00:09:15
俺もはまったからさ。
0257名無しさん＠お腹いっぱい。2005/05/25(水) 10:37:35
0.3.10あげ
http://hyperestraier.sourceforge.net/
0258名無しさん＠お腹いっぱい。2005/05/25(水) 16:35:21
インクリメンタル検索がサポートされたね
0259名無しさん＠お腹いっぱい。2005/05/25(水) 22:28:14
>>258
SUGEEEEEEEEEEE!!!!!!!
0260名無しさん＠お腹いっぱい。2005/05/27(金) 18:44:35
rastをCygwinで構築出来た人いる？
0261名無しさん＠お腹いっぱい。2005/05/31(火) 23:04:02
OpenSearch対応してくんないかな
0262名無しさん＠お腹いっぱい。2005/06/01(水) 11:26:51
今日から金曜まで東京ビッグサイトで開催中の LinuxConference では、

6/2 13:00〜 「全文検索システム Rast の設計と実装」
6/3 10:00〜 「全文検索 BOF」

などという企画をやってる。
0263名無しさん＠お腹いっぱい。2005/06/04(土) 22:50:24
げ、昨日か… (;´Д`)ﾊｧ
0264名無しさん＠お腹いっぱい。2005/06/04(土) 23:10:40
Googleの文字が全部四角になってしまいました。
（□←ばかり）どうしてか教えてください。
0265名無しさん＠お腹いっぱい。2005/06/05(日) 00:05:25
坊やだからさ。
0266名無しさん＠お腹いっぱい。2005/06/05(日) 00:20:49
どうすれば大人になれますか？
0267名無しさん＠お腹いっぱい。2005/06/05(日) 00:54:33
>>266
「電車男」という映画を見に行くとなにかヒントが得られるかもしれません。
0268名無しさん＠お腹いっぱい。2005/06/05(日) 18:28:53
噂通り、インデックス作成がやたら速いね。
並列化できればGoogleとかに匹敵するんじゃないか?
0269名無しさん＠お腹いっぱい。2005/06/06(月) 10:22:14
>262
全文検索BOFでは、NAMAZU開発者とRast開発者とHyper Estraierの開発者が
一堂に会して、開発思想とかを語ってくれた｡
ただ、2時間もあった割には突っ込んだ話ができず、薄かった感じがする｡
0270名無しさん＠お腹いっぱい。2005/06/10(金) 22:35:21
Python&Perl&Rubyバインディングキターーーー
http://tokuhirom.dnsalias.org/~tokuhirom/tokulog/1193.html
0271名無しさん＠お腹いっぱい。2005/06/10(金) 23:07:46
コアAPIのバインディングかぁ...
Rastと違ってAPIがリモートとローカルで違うらしいから、
やっぱノードAPIを待った方がいいんじゃないかと思う。
0272名無しさん＠お腹いっぱい。2005/06/10(金) 23:27:57
パフォーマンスを考えるとコアAPI使って自分でサーバ書いた方がよかないか。
RubyとかだとHTTPサーバのツールキットもあるわけだし。
0273名無しさん＠お腹いっぱい。2005/06/11(土) 10:40:11
HTTPd を自前で実装する、というときにパフォーマンスを考えるならスクリプト言語の
バインディングをわざわざ選ぶかなぁ?

むしろスクリプトで書いたプログラムにいちいちサーバ立てるのやってらんないという
面倒くさがり向きなんじゃないの。
0274名無しさん＠お腹いっぱい。2005/06/11(土) 16:42:53
いや、HTTPdを実装すること自体にスクリプト言語が向いていると思う。
Cでなんてやってられない。
0275名無しさん＠お腹いっぱい。2005/06/12(日) 03:31:38
そうかなぁ... libapr とか使ってみれば?
ちょうどいいから rast のソースでも読んでみなよ。

といいながらも ruby が楽しくなりつつある今日この頃です。
0276名無しさん＠お腹いっぱい。2005/06/12(日) 09:49:52
APRはやばいでしょ。
WEBrick+HyperEstraierとかWEBrick+Rastってのが強力かつ簡単でよさげ。
0277名無しさん＠お腹いっぱい。2005/06/12(日) 15:35:53
>>276
ライセンス問題?
0278名無しさん＠お腹いっぱい。2005/06/12(日) 23:07:12
これってCygwinでも動きますか？
0279名無しさん＠お腹いっぱい。2005/06/24(金) 07:37:52
デスクトップサーチっぽいのが出たね。
まだ作りこみが甘い感じだけど、今後に期待age。
http://www.mitsuki.no-ip.com/~seagull/software-archives/hyperestraier/gdestraier.html
0280名無しさん＠お腹いっぱい。2005/06/24(金) 09:56:05
もうでさぽ
0281名無しさん＠お腹いっぱい。2005/07/04(月) 01:40:52
>.279
open/closeシステムコールをを監視してスポットライト風にインクリメンタルアップデートが
できると面白そう。ガンガレ。
まずは更新があったファイルを指定するとその情報のみをアップデートする機能が
必要だな。既存のものだと全部を指定してアップデートする方法しか用意されてないからな。
0282名無しさん＠お腹いっぱい。2005/07/04(月) 18:08:11
>> 281
いちお、estcmdに-sd -cm 付けてるです。
だから全更新してもタイムスタンプの新しいやつ以外はスキップされるですよ。
0283名無しさん＠お腹いっぱい。2005/07/06(水) 00:48:17
>>281
namazuにしろなんにしろ従来のは全更新しかなかったと思うんだよね。
だから、逆に一部更新はできるのかと。
編集した利用者ならどこを編集したかわかっているわけだから全更新して
全部のディレクトリをなめる時間待たされるよりも更新した箇所を指定して
updateできたほうがよくない？

んで、その上でシステムコールを監視してスポットライト風アップデートですよ。
0284名無しさん＠お腹いっぱい。2005/07/06(水) 03:03:16
システムコールの監視はカーネルに手を入れるかアプリをVM上で動かすか
しないと難しいんじゃない? いずれにしても、オーバーヘッドがでかくなってしまう。
移植性の問題もあるし。

よく更新されるディレクトリの監視頻度を上げるのと、ユーザが明示的に更新を指示
をするのを併用すれば実用上は十分だと思うけど。メールボックスとかだったら、アプ
リケーションのプラグインかなんかで更新ロジックを組み込めるといいね。
0285名無しさん＠お腹いっぱい。2005/07/06(水) 10:40:58
カーネルまで触らなくても、ファイルシステムに細工をすればできるんじゃないか。
Windowsじゃ無理だけど、UNIX系ならそのへん独立してるし｡

WinFSには全文検索っぽい機能が組み込まれているというウワサも聞いたけど、
どうなんでしょ。
0286名無しさん＠お腹いっぱい。2005/07/06(水) 10:49:45
>>283
Hyper Estraierは、ディレクトリでなくファイルそのものを指定して
インデックスに登録できるよ。


>>284
famを使い、特に指定されたディレクトリだけ監視。
移植性と監視コストの問題はfamに丸投げして、各プラットフォームに最適
なアルゴリズムで監視できる事を期待。


更新された時に即座に更新だと確かにオーバヘッドが大きすぎなんで、
遅延してある程度のまとめ更新するデーモンをniceしておけば実用的な
範囲に収まるっぽくね？
いくらなんでも、数分前に更新した文書くらい探さなくても判るだろ。


それより問題は、インデックスをユーザ毎に持つと重複が多すぎるって
事だな。サイズもそうだけど、オーバーヘッドも整数倍になる。
業務の書類とかmanページを探したい時なんか完全に重複だね。

インデックス中の文書データに対するパーミッションをなんとかして、
システムグローバルなインデックス&検索機能のデーモン化をしないと
現実的でないような気がしてきた。
0287名無しさん＠お腹いっぱい。2005/07/06(水) 11:04:33
>>285
ファイルシステムオーバーライドするのは面白そうなんで、
LUFS使って簡単に実装しようと思ったけど、
/usr をすげかえる気にならないし、対象ディレクトリが増えた時に
fstabの構成変えるのも馬鹿らしいので廃棄処分にしますた。
0288名無しさん＠お腹いっぱい。2005/07/06(水) 15:04:04
数分前に更新した文書っていうけど、自分が更新したとは限らないのが問題。
事実、どっかからダウンロードしてきた文書をすぐに全文検索したくなる
ことは多い。それを考えると、やっぱり手動更新指示の機能もほしいよね？
Hyper Estraierの更新処理は異常に速いから、検索窓の横に「更新」ボタンを
つけておいて、結構気軽に更新をかけさせても実用になると思う。

ラジカセのメタファを使って、「再生（右向きの三角）」で検索をして、
「録音（丸）」で更新をして、「停止（四角）」で検索や更新の停止をして、
負荷状態を音圧っぽく表現するというのも面白いかもね。
0289名無しさん＠お腹いっぱい。2005/07/06(水) 16:25:21
>>288
...目的のファイルが判ってるなら、grepした方が早いような気がする...
でもまぁ、同時ログインしてる別ユーザもいるから、確かに遅延はかなり小さく
しないと厳しい状況がありうるだろうね。

更新ボタンを置くのはいい考えなので、Quick build機能付けるよ。
0290名無しさん＠お腹いっぱい。2005/07/06(水) 19:04:30
>>286
デスクトップ検索アプリを目指すなら、マルチユーザのインデックスの共有はそれほど考え
なくてもいいんじゃね?
自分のホームディレクトリを対象にしたインデックスさえ作れればほとんどのユーザは満足
でしょ。デーモン走らせないと使えないのは初心者向けでないような気がするよ。
副次的な機能として、他人のインデックスをリードオンリーで開けるようにして、チェック
ボックスをオンにすればそこの結果もマージして表示できるといいかも。
つまり他人のインデックスを更新できる必要はないってこと。
manとかの共有物のインデックスはrootで最初に作っておいて、/var 以下においておけば
いいんじゃない? その更新もわざわざデーモンにしないで、cron実行で十分でしょ。
0291名無しさん＠お腹いっぱい。2005/07/06(水) 20:47:50
>>290
基本的にはそうなんだけどさ。
manなら問題ないけど。rootで作ると、本来ユーザに読み込み権限の無いファイルも検索
できて、要約も見えちゃうわけじゃん。
かといって、権限単位にインデックス作るというのも現実的でないし。
業務用の、たとえ共有ディレクトリに入っている技術経歴書とか、仕様書とかを対象と考えた時、
細かい制限ができないと問題だと思ったわけ。

つーわけで、ホームユーザには間違いなく十分だけど、職場で活用となると問題があるわけよ。


試してないけど、
> 副次的な機能として、他人のインデックスをリードオンリーで開けるようにして、チェック
> ボックスをオンにすればそこの結果もマージして表示できるといいかも。
これは現段階でできるような気がする。
今現在、検索用にはDBをリードオンリーで開いてるし、マージもデフォルトだし。
Hyper Estraierはリードオンリーで複数プロセスがオープンしても平気だし。


ってか、みんなのところでちゃんとビルドできてる？、、、って、だれも試してませんか、そうですか。
0292名無しさん＠お腹いっぱい。2005/07/07(木) 00:53:57
見せたくないファイルはインデックスに入れないようにするしかないんじゃないか?
一般ユーザの読み込み権限（S_IROTH）がついているファイルだけ読み込むように
すれば大抵は大丈夫だと思うけど。
0293名無しさん＠お腹いっぱい。2005/07/07(木) 13:16:11
>>286
> Hyper Estraierは、ディレクトリでなくファイルそのものを指定して
>インデックスに登録できるよ。

　・・・できないんですけど？
>第3引数としてファイル名を指定すると、そのファイルから処理対象のパスのリストを読み込みます。
　って書いてあるし・・・
0294名無しさん＠お腹いっぱい。2005/07/07(木) 13:43:20
>> 293
そのリストにファイル名書くんだよ。

find . -name '*.txt' | estcmd gather オプション インデックス -

0295名無しさん＠お腹いっぱい。2005/07/12(火) 00:26:37
howmはこっちをサポートしてくれるといいんだけどね。
Cygwinを使えるし。
0296名無しさん＠お腹いっぱい。2005/07/12(火) 16:15:12
Hyperの方ってCygwinじゃなくてネイティブのWin32じゃなかったっけ?
Cygwinでも動くのかなぁ。
0297名無しさん＠お腹いっぱい。2005/07/16(土) 23:16:11
> Hyper Estraierの最終目的はP2P型の分散処理に支えられた高速で高精度な検索システムを構築することですが、

そうだったのカー (AA略
0298名無しさん＠お腹いっぱい。2005/07/17(日) 03:20:26
ノードAPIキターーーー(ﾟ∀ﾟ)ーーーー！
0299名無しさん＠お腹いっぱい。2005/07/17(日) 20:23:17
namazuの改良したいんですが、キーワード毎に重み付けするような
プログラムってどうすればいいかわかりますか？？
調べてもわかんないです。本でもなんでも教えてほしいです。。。
0300名無しさん＠お腹いっぱい。2005/07/17(日) 21:44:47
>>299 http://pc8.2ch.net/test/read.cgi/unix/1113150661/
03012992005/07/17(日) 21:48:42
>>300
サンクス
0302名無しさん＠お腹いっぱい。2005/07/19(火) 13:36:11
うーん、estmasterが動かないなぁ。 libsocketって何だろう?
0303名無しさん＠お腹いっぱい。2005/07/19(火) 21:32:11
ソケットのライブラリだろ。LD_LIBRARY_PATHがおかしいんじゃない?
0304名無しさん＠お腹いっぱい。2005/07/20(水) 10:11:12
>>303
アドバイスどうも。libsocketはソケットの抽象化ライブラリみたいだね。
ふつーのglibcソケットだけでも大丈夫みたいだけど。

起動はするが、ポートを叩いてもうんともすんとも言わないという状況だから、
ダイナミックロード関係じゃなさそう。ちなみにOSX(panther)の話ね。


Debianならあっさり動いたからDebianホストでestmasterを動かす事にするよ。
0305名無しさん＠お腹いっぱい。2005/07/22(金) 22:32:56
gdestraier-0.1.6 リリースしたよ。
ttp://www.mitsuki.no-ip.com/~seagull/software-archives/hyperestraier/gdestraier.html

誰も気にもかけて無いらしいけど。
0306名無しさん＠お腹いっぱい。2005/07/23(土) 11:27:34
こんなとこにアナウンスしてもしょーがないでしょ。
FreshMeatとかSourceForgeに登録したら?
0307名無しさん＠お腹いっぱい。2005/07/24(日) 01:19:46
sargeで使ってみようとしたら必要としてるライブラリのバージョンが
新しすぎで無理だった。>gdestraier
0308名無しさん＠お腹いっぱい。2005/07/25(月) 20:23:32
java版APIも出たねぇ。
デスクトップ検索もJavaで作った方がいいんじゃねの?
クライアントは多少重くても問題ない。その上でさらにアプレット
みたいなプラグインを動作させられるようにすれば、Spotlightに対抗でき
るかもよ。
0309名無しさん＠お腹いっぱい。2005/07/25(月) 20:29:10
>>308
> java版APIも出たねぇ。
> デスクトップ検索もJavaで作った方がいいんじゃねの?

そんな事したら、死に体になってしまう。
0310名無しさん＠お腹いっぱい。2005/07/25(月) 21:18:43
ライブラリのバージョンは、とりあえず手元のsidに入ってるやつ参照しただけなんで、
下げても大丈夫だと思う。
とりあえず、sarge準備して試してみますわ。

>>308
重いにも限度があると思う。
起動がトロかったり、フットプリントが許容できても、サクサク間がでないと。
もっとも、いま現在は単一スレッドで要約まで出してるから、サクサクとは言いがたいけど。

目標は、nautilusでディレクトリたどるより手軽に絞りこみ検索できる事。
0311名無しさん＠お腹いっぱい。2005/07/26(火) 11:37:21
きょうびのPCのパワーならJavaでもサクサク動くと思うが。
つーか移植性が確保できる（LinuxでもWindowsでもMacでも動く）のが重要だろ。
sargeやら何やらのレベルで非互換がでてるようじゃ流行らないと思われ。
0312名無しさん＠お腹いっぱい。2005/07/26(火) 20:29:41
>>311
実際に試せばわかると思うが「サクサク動かない」よ。
0313名無しさん＠お腹いっぱい。2005/07/26(火) 21:40:39
>>311
意味不明。Javaって、必要なランタイムライブラリがインストールされてなかったり、
バージョンが適合しなくても問題無いって？
0314名無しさん＠お腹いっぱい。2005/07/27(水) 03:19:30
起動はサクサクしないだろうけど、そんなに遅いわけでもないだろう。
実装テクニックの問題だったりしないか?
0315名無しさん＠お腹いっぱい。2005/07/27(水) 07:41:42
テクニック云々以前にJVMの起動が遅いんでしょ。
もしかして最近は違うの?（＞＜）
03163152005/07/27(水) 07:42:59
すまん。寝惚けてた orz
0317名無しさん＠お腹いっぱい。2005/07/27(水) 09:18:23
Write once, Debug anywhere.

0318名無しさん＠お腹いっぱい。2005/07/27(水) 09:47:33
JRE入れるのは.NET Frameworkを入れるのと同じようなもんで、大抵のユーザは
抵抗なくやってくれるでしょ。J2SEのコアライブラリ以外に必要なランタイムが
あったとしても、それも同梱してしまえばいい。

別にJavaマンセーと言うつもりはないけど、GNOMEやGTK+のバージョンの違いに
悩まされるのは普通のユーザには耐え難いことだよ。依存関係が連鎖している
から、作業途中で嫌になってやめてしまう人が多いと思う。かくいう俺もそれで
gdestraierの利用を断念した。
もしもDegianやVineなどのディストリビューションに標準採用されたとしたら、
そういう苦労はほとんどなくなるかもしれないが。
0319名無しさん＠お腹いっぱい。2005/07/27(水) 10:20:17
gnome よりは java のほうがまだましだけど，とりあえずコマンドラインで使
えるようにしてくれないと不便だにゃぁ．cgi から叩きたい時もあるし．
0320名無しさん＠お腹いっぱい。2005/07/27(水) 10:25:32
コマンドラインのツールならHyper Estraier自身に含まれてるじゃん。
0321名無しさん＠お腹いっぱい。2005/07/27(水) 10:35:27
Java って Debian だと non-free 扱いじゃなかったっけ?
0322名無しさん＠お腹いっぱい。2005/07/27(水) 11:11:02
kaffeとかgcjとかで動くならmainにいけるよ。
0323名無しさん＠お腹いっぱい。2005/07/27(水) 16:43:19
>>318
作者がコミュニティを小さく保ちたいとは考えていないとか、
windows進出でgoogledesktopなどと張り合う事を考えている
という前提はそもそも正しいの?


ところで、>>304 の問題は0.5.1で解決した。
いまはest_free_net_env()してからest_init_net_env()するとSEGVるので
悩んでいる。
03243182005/07/27(水) 22:39:59
>>323
張り合うっつーか、公開するぐらいだから、ユーザは多い方が嬉しい
かなと思って書いただけ。本当のところは作者氏の弁を待つしか。
0325あうたん2005/07/28(木) 18:09:01

みなさまはじめまして
最近「Estraier」なるものの存在に気づき社内のデータの検索エンジンをWindows
ベースで構築できないかと考えているものでございます。

ここ最近Windowsバイナリが公開されまして早速つかってみました。検索スピード
に驚くばかりでこれはかなりイケてるなと思ったのですが、やはりn-gram検索の
スコアでは検索時にTOPに出てほしいものがでてきてくれません。
そこでインデックスを何とかして指定したもののスコアをあげたいのですが、やはり
そういうことは難しいのでしょうか？スコアをいじること自体がn-gramの検索の精神
に反していることは理解しているのですが、なんとかしてスコアを補正して特定の
ものを検索の最初にヒットさせたいのです。
これは「Estraier」の問題ではないと思いますが　特定のファイルをスコアの重みを
調整する術はないものでしょうか？（たとえばたくさんのアクセスがあったファイル
は最初の方に表示したいというものです）

皆様のお知恵をお貸しいただければ幸いです

　　　　　　　　　　　　　　　　　　WindowsXP+Apache1系+estraier-1.2.28-win32
0326名無しさん＠お腹いっぱい。2005/07/28(木) 18:57:55
全てをEstraierにやらせる必要もないだろう。
文章にキーワードを設定しておいて、それと一致するものは
Estraierによる検索結果「よりも先に」表示させるとか。
0327名無しさん＠お腹いっぱい。2005/07/28(木) 19:23:57
>>325
スピードが遅くなってもいいのなら、実際いろんな方法があると思うけど。
内部に手を入れてスコア計算をいじくるのもいいし、hyperのAPIで出力結果をバッファして
なんらかのヒューリスティックなソートを掛けるのもいいと思う。

特定のキーワードにだけ高く反応してほしいなら、hiddenテキストに
そのキーワードをたくさん書いておけばtf/idfスコアは当然高くなるよね．
ああ、estraierに隠しテキストはあったっけ?
0328名無しさん＠お腹いっぱい。2005/07/28(木) 20:03:18
たくさんアクセスがあるものを上にするという場合、アクセスログを取る仕組みは
既にあるか、自前で作るんだよね。
ならば、アクセス数をDBでカウントして、10アクセスとか100アクセス毎にその文
書の更新をかけて、その際にアクセス数を属性としてつければいい。検索する際に
は、アクセス数をソート条件にすればいい。
0329あうたん2005/07/29(金) 17:17:49
>>328

皆様ご回答ありがとうございます。

アクセスログを取る仕組みに関してはログからなんとかいけそうな気配なんですが
理解力がなくアクセス数を属性としてつける部分がよくわかっていないのです。

ドキュメントには
estcmd gatherで特定ディレクトリのインデックスをつくるところまでは理解できたの
ですが、そこから特定なファイルにのみ属性情報をつける方法が分からないのです。
前身のEstraierではestindex registerでできるようなことが見受けられるのですが、
今回のHyperEstraierでは特定ファイルに対する属性情報（アクセスの頻度による
表示の重み）はどうやってつければいいのでしょうか？

例えば重みを数値（一番先に表示したいものは1000とかその次は999とか）で表現
できると表示順を制御しやすいのですが

またその際にソートは「属性情報（表示の重み）」・「n-gramによるスコア」という順序
でソートがかかるのでしょうか？

教えて君で申し訳ありませんが皆様のお知恵をお貸しいただければ幸いです。


0330名無しさん＠お腹いっぱい。2005/07/29(金) 18:16:55
estcmd putでできるのではないでしょうか。
0331名無しさん＠お腹いっぱい。2005/08/01(月) 05:30:52
>>329
0.5.3のestcmdならいちいちドラフト形式にしたりせずにできるんじゃないの。

あとn-gramはスコアの計算方法じゃないよ。
スコア計算はtf/idfで、namazuなんかと基本的にいっしょ。
0332あうたん2005/08/01(月) 10:22:43
>>331

> 0.5.3のestcmdならいちいちドラフト形式にしたりせずにできるんじゃないの。

使用しているのは0.5.1のWindowsバイナリ版でした。
そのドキュメントには

　estcmd put [-cl] db [file]

となっていて属性を指定するようなオプションがないようなのです。（T_T
0.5.3では330さんがおっしゃるようにできるのでしょうか・・・


> あとn-gramはスコアの計算方法じゃないよ。

よく読むとそうでした。よく理解しないで用語をつかっていました。（＾＾；

■ このスレッドは過去ログ倉庫に格納されています