Los reportes hechos con IA tienen un problema: suenan igual de convincentes cuando aciertan que cuando inventan. Un número sin fuente, una tendencia que nadie midió, un competidor que no existe. Todo con el mismo tono seguro.
Así que me propuse construir un sistema de research que pudiera auditar.
Cómo está armado
Le escribo un pedido en lenguaje natural y un planificador arma un equipo a medida entre 16 especialistas. No convoca a todos, solo a los necesarios. Cada especialista busca en la web y en fuentes de datos, y escribe su parte.
Después revisan dos controles. Uno es un verificador que abre las fuentes y confirma cada dato: lo marca como verificado, corregido, estimación declarada o no verificado. El otro es un juez de calidad determinista que chequea si hicieron lo pedido y, si falta algo, da reintentos.
El reporte muestra un índice de confiabilidad: qué porcentaje de los datos se confirmó contra la fuente. Además, el sistema tiene memoria entre corridas. Está hecho en Python con CrewAI y Gemini, y una corrida promedio cuesta diez centavos de dólar.
El predictor que empataba con la regla más tonta
Como el sistema guardaba memoria, le agregué un predictor: mirando situaciones parecidas del pasado, estimaba hacia dónde iría el precio en los siguientes 7 días.
Pero antes de creerle lo probé contra 8 años de datos históricos, y el resultado fue incómodo: empataba con la regla más tonta posible, "el precio siempre sube". Toda esa complejidad no agregaba nada.
Cinco tesis que cayeron el mismo día
En agosto el sistema escribió cinco afirmaciones del tipo "Bitcoin se va a mantener en este rango durante el próximo mes". El 19 de agosto Bitcoin subió casi 8% y las cinco cayeron juntas.
Al investigar por qué se cayeron juntas encontré algo peor que un error de pronóstico: las tesis eran imposibles desde el principio. Medí 9 años de historia y una banda tan angosta nunca había aguantado 30 días. Ni una vez en más de 3.000 casos.
Lo más frustrante fue que el sistema ya tenía esa herramienta y no la usaba sobre sus propias afirmaciones.
Y había otro problema, más escondido. Las tesis de rango se estaban controlando de un solo lado, cuando pueden fallar tanto por arriba como por abajo. Eso inflaba el historial de aciertos en unos 30 puntos.
Cómo lo resolví
Cambié las reglas y le puse filtros exigentes al modelo:
- Al predictor le puse un filtro estadístico: solo habla si su ventaja es real, con menos de 1% de probabilidad de ser casualidad. Hoy casi nunca emite una predicción, y ese es el resultado honesto.
- Toda tesis tiene que pasar un filtro antes de escribirse: si históricamente tiene menos de 20% de chances de cumplirse, se rechaza.
- Corregí la evaluación de las tesis de rango para que controle los dos lados, arriba y abajo. Eso eliminó el sesgo en el historial de aciertos.
Un sistema con IA no es bueno porque suene inteligente, sino porque puede demostrar cuándo tiene razón y admitir cuándo no. La verificación, las pruebas contra datos reales y los filtros que le dicen "no" al modelo terminaron funcionando.
Lo que me llevo
El loop agéntico es importante para que los mismos LLMs y agentes se verifiquen entre sí y logren el objetivo.
El juez determinista y el verificador de fuentes son fundamentales a la hora de hacer scraping, porque no sabés si la información que traen es real. Comparar fuentes es importantísimo.
Y la parte más valiosa de un proyecto es la que te obliga a reconocer que te equivocaste. No hay que confiar en que el modelo suena convincente, sino armar filtros y pruebas con datos reales que le digan "no".