AuthorsAndreas Ottem
TL;DR
MeVe uses modular memory verification with cross-encoder filtering and fallback retrieval to cut context size by 57.7% on Wikipedia and 75% on HotpotQA versus Standard RAG.
Read our summary here, or open the publisher PDF on the next tab.
THE PROBLEM
Standard top k RAG often injects irrelevant or redundant information, causing context pollution and degrading performance and efficiency in LLMs.
On a Wikipedia subset, Standard RAG uses 188.8 context tokens versus 79.8 for MeVe, wasting budget and increasing hallucination risk.
HOW IT WORKS
MeVe’s core mechanism chains Initial Retrieval, Relevance Verification, Fallback Retrieval, Context Prioritization, and Token Budgeting into a five phase, auditable pipeline.
You can think of MeVe like a CPU with RAM and cache: fast Initial Retrieval fills a buffer, Relevance Verification acts as a gate, and Token Budgeting is the strict cache size.
This modular verification and prioritization lets MeVe curate a compact, high utility context that a plain context window or monolithic RAG pipeline cannot manage or inspect.
DIAGRAM
This diagram shows how MeVe processes a single user query through retrieval, verification, fallback, prioritization, and token budgeting before sending context to the LLM.
DIAGRAM
This diagram shows how MeVe is evaluated across Wikipedia and HotpotQA with different configurations and ablations.
PROCESS
Phase 1: Initial Retrieval
MeVe encodes the user query and runs kNN Initial Retrieval over the vector store to build Cinit with high recall candidates.
Phase 2: Relevance Verification
MeVe applies Relevance Verification using a cross encoder, scoring each candidate and discarding those below threshold τ to form Cver.
Phase 3: Fallback Retrieval
If |Cver| is below Nmin, MeVe triggers Fallback Retrieval with BM25Okapi to add Cfallback and avoid empty or weak contexts.
Phase 4: Context Prioritization
MeVe runs Context Prioritization to sort Call by relevance scores and remove redundant chunks before Token Budgeting packs Cfinal under Tmax.
KEY CONTRIBUTIONS
Five Phase MeVe Architecture
MeVe introduces a five phase pipeline with Initial Retrieval, Relevance Verification, Fallback Retrieval, Context Prioritization, and Token Budgeting, making retrieval auditable and tunable.
Memory Verification with Cross Encoder
MeVe uses Relevance Verification via cross encoder ms marco MiniLM L 6 v2 with τ = 0.5 to aggressively filter irrelevant context before composition.
Context Efficiency on Wikipedia and HotpotQA
MeVe achieves a 57.7% context reduction on the Wikipedia subset and about 75% reduction on HotpotQA compared to Standard RAG while keeping retrieval time near 1.22 seconds.
RESULTS
Context Eff. (Tokens)
79.8 tokens
-109.0 tokens vs Standard RAG
Time (s)
1.22 s
+0.10 s vs Standard RAG
HotpotQA Context Tokens
78.5 tokens
-230.1 tokens vs Standard RAG on HotpotQA
Standard RAG Context
188.8 tokens
baseline context size on Wikipedia subset
On a Wikipedia subset and HotpotQA, which test knowledge heavy QA and multi hop reasoning, MeVe shows large context reductions versus Standard RAG while keeping retrieval latency comparable, demonstrating that modular verification and budgeting can control context size without large time penalties.
BENCHMARK
On a Wikipedia subset and HotpotQA, which test knowledge heavy QA and multi hop reasoning, MeVe shows large context reductions versus Standard RAG while keeping retrieval latency comparable, demonstrating that modular verification and budgeting can control context size without large time penalties.
BENCHMARK
Context Eff. (Tokens) for different retrieval modes on the Wikipedia subset.
KEY INSIGHT
MeVe cuts context size by about 57.7% on the Wikipedia subset, yet the context grounding proxy still often labels answers as derived from irrelevant context.
This is surprising because many assume tighter Relevance Verification and Context Prioritization automatically improve semantic grounding, but MeVe shows efficiency gains do not guarantee factual alignment.
WHY IT MATTERS
MeVe unlocks fine grained, phase level control over retrieval, verification, fallback, and budgeting, enabling explicit tuning of each memory stage.
Builders can now debug and adapt retrieval pipelines like software modules, swapping Fallback Retrieval strategies or Token Budgeting policies without rewriting monolithic RAG systems.
Xingyu Lyu, Jianfeng He et al.
· 2026
ADAM combines Anchor extraction, Distribution estimation, Anchor selection, and Query generation to adaptively probe agent memory via an auxiliary generator and entropy based selection. On the EHRAgent benchmark with Llama2-7b-chat, ADAM reaches EQ=77 and ASR=1.00, compared to MEXTRA’s EQ=44 and ASR=0.89.
Okan Bursa
· 2026
Adaptive RAG Memory (ARM) augments a standard retriever–generator stack with a Dynamic Embedding Layer and Remembrance Engine that track usage statistics and apply selective remembrance and decay to embeddings. On a lightweight retrieval benchmark, ARM achieves NDCG@5 ≈ 0.9401 and Recall@5 = 1.000 with 22M parameters, matching larger baselines like gte-small while providing the best efficiency among ultra-efficient models.
Wei Zhou, Xuanhe Zhou et al.
arXiv 2026 · 2026
Are We Ready For An Agent-Native Memory System? analyzes Memory Representation and Storage, Memory Extraction, Memory Retrieval and Routing, and Memory Maintenance across 12 real systems like Mem0, Zep, MemTree, LightMem, MemOS, MemoryOS, and A-MEM. The study’s main result is that structured systems such as Zep reach 48.0 LLM Judge Accuracy on LongMemEval while Long Context reaches 19.0, and that localized maintenance strategies like LightMem achieve 48.3% normalized utility at only 3.67 s per query.
Answers use this explainer on Memory Papers.
Checking…