オーストラリアの職場におけるコンプライアンス用途向けに、RAG対応のAIアシスタントを構築しました。建設現場、介護施設、鉱山事業で導入しました。実際に痛い目を見て学んだことは以下です：
- クエリ拡張はチャンクサイズより重要
誰もがチャンクサイズ（400語？512トークン？）にばかり注目します。真の成果は、Haikuを使って各クエリから4つの代替表現を生成し、それら4つをすべてChromaDBに投げてから、結果を統合し重複排除することでした。検索の品質が目に見えて向上しました。特に、ユーザーが文書作成者とは異なる言い回しをするような分野特有の専門用語では効果が大きかったです。
- 名前付きドキュメントへのソースブースト
ユーザーのクエリに、インデックスされているドキュメントのタイトルと一致する語が含まれている場合、そのドキュメントからは意味的な類似度に関係なく、そのチャンクを強制的に含めます。たとえば「FIFOポリシーではR&Rフライトについて何と言っていますか？」は、フライトに言及しているだけの意味的に似たチャンクではなく、常にFIFOポリシーから引くべきです。
- プロンプトをレイヤー化—クライアントにレイヤー1を崩させない
3層構成です：中核となるセキュリティ／安全のルール（不変）、縦方向（業界ごとに差し替え可能な）パーソナリティ、クライアントのカスタム指示（加法的に追加のみ）。クライアントは自分たちのカスタム指示によってレイヤー1を上書きできません。これで「前の指示を無視して」といった攻撃から守られ、さらにクライアントが自分のボットをうっかりジェイルブレイクしてしまう事態も防げました。
- ローカルの埋め込みで十分
ChromaDB上でローカル実行しているsentence-transformersのall-MiniLM-L6-v2です。外部の埋め込みAPIは不要。特定ドメインにおけるドキュメントQ&Aなら、ada-002にかなり近い性能を発揮するため、コストとレイテンシの削減に見合います。LLMの品質（Claude Haiku）のほうが、そもそも埋め込みよりも大きな仕事をしています。
- クライアントごとに1滴（1つのインスタンス）
最初に共有インフラを試しました。ChromaDBのコレクションを隔離しておくこと、APIキーを管理すること、クロスコンタミネーション（混入）を防ぐことにかかる運用上のオーバーヘッドは、クライアントごとに月6ドルのVMを立ち上げるだけのほうがマシだと感じるほどでした。各クライアントが自分のベクターストアを所有します。ドキュメントは共有インフラに触れません。
コードの共有も喜んでやります—RAGエンジンはGitHubにあるので、誰かが分解して見たいならどうぞ。
[link] [comments]
