メモリエンジニアリングに必要な、多岐にわたるDB／ストレージ技術をどう整理するか
メモリエンジニアリングを自社で挑戦する際に気をつけたいのが、「コスト・レイテンシー・信頼性」の3つの観点だという。
まずコストの観点でいうと、大量のプロンプトを入力することになるため、ステップ数に比例してコストが増大する。そのため、記憶させる量の上限を決める必要がある。
また、レイテンシーは、検索・リランク・要約の多段パイプラインの処理時間の累積だ。“何を記憶するかの判断自体”が時間を消費することを念頭におきながら、LangChainであれば何ホップ分を要約するか、時系列で要約するのかなど、記憶のさせ方を意識的に選びたい。
さらに、コンテキストが長くなればなるほど、アテンションの分散によって信頼性が下がる。ノイズとならないよう、どんなコンテキストを重視して記憶させるのか、あらかじめ設計しておかなければならない。
「AIエージェントを適切に作ろうと思ったら、最終的に人間の脳のメカニズムや動きを模倣することになる」と語る小川氏は、認知基盤ごとのユースケースと必要なデータベースやストレージを、次のように整理した。
今のスレッド内のやり取り、直前の差分を覚える「短期記憶」は、In-memory DB、 Key-Value Storeにため込む。一方、README・設計書・既存コードの「意味検索」を保存するのが、Vector DB、Document DB、Full-text Search Engineだ。
また、過去の修正履歴・以前の議論の参照する「エピソード記憶」のストレージには、RDB、Time-Series DB、Vector DBがある。CLAUDE.mdのルール・コーディングの方針は「手続き記憶」として、Document DB、JSON Storeに保存する。最後に、モジュール依存関係・クラス構造理解の「関係性記憶」は、Graph DB、Knowledge/Property Graph Storeにため込む。
このように認知基盤の違いによって、必要となるデータベースやストレージは多岐にわたる。その結果、Graph RAGやAgentic RAGなどの“◯◯RAG”が乱立し、どんどん実装が複雑になってしまう。
この課題を解消するのが、メモリコアとしての記憶領域をConverged DBに置いたOracle AI Databaseだ。これにより、ありとあらゆるデータをひとつのデータベースで扱える。さらに、これまではデータの種類だけ、検索の書き方を覚えなければならなかったが、Converged DBを扱うために必要なのは、SQLだけだ。もっと言えば、Oracle AI Databaseでは自然言語でSQLを生成できるため、SQLさえ不要である。
Oracle AI Databaseには、「JSON Relational Duality View」という、JSONをRelational Dataとして、またRelational DataをJSONとして扱える機能がある。そのため、データの結合や移動のコストがゼロとなり、1つの基盤で分析・検索・集計ができるメリットがある。
つまり、Oracle AI DatabaseはこれからのAIエージェントに必要不可欠な“記憶（短期／長期／意味記憶／エピソード記憶）”を統合管理できる、唯一のAIデータベースなのだ。
「Oracle AI Databaseは、AzureやGoogle Cloud、AWSといった他社のクラウド環境でも使うことができる。Oracle Cloud Infrastructure（OCI）は、お客様のデータセンタからOCIへのデータ転送料が無料。OCIからインターネットへのデータ転送も毎月10TBまで無料だ。他社のクラウド環境で構築した生成AIアプリケーションにメモリ機能を加えたいなら、メモリ機能だけでもOracle AI Database を使ってみてもらいたい」と語り、小川氏はセッションを締めくくった。
日本オラクル株式会社からのお知らせ
本セッションでご紹介したサービスにご興味を持たれた方は、ぜひ公式サイトをご覧ください。
