- Skald は、データを第三者に送信せず、完全に セルフホスト可能なRAGシステム を目指して開発されている
- RAGの構成要素は ベクトルデータベース、埋め込みモデル、LLM、リランカー、ドキュメントパーサー に分かれ、それぞれについて オープンソースの代替 を提示
- Skaldの基本ローカルスタックは Postgres+pgvector、Sentence Transformers、Docling、ユーザー指定のLLM で構成
- ベンチマーク結果では、クラウドベースのモデル(Voyage+Claude) は平均9.45点、完全ローカルのGPT-OSS 20B は7.10〜8.63点と評価された
- このアプローチは、データプライバシーを維持しながら高性能なRAGを構築できる ことを示している
RAGの構成要素とオープンソースの代替
- 基本的なRAGは ベクトルデータベース、埋め込みモデル、LLM で構成され、追加で リランカーとドキュメントパーサー を含めることができる
- 各構成要素はSaaSの代わりに ローカルな代替 に置き換え可能
- 例示された代替一覧
- Vector DB: Pinecone, Weaviate Cloud → Qdrant, Weaviate, Postgres+pgvector
- Embeddings: OpenAI, Cohere → Sentence Transformers, BGE, E5
- LLM: GPT, Claude → Llama, Mistral, GPT-OSS
- Reranker: Cohere → BGE Reranker, Sentence Transformers Cross-Encoder
- Document Parsing: Reducto → Docling
- Skaldは完全な オープンソーススタック を志向し、各構成要素をローカルで実行する
Skaldのローカルスタック構成
- Vector DB: Postgres + pgvector を使用
- 既存インフラに統合しやすく、数十万文書まで処理可能
- Vector Embeddings: デフォルトは Sentence Transformers (all-MiniLM-L6-v2)
- 英語専用で、速度と検索性能のバランスが良い
- bge-m3 モデル（多言語対応）もテストされた
- LLM: 標準提供はなく、ユーザーが自分で実行
- テストでは GPT-OSS 20B をEC2で実行
- Reranker: デフォルトは Sentence Transformers Cross-Encoder、多言語モデルとして bge-reranker-v2-m3 なども利用可能
- Document Parsing: Docling を使用し、docling-serveで実行
性能とデプロイ結果
- スタック全体を含むSkaldの本番インスタンスのデプロイに 8分 を要した
- Postgres、埋め込み・リランキングサービス、Doclingを含む
- LLMは別途実行（llama.cppを使用）
- テスト用データセットは PostHogのWebサイトコンテンツ（約2000文書） と自作の質疑応答セットで構成
- 実験設定
- Vector search topK=100, Reranking topK=50, Query rewriting=Off
- 評価基準は 正確性重視
ベンチマーク結果の比較
- Voyage + Claude（クラウド構成）
- Voyage + GPT-OSS 20B（部分ローカル）
- 平均スコア 9.18、大半は正確だが一部に情報の欠落あり
- 完全ローカル + GPT-OSS 20B
- 基本英語モデル(all-MiniLM-L6-v2 + ms-marco-MiniLM-L6-v2) : 平均 7.10
- 英語のクエリには正確だが、多言語・曖昧なクエリ・複数文書の集約では弱い
- 多言語モデル(bge-m3 + mmarco-mMiniLMv2-L12-H384-v1) : 平均 8.63
- ポルトガル語のクエリ処理には成功したが、複数文書の集約時に一部欠落あり
- 主な限界は 複数文書に散らばった情報を統合して処理すること
- クラウドモデルは高性能でこれを補えるが、ローカル環境では追加の手法が必要
今後の計画
- Skaldは ローカルRAGの性能向上とオープンソースモデルのベンチマーク公開 を計画
- エアギャップ環境でAIツールを運用しなければならない企業 に向けたソリューション提供を目指す
- 参加希望者は GitHub(skaldlabs/skald) または Slackコミュニティ を通じて協業可能
7件のコメント
RAGにベクターDBが必要だなんて、いったいどこから出てきた話なんだろう……
ベクターDBだろうが何だろうが、要するに検索さえ実装すればいいってことでは……
Gemini：
はい、RAG（Retrieval-Augmented Generation）におけるベクトルデータベース（Vector Database） の利用は、2020年に関連論文が初めて発表された時点から、その概念的な土台が築かれていました。
RAGは基本的に検索（Retrieval） と生成（Generation） を組み合わせる方式ですが、この検索段階でベクトル埋め込みと、それを効率的に保存・検索するベクトルデータベースが不可欠な役割を果たします。
💡 RAGとベクトルDBの出発点
RAGでベクトルDBが必要だというアイデアは、次の主要な論文と概念から始まりました。
ベクトルデータベースがRAGの必須要素となった根本的な理由は次の通りです。
要約: ベクトルDBが必要な理由
LLMが学習していない最新の知識やドメイン特化の知識にアクセスできるようにするには、単純なキーワードマッチング（従来の検索）ではなく、意味的類似性に基づいて情報を探す必要があります。ベクトルDBは、この意味的類似性ベースの検索を効率的に実行するために、RAGフレームワークへ自然に統合された中核技術です。
実際、RAGに必要なのは検索機能であって、デンスベクトルに埋め込んでvectorDBにプッシュし、コサイン類似度検索をするのは、検索エンジンを実装する数ある方法の一つにすぎないので……。vectorDBをあえて使わない理由はないですが、本当に必須なのかと言われると、長年うまく使われてきた検索エンジンのアルゴリズムも多いので、少し首をかしげてしまいます。
安いですし、たいていの本番向けLLMが使っているので。
実際、webサーバーだってそういう理屈なら、インフラ機能を追加すれば全部ディスク上でできるので、DBMSも必要ないってことになりますね（笑）
ユーザーのqueryの埋め込み値（ベクトル）をkeyとする、いわゆる類似度・意味検索にはDBが必要だというのはその通りですし、keyがベクトル形式なのでベクトルDBというのもその通りです。
Hacker Newsの意見
この種のシステムを作るなら、ベクターデータベースや埋め込みにこだわりすぎないほうがいいという助言をしたい
全文検索や
grep/rgのようなツールのほうがはるかに速くて安く、インデックスを維持する必要もない優れたLLMに検索ツールを与えれば、「dog OR canine」のようなクエリを自分で生成し、反復的に改善できる
しかもこの方法なら チャンク分割の問題 を解決する必要もなくなる
Search Senseiで確認できる
初回読み込み時に約50MBのモデル重みとonnx runtimeをダウンロードするが、その後はスムーズに動作する
たとえばBM25は「j lo」や「jlo」がJennifer Lopezを意味することを理解できないが、埋め込みベース検索はこうした タイプミスや別名 をうまく扱える
2016〜2024年のニュース記事1000本を対象に検索を実行している
ただしBM25単独の性能が公開されていないのは残念
自分の小規模テストでは、クエリ語がそのまま含まれているページを埋め込みが見逃すことがあった — 結局 Ctrl+F が勝つ
Lexical検索は適合率が高いが再現率は低く、semantic検索はその逆の位置にある
「NOT」演算子がもっと必要だと感じる。RAGについてももっと学びたい
一部のエージェント型ツールが自動でこうしたクエリを作ってくれるのは見たが、プロンプトで誘導されているのか、デフォルト動作なのかは分からない
性能が落ちる理由の1つは、semantic chunking が不足していることかもしれない
文書全体を埋め込むと複数の概念が混ざり、精度が落ちる
Spacyのようなツールで意味単位に分割し、各チャンクが文書内でどのような文脈にあるかを追加したうえで埋め込む必要がある
Anthropicのcontextual retrieval アプローチはRAGシステムで非常に効果的だった
GPT OSS 20Bモデルで文脈生成を行えばよい
複数文書のコンテキストを集約する必要がある質問でテストしたため、誤解があったようだ
なぜ semantic検索がlexical検索より優れていると前提 するのか疑問だ
2023年にTantivy（BM25）と比較したとき、結果の差はごくわずかだった
わずかな再現率向上があるとしても、あの複雑な構造を作る価値があるのか分からない
開発者テストでは再現率90%だったが、実ユーザーテストでは30%程度まで落ちた
ユーザーは文書の正確な用語を知らないため、lexical検索だけでは不十分 だった
エージェントを載せることもできるが、レイテンシ が大きくなり、ユーザー満足度が下がる
WanderfuglではBM25スコアが低い箇所もsemantic検索がうまく見つける
結局 ハイブリッドランキング が答えかもしれない
結局は ユースケース依存 だ
メール、Slack、GDrive、コード、Wikiなど、あらゆるデータをローカルのオフライン環境で問い合わせられる オープンソースツール を探している
自分で構築したりカスタマイズしたりするのは避けたく、良いデフォルト設定とモデル推奨があるとありがたい
GitHubリンク
基本的にCRUDをサポートし、ベクトル検索を有効にすると文書やノートを埋め込む
OllamaとOpenAIを埋め込みプロバイダーとしてサポートしている
MCPサーバーは semantic + BM25（qdrant fusion） 検索の両方を提供し、MCP samplingを通じて応答を生成する
サーバー自体が答えを生成するのではなく、どのLLM/MCPクライアントとも連携可能だ
この MCP sampling/RAGパターン は非常に強力で、他のデータソースにも一般化されたオープンソース版が出る可能性が高い
私たちが使っているツールは haiku.rag だ
開発者フレンドリーなPythonコードと pydantic-ai ベースの構造、ベンチマークと高度な引用機能を提供する
ディープリサーチエージェント をサポートしており、長期的に保守される本物のオープンソースプロジェクトだ
デフォルトの埋め込みモデルとして Sentence Transformers (all-MiniLM-L6-v2) を使っているが、英語専用なのでドイツ語RAGを作る際に問題になりうると気づいた
非英語モデルの性能がどうなのか気になる
「Retrieval」セクションの RTEB Multilingual または RTEB German 項目を見ればよい
CPUベースのセルフホスティングなら、100Mパラメータ以下のモデルでフィルタするのがよい
ただしドイツ語は比較的学習データが多く、多言語モデルも十分存在する
特に商用APIベースのモデルの多くは 多言語対応 だ
関連論文は Springerリンク を参照できる
GPT-4時代（8K context）には、本全体をチャンクに分けてGPT-4に入れ、関連する一節を検索 するスクリプトを作っていた
当時は検索1回あたり1ドルほどかかったが、今ははるかに安くなった
Anthropicのcontextual retrieval の記事でも、文書がコンテキストにすべて収まるならRAGではなくそのまま入れるほうがよいとしている
ただしコンテキストが長くなると品質が落ち、コストや速度も問題になる
今では本全体をコンテキストに入れても 1セント程度 で可能だ
RAGで最も難しい部分は 文書パース だ
テキストだけなら問題ないが、表や複数ページにまたがる表、グラフ、目次、脚注などがあると精度が急激に落ちる
これを改善するために、RAPTORパターン のようにLLMが内容を要約・質問し、ベクターDBに保存するアプローチがある
ただし、あらゆるケースに通用する 汎用RAGパイプライン は依然として難しい課題だ
ベクターDBが長いテキストのまとまりと表形式のどちらをよりうまく扱えるのかも気になる
全文検索をRAGに適用した 新しい視点 が興味深かった
エージェント型ツールのループと あいまい検索（fuzzy search） の扱い方に関する洞察が印象的だった
こうしたシステムの 評価用データセット が標準化されているのか気になる
文書と質問セットがあり、特定の文書やチャンクが最も関連性の高い結果として出るべき、という形のベンチマークがあるとよい