マトリョーシカのトリックは本当に面白いね。ここにいい説明があるよ: https://huggingface.co/blog/matryoshka いくつかのモデルで見たことあるけど、Nomic Embed 1.5が最初だったね。https://www.nomic.ai/blog/posts/nomic-embed-matryoshka

Googleのチームは、そのマトリョーシカ技術に夢中みたいだね。どこまでスケールするのか気になるな。

面白いけど、彼らが主張してる改善はそんなに画期的じゃないよね。

OpenAIのtext-embedding-3-largeやtext-embedding-3-smallの埋め込みモデルにはマトリョーシカ特性があるのかな？

セマンティック検索はまだ重要だと思う。特にコーディングエージェントにとって、正規表現検索も急速に重要性を増してるね。

RAGを使うのに真剣に時間をかけてないけど、AWSのナレッジベースを使ってエージェント検索と比較した時は、結局エージェント検索（ClaudeコードSDK経由）に戻っちゃった。RAGには調整できる部分がたくさんあって、全体的に複雑だなって印象を受けた。もしかしたら、テキストの量が十分に多くなればその複雑さが報われるかもしれないけど、今はエージェント検索がすごくうまくいってて、始めるのもずっと簡単だよ。

もしあなたのLLMが十分に良ければ、grepやFTSエンジンを使ったツールコールの方が良い結果が得られると思うよ。良いモデルは「犬 OR 犬科」みたいに検索パターンを適応させることもできるし、以前はベクトルの類似性が大きな利点だったかもしれない。埋め込みを使うには色々と手間がかかる。チャンク戦略を決めて、埋め込みを実行して、素早く取り出せるように保存方法を考えなきゃいけない。大きなデータ量になると、埋め込みストアをメモリに保持しなきゃいけなくなることが多いから、結構な負担になるよ。去年は埋め込みにたくさん取り組んだけど、ツールベースの検索がこんなに強力になった今は、あんまり興味を失っちゃった。埋め込みを使ったツールベースの検索をつなげるのは探る価値があるけど、ripgrepから得られる結果が十分良ければ、かなりの追加労力をかける価値はないかもしれないね。

ちょっと気になるんだけど、テキスト以外のファイルはどうやって扱うの？PDFファイルがたくさんあったらどうするの？

使い方やスケールによるね。もし無構造テキストが100万件あったら（よくあることだけど、商品説明やユーザーレビューのウェブスクレイピングとか）、それに対して埋め込み検索をして、最も関連性の高いドキュメントを見つけたいよね。もし100個の.pyファイルがあったら、エージェントにはgrepツールでそれをナビゲートさせたい。

これがまさに、ベクタリゼーションについて私が心配していたリスクなんだ。オープンソースのモデルが価値があるかもしれないって考えたのは、誰かがホストしてくれるし、自分で非推奨の速度をコントロールできるから。

あなたは、改善や新機能のために年に一度もファインチューニングや埋め込みを再実行する必要がないLLMを使ったアプリをたくさん知ってる？物事がすごく早く進んでるから、「12ヶ月ごと」ってちょっと遅い気がするんだよね…。

埋め込みのコストは推論に比べてかなり小さいから、あまり気にならないんだ。でも、私が狂ってるのか、それともgemini-embedding-001のプレプロダクション版はもっと大きな最大コンテキスト長を持ってたんじゃないかな？編集：実際そうだったみたい？8kから2kにダウングレード？もし本当なら、すごく残念だな。実験モデルがGAに到達するのを楽しみにしてたのに。

数百万の文書をフィルタリングするのにツールコーリングをどう使うつもり？古典的な検索でも埋め込み検索でも、何かしらの検索機能が必要だよ。もし文書が数千しかないなら、検索は必要ないかもね。全部LLMに渡せるから。

検索ツールの呼び出しはRAGって呼ばれてるよね。もっと流行りに乗るために「RAGエージェント」って呼んでもいいかも、へへ。でもRAGはベクターデータベースの埋め込みの類似検索だけじゃないんだ。RAGは、推論の前にリトリーバルとコンテキスト注入のステップを含むあらゆるタイプのものだよ。実際、RAGエージェントは、grepやFTSクエリ、KB API呼び出しなんかを使って、ベクターデータベースでコサイン差分を実行して、広範囲なリコール（候補生成）をしてから、結果を再ランク付け（関連性優先）することもできる。多くのユースケースでは、検索ツールの呼び出しがRAGを動かすための埋め込みの類似検索よりも実用的だと思う。

ツールコールはRAGを補完する。フルスケールのRAG（埋め込み、再ランク、プロンプト作成、LLMからの出力取得）を構築して、それを他のエージェントが見えるツールに接続する。それで両方の力を組み合わせるんだ。

その通りだね。「高度な」RAG技術は結局マーケティングのウソで、やってることはテキストをモデルのコンテキストウィンドウに渡すだけだよ。

LLMは検索エンジンをツールとして使えるよ。一つの可能性は、Googleが検索クエリをこれらの埋め込みを通して埋め込み、そこから取得して、取得した結果をモデルの思考の流れに貼り付けるってこと（外部メモリモジュールがモデルにない限り、基本的にはモデルの唯一の作業メモリだね）。

だから「モデルの作業メモリに直接」っていうマーケティングの話は何なの？私の考え方は間違ってるの？コンテキストは時々作業メモリとも呼ばれるよ。でも、あなたの理解は正しいよ：コサイン類似性（つまり埋め込みを通して）で正しい文書を見つけて、その文書の内容をコンテキストに追加するんだ。

理論的にはそうだよね。同じモデルなら、埋め込みを再計算するんじゃなくて、モデルが再利用できるはず。多分、これが彼らの言いたいことだと思う。実際には、モデルの変更はどれくらい早いのか（トークナイザーも含めて）？ベクターデータベースはモデルのバージョンに合わせてどれくらい早く完全にバックフィルされるのか？それが「キャッシュヒット率」みたいなもので、どれだけ役立つかは特定のコーパスやクエリのボリュームによると思う。

RAGは、いくつかのドキュメントを取り込んで、それを特定の長さのテキストブロックに分割して（どうやってやるのがベストかは議論中）、クエリ（Google検索みたいな）を受け取ってドキュメントのチャンクと比較する検索APIを作ることだよ（君が説明してる通りだね）。返されたチャンクを取り出して、ベクター検索のスコアは無視して、元のクエリと一緒に再ランカーにそのチャンクを入れる（このステップは重要、ベクター検索はほとんど役に立たないから）。再ランク付けされた上位1/2の結果をフィルタリングして、プロンプトを整形する。例えば、「ユーザーが'長いクエリ'を聞いたから、いくつかのドキュメントを取得した（下を見てね）、そのドキュメントに基づいてクエリに答える（気が向いたらドキュメントを参照してもいいよ）」みたいな感じ。Doc1.pdf - チャンクN チーズを食べる Doc2.pdf - チャンクY チーズは食べない。そしたら、その検索APIをLLMが呼び出すための「ツール」として公開して、上のプロンプトを少し再フォーマットしてマルチターンの会話にして、あっという間に成功する。でも、ユーザーがその結果に満足したら、最新のサッカーのスコアみたいなバカなことを求めてくるから、ウェブツールが必要になって、終わりがないんだよね。とはいえ、一度整備すればかなり強力だよ。

あなたが理解していないのは、LLMも内部で埋め込みを使っているってこと。トークンを表現する方法なんだ。ただ、埋め込みは見えないから、内部の仕組みなんだよ。

あなたの考え方は合ってるよ。彼らはその用途を示すためにサードパーティのアプリケーションをリストアップしてるけど、これはそのベクターを生成するためのモデルに過ぎないんだ。

直接的に作業メモリに入る部分はナンセンスだけど、解決する価値のある問題を指摘してるね。KVキャッシュをもっとポータブルにして、カット＆ペーストできるようにするには何が必要なんだろう？理論的には、長いドキュメントの処理を終えたら、そのままKVキャッシュを保存できるはずだよね？次回はそれをロードして、続けられるってこと？続けるためには、無関係な不連続なKVキャッシュセグメントを操作できるようにモデルをトレーニングする必要があるんだけど、今のところそれはできないと思う。KVを「unRoPE」してから「re-RoPE」することで再利用しようとした論文を見た記憶があるけど、最新の情報は見てないな。今の状況を知ってる人いる？同じコンテキストを何度も再処理しないと新しいクエリを聞けないなんて、ちょっとおかしいよね。

書いた人も混乱してるかもしれないね。Geminiの埋め込みモデルは多言語サポートを提供してると思うけど、何でも使えるんだよね。開発者が自分のストレージやクエリの実装（自分のベクターデータベース）でこれらの埋め込みを使う前提になってるみたい。混乱するのは、この記事がそのプロセスが埋め込みをGeminiに送ると自動的に行われると示唆していることだね（それは意味がないと思うけど、テキストだけでいいんじゃないの？）。

HNでOdd Lotsが言及されてるのを見るのは本当にクールだね。私のお気に入りのポッドキャストの一つなんだけど、今回のエピソードのゲストは質問に答えたり、法律の世界でAIを使う可能性を探ったりするにはちょっと力不足だったと思う。

自動的にキュレーションされたコンテンツチャンクってどういう意味？埋め込み検索を使ったRAGは、ボットの文脈にどのチャンクを入れるかを決めるプロセスで、ユーザーの質問に答えるためにそれを参照できるようにするんだ。

一般的な検索にはあまり使われないのは、今までのところ、セマンティックベースの検索のパフォーマンスが複雑さのトレードオフに見合わなかったからかも。NLPは難しい問題だったし、伝統的なキーワードベースの検索を何十年も調整してきたからね。

そのベンチマークを再現できてる人はあまりいないと思う。モデルがちょっと変だし。

自分の経験では、APIコールはLLMがレスポンスを作成する時間に比べたらほんとに些細なことだよ。