# Encoded but not recalled: the brand-fact failure no visibility tool reports

> Frontier models encoded 95 to 98% of tested facts and failed to recall 26 to 34% of them. Missing and unreachable look identical from the outside.

Canonical: https://brandonlazovic.dev/articles/encoded-but-not-recalled/  
Author: Brandon Lazovic  
Published: 2026-08-28

## The short version

- On a 2,150-fact benchmark, Gemini-3-Pro and GPT-5 encoded 95 to 98% of facts and still failed to directly recall 26 to 34% of them.
- A fact that was never learned and a fact that cannot be retrieved need opposite fixes, and standard accuracy scores collapse them into one number.
- Two companies put the bottleneck in getting to a fact instead of in having it, two weeks apart, with Google inside the model and Microsoft outside it.
- Absence from an AI answer has four possible causes with four different responses, and visibility reporting shows them as one row.

When a model gets a fact about your company wrong, there are two very different reasons and one number that hides both. Either the fact was never learned, or it was learned and could not be retrieved. Google Research put that question to frontier models on a 2,150-fact benchmark and found the second answer dominates: 95 to 98% of the facts were encoded, and 26 to 34% of them still failed a direct question. [1] The fact was in there. The model could not get to it. Two weeks earlier, Microsoft published an engineering argument reaching the same neighborhood from outside the model, that once retrieval sits inside the inference loop, missing context turns into a reasoning error rather than a slightly worse answer. [2] The consequence for anyone producing content is specific and awkward. Effort spent making a page more persuasive is spent on the wrong layer if the binding constraint is whether the fact about you gets retrieved at all.

> Frontier models encoded nearly every fact tested and still could not recall between a quarter and a third of them on direct questioning.

## Why does a model get a fact about your brand wrong?

Two causes, and they look identical from outside. An encoding failure means the fact never made it into the model's parameters. A recall failure means the fact is in there and the model cannot reach it on this question. Google's framing is empty shelves against lost keys, and the distinction matters because standard accuracy metrics collapse the two even though they imply very different limitations and very different interventions. [1]

## What did the 2,150-fact benchmark measure?

WikiProfile measures the state of each fact rather than the correctness of each answer. The benchmark holds 2,150 Wikipedia-derived facts, each paired with ten questions that probe encoding, recall and recognition separately. [1] Instead of asking whether a model answered one question correctly, the framework asks what condition the underlying fact is in, which is the shift that makes the finding possible.

The headline result is lopsided. For Gemini-3-Pro and GPT-5, 95 to 98% of facts are encoded, and those same models fail to directly recall 26 to 34% of them. [1] Google's own summary is that factual encoding is close to saturation while recall is not. [1]

![Two large figures from a 2,150-fact benchmark testing Gemini-3-Pro and GPT-5. The first, 95 to 98%, is the share of tested facts encoded into the model. The second, highlighted here, 26 to 34%, is the share of those same encoded facts the model still failed to recall on a direct question. A callout below states that the fact was in the model but could not be reached on 26 to 34% of direct questions.](/figures/encoded-but-not-recalled/encoding-vs-recall.png)

*Google Research, "Empty shelves or lost keys? Recall is the bottleneck for parametric factuality," WikiProfile benchmark.*

Two limits sit alongside those numbers. WikiProfile was constructed by a fully automated pipeline powered by a prompted Gemini 2.5-Pro, with a final manual validation step, so Google measured Gemini on a benchmark Gemini helped build. [1] The manual validation reduces that circularity without removing it. And Wikipedia-derived facts are the easiest possible case, since they are well documented, heavily duplicated and cross-referenced. Recall on a mid-market brand's product detail is very likely worse than these figures, and that is suspected, not measured, because nobody has measured it.

## Encoded, recalled, or inferred: which states are worth telling apart?

Five, and the vocabulary is the useful part. Google classifies each fact into encoding failure, recall failure, direct recall, recall with thinking, and inference without encoding. [1] The first two are the failures. Direct recall is the model producing the fact without deliberation. Recall with thinking is the model reaching it only when reasoning is enabled.

The fifth state is the strangest and worth understanding. Inference without encoding is the model arriving at a fact it never stored, by multi-hop reasoning from other facts it does hold, and Google notes it occurs only when thinking is enabled. [1] For a brand, that is the case where a model gets your category or your pricing tier approximately right by reasoning from your competitors, which is not the same as knowing anything about you and can be wrong in ways that look confident.

## Why is the fix different for each one?

Because the two failures point in opposite directions. Google states that encoding failures call for scaling model size or expanding data coverage, while recall failures point at post-training and inference-time methods that help a model use what it already encodes. [1]

Translate that into publisher terms and the split gets uncomfortable. If the fact about you is genuinely missing, the lever is coverage: get cited more widely, in more places, by sources that get absorbed. If the fact is present and unreachable, more pages will not help at all, and what helps instead is structure, clearer entity association, and the prompt or grounding context the answer is assembled from. Most content programs are built to do the first thing regardless of which problem they have, because the first thing is the one you can put on a roadmap.

There is a third option the paper points at that publishers rarely consider, and it is the cheapest of the three. Google notes that recall failures respond to post-training and inference-time methods, meaning the fact becomes reachable when the surrounding context makes it reachable. [1] The publisher-side equivalent is making the association between your brand and the fact unambiguous wherever it already appears. A product page that names the category, the competitor set and the specification in the same block gives a retrieval step something to land on. The same fact scattered across three pages, each assuming the reader arrived from the other two, gives it nothing.

That reframes what a content brief should ask for. "Cover this topic" is a coverage instruction and it addresses encoding. "Make this fact reachable from the questions people actually ask" is a recall instruction, and on these numbers it is the more likely bottleneck.

## What changes when retrieval moves inside the inference loop?

The trade-offs stop being independent. Microsoft's argument is that in a grounding system, latency, quality and token efficiency collapse into three tightly coupled constraints, so retrieval directly shapes generation, tokens determine both cost and latency, and missing or stale context propagates into reasoning errors rather than degrading gracefully. [2] The optimization target is no longer a ranking function in isolation.

That last phrase is the most consequential, because ranking in isolation is exactly what two decades of SEO practice optimizes. When a human read a results page, a mediocre result cost the reader a click. Inside an inference loop, a mediocre retrieval becomes a confident wrong sentence with your name attached, and nothing downstream flags it. Microsoft reports sub-165ms P95 latency on its production grounding path, which is useful only for making "inside the loop" concrete. [2] It is a vendor-reported figure on their own system, not a benchmark.

One caveat about this pairing: both sources are vendor research, so two companies' framing agreeing is weaker evidence than two independent measurements agreeing. Google published a benchmark with numbers; Microsoft published an architecture argument. I would take no load-bearing claim from the Microsoft prose, and I would treat the convergence as one of diagnosis instead of finding. They are also not the same claim: Google puts the bottleneck inside the model, in reaching a fact the weights hold, and Microsoft puts it outside, in the system that fetches external context. Two weeks apart, two different layers, pointing the same way.

## What can your visibility tool not see?

The reason you are missing. Visibility tools measure whether your brand appears in an answer, and absence is compatible with at least four states: the fact was never encoded, it was encoded and not recalled, it was retrieved and rejected, or nothing was retrieved at all. Those four need four different responses, and current reporting shows them as one row that says you were not mentioned.

**The collapsed absence** is the name worth giving it: a visibility report where four distinct causes with four distinct remedies have been reduced to a single row. It is the metric most AI-visibility spending is currently steered by.

This connects directly to the [44% finding from earlier this week](/articles/half-of-chatgpt-answers-never-search/). If ChatGPT skipped the live web on more than half of a set of commercial comparison queries, then for that half the answer came from the parametric memory Google just measured, and a 26 to 34% recall failure rate was operating on your brand facts with no page fetch anywhere in the path. The two findings compound, and neither tool category reports the interaction.

## How do you tell a recall problem from a coverage problem?

Ask the same fact three ways and watch which framings surface it. Ask it directly. Ask it inside a harder question where the fact is a step rather than the answer. Then ask it again with a nudge toward the right context, naming the category or the document the fact lives in.

Read the pattern rather than any single answer. A fact that appears under the nudge and vanishes without it is a recall problem, and publishing another page will not fix it. A fact that never appears under any framing is a coverage problem, and citations elsewhere are the lever that moves it. A fact that appears confidently and wrong is the inference-without-encoding case, where the model is reasoning from your competitors, and the fix is making the correct version easy to find rather than arguing with the wrong one.

Write down the prompts and the date, because these systems change underneath you and an undated check cannot be repeated. This site's earlier piece on [what RAG actually does](/articles/what-rag-actually-does/) covered how retrieval works. This one is about where its limit now binds, and the limit turns out to sit one layer deeper than most of us have been optimizing.

## Sources

1. Google Research: Empty shelves or lost keys? Recall is the bottleneck for parametric factuality — https://research.google/blog/empty-shelves-or-lost-keys-recall-is-the-bottleneck-for-parametric-factuality/
2. Microsoft: Grounding system, agentic web engineering and retrieval — https://commandline.microsoft.com/grounding-system-agentic-web-engineering-retrieval/