De la Retrieval-Augmented Generation se habla en todas partes, casi siempre de la misma manera: se toma un modelo de lenguaje, se le «conectan» los documentos de la empresa y, desde ese momento, responde citando las fuentes. La realidad, como suele ocurrir, es más interesante que el folleto.
Nosotros lo sabemos porque una plataforma RAG la hemos construido y puesto en producción de verdad — íntegramente on-premise, sobre hardware dentro de nuestro perímetro, con modelos abiertos. Hoy es la base de ACME ECMS IA & RAG Integration, y en su página dedicada encontrarás los esquemas de la infraestructura y una demo de su funcionamiento. Aquí, en cambio, contamos lo que los esquemas no dicen: las cinco lecciones que cambiaron nuestra forma de diseñar estos sistemas.
1 · La calidad se decide en el retrieval, no en el modelo
La tentación de quien empieza es concentrarse en el modelo: qué LLM, cuántos parámetros, qué versión. Es la parte equivocada del problema. Si los pasos que recuperan los documentos llevan al modelo el contenido equivocado, el modelo más potente del mundo hará una sola cosa: resumir bien la cosa equivocada.
El trabajo de verdad está aguas arriba: cómo se trocean los documentos (el chunking), con qué representaciones se indexan (los embeddings) y, sobre todo, cuánta estructura se da a la base de conocimiento. En nuestra plataforma, junto al índice vectorial vive un knowledge graph: entidades y relaciones extraídas de los documentos, que permiten responder también a preguntas que atraviesan varios documentos — allí donde la mera similitud semántica no basta.
2 · Recuperación híbrida más re-ranking: dos pasos, no uno
Un único paso de búsqueda debe elegir entre dos objetivos en conflicto: no perder nada relevante y no dejar pasar ruido. La solución que nos ha funcionado es separarlos.
El primer paso es amplio e híbrido — vectores, palabras clave y grafo a la vez — y está optimizado para la exhaustividad: mejor un candidato de más que uno de menos. El segundo paso es un re-ranker, un modelo dedicado que reordena los candidatos por su pertinencia real respecto a la pregunta y descarta lo que se parece pero no responde. Es uno de los componentes que más ha elevado la calidad percibida de las respuestas: las fuentes citadas dejan de estar «cerca del tema» y empiezan a ser las correctas.
3 · No todas las preguntas merecen el RAG
Un error común es tratar todas las peticiones de la misma manera: pida lo que pida el usuario, se lanza la pipeline completa — búsqueda, re-ranking, generación con contexto. El resultado son respuestas lentas y costosas incluso cuando nada de eso hacía falta.
En nuestra arquitectura la primera decisión la toma un planner: un componente que clasifica la petición y elige el camino. Un saludo o una pregunta de cultura general toman la vía directa, sin tocar la base documental; una pregunta sobre contratos, procedimientos o proyectos activa la pipeline completa. Parece un detalle: en producción es la diferencia entre un sistema que «responde cuando puede» y un servicio con latencias y consumos predecibles.
4 · Sin métricas solo estás adivinando
Cambias el modelo de embeddings y las respuestas «parecen» mejores. Revisas el chunking y «parecen» peores. ¿Le parecen a quién? ¿Con qué preguntas? La sensación de quien desarrolla no es una métrica, y en un sistema que responde en lenguaje natural el ojo se acostumbra rápido.
Por eso la plataforma incluye una evaluación sistemática de la calidad (usamos el framework RAGAS, con un conjunto de prueba construido en italiano sobre nuestros casos de uso): con cada cambio medimos hasta qué punto las respuestas se mantienen fieles a las fuentes, cuán pertinentes son a la pregunta y hasta qué punto es bueno el contexto recuperado. Es el mismo principio de nuestro método — medir, analizar, mejorar, verificar — aplicado a la IA: cada intervención parte de un número y vuelve a un número.
La pregunta correcta no es «¿responde bien la IA?», sino «¿respecto a qué, medido cómo, y mejor o peor que ayer?».
5 · On-premise es viable — y a veces es el único camino
La lección quizá más contraintuitiva: para un RAG corporativo no hace falta un hyperscaler. Modelos abiertos sobre GPU dimensionadas al caso de uso, dentro de una infraestructura gobernada, cubren la inmensa mayoría de las necesidades reales — y aportan una ventaja que ninguna API remota puede ofrecer: los datos no salen nunca del perímetro.
Para sectores enteros esto no es un capricho, es un requisito. En Sanidad los datos relativos a la salud gozan de la protección reforzada del art. 9 del GDPR; en la Administración pública pesan la soberanía del dato y las directrices sobre la nube. Una arquitectura on-premise (o sobre private cloud en Italia) resuelve el problema de raíz — y, con modelos abiertos, elimina también el vendor lock-in.
La otra mitad de la lección: un sistema así hay que gestionarlo como un servicio, no como un experimento. Monitorización de los componentes, backup de la base de conocimiento, actualizaciones controladas de los modelos: la parte «de operación» cuenta tanto como la de diseño.
Por dónde empezar
Si tuviéramos que condensar las cinco lecciones en un solo consejo: empieza en pequeño, pero empieza midiendo. Un caso de uso concreto, un corpus documental definido, métricas de calidad desde el primer día — y una arquitectura que no te obligue a elegir entre innovar y mantener los datos en su sitio.
Cómo está hecha nuestra plataforma — esquemas de infraestructura, flujo lógico y una demo animada del ciclo de vida — se cuenta en la página IA, Agentes y RAG. Y si quieres entender qué podría hacer con tu patrimonio documental, hablemos.
