Recent submissions

Comment · 2 months ago
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.

Comment · 2 months ago
thanks :)
Comment · 2 months ago
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.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton