Soluciones RAG · Granada / Remoto

Soluciones RAG: tu documentación, con respuestas

RAG es la técnica que hace que un modelo responda con tu documentación delante y cite de dónde ha sacado cada afirmación. Lo mantengo en producción a diario en urbanisti.co, sobre normativa urbanística española. El mismo enfoque, aplicado a tus manuales, contratos o procedimientos internos.

RAG —retrieval-augmented generation— funciona así: cuando alguien pregunta, el sistema busca primero los fragmentos relevantes en tu documentación y solo entonces le pide al modelo que redacte una respuesta usando exclusivamente ese material, con la referencia al documento y al apartado. Si no encuentra base suficiente, la respuesta correcta es decir que no lo sabe.

Lo que se compra con RAG no es fluidez, es verificabilidad. Quien recibe la respuesta puede abrir la fuente y comprobarla en diez segundos, y eso cambia quién se atreve a usar el sistema para decidir algo. Es exactamente el problema que resolví en urbanisti.co, un RAG en producción sobre normativa urbanística española construido con FastAPI, LangGraph y BigQuery Vector Search, donde una respuesta sin cita al artículo no le sirve a nadie.

  • Encaja si tienes documentación extensa y viva —normativa, contratos, manuales, procedimientos, histórico de soporte— que se consulta a menudo y que nadie se sabe entera.
  • Encaja si la respuesta tiene que ser comprobable: alguien va a tomar una decisión con ella y necesita ver el párrafo exacto que la sostiene.
  • Encaja si el conocimiento cambia con el tiempo y no quieres reentrenar nada: al actualizar el documento, el sistema responde ya con la versión nueva.
  • No encaja si el volumen es pequeño y estable. A veces el mejor sistema es un buen buscador, o meter los cuatro documentos completos en el contexto del modelo.
  • No encaja si lo que se pregunta son cifras agregadas que viven en una base de datos: eso es una consulta SQL y no una búsqueda semántica.
  • Cuidado si la documentación está desactualizada o se contradice: RAG hará visible ese desorden muy rápido. Es incómodo, y suele ser lo más valioso del proyecto.
Auditoría y preparación del corpus

Reviso qué documentos hay, en qué formato y en qué estado. Después defino el troceado y los metadatos —versión, vigencia, ámbito, permisos—, porque de eso depende la calidad final mucho más que del modelo que elijas.

Pipeline de ingesta

Un proceso repetible que convierte PDF, escaneos, HTML u hojas de cálculo en fragmentos indexados, y que se vuelve a ejecutar solo cuando el documento cambia. Sin ingesta automatizada, el sistema envejece en un mes.

Búsqueda híbrida

Búsqueda vectorial combinada con búsqueda por palabra clave, reordenación de resultados y filtros por metadatos. Los códigos de referencia, los nombres propios y los números exactos se pierden si solo usas embeddings.

Citación obligatoria a la fuente

La respuesta enlaza al documento y al apartado concretos, y el sistema está diseñado para reconocer cuándo no tiene material suficiente y decirlo en lugar de rellenar el hueco.

Evals de calidad de respuesta

Un conjunto de preguntas con respuesta conocida que mide dos cosas distintas: si el sistema encuentra los fragmentos correctos y si lo que afirma está realmente sostenido por ellos. Se ejecuta en cada cambio.

Interfaz de chat o API

Una UI de consulta con historial y fuentes a la vista, una API para integrarlo en tu producto, o ambas. Respetando el modelo de permisos de tu organización: cada persona solo obtiene respuestas de los documentos que puede leer.

El modelo es la parte fácil y la última que decido. La calidad de un RAG se juega en la preparación del corpus, en la búsqueda y en la evaluación, así que la mayor parte del trabajo ocurre antes de la llamada al LLM. Uso pgvector cuando tus datos ya viven en PostgreSQL y quieres una pieza menos que operar, y BigQuery Vector Search cuando el volumen o el ecosistema de Google lo justifican: es la combinación que sostiene urbanisti.co. La orquestación va en Python con FastAPI y LangGraph, y el generador puede ser Claude, GPT o Gemini, que es la pieza más fácil de sustituir cuando cambian los precios.

LangGraphEmbeddingsBigQuery Vector SearchpgvectorFastAPIClaude APIOpenAI APIEvals
01
Auditoría del corpus

Miro una muestra representativa de tus documentos y las preguntas que hace de verdad la gente. Al final de la semana sabes si tu documentación está lista, qué conviene arreglar antes y qué preguntas no va a poder responder ningún sistema. Una semana.

02
Prototipo evaluable

Ingesta de un subconjunto del corpus, búsqueda funcionando y un conjunto de preguntas de evaluación acordado contigo. El resultado no es una demo bonita: es una cifra de acierto sobre preguntas reales, y esa cifra decide si seguimos. De dos a tres semanas.

03
Producción

Corpus completo, ingesta automatizada, permisos, interfaz o API, trazas y control de coste por consulta. Con entrada de usuarios por fases, para corregir sobre uso en lugar de sobre suposiciones. De tres a seis semanas.

04
Mejora continua

Las preguntas que fallan son el mejor mapa de lo que le falta a tu documentación. Cada ciclo de revisión añade casos a los evals y afina el troceado o la búsqueda. Los plazos son orientativos y dependen sobre todo del estado de los documentos: un corpus limpio acelera todo lo demás.

Cuéntame tu caso y te digo con franqueza si la IA es la herramienta adecuada — y cómo la implementaría.