Documentación del TFG: Interconexión entre Espacios de Datos e Inteligencia Artificial Generativa

Fecha: 11/04/2025
Autor: Jaime Alonso Ruiz Tutor: Joaquín Salvachúa Título del TFG: Diseño e implementación de interconexión entre espacios de datos e inteligencia artificial generativa

Propósito del proyecto

El objetivo principal de este Trabajo de Fin de Grado es diseñar e implementar una arquitectura funcional y escalable que permita a un sistema multiagente (LLMs) interactuar entre sí mediante un protocolo estandarizado basado en el Google A2A (Agent to Agent), y con un espacio de datos utilizando el Model Context Protocol (MCP).
Los agentes no deben interactuar directamente entre sí ni acceder directamente a la base de datos, sino que todas las operaciones deben realizarse exclusivamente a través del Broker A2A-MCP, que actúa como Hub intermediario, seguro, modular y extensible.

Infraestructura actual

Se ha desplegado una infraestructura de contenedores basada en Docker Compose que incluye:

o Un servidor MCP que actúa como broker de mensajes A2A.

o Un agente LLM que genera consultas SQL a partir de preguntas en lenguaje natural.

o Un agente de ventas que ejecuta las consultas SQL sobre una base de datos en formato Iceberg y responde con los resultados.

• Cada componente ha sido diseñado de forma modular e independiente, con interfaces REST expuestas mediante FastAPI.

• Se ha utilizado DuckDB como motor de consultas para el backend en esta primera fase local.

• Espacio de datos
  • Implementado localmente usando DuckDB (lake.duckdb).
  • Contiene una tabla iceberg_space.ventas con las siguientes columnas:
    • fecha (DATE)
    • producto (TEXT)
    • cantidad (INTEGER)
    • precio (DOUBLE)
  • Los datos se cargan desde load_data.py.

Protocolo de comunicación A2A

• Se ha definido un protocolo de mensajes A2A basado en objetos JSON que siguen un esquema tipo:

{

  "message_id": "uuid",

    "sender": "agent_id",

    "recipient": "agent_id",

    "timestamp": "ISO8601",

    "type": "query" | "response",

    "body": {...}

  }

• El MCP almacena un registro en memoria de los agentes registrados, incluyendo su agent_id y su URL de callback.
• Los agentes se registran al inicio mediante un mensaje POST /agent/register. El agent_id puede ser fijo o generado aleatoriamente por el MCP si no se especifica.
• El agente LLM actúa como iniciador de las consultas, enviando mensajes query al agente de ventas.
• El agente de ventas responde con un mensaje response, incluyendo el resultado y un correlation_id para que el LLM pueda completar la consulta.

Agente LLM

• Se ha integrado el modelo de lenguaje TinyLlama (TinyLlama-1.1B-Chat-v1.0) de forma local usando transformers, para evitar dependencias externas.
• El agente LLM genera prompts contextualizados con metadatos obtenidos del MCP (productos y fechas disponibles), mediante el Modern Context Protocol (MCP), para generar SQL válido.
• También es responsable de convertir los resultados en lenguaje natural mediante un segundo prompt.
• El agente soporta un endpoint /query que acepta preguntas en lenguaje natural y coordina todo el ciclo de consulta y respuesta

Identificadores fijos y configuración

• Se han fijado los agent_id de ambos agentes mediante un fichero .env, y se ha corregido la configuración para que el contenedor ventas-agent lo importe correctamente.
• Se han introducido mejoras de robustez como:
• Esperas iniciales para resolución DNS y arranque del MCP.
• Retransmisiones exponenciales en caso de fallo de registro.
• Registro de logs detallado en cada componente.

Cliente de consola

Se ha creado un script CLI que permite interactuar con el sistema desde la terminal, enviando preguntas al LLM-Agent y mostrando en consola el SQL generado y la respuesta.

Principios y decisiones clave

• Separación estricta entre procesamiento semántico (LLM) y acceso a datos (MCP).
• Cumplimiento del diseño propuesto por MCP: los LLMs acceden a los datos solo a través de herramientas ("tools").
• Uso de prompts enriquecidos con información contextual previa obtenida del MCP.
• Cumplimiento de las especificaciones publicadas del Google A2A.
• Arquitectura modular, extensible y trazable mediante logs.

Plan de Trabajo Futuro

• Verificación funcional completa: Realizar pruebas de extremo a extremo entre el cliente CLI, el LLM-Agent, el broker MCP y el agente de ventas.

• Extensión al protocolo Google A2A: Adoptar elementos clave de la especificación Google A2A, incluyendo:

  • Identidad estructurada y metadatos del agente (Agent Card).
  • Soporte opcional de JSON-RPC 2.0.
  • Canal de eventos unidireccional (eventos push) con Server-Sent Events (SSE).

• Persistencia y auditoría:

  • Extensión del MCP para registrar mensajes y agentes en una base de datos (SQLite o PostgreSQL)..
  • Incorporación de IDs de conversación para trazabilidad.

• Documentación y despliegue local reproducible:

  • Redacción de README técnico con instrucciones paso a paso.
  • Scripts automáticos de puesta en marcha y pruebas.

Conclusión provisional

Hasta la fecha, se ha implementado de forma satisfactoria una arquitectura funcional basada en agentes cooperantes que utilizan lenguaje natural y SQL para consultar datos sobre un formato Iceberg. Se ha verificado la comunicación mediante un broker A2A minimalista, y el sistema ha demostrado ser modular, escalable y ampliable hacia futuros estándares de interoperabilidad como Google A2A.