[RFC] Proposal A & B Implementation Analysis

[jlin53882]

Proposal A & B Analysis — Why C is Excluded

Context

Following up on #246. I've done a deep-dive analysis of the memory-lancedb-pro codebase to determine the best approach for implementing Proposal A and B.

Key Findings

Existing systems (already in place)

Mechanism	File	What it does
Frequency reinforcement	access-tracker.ts	High access count → longer half-life (up to 3x), via log1p(effectiveAccessCount)
Weibull decay	decay-engine.ts	importance modulates half-life: effectiveHL = halfLife × exp(1.5 × importance)
Tier promotion	tier-manager.ts	Core (β=0.8, slowest decay) / Working / Peripheral (β=1.3, fastest)
Importance weight in recall	retriever.ts	applyImportanceWeight(): score *= (0.7 + 0.3 × importance)
last_confirmed_use_at field	smart-metadata.ts	Field exists but NOT actively used in decay/boost calculations
bad_recall_count field	smart-metadata.ts	Field exists but NOT actively triggered
Reflection quality weighting	reflection-store.ts	quality × logistic(age) × baseWeight already implements dynamic decay

Critical gap

The system has frequency-based reinforcement but no feedback-based importance adjustment. The importance field is written once at store time and never updated based on usage quality.

---

Proposal A — Dynamic Importance (Recommended)

Goal: Make importance dynamic — not a one-time write, but adjusted after each recall based on usage quality.

Recommended feedback signals

Signal	When to capture	Adjustment
Memory was recalled AND used in response	agent_end — compare recall results vs final response	importance += 0.05, cap at 1.0
User explicitly confirmed correctness	User says "correct"/"yes"/"right"	importance += 0.15, cap at 1.0
User explicitly marked as wrong	User says "no"/"wrong"/"not right"	importance -= 0.10, floor at 0.1
Recalled but never used (2+ consecutive times)	Next recall cycle check	importance -= 0.03
Long unused (>30 days)	Decay naturally handles this	No additional logic needed

Why agent_end hook is the right place

• before_agent_start happens before the response, so it can't determine if memory was actually used
• agent_end has full event.messages — can compare recall results against the final response
• No new lifecycle triggers needed; just add a post-processing step to the existing agent_end flow

No changes needed to

• decay-engine.ts — it already reads importance; changes propagate automatically
• tier-manager.ts — Core promotion requires importance >= 0.8; dynamic importance naturally triggers/deters promotions
• access-tracker.ts — frequency tracking and importance adjustment are complementary, not conflicting

---

Proposal B — Attention-Like Neighbor Enrichment (Recommended)

Goal: When a memory is recalled, proactively find its "neighbor" memories and bring them into context too.

Recommended path: B-1 (Reflection-focused, lower risk)

Reflection already has a neighbor-modeling mechanism in loadAgentReflectionSlicesFromEntries(). Extend it:

loadAgentReflectionSlicesFromEntries() → N results
  → For each result: bm25Search(text, topK=2, scope=same)
  → Merge + deduplicate
  → Output (originals + neighbors)

Pros: Contained within reflection-store.ts, doesn't affect main retrieval latency.
Cons: Only affects reflection memories, not the main memories table.

B-2 (Full retrieval, if B-1 proves valuable)

In retriever.ts, after MMR diversity and before returning results:

• For each recalled memory, do one more vectorSearch(text, topK=2, scope=same)
• Merge neighbors, re-sort by similarity + importance
• Cap: max 2 neighbors per recalled memory, total output cap 20 entries

Note: MMR diversity and neighbor enrichment may conflict — MMR pushes similar items later, neighbor enrichment brings them in. Need to adjust MMR order if implementing B-2.

---

Why Proposal C is Excluded

Concern	Reason
Classification accuracy	No session-level domain classifier exists; building one adds latency and can degrade results if wrong
Wrong classification cost	If the domain is misclassified, the wrong memories get boosted and right ones get diluted
A + B already covers the main need	A makes important memories last longer; B enriches context. C's benefit is unproven for this use case
Maturity	No user feedback indicating "context-aware recall is broken"

---

Proposed Implementation Order

1. Proposal A Phase 1 — Add agent_end feedback loop (lowest risk, highest clarity)
2. Proposal B Path B-1 — Neighbor enrichment in reflection recall
3. Proposal A Phase 2 — Wire up last_confirmed_use_at and bad_recall_count triggers
4. Proposal B Path B-2 — Main retrieval neighbor enrichment (if B-1 proves valuable)

---

Questions for the Author

1. Does the feedback signal design (recall → used in response → importance boost) match your intent in Feature Request: Dynamic Importance Learning & Memory Attention Network #246?
2. For Proposal B — should neighbor enrichment be scoped to the same scope filter, or should it cross scopes?
3. Is there a specific use case driving Proposal C that we should reconsider for?

Related: #246

[AliceLJY]

Impressive analysis — the codebase audit is thorough and the existing-mechanism inventory is exactly right.

Proposal A (Dynamic Importance): Agree this is the highest-value change. The current importance being write-once is the most obvious gap. A few notes:

• The agent_end hook placement is correct — it's the only point where you have both the recall results and the final response to compare
• The adjustment magnitudes (+0.05/+0.15/-0.10/-0.03) look reasonable as starting points; they should be tunable via config since optimal values will depend on usage patterns
• Consider adding a min_recall_count threshold before applying negative adjustments — a memory recalled only once and not used isn't necessarily bad, it might just be the wrong context for that session

Proposal B (Neighbor Enrichment): B-1 (reflection-scoped) is the right starting point. The conflict you flagged between MMR diversity and neighbor enrichment is real — good to see it noted upfront. For B-1, since reflection slices are already a bounded set, the performance impact should be minimal.

Implementation order: Agree with A-Phase1 → B-1 → A-Phase2 → B-2. Each stage can be validated independently.

To your questions:

• Q2: Neighbor enrichment should be scoped to the same scope filter by default — crossing scopes risks pulling in context that was intentionally partitioned
• Q3: Proposal C exclusion rationale is sound. If a concrete use case emerges later, it can be reconsidered

Solid RFC. Welcome to submit PRs following the proposed order.