Authors: Pradipta Nanda Amlan Das How we get retrieval that doesn't forget context, search that spans text and images, and full control over our embedding stack. If you've built a RAG system, you've
Markdown supported · ⌘↵ to post
Really interesting read! I liked how the post connects late chunking with context-aware embeddings and then takes it into a practical self-hosted GCP setup. The explanation makes a fairly technical topic feel much more approachable. The trade-offs around preserving context while keeping retrieval efficient were especially interesting. Definitely a useful read for anyone working with RAG and modern embedding pipelines.
The late-chunking flip is the part I keep coming back to, embedding first and cutting after preserves neighbor context that vanilla chunk-then-embed silently drops. I also like that you kept the latency numbers honest (0.14 to 0.8s per chunk on self-hosted GCP vs 1 to 3s on Spaces), the "always-on cost" caveat is what most write-ups skip. Curious whether you saw retrieval quality shift on tables and code blocks specifically, those tend to break mean-pooled token embeddings for us.
Duko tools
Building practical, free-to-use tools for developers and everyday users. Currently: Duko Tools.
"Embed first, chunk later" is the right framing, most teams treat chunking as a one-time tuning step when it's actually deciding how much context survives retrieval.
The honest cost table stands out most though, most migration writeups only show numbers that justify the move. Admitting HF Spaces still wins on raw cost for bursty workloads makes the self-hosting case land harder, since it's clearly not being oversold as cheaper.