Research & Analysis: Avilian Research Labs, Applied Research Division
Domain: AI Architecture & Systems Research

Four proposed extensions to RAG — what's established, what's ours, what's still unsolved, and which one we're prototyping first.

ABSTRACT: Retrieval-Augmented Generation (RAG) became the default architecture for grounding large language models because models had limited context windows, static weights, and no persistent memory. It remains a reasonable default today, and this paper does not claim otherwise. What it proposes is narrower: four architectures — Tacit Knowledge Elicitation, Multi-Agent Deliberative Synthesis, Causal Predictive Caching, and Sleep-Based Consolidation Learning — that can extend RAG rather than replace it, each addressing something RAG structurally cannot: RAG only retrieves what's already documented, it can't predict before being asked, it can't weigh competing perspectives, and it can't learn from an interaction after the session ends. Each proposal below states plainly what's established technique, what's our own combination, what open questions remain, and — new in this revision — what happens when these architectures fail together, not just individually. We are prototyping the lowest-risk of the four, Tacit Knowledge Elicitation, first, and say why at the end.

01. The Limits of Retrieval

Every modern large language model shares the same basic limitation: it cannot learn from its own conversations. A smallholder farmer in Matabeleland might spend an hour establishing context about her soil type, her crop history, and her financial constraints. The moment the session ends, all of it vanishes. The context window offers an illusion of memory — but it's working memory with a hard size limit, gone between sessions.

RAG addressed this by storing conversation fragments in an external vector database and injecting the relevant ones into the prompt at inference time. This works, and it's why RAG became the default. It also has a genuine, underappreciated strength this paper's earlier draft didn't credit enough: RAG preserves provenance. When a system answers from a retrieved document, you can point to the exact source, the exact date, the exact passage. That matters for liability, trust, regulatory compliance, and debugging — and it's a property several of the architectures below give up, which is why this paper no longer claims to go "beyond" RAG so much as alongside and past parts of it.

02. Tacit Knowledge Elicitation — the architecture we are prototyping first

The idea this builds on: Most critical knowledge in the world isn't written down — it exists as experience in people's heads. RAG, by construction, can only retrieve what's been documented. This inverts the usual interaction: instead of the system only answering, it also asks.

The proposed architecture, sharpened per review: Rather than generic "cognitive conflict" prompting, the system should select its next clarifying question using Expected Value of Information (EVI) — a real, established information-theoretic framework for choosing the question that reduces uncertainty about the user's situation the most, per turn. This matters concretely for CHIKARA's context: every SMS turn costs a user money, battery, and time, so the question asked should be the one that earns that cost, not an arbitrary one. Cognitive conflict framing ("if not X, then not Y — right?") remains useful as a technique for surfacing unstated assumptions, but EVI should govern which question gets asked at all.

Channel priority, per review: Voice-first, dialect-aware ASR/TTS (Shona, Ndebele, Setswana) should be the primary channel where available, since natural multi-turn conversation carries far less friction than text — SMS is the fallback for connectivity-constrained contexts, not the default design target.

CHIKARA APPLICATION: A farmer who doesn't know the technical name for a crop blight could be guided through a short, EVI-ordered, dialect-appropriate diagnostic exchange, building a rich, personalized picture of the problem no static document could capture — with every turn justified by how much uncertainty it actually removes.

What we don't yet know: Whether EVI-ordered elicitation genuinely outperforms simpler clarifying-question designs in practice, on real users, in real dialects, over real (unreliable) connections — that's untested. What we can say is that this is the architecture with the smallest infrastructure footprint of the four, the shortest path to a real prototype, and — critically — no provenance problem at all: every fact elicited this way stays attributable to the exact conversation that produced it, unlike consolidation into weights (Section 05).

Why this is the one we're building first: Against the other three, it needs no weight-editing pipeline, no causal graph, no multi-agent orchestration — just dialogue design and existing ASR/TTS. It can be piloted as a pure quality improvement to something CHIKARA already ships (Health Companion's intake flow, for instance) without touching a live model's weights or a live financial decision. If it fails, the failure is contained and reversible. That combination — lowest technical risk, lowest infrastructure cost, no provenance exposure, and a real existing home to pilot inside — is why it leads.

03. Multi-Agent Deliberative Synthesis

The established research this builds on, stated carefully: Structured multi-agent debate among LLM instances — independent positions, critique, revision — is a real, active research area. It's important to be precise about what the current published evidence shows, because it complicates the optimistic case rather than simply supporting it. HiddenBench (Li, Naito & Shirado, arXiv:2505.11556, a 65-task benchmark built specifically to test whether multi-agent LLM groups can pool information no single agent has alone) found that groups performed substantially worse than single agents given full information — 30.1% accuracy for distributed multi-agent groups versus 80.7% for a single agent with everything at once. We cite this specific paper because we checked it directly against its arXiv listing and its own abstract; we're stating that verification plainly here rather than assuming a citation is trustworthy just because it looks right, which is the mistake this paper made in an earlier draft (see Section 08). The core failure mode HiddenBench identifies is that agents don't reliably ask each other for information they don't have — they converge early on whatever's already shared. The same research found that adding a single agent explicitly prompted to disagree and probe nearly doubled accuracy, which is the one concrete, published mitigation this proposal can lean on.

The proposed architecture, revised: A structured deliberation protocol including at least one dedicated "probe" role, gated by a Conditional Escalation Trigger — a lightweight, cheap classifier or confidence score that routes routine, low-uncertainty queries to a single fast model, and reserves the full multi-agent deliberation pipeline for cases where confidence is low, stakes are high (loan approvals, treatment guidance), or conflicting local data is detected. Without this gate, running full deliberation on every query is token-heavy and compute-expensive in a way that's simply impractical on a regional node.

CHIKARA APPLICATION: A micro-loan question — genuinely high-stakes, genuinely worth the compute — could route to agent roles representing bank policy, community context, development priorities, and climate risk, with the synthesis explicitly preserving where those perspectives agreed and disagreed, rather than collapsing to false consensus.

What we don't yet know: Whether a CHIKARA-specific implementation, even with the probe-role mitigation, actually closes HiddenBench's documented gap. That's an empirical question this paper doesn't answer, because it hasn't been tested.

04. Causal Predictive Caching

The established idea this builds on: Structural causal models (SCMs) are a real, well-studied framework in causal inference. Running counterfactual simulations against a causal graph is standard practice in that field.

The proposed architecture, hardened per review: A continuously updated causal graph of a domain, paired with a speculative-reasoning engine that runs counterfactuals before anyone asks, caching results for instant, causally-grounded response. The earlier version of this proposal treated the cache as static; that's a real safety gap for non-stationary systems like regional agriculture and rural economics. This revision adds an Epistemic Invalidation Layer: an explicit mechanism that detects when an exogenous shock — a flash flood, a sudden regional price spike, an unexpected pest outbreak — has pushed real conditions outside the graph's valid range, and automatically flushes the affected cached predictions rather than continuing to serve them with false confidence. The graph should carry a Confidence Invalidation Threshold: when live data drifts beyond the graph's known boundaries, the system degrades gracefully to explicit uncertainty signaling rather than silently serving a stale answer.

CHIKARA APPLICATION: A question like "how would a delayed rainy season affect seed distribution in the North-East" could be answered from a pre-computed simulation — but if real-time weather anomaly data crosses the invalidation threshold, the cached seed-distribution predictions should be flushed automatically, before a farmer acts on a now-wrong forecast.

What we don't yet know: We do not have a validated causal graph for any specific CHIKARA domain yet. This section describes an architecture pattern with a safety mechanism attached, not a working, tested system.

05. Sleep-Based Consolidation Learning

The established technique this builds on: Mass-Editing Memory in a Transformer (MEMIT) and Low-Rank Adaptation (LoRA) are both real, published, working techniques. What's proposed is a specific combination of them, not a new technique in itself.

The proposed architecture, with the edge-hardware problem now addressed: A wake/sleep/dream cycle — MEMIT for fast wake-phase fact injection, LoRA fine-tuning during offline cycles for durable consolidation, and an RL-based "dreaming" phase generating synthetic rehearsal data. The earlier draft underspecified two things the reviews correctly identified as serious gaps, addressed here:

Quantization reality. Regional CHIKARA nodes will almost certainly run quantized models (4-bit or 8-bit GGUF/AWQ) for RAM and power reasons, and direct weight-editing on quantized weights carries real technical friction — dequantization overhead, precision loss during gradient updates. A more realistic sleep-phase mechanism is model merging via task vectors (TIES-Merging or SVD-based weight arithmetic): a local node computes small parameter deltas offline and merges them into a base adapter, rather than retraining dense weights directly. Any implementation needs an explicit Quantization-Aware Consolidation Pipeline to keep nightly updates numerically stable once re-quantized for the next day's deployment.

The dreaming phase is the least developed part of this proposal, and we're saying so rather than implying otherwise. What RL algorithm, what reward signal, who defines it, how reward hacking or mode collapse gets prevented, how synthetic rehearsal data gets validated before being consolidated into live weights, and what this costs computationally on a regional node — none of this is specified here. It shouldn't be read as more mature than it is.

This is also where the provenance problem is most serious, and it may be disqualifying for some CHIKARA use cases. Once a fact is consolidated into weights, it cannot be cleanly cited, selectively removed, or audited the way a retrieved document can. For a system touching micro-loans, agricultural advice with financial consequences, or health guidance, that's not a minor limitation — it's a real constraint on which categories of knowledge should ever go through this pipeline at all. A consolidation ledger — a parallel record of which facts were consolidated, when, from which interaction, at what confidence — provides an audit trail, not full attribution; a retrieval-augmented verification step, re-checking consolidated knowledge against retrievable sources before high-stakes answers, keeps this hybrid rather than a clean replacement for RAG. This is the honest framing: consolidation extends what a model can do, it doesn't replace the parts of RAG that make a system accountable.

Governance and consent, previously missing entirely. If farmer interactions are consolidated into model weights, real questions follow: does the farmer consent to that. Who owns the resulting knowledge. Can deletion be requested, given that weight-editing makes selective removal difficult or impossible. Does this comply with data protection requirements in Zimbabwe, Botswana, and across SADC. We do not have answers to these questions yet. Stating them here, unresolved, is more honest than omitting them — a system that consolidates personal interaction data into a model without a clear consent and deletion framework is a legal and ethical exposure, not just an engineering one.

CHIKARA APPLICATION: A nightly cycle on a regional node could, in principle, replay anonymized interaction patterns and consolidate them into the model's weights — but "anonymized" itself needs a defined, auditable standard before this moves past prototype.

06. What Model Size Does Any of This Actually Require?

None of the four architectures above specify a minimum viable model capability, and that's a real gap the realistic CHIKARA deployment target — likely a 7B-parameter model running on a regional node, not a frontier model with unlimited compute — makes unavoidable. Metacognitive self-assessment (knowing what you don't know, which Tacit Elicitation depends on), causal graph manipulation, multi-perspective deliberation, and dialect-sensitive elicitation all plausibly degrade at smaller model sizes, and this paper does not yet know where each architecture's quality floor sits, or what a graceful fallback looks like when a regional node's model is too small to run a given architecture well. This is an open question for the prototyping phase, not something resolved here.

07. When These Architectures Fail Together, Not Just Alone

A combined post-RAG stack layering all four is a plausible long-term target, but stacking them doesn't just combine their individual strengths — it can combine their failure modes in ways worse than any one alone. The clearest example: a confidently wrong causal prediction (Section 04's known failure mode) feeding into a multi-agent deliberation layer that has a documented tendency toward premature consensus (Section 03's known failure mode) produces a system that confidently agrees with itself about something wrong — a worse outcome than either failure mode in isolation, because the deliberation layer's apparent thoroughness would make the wrong answer look more, not less, trustworthy. We don't yet have a systematic account of which combinations of these four architectures create this kind of compounding risk and which don't; that analysis is a prerequisite for building the full combined stack, not an afterthought to add once it exists.

08. What Can Be Explained, and to Whom

If a CHIKARA system declines a micro-loan application based on a causal simulation and a deliberation process, the applicant, and potentially a regulator, will reasonably ask why. The four architectures differ sharply in how explainable they are. Causal graphs are interpretable in principle, but only if the graph structure itself is exposed, not just its output. Multi-agent deliberation can produce a genuine explanation — who argued what, where they disagreed — but only if the synthesis layer preserves that record rather than collapsing it into a single answer. Weight-edited consolidation is the least explainable of the four by construction; a fact baked into MLP weights via MEMIT has no clean answer to "why did the system say that." Tacit elicitation is the most naturally explainable, since the system's own clarifying questions are, themselves, a visible record of its reasoning process. This asymmetry should inform which architecture is acceptable for which category of decision — a further reason Section 02's low-stakes, high-transparency prototype is the right starting point, not the high-stakes loan-and-treatment cases Section 03 and 05 gesture toward.

09. Prioritization for Prototyping

Architecture Technical Risk Infrastructure Required Provenance Risk Time to Prototype
Tacit Elicitation Low Low (ASR/TTS, dialogue design) None Short — prototyping first
Multi-Agent Deliberation Low–Medium Low (orchestration, API calls) Low (preservable if designed for it) Short
Causal Predictive Caching Medium High (causal graph construction) Low Medium
Sleep-Based Consolidation High Medium–High (LoRA/MEMIT/merging, local compute) High — may be disqualifying for some use cases Long

Tacit Knowledge Elicitation is where we're starting, for the reasons laid out in Section 02: lowest technical and infrastructure risk, no provenance exposure, and a real existing product surface — Health Companion's intake flow — to pilot inside without touching a live model's weights or a live financial decision.

10. Honest Limitations, Including a Correction We're Not Hiding

An architectural proposal that doesn't state its failure modes plainly is closer to marketing than research. In addition to what's already stated inline above:

11. Conclusion: Investigate · Reason · Build

RAG remains a reasonable default for grounding language models in retrievable, attributable knowledge. This paper's claim is narrower than replacing it: four specific architectures — one of them, Tacit Elicitation, ready to prototype now with the least risk; the other three genuinely promising but carrying open technical, provenance, or governance questions this paper has tried to state honestly rather than paper over.

WE ARE LOOKING FOR COLLABORATORS, specifically: dialect-aware ASR/TTS engineers for the Tacit Elicitation prototype; researchers willing to help specify the dreaming phase in Section 05 properly before it goes further; and anyone with a serious answer to the consent and data-sovereignty questions in Section 05, since we don't have one yet.

Investigate. Reason. Build.

Sources consulted: published research on MEMIT and mass-editing approaches to transformer weight editing; published work on LoRA fine-tuning and TIES-Merging/task-vector model merging; structural causal model literature in causal inference; Li, Naito & Shirado, "HiddenBench: Assessing Collective Reasoning in Multi-Agent LLMs via Hidden Profile Tasks" (arXiv:2505.11556, verified directly against its own listing and abstract — venue stated conservatively as an arXiv preprint rather than asserting a specific conference acceptance we could not independently confirm); Expected Value of Information as used in information theory and active learning literature; published work on cognitive conflict theory in educational psychology — current as of September 2026. This revision incorporates two independent rounds of external technical review.