（ダウンロード不可）
関連スライド
各ページのテキスト
DBひとつでRAGから エージェントメモリまで TiDB X ⼊⾨と ベクトル/全⽂検索の実践 PingCAP株式会社 エバンジェリスト 関⼝匡稔
関⼝匡稔 X: @bohnen PingCAP株式会社 エバンジェリスト 漫画でわかるNewSQL 「わかばちゃんと つくって、壊して、直して学ぶ NewSQL⼊⾨」共著
アジェンダ ● TiDB紹介 ● AIとデータ∕データベースの関係 ● TiDBによるRAG∕ハイブリッド検索の実装 ● エージェントメモリ ● エージェントの記憶を担うDBとは？
TiDB紹介
とは MySQL互換のオープンソース分散型データベースで、従来のRDBMSとは異なり、無停⽌で の⽔平スケールが可能となっています。また、DWH機能も内包しており、分析までワンス トップでこなせるユースケースの幅広さも特徴です。 ミッションクリティカルな ワークロードをスケーラブルに +リアルタイム分析能⼒ ビルトインDWH ⽔平分散 ⾼可⽤性 高速分析 リアルデータ ⾼い⼀貫性 MySQL互換 自動同期 組み込み型
TiDBの導⼊実績 ワールドワイドで3000社 以上の基幹業務システム で採⽤されています 特に⾦融、インターネッ ト、Software&SaaS、 ゲーム業界を中⼼に採⽤ 実績が増加しています 弊社事例ページに詳細ご ざいますので、是⾮ご覧 ください https://pingcap.co.jp/case-study/
TiDB X：AIネイティブDBへ TiDB Xの先進性 ● ● ● ● OLTPとOLAPの融合（HTAP） 柔軟なスケーラビリティの追求 運⽤管理負荷の軽減 AIネイティブなデータ基盤への変⾰ TiDB(OSS) リリース 2015 TiDB Cloud マネージドサービス TiDB Cloud Serverless 柔軟にスケール可能な All-in-One DB 安価でスケーラブルな 全ての開発者向けDB 2020 2022 TiDB X 発表 AIエージェント時代の All-in-One DB 2025
AI利⽤に適したマイクロサービス‧サーバレス サーバレス+オートスケールで、管理不要かつ従量課⾦を実現 ● データはオブジェクトストレー ジに保存し最⾼の耐障害性 ● 数百万スケールの論理クラスタ をサポート。エージェント毎の データベースでデータ分離も安⼼ ● 従量制（クエリ + ストレージ） の課⾦で間⽋的なAIワークロード の利⽤に最適
TiDB X: AI時代のデータベース AIワークロードのデータ基盤に必要な全てをワンパッケージに オートスケール マルチモデル AIワークロードに 応じて⾃動的に拡張 リレーショナル + ベクトル検索 + 全⽂検索 従量課⾦ Zero Friction すぐ⽴ち上がり 利⽤した分だけの課⾦ API/Skillを活⽤し、利⽤ 開始から開発までAIで
TiDB Cloud Zero：Built for Agents AI駆動開発に適したTiDB Cloud。サインアップも設定も不要ですぐ作れる サインアップ不要で、AIエー ジェントから作成‧利⽤が可 能なTiDB Cloud AIエージェントのプロジェク トレベルでの利⽤を想定し、 保存期間は30⽇間。残した い場合はStarterへのアップ グレードが可能 https://zero.tidbcloud.com
AIとデータ／ データベースの関係
AIとデータの関係：コンテキストエンジニアリングの⼀環 LLMのコンテキストを作成する中で、外部情報として埋め込まれる ① ユーザー (User) ② LLM (⼤規模⾔語モデル) ③ 外部情報源 (Knowledge) 質問の送信と最終回答の 受け取り 質問の意図を解釈し、外部情報源を 検索した上で、その⽂脈を踏まえて 回答を⽣成 データベース、ドキュメント、Web 等。LLMが学習していない最新‧固 有データを保持 1 質問の送信 ユーザーが知りたい内容 をLLMに向かって⾃然⾔ 語で問いかけます。 2 外部検索の実⾏ 3 検索結果の返却 LLMは質問を元に、最適 なキーワードやベクトル を⽤いて情報源を検索し ます。 外部情報源が、質問に関 連するドキュメントや データスニペットを返却 します。 4 回答の⽣成 LLMは得られた検索結果 （コンテキスト）を統合 し、⾼精度な回答を作り ます。 5 回答受領 ユーザーは正確で最 新の⽂脈を反映した 回答を受け取りま す。
AIにおけるデータベース利⽤の⼤枠 外部情報参照のRAGと、書き込みも含まれるメモリの２種類に⼤別される RAG（検索拡張⽣成） 最新‧固有データ モデルが学習してい ない最新情報や社内 業務データへのアク セスを実現 エージェントメモリ セマンティック 検索 エージェントの ⻑期記憶 曖昧な問いに対し、 「意味の近さ」で情 報を抽出 動作過程やユーザー ごとのパーソナライ ズ情報を保持し、改 善 継続性の確保 セッションを跨いだ コンテキスト維持 や、ユーザー⼊⼒か らの学習能⼒を提 供。
AIの精度はデータベースの問題でもある “The database is the product” - Ed Huang / PingCAP CTO LLMの性能だけでなく元データの質や検索⼿法に依存する。データとデータベースを真剣に考えるべき 必要なデータのサイロ化 インデックス同期の遅延 画⼀的な検索アプローチ フィードバックの未反映 必要なデータが各所に分散して存在しているた め、それぞれの情報取得に時間がかかり、レイ テンシが悪化 ⼀般的な検索しか⾏えず、ユーザーの個別ニーズ や特有のデータソースの強みを活かした回答⽣ 成ができない 元となる⽂書と検索⽤インデックスの同期がと れておらず、ユーザーに古い情報や誤った情報を 返してしまう AIが出⼒した誤りの修正結果が元のデータソース にフィードバックされず、同様の誤りを繰り返し 起こす
TiDBによるRAG／ ハイブリッド検索の実装
ベクトル検索と全⽂検索 RAGでよく利⽤される代表的な２つの⼿法 ベクトル検索（セマンティック検索） 全⽂検索（キーワード検索） 「意味の近さ」で探す 「⾔葉の⼀致」で探す テキストを特徴量によってベクトル化し、多 次元空間上での距離を⽐較して⽂脈やニュア ンスが近い情報を抽出 ⽂書内に指定されたキーワードが含まれてい るかを調べ、適合性の⾼い順にソートして抽 出 ● ● ● あいまい検索をサポート ユーザーの問いと表現が違っても意味が 近ければヒット キーワードが直接含まれない⽂書も抽出 可能 ● ● ● 固有名詞や製品型番などの完全⼀致検索 キーワードが含まれる確実な⽂書のみを 的確に特定 質問⽂で適切なキーワードが与えられな いと⽂書がヒットしない
ベクトル検索 - Demo Livedoorニュースコーパスを利用 https://www.rondhuit.com/download.html#ldcc
TiDBでのベクトル検索‧全⽂検索の利⽤ SQLで完結するシンプルな実装 個別DBの⽤意や複雑な同期は不要 ● ● ● ● DDL宣⾔のみでハイブリッド検索環境を構築 可能 外部のベクトル専⽤DBや検索エンジンとの連 携は不要 データの登録‧更新に同期ラグが発⽣せず、 常に最新のデータに対して検索を実⾏できる トランザクション（ACID特性）を保ったま ま、業務データとインデックスを同⼀DB内で ⼀元管理 実装例：テーブル定義（DDL） -- 1つのテーブルに両方のインデックスを定義 CREATE TABLE `products` ( `id` INT NOT NULL, `category` VARCHAR(255), `price` INT, `name` VARCHAR(255), `description` TEXT, `description_vec` VECTOR(1024) GENERATED ALWAYS AS ( EMBED_TEXT("tidbcloud_free/amazon/titan-embed-text-v2", `description`) ) STORED, PRIMARY KEY (`id`), FULLTEXT INDEX `fts_idx` (`description`) WITH PARSER MULTILINGUAL, VECTOR INDEX `vec_idx` ((VEC_COSINE_DISTANCE(`description_vec`))) );
ハイブリッド検索 💡 複数の検索⼿法の組み合わせによる⾼精度化 ベクトル検索と全⽂検索など複数の検索⼿法を組み合わせ、結果をマージ‧並べ替えて返す⼿法 LlamaIndex での実装例 TiDB Cloud Starter (pytidb) での実装例 LlamaIndex pytidb vec_retriever = vec_index.as_retriever( similarity_top_k=5 ) fts_retriever = fts_index.as_retriever( similarity_top_k=5 ) hybrid_rrf = QueryFusionRetriever( [vec_retriever, fts_retriever], similarity_top_k=5, num_queries=1, mode="reciprocal_rerank", use_async=False, ) return hybrid_rrf.retrieve(QUERY) # pytidb results = ( table.search(QUERY, search_type="hybrid") .text_column("description") .vector_column("description_vec") .limit(5) .to_pydantic() ) return results
マルチモデルによる検索の複雑さの解消 個別インデックスによるRAG TiDB XによるRAG Auto Embeddingで変換も不要 RDB ベクトルDB 全⽂検索DB LLM 応答速度の低下 データの不整合 データ統合がどこで ⾏われるかも 気をつける必要がある （コンテキスト？） 統⼀されたアクセス 1111 LLM 素早い回答 効率的な開発 TiDB
RAGの活⽤例：TiDB AI 精度向上のために ‧クエリ拡張 ‧知識グラフ ‧推奨演習 などを実装 https://tidb.ai/
RAGの活⽤例：TiDB AI
TiDB.AIの⼯夫 ハイブリッド検索のクエリ拡張とGraph RAGによる精度向上 クエリ拡張（検索ヒット率の向上） Graph RAG（関連ドキュメントの抽出） 💡 質問⽂の改変によるヒット率の向上 🔗 知識グラフ併⽤による確実な⽂脈補完 ユーザーのシンプルな⼊⼒からキーワードを散り ばめた詳細な質問に拡張。全⽂検索とベクトル検 索のヒット率向上を図る ベクトル検索で直接ヒットした特定の⽂書だけで なく、ナレッジグラフ上で結びついている関連⽂ 書群も合わせて同時に抽出 ● 元クエリの例 「TiDBのAI機能について教えてください」 ● ⾃動改変‧拡張後 「TiDBのAI機能について、現在利⽤可能な機能 （Vector Search、Hybrid Search等）、統合⽅法 （LlamaIndex、SDK等）、およびメリット（RAG 等）を含めて詳しく...」 ● 情報の断⽚化を防⽌： 単⼀のキーワードやベ クトル類似性だけではなく、背景情報や設定 ガイドなど関連情報を含める ● LLMへの最適なインプット： 網羅的なコンテ キストを提供することで、ハルシネーション を防ぐ
Graph RAG（グラフ構造を⽤いた検索） あらかじめ文書からエンティティ を抽出し、エンティティの説明と 関係をグラフとして保存 質問文からベクトル検索を使っ てエンティティを検索し、そこから グラフを辿って近傍のエンティ ティと説明を取得 検索した情報に近しい情報を与 えてより包括的な説明を可能と する
エージェントメモリ
AIエージェントとは 回答を返すだけではなく、与えられたタスクを状況に応じて⾃律的に遂⾏する ⽣成AI = レシピブック Agentic AI = シェフ ⼿順を提供するが、何がユーザーに適してい ユーザーの好みや、状況に適応した料理を提供 るかを判断できない。回答が常に同じ する。 ⽬標を把握し、⾃律的に⾏動する。 知覚 (Perceive) 推論 (Reason) ⾏動 (Act) 学習 (Learn) 外部ソースの情報 ⽬的と制約の評価 ワークフローの実⾏ フィードバックループ
AIエージェントの例： TiPilot 今⽇の10時頃、DBの レスポンスが急に悪化 したんだ。原因と対処 を教えて Tools（業務固有データ） DB ログ DB メトリクス Skills（考え⽅、取り組み⽅） リファレンス 該当時間帯でDisk IOの遅延 が観測されています。同時期 に実⾏された分析クエリが原 因の可能性が⾼く‧‧‧ トラブルシューティ ングガイド
AIエージェントとメモリ 今⽇の10時頃、DBの レスポンスが急に悪化 したんだ。原因と対処 を教えて Tools（業務固有データ） Skills（考え⽅、取り組み⽅） memory（記憶、履歴） この事象は半年前にも発⽣し ており、その際とは別のSQL ですが、実⾏元は同じです。 分析⽅法が変わっている可能 性があります。
エージェントメモリ：mem9 https://mem9.ai/ TiDB X をベースとして、エージェントの⻑期記憶の保存と検索に特化した製品
mem9の記憶⽅法 TiDBをベースとして、⻑期記憶を段階的に最適化して保存‧利⽤する仕組み 01 02 03 会話履歴の保存 Factの抽出 リコンサイル 全ての会話データをTiDBに直 接保存し、やり取りの全履歴 を漏れなく記録する LLMを活⽤して会話から記憶 すべき重要な事実のみを抽出 既存の事実とセマンティック 検索で⽐較。統合‧上書き、 ⽭盾する情報の削除を判断 記憶の利⽤：新しい会話へのコンテキスト挿⼊ 次の2つの要素を会話のコンテキストに動的に挿⼊し、最適化されたエージェント応答を実現 ● ユーザーの指⽰に基づき、整理されたFactをセマンティック検索した結果 ● 直近のやり取りを記録した最新の会話履歴
参考: Mem0の記憶⽅法 https://docs.mem0.ai/core-concepts/how-it-works 複数のデータベースを使い、テーブル‧ベクターインデックス‧グラフで保存する
参考: CrewAIの記憶 https://docs.mem0.ai/core-concepts/how-it-works 半減期による疑似忘却プロセス、カテゴリ毎の記憶により、パーソナル‧マルチエージェントに特化 100% 50% 25% T½ 半減期による疑似忘却 (Decay) マルチレイヤー記憶階層 (Hierarchy) エージェント単位 (Agent) プロジェクト階層 (Project) 一定期間をすぎるとスコアが 1/2になり、 検索結果として採用されづらくなる タスク階層 (Task)
AIエージェントの学習 フィードバックループ 検索‧注⼊ メモリだけではなく、全領域で 学習‧改善を⾏っていく Tools 業務固有データ コンテキスト Tool/Skillsの 更新 Skills 能⼒‧ノウハウ 会話履歴 エージェント memory 記憶、履歴 分析‧評価 開発者 プロンプトの 改良
TiPilotの改善活動の例 Skillやシステムプロンプトも固定ではなく改善していく コンテキスト共有機能 スキルハブ コンテキストを共有して、チームで 調査を⾏う。開発チームへのバグ報 告にも有⽤ スキルを選択したり、アップロード してカスタマイズ。ロールに応じて 利⽤できるように
エージェントの記憶を担うDB とは？
エージェントの認知 CoALAにおける4つの分類 ※枠線内は筆者の解釈 https://arxiv.org/abs/2309.02427 作業記憶 Working Memory エピソード記憶 Episodic Memory 現在のモデルが認識するコンテキスト LLM呼び出しをまたいで永続するデータ 過去の意思決定の履歴を保存 過去のユーザーとLLMのやりとりやイベント履歴を保 持 セッション （ファイル） メモリ 意味記憶 Semantic Memory ⼿続き記憶 Procedural Memory 世界およびエージェント⾃⾝の知識 エージェントの動作を規定する仕組み エージェントの外部データソース、 Tools/リファレンス LLMの重みによる暗黙的知識と、コードに書かれた明 ⽰的⼿続きの２つがある プロンプト/スキル
AIエージェントの活動をカバーするDB 検索‧注⼊ Tools 意味記憶 コンテキスト マルチモデル検索 drive9 Skills ⼿続き記憶 ファイル システム mem9 会話履歴 エージェント memory エピソード 記憶 - メモリ スケーラブルな書き込み TiDB X データベース
エージェントファイルシステム：drive9 https://drive9.ai/ ⾮構造化データも含めたファイル保存‧セマンティック検索を実現
エージェントの記憶装置に求められる特性 01. リアルタイムの更新と検索 02. 複数の検索⽅式 頻繁なインプットと即時反映 マルチモデルによる柔軟なアプローチ エージェントは過去の情報を検索するだけでな く、対話や⾏動のログをリアルタイムで記憶（更 新）し続ける必要がある ベクトル検索だけでなく、キーワード、構造化ク エリなど、状況に応じた最適な⼿法をサポートす る 03. 多彩なデータ形式のサポート 04. データの独⽴性確保 ⾮構造化データのセマンティック検索 テナント‧ユーザーごとのメモリ分離 テキストデータだけでなく、⾳声、画像、動画、 システムログなど、エージェントが触れるあらゆ る形式を記憶‧検索 記憶はパーソナルなもの。エージェントごと、エ ンドユーザー単位での厳格な記憶の分離が必須 TiDB Xはこれらの特性をサポートできるように進化していく
Thank You! / 42