Knowledge conflict and parametric override

Parametric knowledge is what a model recalls from its weights; contextual knowledge is what you put in the prompt this turn. Chapter 2 established that parametric recall carries no timestamps and no signal of absence, and ended on the obvious remedy: supply the current document and let the model read it. This chapter is about the case where you do that, the retrieval stage does its job perfectly, and the answer still carries the old value.

That failure has a name in the research literature — a knowledge conflict — and the useful framing is that resolving one is a behaviour rather than a guarantee. It is worth separating from its neighbours early, because several distinct faults produce the same user-visible symptom, and the one described here is the only one with no entry in any dashboard. Teams reach for the subsystem they can see, and a well-instrumented retriever is more visible than an uninstrumented generation step regardless of where the fault actually is.

Two sources of knowledge, one output#

Consider a pricing assistant whose Team plan price moved from $20 to $24. The $20 is heavily represented in the weights: it appeared on the marketing site, in comparison blog posts, in review articles and in pricing-page snapshots crawled repeatedly over three years. The $24 is in a 380-token chunk retrieved this turn. When those disagree, the model does not have a rule that says the context wins. It produces a continuation, and which source that continuation reflects is an empirical property of the model, the prompt and the specific fact.

It is worth being clear about why no such rule exists, because "the context should obviously take priority" is the intuition the whole failure runs against. Nothing in pretraining establishes a precedence order between the two sources, since pretraining is next-token prediction over documents, and a document containing a claim the model has seen contradicted elsewhere is just another document. Post-training pushes toward using supplied material — instruction data is full of examples where the correct behaviour is to answer from the passage — and that pressure is statistical rather than architectural. It raises the probability that the context wins. It does not install a switch.

Both halves of that are worth unpacking, because a reader who cannot rebuild them will spend a long time hunting for the setting that turns precedence on. Pretraining scores the model on one thing, which is how well it predicts the next piece of text in a document. That objective has no notion of where a document came from, when it was written, or whether anything else in the training data contradicts it. A page stating the old price and a page stating the new one are both text to be continued, and neither is marked as the authoritative one — there is no field in which to mark it, and nothing in the training signal would consult such a field if there were. Whatever precedence the finished model exhibits cannot have been established at this stage, because this stage cannot represent the concept.

The second half is the post-training pressure, and the useful question about it is what a pressure can and cannot do. Training on those exchanges makes answering-from-the-passage more likely in later contexts that resemble them, which is a change to a distribution. What that changes is the odds at every token, which is what "statistical rather than architectural" amounts to in practice: no branch checks whether a document was supplied, no state exists that the model enters when one is, and no threshold switches memory off. The pressure is real and it is strong enough that the context wins most of the time. A large probability is still a probability, and there is no configuration in which the supplied value is certain to be emitted, which is why the search for one comes back empty.

The intuition itself deserves granting before it is taken apart, because it is nearly right and it comes from sound habits. Every other component in the stack behaves that way: a function handed an argument uses the argument, and a template handed a value renders that value. The post-training pressure above makes models behave that way on most requests too, so the intuition is confirmed by nearly every example anyone tries by hand. What it misses is that the exceptions are not spread evenly across your facts. They concentrate on the facts the model has read the most about, which for a company assistant are the public, flagship, heavily discussed ones — the facts a wrong answer is most visible on.

Navigating Unreliable Parametric and Contextual Knowledge: Explicit Knowledge Conflict Resolution sets out the parametric-versus-contextual split and the ways models arbitrate between them. When LLMs Lag Behind: Knowledge Conflicts from Evolving APIs in Code Generation studies the exact form backend engineers meet most often — a model that has read years of documentation for version 2 of a library, handed version 3 documentation in context, generating version 2 calls anyway.

Diagram

The diagram is the argument in one picture. Every metric a retrieval team instruments lives on the left edge of the generation box. The failure lives inside it.

Spelling that out as an argument is what turns it from an illustration into a prediction about your dashboards. Every metric a retrieval team computes — recall at k, mean reciprocal rank, precision at the cutoff, the hit rate on a labelled set — is a function of the ranked list of chunks and of nothing else. When the list is correct, every function of that list reports correct, and no retrieval metric can be constructed that behaves otherwise, because the list is the whole of what such a metric has to read. The conflict is resolved afterwards, in the step that turns the list and the question into a sentence, and every input to that step was fine. A dashboard covering the left edge of the generation box therefore stays green through every instance of this failure, and staying green is the correct behaviour for it rather than a bug in the instrumentation.

That has a consequence for how the failure gets diagnosed, and the consequence is organisational rather than technical. A hypothesis naming the retriever arrives with an owner, a dashboard, a backlog and a remedy everybody already understands. A hypothesis naming conflict resolution inside the generation step arrives with a prompt template nobody has edited in months and no number attached to it. Instrumentation is what makes a stage visible, so the instrumented stage is the one that accumulates hypotheses, and the investigation heads toward the stage that is already returning the correct answer. The scenario later in this chapter is that pattern running to within a sprint of being funded.

Why memory wins some of the time and not others#

Running 240 conflict pairs through a deliberate evaluation — each one a document chunk stating a current value alongside a question whose older answer the model demonstrably knows from memory — produced a context-wins rate of 91 percent overall. Split by how heavily the old fact was represented in training, it separated cleanly:

The last row is the control that makes the rest legible. Where the model has no competing memory, the context is used flawlessly — this is not a system that struggles to read documents. Where it has a strongly reinforced memory, the supplied fact loses close to half the time. The failure rate observed in production is then a weighted average over whatever mix of questions users ask, which is why it lands at some unremarkable-looking single-digit percentage instead of at zero or at fifty.

The ordering of those rows is not an accident of which facts were picked, and the account from the previous chapter predicts it. Recall from the weights is an accumulated tilt: a claim that appeared in ten thousand documents nudged the weights ten thousand times in a consistent direction, and a claim that appeared in one nudged them once, faintly. The competing prior in a knowledge conflict is that tilt, so its strength scales with how much text stated the old value. A flagship price that sat on comparison sites, review articles and pricing-page snapshots for years is the deepest tilt in the table, and it is the row where the supplied value loses most often. An education discount rate that appeared on one page and was rarely syndicated is a shallow tilt, and the context wins nearly every time. The rows are ordered by textual presence because textual presence is what the competition is made of.

That control row is the same account with the tilt set to nothing. A rate that was never publicly documented was never in any crawl, so no training step ever pushed the weights toward a value for it, and the supplied number arrives unopposed. Its result is the one the account predicts before the evaluation is run, which is what makes it usable as a control rather than as one more data point. The 100 percent belongs to this evaluation's construction — one fact class, one prompt shape, one revision — and it reads as evidence that nothing in the delivery path is broken, rather than as a guarantee that arbitrary documents are used unopposed.

Two other factors move the number, and both are worth knowing before you start changing things. The larger the gap between the recalled and supplied values, the more often the context wins, because a wildly discrepant supplied value is distributionally strange and gets more attention; small plausible edits, like $20 to $24, are the hardest case. And explicit instruction helps without settling it: adding "Answer only from the provided documents. If they disagree with what you recall, the documents are correct" moved the Team plan row from 58 percent to 79 percent in the same evaluation. Meaningful, and not a fix.

That first effect is worth stating with its conditions, because it is the claim here most likely to be carried somewhere it does not hold. What the evaluation establishes is a direction — larger gaps favour the context — measured on one fact class, in one prompt shape, on one revision. The magnitude does not transfer, and neither does the distance at which the effect becomes dependable. The reason does transfer: a value far outside the expected range is unusual, and unusual material is easy to single out, while two values a few units apart compete on nearly equal terms because neither of them stands out at all.

The production consequence follows directly and it is uncomfortable. Real edits are small ones: a trial length moves from 14 to 30 days, a price moves by a few units, a threshold is nudged one step, and each of those lands close to what the model already remembers, which is exactly where memory competes hardest. A test suite built from dramatic substitutions will therefore pass while the system fails on every change a policy team actually makes. The sentinel experiment two chapters on is built around this fact, and the reason it runs a ladder of values rather than a single one is that one dramatic edit answers a question nobody has.

The rate is also a property of the model revision, which makes it a thing to measure when qualifying an upgrade rather than a constant you can look up. The same 240 pairs run against a smaller, cheaper revision in the same family produced an overall context-wins rate of 84 percent against the primary revision's 91 percent, with the gap concentrated entirely in the high-frequency rows — the cheap model was fine on the education discount and noticeably worse on the flagship price. That is a sensible thing to have on a comparison sheet next to latency and cost per thousand requests, and almost nobody has it, because the standard evaluation suites measure whether a model can use a passage rather than whether it will use a passage that contradicts it. Rethinking LLM Parametric Knowledge as Post-retrieval Confidence takes the same measurement in the other direction, using what the model already believes as a signal for when retrieval is needed at all.

Building that evaluation is more work than running it, and the work is in construction rather than code. Each pair needs a fact where you can establish what the model recalls unaided — chapter 4's no-context arm gives you that — plus a document stating the current value, plus a question whose correct answer is unambiguous. Fifty pairs spread across your fact classes is enough to see the shape. What comes out is not a single quality score but a map of which of your facts the model will argue with, and that map is what tells you where the remaining effort should go.

The tells that separate this from its neighbours#

Several distinct failures produce the same user-visible symptom — a wrong number in an answer that otherwise reads as though it came from the document. Each has a different tell.

The stale-index row is the one worth checking before anything else, because it is cheap and it is embarrassing to miss. Grep the assembled prompt — the literal string sent to the model — for the correct value. If $24 is not in it, the fault is upstream and none of this chapter applies.

The parametric-override row is the only one with no entry in the metric column, and that absence is the reason this failure survives well-instrumented systems. Retrieval evaluation measures whether the right text was found. Answer-quality evaluation, if you have it, measures whether the final answer was right. Neither of them measures the step in between, and the step in between is where the conflict is resolved.

Two further readings are worth heading off. This is not the model ignoring the context: in the eleven failing conversations the assistant used the retrieved chunk correctly for everything except the number — it described the seat-based billing model, the annual discount and the included support tier exactly as the current page states, then quoted $20. Partial use is the norm, and it is precisely what makes the failure hard to spot in review, because the answer looks sourced since most of it is.

And it is not solved by putting the whole document in the context instead of a chunk. Larger context reduces retrieval misses and does nothing about conflict resolution; if anything, a longer prompt gives the correct value more competition for attention.

That proposal keeps coming back, and the belief under it survives the diagnosis intact, so it is worth saying where the belief comes from and where the extra competition comes from. A larger context genuinely does reduce retrieval misses, which is the first row of the table above and a real failure, so the move gets confirmed by whichever neighbouring fault a team happened to have last. The competition it adds is the rivalrous attention budget from the topic on context degradation, arriving in a new place: the weighting a model spreads across the prompt when producing each token sums to one, so every block of text added to a request takes share from the block carrying the contested value. Widening the context is a fix for the failure at the top of that table, applied to the failure near the bottom of it.

There is a real remedy space — instruction wording, requiring the model to quote the source span before stating a value, structured extraction of the number by a separate call, and simply choosing a model with a higher context-wins rate — and Seeing through the Conflict: Transparent Knowledge Conflict Handling in RAG is a good starting point for the version of this that surfaces conflicts explicitly rather than silently picking a side. All of that is downstream of a diagnosis, and none of it is worth starting without one.

Which leaves the diagnosis itself. Believing that memory beat context is not the same as showing it, and eleven failing conversations do not show it: an answer containing $20 is consistent with parametric override and also with a dozen other explanations a sceptical reviewer can raise. The obvious next move is to ask the same question twice, once with the pricing page in context and once without, and compare. That is worth running, and the next chapter is about exactly how far it gets you.