Radar Live
✦ Ask AI
AI INTELLIGENCE & SIGNALS

Graph Memory for LLM Agents: At What Cost? A Comparative Evaluation of Query, Ingest, and Update Performance Across Graph Database Engines

Phân tích đã xử lý trước và các nguồn liên quan.

Tín hiệu Radar

65 RADAR
Research LLM Agent Memory & Graph Databases · 1 nguồn đối chiếu · 2026-09-20 03:04:30 +0000 UTC

Graph Memory for LLM Agents: At What Cost? A Comparative Evaluation of Query, Ingest, and Update Performance Across Graph Database Engines

Nguồn: arXiv AI
↗

Nghiên cứu thực nghiệm đánh giá hiệu năng và tổng chi phí sở hữu (TCO) của các engine cơ sở dữ liệu đồ thị khi làm bộ nhớ (Graph Memory) cho LLM Agent. Trên đồ thị y sinh tổng hợp (1,02 triệu node, 5,34 triệu dòng) với 20 dạng truy vấn, nhóm tác giả đo lường Corvic AI cùng 7 engine khác (Ladybug, LoraDB, DuckPGQ, Memgraph, Neo4j, HugeGraph, FalkorDB). Kết quả cho thấy không có engine nào nhanh nhất toàn diện: Ladybug dẫn đầu ở các truy vấn lân cận hẹp có giới hạn, Corvic AI tối ưu ở các truy vấn quét hoặc nối diện rộng, còn DuckPGQ (SQL/PGQ) chậm rõ rệt do lựa chọn kế hoạch truy vấn kém. Đáng chú ý, yếu tố chi phí chi phối hệ thống không phải độ trễ truy vấn mà là thông lượng nạp dữ liệu hàng loạt (chênh lệch từ 5.0k đến 4.3M dòng/giây), quyết định phần lớn TCO cho các khối lượng công việc có dưới khoảng 105 truy vấn giữa mỗi lần làm mới dữ liệu.

✦ TÁC ĐỘNG & GIÁ TRỊ THỰC TIỄN

Nghiên cứu bác bỏ quan niệm cho rằng graph database chuyên dụng luôn là lựa chọn bắt buộc cho connected-data trong LLM Agents. Bằng cách chỉ ra chi phí nạp dữ liệu mới là yếu tố quyết định TCO khi khối lượng truy vấn dưới ngưỡng hòa vốn, nghiên cứu cung cấp cơ sở kỹ thuật thực chứng giúp kỹ sư và doanh nghiệp lựa chọn đúng kiến trúc, tránh lãng phí chi phí hạ tầng.

Developer 80
Business 76
Novelty 78
Actionable 84

Nội dung thu thập đã chuẩn hóa

Collected Evidence

Nội dung văn bản được dùng làm dữ liệu đối chứng cho mô hình AI, không phải chỉ thị hệ thống.

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.

Các nguồn đối chiếu cho sự kiện này

1 nguồn
Thông tin phân tích AI & Model Details ▾
Provider: openai-compatible · Model: gemini-3.8-flash-high · Version: analysis-v1 · Time: 2026-09-22 08:44:37 +0000 UTC
{"tags": ["Graph Memory", "LLM Agents", "Graph Database", "Benchmark", "TCO", "Corvic AI", "Ladybug", "DuckPGQ", "Query Optimization"], "risks": ["Lựa chọn engine theo quảng bá của nhà cung cấp thay vì đặc thù khối lượng công việc có thể làm tăng chi phí nạp dữ liệu lên hàng trăm lần.", "Hiệu năng suy giảm nghiêm trọng khi dùng các tiện ích mở rộng đồ thị trên SQL chưa tối ưu query planner trong môi trường production.", "Đội chi phí vận hành nếu áp dụng graph database cho các hệ thống có tần suất cập nhật dữ liệu cao nhưng lượng truy vấn thấp hơn ngưỡng hòa vốn."], "category": "Research", "entities": ["Corvic AI", "Corvic", "Ladybug", "LoraDB", "DuckPGQ", "Memgraph", "Neo4j", "HugeGraph", "FalkorDB"], "summary_vi": "Nghiên cứu thực nghiệm đánh giá hiệu năng và tổng chi phí sở hữu (TCO) của các engine cơ sở dữ liệu đồ thị khi làm bộ nhớ (Graph Memory) cho LLM Agent. Trên đồ thị y sinh tổng hợp (1,02 triệu node, 5,34 triệu dòng) với 20 dạng truy vấn, nhóm tác giả đo lường Corvic AI cùng 7 engine khác (Ladybug, LoraDB, DuckPGQ, Memgraph, Neo4j, HugeGraph, FalkorDB). Kết quả cho thấy không có engine nào nhanh nhất toàn diện: Ladybug dẫn đầu ở các truy vấn lân cận hẹp có giới hạn, Corvic AI tối ưu ở các truy vấn quét hoặc nối diện rộng, còn DuckPGQ (SQL/PGQ) chậm rõ rệt do lựa chọn kế hoạch truy vấn kém. Đáng chú ý, yếu tố chi phí chi phối hệ thống không phải độ trễ truy vấn mà là thông lượng nạp dữ liệu hàng loạt (chênh lệch từ 5.0k đến 4.3M dòng/giây), quyết định phần lớn TCO cho các khối lượng công việc có dưới khoảng 105 truy vấn giữa mỗi lần làm mới dữ liệu.", "key_changes": ["Không có hệ thống nào nhanh nhất tuyệt đối: engine đồ thị gốc (Ladybug) tối ưu cho truy vấn lân cận hẹp có giới hạn, trong khi engine dạng cột (Corvic AI) vượt trội ở các truy vấn quét hoặc nối diện rộng.", "Thông lượng nạp dữ liệu hàng loạt (bulk-ingest) là yếu tố chênh lệch chi phí chính chứ không phải độ trễ truy vấn, dao động từ 5.0k đến 4.3M dòng/giây (chênh lệch tới 3 bậc độ lớn giữa các engine).", "Mô hình TCO chỉ ra chi phí chuẩn bị nạp dữ liệu áp đảo tổng chi phí đối với mọi khối lượng công việc có dưới khoảng 105 (hoặc 10^5) truy vấn trên mỗi chu kỳ làm mới dữ liệu.", "Triển khai cú pháp đồ thị qua SQL/PGQ (DuckPGQ) bị suy giảm hiệu năng rõ rệt thuần túy do lựa chọn kế hoạch truy vấn (query-plan choice)."], "sub_category": "LLM Agent Memory & Graph Databases", "novelty_score": 78, "business_score": 82, "research_score": 86, "why_it_matters": "Nghiên cứu bác bỏ quan niệm cho rằng graph database chuyên dụng luôn là lựa chọn bắt buộc cho connected-data trong LLM Agents. Bằng cách chỉ ra chi phí nạp dữ liệu mới là yếu tố quyết định TCO khi khối lượng truy vấn dưới ngưỡng hòa vốn, nghiên cứu cung cấp cơ sở kỹ thuật thực chứng giúp kỹ sư và doanh nghiệp lựa chọn đúng kiến trúc, tránh lãng phí chi phí hạ tầng.", "developer_score": 88, "importance_score": 82, "possible_use_cases": ["Lựa chọn kiến trúc lưu trữ tối ưu khi xây dựng bộ nhớ đồ thị (Graph Memory/Knowledge Graph) cho LLM Agents dựa trên đặc thù truy vấn.", "Tính toán điểm hòa vốn TCO để tối ưu chi phí hạ tầng cho các hệ thống RAG/Agent thường xuyên làm mới dữ liệu tri thức.", "Thiết kế và tối ưu bộ lập kế hoạch truy vấn (query planner) cho các hệ thống đồ thị mở rộng trên nền tảng quan hệ (SQL/PGQ)."], "actionability_score": 84}