Nikunj Bajaj, Co-fondateur et PDG de TrueFoundry – Série d’entretiens

Vous avez travaillé dans la recherche en apprentissage automatique, l’IA de production chez Facebook (META ) et les systèmes de recommandation à grande échelle avant de fonder TrueFoundry — quels ont été les expériences qui vous ont le plus directement poussé à créer une entreprise d’infrastructure d’IA d’entreprise, et quelles douleurs n’étaient pas abordées à l’époque?

À Meta, nous considérions l’apprentissage automatique comme un cas spécial de logiciel, et l’IA générative comme un cas spécial d’apprentissage automatique, ce qui a abouti à une pile verticale avec le logiciel à la base, l’apprentissage automatique au milieu et l’IA générative au sommet. Dans cette configuration, si je suis un développeur d’apprentissage automatique, les modèles que je crée suivent le même modèle de déploiement que le reste du logiciel, ce qui rend la mise à l’échelle des systèmes très simple.

La plupart des entreprises, cependant, déployaient des piles parallèles, ce qui signifie qu’elles avaient des piles distinctes pour le logiciel, l’apprentissage automatique et l’IA générative. Dès l’instant où vous avez ces piles parallèles, la mise à l’échelle devient plus complexe en raison des transferts nécessaires entre l’apprentissage automatique et le monde du logiciel.

Notre équipe a toujours travaillé à l’intersection de la construction de modèles d’apprentissage automatique et d’infrastructure d’apprentissage automatique, nous avions donc une perspective unique que nous pouvions apporter à des piles verticales similaires aux entreprises et les adapter à leurs besoins spécifiques. Nous avions également une hypothèse vers la fin de 2021 selon laquelle l’apprentissage automatique approchait un point d’inflexion, et que lorsque cela se produirait, plus d’entreprises auraient besoin d’une pile intégrée verticalement pour déployer et mettre à l’échelle ces systèmes de manière efficace. C’est ce qui nous a finalement amenés à fonder TrueFoundry, et notre hypothèse était juste. L’adoption de l’IA a accéléré après le lancement de ChatGPT à la fin de 2022.

À mesure que les systèmes d’IA passent de l’expérimentation aux opérations quotidiennes, qu’est-ce qui a changé dans la façon dont les organisations devraient penser la fiabilité et la défaillance?

Les enjeux de l’IA générative sont nettement plus élevés par rapport aux systèmes d’apprentissage automatique traditionnels. À mesure que ces systèmes passent en production, les organisations sont confrontées à un niveau d’ambiguïté et de non-déterminisme beaucoup plus élevé, car les LLM sont stochastiques par nature. Les systèmes agents construits sur ceux-ci ajoutent une ambiguïté supplémentaire.

De plus, les défaillances ne sont plus binaires. Au lieu que les systèmes défaillent simplement ou non, de nombreux problèmes apparaissent sous forme de défaillances partielles ou de dégradations silencieuses. Les systèmes peuvent répondre avec une latence plus élevée, une qualité dégradée ou un comportement incorrect au fil du temps. Dans de nombreux cas, ces dégradations peuvent être plus difficiles à détecter et parfois même plus préjudiciables qu’une panne dure.

Les organisations doivent réfléchir à la fiabilité non seulement en termes de temps d’activité, mais également de dégradation des performances au fil du temps.

TrueFailover a été lancé au milieu d’une vague de perturbations de services cloud et d’IA de haute visibilité. Quels événements récents ont rendu clair que la fiabilité de l’IA était passée d’un « agréable à avoir » à un requisitoire architectural de base?

L’un de nos clients du secteur de la santé, qui traite des demandes de patients en temps réel et sensibles au temps, a été touché par une panne causée par une défaillance de modèle. Leurs flux de travail génèrent des milliers de dollars de revenus par seconde, et la panne a perturbé certains de ces flux de travail critiques. En tant que client précoce de TrueFailover, nous avons pu aider à une récupération rapide, et l’impact a été contenu.

Des incidents comme celui-ci soulèvent une question importante. À mesure que les enjeux des systèmes d’IA générative continuent d’augmenter, pourquoi les processus de récupération sont-ils encore largement manuels ? Cela a renforcé l’idée que les systèmes devraient être conçus en supposant que les défaillances se produiront, et qu’ils devraient être conçus pour se corriger automatiquement. La fiabilité doit également être intégrée dans la pile d’IA elle-même grâce à l’utilisation de passerelles d’IA, qui peuvent fournir un routage centralisé, une observabilité, des garde-fous et un commutation de modèles intelligent entre les fournisseurs.

De nombreuses pannes d’IA sont encore présentées comme des problèmes techniques. Où voyez-vous les véritables coûts économiques et humains commencer à émerger lorsque les systèmes d’IA sont défaillants?

L’IA d’entreprise a évolué à un point où ces problèmes n’affectent plus seulement les flux de travail internes. Aujourd’hui, les pannes et les dégradations affectent directement la perception du public et les profits, car les cas d’utilisation de production sont maintenant orientés vers le client. Ce passage de l’expérimentation interne aux applications à haute visibilité est la raison pour laquelle nous voyons une demande accrue d’attention et de surveillance de la part de la direction.

À mesure que les systèmes d’IA s’intègrent plus profondément dans les flux de travail opérationnels, les pannes ne sont plus seulement des problèmes techniques. Ils ont de plus en plus de conséquences commerciales, client et de réputation.

Dans des environnements critiques comme les pharmacies, les opérations de santé ou le support client, combien de temps peut-il falloir pour que les temps d’arrêt d’IA s’aggravent en risque opérationnel ou de réputation?

Dans des environnements critiques, l’aggravation se produit presque immédiatement, car ces systèmes soutiennent des flux de travail en temps réel et sensibles au temps. Même une brève perturbation peut arrêter des processus critiques, retarder la livraison de services ou interrompre des systèmes en aval qui dépendent de ces sorties, créant des effets opérationnels en cascade dans l’ensemble de l’organisation.

Dans des secteurs comme la santé, l’impact va au-delà de la perturbation opérationnelle pour affecter l’expérience client et les résultats du service. Si un patient n’est pas en mesure de remplir sa prescription à temps, il peut y avoir de véritables conséquences. Non seulement est-ce un problème pour le patient, mais cela peut également nuire à la réputation d’une pharmacie ou d’un fournisseur de soins de santé. Dans des environnements critiques où la confiance est un facteur, il est essentiel que les systèmes restent en ligne. C’est pourquoi les organisations reconnaissent de plus en plus que les systèmes d’IA doivent être conçus en supposant que les défaillances se produiront et que les mécanismes de récupération doivent s’activer automatiquement pour minimiser les risques.

Vous avez dit que de nombreuses équipes conçoivent pour la capacité plutôt que pour la continuité. Pourquoi pensez-vous que la résilience a historiquement été sous-estimée dans la conception des systèmes d’IA?

Cela vient principalement des incitations au sein des organisations. Les nouvelles capacités sont visibles et excitantes. Elles débloquent des démonstrations, des fonctionnalités et des possibilités de produits que la direction peut voir immédiatement.

La continuité, par définition, est invisible lorsqu’elle fonctionne bien. Par conséquent, les systèmes de récompense sont biaisés vers le lancement de nouvelles fonctionnalités plutôt que vers la garantie que rien ne se brise. En conséquence, les organisations investissent de manière disproportionnée dans le développement de capacités plutôt que dans l’ingénierie de résilience.

À mesure que les entreprises s’appuient de plus en plus sur des modèles et des API externes, quelles nouvelles fragilités sont introduites dans la pile d’IA que les dirigeants peuvent ne pas encore pleinement apprécier?

Les LLM sont fondamentalement des ressources partagées, et les entreprises ne les possèdent pas comme elles le font pour les infrastructures traditionnelles. De plus, des systèmes commerciaux critiques au sein des entreprises fonctionnent sur des systèmes externes qui ne sont pas encore pleinement éprouvés. Les LLM eux-mêmes évoluent rapidement, ce qui signifie qu’un fournisseur de modèles ne peut pas être tenu responsable de choses comme la latence ou la performance du modèle qui baisse légèrement, car ils itèrent rapidement sur leurs recherches.

Puisque les LLM sont des ressources partagées, la latence peut augmenter parce qu’un autre consommateur de ces LLM prend une action spécifique. Il y a de nombreux points de défaillance qui sont introduits en raison de la nature fondamentale des LLM, et les entreprises dans ce nouveau monde n’ont simplement pas un contrôle total. Sans contrôle total, la meilleure chose qu’une entreprise peut faire est de créer suffisamment de redondances de système pour concevoir un système résilient.

Sans se concentrer sur des produits spécifiques, comment les organisations devraient-elles repenser l’architecture d’IA pour supposer la défaillance plutôt que de traiter les pannes comme des cas de bord rares?

Les organisations devraient revenir aux principes fondamentaux de la conception de systèmes distribués. Les systèmes logiciels ont été conçus en supposant que les composants réseau et les machines défailliraient, et qu’une région entière pourrait tomber en panne.

Les systèmes d’IA ne devraient pas être différents. Nous devrions supposer que les fournisseurs de modèles connaîtront des problèmes de latence, des dégradations ou des pannes, et incorporer la redondance afin que les applications restent résilientes face à différents scénarios de défaillance.

Attendez-vous que la résilience d’IA devienne un facteur décisif dans le choix de plateforme et de fournisseur, semblable à la façon dont le temps d’activité et la redondance ont façonné les décisions d’infrastructure cloud?

À mesure que davantage de systèmes d’IA passent en production, la résilience deviendra un élément de base. Si un fournisseur ne peut pas présenter ses graphiques et ses métriques sur le temps d’activité et la résilience globale, il ne sera même pas considéré. Une fois que la résilience devient une attente de base pour les fournisseurs, les facteurs décisifs se déplaceront vers l’expérience utilisateur, l’optimisation des performances, l’observabilité et les capacités de produit de niveau supérieur. Au fil du temps, des composants tels qu’une passerelle d’IA et des capacités de basculement automatique deviendront des éléments fondamentaux de l’infrastructure d’IA d’entreprise.

En regardant vers l’avenir, qu’est-ce que signifie réellement « prêt pour la production » pour l’IA dans un monde où l’IA est censée être continuellement disponible, et non seulement occasionnellement utile?

Les systèmes d’IA prêts pour la production devraient être observables, contrôlables et récupérables. Toutes ces cases doivent être cochées.

Pour que l’IA de production soit observable, les équipes ont besoin d’une visibilité approfondie sur le comportement du modèle, la latence, les taux d’erreur, l’utilisation de jetons, la dérive et les modèles de défaillance. Sans une forte observabilité, il devient très difficile de détecter les dégradations avant que les utilisateurs commencent à les remarquer.

Pour que les systèmes soient contrôlables, cela inclut le façonnage du trafic, la limitation des taux, les garde-fous, l’application des politiques et le routage intelligent entre les modèles et les fournisseurs. C’est là que la passerelle d’IA devient fondamentale, agissant comme un plan de contrôle centralisé qui impose des garde-fous, fournit une gouvernance cohérente et permet le commutation dynamique de modèles lorsque les performances ou la fiabilité diminuent.

Et enfin, en ce qui concerne la récupérabilité, les systèmes devraient être conçus en supposant que les composants peuvent être partiellement ou complètement défectueux, que ce soit en raison de pannes de fournisseurs, de qualité de modèle dégradée, de limitations de taux ou d’entrées inattendues de la part d’acteurs malveillants. Les mécanismes de basculement automatique et d’auto-réparation devraient être natifs de l’architecture, et non des carnets de notes manuels déclenchés après que quelque chose se soit mal passé.

C’est la direction dans laquelle nous travaillons à TrueFoundry. Les fournisseurs qui définissent la production prête de cette manière, en combinant l’observabilité, le contrôle centralisé et la récupération automatisée, gagneront la confiance à long terme des clients et seront en mesure de continuer à résoudre de nouveaux problèmes à mesure qu’ils émergent. Vendors that define production readiness in this way, combining observability, centralized control, and automated recovery, will earn long-term customer trust and will be able to continue to solve new issues as they emerge. Thank you for the great interview, readers who wish to learn more should visit TrueFoundry.

Thank you for the great interview, readers who wish to learn more should visit TrueFoundry.