Why Large Language Models Fail to Learn Reversible Facts
Auto-regressive models cannot automatically infer that B is A after learning A is B, forcing a rethink of fine-tuning.
When we teach a human that "Valentina Tereshkova was the first woman to travel to space," they instantly gain the ability to answer "Who was the first woman to travel to space?" This bidirectional deduction feels so natural that we assume our software systems do the same. However, research published on arXiv reveals a striking blind spot in auto-regressive large language models: the Reversal Curse. If a model is trained on the statement "A is B," it fails to automatically infer that "B is A."
This asymmetry is not a minor bug or a temporary quirk of smaller models. It is a fundamental property of how next-token prediction works. For developers building production applications, this research is an eye-opener. It shows that fine-tuning is not a reliable way to inject symmetric knowledge into a model. If you want your model to know a relationship in both directions, you have to build that symmetry into your data pipelines or your system architecture.
The Mechanics of the Curse
Why does this happen? Auto-regressive language models are trained to predict the next token from left to right. When a model learns "Olaf Scholz was the ninth Chancellor of Germany," the training process updates the model's weights to increase the probability of the sequence "ninth Chancellor of Germany" given the prefix "Olaf Scholz."
However, this gradient update does not automatically increase the probability of "Olaf Scholz" when the model is prompted with "Who was the ninth Chancellor of Germany?" To answer the reverse question, the model must predict "Olaf Scholz" as the very first tokens of its response. Because the model has never seen the sequence in that order during training, the probability of generating the correct name is no higher than that of a random name.
The researchers demonstrated this by fine-tuning models like Llama and GPT-3 on fictitious facts, such as "Uriah Hawthorne is the composer of Abyssal Melodies." When asked "Who composed Abyssal Melodies?", the models failed to answer correctly. The phenomenon persists across different model sizes and families, and standard data augmentation does not solve it.
The Real-World Impact
This is not just a problem for synthetic datasets. The researchers tested OpenAI GPT-4 on real-world celebrity relationships. When asked "Who is Tom Cruise's mother?", GPT-4 answered correctly 79% of the time. But when asked "Who is Mary Lee Pfeiffer's son?", the accuracy plummeted to 33%. On a larger dataset of celebrity parents, the reversal accuracy dropped to 28%.
xychart-beta
title "GPT-4 Accuracy on Forward vs. Reverse Queries"
x-axis ["Forward (Tom Cruise's Mother)", "Reverse (Mary Lee's Son)", "Large Dataset Reversals"]
y-axis "Accuracy (%)" 0 --> 100
bar [79, 33, 28]
This gap proves that even the most capable models on the market suffer from this structural limitation. The knowledge is technically inside the weights, but the model cannot access it when the query order is reversed.
The Developer Angle: How to Architect Around the Curse
If you are building applications that rely on precise factual recall, you cannot expect the model to perform logical deduction on its weights. You must design your systems to handle this asymmetry.
Strategy 1: Programmatic Bidirectional Augmentation
If you must fine-tune a model on custom domain knowledge, you cannot simply feed it raw documents and hope it connects the dots. You must pre-process your training data to explicitly include both forward and reverse formulations of every key fact.
Here is a simple Python pattern to generate bidirectional training pairs from a structured data source:
def generate_bidirectional_pairs(subject, relation, object_entity):
# Forward relation: Subject -> Object
forward_prompt = f"Who is {subject}?"
forward_completion = f"{subject} is the {relation} of {object_entity}."
# Reverse relation: Object -> Subject
reverse_prompt = f"Who is the {relation} of {object_entity}?"
reverse_completion = f"The {relation} of {object_entity} is {subject}."
return [
{"prompt": forward_prompt, "completion": forward_completion},
{"prompt": reverse_prompt, "completion": reverse_completion}
]
# Example usage
pairs = generate_bidirectional_pairs(
subject="Uriah Hawthorne",
relation="composer",
object_entity="Abyssal Melodies"
)
for pair in pairs:
print(pair)
By explicitly training the model on both sequences, you bypass the Reversal Curse. However, this doubles the size of your training dataset and increases training costs.
Strategy 2: Shift from Fine-Tuning to RAG
The research notes a critical exception to the Reversal Curse: if "A is B" is present in-context, the model can deduce "B is A" perfectly. This makes Retrieval-Augmented Generation (RAG) the most reliable architecture for factual symmetry.
Instead of trying to bake facts into the model's weights via fine-tuning, store your facts in a structured database, such as a graph database. When a user asks a question, query your database to retrieve the relevant relationship, and inject it into the prompt.
For example, if the user asks: "Who is Mary Lee Pfeiffer's son?"
Your RAG system queries the database, finds the relationship (Mary Lee Pfeiffer) -[mother of]-> (Tom Cruise), and constructs the prompt:
Context: Mary Lee Pfeiffer is the mother of Tom Cruise.
Question: Who is Mary Lee Pfeiffer's son?
Answer:
Because the fact is in the context window, the model easily bypasses the Reversal Curse and returns the correct answer.
Strategy 3: Structured Knowledge Graphs
For complex enterprise data, relying on unstructured text is risky. A better approach is to use the LLM as an extraction engine to build a structured knowledge graph, and then query that graph directly.
You can use the LLM to parse documents and extract triples:
("Olaf Scholz", "is_chancellor_of", "Germany")
Once stored in a graph database, you can query the relationship from either direction with 100% accuracy, completely removing the dependency on the LLM's internal memory.
The Path Forward
The Reversal Curse reminds us that LLMs are not databases; they are next-token prediction engines. They do not store abstract concepts that can be viewed from any angle. They store statistical paths between words.
Understanding this limitation allows us to build better systems. Instead of wasting resources on massive fine-tuning runs hoping the model will learn the underlying logic, we can focus on building robust RAG pipelines and structured knowledge bases. By keeping the facts in the context and letting the LLM handle the language, we can build applications that are both accurate and reliable.
Sources & further reading
- The Reversal Curse: LLMs trained on "A is B" fail to learn "B is A" — arxiv.org
- THE REVERSAL CURSE: LLMS TRAINED ON “A IS B” ... — openreview.net
- Paper: LLMs trained on “A is B” fail to learn “B is A” — lesswrong.com
- LLMS TRAINED ON “A IS B” FAIL TO LEARN “B IS A” — proceedings.iclr.cc
- ICLR Poster The Reversal Curse: LLMs trained on “A is B” fail to learn “B is A” — iclr.cc
Mariana covers the fast-moving world of machine learning and generative AI, with a particular focus on how these technologies are reshaping development workflows. When she isn't stress-testing the latest foundation models, she's usually at a local hackathon.
Discussion 2
so how does this impact data pipeline design, especially when it comes to handling backfills and bidirectional data flows? does this mean we need to explicitly model reversals in our schemas?
need to read this again and think about implications
