Datos maestros antes de un RAG: la lista para revisarlos

Antes de montar un RAG, revise los datos maestros: duplicados, campos vacíos, nomenclatura inconsistente, registros vencidos y qué información no debe exponerse. El modelo casi nunca es el problema. La fuente de datos casi siempre lo es. Un RAG sobre datos sucios responde con seguridad y se equivoca, y esa confianza mal fundada es lo que rompe la adopción.

El 80% del trabajo no es el modelo

Cuando una empresa piensa en un RAG, la conversación arranca por el modelo: Claude, GPT o Gemini. Esa es la parte fácil y estandarizada. El 80% del trabajo no es el modelo: es preparar y limpiar la fuente de datos.

Un RAG recupera fragmentos de su información y se los entrega al modelo como contexto. Si el contexto está sucio, la respuesta sale sucia. La calidad de la recuperación depende de la calidad de los datos maestros, no del tamaño del modelo.

Para una empresa de manufactura con SAP Business One, el cuello de botella suele estar en la calidad de los datos maestros antes de llegar al RAG. Por eso la revisión empieza ahí, no en la elección de la herramienta.

Qué revisar en los datos maestros antes de montar un RAG

Esta es la lista que aplico antes de conectar cualquier modelo. Cada punto sale de montar un RAG que hoy responde a presidencia sobre información financiera y productiva en lenguaje natural.

1. Duplicados: un mismo cliente o artículo con dos códigos

El registro duplicado es el error más común y el más caro. El mismo cliente cargado con dos códigos, el mismo artículo con dos referencias. El RAG recupera las dos versiones, cada una con cifras distintas, y el modelo elige una sin saber cuál es la buena. Consolide antes de indexar: un concepto, un registro.

2. Campos obligatorios vacíos o inconsistentes

Unidades de medida ausentes, categorías sin asignar, fechas en formatos distintos. Un artículo sin unidad de medida no se puede comparar con otro; una factura sin fecha consistente no se puede ordenar en el tiempo. Defina qué campos son obligatorios para las preguntas que va a responder y complételos antes, no durante.

3. Nomenclatura: que cada concepto se llame igual en todas partes

Si en un módulo dice “devolución” y en otro “nota crédito” para lo mismo, el RAG los trata como cosas distintas. La recuperación se fragmenta y las respuestas quedan incompletas. Unifique el vocabulario de negocio antes de indexar: el modelo no adivina sinónimos que usted no le declaró.

4. Registros inactivos y datos vencidos

Clientes que ya no operan, listas de precios de hace tres años, productos descontinuados. Si viven en la misma tabla que los datos vigentes, el RAG los recupera como si fueran actuales. Marque el estado de cada registro y filtre lo inactivo antes de que llegue al índice.

5. Qué NO debe exponer el RAG

Un agente sin límites es un riesgo, no una ventaja. Antes del primer prompt, defina qué información no puede salir: costos sensibles, datos personales, cifras que solo ve la dirección. La revisión de datos maestros también decide qué queda fuera del alcance del modelo, no solo qué entra.

6. Una sola fuente de verdad

El dato debe vivir en un lugar y actualizarse en un lugar. Si la misma cifra existe en SAP Business One, en una hoja de cálculo y en un correo, el RAG puede recuperar la versión equivocada. Declare SAP Business One como el maestro y trate el resto como copias que se sincronizan, no como fuentes paralelas.

La prueba en producción: un RAG sobre SAP Business One

Esta lista no es teórica. En SAFRA, una empresa de manufactura de Bogotá, monté un RAG sobre la información financiera y productiva de SAP Business One. Presidencia consulta las cifras en lenguaje natural, en tiempo real, sin abrir un reporte intermedio ni esperar al área de sistemas.

El sistema no llegó ahí por el modelo. Llegó después de limpiar y ordenar los datos maestros con la lista de arriba. La primera versión, sobre datos sin depurar, respondía con seguridad y se equivocaba, que es la peor combinación posible en una consulta de negocio.

Ese RAG convive con dos agentes autónomos, OpenClaw y HermesAgent, operando 24/7 desde hace más de 2 años, y con flujos n8n que combinan IA, SAP, PayU y WhatsApp. Todo eso se sostiene sobre la misma base: datos maestros en orden.

Cómo empezar sin sobre-invertir

No hace falta limpiar toda la base para arrancar. Elija el conjunto de preguntas que la dirección va a hacer primero — por ejemplo, ventas por línea o inventario por bodega — y depure solo los datos maestros que esas preguntas tocan. Defina el resultado medible a 90 días y trabaje hacia atrás desde ahí.

Con 25 años poniendo sistemas en producción, la lección se repite: el proyecto que intenta limpiarlo todo antes de mostrar valor rara vez llega a producción. El que resuelve una pregunta real y la pone a operar, sí llega.

Preguntas frecuentes

¿Qué son los datos maestros en el contexto de un RAG?

Son los registros base de su operación: clientes, proveedores, artículos, listas de precios, plan de cuentas. En un RAG son la fuente que el sistema recupera para responder. Si están sucios o duplicados, el modelo responde sobre información equivocada.

¿Cuánto tiempo toma preparar los datos antes de un RAG?

Depende del estado de la base y del alcance que elija. Acotando la revisión a las preguntas iniciales, se avanza en semanas, no en meses. Intentar depurar toda la base de una vez es la forma más rápida de que el proyecto no llegue a producción.

¿Un RAG puede funcionar sin limpiar los datos primero?

Funciona en una demo. En producción no. Un RAG sobre datos sucios responde con seguridad y se equivoca, y esa confianza mal fundada rompe la adopción más rápido que cualquier error visible.

¿Qué diferencia hay entre limpiar los datos y montar el modelo?

Montar el modelo es conectar Claude, GPT o Gemini y configurar la recuperación: la parte estandarizada. Limpiar los datos es el 80% del trabajo y lo que decide si las respuestas sirven. El criterio está en los datos, no en la marca del modelo.

¿Necesito SAP Business One para montar un RAG?

No. El método aplica a cualquier fuente estructurada. SAP Business One es el caso donde lo tengo operando, pero la lista — duplicados, campos vacíos, nomenclatura, registros vencidos, límites y fuente única — sirve para cualquier ERP o base de datos.

El trabajo menos vistoso decide el resultado

Antes de elegir el modelo, revise los datos maestros. Es la parte menos vistosa del proyecto y la que decide si el RAG sirve. Puede ver cómo trabajo la IA y la automatización en la página principal, el detalle de los dos agentes que corren 24/7 y el resto de casos en producción.

Si su empresa ya tiene SAP Business One y una pregunta que la dirección repite, hablemos de su proyecto: escríbame desde la página de contacto.