AIエージェントのグラフ記憶に使うデータベースの費用を比較
Graph Memory for LLM Agents: At What Cost? A Comparative Evaluation of Query, Ingest, and Update Performance Across Graph Database Engines
この論文をやさしく読む
ひとことで言うと
AIエージェントのグラフ記憶に使う複数のデータベースを、検索とデータ投入の費用で比較した。
何に役立つ？
グラフ記憶を設計するときに、検索の種類と更新頻度に合わせて保存方式を選ぶ参考になる。
この研究の面白いところ
検索速度だけでなく、データを検索可能にするまでの投入速度の大きな差を総費用に結び付けた点。
どこまで分かった？
評価は合成の生物医療風グラフと20の検索、指定された八システムでの結果であり、あらゆる負荷での順位ではない。
v1のアブストラクトに基づくAI解説。日本語訳とは別に、用途の解釈を含みます。
アブストラクトの日本語訳
つながりのあるデータにはグラフデータベースが必須だと語られることが多いが、製品の説明と切り離して、検索計画、索引、データを検索可能にする費用の違いを測る機会は少ない。本研究は生物医療分野に似せた合成の属性グラフを作り、102万節点、節点と辺を合わせて534万行を用意した。近傍の検索、長さを制限した経路、集合の共通部分、反結合、集計、上位k件、時間フィルター、全走査、関係結合にまたがる20の検索を用いる。Corvicの記憶管理層を支える列指向の検索エンジンCorvic AIと、LoraDB、Ladybug、DuckPGQ、Memgraph、Neo4j、HugeGraph、FalkorDBの七システムを、規模が三桁にわたる三種類のグラフで比較した。検索遅延の幾何平均、大量投入の処理量、個別更新の遅延、回答の正しさを報告し、検索回数に応じた投入と検索の費用の兼ね合いを示す簡単な総費用モデルを導く。 比較した範囲で常に最速のシステムはなかった。ネイティブなグラフエンジンのLadybugは狭く長さを限った近傍検索でCorvic AIより速く、Corvic AIはグラフの大部分を走査・結合する検索で速かった。SQL/PGQを通じてグラフ検索を実装するDuckPGQは、検索計画の選択だけで測定可能な遅さが生じた。データで最も大きい費用差は検索遅延ではなく、検索可能にするための投入費用だった。大量投入の処理量は毎秒5000～430万行と三桁の差があり、単純な交差点の計算では、データの更新一回あたり検索回数が約10⁵回未満なら、この差が総費用を支配すると示された。
v1の要旨から自動生成。本文の精読・人による確認は未実施。
- 初稿
- 2026-09-20（UTC）
- 最新改訂
- 2026-09-20 · v1
- 査読・掲載
- 査読状況未確認
更新履歴
- v1 2026-09-20 この版を読む
取得できた版を表示。版の更新は査読済みを意味しません。過去版の本文差分は未解析です。
原文の要旨
Graph databases are frequently positioned as categorically necessary for connected-data workloads, yet the systems dimension along which they actually differ - query planning, indexing, and data-readiness cost - is rarely isolated from vendor framing. We construct a synthetic, biomedical-shaped property graph (1.02 million nodes, 5.34 million total node and edge rows) and a twenty-query workload spanning neighborhood lookups, bounded paths, set intersections, anti-joins, grouped aggregation, top-k ranking, temporal filters, full scans, and relational joins. We benchmark Corvic AI - a purpose-built columnar query engine underlying Corvic's ontology management layer ("memories")- against seven purpose-built or graph-extension database systems (LoraDB, Ladybug, DuckPGQ, Memgraph, Neo4j, HugeGraph, and FalkorDB) at three graph scales spanning three orders of magnitude. We report query latency geomeans, bulk-ingest throughput, point-update latency, and answer correctness for each system, and we derive a simple total-cost-of-ownership model that expresses the ingest/query trade-off as a function of query volume. Our central finding is that no system in this sample is categorically fastest: a native graph engine (Ladybug) outperforms Corvic AI on narrow, bounded-neighborhood shapes, while Corvic AI is faster on shapes that scan or join a large fraction of the graph, and a system implementing graph query syntax via SQL/PGQ (DuckPGQ) is measurably slower purely due to query-plan choice. The dominant cost differential in our data is not query latency but the cost of making data queryable at all: bulk-ingest throughput varies by three orders of magnitude across engines (5.0k-4.3M rows/s), a gap that a simple crossover-point calculation shows dominates total cost for any workload with fewer than roughly 105 queries per data refresh.
arXiv ID: 2609.23315 ／ 要約の誤りについて