How to Tune Decay Parameters for Your Data
Why Decay Tuning Matters
The decay parameter d is the single most impactful configuration choice in ACT-R scoring. It determines the half-life of memory activation, which directly controls whether your retrieval results skew toward recent information or include historical context. Setting d too high causes useful historical knowledge to disappear from results. Setting d too low allows outdated information to clutter results alongside current data.
Different applications have fundamentally different information lifecycles. A customer support system for a SaaS product with monthly releases needs recent information because last month's workaround may no longer apply. A legal research assistant needs slow decay because case law from years ago remains authoritative. A coding assistant falls somewhere in between, where framework documentation changes annually but algorithmic concepts persist for decades.
Step-by-Step Tuning Process
Before touching parameters, characterize how quickly information becomes stale in your domain. Ask three questions: How often does the ground truth change? How far back in time should retrieval results reach? What is the cost of retrieving outdated information versus the cost of missing relevant history? A customer support system where returning an outdated answer causes a support escalation has different tolerances than a research assistant where missing historical context means an incomplete analysis.
Map your domain to one of these profiles:
| Profile | Information Half-Life | Suggested d Range | Examples |
|---|---|---|---|
| Fast-moving | Days to weeks | 0.6 to 0.8 | Customer support, news, social media |
| Moderate | Weeks to months | 0.4 to 0.6 | Coding assistants, product docs, project management |
| Slow-moving | Months to years | 0.2 to 0.4 | Legal research, scientific literature, institutional knowledge |
Set d = 0.5 as your baseline. This is the standard ACT-R value, calibrated against human memory experiments across decades of research. It produces a decay curve where a memory accessed once loses about 60% of its activation in the first day, retains about 20% after a week, and retains about 10% after a month. For many applications, this default works well enough that further tuning produces only marginal improvement.
Create 20 to 50 queries that represent real usage patterns, with known expected results for each. Include queries where the best answer is recent (stored in the last few days), queries where the best answer is older (weeks or months), and queries where both recent and historical results are relevant. This spread ensures you can detect both recency bias and historical blindness in your retrieval.
test_queries = [
{
"query": "How do we handle JWT token refresh?",
"expected_top": ["mem_jwt_refresh_v2"], # stored 2 days ago
"expected_present": ["mem_jwt_refresh_v1"], # stored 3 months ago
"notes": "v2 should rank above v1 due to recency"
},
{
"query": "What is our database naming convention?",
"expected_top": ["mem_db_conventions"], # stored 6 months ago
"expected_present": [],
"notes": "stable knowledge, should survive decay"
},
{
"query": "Latest deployment checklist",
"expected_top": ["mem_deploy_v3"], # stored 1 week ago
"expected_present": [],
"notes": "v3 supersedes v2, recency matters"
}
]Test your query set at three decay values: your low candidate (d = 0.3), the default (d = 0.5), and your high candidate (d = 0.7). For each query, record which expected results appear in the top 5 and top 10 positions. Count how many expected results are correctly ranked and how many unexpected results appear above them.
def evaluate_decay(test_queries, memories, decay_values):
results = {}
for d in decay_values:
hits_at_5 = 0
hits_at_10 = 0
total_expected = 0
for tq in test_queries:
ranked = retrieve_with_decay(tq['query'], memories, decay=d)
top_5_ids = [m['id'] for m in ranked[:5]]
top_10_ids = [m['id'] for m in ranked[:10]]
for expected in tq['expected_top']:
total_expected += 1
if expected in top_5_ids:
hits_at_5 += 1
if expected in top_10_ids:
hits_at_10 += 1
results[d] = {
'precision_at_5': hits_at_5 / total_expected,
'precision_at_10': hits_at_10 / total_expected
}
return resultsCompare the precision-at-5 and precision-at-10 values across decay settings. The best decay value is the one that maximizes precision for your expected results. If multiple settings produce similar precision, prefer the one that also includes relevant historical context in positions 6 through 10. If you see a clear winner, use that value. If results are close, stick with 0.5 because it has the strongest theoretical backing.
Deploy your chosen decay value and monitor retrieval quality in production. Track how often users find what they need in the first retrieval versus needing to refine their query. If users consistently miss recent information, decrease d. If they consistently get outdated results, increase d. Plan to re-evaluate quarterly as your data volume and usage patterns change.
Advanced: Per-Category Decay
Some systems benefit from different decay rates for different types of content. Product documentation might use d = 0.3 because it changes infrequently, while customer interaction logs might use d = 0.7 because recent interactions are far more relevant than old ones. If your memory store has clear content categories, consider allowing per-category decay parameters rather than a single global value.
In Adaptive Recall, the decay parameter is configurable per application, and the consolidation process can adjust effective decay rates by reinforcing high-confidence memories. Memories that pass evidence-gated validation receive activation boosts that partially counteract decay, creating a natural mechanism where well-established knowledge persists longer than unverified observations.
Common Mistakes
- Setting d too aggressively high (above 0.8) causes useful context from last week to vanish, forcing users to re-teach the system information it already had.
- Setting d too low (below 0.2) means the system never effectively forgets, which defeats the purpose of having decay at all and leads to noisy, cluttered results.
- Tuning on too few test queries leads to overfitting the parameter to specific cases rather than finding the generally best value.
- Ignoring the interaction between decay and confidence. High-confidence memories should resist decay more than low-confidence ones. If your scoring model does not account for this, tuning d alone cannot solve the problem.
Adaptive Recall handles decay tuning with sensible defaults and per-application configuration. Start building in minutes.
Try It Free