Cómo las consultas SQL rígidas están alimentando tus alucinaciones con la IA

Integras una IA moderna en tu sistema ERP antiguo esperando milagros. En cambio, te miente descaradamente. ¿El verdadero problema? Sigues consultando registros históricos como si estuviéramos en 2005.

Como consultor de ERP, leo sobre estos escenarios constantemente. Los ejecutivos se apresuran a integrar la IA generativa en los sistemas empresariales, con la esperanza de obtener información conversacional instantánea. Utilizan grandes modelos de lenguaje en antiguos repositorios de datos y esperan los resultados.

Pero este enfoque suele fracasar en el momento en que se pone un pie en la planta de producción.

Si intentas extraer el significado semántico utilizando métodos rígidos basados ​​en palabras clave para alimentar una IA moderna, prácticamente estás pidiendo a gritos que te dé alucinaciones.

Analicemos cómo consultamos los datos empresariales hoy en día y hacia dónde se dirigen realmente las arquitecturas preparadas para la IA. Si nos equivocamos ahora, nuestra estrategia de IA se verá seriamente comprometida.

Las limitaciones de las consultas ERP tradicionales

Las bases de datos en sistemas como Infor LN son excepcionales en lo que realmente hacen: precisión e integridad transaccional.

Están diseñadas para ejecutar reglas específicas de forma rápida y sin errores. Si sabe exactamente lo que busca, SQL clásico es perfecto. Cuando necesita el estado exacto de una orden de producción específica, una simple instrucción SQL es suficiente. Acceda a la tabla tisfc001, asigne las claves primarias y recupere el registro exacto sin ambigüedad.

Pero el análisis histórico rara vez es tan preciso.

Cuando un gerente de la cadena de suministro pregunta: "¿Por qué nos retrasamos constantemente con esta línea de productos en particular?", una consulta SQL estándar no puede responder directamente. Requiere la combinación manual de cinco módulos diferentes de compras, almacenamiento y producción. Y lo que es más importante, requiere interpretar notas no estructuradas dejadas por distintas personas en diferentes departamentos.

Imagina investigar una falla recurrente en una máquina y analizar defectos de calidad. Escribes una consulta SQL estándar que busca WHERE description LIKE '%overheating%'. Tu base de datos heredada devolverá obedientemente solo coincidencias exactas.

¿Qué le falta? Todo lo demás. Ignora por completo los registros críticos donde un operario apresurado escribió " alta temperatura", "sobrecalentamiento" o "componentes que se queman" al final de su turno.

El SQL tradicional carece de comprensión semántica. Solo reconoce caracteres rígidos. Al introducir estos resultados incompletos y filtrados por palabras clave en una IA, el modelo extrae conclusiones basadas en una realidad fragmentada. Es precisamente ahí donde se pierden las ideas de negocio.

La ventaja semántica

Si necesita analizar datos históricos en busca de correlaciones poco claras, una base de datos vectorial ofrece una clara ventaja estructural.

La vectorización de datos traduce el texto escrito a mano en coordenadas numéricas llamadas incrustaciones. Esto agrupa los datos según su contexto y significado matemático. Una incrustación se puede comparar con una coordenada GPS para un concepto específico.

En lugar de hacer coincidir letras, la base de datos hace coincidir el significado subyacente. Si un planificador escribe " retrasado por el proveedor" y un operario de almacén registra " esperando piezas", una consulta SQL clásica ve dos problemas no relacionados. Una base de datos vectorizada reconoce que se trata exactamente del mismo problema.

En una base de datos vectorizada, los términos sobrecalentamiento y alta temperatura se colocan matemáticamente uno al lado del otro.

Al transferir sus datos transaccionales a una base de datos con capacidad vectorial como Google AlloyDB, deja de comparar cadenas de texto y comienza a comparar significados. Esto generalmente utiliza flujos de datos para transferirlos de forma segura fuera del núcleo del ERP.

Podrás consultar años de datos históricos utilizando lenguaje natural. El sistema comprende la intención. Los usuarios ya no necesitan memorizar sintaxis SQL complejas, navegar por tablas poco claras ni adivinar abreviaturas antiguas.

La arquitectura adecuada para empezar: RAG y aislamiento del núcleo

Es posible que sientas la tentación de aplicar la IA generativa directamente a tu ERP transaccional. No lo hagas. Si lo haces, el rendimiento operativo se verá seriamente afectado y podrías bloquear tu sistema principal.

Los sistemas de gestión de información de mantenimiento (LLM) son increíblemente pesados. Si se utiliza una IA conversacional directamente con las tablas de transacciones en tiempo real, se paralizarán las operaciones diarias. El empleado del almacén que intenta enviar un camión cargado de mercancías no debería tener que esperar a que el sistema responda porque un ejecutivo le está pidiendo a la IA que analice diez años de datos de mantenimiento.

La solución moderna se basa en la Generación Aumentada por Recuperación (RAG) y el aislamiento del núcleo. Un ejemplo clave es la transición de Infor desde su sistema Coleman ML heredado. Actualmente, utilizan LangChain para crear agentes capaces de realizar un razonamiento semántico profundo, con una sólida base en la lógica empresarial.

El flujo de trabajo RAG generalmente sigue estos pasos operativos:

• Descarga de datos: Transfiere los datos del ERP fuera del núcleo transaccional. Mediante herramientas como Infor Data Fabric, transfiere estos datos a tu base de datos vectorial. Esto permite que tu sistema principal funcione sin problemas.
• Recuperación: El usuario formula una pregunta en lenguaje natural. La base de datos vectorial AlloyDB realiza una búsqueda de alta velocidad para encontrar registros históricos conceptualmente relevantes.
• Extracción: Solo estos registros válidos se envían como contexto de verdad a un modelo de lenguaje externo de gran escala como Vertex AI. El modelo procesa esta información y genera una respuesta precisa sin necesidad de interactuar con el sistema ERP en tiempo real.

Este flujo de trabajo RAG es la base correcta para cualquier iniciativa de IA empresarial en la actualidad. Pero considérelo como un punto de partida, no como un destino.

La industria ya está avanzando hacia la búsqueda agencial: arquitecturas donde la IA no realiza una única búsqueda semántica estática, sino que decide de forma autónoma cómo y dónde buscar. Alterna entre múltiples estrategias de recuperación (búsqueda vectorial, consultas estructuradas, sistemas de archivos, grafos de conocimiento) en función de la complejidad de la pregunta.

Andrej Karpathy llamó recientemente la atención sobre un patrón similar: la wiki de LLM. Un agente de IA precompila datos fuente sin procesar en una base de conocimiento estructurada e interconectada. En lugar de recuperar fragmentos de texto cada vez, el agente consulta un artefacto limpio y organizado que ya ha creado, acumulando inteligencia con el tiempo.

En la mayoría de los entornos ERP actuales, una canalización RAG bien diseñada es la opción correcta. Sin embargo, las limitaciones de la ventana de contexto que hicieron obligatoria la segmentación vectorial se están reduciendo rápidamente. Si diseña su arquitectura sin una vía de transición hacia patrones basados ​​en agentes, tendrá que actualizarla de nuevo en dieciocho meses.

Cómo acabar con las alucinaciones

Una alucinación de IA se produce cuando un modelo de lógica descriptiva genera un resultado fluido y persuasivo, pero objetivamente absurdo. Estos modelos no «conocen» los hechos; simplemente predicen probabilidades basándose en su arquitectura subyacente.

En entornos industriales complejos, una alucinación representa un fallo crítico. La IA podría inventar con confianza un programa de mantenimiento que se ajuste a un patrón estadístico, pero que no exista en la realidad. Podría sugerir el pedido de piezas que se dejaron de fabricar hace una década simplemente porque aparecían con frecuencia en registros antiguos.

No podemos eliminar matemáticamente las alucinaciones, pero debemos reducirlas hasta que sean estadísticamente irrelevantes. Estas son las reglas estrictas que debes aplicar:

• Requerir una vinculación estricta: Obligue al LLM a depender exclusivamente del contexto RAG proporcionado por su base de datos de vectores. Bloquee explícitamente su conocimiento de Internet preentrenado para imponer una vinculación empresarial.
• Implementar temperatura cero: Establezca la temperatura del modelo en cero. Elimine la creatividad de la IA para garantizar resultados deterministas y altamente repetibles. Buscamos precisión quirúrgica, no creatividad.
• Implementar una alternativa obligatoria: mediante una ingeniería de indicaciones rigurosa, obligar al LLM a indicar " Datos no encontrados" si la respuesta depende de datos fuera del contexto recuperado.
• Priorice la calidad de los datos: Esta arquitectura avanzada no sirve de nada si sus datos de origen son basura. Los datos del ERP que ingresan a la base de datos vectorial deben estar limpios y normalizados.

Información práctica para líderes de TI

Dejen de dejarse llevar por la publicidad engañosa. Comprar una licencia de IA no soluciona una arquitectura empresarial deficiente. Si su ERP es un caos de soluciones improvisadas y desorganizadas, alimentarlo con una IA solo automatizará la confusión.

Combina la precisión transaccional de tu ERP con la comprensión semántica de una base de datos vectorial y, finalmente, lograrás que la IA deje de adivinar.

Antes de adquirir herramientas de IA, comience por evaluar el nivel de madurez de sus datos. Analice cómo sus usuarios registran actualmente los problemas y si esas descripciones están lo suficientemente estandarizadas como para poder vectorizarlas eficazmente.

A continuación, evalúe las bases de datos vectoriales para el análisis histórico. Defina sus intenciones de consulta y, sobre todo, proteja su sistema central mediante una arquitectura RAG desacoplada. Finalmente, diseñe con una vía de salida. Construya su capa de recuperación como un componente modular, no como un monolito. Cuando los patrones basados ​​en agentes maduren para su uso empresarial, podrá intercambiar o extender su estrategia de recuperación sin tener que reconstruir todo desde cero.

Si su sistema ERP todavía tiene problemas para proporcionar datos básicos y limpios, añadirle una IA semántica solo hará que falle más rápidamente.

Si tu base de datos es deficiente, la IA solo generará confusión a gran escala. Soluciona los problemas de arquitectura antes de adquirir la licencia.

Escrito por Andrea Guaccio 

5 de mayo de 2026