Limpieza de datos con LLMs: pros, contras y costo real

Tienes una tabla de clientes exportada de tu CRM. El campo “giro” tiene 47 variaciones para decir lo mismo: “manufactura”, “Manufactura”, “MANUFACTURA”, “mfg”, “ind. manufacturera”. Tu equipo lleva dos sprints intentando escribir reglas regex para normalizarlo. Alguien propone: “¿y si le pasamos todo a ChatGPT?”

La idea no es mala. Pero tampoco es la solución completa que parece a primera vista.

Qué hace bien un LLM en limpieza de datos

Los LLMs sobresalen donde las reglas deterministas fallan: en la ambigüedad del lenguaje humano. Un regex puede capturar “mfg” si alguien lo programa explícitamente. Un LLM infiere que “ind. manufacturera NL” y “planta de manufactura Monterrey” probablemente son el mismo giro, sin que nadie le enseñe esa regla.

Los casos de uso donde el LLM aporta ROI claro:

• Normalización de texto libre: nombres de empresas, razones sociales, direcciones capturadas a mano.
• Clasificación con categorías ambiguas: cuando las reglas de negocio no son binarias y dependen de contexto.
• Deduplicación semántica: dos registros que dicen cosas distintas pero se refieren al mismo proveedor.
• Inferencia de campos vacíos: si tienes “nombre del producto: Tornillo hexagonal M8 acero inoxidable” y el campo “material” está vacío, el LLM lo completa con alta precisión.

En proyectos de análisis de datos en Eurema, este tipo de tareas —que antes tomaban 2–3 semanas de trabajo manual o de construcción de reglas— se resuelven en 2–3 días con un pipeline LLM bien armado. El ahorro es real, pero solo en ese rango de problema.

Dónde falla y por qué importa saberlo antes

El error más común es asumir que “el LLM entiende los datos”. No entiende tu negocio, entiende patrones de lenguaje. Esa diferencia importa cuando:

El volumen es masivo. Un dataset de 5 millones de filas enviado fila por fila a la API de un LLM puede costar entre 1,500 y 8,000 USD dependiendo del modelo y la longitud de los registros. Sin una estrategia de filtrado previo —procesar solo las filas que no matchean reglas simples— el costo escala sin control.

Las reglas son exactas, no aproximadas. Si tu campo “RFC” tiene errores de formato, un LLM puede intentar corregirlos, pero una función de validación determinista lo hace en microsegundos y sin costo por token. Los LLMs no son calculadoras: tienen una tasa de error que, aunque baja, es inaceptable para datos fiscales o identificadores únicos.

La latencia importa. Un pipeline de limpieza que corre overnight puede tolerar llamadas a API. Si necesitas limpiar datos en tiempo real dentro de un flujo transaccional, los LLMs externos introducen latencia y dependencia de disponibilidad de servicio.

El criterio que usamos en Eurema para decidir si vale la pena usar un LLM en limpieza es simple: ¿el problema tiene ambigüedad semántica que no se puede resolver con reglas explícitas? Si la respuesta es no, hay una solución más barata.

El modelo de costo real: cómo calcularlo antes de comprometerte

Antes de lanzar cualquier pipeline LLM sobre tus datos, estima el costo con esta fórmula básica:

Costo estimado = (filas a procesar) × (tokens promedio por fila) × (precio por token del modelo)

Ejemplo concreto con GPT-4o mini (uno de los modelos más económicos a julio 2025, ~$0.15 USD por millón de tokens de input):

• 100,000 filas
• 200 tokens promedio por fila (campo de texto + prompt de instrucción)
• 100,000 × 200 = 20,000,000 tokens
• Costo: ~3 USD

Parece barato. Pero si el dataset tiene 2 millones de filas y los registros son más largos, estás en 60–120 USD por ejecución. Si ese proceso corre diario, son 1,800–3,600 USD al mes solo en llamadas a API, sin contar infraestructura ni tiempo de ingeniería.

La estrategia que reduce ese costo entre 60–80%: filtrar primero con reglas baratas. Pasa por regex y validaciones deterministas todo lo que puedas resolver así. Solo envía al LLM las filas que fallaron esas reglas. En la mayoría de datasets B2B, entre el 15% y el 30% de los registros tienen ambigüedad real que justifica el LLM; el resto se limpia con lógica tradicional.

Arquitectura práctica: LLM como capa de excepción, no como pipeline principal

El patrón que funciona en producción no es “LLM limpia todos los datos”. Es:

1. Capa 1 — Reglas deterministas: validaciones de formato, regex, lookup tables. Resuelve el 70–85% de los casos. Costo: casi cero.
2. Capa 2 — LLM de bajo costo (GPT-4o mini, Claude Haiku): maneja los casos que pasaron la capa 1 sin resolver. Prompt corto, respuesta estructurada (JSON), temperatura 0.
3. Capa 3 — Revisión humana: los casos donde el LLM devolvió baja confianza o respuestas contradictorias. Puede ser el 2–5% del total.

Este diseño hace que el LLM procese solo la fracción del dataset donde realmente agrega valor. Lo hemos implementado en proyectos de Análisis de datos para empresas de retail e inmobiliario en Monterrey, y la diferencia en costo operativo mensual es significativa comparada con enviar todo al modelo.

Un detalle técnico que no es menor: pide siempre al LLM que devuelva su respuesta en JSON con un campo de confianza ("confidence": "high" | "medium" | "low"). Eso te permite automatizar la decisión de qué va a revisión humana sin leer cada registro.

Privacidad y datos sensibles: la pregunta que muchos omiten

Antes de enviar cualquier dataset a una API externa, revisa qué hay en esos datos. Un archivo de clientes con nombres, correos y RFCs es información personal identificable. Los principales proveedores (OpenAI, Anthropic, Google) ofrecen acuerdos de procesamiento de datos (DPA) bajo los cuales los datos no se usan para entrenar modelos, pero eso no elimina el riesgo de transmisión.

Las opciones para reducir el riesgo:

• Anonimizar antes de enviar: reemplaza nombres y datos personales con tokens antes de pasar el registro al LLM. Después mapea de regreso.
• Modelos locales: Llama 3, Mistral o Qwen corriendo en infraestructura propia procesan los datos sin salir de tu red. El costo de GPU se compara favorablemente con la API cuando el volumen es alto y constante.
• Procesamiento selectivo por campo: solo envía al LLM los campos que necesitan limpieza semántica (ej. “descripción del producto”), no toda la fila con datos del cliente.

Para industrias reguladas —salud, servicios financieros— la opción local no es opcional, es el único camino razonable.

Si estás evaluando si tu caso de uso justifica un pipeline así, el equipo de Análisis de datos de Eurema puede hacer una estimación de costo y complejidad con base en una muestra de tus datos reales, sin compromiso.