Data Foundations: ¿cómo estructurar tus datos para los LLMs?
David Guede, Partner Data / IA y experto en Agentes de IA en Converteo, está especializado en el despliegue de arquitecturas de IA en producción. Asesora a las empresas en la industrialización de agentes inteligentes, transformando procesos de negocio complejos en verdaderas palancas de rendimiento y ventaja competitiva.
Ideas clave:
- Tus contenidos, fichas de producto y APIs se estructuraron pensando en humanos que navegan por una web. Cuando un LLM los lee para responder a un cliente, no están adaptados.
- Es un trabajo de fondo que arranca con una pregunta: ¿qué datos hay que reestructurar para que un LLM los explote correctamente?
Imagina la siguiente situación. Un equipo construye un agente de voz de calidad, sobre una plataforma moderna y con uno de los mejores modelos del mercado. En la demo, todo funciona a la perfección. Pasamos a la fase de validación y, de repente, en ciertos temas muy concretos, el agente falla la mitad de las veces.
La primera reacción es echarle la culpa al modelo. Es muy limitado. Los prompts son malos. Está mal configurado. A veces hay parte de verdad en esto. Pero la experiencia nos demuestra que, en la inmensa mayoría de los casos, el problema está en otro sitio: viene de los datos de entrada que le damos al modelo.
Esta anécdota viene del proyecto Sharlie en Orange. En las tarifas móviles que incluyen destinos como Marruecos o Suiza, el agente fallaba constantemente. Al investigar a fondo, el equipo no descubrió un fallo en el modelo. Descubrió que los datos que se le inyectaban estaban pensados para una página web y que se volvían ilegibles en cuanto se pasaban por un LLM.
Este es, probablemente, uno de los retos a más largo plazo que la IA generativa plantea a cualquier organización. Y uno de los que menos se habla.
Por qué tus datos no están hechos para los LLMs
A lo largo de los años, los contenidos de una empresa se han estructurado con un objetivo muy claro: mostrarse a humanos, a través de pantallas, dentro de customer journeys digitales. Y eso ha condicionado las decisiones estructurales.
Contenidos optimizados para el ojo humano. Una buena ficha de precios destaca la oferta más atractiva, jerarquiza visualmente la información a través del diseño y agrupa ciertas condiciones en un cuadro de “información útil”. Para un humano que mira la página, todo está claro. Para un LLM que recibe ese mismo contenido en forma de texto plano o vía API, la jerarquía visual desaparece y la información se mezcla por completo.
APIs diseñadas para aplicaciones, no para modelos. Una API que alimenta una página web suele devolver un bloque inmenso de información, estructurado para que el front-end pinte en pantalla lo que necesite. Para un desarrollador, es muy eficiente. Para un LLM, es una trampa: tiene que reconstruir el sentido a partir de un formato pensado para otra cosa.
Reglas de negocio implícitas. Muchos contenidos se basan en convenciones no escritas que todos en la empresa comparten. “Cuando decimos ‘internacional’, excluimos Europa”. “Cuando una condición no se menciona, se aplica por defecto”. Los agentes humanos aprenden estas normas tácitas con los años. Un LLM no las conoce y no las puede adivinar.
Si sumamos estos tres factores, se entiende perfectamente por qué un modelo, por muy potente que sea, puede equivocarse en preguntas concretas: hace correctamente lo que se le pide, pero basándose en una materia prima que jamás fue diseñada para él.
3 frentes de trabajo para estructurar tus datos para los LLMs
Se abren tres grandes frentes de trabajo.
- Repensar ciertas APIs para los LLMs. No se trata de tirarlo todo y empezar de cero. Consiste en identificar las APIs más críticas para los agentes conversacionales y añadirles una variante estructurada específica para que la consuma un modelo. Por ejemplo, una API que devuelve una tarifa móvil debería explicitar qué incluye, qué no incluye, en qué países y bajo qué condiciones, en un formato que el modelo pueda procesar directamente.
- Reestructurar los contenidos de negocio. Las fichas de producto, las políticas de pricing, los términos y condiciones… todo lo que sirva de base de conocimiento al agente debe reescribirse progresivamente con un doble enfoque (humano y máquina). Es un trabajo de fondo que impacta en los equipos de Contenidos, Producto y Atención al Cliente.
- Hacer explícitas las reglas implícitas. Todo lo que se transmite de boca en boca entre los asesores humanos, todo lo que “se sabe” en la compañía aunque no esté escrito, debe plasmarse negro sobre blanco para que un agente pueda explotarlo. Este ejercicio aporta un gran valor mucho más allá de la IA: a menudo saca a la luz incoherencias, reglas obsoletas o lagunas en la gestión del conocimiento.
Data foundations: un tema de gobernanza
Este frente de trabajo trasciende con creces a los equipos técnicos. Pone sobre la mesa la cuestión de la gobernanza del dato dentro de la empresa.
¿Quién es el responsable de la calidad de una ficha de producto orientada a un LLM? Hoy en día, por lo general, nadie. La ficha existe para la página web y punto. El día de mañana harán falta owners claros, capaces de mediar entre la versión “humana” y la versión “máquina” de un mismo contenido, garantizando que ambas mantengan la coherencia a lo largo del tiempo.
Esto también exige nuevos procesos. Cuando un producto cambia o evoluciona una condición de la tarifa, ¿cómo garantizamos que esa actualización se propaga a todas partes, incluyendo los componentes que explotan los agentes de IA? Sin ese proceso, iremos acumulando desviaciones silenciosas que, tarde o temprano, provocarán fallos en producción.
Este es uno de los retos a más largo plazo que la IA impone hoy a las grandes organizaciones, y exige transformar progresivamente la forma en que se estructuran y gobiernan los contenidos.
La buena noticia es que no hace falta hacerlo todo de golpe. Se puede empezar por los contenidos más consultados por los agentes en producción, medir el impacto y, a partir de ahí, escalar. La mala noticia es que es inevitable: mientras la materia prima no esté adaptada, ningún modelo, por excelente que sea, dará buen resultado. Y mientras no se asuma este trabajo, el agente de voz seguirá tocando techo… limitado por la calidad de sus datos, no por su tecnología.