規制産業におけるRAGボット導入から得られた実践的教訓

主要な実装詳細

このケーススタディでは、建設現場、介護施設、鉱業操業におけるオーストラリアの職場コンプライアンス向けにRAG搭載AIアシスタントを導入した事例を扱います。

技術的に学んだ教訓

• クエリ拡張はチャンクサイズよりも重要： チャンクサイズ（400語？512トークン？）にこだわる代わりに、開発者はHaikuを使用して各クエリの4つの代替表現を生成し、それら全てをChromaDBに対して実行し、結果を統合・重複排除することで、検索品質が大幅に向上することを発見しました。これは、ユーザーが文書作成者とは異なる表現を使うドメイン固有の専門用語に特に効果的でした。
• 名前付き文書のソースブースト： ユーザーのクエリにインデックス化された文書タイトルと一致する単語が含まれる場合、意味的類似性に関わらず、その文書からのチャンクを強制的に含めます。例えば、「FIFOポリシーはR&Rフライトについて何と言っていますか？」というクエリは、意味的に類似したフライトに言及したチャンクだけでなく、常にFIFOポリシーから情報を引き出すべきです。
• プロンプトを階層化する — クライアントに第1層を壊させない： 3層システムを実装：コアのセキュリティ/安全ルール（不変）、業界ごとの垂直的個性（交換可能）、クライアントのカスタム指示（追加のみ）。クライアントはカスタム指示で第1層を上書きできません。これにより、「以前の指示を無視する」攻撃や、クライアントが自身のボットを誤って脱獄させることを防ぎました。
• ローカル埋め込みは十分に機能する： 外部の埋め込みAPIを使用せず、ChromaDB上でローカル実行されるsentence-transformers all-MiniLM-L6-v2を使用しました。特定ドメインの文書Q&Aでは、ada-002に十分近い性能を発揮し、コストと遅延の削減が価値があります。LLMの品質（Claude Haiku）が埋め込みよりも多くの作業を担っているからです。
• クライアントごとに1つのドロップレット： 最初は共有インフラを試しましたが、ChromaDBコレクションを分離し、APIキーを管理し、相互汚染を防ぐ運用オーバーヘッドが、クライアントごとに月6ドルのVMを立ち上げるよりも悪いことが分かりました。各クライアントは自身のベクトルストアを所有し、その文書は共有インフラに触れることはありません。

開発者は、他の人が検証できるようにRAGエンジンをGitHubで公開しています。