前編では主にRAGとの違いについて説明をしました。後編では会話の内容をまるごと翻訳・整理しています。
※本記事はこちらの会話をもとにして作成しています
前編で説明したRAGとの違いだけでなく、Airticul8がエンタープライズでの利用を想定し設計されたソリューションだということがわかる内容になっています。
エンタープライズAIにおけるRAGの限界と、その先にある考え方
生成AI、とくに RAG（Retrieval Augmented Generation） をエンタープライズで活用する際に直面する課題と、それに対する新しいアプローチについて、対談形式で議論した内容をまとめたものです。
会話は、「RAGは現在もっとも一般的なAI活用方法として認識されているが、本当に企業規模で機能するのか」という問題意識から始まります。
1. RAGはAIの代表例だが、スケールすると問題が表面化する
対談ではまず、RAGが「AIの代表的ユースケース」として語られている現状に触れつつ、実際に企業が導入すると多くの問題が発生するという点が指摘されています。
特に、RAGは 小規模なデータ量ではうまく機能する一方で、エンタープライズ規模になると急激に精度が低下する という問題が議論されています。
2. Semantic Collapse（意味の崩壊）という問題
会話の中心的な論点として、「semantic collapse（意味の崩壊）」が挙げられています。
これは、文書数やトピック数が増えすぎることにより、
- ベクトル空間上で文書同士の距離差が小さくなり
- どのトピックも他のトピックから「同じくらい近い」ように見えてしまう
という状態を指します。
その結果、
- 特定のファイルやバージョンを指定しても、別の文書が参照される
- 微妙な違い（例：v2 と v2.1）を区別できなくなる
- 検索結果が安定しなくなる
といった問題が発生します。
対談では、これは 後処理やチューニングで解決できる問題ではなく、最初から設計に組み込まれていなければ回避できない と語られています。
3. 「検索は始まりにすぎない」という認識
会話の中では、
検索（search）は問題解決の出発点にすぎない
という考え方が繰り返し強調されています。
RAGは情報を探すことはできますが、
- 分析
- 内省（introspection）
- 複数情報の統合
- 文脈の理解
といった 検索後に必要となる作業 までは十分にカバーできない、という認識が共有されています。
4. エンタープライズにおける最大の障害は「データ移動」
対談では、エンタープライズAIが本番利用に至らない最大の要因として、データを移動させること自体が大きな障害になる点が指摘されています。
具体的には、
- System of Record（正本データ）を別システムにコピーすること
- データウェアハウスから外部に持ち出すこと
が、セキュリティ、ガバナンス、運用の観点から大きな制約になると説明されています。
そのため、データを動かさず、可能な限り元の場所で処理する設計が重要であるという考え方が示されています。
5. グラフによる3段階の理解（Structure / Content / Activity）
RAGの限界を補うアプローチとして、対談では グラフ構造を用いた段階的な理解方法 が紹介されています。
- Level 1：Structure ファイルの所在、フォルダ構成など、「どこにあるか」を理解する段階
- Level 2：Content 文書の内容そのものを扱う段階
- Level 3：Activity 利用履歴や関連付け、ユーザーとのやり取りを扱う段階
重要な点は、最初からすべての文書を深く理解しようとしないことです。
実行時（Runtime）に必要な範囲だけを段階的に処理するという考え方が説明されています。
6. 企業データの大半は実際には使われない
対談では、企業が保有する大量のデータのうち、
- 実際に業務上価値を持つのは 5〜10% 程度
であることが多い、という現実も語られています。
そのため、
- すべてのデータを事前に処理・分類する
- 一律にAIで理解させる
といったアプローチは、コスト面・運用面の両方で現実的ではないと指摘されています。
7. ストレージ統合における落とし穴
具体例として、クラウドストレージ（例：Blobストレージ）が取り上げられています。
- 見た目上はフォルダ構造が存在するように見えても
- 実際のAPIではフラットな構造である
という違いを正しく理解しないと、単純な操作でも全データの走査が必要になり、
AIとの統合コストが大きく増加してしまう、という問題が説明されています。
8. 固定的な「アプリケーション」という考え方からの転換
対談の後半では、
- 要件を事前に定義し
- 固定的なアプリケーションを構築する
という従来の考え方が、AI時代には適合しなくなりつつある、という議論が行われています。
代わりに、
- 目的（Mission）ごとに
- 必要なエージェントが動的に組み合わされ
- 処理が完了すると消える
という 目的駆動型・一時的なAI実行モデル が紹介されています。
9. エージェントは脆弱であり、監査が不可欠であるという指摘
会話の中では、マルチエージェント構成が現実には不安定であり、
- ツール呼び出しのリトライが頻発する
- 内部では多くの試行錯誤が行われている
という実情も率直に語られています。
そのためエンタープライズ環境では、
- なぜその結論に至ったのか
- どのような処理や試行が行われたのか
を説明できる 監査（Audit）可能性 が不可欠である、という問題提起がなされています。
10. 最後の論点：スケール以前に「精度」と「業務言語」が重要
対談の締めくくりとして、次の点が強調されています。
- エンタープライズでは、スケールよりもまず精度が重要であること
- 業界や企業ごとに用語や略語が大きく異なること
- ユーザーの業務言語（タクソノミー）を理解できないAIは実用にならないこと
単純な意味検索だけでは、企業の現実的な業務要求に応えることは難しい、という結論です。