---
title: "Comment by Ahmet Özel on \"RAG vs Long Context in .NET\" | Hashnode"
description: "EvidencePacker re-counting the assembled messages on each trial is a defensible correctness baseline because metadata and framing consume tokens too. With many"
url: "https://hashnode.com/posts/rag-vs-long-context-in-net/6ac12ef77048726fab66cd50/comment/6ac2922725455dedc00c8392"
---

[Discussion](https://hashnode.com/posts/rag-vs-long-context-in-net/6ac12ef77048726fab66cd50)

Comment [RAG vs Long Context in .NET](https://hashnode.com/posts/rag-vs-long-context-in-net/6ac12ef77048726fab66cd50)

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

[Oct 4](https://hashnode.com/posts/rag-vs-long-context-in-net/6ac12ef77048726fab66cd50/comment/6ac2922725455dedc00c8392)

EvidencePacker re-counting the assembled messages on each trial is a defensible correctness baseline because metadata and framing consume tokens too. With many candidate sections, however, it repeatedly tokenizes the same growing prefix, so packing itself can become measurable work before the model call.

I would record packing latency alongside retrieval and generation, particularly for parent-expanded evidence. An incremental counter could reduce repeated work, but only after testing it against the complete serialized request; summing isolated text counts can miss boundary and framing effects. Keeping the existing full-count path as an oracle would make that optimization safer.

[Patrick Kearns](https://hashnode.com/@fullstackcity)

[Oct 4](https://hashnode.com/posts/rag-vs-long-context-in-net/6ac12ef77048726fab66cd50/comment/6ac2922725455dedc00c8392#reply-6ac2956377e0ea1cc23f374d)

Yeah, I’d expect packing latency to be measured alongside retrieval and generation when taking this into production. The full count approach gives the example a straightforward correctness baseline, if profiling shows it's becoming expensive, an incremental counter is a sensible optimisation, validated against that existing path.

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

[Oct 4](https://hashnode.com/posts/rag-vs-long-context-in-net/6ac12ef77048726fab66cd50/comment/6ac2922725455dedc00c8392#reply-6ac29a50c53a302552cf1e7b)

Keeping the example's full-count path as the baseline makes sense. For an incremental implementation, I would build the parity fixtures around boundary cases: an empty section, a source label containing non-ASCII text, a section admitted exactly at the budget, and one rejected just above it.

Assert the selected section IDs as well as the final count. Two counters can disagree only slightly yet choose different evidence at the boundary, which changes the model input even when both totals look reasonable. Profiling can then decide whether the extra implementation is justified.