Event-Centric Memory with Query-Aware Graph Augmentation for Long-Term Conversational Agents

A support or data assistant repeats work across related customer requests.

What you would change

Try the paper's memory change in a replay of past tasks, with separate memory per customer.

Try the paper's memory change in a replay of past tasks, with separate memory per customer.

Compare against

Your current memory pipeline plus a no-memory control using the same agent.

1. Locate the paper's implementation and check its license, model support, data needs, and hardware requirements. Stop here if you cannot obtain the required artifacts.
2. Save a small set of representative product tasks and expected outcomes. Keep evaluation tasks out of any training or tuning, and choose quality and cost limits before running.
3. Run the baseline and the proposed change on identical inputs. Keep other settings fixed and repeat paired runs to expose variation.
4. Save per-task outputs, failures, timings, and all usage costs. Review regressions before expanding the test.

What to measure

Task success, stale memories, retrieval misses, response latency, and all memory maintenance costs.

When to keep it

Keep the change only if it meets your preselected quality and latency limits and improves the metric you care about after setup and operating costs. Otherwise retain the baseline. This is an exploration plan, not a validated recommendation.

recommendation

test

research area

memory and context

technical change

Event-centric memory with query-aware graph working memory

published

2026-10-08

The pipeline is deployable with a single GPU or API-based LLM since it is an inference-time and indexing-time framework rather than a training method, but its multi-component complexity and unquantified benchmark gains require validation on the reader's own conversational workload before production adoption.

1. claim 01Paperraft inference
   Read the brief interpretation

   QGMem replaces both flat RAG-style memory (which leaves event relations and state updates implicit) and monolithic graph-based memory (which is costly to build and accumulates irrelevant relations) with event-indexed atomic memory units consolidated into state-trace memories, plus a per-query local graph encoded as a graph token for the LLM. The cost is a multi-stage pipeline: event extraction and consolidation over dialogue history, hybrid retrieval with query-aware reranking, and per-query graph construction and encoding, which adds indexing storage, build-time compute, and per-query latency compared with plain vector retrieval. It can fail when event segmentation or consolidation mis-attributes state updates, when the hybrid retrieval and reranking pipeline underperforms on a specific domain (making the graph token noisy context), and its claimed gains are benchmark-specific and may not transfer to a production workload with different conversation lengths or query types.

   This is a Paperraft inference. It is not pinned to a verified PDF passage.

   Inspect the source
2. claim 02Paperraft inference

   Consistent gains in retrieval, multi-hop evidence composition, conflict resolution, and ultra-long dialogue reasoning across six benchmarks, with compact contexts and moderate inference cost; no quantified factor is reported in the abstract.

   This is a Paperraft inference. It is not pinned to a verified PDF passage.

   Inspect the source