RAGの「鮮度」定量化：TiDBでの実装から見えた落とし穴と最新データ参照の境界線

本記事は、業務データを扱うRetrieval-Augmented Generation (RAG)システムにおいて、「データの鮮度（Staleness）」を定量的に評価する方法論と、具体的なデータベースの実装上の知見を共有している。

まず「鮮度」の問題点として、在庫切れの商品に関する質問を例に挙げ、定期的なデータ同期を行う従来の「同期型RAG」（VectorDB+RDBを別々に持ち同期）では、更新直後の商品に対して最大43%もの誤答率が発生する危険な状況が示されている。これはLLMの性能ではなく、検索基盤（データベース）が古いスナップショットデータを返すことに起因する。

この鮮度リスクを定量化するため、「鮮度誤答率」という指標が提案された。これは「同一質問をライブデータと同期データに同時投入し、ライブが正答かつ同期型が誤答の割合」として定義され、LLMを介さずデータベース層で判定される。実験では、更新直後の商品を狙う「active（上限ケース）」において、同期間隔が広いほど誤答率が増加することが示された。

次に、TiDBを用いた具体的な実装検証が行われた。日本語全文検索においては、`MULTILINGUAL PARSER`は形態素解析ではないため、日本語の自然文では漏れや誤ヒットが発生しやすく、英数字（SKU/型番）に限定する設計レシピが推奨されている。

さらに、「鮮度境界」の実測結果として、TiDBのHTAP構造におけるデータ反映タイミングの違いが明らかになった。点参照（TiKV行ストア）は更新直後から即時性が保たれる一方、分析・大規模ベクトル検索に使用される列ストア（TiFlash）には約142msという同期遅延が存在することが実測された。

結論として、「鮮度ゼロ遅延」を保証するには点参照の利用が必須であり、ライブ参照RAGは常に最新の状態を参照できるが、大規模な意味検索を行う場合はこの0.1秒級の境界線を考慮する必要がある。また、TiDBの優位性は「単一エンジンでの即時性（read-your-writes）」と「並行更新下での干渉耐性」にあり、実効85 updates/秒の書き込み負荷がかかっても検索レイテンシが劣化しないことが示されている。

---

背景

RAG（Retrieval-Augmented Generation）は、LLMの回答精度を向上させるために外部データベースから情報を取得する仕組みである。しかし、この情報源となるデータがリアルタイムで更新される業務システムにおいて、「データの鮮度」が大きな課題となる。本記事は、同期的なデータパイプラインと、データを単一DBに保持するライブ参照型の比較を通じて、その技術的限界を定量的に示した。

重要用語解説

• RAG: LLM（大規模言語モデル）が回答を生成する前に、外部データベースから関連情報を検索し、プロンプトとして渡す仕組み。これにより、最新かつ根拠に基づいた回答が可能になる。
• 鮮度誤答率: 同一の質問に対し、リアルタイムデータと同期遅延のあるデータ源を比較した際に、古い情報（スナップショット）に基づいて誤った答えを出す割合。RAGシステムの信頼性を測る指標となる。
• TiFlash: MySQL互換DBであるTiDBが採用する列ストア技術。集計や分析処理に特化しており、大規模なベクトル検索などOLAP的な用途で利用される。

今後の影響

本知見は、リアルタイム性が求められる業務RAGシステムの設計指針を明確にする。特に「点参照（即時）」と「分析系（~0.1秒遅延）」の鮮度境界線を理解し、どの種類のデータアクセスにどのDB層を利用するかというアーキテクチャ設計が重要となる。これにより、システムの実用性と信頼性が飛躍的に向上する。