[dead]
We replaced RAG with a virtual filesystem for our AI documentation assistant
141–150 of 190 posts
Re: We replaced RAG with a virtual filesystem for our AI documentation assistant
#142Re: We replaced RAG with a virtual filesystem for our AI documentation assistant
#143Re: We replaced RAG with a virtual filesystem for our AI documentation assistant
#144[dead]
Re: We replaced RAG with a virtual filesystem for our AI documentation assistant
#145[dead]
Re: We replaced RAG with a virtual filesystem for our AI documentation assistant
#146Re: We replaced RAG with a virtual filesystem for our AI documentation assistant
#147> even a minimal setup (1 vCPU, 2 GiB RAM, 5-minute session lifetime) would put us north of $70,000 a year based on Daytona's per-second sandbox pricing ($0.0504/h per vCPU, $0.0162/h per GiB RAM) $70k? how about if we round off one zero? Give us $7000. That number still seems to be very high.
Hm. I think a dedicated 16-core box with 64 ram can be had for under $1000/year. It being dedicated there are no limits on session lifetime and it'd run 16 those sessions no problem, so the real price should be around ~$70/year for that load.
It looks like, to me, that someone spent a long back-and-forth with an LLM refining a design - everything they wrote screams "over-engineered, lots of moving parts, creating tiny little sub-problems that need to then be solved".
I find it very hard to believe that a human designed their process around a "Daytona Sandbox" (whatever the fuck that is) at 100x markup over simply renting a VPS (a DO droplet is what, $6/m? $5/m?) and either containerising it or using FreeBSD with jails.
I'm looking at their entire design and thinking that, if I needed to do some stuff like this, I'd either go with a FUSE-based design or (more flexible) perform interceptions using LD_PRELOAD to catch exec, spawn, open, etc.
What sort of human engineer comes up with this sort of approach?
Re: We replaced RAG with a virtual filesystem for our AI documentation assistant
#148Re: We replaced RAG with a virtual filesystem for our AI documentation assistant
#149The title says you replaced RAG, but ChromaFs is still querying Chroma on every command — you replaced RAG's interface, not RAG itself. Which is actually the more interesting finding: the retrieval was never the bottleneck, the abstraction was. Agents don't need better search. They need `grep`.
exactly, embeddings destroy information.. exact keywords, acronyms, etc. They get squashed into floats.
That is why grep still beats it for code.
I generated visual schematic of every stage of the pipeline - https://vectree.io/c/retrieval-augmented-generation-embeddin...
Re: We replaced RAG with a virtual filesystem for our AI documentation assistant
#150The real thing I think people are rediscovering with file system based search is that there’s a type of semantic search that’s not embedding based retrieval. One that looks more like how a librarian organizes files into shelves based on the domain. We’re rediscovering forms of in search we’ve known about for decades. And it turns out they’re more interpretable to agents. https://softwaredoug.com/blog/2026/01/08/seman…
more and more often you see "new discoveries" that are very old concepts. the only discovery that usually happens there is that the author discovers for himself this concept. but it is essential nowadays to post it like if you discovered something new