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 ».
Je vais ensuite choisir le service d’inférence que je veux utiliser. Vous avez des options. Vous pouvez utiliser un service d’un fournisseur de cloud ou une IA en tant que service (comme ChatGPT) ou exécuter un service local. Par exemple, mes dernières expérimentations ont utilisé Ollama et phi3 sur mon MacBook. Ici, je n’exécute qu’une seule instance du serveur d’inférence car en lancer plusieurs demanderait plus de ressources que je n’en ai. En production, on déploierait bien sûr plusieurs instances pour garantir une réponse à 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é.
Depuis des décennies, la normalisation permet aux entreprises d’accélérer l’arrivée de nouvelles fonctionnalités sur le marché, d’améliorer leur efficacité opérationnelle et de libérer les ressources humaines indispensables pour gérer la diversité des architectures d’applications 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.