🏭 RAGはクラウドではなく、オンプレでこそ本領を発揮する

観察

クラウドRAGは手軽だが、データ持ち出し・ランニング・遅延が壁になる。

仮説

社内ドキュメントを扱うなら、オンプレのほうが継続コストと安心感で勝つ。

介入（実装）

軽量モデル＋ローカルベクトルDBでPoC→ボトルネック計測→必要に応じてGPU/推論基盤へ。

結果

“現場で回るRAG”の条件が見え、提案が具体化した。

次の実験

業種別のRAGテンプレ（データ種・更新頻度・権限）を整備。

原文メモ（抜粋）

― 整ってなくても、突っ込めばAIが使える時代がやってくる ―
📍 序章：PoCでは気づけない、本当のRAGの壁
企業内文書や業務記録をAIで活用する流れが加速しています。
中でも「RAG（検索拡張生成）」は、社内情報をAIに喋らせる技術として期待されてきました。
僕もその魅力に惹かれ、今回は、
製造現場の作業記録22万件
をRAG化する実証に踏み出しました。
最初は簡単に考えていました。
データ突っ込んで、ベクトル作って、RAG回すだけでしょ？
ところがやってみて、わかったのです。
最大のボトルネックは「ベクトル生成」にある
と。
🧱 Embeddingは「やってからじゃないと分からない地獄」
僕がが現場でぶつかった embedding の実態：
1件あたり1〜2秒 × 22万件 → 半日〜1日処理
空文字・HTMLタグ・記号揺れ（例：−と-）の
手動正規化
RTX6000を積んでいてもギリギリの処理時間
クラウドならコスト爆増＆レート制限の罠
しかもRAG精度は
embeddingの質で全てが決まる
つまりRAG導入は「Embedding設計まで踏み込めるか」が成否を分けます。
🌐 そして見えてきた本質：RAGは オンプレ一択 だ
企業の独自情報
――つまり、営業日報・作業ログ・調査メモ・検査記録・報告書……
この種のデータは：
社外に出せない（情報資産）
更新頻度が高い（毎日・毎時）
フォーマットがバラバラ
でも、蓄積量が膨大
これらを
クラウドAPIに毎回流す
設計は現実的ではありません。
💡 だからこそ：
Embeddingも全文検索も、自社の中（オンプレ）で回すしか…

※このページはnote原文をAIO向けに「構造化」した要約版です。詳細は原文をご参照ください。