Why can contradictory statements look so similar?
Why can embeddings miss the word that changes the meaning?
How closely do contradictions actually score?
What happens when old and new information conflict?
The same problem applies to multimodal RAG
How can standard RAG hide conflicting information? Top-k retrieval can hide one side of the disagreement Chunking can strip away important context Removing duplicates can delete the fix The model can't recover information that retrieval left out
Top-k retrieval can hide one side of the disagreement
Chunking can strip away important context
Removing duplicates can delete the fix
The model can't recover information that retrieval left out
What should a RAG system do with conflicting information?
How can you design RAG to handle conflicting sources? 4 ways to architect RAG for contradictory data Find the conflicts once, when you load the documents Add rules for choosing between conflicting sources Turn important conditions into metadata Expose disagreements instead of hiding them
4 ways to architect RAG for contradictory data
Find the conflicts once, when you load the documents
Add rules for choosing between conflicting sources
Turn important conditions into metadata
Expose disagreements instead of hiding them
How Akamai can help

Key takeaways

Vector search measures similarity; therefore, contradictory statements about the same subject can receive nearly identical scores.

Standard retrieval-augmented generation (RAG) techniques like chunking and top-k retrieval can strip away context or hide conflicting information from an AI agent.

Combining vector search with keyword search, metadata, conflict detection, and reranking can give agents the context they need to handle disagreements.

Imagine that a RAG system asks a vector database to retrieve the most relevant information about whether a product, process, or action is safe. It may return answers that both “X is safe” and “X is not safe” with almost the same similarity score. Better embedding models narrow the gap, but you generally can't tune it away with the embedding alone. It comes from what similarity search is built to do.

The problem is that similarity search is designed to find things that look alike — but opposites can look alike, too. In a RAG system, the wrong answer can rank right next to the right one, with no signal that the sources disagree.

Why can contradictory statements look so similar?

Two sentences can only disagree if they're about the same thing. For instance, “The battery is replaceable” and “Paris is in France” don't disagree. They're just unrelated.

To truly disagree, everything in the sentence has to match except the one key difference between them. Sometimes, that’s only one word.

Vector search measures that matching, which means it can tell that two sentences are about the same subject, such as batteries, but not necessarily whether they agree. “The battery is replaceable” and “The battery is not replaceable” look very similar because almost all the same information is there.

That’s why contradictory statements can end up ranking almost identically in vector search.

Why can embeddings miss the word that changes the meaning?

An embedding turns a sentence into a few hundred numbers, which means some information gets compressed or lost. What remains depends on what the embedding model was trained to recognize.

For many retrieval models, that training emphasizes whether two pieces of text are about the same subject. A question is paired with a passage that answers it, while incorrect answers come from completely unrelated topics. Over time, the model gets rewarded for spotting the “same subject.” However, it gets much less practice spotting “opposite claims,” especially when the difference comes down to a single word, like “not.”

The way embeddings represent a sentence can make that problem worse. For example, “The policy was approved” and “The policy was not approved” share every word but one. When those words are represented together in an embedding, the one word that reverses the meaning can have very little influence on the overall similarity score.

How closely do contradictions actually score?

To see how this plays out in practice, we ran 16 test sentence pairs through an embedding model (Figure 1):

The second column shows the expected relationship between each pair, and the third column shows the similarity score between their vectors. The average scores are:

Paraphrases — 0.86

Paraphrases — 0.86

Contradictions — 0.84

Contradictions — 0.84

Unrelated sentences — 0.37

Unrelated sentences — 0.37

The results show how difficult these contradictions are for vector search to distinguish. Contradictions score about as high as paraphrases, and some even score higher. “Locked after five attempts” against “after ten,” for example, came out at 0.92. “The client sends the token to the server” against its exact reverse came out at 1.00, a perfect match.

Although the model can tell topics apart, it can't tell “yes” from “no.”

What happens when old and new information conflict?

Suppose that you build a RAG-based customer support assistant that answers questions using your company’s documentation: the current manual, a 2019 version that nobody deleted, some old blog posts, and a few forum threads. A customer asks: Can I replace the battery myself?

In the corpus, the assistant finds:

“The battery can be replaced by the user with a standard screwdriver.” — 2024 manual

“The battery can be replaced by the user with a standard screwdriver.” — 2024 manual

“The battery is sealed and cannot be replaced by the user.” — 2019 manual

“The battery is sealed and cannot be replaced by the user.” — 2019 manual

Only one of these is right. But to an embedding model, they’re still highly similar because they’re about the same part and the same action. As a result, both can be returned as answers, and the outdated answer may rank just as highly as the current one. Nothing in the score knows that one of them is five years out of date.

Here’s another example: If a retrieval query is against a corpus like the one below, the outdated answer will rank higher than the current one four times out of six (Figure 2).

That’s only one hundredth of a point between the two results, and the wrong one is on top.

The same problem applies to multimodal RAG

This contradiction problem isn’t limited to text. Consider an image-based RAG system like Miranda. If a user provides a picture of a garment and asks, “Find me something that looks like this, but only something that can be tumble-dried,” the image embedding can easily find visually similar items. However, the retrieval process must still distinguish between “can be tumble-dried” and “cannot be tumble-dried,” bringing us right back to the exact same challenge.

How can standard RAG hide conflicting information?

The usual RAG setup is straightforward: Split documents into chunks, embed them, retrieve the top few matches, and paste them into the prompt. Along the way, other common steps like deduplication and filtering can also affect what the model ultimately sees.

A few other ways that conflicting information can get lost include:

Top-k retrieval can hide one side of the disagreement

Top-k retrieval can hide one side of the disagreement

Chunking can strip away important context

Chunking can strip away important context

Removing duplicates can delete the fix

Removing duplicates can delete the fix

The model can't recover information that retrieval left out

The model can't recover information that retrieval left out

Top-k retrieval can hide one side of the disagreement

When conflicting passages are only one hundredth of a point apart, that very small score difference can determine which one makes the cut. Retrieve the top three results, and the outdated passage may appear while the conflicting current version doesn’t make the list.

Chunking can strip away important context

The publication or effective date may have been in the section heading. The plan name may have been in the page title. The word “deprecated” may have appeared in a banner at the top. So, although the body text remains, the context that tells you whether it still applies is lost.

Removing duplicates can delete the fix

RAG pipelines often remove passages that appear too similar so they don’t send redundant information, but a corrected passage often repeats most of the original language. If a corrected passage closely resembles the outdated one, the system may discard the updated version and keep the older one.

The model can't recover information that retrieval left out

The model can only work with the passages that it receives. If important context, a conflicting source, or a newer version was filtered out earlier in the process, the model has no way to know it existed. If both current and outdated versions appear, the model may choose one over the other. If only one appears, it may provide that answer without realizing there was ever a disagreement.

This is the most serious problem. Vector search can return the wrong answer and hide the fact that other sources disagree.

What should a RAG system do with conflicting information?

An agent can deal with a disagreement if the retrieval system shows that one exists. It can check dates, search again, compare sources, or come back and ask you for clarification. But it can't do any of that if search returns only one version.

To mitigate this, the search layer should surface the conflict instead of silently choosing between the two sources. This takes more than one signal, including:

Vectors that find candidates, and nothing more

Vectors that find candidates, and nothing more

Keyword searches for exact details like numbers, versions, or error codes (an embedding gives “five” and “ten” a 0.92 similarity score, but keyword search can distinguish them)

Keyword searches for exact details like numbers, versions, or error codes (an embedding gives “five” and “ten” a 0.92 similarity score, but keyword search can distinguish them)

Metadata filters for date, version, plan, region, and source

Metadata filters for date, version, plan, region, and source

A conflict list built when documents are loaded, so known disagreements can be flagged before a user ever asks a question

A conflict list built when documents are loaded, so known disagreements can be flagged before a user ever asks a question

A rule for picking between sources that the agent can explain

A rule for picking between sources that the agent can explain

None of these techniques is complicated on its own, but the mistake is expecting the vector search to do all five jobs.

How can you design RAG to handle conflicting sources?

Instead of making vector search do everything, the goal is to build a retrieval process that can recognize conflicts, preserve the context around them, and give the agent enough information to respond appropriately.

4 ways to architect RAG for contradictory data

Building conflict-aware retrieval requires moving beyond simple similarity scoring toward strategies that surface, categorize, and reconcile opposing sources. Here are four ways to do that:

Find the conflicts once, when you load the documents

Find the conflicts once, when you load the documents

Add rules for choosing between conflicting sources

Add rules for choosing between conflicting sources

Turn important conditions into metadata

Turn important conditions into metadata

Expose disagreements instead of hiding them

Expose disagreements instead of hiding them

Find the conflicts once, when you load the documents

Disagreement is a property of the source material, not the user’s question, so there's no need to rediscover it on every query. Instead, embed the documents, keep the pairs that already look similar, and run a cross-encoder over just those pairs. Because a cross-encoder reads both passages together, it can evaluate whether a word like “not” changes the relationship between them. Save the conflicts it flags so they can be checked at query time.

Add rules for choosing between conflicting sources

Finding a conflict tells you there’s a problem, but it doesn’t tell you which source is right. When two documents disagree, use signals like source quality or publication date to decide which one should take priority.

Turn important conditions into metadata

If information only applies to a specific plan, version, region, or other condition, tag it when you load the document. Then the system can filter based on that information instead of relying on a few small words that compete with the rest of the sentence.

Expose disagreements instead of hiding them

If trusted sources really do conflict, don’t hide that from the agent — that's the most useful thing your system knows. Show the disagreement, along with relevant dates and source information, so the agent can respond with the context it needs.

How Akamai can help

These patterns become especially important as RAG and agentic applications move into production. Akamai offers several capabilities that can support these workflows:

Akamai Valkey Managed Database supports low-latency vector retrieval and contextual data access for AI applications

Akamai Valkey Managed Database supports low-latency vector retrieval and contextual data access for AI applications

Akamai Functions runs application logic and AI pre- and post-processing close to users

Akamai Functions runs application logic and AI pre- and post-processing close to users

Akamai Cloud for AI provides distributed compute, data, serverless functions, and GPU-powered inference for AI applications at global scale

Akamai Cloud for AI provides distributed compute, data, serverless functions, and GPU-powered inference for AI applications at global scale

Akamai AI Professional Services helps enterprises accelerate AI adaption through fixed-scope, outcome-focused engagements that deliver clear value

Akamai AI Professional Services helps enterprises accelerate AI adaption through fixed-scope, outcome-focused engagements that deliver clear value

Together, these capabilities give teams more flexibility to build retrieval and inference workflows that preserve context and handle conflicting information more deliberately.

About the Author(s)

Sachidananda Karkala

Sachidananda Karkala is a Singapore-based Enterprise Architect with more than 26 years of experience driving digital transformation. Progressing through roles ranging from Software Engineer to seasoned Solution Architect, he has designed and delivered scalable enterprise ecosystems, complex cloud migrations, and next-generation digital solutions for strategic customers across the APAC region. Sachi is passionate about artificial intelligence and using technology to elevate user experiences. He also enjoys music, reading, and spending quality time with his family outside of work.