Las tablas que no existían

Capítulo 2 — Las tablas que no existían

Un técnico de una empresa mecánica del Nordeste nos lo contó frente a un espresso, con esa calma veneciana que presagia un desastre: "Nuestro chatbot sabía todo sobre el motor. Excepto los datos del motor." Luego explicó. Su asistente de IA interno sabía describir las gamas de producto, los contextos de uso, la historia de la marca, las ventajas competitivas. Una maravilla, en el plano narrativo. Pero cuando un cliente preguntaba el par nominal del modelo CMP50L — es decir, el dato técnico por el que la gente abre el catálogo, el número por el que se compra un motor — el chatbot respondía de forma vaga, a veces plausible, a veces no. Cinco meses de desarrollo, el director operativo cada vez más perplejo, y nadie que supiera decir el porqué.

El diagnóstico llegó por casualidad, casi por aburrimiento, inspeccionando manualmente la base de datos después de la enésima reunión sin conclusión. El catálogo PDF contenía 342 tablas técnicas. En la base de datos habían llegado cero. No unas pocas: cero. Ninguna. El código que extraía las tablas de los PDF guardaba los datos en campos llamados columns y data, mientras que el código que luego las indexaba esperaba campos llamados headers y rows. Un "sinónimo" no respetado. Una convención interna que se había saltado en un refactoring olvidado. El resultado, durante cinco meses silenciosos: toda la inteligencia numérica del catálogo — pares, potencias, diámetros, pesos, códigos de pedido, tensiones de alimentación — había salido del grifo sin ser nunca vertida en el vaso. Trescientos cuarenta y dos tablas, perdidas una por una en silencio litúrgico.

Este es el tipo de error que no grita. No genera excepciones, no hace que nada se bloquee, no aparece en ningún registro. Simplemente, una parte del mundo deja de existir para su sistema, y nadie se da cuenta hasta que un usuario —normalmente un usuario enfadado— hace suficientes preguntas persistentes como para mostrar el abismo. Y es emblemático de un problema mucho mayor que los nombres de los campos: los frameworks RAG genéricos están optimizados para el texto corriente —artículos, páginas web, párrafos de narrativa— y tratan las tablas como ciudadanos de segunda clase, cuando las tratan. Pero los documentos empresariales italianos son a menudo tablas. Catálogos técnicos, listas de precios, especificaciones de producto, fichas de seguridad, boletines de pedido: la parte valiosa, para quien consulta estos documentos, es la tabular. La que se rompe primero y de la que nadie se da cuenta.

La lección no es "ten cuidado con los nombres de los campos". Es más incómoda: en un RAG serio, cada tipo de contenido — tablas, imágenes, códigos alfanuméricos, títulos de párrafo, notas al pie de página — necesita un tratamiento dedicado, diseñado, probado. Y la prueba de funcionamiento no es "el chatbot responde a preguntas banales" — a esas responden también los sistemas rotos, porque hay suficientes datos flotantes para construir algo de plausibilidad. La prueba verdadera es "el chatbot responde a preguntas que lo obligan a tocar cada pieza de la canalización". Preguntas específicas, numéricas, verificables. Preguntas para las que existe una respuesta correcta y una sola, y si el sistema se equivoca lo sabes inmediatamente.

Si no haces esta prueba, no sabes si tu RAG funciona. Solo sabes que no se queja. Y "no se queja" es un criterio de calidad muy bajo para un sistema que las personas usarán para tomar decisiones.