Comprensión de la arquitectura de las aplicação de IA
¿Cómo es realmente una aplicação de IA? Después de haber construido algunos, parece un buen momento para dividirlos en sus (muchas) partes y explorar las implicaciones operativas.
Ya hemos explorado anteriormente qué es lo mismo (mucho) y qué es diferente (mucho) acerca de las aplicações de IA . Es bastante fácil definir una aplicação de IA como "una aplicação que aprovecha la IA, ya sea predictiva o generativa ".
Eso es cierto, pero para las personas que deben construir, implementar, entregar, proteger y operar estos nuevos tipos de aplicações, ¿qué significa eso?
Significa nuevas piezas móviles, por un lado. Y no sólo servicios de inferencia . Hay otros componentes nuevos que se están convirtiendo en estándar en la arquitectura de la aplicação , como las bases de datos vectoriales. También significa una mayor dependencia de las API .
También es cierto que la mayoría de estos componentes están en contenedores. Cuando configuro un nuevo proyecto de aplicação de IA, inicio un contenedor que ejecuta PostgreSQL para usarlo como almacén de datos vectoriales. Esto es para respaldar RAG (Recuperación y Generación Aumentada), que un porcentaje significativo de aplicações de IA utilizan según varios informes de la industria ( este de Databricks, por ejemplo) . Esto se debe a que puedo ampliar un modelo de IA estándar utilizando cualquier dato que desee sin tener que ajustar o entrenar un modelo yo mismo. Para una cantidad significativa de casos de uso, esa es la mejor manera de implementar una aplicação de IA.
También puedo activar un gráfico de conocimiento, generalmente ejecutando una base de datos de gráficos en contenedores como Neo4J. Las bases de datos de gráficos son particularmente útiles cuando se trabaja con datos afines a los gráficos, como redes sociales, datos de motores de recomendación y detección de fraude. Resulta que también son útiles para mitigar las alucinaciones relacionadas con la generación de políticas, como aprendimos a principios de año . La inclusión de una base de datos gráfica puede agregar un nuevo protocolo, GraphQL, a la lista de "cosas nuevas que necesitan protección".
Luego decidiré qué servicio de inferencia quiero utilizar. Tengo opciones Podría utilizar un servicio de un proveedor de nube o IA como servicio (como ChatGPT) o podría ejecutar un servicio local . Por ejemplo, mi último retoque ha sido utilizar Ollama y phi3 en mi MacBook. En este caso, solo estoy ejecutando una copia del servidor de inferencia porque, bueno, ejecutar varios consumiría más recursos de los que tengo. En producción, por supuesto, es probable que haya más instancias para asegurarse de que pueda satisfacer la demanda.
Como voy a utilizar phi3, elijo phidata como mi marco para acceder al servicio de inferencia. También he utilizado langchain al aprovechar la IA como servicio, una opción popular, y la buena noticia es que, desde una perspectiva operativa, el marco no es algo que opere fuera de la aplicação principal de IA en sí.
Impacto operativo de las aplicações de IA
Ni siquiera he escrito una línea de código todavía y ya tengo varios componentes en ejecución, cada uno de los cuales se accede a través de API y se ejecutan en sus propios contenedores. Por eso partimos de la premisa de que una aplicação de IA es una aplicação moderna y conlleva los mismos desafíos familiares de entrega, seguridad y operación. Es también por eso que creemos que la implementación de modelos de IA aumentará radicalmente la cantidad de API que necesitan entrega y seguridad.
Las aplicações de IA agregan otro nivel a un entorno ya complejo, lo que, por supuesto, aumenta la complejidad. Esto significa que la arquitectura de aplicação de IA aumentará la carga en todas las funciones operativas, desde la seguridad hasta la SRE y la red. Cada uno de estos componentes también tiene su propio perfil de escalamiento; es decir, algunos componentes necesitarán escalar más rápido que otros y la forma en que se distribuyen las solicitudes variará simplemente porque la mayoría de ellos aprovechan diferentes API y, en algunos casos, protocolos.
Es más, la arquitectura de las aplicação de IA será muy variable internamente. Es decir, es probable que la aplicação de IA que construya presente características y necesidades de tráfico local diferentes a las de la aplicação de IA que usted construya. Y una mayor heterogeneidad significa naturalmente una mayor complejidad porque es lo opuesto a la estandarización, que promueve la homogeneidad.
La estandarización ha sido, durante décadas, el medio a través del cual las empresas aceleran la entrega de nuevas capacidades al mercado y logran mayores eficiencias operativas al tiempo que liberan los recursos humanos necesarios para abordar la variabilidad en las arquitecturas de aplicação de IA.
Es por esto que vemos que algunos servicios compartidos (en particular la seguridad de aplicaciones y API) se están trasladando al borde, como la seguridad como servicio . Un conjunto de servicios compartidos de este tipo no solo puede proteger mejor las cargas de trabajo en todos los entornos (núcleo, nube y borde), sino que también proporciona un conjunto común de servicios que puede servir como estándar en todas las aplicações de IA.
Comprender la anatomía de las aplicações de IA ayudará a determinar no solo los tipos de entrega de aplicação y servicios de seguridad que necesita, sino también dónde los necesita.