- Hacker Newsで、ユーザーがローカル環境で Retrieval-Augmented Generation(RAG) をどのように実装しているかを尋ねた質問
- ローカルRAGでは ベクターDBなしでも SQLite FTS5・BM25・grep のようなテキスト検索で十分に回せるという流れが強く見られる
- コード検索では埋め込みは 遅くノイズ が多いという体験談が多く、BM25+トライグラムのようなキーワードベースの方が良いという主張も多数見られる
- ベクター検索が必要な場合でも、Postgres+pgvector、SQLite にベクター BLOB を保存、FAISS をメモリに載せるといった 軽量な構成 で解決する事例が続く
- BM25+ベクターを組み合わせる ハイブリッド検索 と、RRF(Reciprocal Rank Fusion)、リランキング、マルチクエリ拡張のような組み合わせで検索品質を向上できる
- 「RAG=ベクターDB」と固定せず、文書の種類・規模・運用負荷に応じて 単純検索→ハイブリッド→エージェント型 を選ぶ傾向が見られる
検索段階での共通した結論
- ベクターDBやグラフが必須という前提より、既存インフラ・ファイル種別・要求性能に合わせてシンプルに始める アプローチが多数派
- エージェントがファイルシステムや API を直接照会する方式は、設定・保守は容易だがやや遅い可能性があるという言及あり
- 「RAGがLLMに渡すのは検索結果の短いテキスト断片」 という認識が、性能改善の焦点を 検索品質 に向けるきっかけになっている
- 「RAGの定義」については、ベクターDBがなくても retrieval+generation ならRAG だという反応と、通常はベクターDBを前提に呼ぶことが多いという反応が併存する
埋め込みモデルとベクター検索
- MongoDB が開発した mdbr-leaf-ir 埋め込みモデルは CPU 専用で動作し、このサイズ帯のモデルとして複数のリーダーボードで1位を記録
- 標準的な 2vCPU サーバーで毎秒約22件の文書、120件のクエリを処理可能
- BEIR ベンチマークで 53.55 点を記録 (
all-MiniLM-L12-v2 は 42.69 点)
- model2vec/minish のような静的単語埋め込みは推論速度がさらに速いが、検索精度は低い
- トークナイズ + ルックアップテーブル + 平均だけを行うため、Transformer ベースより高速
- Meta-Llama-3-8B でテキストチャンクごとのベクターを生成し、SQLite BLOB カラム に保存して FAISS で検索する方式も使われている
- 500万チャンク基準で約40GBのメモリを使用
- A6000 では
faiss-gpu が非常に高速で、M1 Ultra の faiss-cpu は遅いが1日に数回のクエリ程度なら十分
コード検索に関する推奨事項
- コードにはベクターデータベースの使用を避け、BM25+トライグラム の組み合わせを推奨
- 埋め込みは遅く、コードに適していない
- リランカーがないとノイズが多くなり、ファイルの再インデックス負荷も大きい
- 検索応答速度が速く、結果品質も優れている
- PostgreSQL では plpgsql_bm25 によって BM25 検索を実装可能
- pgvector と組み合わせたハイブリッド検索 + Reciprocal Rank Fusion をサポート
- ファイルパス + シグネチャに埋め込みを適用し、BM25 と融合すると良い結果を得られる
- gpt-oss 20B を ripgrep と一緒に while ループで動かすエージェント的方式も効果的
データベースベースのソリューション
- SQLite FTS5: Markdown ファイルベースの文書に適しており、ベクターDBなしでもRAGを実装可能
- 各ファイルに短い説明フィールドを持たせ、キーワード検索で文書を探索
- SQLite に fp16 ベクターを BLOB として保存し、フィルタで部分集合を作った後、メモリ上で類似度計算を行う設計も可能
- sqlite-vec、sqlite-vector、vec0、SQLite の bm25 といった選択肢もある
- 「SQLite は驚くほどうまく機能する」
- PostgreSQL + pgvector: 既存の Postgres の知識を活用でき、運用チームへの引き継ぎもしやすい
- ハイブリッド BM25、マルチクエリ拡張、リランキングをサポートする llmemory ライブラリもある
- LanceDB: 組み込み型ベクターDBとして手軽に使える
- Ollama の nomic-embed-text 埋め込みと組み合わせて利用
- DuckDB: ベクター類似検索の拡張機能を提供し、3GB以下の小規模プロジェクトに適している
- Meilisearch, Typesense, Manticore: Elasticsearch/OpenSearch より運用がシンプル
ハイブリッドおよびエージェント型検索
- nori(usenori.ai): SQLite + vec0 + fts5 でセマンティック検索と単語検索を結合
- Turbopuffer: ベクター + BM25 のハイブリッド検索をサポート
- エージェント型検索とテキスト検索の組み合わせだけでもかなり良い結果を得られる
- ベクター検索とグラフRAGを追加すると、速度と品質が多少向上する可能性がある
- Claude Code/Codex は内部的に ripgrep を使用
- ファイルパスに埋め込みを適用するのも効果的で、BM25 と融合するとさらに改善する
BM25 活用事例
- shebe: BM25 ベースのコードベース索引化および検索 CLI/MCP ツール
- リファクタリングのワークフローで特に有用（例: Istio のアップグレード時に変更が必要な箇所を列挙）
- 85% のケースではベクターDBなしでタグマッチングだけでも十分
- 運用者が入力と文書の両方にタグを追加し、100% マッチを達成
- ほとんどのベクターDBは「見つけられない問題を解決しようとするハンマー」だという意見
特殊ツールおよびライブラリ
- qmd: Markdown ファイル検索用 CLI ツールで、fzf よりファジークエリ結果が優秀
- ck: Rust ベースのセマンティック grep ツール
- Kiln: ドラッグ＆ドロップでファイルを追加でき、さまざまな設定を比較可能
- 抽出方法、埋め込みモデル、検索方式(BM25、ハイブリッド、ベクター)の比較をサポート
- 検索精度評価と評価データセット自動生成機能
- libragen: バージョン管理された RAG コンテンツライブラリ生成用 CLI/MCP サーバー
- GitHub リポジトリを RAG DB に変換可能
- piragi: シンプルな Python RAG ライブラリで、ローカル/S3/API など多様なソースをサポート
- ragtune: ローカルRAG検索のデバッグおよびベンチマーク用 CLI ツール
文書処理と OCR
- discovery: Qwen-3-VL-8B で文書 OCR を行い、ChromaDB にベクターを保存
- docling: 文書抽出用ツールで、複数のRAGプロジェクトで活用
- PDF 変換時は表、複数カラム、ページをまたぐ表の処理が難しい
- Mistral OCR モデルが最良の結果を提供（非公開モデル）
メモリとコンテキスト管理
- RAGがLLMに渡すのは 短い検索結果文字列 だけ
- 小型モデルでは
TOP_K=5 程度が限界で、それ以上ではコンテキスト忘却が起きる
- ファイルやフォルダを 事前要約 する方式で改善可能
- Sonnet + 1M コンテキストウィンドウで全内容をコンテキストに入れる方式も使われている
- セッションファイルに対するセマンティック検索で Claude Code 向けメモリシステムを構築した事例
エンタープライズおよび大規模活用
- 1日30万件の顧客インタラクションを処理する場合、レイテンシと精度が重要
- 埋め込み + 全文検索 + IVF-HNSW のハイブリッドアプローチを使用
- 約600の分散システムにおける情報拡散管理が課題
- KAG(Knowledge Augmented Generation) アプローチでビジネスルールのマッピングを実験中
- 50万件以上のニュース記事に対し、Postgres ベクターDBで完全ローカルRAGの実装に成功
その他のツールおよびアプローチ
- AnythingLLM: 文書用ベクターDBをバンドル提供
- LibreChat: 文書用ベクターDBを同梱
- ChromaDB: Obsidian 拡張としてセマンティック/ハイブリッド検索を実装
- SurrealDB: ローカルベクトル化と組み合わせて使用
- OData クエリインターフェース: LLM にツールとして提供すると効果的で、4万行の Excel を分析可能
- Nextcloud MCP Server: Qdrant をベクターDBとして使用し、個人文書にセマンティック検索を提供
- LSP(Language Server Protocol): Claude Code に追加されたが、現時点ではバグが存在
- TreeSitter の方が有用かもしれない（シンボル名による照会、定義/使用箇所の探索）
3件のコメント
日本語がちゃんと動くのか疑問ですね。
社内の粗雑なRAGシステムの性能を見たうえでこういう投稿を見ると、視点が少しずつ変わってきますね
Hacker Newsの意見
私たちのチームはQ&Aデータベースを運用中
質問と回答をtrigramインデックスと埋め込みの両方で索引化してPostgresに保存している
検索時は
pgvectorとtrigram検索を併用し、関連度スコアで結果を結合している検索段階ではCPUフレンドリーな高効率テキスト埋め込みモデルを開発した
MongoDB/mdbr-leaf-irモデルで、同クラスのモデルの中でリーダーボード1位を獲得している
Snowflake/snowflake-arctic-embed-m-v1.5モデルと互換性がある
search-senseiデモでsemantic検索 vs BM25 vs hybridを比較できる
たとえば、埋め込みモデルは「j lo」が「Jennifer Lopez」を意味すると認識する
また、学習レシピも公開しており、一般的な水準のハードウェアでも簡単に学習できる
私は2024年4月からMeta-Llama-3-8Bでベクトルを生成していた
PythonとTransformersをRTX-A6000で使っていたが、速い一方で騒音と発熱がひどかった
その後M1 Ultraに移行し、AppleのMLXライブラリを使ったところ、速度はほぼ同じでずっと静かになった
Llamaモデルは4k次元なのでfp16では8KB/チャンクとなり、これを
numpy.save()でSQLiteのBLOBカラムに保存している検索時にはSQLiteからすべてのベクトルを読み出して
numpy.arrayにしたうえでFAISSで検索するRTX6000のfaiss-gpuは非常に高速で、M1 Ultraのfaiss-cpuも私の用途（1日に数クエリ）には十分速い
500万チャンク基準でメモリ使用量は約40GBで、どちらのマシンでも余裕で処理できる
複雑な文書の大半はMarkdownファイル
tobi/qmdというシンプルなCLIツールを勧める
以前はfzfベースのワークフローを使っていたが、このツールはより優れたあいまい検索を提供する
コード検索には使っていない
コード検索にはベクターデータベースを使わない方がいいと勧める
埋め込みは遅く、コードには向いていない
BM25 + trigramの組み合わせの方が結果が良く、応答も速い
plpgsql_bm25プロジェクトを参考にできる
BM25とpgvectorをReciprocal Rank Fusionで結合した例とJupyterノートブックも含まれている
コード向けでないモデルを使うと、ベクトル検索はノイズを多く生む
今は
gpt-oss 20Bをripgrepと組み合わせてループさせる方が、ずっと速くて正確だBM25と**結合（fusion）**するとさらに改善する
ローカルRAGの実験用にlocal-LLM-with-RAGを作った
Ollamaの「nomic-embed-text」で埋め込みを生成し、LanceDBをベクターDBとして使っている
最近は「agentic RAG」に更新したが、小さなプロジェクトにはやり過ぎかもしれない
fp16ベクトルをSQLiteにBLOBとして保存し、フィルタリング後にメモリへ読み込んで**行列ベクトル積（matvec）**で類似度を計算している
numpyやtorchがマルチスレッド/BLAS/GPUを活用すれば非常に高速
ボトルネックが出たらsqlite-vectorに移行する予定
日付や位置のようなフィルタでデータ量が大きく減るので効率的
バックエンドは差し替え可能なインターフェースの背後に隠してある
私の文書の95%は小さなMarkdownファイルなので、SQLite FTS5で通常のテキスト検索インデックスを使っている
すでにインデックスがあったので、mastra agentにそのまま接続した
各ファイルには短い説明フィールドがあり、キーワード検索後に説明が一致すれば文書全体を読み込む
設定には1時間ほどしかかからず、とてもよく動いている
埋め込みベースの検索の方が一般的ではあるが、本質は同じ
私たちはPostgresに慣れていたので、PGVectorから始めた
後になって、プロンプトの半構造化フィールドが必要なコンテンツと100%一致していることに気づいた
運用担当者が入力側にも文書側にもタグを入れ始めたからだ（文書は50件ほど）
そこでまずフィールドを検索して該当ファイルをプロンプトに入れ、その後で埋め込み検索を行う
結果として、85%のケースではvectordbは不要
私はllmemoryを作って、ローカルでも会社のアプリでも使っている
PostgreSQL + pgvectorベースで、ハイブリッドBM25、マルチクエリ拡張、reranking機能を含んでいる
公開したばかりなので多少のバグはあるかもしれない
性能にはかなり満足している