Rawq – semantic code search for AI agents (4x fewer wasted tokens, Rust, OSS)(github.com)
github.com
Rawq – semantic code search for AI agents (4x fewer wasted tokens, Rust, OSS)
https://github.com/auyelbekov/rawq
6 comments
Thanks for the concrete numbers — 4 minutes for 63k lines on a 3060 is pretty reasonable for a full index pass, especially with incremental after that.
I work with a few TypeScript/Python monorepos in the 5-8k file range. Most are mixed codebases — application code, configs, generated types, test fixtures. Happy to run rawq against one and report back with timings and chunk counts. The interesting test would be whether search quality degrades gracefully as you push past the 50k chunk threshold, or if it falls off a cliff.
Curious about your thinking on the vector store side — is HNSW (or something like FAISS IVF) on the roadmap, or are you leaning toward a different approach for scaling? The flat search has the advantage of exact results, so there's a real tradeoff there. For code search specifically, I'd imagine recall matters more than in typical document search since missing a relevant function can break an agent's whole approach.
I work with a few TypeScript/Python monorepos in the 5-8k file range. Most are mixed codebases — application code, configs, generated types, test fixtures. Happy to run rawq against one and report back with timings and chunk counts. The interesting test would be whether search quality degrades gracefully as you push past the 50k chunk threshold, or if it falls off a cliff.
Curious about your thinking on the vector store side — is HNSW (or something like FAISS IVF) on the roadmap, or are you leaning toward a different approach for scaling? The flat search has the advantage of exact results, so there's a real tradeoff there. For code search specifically, I'd imagine recall matters more than in typical document search since missing a relevant function can break an agent's whole approach.
The search quality should not degrade as rawq chunks code by its structure into similar sizes across the codebase, the only thing that can get worse is the full indexing time for large codebases, but it is a one-time action and depends on the hardware capabilities.
I wanted to implement HNSW to make searching faster for 50K+ chunks, but there are difficulties with that right now, I couldn’t get it to work properly, but it is on the roadmap.
I wanted to implement HNSW to make searching faster for 50K+ chunks, but there are difficulties with that right now, I couldn’t get it to work properly, but it is on the roadmap.
1. Indexing is incremental — only changed files get re-embedded either on subsequent runs or with the watch mode command in the background. So no, it is not full re-index each time, unless forced.
2. 63k lines of Rust code took about 4 minutes on my 6 GB VRAM 3060 RTX on laptop for full indexing. For a 10k-file monorepo, I honestly haven't tested yet. The vector store is flat brute-force (no HNSW), works well under ~50k chunks. At 10k files, you'd probably hit 200k+ chunks, so that part would need work. If you have a repo that size, I'd love to know how it goes.
Interesting that you went with a hybrid semantic + lexical approach. Pure semantic search on code tends to miss exact identifier matches, and pure lexical misses conceptual similarity. The combination is the right call.
How does indexing scale? For a 10k-file monorepo, what's the initial index time and index size? And does it handle incremental updates (only re-index changed files), or is it full re-index each time?