Antenor Blog 5 min read
We Built RAG Before It Was Called RAG
Decades before large language models, we built XLBase — a proprietary retrieval engine — and the legal case-law system on it acquired by Jurisprudencia Argentina. What that experience teaches about building RAG that actually works today.
Retrieval-augmented generation feels new because the “generation” part is. The “retrieval” part — finding the right document by meaning, at scale, over a corpus that never stops growing — is a problem we have been solving for decades. We built XLBase, a proprietary search engine, and on it a legal case-law retrieval system, acquired by Jurisprudencia Argentina, that let lawyers find precedents by court, ruling, parties and jurisdiction. The engineering lessons from that era are exactly the ones most RAG projects get wrong today.
Everyone building a RAG system right now is spending their attention on the language model. That is the part that changed. It is not the part that decides whether the system works.
We know because we built the retrieval half of this problem long before there was a model to bolt onto it. Our founder’s team built XLBase, a proprietary high-performance search engine, and used it to power a legal information-retrieval system for national jurisprudence — precedents searchable by court, ruling, parties and jurisdiction, over a corpus kept current through the internet when that was itself novel. That system was acquired by Jurisprudencia Argentina, one of the country’s canonical case-law publishers. The same engine went on to run bibliographic CD-ROMs, national phone directories, and telecom call-detail-record consultation.
Four industries, one retrieval engine, built when “vector database” and “semantic search” were not yet phrases. Here is what that leaves you knowing that a model-first team does not.
The retrieval engine decides the answer, not the model
An LLM can only reason over what retrieval hands it. If the right passage never makes it into the context window, no amount of model quality recovers the answer — the model simply writes a fluent, confident version of the wrong one. In the XLBase era we had no model to hide behind: if the search returned the wrong case, the lawyer got the wrong case, and there was no “the AI summarized it nicely” to paper over it.
That discipline is the one most RAG projects skip. They ship a demo on a clean corpus, watch the model sound smart, and never measure whether retrieval actually surfaces the decisive document on real queries. We build the retrieval layer first and measure it in isolation, before a single token of generation, because that is the layer that is actually failing when a RAG system “hallucinates.”
In high-stakes domains, a confident wrong answer is the worst outcome
Legal research has no tolerance for “mostly right.” A missed precedent or a misattributed ruling is not a lower score on a benchmark; it is a losing case. Building for that standard forces a different posture: the system must know what it does not know, refuse when confidence is low, and make every claim traceable to a source a professional can open and verify.
This is why, on modern RAG engagements, we put a verification layer on top of retrieval that checks every claim in the consolidated answer back against its source passages and drops anything the documents do not support. The instinct comes straight from legal retrieval: the system that summarizes must be audited by a system that fact-checks it. Law firms feel this most acutely, but so does anyone whose answers carry real cost.
Freshness is a systems problem, not a model problem
XLBase kept its legal corpus current by updating over the internet — an ingestion and reconciliation pipeline, not a clever query trick. Jurisprudence that is a month stale is a liability, so the hard engineering was in keeping the searchable corpus aligned with the authoritative source.
Nothing about LLMs removed that work. A RAG system is only as trustworthy as the freshness of what it retrieves, and incremental updates — knowing what changed, re-indexing only that, and never serving a confidently outdated answer — are still where production systems live or die. Teams that treat the corpus as a one-time upload learn this the expensive way.
Structure beats similarity when the domain has structure
Legal search is not “find text that looks like my query.” It is find the ruling from this court, in this jurisdiction, involving these kinds of parties. Those are facets, relationships and metadata — structure that generic similarity throws away. XLBase indexed around how legal professionals actually search, not around raw text proximity.
The modern echo is the same: pure vector search underperforms on entity-heavy, structured corpora — contracts, filings, case law, catalogs — where hybrid retrieval and, where it pays off, graph-aware retrieval beat embeddings alone. The lesson predates the tools: model the way the domain is queried, not just the way the text reads.
Why this matters if you are buying RAG today
Most “AI search” vendors started building last year. The retrieval problems they are discovering — precision on high-stakes queries, freshness, entity structure, verifiable answers — are problems we have been solving since before the language model existed. When we build a RAG or knowledge system, especially for a law firm or research team, that history is not nostalgia. It is why the system surfaces the right document, refuses when it should, and can be trusted with an answer that carries a cost.
Frequently asked questions
Isn’t RAG a brand-new technology?
The generative layer is recent; the retrieval layer is not. Information retrieval — ranking documents by relevance to a query — is a mature discipline, and the failure modes of RAG systems are overwhelmingly retrieval failures wearing a language-model costume. Teams with deep retrieval experience tend to build more reliable RAG than teams who treat it as a prompting exercise.
What makes legal document retrieval harder than general search?
Stakes and structure. A wrong result can lose a case, so precision and verifiability are non-negotiable, and legal queries depend on structured facets — court, jurisdiction, parties, date — that plain similarity ignores. Systems built for law transfer well to any domain where being wrong is expensive.
How does old search experience help with modern LLM systems?
The hard, unglamorous parts of RAG — measuring retrieval in isolation, keeping a corpus fresh, modeling domain structure, refusing when confidence is low — are exactly the parts a language model does not solve for you. Having built retrieval engines before LLMs existed means we start from the layer that actually determines whether the system works.