Orca Security y AWS han presentado Discovery AI, un agente de IA con Amazon Bedrock que traduce preguntas en lenguaje natural a consultas Sonar, el sistema con el que Orca interroga más de 900 modelos de recursos cloud. El dato que lo hace interesante no es que funcione, sino cómo pasó de un prototipo inviable a uno que responde en unos 15 segundos a miles de consultas diarias, con un 90 % menos de coste. Es una lección de arquitectura útil para cualquiera que esté montando algo parecido.
Qué ha pasado: un agente de IA con Amazon Bedrock que sí llega a producción
Discovery AI permite que un usuario pregunte en lenguaje natural por el estado de su infraestructura cloud y reciba una consulta Sonar ya construida. Sonar es el lenguaje de consulta de Orca y se apoya en un esquema enorme: más de 900 modelos de recursos. Esa amplitud es justo lo que complicó el proyecto. Para que un modelo de lenguaje escriba una consulta correcta necesita conocer el esquema, y aquí el esquema es muy grande.
La prueba de concepto inicial siguió el camino más directo: meter todo el esquema en un único prompt. Funcionó como demostración, pero los números la descartaron para producción. Cada workload requería unos 2 millones de tokens de entrada y unos 60 segundos de procesamiento. Con esas cifras, ni el coste ni la espera son asumibles para una herramienta que debe atender consultas todos los días y a escala.
La versión final cambia el enfoque. Orca ha construido una arquitectura híbrida que combina RAG con construcción de consultas basada en el esquema, y asigna a cada fase del pipeline el modelo de Bedrock más adecuado. Según el caso publicado, el resultado es una reducción del 90 % en el coste de las consultas, del 93 % en los tokens de entrada y del 75 % en la latencia, con respuestas de unos 15 segundos.
Por qué importa el agente de IA con Amazon Bedrock de Orca: menos contexto, mejor pipeline
La primera conclusión técnica es incómoda para quien confía en las ventanas de contexto largas: que algo quepa en el prompt no significa que convenga enviarlo. Mandar el esquema completo en cada petición funciona en pruebas, pero penaliza el coste y el tiempo de respuesta de forma lineal con el tamaño del esquema. Orca ha pasado de enviar todo a recuperar solo lo relevante, y ese cambio explica buena parte del 93 % de ahorro en tokens de entrada.
La segunda es la asignación de modelos por fase. En lugar de usar un único modelo para todo el flujo, Orca elige dentro de Bedrock el más adecuado para cada paso del pipeline. Es una decisión de ingeniería sensata: no todas las fases exigen la misma capacidad, y pagar el modelo más potente en tareas que no lo necesitan encarece el sistema sin mejorar el resultado. Bedrock facilita este enfoque porque ofrece varios modelos bajo una misma plataforma.
La tercera lección es la construcción de consultas guiada por el esquema. Al generar una consulta Sonar, el sistema no depende solo de que el modelo «recuerde» cómo se escribe: se apoya en la estructura real de los modelos de recursos. Eso reduce la superficie de error en un lenguaje de consulta propio, que ningún LLM ha visto en su entrenamiento con la misma profusión que SQL.
Conviene ser prudente con las cifras. Son resultados que comunica la propia empresa sobre su sistema, en su entorno y con su esquema. Sirven como orden de magnitud y como argumento para revisar una arquitectura, no como garantía de que cualquier proyecto vaya a reproducir un 90 % de ahorro.
Cómo pueden aplicar esto las empresas hoy
Orca es un proveedor de seguridad cloud con un esquema de 900 modelos, y la mayoría de las PYMEs no tienen algo así. Pero el patrón sí es trasladable a cualquier empresa que quiera dejar consultar datos propios en lenguaje natural: un ERP, un CRM, un almacén de datos o un sistema de tickets con muchas tablas y campos.
Lo primero es medir antes de optimizar. Si ya tenéis un prototipo que mete toda la documentación o todo el esquema en el prompt, calculad cuántos tokens de entrada consume por consulta y cuánto tarda. Con esos dos números sabréis si el prototipo es viable o si, como el de Orca, solo vale para la demo.
Lo segundo es separar el problema en fases. Recuperar la información relevante del esquema, construir la consulta y validar el resultado son tareas distintas, y no todas necesitan el mismo modelo. Probad modelos más ligeros en las fases sencillas y reservad el más capaz para donde de verdad marque diferencia.
Lo tercero es qué evitar: no empecéis por la arquitectura más sofisticada si vuestro esquema tiene diez tablas. Con un esquema pequeño, cargarlo entero en el prompt puede ser razonable y mucho más barato de mantener que un pipeline con RAG. La complejidad solo compensa cuando el volumen de consultas y el tamaño del esquema la justifican. Y fijad un objetivo de latencia antes de empezar: los 15 segundos de Orca son aceptables para su caso, pero pueden no serlo para un usuario que espera una respuesta inmediata.
Análisis Blixel
El error más habitual en proyectos de IA generativa es confundir una demo que funciona con un producto que se sostiene. Orca lo ilustra bien: su prueba de concepto daba respuestas, pero con 2 millones de tokens y 60 segundos por workload nadie la habría puesto delante de un cliente. El trabajo valioso llegó después, y no consistió en cambiar a un modelo mejor, sino en rediseñar el flujo para que el modelo reciba menos y más relevante.
Esa es la parte que conviene subrayar. Se habla mucho de modelos con contextos cada vez más largos, y se habla poco de que cada token de entrada se paga y se espera. Un buen agente de IA con Amazon Bedrock, o con cualquier otra plataforma, se define más por la disciplina con que gestiona el contexto que por el modelo que hay detrás.
Dicho esto, no vendamos humo: el caso lo cuenta quien lo ha construido, las métricas son suyas y el esquema de 900 modelos de recursos es una condición muy particular. Para una PYME, la enseñanza no es copiar la arquitectura, sino adoptar el método: medir tokens y latencia desde el primer prototipo, dividir el flujo en fases y asignar a cada una el modelo que toca.
Mi posición es clara: la ventaja competitiva en agentes de consulta ya no está en acceder a un LLM potente, que está al alcance de todos, sino en la ingeniería que rodea al modelo. Quien trate el coste por consulta como un requisito de diseño, y no como una sorpresa de la factura, llegará a producción antes y con menos sobresaltos.
¿Quieres aplicar esto en tu empresa? En Blixel.ai te ayudamos a integrar IA con sentido común. Hablemos.