RAG solutions · Granada / Remote

RAG solutions: your documents, answering back

RAG is the technique that makes a model answer with your documents in front of it and cite where each statement came from. I keep one running in production every day at urbanisti.co, over Spanish urban-planning regulations. The same approach, applied to your manuals, contracts or internal procedures.

RAG — retrieval-augmented generation — works like this: when someone asks a question, the system first searches your documentation for the relevant passages, and only then asks the model to write an answer using that material alone, with a reference to the document and section. If it cannot find enough to stand on, the correct answer is to say so.

What RAG buys you is verifiability rather than fluency. Whoever receives the answer can open the source and check it in ten seconds, and that changes who is willing to use the system to decide anything. It is exactly the problem I solved in urbanisti.co, a production RAG system over Spanish urban-planning regulations built with FastAPI, LangGraph and BigQuery Vector Search, where an answer without a citation to the article is no use to anyone.

  • A good fit if you have a large, living body of documents — regulations, contracts, manuals, procedures, support history — consulted often and known in full by nobody.
  • A good fit if answers have to be checkable: someone is going to make a decision with them and needs to see the exact paragraph behind it.
  • A good fit if the knowledge changes over time and you do not want to retrain anything: update the document and the system answers from the new version.
  • Not a fit if the document set is small and stable. Sometimes the best system is a decent search box, or simply putting all four documents into the model context.
  • Not a fit if the questions are aggregate figures that live in a database: that is a SQL query, not a semantic search.
  • Be careful if the documentation is out of date or contradicts itself: RAG will surface that mess very quickly. It is uncomfortable, and it is often the most valuable part of the project.
Corpus audit and preparation

I review what documents exist, in what format and in what condition. Then I define chunking and metadata — version, validity, scope, permissions — because final quality depends on that far more than on which model you pick.

Ingestion pipeline

A repeatable process that turns PDFs, scans, HTML or spreadsheets into indexed passages, and re-runs by itself when a document changes. Without automated ingestion the system goes stale within a month.

Hybrid retrieval

Vector search combined with keyword search, plus reranking and metadata filters. Reference codes, proper nouns and exact figures get lost if you rely on embeddings alone.

Mandatory source citation

Every answer links to the specific document and section, and the system is designed to recognise when it lacks the material and say so instead of filling the gap.

Answer-quality evals

A set of questions with known answers that measures two different things: whether the right passages are retrieved, and whether what the answer claims is genuinely supported by them. It runs on every change.

Chat interface or API

A query UI with history and sources in plain sight, an API to embed it in your product, or both. Respecting your permission model: each person only gets answers from documents they are allowed to read.

The model is the easy part, and the last thing I choose. RAG quality is won in corpus preparation, retrieval and evaluation, so most of the work happens before the LLM call. I use pgvector when your data already lives in PostgreSQL and you want one less thing to operate, and BigQuery Vector Search when volume or a Google-centred stack justifies it — that is the combination behind urbanisti.co. Orchestration is Python with FastAPI and LangGraph, and the generator can be Claude, GPT or Gemini, which is the easiest piece to swap when prices move.

LangGraphEmbeddingsBigQuery Vector SearchpgvectorFastAPIClaude APIOpenAI APIEvals
01
Corpus audit

I look at a representative sample of your documents and at the questions people actually ask. By the end of the week you know whether your documentation is ready, what needs fixing first, and which questions no system will be able to answer. One week.

02
Measurable prototype

Ingestion of a subset of the corpus, retrieval working and an evaluation set agreed with you. The output is not a pretty demo — it is an accuracy figure over real questions, and that figure decides whether we continue. Two to three weeks.

03
Production

Full corpus, automated ingestion, permissions, interface or API, tracing and cost-per-query control. Users come in by phases, so corrections are based on use rather than assumptions. Three to six weeks.

04
Continuous improvement

The questions that fail are the best map of what your documentation is missing. Each review cycle adds cases to the evals and tunes chunking or retrieval. Timelines are indicative and depend mostly on the state of the documents: a clean corpus speeds up everything else.

Tell me about your case and I'll tell you honestly whether AI is the right tool — and how I would implement it.