La pila completa de IA agente, capa por capa: desde el frontend hasta la observabilidad.
Diez capas detrás de un agente de producción: frontend, ingestión, particionamiento, embeddings, búsqueda vectorial, recuperación, generación de prompts, el LLM, despliegue y evaluación.
Fuentes: The Full Stack of Agentic AI: From User Interface to Production-Grade Intelligence
La inteligencia artificial ya hace tiempo que superó la etapa en la que alguien escribe una solicitud y lee una respuesta. Los productos de IA modernos son sistemas de software completos. Reciben documentos, convierten material desorganizado y caótico en conocimiento utilizable, generan embeddings, recuperan contexto, interactúan con modelos de lenguaje grandes, ejecutan herramientas, operan dentro de la infraestructura en la nube y vigilan su propio rendimiento. Esto es doblemente cierto en el caso de la IA agente. Un agente no es un modelo de lenguaje grande atrapado dentro de una ventana de chat. Una aplicación agente de nivel profesional necesita toda una pila tecnológica alrededor del modelo, y el modelo es solo una de sus capas.
Un diagrama de arquitectura de referencia de esa pila sirve como mapa útil, que abarca desde la interfaz de usuario pasando por la ingesta, la recuperación y la formulación de solicitudes hasta los modelos, el despliegue y la supervisión. Las secciones siguientes explican cada capa, su función, el motivo de su existencia y cómo se integran las herramientas entre sí.
Un vistazo a las capas
En orden, el stack funciona de la siguiente manera: frontend, ingestión de documentos, particionamiento y preprocesamiento, embeddings, base de datos vectorial, recuperación de información, ingeniería de prompts, LLM, infraestructura e implementación, y finalmente, capacidad de observabilidad y evaluación.
Esa secuencia no constituye un flujo estricto. En los sistemas agentes reales, las distintas partes interactúan constantemente. Un agente puede recuperar información varias veces, llamar a herramientas externas, invocar modelos diferentes, calificar sus propias respuestas y activar flujos de trabajo adicionales antes de producir un resultado final. Es mejor considerar este stack como el ecosistema tecnológico que rodea a la inteligencia que como una simple cadena de solicitud-respuesta.
Capa 1: el frontend
Cada sistema de IA necesita un lugar donde las personas puedan interactuar con él. La interfaz frontal presenta la experiencia, ya sea a través de un chatbot, un portal empresarial, un panel de análisis, una herramienta interna o un espacio de trabajo asistido por IA. Las opciones tecnológicas típicas incluyen React, Next.js, Streamlit y Azure App Service. React permite crear interfaces interactivas, mientras que Next.js es un framework más completo para aplicaciones web en producción. Streamlit resulta útil para desarrollar rápidamente aplicaciones de IA y de datos sin necesidad de una cadena de herramientas de interfaz frontal tradicional. Azure App Service ofrece hosting gestionado para aplicaciones web y APIs.
En una configuración empresarial basada en agentes, la interfaz frontal es algo más que un cuadro de chat. Puede mostrar el progreso del agente, las fuentes de información consultadas, el estado del flujo de trabajo, los resultados de las herramientas, las solicitudes de aprobación, los documentos generados y las interacciones con intervención humana. Es allí donde la IA se vuelve accesible para los usuarios empresariales.
Capa 2: ingestión de documentos
Un sistema eficaz necesita acceso a información relevante, y el conocimiento corporativo rara vez se encuentra en un formato ordenado. Está disperso en PDF, archivos de Word, presentaciones, escaneos, páginas web, bases de datos, correos electrónicos y mucho más. La ingestión permite recopilar y extraer contenido de todos estos recursos.
Las herramientas utilizadas para esta tarea son Azure AI Content Understanding, Apache Tika, Microsoft Fabric, LangChain y motores OCR. El OCR es importante cuando la información se encuentra dentro de escaneos o imágenes. Apache Tika extrae texto y metadatos de una amplia variedad de formatos. Microsoft Fabric contribuye a flujos de trabajo de datos empresariales más amplios, y un framework como LangChain puede conectar los componentes de ingestión con las pipelines de inteligencia artificial.
El objetivo es sencillo: convertir la información empresarial dispersa en contenido que una máquina pueda procesar. Sin una capa de ingestión fiable, incluso el modelo más sofisticado tendrá dificultades para ofrecer respuestas significativas sobre su organización.
Capa 3: fragmentación y preprocesamiento
Extraer texto es solo el comienzo. Un documento de 200 páginas no puede enviarse completo en cada solicitud al modelo, por lo que los documentos grandes deben dividirse en unidades más pequeñas y significativas. Esos fragmentos pueden ser párrafos, secciones, páginas o unidades semánticas, y LangChain y marcos de trabajo similares ofrecen varias estrategias de fragmentación.
Un buen particionamiento va más allá de dividir el texto cada pocos cientos de caracteres, ya que un mal particionamiento destruye el contexto. Cuando una definición se separa de la explicación que le da significado, la recuperación puede devolver información incompleta. Los fragmentos demasiado grandes hacen que la recuperación sea imprecisa, mientras que los fragmentos demasiado pequeños pierden relaciones importantes. Por lo tanto, esta estrategia afecta directamente la calidad de todo lo que sigue.
El preprocesamiento incluye tareas como la limpieza, eliminación de contenido no necesario, normalización de formatos, extracción de metadatos, detección de la estructura del documento y enriquecimiento de los fragmentos con información adicional. El rendimiento posterior de la recuperación a menudo se decide aquí mismo.
Capa 4: embeddings
Una vez que los documentos están particionados, el sistema necesita una forma de capturar su significado. Un modelo de embeddings convierte el texto en un vector numérico, de modo que los conceptos similares terminan cerca uno del otro en el espacio de embeddings.
Compare una solicitud para restablecer la contraseña de un empleado con una que pregunta cómo cambiar los detalles de inicio de sesión laboral. La redacción es diferente, pero la intención es similar, y un buen modelo de embedding lo reconoce. Los proveedores mostrados para esta capa incluyen OpenAI, Cohere y servicios de IA basados en Azure. Los vectores resultantes sirven de base para la búsqueda y recuperación semántica, lo que convierte esto en una de las transiciones más importantes en esta estructura: el lenguaje humano se convierte en una representación matemática, y dicha representación permite la similitud semántica.
Capa 5: la base de datos de vectores
Los embeddings deben almacenarse en un lugar que permita una búsqueda rápida de similitudes, y esa es la función de la base de datos de vectores. El diagrama enumera Milvus, FAISS, Azure AI Search, Azure Cosmos DB y Azure Database for PostgreSQL. Diferen mucho en capacidades y modelo de implementación, pero todos tienen como objetivo una recuperación eficiente mediante similitud semántica.
Cuando un usuario hace una pregunta, la consulta se convierte ella misma en un embedding, y el sistema busca los vectores más cercanos. Los fragmentos que coinciden se pasan luego a las capas siguientes. Esta es la base de la mayoría de los sistemas de generación reforzada por recuperación de información.
Capa 6: la capa de recuperación
Una base de datos vectorial almacena información, pero es la capa de recuperación la que decide qué se muestra realmente al modelo. Esta distinción es fácil de pasar por alto. La recuperación puede basarse en similitud semántica, búsqueda por palabras clave, filtrado de metadatos, búsqueda híbrida, reclasificación y otras técnicas; herramientas como Azure AI Search, LangChain y LlamaIndex abarcan estas funcionalidades.
Una configuración madura combina estrategias. La búsqueda semántica localiza material conceptualmente relacionado, mientras que la búsqueda por palabras clave asegura que no se pasen por alto identificadores exactos, nombres de productos, números de pólizas o términos técnicos. Se trata de una recuperación híbrida, y los sistemas RAG empresariales añaden cada vez más filtros de metadatos, reclasificación, grafos de conocimiento y otros mecanismos adicionales.
El objetivo no es recuperar la mayor cantidad posible de información, sino obtener la información correcta.
Capa 7: ingeniería de prompts
Después de la recuperación, el sistema debe elaborar una instrucción adecuada para el modelo de lenguaje. Un prompt de producción es mucho más que la pregunta del usuario; puede incluir instrucciones del sistema, contexto recuperado, historial de conversaciones, reglas empresariales, requisitos de formato de salida, restricciones de seguridad, ejemplos, definiciones de herramientas y metadatos. LangChain, Promptify y DSPy son ejemplos de herramientas que ayudan a estructurar y ajustar dichos prompts.
La ingeniería de prompts también está trascendiendo la elaboración manual de frases ingeniosas. La atención se está desplazando hacia la ingeniería de contexto, que plantea una pregunta más amplia: ¿qué debe recibir el modelo, con qué estructura y en qué momento del flujo de trabajo? Esto es aún más importante para los agentes, que pueden construir el contexto dinámicamente a partir de acciones anteriores, material recuperado, resultados de herramientas y resultados intermedios.
Capa 8: el LLM
En el centro se encuentra el modelo de lenguaje grande, donde tienen lugar la comprensión del lenguaje, el razonamiento, la generación y el seguimiento de instrucciones. Las plataformas y modelos mencionados incluyen Azure, OpenAI, LLaMA y Mistral AI. El modelo recibe la solicitud junto con un contexto e instrucciones cuidadosamente preparados.
Hay un principio que merece repetirse: el LLM no es toda la aplicación. Es un componente dentro de un sistema mucho más grande, y una aplicación en producción necesita mecanismos de recuperación de información, orquestación, seguridad, evaluación, monitoreo, infraestructura y lógica empresarial alrededor de él. Esto se vuelve especialmente evidente al pasar de un prototipo a una implementación empresarial a gran escala.
De las aplicaciones basadas en LLM a los agentes
Es útil diferenciar una aplicación convencional basada en LLM de una que utiliza agentes. Una aplicación básica sigue este flujo: usuario, prompt, LLM, respuesta. Una aplicación RAG sigue: usuario, recuperación de información, contexto, LLM, respuesta. Un sistema basado en agentes es mucho más dinámico: usuario, agente, planificación, recuperación de información, herramientas, LLM, evaluación, acciones adicionales, respuesta final. El agente decide qué hacer a continuación y no se limita a seguir una secuencia fija.
Supongamos que alguien pregunta por qué falló el pipeline de producción de ayer y qué hacer al respecto. Un agente podría consultar el historial de ejecución, inspeccionar los registros, realizar consultas a las bases de datos, analizar los mensajes de error, consultar las políticas operativas, determinar la causa raíz probable y, posiblemente, recomendar o aplicar una solución aprobada. Eso es fundamentalmente diferente de redactar un párrafo de texto.
Capa 9: infraestructura e implementación
Un prototipo pulido no convierte automáticamente un producto en listo para producción. Para ponerlo en funcionamiento se necesita una infraestructura escalable, redes, seguridad, automatización de implementación, gestión de recursos y resiliencia. Los nombres de la arquitectura son Azure Container Apps, Azure Kubernetes Service, Docker y Kubernetes.
Docker empaqueta las aplicaciones en contenedores portátiles. Kubernetes orquesta cargas de trabajo en contenedores en entornos distribuidos. Azure Kubernetes Service es una oferta de Kubernetes gestionada, y Azure Container Apps simplifica el despliegue de contenedores sin necesidad de gestionar todo el entorno de Kubernetes.
Esta capa es importante cuando un sistema debe hacer frente a un alto tráfico de usuarios, muchos flujos de trabajo de agentes concurrentes, carga de inferencia de modelos, procesamiento en segundo plano, pipelines de ingesta de documentos, tareas de larga duración, integraciones con herramientas externas y requisitos de seguridad empresarial. Un modelo puede ser excelente, pero la infraestructura determina si esa excelencia puede entregarse de manera fiable a gran escala.
Capa 10: observabilidad y evaluación
La observabilidad es una de las partes más descuidadas en la ingeniería de IA. Las aplicaciones tradicionales pueden monitorearse mediante el uso de la CPU, la memoria, la latencia, los errores y las tasas de solicitud. Las aplicaciones de IA necesitan algo más. Los equipos deben poder ver qué recibió el modelo, qué se recuperó, qué herramientas se ejecutaron, qué decisiones se tomaron, la duración de cada paso, el recuento de tokens y si la respuesta final fue útil.
Azure AI Foundry, OpenTelemetry y Grafana son herramientas relevantes en este contexto. OpenTelemetry recopila datos de telemetría en aplicaciones distribuidas, mientras que Grafana visualiza métricas operativas y a nivel de aplicación.
La evaluación constituye otra dimensión importante. Los sistemas en producción pueden requerir puntuaciones relacionadas con la relevancia, la fundamentación, las alucinaciones, la calidad de la recuperación de información, la latencia, el costo, la seguridad y la satisfacción del usuario. Los agentes elevan aún más los estándares, ya que sus acciones también deben calificarse junto con la respuesta final:
- ¿Elegió la herramienta adecuada?
- ¿Recuperó la información correcta?
- ¿Realizó llamadas a herramientas innecesarias?
- ¿Siguió el flujo de trabajo adecuado?
- ¿Se detuvo una vez finalizada la tarea?
- ¿Elevó la situación correctamente cuando se necesitó ayuda humana?
Esas preguntas hacen que la observabilidad y la evaluación sean esenciales en el trabajo con IA en producción.
Por qué es importante todo el conjunto
Existe un concepto erróneo común que sostiene que crear una aplicación de IA implica elegir un LLM potente y añadir una interfaz de usuario. Eso puede funcionar para una demostración, pero rara vez refleja lo que requiere una plataforma de IA empresarial.
Imaginemos a un empleado que consulta a un asistente sobre la política de la organización para manejar un problema específico de un cliente. El sistema debe comprender la solicitud, encontrar los documentos de política adecuados, seleccionar las secciones relevantes, proporcionárselas al modelo, generar una respuesta fundamentada, quizás citar su fuente, aplicar políticas de seguridad, monitorear la interacción y determinar si la respuesta fue útil. Cada capa desempeña un papel: la interfaz frontal permite la interacción, la ingesta aporta conocimiento, el preprocesamiento lo hace utilizable, los embeddings capturan el significado, las bases de datos vectoriales almacenan representaciones buscables, la recuperación encuentra el contexto, la inducción estructura la respuesta, el LLM la genera, la infraestructura brinda escala y fiabilidad, y la observabilidad proporciona visibilidad y rendición de cuentas. En ese sentido, la IA moderna es de tipo full-stack.
Elegir herramientas
Las tecnologías de la arquitectura de referencia no constituyen una lista de compras que deba adoptarse en su totalidad. Cada una representa una opción para su respectivo nivel. Una empresa podría elegir React y Next.js desde el principio, Azure AI Content Understanding para procesar documentos, LangChain para orquestar las tareas, un modelo de incrustación alojado, Azure AI Search para la recuperación de información, un modelo servido en Azure y Azure Container Apps para ejecutar todo ello. Otra empresa podría optar por un conjunto completamente diferente.
La lección más importante es que la arquitectura precede a las herramientas. Los requisitos empresariales dan forma a la arquitectura, esta define las capacidades que necesita cada nivel, y solo entonces se deben elegir las tecnologías específicas.
Más que un LLM
La visión de full-stack también explica por qué los proyectos basados en agentes se complican rápidamente. Un agente puede necesitar conocimientos empresariales a través de RAG, datos estructurados de bases de datos, información externa vía APIs, capacidades operativas mediante herramientas y ejecución de flujos de trabajo a través de sistemas de orquestación. También requiere medidas de seguridad: autenticación y autorización, controles de privacidad de datos, protección contra inyecciones de prompts, permisos para herramientas, pasos de aprobación humana, registros de auditoría y marcos de evaluación.
Por lo tanto, la IA basada en agentes se encuentra en el punto de encuentro de varias disciplinas: ingeniería de software, ingeniería de datos, ingeniería de IA, ingeniería en la nube, seguridad y observabilidad. Construir agentes de nivel producción es un desafío de ingeniería y no solo un ejercicio de redacción de prompts.
Cómo ha evolucionado la arquitectura de aplicaciones
La industria ha pasado por diferentes etapas. Las primeras aplicaciones de IA estaban centradas en los modelos. Luego, RAG conectó los modelos con conocimientos externos. Los sistemas mejorados con herramientas permitieron que los modelos interactuaran con capacidades externas. Actualmente, la IA agente combina modelos, recuperación de información, herramientas, memoria, planificación, orquestación y evaluación. La evolución va desde los simples LLM hasta RAG, pasando por el uso de herramientas, los agentes, los sistemas multiagente, y a medida que avanza, la infraestructura circundante cobra cada vez más importancia.
Por dónde empezar
No toda aplicación necesita toda la capa tecnológica. Una herramienta sencilla de preguntas y respuestas puede funcionar bien con un LLM básico. Si la aplicación necesita conocimientos privados o que cambian con frecuencia, añada RAG. Cuando las relaciones entre entidades son clave en el problema, considere la recuperación basada en grafos. Cuando el sistema debe planificar tareas, elegir herramientas, ejecutar varios pasos y tomar decisiones de forma instantánea, la IA agente resulta ser la opción más adecuada.
El objetivo no debería ser la arquitectura más elaborada, sino la más simple que resuelva el problema de manera fiable.
Qué viene a continuación
El campo sigue en movimiento. Es probable que los grafos de conocimiento, las bases de datos vectoriales, los marcos de agentes, los motores de flujos de trabajo, los modelos multimodales, las herramientas de evaluación y las plataformas en la nube se acerquen cada vez más entre sí. Las aplicaciones recibirán imágenes, audio, video, datos estructurados, sistemas empresariales y flujos de trabajo del mundo real, además de texto. Observar y evaluar un sistema tendrá la misma importancia que elegir su modelo. Lo que está por venir no se trata tanto de modelos más inteligentes por sí solos, sino de sistemas fiables construidos en torno a ellos.
Conclusión
La IA agente no es una sola tecnología, sino un conjunto completo. Desde la interfaz frontal donde interactúan los usuarios, pasando por la ingesta y preprocesamiento, los embeddings y las bases de datos vectoriales, la recuperación de información y la generación de prompts, hasta los LLM, el despliegue y la supervisión, cada capa determina la inteligencia que finalmente muestra el sistema. El LLM es solo una parte. Un sistema agente de nivel profesional necesita los datos adecuados, una estrategia de recuperación eficaz, mecanismos de orquestación, infraestructura y métodos de evaluación. La capacidad de los modelos será menos importante que la calidad de la ingeniería de los sistemas que los rodean.
Leer más
- Un stack web para startups en la era de los agentes de IA: Next.js, MUI y Firebase — Qué herramientas son viables cuando los agentes escriben gran parte del código: Next.js, MUI, Firebase, Vercel, PostHog y una configuración mínima de agente, con la lógica detrás de cada una.
- Lo que descubre un agente de diferenciación de modelos: los cambios de estilo eclipsan un ajuste fino limitado — Un auditor de tipo caja negra comparó un modelo base con un LoRA financiero: el 82% de las pruebas detectaron cambios en la longitud y estructura, mientras que el cambio previsto en el razonamiento relacionado con los riesgos permaneció oculto.