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 desfasados antes de que los mires. Queríamos algo radicalmente más sencillo: 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 cuestión de segundos. El verdadero reto fue hacerlo lo suficientemente fiable para producción: 99,9% de uptime, p99 por debajo de 200ms, miles de consultas gestionadas cada día.

El problema

La mayoría de herramientas de datos blockchain asumen que sabes SQL o que te manejas bien con dashboards complejos. Eso funciona para analistas. Pero 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 tener que 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 completamente inventado. Las consultas pueden salir caras rápidamente si no las vigilas. Y la frescura importa más de lo que la gente cree: nadie quiere el precio de ayer cuando está tomando una decisión ahora mismo.

Así que el reto nunca fue construir una interfaz de chat. Era conseguir respuestas deterministas y verificables a partir de modelos probabilísticos, manteniendo la latencia baja y los costes bajo control.

El producto

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

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

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

En la parte de IA, aquí es donde el lenguaje natural se convierte en SQL. El controlador enruta entre GPT y Gemini dependiendo del tipo de consulta y las restricciones de coste. Las búsquedas simples van al modelo más barato. Los análisis complejos se dirigen 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 le 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 lugar de devolver basura.

La arquitectura

La lógica de reintentos gestiona los fallos del modelo de forma elegante. Si GPT devuelve algo malformado, hacemos fallback a Gemini. Si ambos fallan, devolvemos un error honesto en lugar de una respuesta errónea 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 el medio, la capa semántica que estandariza métricas entre cadenas y protocolos. Encima, 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 toda la cadena 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í

Los LLMs sin estructura son simplemente mentirosos con mucha seguridad. 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 realmente posible antes de intentar responder nada.

Dedicamos mucho esfuerzo inicial a perseguir frescura en tiempo real para todo antes de darnos cuenta de que era un desperdicio. No todo necesita estar actualizado al segundo. Averiguar qué datos sí lo necesitan y cuáles pueden permitirse un pequeño retraso nos ahorró costes de computación significativos sin que nadie notase 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 algo. Una respuesta errónea pero segura de sí misma destruye la confianza mucho más rápido que un sincero "No tengo esos datos." Construimos los guardrails no como restricciones, sino como una parte fundamental de lo que hace que el producto sea fiable.