Divergence Engines (Part 2): A Technical Framework for Useful Difference

25. October 2025
AIRAGGraphRAGContext EngineeringRetrievalMemory SystemsKnowledge GraphsComplexity

Relevance is easy to optimize. Exploration is harder to specify. A retriever that only ranks the closest matches gives us no direct way to ask for a useful difference.

Here is a working design for giving retrieval two objectives: answer the question and expand the inquiry. It combines a mode switch with seven operations for weak ties, bridges, disagreement, time, variance, absence, and write-back.

Work in progress
Disclaimer

These are design patterns and conceptual examples, not measured results or a final specification. I would like to hear what fails as much as what works when someone tries them in a real corpus.

Part 1 described a retrieval feedback loop that can keep an inquiry near its starting frame. The practical question is where to intervene. I am exploring that question through Recurse, a sense-making substrate concerned with context injection, relationship-based retrieval, and portability across providers. The patterns below are proposals; their useful parameter values will depend on the corpus and the task.

Two objectives

Answering and exploring require different selections. A concise answer may need the nearest, best-supported source. An open inquiry may need that source and a credible counterexample or connection that changes the question. One way to express the trade-off for a retrieved set S\mathcal{S} is:

max⁡S⊂D,∣S∣=k    Rel(q,S)+λ Reach(q,S)\max_{\mathcal{S} \subset \mathcal{D}, |\mathcal{S}|=k} \;\;\text{Rel}(q,\mathcal{S}) + \lambda\,\text{Reach}(q,\mathcal{S})

Rel\text{Rel} measures how well the set answers query qq. Reach\text{Reach} is a proposed composite of diversity within the set, distance from the current frame, supported cross-domain links, disagreement, and signals that have not yet been assimilated. λ\lambda sets their relative weight; it is not a universal knob with a known optimum. Both terms need operational definitions and comparable scales before this becomes an objective a system can optimize.

A simple interface could make the intent explicit:

The values here illustrate an API shape, not recommended settings. The modes need not be permanent identities for a session. I might diverge while looking for alternative interpretations, converge when checking a specific claim, then return to exploration after the answer exposes a new gap. The mode tells the retriever which selection problem it is solving now.

A graph gives difference a shape

Vector search can diversify a result set by penalizing redundancy. A graph can also represent why two items differ or belong together: one claim contradicts another; a method extends an earlier one; a concept bridges clusters. These edges are useful only if their types and provenance can be inspected. Automatically labeled relations are candidates for retrieval, not settled facts.

One possible ingestion path is to retrieve context for a new item, propose typed relationships such as supports, contradicts, or extends, and keep the source passages that justify each edge. A language model may help classify the relations. Human review or later evidence must be able to correct them. Otherwise a graph can make a mistaken inference look more authoritative than a similarity score.

Operations for useful difference

Associative drift

The nearest candidates often repeat one another. Granovetter’s account of weak ties offers an analogy: a connection outside the closest circle can bring information the circle does not have. In retrieval, I would first keep a floor of relevance, then select some candidates for what they add to the set.

Maximal Marginal Relevance (MMR) is one way to do this. At each selection, it rewards similarity to the query and penalizes similarity to results already chosen:

Score(d)=α sim(d,q)−(1−α)max⁡s∈Ssim(d,s)\text{Score}(d)=\alpha\,\mathrm{sim}(d,q)-(1-\alpha)\max_{s\in\mathcal{S}}\mathrm{sim}(d,s)

Here α\alpha belongs to MMR and should not be confused with the earlier weight on Reach. A lower value makes redundancy more costly. Whether this reveals useful weak ties rather than noise depends on the candidate pool and the relevance floor. The original MMR method is a greedy selector; the formula does not tell us which value of α\alpha works for a particular corpus.

For a first pass, MMR could sit after ordinary candidate retrieval. It does not require changing the index:

This selection still sees only the initial candidate pool. If the index never retrieved the weakly related item, MMR cannot recover it. A graph traversal or a second query strategy has to widen the pool first.

Cross-domain bridges

MMR can spread results without explaining the connection between them. A graph bridge does more: it provides a path from the query’s neighborhood to another cluster. I would reserve some retrieval capacity for candidates reached by such paths, then require the result to show the bridge and its supporting passages. A node that is merely far away is not a bridge.

A query about attention in transformer models might encounter work on biological attention, but the value lies in the specific relation one can inspect, not in the shock of two disciplines appearing on the same screen. Cross-domain work can be fruitful; the cited studies of polymathy among Nobel laureates and interdisciplinary research are suggestive, not validation of this retrieval strategy. A graph bridge still has to earn its place in a result.

An implementation needs at least a cluster assignment, a retrievable edge between clusters, and enough source context to explain that edge. A useful selection sequence is: find the query’s home cluster; retrieve its best candidates; traverse a limited number of typed bridge edges; check the distant candidates against the original question; then return the bridge path with each selected item. The slot reservation is a cap, not a quota to fill when no bridge survives those checks. Clusters also move as the corpus changes, so their labels and the bridge paths need periodic review.

Contradiction surfacing

For a claim with a discernible stance, retrieval can ask for a source that disputes it and show the grounds of disagreement. This requires claim extraction, stance classification, and provenance. A simple negation match is not enough: “vaccines are safe” and “vaccines have side effects” can both be true. Scope, method, date, and evidence may explain the apparent conflict.

I would display disagreement as a relation between specific claims, with links back to their sources. That makes it possible to distinguish a genuine contradiction from a difference in granularity or a later correction. Contradictions should illuminate contested terrain, not provide automatic “balance” to a well-supported finding.

The extraction step is the fragile one. A stance label without the claim’s conditions can invert its meaning. “X causes Y under condition Z” may be consistent with “X does not cause Y” in another population. I would store the exact claim span, scope, source date, and the model’s proposed relation before ranking any apparent contradiction. The result should let a person inspect both passages rather than trust a synthesized verdict.

Temporal novelty

An item newly added to a corpus may use unfamiliar terms and have few graph connections. A bounded boost can keep it visible long enough to be evaluated. Ingestion date and publication date answer different questions: the former tells us what is new to the system; the latter tells us when the claim entered the world. Both should remain available to the reader.

Recency alone is a poor proxy for insight. I would combine it with a relevance floor and evidence that the item contributes something missing from the current set. The decay window should follow the corpus and the pace of its subject, then be checked against outcomes rather than chosen by intuition.

Entropy control

Repeated retrieval can produce a set of near-duplicates. We can measure how its items are distributed across interpretable groups or clusters and intervene when one group takes over. Shannon entropy is one possible summary of that distribution, but it depends on how groups are defined. There is no meaningful universal entropy threshold for arbitrary embeddings.

For a query about optimization methods, a result set containing seven variations of gradient descent may be precise yet narrow. A system could keep the strongest gradient-based sources and test whether a different family, such as simulated annealing, meets the same relevance floor. The useful test is whether the difference contributes to the inquiry, not whether an entropy number rises.

Negative space

Sometimes the omission matters more than another result. If a corpus has an explicit domain map, we can compare the concepts retrieved with those expected for the query and show uncovered areas. Repeated failed searches can offer another, weaker signal. The interface should say whether the gap is in this corpus, in the retrieval process, or in the field itself; those are very different claims.

For example, if a domain map associates a query with four subtopics and the retrieved passages cover only two, the system can report the other two as uncovered in this result set. It should then search the corpus for them before claiming the corpus lacks coverage. If that search also fails, it can say not found here and identify which sources were searched. This extra step stops a retrieval failure from masquerading as a gap in knowledge.

No ontology can tell us every document that should exist. A missing bridge in a graph is a prompt for investigation, not evidence that the literature has overlooked a connection.

Write-back

If a person or agent follows an unexpected connection and finds it useful, the path is a candidate for memory. A graph could save a proposed edge with its source passages, time, task context, and confidence, then review it outside the query path. Repeated traversal may strengthen the case for keeping an edge, but use is not proof that the relation is true.

The edge should retain its origin even after approval. If a later source contests the relation, the graph needs to show that conflict rather than silently replacing one edge with another. A rollback should remove the edge from retrieval without erasing the record of why it was proposed.

This is where I would be most cautious. Automatic reinforcement favors popular paths; it can create exactly the attractor the system was meant to resist. Batch proposals, allow rollback, retain provenance, and review structural changes before they become retrieval defaults. Write-back should remember how a connection was made, including uncertainty, rather than hardening every productive detour into a fact.

What to measure

An exploratory system should be compared with a relevance-only baseline on the same queries and corpus. Measure diversity across result sets, but inspect whether the additional items clear a relevance floor. Record which bridges are followed, which contradictions change the next question, and whether the person can trace each item to a source. Time to a useful novel result matters more than time to any distant result.

The strongest test is task-based: does diverge mode help someone find a missing premise, revise a claim, or formulate a better next query? Engagement alone is ambiguous. A surprising item can attract a click and still waste the person’s time. Likewise, fewer prompts do not necessarily mean better understanding.

I would use a small set of actual inquiries with source-backed judgments. For each, record the initial question, the retrieved set, why each divergent candidate appeared, and what the person did next. A reviewer can then judge usefulness without knowing which mode produced the set. The comparison should retain failures: irrelevant bridges, false contradictions, stale “novel” items, and missing concepts the system claimed were absent. Those cases tell us which primitive needs repair. Aggregate diversity measures alone cannot distinguish them.

The comparison visual above is illustrative. The figures in this article do not report measured relevance, reach, latency, or user outcomes. Earlier drafts offered target percentages and latency estimates without a benchmark; those numbers would have implied a validation we do not have. Implementation should start with a small corpus, a few traceable queries, and explicit judgments about which differences proved useful.

There is a cost to selecting and explaining more candidates, especially with claim extraction and graph maintenance. Whether richer retrieval saves effort downstream is an empirical question. I would first add one operation, expose why each divergent result appeared, and compare the next step in the inquiry with and without it. That is enough to learn whether the extra path opened anything worth following.