HNHacker News
TopNewBestAskShowJobs

emilianoc

6 karma · joined June 29, 2026

submissionscomments
emilianoc··on Show HN: RAGless – similar to RAG, but $0 LLM API costs at runtime
In traditional RAG (Retrieval-Augmented Generation), you use an LLM at runtime to read those retrieved documents and synthesize a direct, conversational answer for the user. That generative step is what incurs an API cost and adds latency per query.

RAGless gives you that direct Q&A experience (the synthesized answer) but removes the runtime generation by pre-computing all the answers offline.

emilianoc··on Show HN: RAGless – similar to RAG, but $0 LLM API costs at runtime
thanks :)
emilianoc··on Show HN: RAGless – similar to RAG, but $0 LLM API costs at runtime
Hi HN,

I built RAGless to remove the LLM from the critical query path. Traditional RAG is powerful, but introduces non-deterministic behavior (hallucinations) and recurring API costs at runtime.

RAGless shifts the LLM entirely to build/ingestion time. It processes your documents offline to generate a deterministic artifact of Question-Answer pairs, strictly grounded in source quotes.

At runtime, there is no LLM in the loop. It relies solely on semantic search (Q-Q matching) between the user's query and the pre-computed questions.

$0 LLM API costs per query.

Deterministic outputs: it only serves pre-validated answers.

Low latency: zero generation wait time.

The hardest bottleneck in this "compile-time" architecture is validating the generated artifact before deployment. Currently, I use strict JSON schema enforcement and an optional --judge pass. The judge acts purely as a tripwire/veto to discard ungrounded blocks, keeping the ultimate trust on the deterministic layer.

I'd love to hear your thoughts on this pattern and how you tackle artifact validation.