# RAG を第二の脳として：最善の解決策はなく、最適なシナリオがあるだけ 過去2年間、大規模言語モデルを開発するほぼすべてのチームが同じことを行ってきた。それは、自らのモデルにRAGを追加することだ。 理由は明白だ。大規模言語モデルには2つの先天的欠陥がある。知識に有効期限があり、でっち上げを行うことだ。RAGはこれら2つの問題を同時に解決することが期待されている。最新の外部資料を与え、その資料に基づいて回答させるのだ。 そこから、ある一般的な誤解が生まれた。**RAGは技術である。正しいものを選べば、勝ちだ。** しかし実際はそうではない。RAGは一つの技術ではない。**RAGはアーキテクチャの総称である。** シナリオが異なれば、まったく異なるアーキテクチャの選択が必要となる。大規模言語モデルがそれぞれに用途があるのと同じだ。4Bの軽量モデルは無価値ではない。エッジ推論、低レイテンシ、低コストのシナリオでは、数千億パラメータのモデルよりも実用的だ。数兆パラメータのモデルは推論能力が高いが、企業は導入できない。それぞれに適した場所がある。RAGソリューションの間にも、同じような違いが存在する。絶対的に最善のソリューションなどない。現在のシナリオに最も適したものがあるだけだ。**この記事で言いたいことは、「ノート＋ドキュメント＋RAG」という特定のシナリオ、つまりAIを使って第二の脳を作るというシナリオにおいて、どのようなソリューションが最適解なのか、そしてなぜなのか、ということだ。** --- ## 一、2025年におけるRAGの真の難しさ RAGのデモは半日あればできる。しかし、本番環境で露呈する問題は、主に3つの側面に集中している。 ### インデックス作成は一度限りの作業ではなく、長期的な負担である 「すべてのドキュメントをベクトルデータベースに埋め込む」というのは簡単そうに聞こえる。しかし実際に運用してみると、モデルをアップグレードする際、1000万のドキュメントを再処理するには約50億トークンが必要で、API費用だけで300〜650ドルかかる。ドキュメントを削除した場合、ベクトルデータベースに残った期限切れのエントリが数日間もクリーンアップされないことがある。権限が変更された場合、退職した従業員のドキュメントのインデックスが適時に更新されていなければ、数時間のセキュリティウィンドウが存在する。プラットフォームの制限として、SlackやNotionなどのツールはすでにサードパーティによるデータの一括取得を制限している。 ### レイテンシは多段階のチェーンである 各クエリリクエストは、問題の理解 → ベクトル検索 → 結果のソート → コンテキストの結合 → AIによる回答生成という経路を通過する。どの段階でも遅くなれば、全体が遅くなる。LLM推論は、エンドツーエンドの時間の60〜80%を占める。 ### コストはデータ量の増加に伴って増加する ドキュメントが増えれば、処理も増える。3つの段階すべてが膨張する。**共通の根源：クエリを開始する前に、まずドキュメントをインデックス化する必要がある。** これが「検索中心」のRAGである。 --- ## 二、2つの主要なソリューションタイプ ### ソリューション1：ベ���トルデータベース＋静的インデックス ドキュメントはまず細分化され、変換され、ベクトルデータベースに格納される。クエリ時には、データベースから最も類似したコンテンツが検索される。**得意とする分野：** 大量のドキュメント、固定されたコンテンツ。**苦手とする分野：** 頻繁に変化するコンテンツ。編集のたびにインデックスの再構築が必要。 ### ソリューション2：リアルタイムデータストリーム＋イベント駆動 データの変更が更新をトリガーし、インデックスがリアルタイムで同期される。**得意とする分野：** 秒単位の鮮度。**苦手とする分野：** インフラが複雑で、キャッシュ層、イベントメカニズム、二重ストレージ層が必要。 ### どちらの路線も対応できないシナリオがある 弁護士が訴訟の概要を作成している。200件の事件ノート、50件の規制文書がある。彼女は書きながら調べる。「以前の競業避止義務に関する事件はどのように論証されていたか？」。ある段落を書き終えた後、内容を変更し、数秒後にもう一度調べる。新しいコンテンツはすでに検索結果に含まれているべきだ。 このシナリオの特徴は、**コンテンツが頻繁に変化する**（静的ライブラリではない）、**クエリと創作が織り交ざっている**（書きながら調べる）、**ユーザーは一般の人である**（コードを書かず、ベクトルデータベースを知らない）、**データとプライバシーは絶対条件である**、ということだ。**これは「技術的な複雑さがより高い」という要件ではない。これは「技術的ソリューションがこんなに重くあるべきではない」という要件である。** --- ## 三、Search-centric から Memory-centric へ 主流のソリューションは、**知識ベースは静的である**と仮定している。クエリは一度限りの検索行為である。このパラダイムは**検索中心のRAG（Search-centric RAG）** と呼ばれる。モデル：知識ベース＝ドキュメントコレクション、RAG＝スマート検索。 しかし、第二の脳を構築するには別のパラダイムが必要だ。あなたは毎日ノートを書き、修正し、削除し、新しいドキュメントを取り込んでいる。知識は継続的に成長し、進化している。あなたがAIに望むのは「検索すること」ではなく、**継続的にあなたの知識を「記憶」し、必要なときに自然に呼び出すこと**だ。これが**記憶中心のRAG（Memory-centric RAG）** である。モデル：知識ベース＝継続的に進化する記憶、RAG＝自然なアクセス。 | | Search-centric RAG | Memory-centric RAG | | --- | --- | --- | | 知識の捉え方 | 静的なドキュメントコレクション | 継続的に成長する記憶 | | データの鮮度 | インデックス更新頻度に依存 | リアルタイム、書いたら即記憶 | | クエリ方法 | 能動的な検索 | 自然な対話 | | 創作との関係 | 検索と創作は分離 | 織り交ざる——編集は記憶の更新 | | 典型的なシナリオ | エンタープライズ検索、ポリシーQ&A | 個人知識管理、第二の脳 | **2つのパラダイムは、互いに置き換わるものではない。まったく異なるシナリオにサービスを提供するものだ。** それは検索エンジンとパーソナルアシスタントのようなものだ。 --- ## 四、Memory-centric RAG にはどのようなアーキテクチャが必要か？ アーキテクチャに対する4つの要件： **1. 事前インデックスに依存しないこと。** 編集のたびにインデックスを再構築していては、リアルタイム性はあり���ない。検索システムはエディターとデータを共有しなければならない。コンテンツが変われば、次の瞬間のクエリに反映される。 **2. コンテキストの使用量を最小限にすること。** ノートはプライベートデータであり、全量をアップロードすることはできない。しかし、AIは情報を見て回答する必要がある。バランスポイント：最も関連性の高い数文のみを送信し、断片を圧縮し、送信後は削除する。 **3. 生成能力には最良のクラウドモデルを使用すること。** ユーザーは手間をかけず、サーバー側は最小限のコンテキストのみを見る。**4. 編集は記憶の更新であること。** 修正は即座に記憶に入り、次のクエリに反映される。 --- ## 五、NoteRich の Memory-centric RAG 実践 ### ノートは常にローカルにあり、全量データはアップロードしない ノートはブラウザのローカルに保存される。許可もされない（コスト爆発）、すべきでもない（ユーザープライバシー）。 ### クエリ時には最小限の必要なコンテキストのみを送信 検索された最も関連性の高い数文のみ、圧縮された断片を送信する。サーバー側は処理後すぐに削除する。保存しない、記録しない、学習しない。**少量のアップロードは避けられないが、全量のアップロードは完全に回避できる。** ### 事前インデックスは行わず、編集は記憶 ベクトルデータベースを事前に構築しない。ノートを書くと同時に検索システムがオンラインになる。コンテンツの変化はリアルタイムで反映される。 ### 多次元評価＋文単位の精度＋サーバー側ステートレス 意味的類似性だけに依存しない。文単位で正確に返し、重複を排除して結合する。バックエンドは保存しない、記録しない、学習しない。 --- ## 六、第二の脳の4つのレベル **第一レベル：記憶。** 書かれたすべてのノートを、AIが「覚えている」。 **第二レベル：創作支援。** 古いノートに基づいて新しいコンテンツを生成する。 **第三レベル：リアルタイムフィードバック。** ある段落を書き終えると、AIが即座に感知する。 **第四レベル：編集は記憶。** AIが生成したコンテンツを修正すると、即座に記憶に入る。知識環境が閉ループになる。 --- ## 七、限界を認め、それを超える ### 限界一：ブラウザの能力上限 オンライン版は完全にブラウザ内で動作する。実際のテストでは、数万件のテキスト、数千万文字で非常にスムーズである。**数十万件以内であれば問題なく、それを超えるとパフォーマンスが低下する。** これがブラウザの物理的な限界である。しかし、個人ユーザーがこの限界に達することはほとんどない。もし達したなら、それはエンタープライズレベルの要件である。オフライン導入ソリューションでは、同じアーキテクチャがサーバー側で動作し、必要に応じて拡張される。 ### 限界二：マルチモーダルサポート 現在はテキストに焦点を当てている。画像OCR、音声文字起こし、動画分析は、オンライン版ではブラウザの計算能力に制限される。エンタープライズオフライン導入では、サーバー側でカスタマイズして統合できる。**テキスト記憶は基本であり、マルチモーダル記憶はアップグレードである。** ### 限界三：ドキュメントを横断した複雑な推論 多段階推論は生成段階のタスクであり、検索段階のタスクではない。検索は「見つける」こ���だけを担当し、「推論」は担当しない。NoteRichは、コンシューマーグレードのモデルが高品質なコンテキストを通じて実用的な効果を発揮できるようにする。 ### 限界四：完全オフライン トップクラスの大規模言語モデルは通常のコンピューターでは実行できない。これは物理法則である。オフライン導入ソリューションでは、企業が自社で導入したローカルモデルに接続できる。 --- ## 八、オフラインソリューション 法律事務所、病院、金融機関は、データを絶対に内部ネットワークの外に出せない。オフライン導入では、Memory-centric アーキテクチャを単一コンポーネントのバックエンドとしてパッケージ化し、ワンクリックで導入、プロセス全体が企業ネットワークから出ることはない。 --- ## 九、最終的なビジョン **Search-centric RAG は「見つける」問題を解決する。** Memory-centric RAG は「記憶する」問題を解決する。両者は競合関係ではない。 NoteRichが行っていることは、Memory-centric RAG の道において、より直接的な選択をいくつか行ったに過ぎない。**高速、低コスト、高品質。** 一般の人が30秒以内にAIを使って知識管理を始められるようにし、企業がファイアウォール内で完全に信頼できるようにする。 **[NoteRich を試す →](https://noterich.com/app/)** *オープンソースコンセプトプロジェクト [github.com/Lisanoterich/memory-centric-rag](https://github.com/Lisanoterich/memory-centric-rag)*