NumiaAI

Los datos blockchain son difíciles de manejar. Dashboards que van a paso de tortuga, consultas SQL que se rompen cada vez que una cadena se actualiza, snapshots cacheados que ya están obsoletos antes de mirarlos. Queríamos algo radicalmente más simple: hacer una pregunta en lenguaje natural y obtener una respuesta real a partir de datos on-chain en vivo. Sin batching, sin esperas. Así que lo construimos.

NumiaAI se lanzó en colaboración con dYdX y ahora da servicio a protocolos e instituciones que quieren respuestas, no dashboards. Puedes preguntar "¿Cuál es el TVL actual en Osmosis?" o "Muéstrame las operaciones más grandes en dYdX en la última hora" y obtener datos en vivo en segundos. El verdadero reto fue hacerlo suficientemente fiable para producción: 99,9% de uptime, p99 por debajo de 200ms, miles de consultas al día.

El problema

La mayoría de herramientas de datos blockchain dan por hecho que sabes SQL o que te manejas con dashboards complejos. Para analistas funciona. Se desmorona cuando un gestor de fondos solo necesita una comprobación rápida, o cuando un equipo de protocolo quiere vigilar sus métricas sin contratar a un ingeniero de datos.

Conectar LLMs a datos financieros en vivo es arriesgado de formas que la gente subestima. Los modelos alucinan. "El precio actual de ATOM es 47,32 $" suena perfectamente convincente incluso cuando es pura invención. Las consultas se encarecen rápido si no las vigilas. Y la frescura importa más de lo que parece: nadie quiere el precio de ayer cuando está tomando una decisión ahora mismo.

El reto nunca fue construir una interfaz de chat. Era sacar respuestas deterministas y verificables de modelos probabilísticos, manteniendo la latencia baja y los costes controlados.

El producto

Diseñamos y construimos la infraestructura de datos y el controlador de IA desde cero. Tres capas que trabajan juntas: pipelines de datos en vivo, una capa semántica para garantizar consistencia, y un controlador de IA con guardrails de verdad.

El warehouse en BigQuery corre con ingesta continua desde múltiples cadenas Cosmos. La clave estaba en encontrar el equilibrio justo entre frescura y coste. Los datos de precio tienen que estar al momento. El volumen histórico puede permitirse un pequeño retraso. Definimos SLAs de frescura por tipo de tabla para no quemar dinero actualizando en tiempo real datos que no lo necesitan.

DBT se encarga de todas las transformaciones. Tablas pre-agregadas para consultas habituales mantienen las lecturas por debajo de 200ms. La capa semántica estandariza definiciones entre protocolos para que TVL signifique lo mismo tanto si preguntas por Osmosis como por dYdX. Suena obvio, pero conseguir que funcionase bien llevó mucho más trabajo del esperado.

En la parte de IA es donde el lenguaje natural se convierte en SQL. El controlador enruta entre GPT y Gemini según el tipo de consulta y las restricciones de coste. Las búsquedas simples van al modelo más barato. Los análisis complejos se derivan al más potente.

Los esquemas de prompts restringen el formato de salida de forma estricta. El modelo no puede alucinar libremente con datos financieros porque lo obligamos a devolver consultas estructuradas que validamos antes de ejecutar nada. Si una consulta no tiene sentido (preguntar por una cadena que no indexamos o pedir datos que no existen), se rechaza con una explicación clara en vez de devolver basura.

La arquitectura

La lógica de reintentos gestiona los fallos del modelo con elegancia. Si GPT devuelve algo malformado, hacemos fallback a Gemini. Si ambos fallan, devolvemos un error honesto en lugar de una respuesta incorrecta pero segura de sí misma. En producción, la fiabilidad siempre gana al optimismo.

El sistema tiene tres capas. En la base, BigQuery con ingesta continua y transformaciones DBT. En medio, la capa semántica que estandariza métricas entre cadenas y protocolos. Arriba, el controlador de IA que recibe lenguaje natural, genera SQL validado, enruta entre modelos y devuelve respuestas estructuradas.

Todo corre en GCP. La capa de datos se refresca según SLAs por tabla. La capa de IA es stateless y escala horizontalmente. La monitorización cubre todo el camino: desde el lag de ingesta hasta el tiempo de respuesta del modelo y la latencia de cara al usuario.

Resultados

El sistema lleva funcionando en producción desde el lanzamiento con dYdX:

• 99,9% de uptime desde el lanzamiento
• p99 de latencia por debajo de 200ms en consultas respaldadas por IA
• Miles de consultas procesadas a diario
• Adoptado por protocolos como dYdX y equipos de datos institucionales

Lo que aprendí

Sin estructura, los LLMs son simplemente mentirosos con mucho aplomo. Apunta un modelo de lenguaje a datos blockchain en bruto y se inventará cosas sin pestañear. La capa semántica es lo que hace que todo funcione: métricas definidas, esquemas validados, salidas restringidas. El modelo necesita saber qué es posible antes de intentar responder.

Dedicamos mucho esfuerzo inicial a perseguir frescura en tiempo real para todo, hasta que nos dimos cuenta de que era un desperdicio. No todo necesita estar actualizado al segundo. Descubrir qué datos sí lo necesitan y cuáles pueden permitirse un pequeño desfase nos ahorró costes de cómputo significativos sin que nadie notase la diferencia.

La decisión de diseño más infravalorada fue enseñar al sistema a decir "no lo sé". Los usuarios confían en él porque les dice con honestidad cuándo no puede responder. Una respuesta incorrecta pero segura de sí misma destruye la confianza mucho más rápido que un sincero "no tengo esos datos". Los guardrails no los construimos como restricciones, sino como parte esencial de lo que hace fiable al producto.