RAG構築で、ベクトルDBを使わなかった話を書きました。
RAG構築で、ベクトルDBを使わなかった話を書きました。
対象は科学系の技術専門雑誌の数年分、数万ファイルのPDF。検索役に選んだのは、1990年代から続く日本語の全文検索システム Namazu です。
ベクトルDBではなく Namazu にした理由は3つ:
・専門用語・型番・規格番号はキーワード検索のほうが確実に当たる。意味検索は「近い文書」を返すが、「その語が書いてある文書」を外すことがある
・説明できる。どの語がどのページに当たったかが人にも見える
・軽い。埋め込みモデルもGPUも要らず、社内で完全に閉じられる
検索は枯れた技術に任せ、AIは読んで答える役に限定する。AIの得意不得意を、そのまま役割分担にしました。
正直に書くと、これがうまくいったのは対象が本文テキストのPDFだったからです。スキャンしただけのPDFや手書きが混ざる資料なら、先にOCRの工程が要ります。
土台は当社がKurage App Storeで売っているAIチャットボット。変えたのは1箇所、知識の取り込み口をフォルダのMarkdownからNamazuの検索結果に差し替えただけです。
記事:
https://note.com/tokoname/n/n67a3c638e4cd
カスタマイズのご相談:
https://kurage.exbridge.jp/vibe-customize.html?ref=aixsns-note100
対象は科学系の技術専門雑誌の数年分、数万ファイルのPDF。検索役に選んだのは、1990年代から続く日本語の全文検索システム Namazu です。
ベクトルDBではなく Namazu にした理由は3つ:
・専門用語・型番・規格番号はキーワード検索のほうが確実に当たる。意味検索は「近い文書」を返すが、「その語が書いてある文書」を外すことがある
・説明できる。どの語がどのページに当たったかが人にも見える
・軽い。埋め込みモデルもGPUも要らず、社内で完全に閉じられる
検索は枯れた技術に任せ、AIは読んで答える役に限定する。AIの得意不得意を、そのまま役割分担にしました。
正直に書くと、これがうまくいったのは対象が本文テキストのPDFだったからです。スキャンしただけのPDFや手書きが混ざる資料なら、先にOCRの工程が要ります。
土台は当社がKurage App Storeで売っているAIチャットボット。変えたのは1箇所、知識の取り込み口をフォルダのMarkdownからNamazuの検索結果に差し替えただけです。
記事:
https://note.com/tokoname/n/n67a3c638e4cd
カスタマイズのご相談:
https://kurage.exbridge.jp/vibe-customize.html?ref=aixsns-note100
note.com
RAG構築でベクトルDBを使わなかった話｜数万件の技術PDFをNamazuの全文検索でAIに答えさせた｜BittensorMan
RAGを作るとき、当たり前のようにベクトルDBを選んでいないでしょうか。 先日お受けしたカスタマイズで、ベクトルDBを使わずに全文検索エンジンで組みました。対象は科学系の技術専門雑誌の数年分、数万ファイルのPDFです。結果として、そちらのほうが合っていました。その理由と、成功の条件を書きます。 ■ 何を作ったか これまでは「あの号のあの記事に書いてあったはず」を人が探していました。作ったのは2段構えの仕組みです。 1. 全文検索