---
title: "Comment by Ahmet Özel on \"How RAG Works, End to End: From Raw Documents to Grounded Answers\" | Hashnode"
description: "The paragraph-based chunker needs one additional size guard: a single paragraph can exceed max_tokens, because it is appended after the overflow check and is ne"
url: "https://hashnode.com/posts/how-rag-works-end-to-end-from-raw-documents-to-grounded-answers-x482z/6ad6de51055a947908902e5b/comment/6ad72bb35cfb27624431e135"
---

[Discussion](https://hashnode.com/posts/how-rag-works-end-to-end-from-raw-documents-to-grounded-answers-x482z/6ad6de51055a947908902e5b)

Comment [How RAG Works, End to End: From Raw Documents to Grounded Answers](https://hashnode.com/posts/how-rag-works-end-to-end-from-raw-documents-to-grounded-answers-x482z/6ad6de51055a947908902e5b)

[Ahmet Özel](https://hashnode.com/@ahmetozel)

[Oct 20](https://hashnode.com/posts/how-rag-works-end-to-end-from-raw-documents-to-grounded-answers-x482z/6ad6de51055a947908902e5b/comment/6ad72bb35cfb27624431e135)

The paragraph-based chunker needs one additional size guard: a single paragraph can exceed max\_tokens, because it is appended after the overflow check and is never split. That matters when the embedding endpoint truncates long inputs without rejecting them.

The stored chunk can then contain a relevant sentence that never contributed to its vector, making the failure look like weak semantic retrieval. I would add a long-paragraph fixture and assert the final token count using the embedding tokenizer, including any contextual prefix. Record truncation explicitly or reject oversized chunks before indexing, so the text you inspect is the text the embedding model actually saw.

[ZyVOP](https://hashnode.com/@zyvop)

[Oct 20](https://hashnode.com/posts/how-rag-works-end-to-end-from-raw-documents-to-grounded-answers-x482z/6ad6de51055a947908902e5b/comment/6ad72bb35cfb27624431e135#reply-6ad73512359dd3ec7b06bcc0)

Good catch. You're right — a long paragraph can slip past the size check, and if the embedding model truncates it, the stored text won't match what the model actually used to create the vector. Adding a test for that case, including the contextual prefix, makes sense. I'd rather catch oversized chunks before indexing than have them silently affect retrieval. Thanks for pointing this out.

[Ahmet Özel](https://hashnode.com/@ahmetozel)

[Oct 30](https://hashnode.com/posts/how-rag-works-end-to-end-from-raw-documents-to-grounded-answers-x482z/6ad6de51055a947908902e5b/comment/6ad72bb35cfb27624431e135#reply-6ae42eac31804cf4d6b1213a)

Rejecting oversized chunks before indexing is the right place for the invariant. I would make the check part of the final embedding request construction, after adding headings or other contextual prefixes, because a chunk that passed an earlier size check can exceed the limit at that last step.

The long-paragraph fixture should put its decisive sentence near the end. That makes silent truncation observable in the test, rather than only checking the size of text retained in storage.