El problema fundamental que resuelve Vedder es la escalabilidad del conocimiento experto en dominios de datos complejos y vastos. En organizaciones con miles de datasets y petabytes de información, la demanda de insights supera la capacidad de los expertos humanos para responder consultas ad-hoc. Los Large Language Models (LLMs) por sí solos no son suficientes debido a las limitaciones de la ventana de contexto y la incapacidad de los esquemas de datos brutos para capturar la semántica de negocio, las peculiaridades históricas o las definiciones contextuales.
Vedder aborda esto mediante la introducción de una 'capa de contexto' curada por expertos de dominio. Esta capa actúa como un filtro y enriquecedor de información, proporcionando al LLM solo el subconjunto relevante y semánticamente enriquecido de datos necesario para una consulta específica. Este enfoque híbrido, que combina la capacidad generativa de los LLMs con la supervisión y curación humana, busca democratizar el acceso a los datos y escalar la 'expertise' sin comprometer la fiabilidad, un desafío recurrente en sistemas de información a gran escala donde la confianza en los resultados es crítica.
Arquitectura del Sistema
La arquitectura de Vedder se centra en el concepto de 'clusters', que son dominios de datos lógicos definidos y gestionados por equipos de expertos. Cada cluster encapsula tres componentes clave: Datasets, Pairs y Docs. Los Datasets incluyen los esquemas de las tablas relevantes del data warehouse, enriquecidos con metadatos como la cardinalidad de las columnas, muestras de valores comunes y estructura de particiones. Los Pairs son ejemplos curados de preguntas en lenguaje natural y sus correspondientes consultas SQL, que sirven como mecanismo de 'few-shot learning' para el LLM, enseñándole patrones de consulta y semántica de datos específicos del dominio. Finalmente, los Docs proporcionan contexto de negocio adicional, terminología, definiciones y 'gotchas' que no se infieren directamente de los esquemas.
Cuando un usuario formula una pregunta, el 'agente de datos' de Vedder utiliza un bucle ReAct (Reasoning and Acting) para interactuar con estos clusters. Primero, selecciona el cluster de contexto más apropiado. Luego, basándose en los Datasets, Pairs y Docs del cluster, el LLM genera una consulta SQL. Esta consulta se ejecuta contra el data warehouse, y el resultado se devuelve al usuario junto con la consulta generada y sus fuentes, promoviendo la transparencia. El sistema se integra en múltiples interfaces (Slack bot, MCP server, UI web) y mantiene un 'health score' para cada cluster, monitoreando la validez de los esquemas y los 'pairs' curados, y sugiriendo acciones a los expertos para mantener la relevancia del contexto. Cada interacción del usuario retroalimenta el sistema, permitiendo a los propietarios del cluster revisar y refinar el conocimiento.
Flujo de Consulta del Asistente de Datos
- 1 Usuario Formula una pregunta en lenguaje natural
- 2 Agente de Datos Recibe la pregunta y aplica el bucle ReAct
- 3 Capa de Contexto (Clusters) Identifica el cluster de dominio relevante (Datasets, Pairs, Docs)
- 4 LLM Genera consulta SQL basada en la pregunta y el contexto curado
- 5 Data Warehouse Ejecuta la consulta SQL generada
- 6 Agente de Datos Recibe resultados y los presenta al usuario junto con la SQL y fuentes
- 7 Sistema de Monitoreo Registra conversación y feedback para mejorar clusters
| Capa | Tecnología | Justificación |
|---|---|---|
| compute | Large Language Models (LLMs) | Núcleo generativo para interpretar preguntas en lenguaje natural y generar consultas SQL. Su capacidad se amplifica con el contexto curado. |
| data-processing | Data Warehouse | Almacenamiento y ejecución de consultas de datos a gran escala. Es el destino final de las consultas SQL generadas por el LLM. |
| orchestration | ReAct Framework | Orquesta el proceso de razonamiento y acción del agente de datos, permitiendo al LLM interactuar con herramientas externas (la capa de contexto y el data warehouse). |
| observability | Health Score System | Monitorea continuamente la validez y relevancia de los clusters de contexto, alertando a los expertos sobre la necesidad de curación. |
Trade-offs
Ganancias
- ▲ Fiabilidad de las respuestas del LLM
- ▲ Escalabilidad del conocimiento experto
- ▲ Accesibilidad de datos para usuarios no técnicos
Costes
- ▲ Esfuerzo de curación manual por expertos de dominio
- ▲ Tiempo de implementación inicial para construir la capa de contexto
Fundamentos Teóricos
El problema de la gestión del conocimiento y la inferencia contextual en sistemas de información ha sido un tema central en la investigación de bases de datos y sistemas de IA durante décadas. La necesidad de un 'contexto' semántico que vaya más allá de la estructura sintáctica de los datos se remonta a los trabajos sobre bases de datos semánticas y ontologías en los años 80 y 90, buscando capturar el significado inherente a los datos para mejorar la recuperación y la inferencia. El enfoque de Vedder de curar 'pairs' de preguntas-SQL y documentación de negocio resuena con los principios de 'knowledge representation' y 'expert systems', donde el conocimiento tácito de los expertos se codifica explícitamente para ser utilizado por sistemas automatizados.
La arquitectura ReAct, citada en el artículo, es un desarrollo más reciente en el campo de los LLMs, propuesto por Yao et al. (2022). ReAct combina 'reasoning' (generación de trazas de pensamiento) y 'acting' (interacción con herramientas externas) para mejorar la capacidad de los LLMs para resolver problemas complejos, particularmente aquellos que requieren acceso a información externa o ejecución de acciones. En el caso de Vedder, las 'herramientas' son el data warehouse y la capa de contexto curada, y el 'razonamiento' del LLM se guía por la información semántica proporcionada por los expertos, mitigando las alucinaciones y mejorando la fiabilidad de las respuestas generadas.