
J'y ai passé 5 jours de conférence la semaine dernière (y compris l'atelier de la veille), et je suis reparti avec de bonnes idées, des réponses à mes questions et beaucoup de choses à approfondir.
Si l'année dernière tout tournait autour de Microsoft 365 Copilot, cette année était axée sur les agents. Agents intelligents ne sont pas nouveaux, mais ce qui est intéressant dans ce nouveau monde agentique, c'est que ces agents supposent l'utilisation de grands ou de petits modèles linguistiques (LLM ou SLM), même si ce n'est pas leur tâche principale. Un agent intelligent est, à la base, une application capable d'effectuer une tâche de manière autonome. Vous lui demandez de faire quelque chose comme résumer une transcription, exécuter un morceau de code ou même simplement vous dire l'heure qu'il est, et il le fera. Vous n'avez pas besoin de savoir comment il fonctionne, et vous ne savez pas nécessairement quand il vous répondra, mais vous pouvez généralement faire confiance à ce que la tâche sera accomplie. C'est un peu comme les services ou les API dans le monde du logiciel. Cependant, en ajoutant des modèles linguistiques au mélange, nous pouvons orchestrer et communiquer entre les agents en utilisant le langage naturel, ce qui offre un potentiel incroyable pour les systèmes intelligents.
Bien que les API soient utiles, elles exigent un contrat bien défini entre les points d'extrémité. Elles s'attendent à une requête formatée de manière spécifique et fourniront une réponse formatée de manière spécifique. Un développeur doit connaître les deux pour utiliser le service via l'API, et si ce contrat change, alors tout consommateur de ce service doit mettre à jour son code en conséquence. Les interfaces LLM changent cela et signifient que ces définitions peuvent être plus flexibles. Par exemple, je pourrais demander à un agent horaire « Quelle heure est-il? » et il pourrait répondre « 16 h 30 » ou peut-être « 16 h 30 le 24 nov. 2025 » ou même « Quatre heures et demie » si l'agent est particulièrement britannique. Étant donné que la réponse est également destinée à être traitée par un LLM, ces variantes seraient probablement gérées, et l'agent aurait fait son travail.
Ce qui rend les agents passionnants, c'est la façon dont ils peuvent étendre les capacités des systèmes intelligents de manière modulaire en implémentant des morceaux de fonctionnalité discrets, ce qui signifie que vous n'avez pas besoin de construire une IA omnisciente et englobante. Il y a aussi toujours des fonctionnalités qui améliorent ice sans aucun changement de produit. Il est déjà possible d'utiliser Microsoft 365 Copilot pour analyser un appel en cours dans Teams, donc je soupçonne que le nouvel interprète (traduction en temps réel) et la compréhension du contenu (Copilot accédant au contenu partagé à l'écran) fonctionneront directement dès leur lancement.
Le simple fait d'avoir des agents ne signifie rien sans un moyen de les trouver, et c'est là qu'intervient un orchestrateur d'agents. Un orchestrateur d'agents est vraiment la « porte d'entrée » de toute conversation d'IA et est responsable de savoir comment gérer une requête, y compris quels agents d'IA doivent être impliqués. Cela signifie qu'il doit savoir quels agents existent et ce qu'ils peuvent faire. À cette complexité s'ajoute le fait qu'un agent peut lui-même orchestrer d'autres agents, créant ainsi un graphique qui commence à ressembler à un organigramme.
À Ignite, plusieurs méthodes d'orchestration ont été discutées, mais toutes étaient raisonnablement brèves. Évidemment, Microsoft 365 Copilot a été présenté comme un exemple d'orchestrateur, mais il existait d'autres solutions qui s'appliquent aux applications personnalisées. Dans le cas idéal, l'orchestration des agents se ferait par une description des capacités en langage naturel, par exemple « cet agent renvoie l'heure actuelle » pour un agent horaire. Certains exemples utilisaient cependant un flux d'orchestration d'agents plus manuel, invoquant manuellement des éléments comme un agent de recherche, un agent d'annotation et un agent de personnalisation, avant de composer une réponse finale. Les deux architectures ont leur place et sembleront probablement très familières à quiconque a passé du temps avec un centre de contact. Dans ice, le flux de travail est la plateforme d'orchestration des agents, et les agents sont soit des flux de travail, des blocs de construction, ou des agents humains pour lesquels nous définissons des règles d'implication dans les demandes de service.
Outre tout ce qui concerne l'architecture agentique, j'ai également appris comment le réglage fin multi-LoRA pourrait être appliqué pour ingérer des connaissances et du jargon. Plus important encore, j'ai discuté avec des experts des meilleures pratiques concernant la pertinence d'une approche de réglage fin par opposition à une approche RAG (Retrieval Augmented Generation). Bien sûr, ajouter des agents à l'équation favorise une approche « pourquoi pas les deux », et cela s'harmonise très bien avec ce que notre équipe expérimente déjà.
De plus, j'ai eu une bonne exposition à l'utilisation de chaînes d'outils dans les applications d'IA générative (qui fonctionnent comme des agents eux-mêmes) que je n'avais pas vraiment eu l'occasion d'expérimenter auparavant, ce qui a inspiré des idées pour les futures fonctionnalités du centre de contact ice.
Il y a aussi de nouvelles fonctionnalités intéressantes qui méritent d'être explorées davantage :
L'une des choses géniales à propos d'une conférence comme Ignite, c'est que c'est l'occasion de passer une semaine à parler à des gens intéressants, à apprendre de nouvelles choses et à réfléchir à l'avenir de notre entreprise. Être dans un endroit différent et avoir de nouveaux stimuli suscite toujours de nouvelles idées, et je reviendrai l'année prochaine avec une bonne liste de choses que je veux essayer.
Au sortir du salon de cette année, je suis confiant que ComputerTalk est dans une excellente position par rapport à notre Fonctionnalités d'IA, et nous avons hâte de voir ce que nous pourrons faire ensuite.