Baseten reports LLM fact writes can retain lift but vanish from answers

• Baseten tested fact writes as a memory primitive: oneill_c's setup compares invented facts in weights against the same facts placed in the prompt.
• Training breadth changed the kind of knowledge written: bare statements left a 27-point recitation-to-use gap, while diverse restatements cut it to 5 points in oneill_c's training-breadth post.
• Sequential writes broke reachability: after 20 writes, bare-statement facts retained 1% accuracy and broad-study facts retained 46%, with 100-write retention plateauing at 25-28%, per oneill_c's retention numbers.
• Forgotten facts still left a weight-space fingerprint: oneill_c's log-probability result says 57-67% of the write's lift remained after the fact failed every question, and oneill_c's context result says prompts recovered forgotten facts to 77-80%.
• Memory is also moving into files: hwchase17's OKF post said OpenWiki now uses Open Knowledge Format, and hwchase17's follow-up framed OKF as a standard for knowledge files.

The arXiv paper is unusually concrete: 247 invented facts, Qwen3-4B with LoRA by default, five question types from recall to counterfactuals, and a footnote pointing to Baseten's code and evaluation data. Google's OKF spec is just Markdown files with YAML frontmatter; LangChain's OpenWiki 0.2 announcement turns that into repo docs a coding agent can traverse through index.md and log.md.

Baseten's paper turns continual learning into a bounded write test. Charles O'Neill of Baseten says in the paper that the primary evaluation used invented facts the model initially failed, then compared every weight write against two anchors: the original model and the original model with the fact in its prompt.

The setup in oneill_c's thread uses five question types:

1. Recall
2. Paraphrase
3. Application
4. Composition
5. Counterfactual

The paper's example fact is deliberately weird, "Zorvathine is a metal that melts when cooled below -10 °C," so a correct answer has to come from the injected fact rather than ordinary world knowledge.

The first result is a data result, not an optimizer result. Bare-statement training let the model recite the fact, but left a 27-point gap against the same fact in context; diverse restatements cut that gap to 5 points in oneill_c's post.

The paper gives the more exact numbers: diverse restatements reduced the recitation-to-use gap from 27.4 points to 5.4 points without showing the model a conclusion.

The retention numbers are the bookmark line. After 20 sequential writes, oneill_c's retention post says bare-statement facts survived at 1% accuracy, while facts trained from diverse restatements survived at 46%.

The same post says 100 writes did not collapse to zero. Retention plateaued at 25-28%, which makes the result stranger than ordinary erasure.

The old fact often remained measurable after it vanished from answers. In oneill_c's log-probability post, forgotten facts kept 57-67% of the write's log-probability lift after failing every question.

The paper calls the result "stored but question-keyed." Under bare-statement writes, oneill_c's routing post says 70% of wrong answers about a forgotten fact contained the newest fact's content.

Composition exposed the same reachability failure before long-run forgetting. oneill_c's composition result says two individually usable written facts produced 32% accuracy on a question needing both, while putting the same two facts in the prompt produced 91%.

Capability preservation looked more tractable than fact reachability. Across 12 conditions, oneill_c's KL result put capability damage at rho = 0.83 with KL divergence from the original model; distilling each write against a frozen original cost about 2 capability points after 20 facts.

The local-control result was harsher. A linearised predictor forecast each update's immediate effect at rho = 0.795, but said little about eventual forgetting at rho = -0.258, according to oneill_c's local-control post.

The sharp version: local measurements looked useful for the next step and weak for the trajectory.

The context result is boring in the way production systems like. Through the same write sequences, oneill_c's context post says in-context use eroded no faster than general capability, and a forgotten fact recovered to 77-80% once its statement returned to the prompt.

oneill_c's summary separates the problem into three requirements:

• Creating usable knowledge: solvable with data breadth.
• Preserving capability: solvable with a frozen teacher or KL penalty.
• Keeping earlier facts reachable: unsolved by the tested interventions.

oneill_c later narrowed the claim: weight integration may be possible, but the tested path is harder than applying vanilla methods on vanilla training data oneill_c's reply. Vtrivedy10 made the infrastructure version of the same split, writing that enterprise and user-specific knowledge may divide between contextual retrieval at the harness layer and model-layer methods that still need a breakthrough Vtrivedy10 on enterprise knowledge.

A separate reply from oneill_c names the trap behind the weight-memory debate: representational capacity is different from non-destructive writeability. The post separates three spaces that often get collapsed:

1. Feature directions in activation space
2. Updates in parameter space
3. Behaviours in function space

The technical complaint is that a new feature being nearly orthogonal to old features does not make the parameter update safe for old behaviours. oneill_c writes the ideal local constraint as finding an update where J_new x Delta theta = r while J_old x Delta theta = 0 for everything preserved.

Superposition, in that framing, is compression with cross-talk, not a private allocator for future facts. The same reply says an old memory can remain physically present while its key or decoder drifts, which matches the paper's stored-but-unreachable result.

Memory also moved at the file-format layer. hwchase17's OKF post said OpenWiki now uses Open Knowledge Format, while LangChain's OpenWiki 0.2 announcement says generated or updated repo wikis now follow OKF.

Google's OKF spec defines a knowledge bundle as:

• A directory tree of Markdown files.
• YAML frontmatter plus a Markdown body for each concept document.
• One required frontmatter field, type.
• Optional title, description, resource, tags, and timestamp fields.
• Optional index.md files for progressive disclosure.
• Optional log.md files for update history.

OpenWiki adds those fields to codebase wikis and says future tooling can search tags, categories, descriptions, and resource URLs instead of relying only on open-ended agentic search. That is the pragmatic side of the Baseten result: if context is the reliable memory channel, the memory files need addresses too.