--- title: "Discussion on \"RAG vs Long Context in .NET\" | Hashnode" description: "Discussion on \"RAG vs Long Context in .NET\". A side by side comparison" url: "https://hashnode.com/posts/rag-vs-long-context-in-net/6ac12ef77048726fab66cd50" --- [Feed](https://hashnode.com/feed) / Discussion # [RAG vs Long Context in .NET](https://dotnetdigest.com/rag-vs-long-context-in-net?utm_source=hashnode&utm_medium=feed) A side by side comparison Oct 3 · 22 min read · dotnetdigest.com Read the article - [#ai](https://hashnode.com/tag/ai) - [#artificial-intelligence](https://hashnode.com/tag/artificial-intelligence) - [#programming-blogs](https://hashnode.com/tag/programming-blogs) - [#microsoft](https://hashnode.com/tag/microsoft) - [#dotnet](https://hashnode.com/tag/dotnet) - [#csharp](https://hashnode.com/tag/csharp) - [#software-engineering](https://hashnode.com/tag/software-engineering) - [#software-development](https://hashnode.com/tag/software-development) - [#web-development](https://hashnode.com/tag/web-development) - [#rag](https://hashnode.com/tag/rag) - [#long-context](https://hashnode.com/tag/long-context) ## Written by [Patrick Kearns](https://hashnode.com/@fullstackcity) @fullstackcity · Dublin [View profile](https://hashnode.com/@fullstackcity) Senior .Net Engineer Senior Software Engineer specialising in cloud architecture, distributed systems, and modern .NET development, with over two decades of experience designing and delivering enterprise platforms in financial, insurance, and high-scale commercial environments. My focus is on building systems that are reliable, scalable, and maintainable over the long term. I’ve led modernisation initiatives moving legacy platforms to cloud-native Azure architectures, designed high-throughput streaming solutions to eliminate performance bottlenecks, and implemented secure microservices environments using container-based deployment models and event-driven integration patterns. From an architecture perspective, I have strong practical experience applying approaches such as Vertical Slice Architecture, Domain-Driven Design, Clean Architecture, and Hexagonal Architecture. I’m particularly interested in modular system design that balances delivery speed with long-term sustainability, and I enjoy solving complex problems involving distributed workflows, performance optimisation, and system reliability. I enjoy mentoring engineers, contributing to architectural decisions, and helping teams simplify complex systems into clear, maintainable designs. I’m always open to connecting with other engineers, architects, and technology leaders working on modern cloud and distributed system challenges. ## Responses 5 Markdown supported · ⌘↵ to post [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. [Evelyn Wyatt](https://hashnode.com/@Evelynwyatt) [Oct 5](https://hashnode.com/posts/rag-vs-long-context-in-net/6ac12ef77048726fab66cd50/comment/6ac38c67c6334ea27e3bd211) The distinction between finding relevant evidence and preserving sufficient evidence for reasoning is an important one here. A retrieval system can return highly relevant chunks and still fail if the answer depends on a definition, exception, or relationship that wasn't included in the final evidence bundle. I’d be interested in evaluating “evidence completeness” alongside retrieval precision and recall: not just whether the expected passage was retrieved, but whether all dependencies required to justify the answer survived selection and packing. That metric could also make the RAG-versus-long-context decision more concrete. If a task repeatedly requires broad evidence relationships, long context or structured parent expansion may be the better baseline even when top-k retrieval looks strong. [Patrick Kearns](https://hashnode.com/@fullstackcity) [Oct 6](https://hashnode.com/posts/rag-vs-long-context-in-net/6ac12ef77048726fab66cd50/comment/6ac38c67c6334ea27e3bd211#reply-6ac53d7a9ca5553710ebb889) Yeah, thats worth measuring alongside precision and recall. Id test completeness against the evidence actually sent to the model, because retrieving a required definition or exception doesn't help if packing drops it. Questions with known evidence dependencies would make a useful comparison between top-k retrieval, parent expansion and long context, checking whether each approach preserves enough evidence to support the answer.