HeadlinesBriefing favicon HeadlinesBriefing.com

RAGの過剰設計を回避:シンプルから始める

Hacker News •
×

多くのチームは埋め込みやベクターデータベースに一直線で進み、RAGスタックを過剰に設計してしまいますが、ユーザーは特定のドキュメントを探しているだけです。アーキテクチャを選ぶ前に、データ鮮度、コーパスの特性、クエリパターン、スケール、チーム能力の5つの要因を検討してください。

BM25とフルテキスト検索(Elasticsearch、Postgres)から始めましょう。このアプローチは機械学習の複雑さがなく、クエリあたりのコストはゼロ、10ミリ秒以内で動作し、デバッグも簡単です。チャンキング戦略や評価オーバーヘッドなしで多くのユースケースを効果的に処理できます。主な制限は同義語の欠如と語義クエリでの失敗です。

キーワード中心のクエリや正確なマッチ、独自用語が求められる場合はBM25が最適です。ユーザーが会話的なクエリを書く場合は、LLMを使ってこれをクリーンなキーワード検索に変換します。この方法はクエリあたり約0.001ドルのコストかけ、システムプロンプトの調整で迅速な反復が可能です。

埋め込みを使用すると、結果が悪い場合はコーパス全体を再埋め込みし、回帰テストが必要です。クエリリライティングでは、システムプロンプトを調整して問題を修正し、すぐにテストできます。シンプルに始め、データが追加の複雑さが必要であることを証明するまで進まないでください。