Skip to main content
Antigravity 3.5 FlashTavilyRAG

Antigravity 3.5 Flash y Tavily: Conclusiones de las pruebas

Las primeras pruebas de usuarios de Antigravity 3.5 Flash elogian la modelo por su sólida planificación arquitectónica. Sin embargo, surgió otro problema: Tavily puede fallar en RAG, especialmente en búsquedas fuera del inglés. Esto afecta la automatización de IA porque el error suele estar en la búsqueda, no en la modelo.

Contexto técnico

Revisé los primeros comentarios reales sobre Antigravity 3.5 Flash y no me fijé en el entusiasmo, sino en un patrón: la modelo es elogiada justo donde las cosas suelen desmoronarse rápidamente: la planificación arquitectónica. Si esto se confirma en pruebas más amplias, es una fuerte señal para la implementación de IA: la modelo no solo autocompleta código, sino que mantiene la estructura del sistema en mente.

Según los datos disponibles, la situación no es blanco y negro. Google promueve 3.5 Flash como una clase agentic rápida con resultados sólidos en Terminal-Bench, MCP Atlas y tareas de uso de herramientas. Sin embargo, en SWE-Bench Pro, no parece ser la líder absoluta, y eso es normal: una cosa es diseñar el flujo de la solución y otra ganar consistentemente en rigurosas evaluaciones de ingeniería de software.

Y aquí está lo más interesante. En las discusiones, los usuarios elogian la modelo pero critican a Tavily: una consulta de búsqueda genérica suele extraer comunicados de prensa pulidos en lugar de pruebas de usuarios reales. He visto esto a menudo: si la capa de recuperación (retrieval) trae un comunicado de prensa en lugar de datos concretos, cualquier modelo inteligente parecerá un genio absoluto o completamente inútil.

Por otro lado, las quejas sobre búsquedas que no están en inglés no me sorprendieron. Para RAG, esto es un viejo problema: en ruso y otros idiomas, la búsqueda a menudo sufre de una menor recuperación, peor clasificación y atrae ruido en inglés con facilidad. Luego, la gente culpa al LLM, aunque el problema radica en la API de búsqueda.

Negocios y automatización

La conclusión práctica es sencilla: si Antigravity 3.5 Flash realmente mantiene la arquitectura tan bien, vale la pena explorarla para la automatización de IA, donde un agente debe planificar cadenas de acciones en lugar de solo charlar. Esto es especialmente cierto en escenarios de copilot internos, donde el costo de un error estructural es mucho mayor que el de una sola línea de código.

Pero no todos ganan aquí. Los que triunfan son los equipos que miden todo el stack: modelo, recuperación, reclasificación (reranking), idioma de consulta y costo de tokens. Los perdedores son aquellos que colocan un modelo de moda sobre una búsqueda frágil y luego se preguntan por qué su RAG miente con tanta seguridad y costo.

En Nahornyi AI Lab, resolvemos estas cosas en la práctica: no elegimos una modelo por un anuncio llamativo, sino que creamos una arquitectura de soluciones de IA funcional para procesos específicos. Si tu búsqueda ya genera ruido y el agente toma decisiones con mal contexto, analicemos este circuito y armemos una integración de IA para que el sistema ahorre tiempo y no consuma tu presupuesto en tokens y depuración.

Anteriormente, analizamos un caso similar de expectativas infladas con Codex 5.2, donde la falta de una arquitectura cuidadosa convirtió una demostración ruidosa en un mito. Esta experiencia muestra por qué al evaluar alternativas prometedoras siempre se deben estudiar sus limitaciones técnicas.

Compartir este articulo