# Large source’s chunks are overrides small source’s chunks

> Source: <https://discuss.huggingface.co/t/large-source-s-chunks-are-overrides-small-source-s-chunks/191389#post_2>
> Published: 2026-11-03 14:58:54+00:00

This sounds like a retrieval-ranking issue rather than an embedding-generation issue.

Since your large sources contribute significantly more chunks, they may dominate the candidate pool during similarity search. Vector search doesn’t automatically prioritize smaller or newer documents.

A few things you could try:

**Metadata filtering:** Attach a `source_id` or document identifier to each chunk and filter retrieval to the relevant PDF when the user specifies it.

**Hybrid retrieval:** Combine dense vector search with BM25 so exact heading and keyword matches aren’t missed.

**Reranking:** Retrieve a broader set of candidates and use a cross-encoder reranker to improve relevance.

**Source-aware ranking:** Apply a controlled source-priority score when you know which document the user wants.

**Check chunking and indexing:** Verify that the PDF’s five chunks were successfully embedded, stored and included in the retrieval results.

One important debugging step: run the query directly against your vector database and inspect the top 10 retrieved chunks, including their source metadata and similarity scores.

That will help establish whether the PDF chunks are missing from retrieval or whether the assistant is losing them later in the RAG pipeline.

Which vector database and retrieval framework are you using?
