オープンソースの分散電子書籍検索エンジンの構築
(github.com/j2qk3b)オープンソースの分散電子書籍検索エンジンを構築する
- 友人の勧めで、ENSドメイン名を使う Liber3 という電子書籍検索ウェブサイトを知った。
- Liber3 は ENS と IPFS を利用して電子書籍検索ウェブサイトを作ったが、ソースコードは公開していない。
- Glitter のドキュメントとデータセットを確認した後、オープンソースのコミュニティ版を自分で実装することにした。
プロジェクトの初期化
- 新しいプロジェクトを作成し、Glitter SDK をインストールすることで、Glitter ネットワークへ簡単に接続し、電子書籍のメタデータを取得できる。
ネットワーク接続
- Glitter ネットワークとやり取りできるクライアントを作成した。
- Glitter SDK を通じて LCDClient インスタンスを初期化し、関連パラメータを設定した。
検索機能の構築
- ユーザーのクエリキーワードを受け取り、クエリ文を構成して Glitter ネットワークへ送信する検索機能を定義した。
検索結果の表示
- 検索機能を構築した後、電子書籍の基本情報を表示するインターフェースを設計し、ユーザーが本を簡単に閲覧して選択できるインタラクティブな要素を提供した。
- これら4つのステップを通じて電子書籍検索エンジンを構築でき、ユーザーに電子書籍リソースを検索する効率的で便利なプラットフォームを提供できる。
- コンパイル済みのウェブサイト版を IPFS ネットワークに公開すれば、IPFS ゲートウェイ経由でアクセスできる分散電子書籍検索エンジンを持つことができる。
- 全ソースコードはこのリポジトリで確認できる。
GN⁺の意見
- この記事は、オープンソースと分散技術を活用して電子書籍検索エンジンを構築する方法を説明しており、技術に関心のある人にとって興味深い内容になりうる。
- 分散データベースと IPFS を使うことは、中央集権型サーバーに依存せずにデータを保存・検索する新しい方法を示し、データの永続性とアクセシビリティを向上させる可能性がある。
- この技術を導入する際には、ネットワークの安定性、検索速度、ユーザー体験などを考慮する必要があり、既存の中央集権型検索エンジンと比べた際の長所と短所を理解することが重要である。
- 類似の機能を提供する他のプロジェクトとしては Project Gutenberg や Google Books API があるが、これらは分散技術を使用していない。
- 分散技術を使うことで、データの所有権とコントロールをユーザーに戻すと同時に、コンテンツの検閲耐性を強化できる。
1件のコメント
Hacker News のコメント
かなり前に、IPFS 上で AI データセットとモデルを似たように扱ってみたいと思っていた
IPFS の未来は分からないけれど、大規模データセットを扱うときに、個人が少ないハードウェアでも問題を解決できるようにしてくれる P2P データ共有インフラの中核が、もっと利用しやすくなるといいと思う
https://github.com/JakeKalstad/IPFSPytorchDataset
https://github.com/JakeKalstad/load_ipfs_pytorch_model
タイトルを見て全文検索をするものだと思い、本当に期待した
Zlib と Google Books はすでにやっているけれど、誰もが貢献でき、全文アクセスまで提供するオープンソース版があれば、素晴らしいプロジェクトになりそう
例: https://openlibrary.org/search/inside?q=%22institutional+thi...
オープンソースで、常に貢献者を探している。特に検索改善の手助けは歓迎されそう
https://github.com/internetarchive/openlibrary/
多くの本が PDF スキャン版で原文テキストがないのが問題で、OcrMyPdf はかなりうまく処理してくれるものの、CPU をかなり使う
本のタイトルや著者だけを探すなら、検索エンジンはすでにいくらでもある
足りないのは電子書籍本文の検索インデックスで、生成 AI の時代にはまもなく非常に重要になるはず
HN では、ノート PC 1 台で数百万冊の本文をインデックス化できると言う人もいれば、規模的にほぼ不可能だと言う人もいた。これをやっているプロジェクトがあるのか気になる
今は自分のコンテンツだけをインデックス化しているけれど、将来的にはコレクションを共有して、ほかの人が本から見つけた関連アイデアを意味検索で発見できるモードを入れたい。現在の動作方式はオープンソースで見られる
[1] https://emdash.ai/
[2] https://github.com/dmotz/emdash
Google が初期にこうした内容を文書化していたと記憶しているが、検索インデックスは特定のクエリに合う関連メタデータを返す。クエリ空間は主に生のキーワードとタプル、記憶が正しければ 2〜3 語の n-gram に基づき、後者は最低出現頻度の条件を満たす必要がある。長い検索語は、より短い n-gram で構成できる
英語の上級ネイティブ語彙は通常約 4 万語で、古い語まで含めた大きな辞書でも 25 万語未満かもしれない
語彙を、その単語を引用した著作物にマッピングするのは比較的単純。n-gram には組み合わせ爆発があるが、それでもかなり限られた空間で、私たちはすでに 25 年以上にわたり Web 規模の文書インデックス化を経験している
ノート PC でも数百万冊について、ある程度実用的なインデックスは作れそうだが、より包括的なインデックス、特に検索空間のランキング用インデックスまでやるには、もう少し大きなシステムが必要になる可能性が高い。おそらくそちらの方が大きな難題だ
最近の仕事でローカル LLM を扱ったが、今は量子化が大きく進歩していても、ThinkPad でこうした作業は可能ではあるものの、4090/H100 を数枚積んだ VPS を数時間借りるのと比べると、やはりかなり見劣りする
要約で一番大きな問題は、ローカル LLM モデルの大半はコンテキストウィンドウがそれほど大きくないため、短い Vonnegut の小説のような大きなテキストでも荷が重いという点。GitHub issue の要約でテストしたが、16k トークンのコンテキストウィンドウでもコメントが多いと時々厳しい
もちろん、私より賢い人なら Raspberry Pi でも動くようにできるかもしれない
根拠はなく推測にすぎないので、もっと知りたい
検索インデックスをどのように埋めるのか、そして想定しているメモリ上限がどの程度なのか、詳しく説明してもらえる？
いいね。トレント検索にも使えるだろうか？
動画ストリーミングができる WebTorrent と分散型検索エンジンを一緒に動かすような形で
オープンソース版も作る予定
同じ技術を使うトレント検索向けのオープンソース版がここにある
これが実際の検索エンジンなのか、それとも
select fromクエリを作ってくれるフロントエンドにすぎないのか気になるこれがいったい何の話なのか分からない
「Liber3 を薦められ、ENS ドメイン名を使い、ENS と IPFS 上で動作し、Glitter を使っているらしく、Tendermint で作られたサービスだ」といった文が出てくるが、別の銀河の言語で届いた宇宙人の信号のように聞こえる
Liber3 というものも試してみたが、何をしても “Oops! Something went wrong. Please refresh or try again later” と出るだけ。これは全部、何を言っているんだ？
IPFS は InterPlanetary File System で、不変の P2P S3 のような分散オブジェクトストレージに近い
Glitter は聞き覚えがあるが、すぐには思い出せない
Tendermint はブロックチェーン向けのコンセンサスエンジンで、Inter-Blockchain Communication(IBC) Protocol や Cosmos SDK とともに、ブロックチェーン間の相互運用性を可能にしようとするツールチェーンの一部
ブロックチェーンのエコシステムは、本当にそれ自体が小さな世界。排他的という意味ではないが、かなり内輪的なので、積極的に探さないと触れる機会はほとんどない
付け加えると、IPFS はデータベースや分散型トラストレスシステムに関心があるなら、ブロックチェーン懐疑派でも見てみる価値がある。内部ではかなり興味深い作業をしていて、チームもほとんどのブロックチェーンプロジェクトのようなゴールドラッシュ的な雰囲気には乗っていない
オープンソースの電子書籍検索エンジンを作るための実装ガイドと見ればいい。もちろんその説明にも多少の専門用語は残っているが、特定のライブラリ名を延々と並べるほどではない
記事の大半は実装の詳細で、親切にリンクが貼られている
そして、それがほぼ 15 年前から存在していて、名前が libgen.rs だったことに気づく