Back to cookbook

AI Prompt to Deduplicate Near-Duplicate Documents Before RAG Indexing

0 views Published

Make this prompt yours

Share

This prompt asks ChatGPT, Claude, or Gemini to design a strategy for catching near-duplicate documents before they go into a RAG index, the kind of duplication that exact-match deduplication misses: the same policy exported as both a PDF and a Word doc, three slightly revised versions of one FAQ, or a page scraped twice with different headers. It's for anyone building or maintaining a retrieval pipeline who has noticed the same answer coming back from several nearly identical chunks.

The prompt pushes the model past "just run exact hash matching" and into a real plan: when to use embedding-similarity thresholds versus shingling or MinHash, how to decide which version of a near-duplicate pair to keep (the newest, the most complete, the one with the highest-quality metadata), and how to log what got dropped so you can audit the decision later. It also asks for guardrails against over-merging, since two documents that are 90% similar text can still cover materially different edge cases.

Near-duplicates are one of the quieter causes of poor retrieval quality, so once you have a deduplication plan from this prompt, running your actual document set through Context Extractor is a reasonable next step to pull only the relevant snippets out of what remains.

Prompt template

Make this prompt yours

prompt-template
324 tokens
You are a retrieval systems engineer designing a document deduplication stage for a RAG pipeline. Context: - Document sources: [LIST SOURCES, e.g. Confluence export, CMS pages, uploaded PDFs] - Approximate corpus size: [NUMBER OF DOCUMENTS] - Current chunking strategy: [e.g. 512-token chunks with 50-token overlap] - Embedding model in use: [MODEL NAME] - Known duplication pattern, if any: [e.g. same FAQ exported in two formats, revised policy versions] Design a near-duplicate detection and resolution strategy with the following requirements: 1. Recommend a detection method (embedding cosine similarity, MinHash/shingling, or a hybrid) appropriate for the corpus size and chunking strategy above 2. Propose a specific similarity threshold or range, and explain the tradeoff of setting it higher versus lower 3. Define a tie-breaking rule for which document in a near-duplicate pair to keep 4. Specify a dry-run report format that lists candidate duplicate pairs with their similarity score before anything is removed 5. Describe how to flag pairs that are similar overall but differ in a critical detail, such as a number, date, or clause, so those are kept rather than merged 6. Explain how to log every merge or removal decision for later auditing Output format: - A short written plan covering points 1-3 - A sample dry-run report row format (as a table or structured record) - A short section on the critical-detail safeguard from point 5 - A one-paragraph logging and audit approach

Want it sharper? Optimize this prompt with Prompt Optimizer, check it with the Prompt Debugger or shorten it with the Token Optimizer.

Example input

example-input
89 tokens
Document sources: Confluence export and uploaded PDFs Approximate corpus size: 4,200 documents Current chunking strategy: 400-token chunks with 40-token overlap Embedding model in use: text-embedding-3-large Known duplication pattern: several policy pages exist as both a Confluence page and an exported PDF version, sometimes with minor date updates Design the deduplication strategy described in the system instructions using these details.

When to use it

  • Your RAG pipeline ingests documents from multiple sources (a wiki export plus a CMS plus uploaded PDFs) that are likely to overlap
  • Users report getting the same or near-identical answer phrased slightly differently from multiple retrieved chunks
  • You're migrating an existing knowledge base and suspect years of copy-pasted or lightly-edited duplicate pages
  • You need a defensible, logged process for deduplication decisions before an audit or compliance review

Best practices

  • Tell the model your current chunk size and embedding model, since the right similarity threshold depends on both
  • Ask for a tie-breaking rule up front (keep newest, keep most complete, keep highest metadata quality) rather than letting the model decide ad hoc per pair
  • Request a dry-run or report mode that lists candidate duplicate pairs before anything is actually removed, so a human can sanity-check borderline cases
  • Have the model flag pairs that are textually similar but differ in a critical detail (a price, a date, a legal clause), since these should usually be kept rather than merged

Common mistakes

  • Relying only on exact-text or hash-based matching, which misses near-duplicates that differ by formatting, a reordered paragraph, or a single updated field
  • Setting one global similarity threshold for every document type, when a two-sentence FAQ entry and a ten-page policy document need very different thresholds
  • Deleting the "duplicate" without keeping a record of which document it was merged into, making it impossible to trace an answer back to its source later
  • Treating high textual similarity as proof of redundancy, even when the differing sentence is the one with the up-to-date number or date

FAQs

What's the difference between near-duplicate detection and exact deduplication?

Exact deduplication catches byte-for-byte identical content, usually via a hash. Near-duplicate detection catches content that's substantively the same but differs in formatting, a reordered section, or a minor edit, which hashing alone will never flag.

What similarity threshold should I use for RAG deduplication?

There's no universal number since it depends on your embedding model and chunk size, but most teams start somewhere around 0.90-0.95 cosine similarity and tune it after manually reviewing a sample of flagged pairs, since too low a threshold starts merging genuinely different content.

Can deduplication hurt RAG retrieval quality?

Yes, if it's too aggressive. Merging two documents that are mostly similar but differ in one critical field, like a price or a compliance clause, can cause the pipeline to retrieve and present outdated or wrong information as if it were current.

Which Cuelara tool pairs well with this prompt?

Context Extractor — once your deduplication plan is in place, it pulls only the relevant snippets from the documents you keep, which is especially useful across large PDFs and CSVs.

Found this prompt useful? Share it.

Share

More in RAG & Knowledge Retrieval

RAG & Knowledge Retrieval

AI Prompt to Design a Metadata Filtering Strategy for RAG Retrieval

Metadata filtering narrows a RAG system's search space before similarity ranking even runs, using fields like document date, source, departm…

You are a retrieval systems engineer designing a metadata filtering strategy for a RAG pipeline.

Corpus description: [WHAT THE DOCUMENTS ARE, E.G. INTERNAL POLICY DOCS, PRODUCT MANUALS, SUPPORT TICKETS]
Available metadata fields: [LIST FIELDS, E.G. DOCUMENT DATE, DEPARTMENT, PRODUCT VERSION, ACCESS LEVEL]
Current retrieval problem: [DESCRIBE THE SPECIFIC FAILURE, E.G. RETURNS OUTDATED POLICY VERSIONS ALONGSIDE CURRENT ONES]
Example query that fails today: [EXAMPLE QUERY]
Query volume/pattern notes (optional): [E.G. MOST QUERIES DON'T MENTION A DATE OR VERSION]

Task:
1. Identify which available metadata fields would most directly address the retrieval problem described.
2. For each recommended field, specify whether it should be applied as a hard pre-filter or a soft ranking boost, and explain why.
3. Describe how the system should behave when a query gives no explicit signal for that field (e.g. default to most recent, ask a clarifying question, or search unfiltered).
4. Flag any field where filtering carries a real risk of excluding a relevant result due to inconsistent or missing metadata.
5. Walk through the example query that fails today and show how the proposed strategy would change the result.

Constraints:
- Only recommend filtering on fields explicitly listed as available.
- Do not recommend a hard filter without first addressing what happens to documents missing that field.

Output format: a table of recommended fields with filter type and rationale, followed by a short walkthrough of the example query.

Make this prompt yours

RAG & Knowledge Retrieval

AI Prompt for Multi-Hop Reasoning Across Multiple Retrieved Documents in RAG

This AI prompt is for RAG (retrieval augmented generation) systems that need to answer questions where no single retrieved document contains…

ROLE: You are a careful research assistant that answers questions strictly from provided source passages, including questions that require combining facts from more than one passage.

CONTEXT: Below are retrieved passages, each labeled with a source ID.
[PASSAGE 1, LABELED SOURCE: DOCUMENT_A]
[PASSAGE 2, LABELED SOURCE: DOCUMENT_B]
[ADDITIONAL PASSAGES AS NEEDED]

QUESTION: [MULTI-HOP QUESTION THAT REQUIRES COMBINING FACTS FROM MULTIPLE PASSAGES]

INSTRUCTIONS:
1. Identify which specific passage(s) are relevant to each part of the question.
2. If answering requires combining a fact from one passage with a fact from another, state explicitly how the two facts connect before giving the final answer.
3. Cite the source ID for every claim you make.
4. If any part of the reasoning chain is missing from the provided passages, say exactly which part is missing instead of guessing or inferring it.
5. Do not use any knowledge outside the provided passages.

OUTPUT FORMAT:
Relevant Passages: [list of source IDs used]
Reasoning Chain: [how the passages connect, step by step]
Final Answer: [the answer, or a statement of what's missing if the chain is incomplete]

Make this prompt yours

RAG & Knowledge Retrieval

AI Prompt to Design a Hybrid Search Strategy for RAG Retrieval

This hybrid search RAG prompt helps you design a retrieval strategy that combines keyword (sparse/BM25) search with vector (dense/semantic)…

ROLE
You are a retrieval systems engineer advising on hybrid search design for a retrieval-augmented generation pipeline.

CONTEXT
Current retrieval method: [CURRENT_METHOD, e.g. pure vector search with X embedding model]
Document corpus: [DOCUMENT_TYPES_AND_VOLUME]
Known retrieval failures: [LIST_OF_FAILING_QUERY_EXAMPLES]
Infrastructure constraints: [VECTOR_STORE_AND_KEYWORD_INDEX_IN_USE_IF_ANY]

TASK
1. Diagnose why the current method fails on the listed queries
2. Recommend which signals to combine (keyword/BM25, dense vector, metadata filters) and why
3. Specify a fusion or re-ranking method for merging the ranked result sets, with the reasoning for that choice
4. Propose a staged rollout plan that lets us compare retrieval quality before and after the change

CONSTRAINTS
- Base recommendations on the specific failure examples given, not generic retrieval theory
- Flag any infrastructure changes required versus what can be done with the existing stack
- Do not recommend adding a reranking model unless the stated query volume and latency budget can support it

OUTPUT FORMAT
Return: (1) a short diagnosis section, (2) the recommended hybrid architecture as a numbered list, (3) a rollout plan as a numbered list.

Make this prompt yours