Comprendre l’architecture des applications d’IA

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

À quoi ressemble réellement une application d’IA ? Après en avoir développé quelques-unes, le moment semble bien choisi pour la décomposer en ses (nombreux) éléments et examiner les implications opérationnelles.

Nous avons déjà examiné les nombreux points communs et les nombreuses différences entre 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 qu’est-ce que cela implique pour les personnes chargées de développer, déployer, fournir, sécuriser et exploiter ces nouveaux types d’applications ?

Cela implique tout d’abord de nouveaux éléments mobiles. Et pas seulement des « services d’inférence ». D’autres nouveaux composants s’imposent désormais comme des ajouts standard à l’architecture applicative, tels que les bases de données vectorielles. Cela implique également une dépendance accrue aux API.

Il est également vrai que la plupart de ces composants sont conteneurisés. Lorsque je mets en place un nouveau projet d’application d’IA, je lance un conteneur exécutant PostgreSQL afin de l’utiliser comme base de données vectorielle. Cela permet de prendre en charge la RAG (génération augmentée par récupération), qu’une part importante des applications d’IA utilise, selon plusieurs rapports du secteur (comme celui-ci de Databricks, par exemple). En effet, je peux enrichir un modèle d’IA standard avec les données de mon choix sans avoir à affiner ni à entraîner moi-même un modèle. Pour un grand nombre de cas d’usage, c’est la meilleure façon de mettre en œuvre une application d’IA.

Je peux également mettre en place un graphe de connaissances, généralement en exécutant une base de données orientée graphe conteneurisée telle que Neo4J. Les bases de données orientées graphe sont particulièrement utiles pour travailler avec des données qui se prêtent à une représentation sous forme de graphe, comme les réseaux sociaux, les données des moteurs de recommandation et la détection des fraudes. Il s’avère qu’elles sont également utiles pour atténuer les hallucinations liées à la génération de politiques, comme nous l’avons constaté en début d’année. L’ajout d’une base de données orientée graphe peut ajouter un nouveau protocole, GraphQL, à la liste des « nouvelles technologies à sécuriser ».

Ensuite, je vais choisir le service d’inférence que je souhaite utiliser. Plusieurs possibilités s’offrent à moi. Je pourrais utiliser un service d’un fournisseur cloud ou une IA en tant que service (comme ChatGPT), ou bien exécuter un service local. Par exemple, lors de mes dernières expérimentations, j’ai utilisé Ollama et phi3 sur mon MacBook. Dans ce cas, je n’exécute qu’une seule instance du serveur d’inférence, car en exécuter plusieurs consommerait plus de ressources que je n’en ai. En production, bien sûr, il y aurait probablement davantage d’instances afin de pouvoir répondre à la demande.

Comme 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. La bonne nouvelle, d’un point de vue opérationnel, est que le framework ne fonctionne pas 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 seule ligne de code que plusieurs composants sont déjà en cours d’exécution, chacun étant accessible via une API et s’exécutant dans son propre conteneur. C’est pourquoi nous partons du principe qu’une application d’IA est une application moderne, qui s’accompagne des mêmes défis bien connus en matière de déploiement, de sécurité et d’exploitation. C’est également pourquoi nous pensons que le déploiement de modèles d’IA augmentera considérablement le nombre d’API à déployer et à sécuriser.

Les défis opérationnels se cumulent, et chaque nouvelle architecture en crée de nouveaux ou amplifie ceux qui existent déjà.

Les applications d’IA ajoutent une couche supplémentaire à un environnement déjà complexe, ce qui, bien entendu, en accroît la complexité. L’architecture des applications d’IA va donc alourdir la charge de 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 : certains devront évoluer plus rapidement que d’autres, et la répartition des requêtes variera, tout simplement parce que la plupart d’entre eux utilisent 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 développe présentera probablement des caractéristiques et des besoins différents en matière de trafic local par rapport à celle que vous développez. Or, une plus grande hétérogénéité entraîne naturellement une complexité accrue, car elle est à l’opposé de la standardisation, qui favorise l’homogénéité.

Depuis des décennies, la standardisation permet aux entreprises d’accélérer la mise sur le marché de nouvelles fonctionnalités et d’améliorer leur efficacité opérationnelle, tout en libérant les ressources humaines nécessaires pour gérer la variabilité des architectures d’applications d’IA.

C’est pourquoi nous constatons que certains services partagés, notamment ceux liés à la sécurité des applications et des API, migrent vers la périphérie, sur le modèle de la sécurité en tant que service. Un tel ensemble de services partagés permet non seulement de mieux protéger les charges de travail dans tous les environnements (cœur de réseau, cloud et périphérie), mais aussi de fournir un socle de services commun pouvant servir de norme pour l’ensemble des applications d’IA.

Comprendre l’anatomie des applications d’IA vous aidera à déterminer non seulement les types de services de mise à disposition et de sécurité des applications dont vous avez besoin, mais aussi où vous en avez besoin.

À propos de l’auteur

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.

Autres articles de Lori Mac Vittie