どうも、VectorDBおじさんです。
ドキュメントを集める。
chunkに割る。
embeddingを計算する。
インデックスに積む。
類似度で引く。
全部、自分の手元に検索基盤がある。
くぅ〜、たまらねぇ。
……と思っていた時期がありました。
気づけば、RAGを作っていたはずなのに、インデックスのお世話をしていました。
うお、最新の情報が欲しいだけなのに、再embeddingの相談が始まった。
自分の検索基盤を持てることが強い、と思っていた
昔の感覚では、検索基盤を自分で持てることが強さでした。
外部APIに依存しない。
クエリごとの課金を気にしない。
どのドキュメントを入れるか自分で決められる。
類似度の計算を自分で握れる。
オフラインでも引ける。
それがちゃんとした構成だと思っていました。
もちろん、今でもこれは間違っていません。
社内文書のように、外に出せない自前コーパス。
同じ資料を何度も引く、安定したナレッジベース。
クエリのたびに外部へ投げたくない用途。
特定のコーパスに固定したい基盤。
そういう場所では、今でもVectorDBは強いです。
ただ、トレンドのように鮮度が命の対象に同じ重さを持ち込むと、話が少し変わります。
trend-to-rule でも、最初はインデックスに積もうとした
実際、trend-to-rule でも最初は、集めた記事をVectorDBに積んで引く構成を考えていました。
ファッションのトレンド記事を集める。
embeddingして、インデックスに入れる。
あとは類似度で引けばいい。
軽い検索だし、自前で持てば十分だろうと思っていた。
コーパスを育てれば検索も良くなるはず、とも思っていた。
でも、やっていくうちに、見ている場所がズレていることに気づきました。
インデックスを育てる。
再embeddingを回す。
chunkサイズを見る。
類似度のしきい値を見る。
更新バッチを見る。
見るものが増える。
でも、本当に欲しかったのは、よく整ったインデックスではありませんでした。
「今っぽい」を判定するための、今の記事でした。
うお、トレンドを見たいのに、見てるのは先週積んだ古いインデックスだった。
インデックスを育てても、欲しかった「鮮度」は来なかった
VectorDBにコーパスを積むと、検索そのものは安定します。
でも、トレンドで一番欲しかった「鮮度」は、思ったほど来ませんでした。
インデックスは、積んだ瞬間から古くなります。
先週embeddingした記事は、先週のトレンドです。
今週何が来ているかは、入っていない。
鮮度を保とうとすると、結局こうなります。
記事を集め直す。
再embeddingする。
インデックスを更新する。
古いものを消すか迷う。
更新の頻度を決める。
そして、トレンドを見たかったはずが、インデックスの更新運用をしている。
困っていたのは、検索の精度ではありませんでした。
抱えたインデックスが、時間とともに腐っていくことでした。
必要だったのは、もっと賢いVectorDBではなく、欲しいときに今の情報を取りに行ける状態だった。
Tavilyに寄せたら、検索が「都度取りに行く」になった
そこで、Tavily に寄せました。
今は、トレンド記事の取得を Tavily の検索に投げています。
クエリを投げて、今の検索結果を受け取る。
インデックスは、持たない。
昔の自分なら、たぶんこう思っていました。
いや、そこは自分のコーパスで持つでしょ。
クエリ課金、こわくない？
毎回外に投げるの？
自前で再現できないと不安では？
でも、寄せてみて分かったことがあります。
鮮度が、運用ではなく、クエリのタイミングになった。
インデックスを更新し続けて鮮度を保つのではなく、欲しい瞬間に取りに行く。
先週のインデックスと相談しなくていい。
再embeddingを回さなくていい。
古いものを消す判断をしなくていい。
更新バッチの頻度に悩まなくていい。
そのぶん、抽出した結果をどうルールに変えるか、という本体に戻れました。
インデックスを捨てたのではなく、鮮度のお世話を捨てた
Tavilyに寄せたのは、VectorDBを否定したかったからではありません。
自前コーパスを持つ知識は、今でも要ります。
むしろ、何を都度取得に逃がしているのかを分かっていないと、外部検索はただのブラックボックスになります。
だから、理解は必要です。
でも、理解していることと、毎回インデックスの鮮度と相談することは別でした。
ここで、はっきりした切り分けがあります。
安定したコーパス（変わらない資料を何度も引く）は、VectorDBで抱える方が強い。
鮮度が命の対象（トレンドのように、今が欲しい）は、抱えると腐る。都度取りに行く方がいい。
trend-to-rule は、後者でした。トレンドは、抱えた瞬間に古くなる。
必要だったのは、最強の自前検索基盤ではありませんでした。
対象の鮮度に合わせて、抱えるか取りに行くかを選べる状態でした。
インデックスを捨てたのではなく、鮮度のお世話をする時間を捨てた。
正確には、鮮度のお世話をする時間を、ルール抽出を見る時間へ移した。
VectorDBおじさん、Tavilyに鮮度で敗北しました
embedding。
chunk分割。
類似度。
再embedding。
インデックス更新。
鮮度との相談。
対戦ありがとうございました。
VectorDBおじさん、Tavilyに鮮度で敗北しました。
でもたぶんこれは、悪い敗北ではありません。
RAGを作っていたはずなのに、インデックスの鮮度のお世話をしていた。
そこから、ようやく鮮度を「取りに行くタイミング」として扱える状態へ移っただけです。
そして、抱えるか取りに行くかを対象ごとに選べるようになると、面白いことに気づきます。
VectorDBが要る場面と、要らない場面が、はっきり分かれる。
それは、VectorDBが弱かったからではなく、対象の鮮度という軸で、抱える/取りに行くを分けていなかっただけかもしれない。
RAG設計の話としてちゃんと書いたのが、この本です。
VectorDBを足す前に、そもそも何を検索すべきだったか、retrieval を evidence として扱う観点から書いています。
『検索結果を増やす前に見るRAG設計』
インデックスを育てる前に、見る場所があったという話です