なぜRAGの見積もりは当たらないのか——金額を決めているのは、渡される文書の状態です
RAGの実装部分は正確に見積もれます。見積もれないのは、渡される社内文書の状態のほうです。スキャンPDFはOCRより精度検証に時間がかかり、Excelは行と列の関係を文章に組み直す設計が要る。そして「就業規則_最新版(修正)」のような版の重複だけは、技術では解決できません。
RAGの実装部分は正確に見積もれます。見積もれないのは、渡される社内文書の状態のほうです。スキャンPDFはOCRより精度検証に時間がかかり、Excelは行と列の関係を文章に組み直す設計が要る。そして「就業規則_最新版(修正)」のような版の重複だけは、技術では解決できません。
社内RAGの相場は「小規模50〜200万円、運用は月5〜50万円」と言われます。ですがこの幅を作っているのは開発工数ではなく構成の選択です。埋め込みをローカル化しpgvectorを使えば追加の固定費は消え、小規模なら30万円台・保守は月1万円から始められます。そして予算を本当に壊すのは、初期費用ではない3つの場所です。
専用のベクトルDBを契約せず、すでに動いているPostgreSQLにpgvectorを入れてRAGを組む構成。次元数が後から変えられない理由、e5系のプレフィックス、HNSWとIVFFlatの選び分け、しきい値をギャップで切る方法、そして最も重い「埋め込みモデルを差し替える日」の入れ替え手順まで、Djangoの実コードで解説します。
ベクトル検索は「意味が近いか」しか見ていないため、閲覧権限のない文書も平気で返してきます。社内RAGが本番直前に必ずぶつかるこの壁を、Django+pgvectorの事前フィルタでどう塞ぐか。後フィルタが破綻する理由、絞り込むと件数が足りなくなるHNSWの罠、そして実装後も残る3つの漏洩経路まで書きます。