Comprendre l’architecture des applications d’IA
À quoi ressemble vraiment une application d’IA ? Après en avoir construit quelques-uns, il semble être le bon moment de le décomposer en ses (nombreuses) parties et d’explorer les implications opérationnelles.
Nous avons déjà exploré ce qui est le même (beaucoup) et ce qui est différent (beaucoup) dans les applications d’IA . Il est assez facile de définir une application d’IA comme « une application qui exploite l’IA, qu’elle soit prédictive ou générative ».
C'est vrai, mais pour les personnes qui doivent créer, déployer, fournir, sécuriser et exploiter ces nouveaux types d'applications, qu'est-ce que cela signifie ?
Cela signifie de nouvelles pièces mobiles, pour commencer. Et pas seulement des services d'inférence . D'autres nouveaux composants deviennent des ajouts standards à l'architecture de l'application, comme les bases de données vectorielles. Cela signifie également une dépendance accrue aux API .
Il est également vrai que la plupart de ces composants sont conteneurisés. Lorsque je configure un nouveau projet d’application d’IA, je lance un conteneur exécutant PostgreSQL à utiliser comme magasin de données vectorielles. Il s'agit de prendre en charge RAG (Retrieval Augmented Generation), qu'un pourcentage important d'applications d'IA utilisent selon plusieurs rapports du secteur ( celui-ci de Databricks par exemple) . C’est parce que je peux augmenter un modèle d’IA standard en utilisant toutes les données que je souhaite sans avoir à peaufiner ou à former un modèle moi-même. Pour un nombre important de cas d’utilisation, c’est la meilleure façon de mettre en œuvre une application d’IA.
Je peux également lancer un graphique de connaissances, généralement en exécutant une base de données graphique conteneurisée comme Neo4J. Les bases de données graphiques sont particulièrement utiles lorsque vous travaillez avec des données affines graphiques, comme les réseaux sociaux, les données des moteurs de recommandation et la détection des fraudes. Il s’avère qu’ils sont également utiles pour atténuer les hallucinations liées à l’élaboration des politiques, comme nous l’avons appris au début de l’année . L'inclusion d'une base de données graphique peut ajouter un nouveau protocole, GraphQL, à la liste des « nouvelles choses qui doivent être sécurisées ».
Ensuite, je vais décider quel service d’inférence je souhaite utiliser. J'ai des options. Je pourrais utiliser un service de fournisseur de cloud ou l'IA en tant que service (à la ChatGPT) ou je pourrais exécuter un service local . Par exemple, mes derniers bricolages ont utilisé Ollama et phi3 sur mon MacBook. Dans ce cas, je n'exécute qu'une seule copie du serveur d'inférence car, eh bien, en exécuter plusieurs consommerait plus de ressources que ce dont je dispose. En production, bien sûr, il est probable qu'il y aura davantage de cas pour s'assurer que le système puisse répondre à la demande.
Parce que je vais utiliser phi3, je choisis phidata comme framework pour accéder au service d'inférence. J'ai également utilisé langchain pour tirer parti de l'IA en tant que service, un choix populaire, et la bonne nouvelle est que d'un point de vue opérationnel, le framework n'est pas quelque chose qui fonctionne en dehors de l'application d'IA principale elle-même.
Impact opérationnel des applications d'IA
Je n’ai même pas encore écrit une ligne de code et j’ai déjà plusieurs composants en cours d’exécution, chacun accessible via l’API et exécuté dans leurs propres conteneurs. C’est pourquoi nous partons du principe qu’une application d’IA est une application moderne et qu’elle présente les mêmes défis habituels en matière de livraison, de sécurité et d’exploitation. C’est également pourquoi nous pensons que le déploiement de modèles d’IA augmentera radicalement le nombre d’API nécessitant diffusion et sécurité.
Les applications d’IA ajoutent un niveau supplémentaire à un environnement déjà complexe, ce qui, bien sûr, augmente la complexité. Ce qui signifie que l’architecture des applications d’IA va augmenter la charge sur toutes les fonctions opérationnelles, de la sécurité au SRE en passant par le réseau. Chacun de ces composants possède également son propre profil de mise à l'échelle ; c'est-à-dire que certains composants devront évoluer plus rapidement que d'autres et la manière dont les requêtes sont distribuées variera simplement parce que la plupart d'entre eux exploitent des API différentes et, dans certains cas, des protocoles différents.
De plus, l’architecture des applications d’IA sera très variable en interne. Autrement dit, l’application d’IA que je crée est susceptible de présenter des caractéristiques et des besoins de trafic local différents de ceux de l’application d’IA que vous créez. Et plus d’hétérogénéité signifie naturellement plus de complexité, car c’est l’opposé de la standardisation, qui favorise l’homogénéité.
La normalisation est, depuis des décennies, le moyen par lequel les entreprises accélèrent la mise à disposition de nouvelles capacités sur le marché et atteignent une plus grande efficacité opérationnelle tout en libérant les ressources humaines nécessaires pour faire face à la variabilité des architectures d'applications d'IA.
C’est pourquoi nous voyons certains services partagés, notamment la sécurité des applications et des API, se déplacer vers la périphérie, à la manière de la sécurité en tant que service . Un tel ensemble de services partagés peut non seulement mieux protéger les charges de travail dans tous les environnements (cœur, cloud et périphérie), mais également fournir un ensemble commun de services pouvant servir de norme dans toutes les applications d'IA.
Comprendre l’anatomie des applications d’IA vous aidera à déterminer non seulement les types de services de distribution d’applications et de sécurité dont vous avez besoin, mais également où vous en avez besoin.