Premiers retours sur la performance de Copilot M365 et les contenus SharePoint
Dans ce billet, je ne parlerai pas de Copilot pour SharePoint, dont la sortie reste annoncée sur les Tenants d’Amérique du Nord pour le premier semestre 2024 avant de déferler sur les autres zones géographiques. Je ne manquerai pas de vous partager mes premières expériences sur ce qu’il permet de réaliser, sujet déjà présenté dans ce précédent billet.
Dans ce billet, il est question de la performance de Copilot M365 concernant les contenus SharePoint et ce concernant, j’ai déjà une idée assez précise sur :
- La performance actuelle de Copilot Microsoft 365,
- Les axes d’amélioration qui se présentent..
Ce que l’on constate de la performance actuelle de Copilot M365 sur les contenus SharePoint
Dans la version actuelle que j’utilise sur le Tenant US gracieusement mis à disposition pour les essais des MVP, on constate que, comme sur Bing, il suggère des prompts d’exemples, pour ne pas laisser l’utilisateur dans un possible état de passivité proche de celui de la page blanche.
Une expérience proche de Bing… sans les sources Bing ?!
Ensuite, concernant la présentation des résultats, l’expérience est riche puisque, en plus du texte généré attendu, Copilot M365 fournit, comme sur Bing, les fichiers-références principaux utilisés sous générer le texte ainsi que des suggestions de prompts complémentaires.
En revanche, si le texte généré devait s’appuyer également sur le web (Bing, ce qui ne constitue qu’une option activable ou désactivable depuis le centre d’administration M365), je n’accède pas aux références utilisées. Je trouve cela dommage.
Revenons aux contenus SharePoint et voyons là-aussi une nouvelle piste d’amélioration qui me semble là-aussi évidente, c’est que seuls les contenus des bibliothèques de documents SharePoint sont traités : les fichiers OK, les pages SharePoint OK mais pas d’éléments de liste SharePoint !
Pas de liste SharePoint
Concernant les listes, j’ai trouvé un tuto-vidéo qui permet d’ajouter le contenu d’une liste, par exemple une FAQ, dans le traitement de Copilot M365 en passant par Copilot Studio et Power Automate ; voici le lien direct Copilot Studio : Use Generative Answers on SharePoint List (youtube.com).
Un Copilot M365 davantage fait pour la GED ou pour les pages SharePoint ?
Copilot prend en compte les pages SharePoint mais prend-il de façon complète et entière la dimension GED de SharePoint ? Et bien, continuons à faire le tour de la façon dont Copilot M365 traite actuellement nos fichiers SharePoint pour répondre à cette question.
Lorsque que l’on clique sur la flèche en regard du nom fichier, on accède à des informations complémentaires qui permettent de qualifier la source avec le nom du dernier utilisateur ayant modifié le fichier et la date de cette dernière modification.
Et là peut s’ouvrir un champ de questions complémentaires : comment Copilot M365 gère-t-il actuellement la structuration de mes données ? Dans les billets de la série « SharePoint et la GED », j’ai décrit différents niveaux de structuration de l’information, en passant par les colonnes de valeur par défaut sur les dossiers et en allant jusqu’à l’expérience de recherche personnalisée avec des filtres à facette, déclarées dans le schéma de recherche…
Que fait Copilot M365 avec nos métadonnées ?
Ma réponse oscille actuellement pour l’instant entre « rien » et « presque rien ».
En effet, les propriétés connues et exploitées par Copilot sont celles que je vous liste ci-contre.
Mais cela va changer car Microsoft communique sur le concept d’index sémantique Copilot M365.
Il est donc temps de passer aux pistes d’amélioration.
Les axes d’amélioration qui se présentent…
Est-ce si important que cela de prendre en compte le schéma de recherche qui peut contenir des métadonnées SharePoint ou de prendre en compte le magasin de termes, l’emplacement du Master Data Management dans les solutions SharePoint ?
La question peut se poser puisque Copilot M365 est une IA générative de texte, qui permet de capitaliser sur des contenus textuels, tapuscrit ou OCR-isé avec SharePoint Syntex (SharePoint Premium) ou transcrit depuis les réunions Ms Teams. C’est le fameux modèle LLM de ChatGPT qui a ainsi fait l’objet de l’intérêt de Microsoft dans son rapprochement avec OpenAI.
Cependant, avant que le prompt soit traité dans le modèle LLM, le prompt « passe » dans le Microsoft Graph, comme une requête adressée au moteur de recherche : cela permet de s’assurer de ne présenter que des données auxquelles vous avez accès.
Cela signifie aussi qu’une requête de recherche va « passer au travers du schéma de recherche » car, comme vu précédemment dans l’épisode 3 de la série « SharePoint et la GED », les métadonnées SharePoint vont permettre d’augmenter l’expérience utilisateur non seulement en termes de filtres à facette mais également en alimentant l’index de recherche, au-delà du contenu plein-texte indexé par le moteur de recherche. En termes de calcul de pertinence, ces colonnes de métadonnées possèdent même un poids supérieur au contenu plein-texte indexé.
Actuellement, Copilot M365 ignore quant à lui le schéma de recherche et ses colonnes gérées et, par conséquent, le magasin de termes.
Microsoft y travaille : quand Microsoft explique le fonctionnement de Copilot M365, le concept d’index sémantique est mis en avant, pour améliorer la qualité de la proposition formulée par Copilot.
Améliorer la qualité avec l’index sémantique
Ce concept avait été aperçu avec Project Cortex et Viva Topics (billet datant de 2020), que Microsoft a décidé de décommissionner en janvier 2025 au profit de Copilot M365 : le concept d’index sémantique ouvre le champ à la recherche par vectorisation, i.e. un traitement d’enrichissement de l’index de recherche au travers de regroupement logiques. Comme Microsoft l’écrit dans la page de learn.microsoft.com, « Cela signifie qu’au lieu d’utiliser des méthodes traditionnelles pour interroger en fonction de correspondances exactes ou de critères prédéfinis, l’index sémantique peut trouver les données les plus similaires ou pertinentes en fonction de la signification sémantique ou contextuelle.«
Cela se traduit par le concept plus connu de « recherche floue », qui devrait pouvoir se gérer sur base de règles de type :
- Référentiel documentaire traditionnel, pour gérer des synonymes et des acronymes dans des thesaurus par Métier, de manière à pouvoir spécifier que 2 choses sont égales, pareilles (exemple : « Delflopion » = « pomme »),
- Référentiel logique, pour gérer des types de concept, de manière à indiquer le type d’une chose (pomme [enfant] = fruit [parent]),
- Référentiel relationnel, pour gérer la relation hiérarchique entre 2 choses (pomme < pommier commun ou domestique ou Malus x.domestica < famille Rosaceae <…).
Peut-être que vous avez pensé au magasin de termes en lisant ces dernières lignes ; comme évoqué plus tôt, on peut effectivement imaginer qu’il va être essentiel dans la gestion de l’index sémantique.
Cela améliora la qualité des réponses du moteur de recherche et, par contagion, celle de la pertinence de l’IA générative.
Après la qualité, un second aspect d’amélioration est de jouer sur la quantité. Explications
Améliorer en jouant sur la quantité ?
Que signifie jouer sur la quantité ?
Depuis que j’utilise Copilot M365 et ai réalisé mes premiers Copilots spécialisés via Copilot Studio (épisode 5 de la série « SharePoint et la GED »), je me suis intéressé à la façon dont fonctionne le robot d’indexation de ChatGPT, baptisé « GPTBot », même si c’est désormais l’indexation de SharePoint qui alimente Microsoft Graph :
- Le robot a été entrainé pour traiter des pages Web, donc des documents « courts » par rapport à des fichiers Office ou PDF qui peuvent compter couramment des centaines de page ;
- A ma connaissance, tout le contenu est indexé « à plat », sans conserver la structure HTML/XML des informations textuelles.
Sur la base de ces deux constats, dans le but d’optimiser le traitement de LLM, j’ai coutume de privilégier les fichiers courts.
Par exemple, pour mettre en place un Copilot spécialisé sur des problématiques de FAQ Ressources Humaines, je préfère éclater les documents de référence volumineux qui m’ont été transmis pour créer de plus petits documents en me basant par exemple, sur les chapitres principaux (style Titre 1 d’un document Word).
Alors Microsoft a fini par communiquer officiellement que le modèle LLM ChatGPT 4.0 utilisé par Copilot M365 n’est pas (encore) calibré pour les gros documents (https://support.microsoft.com/en-au/topic/keep-it-short-and-sweet-a-guide-on-the-length-of-documents-that-you-provide-to-copilot-66de2ffd-deb2-4f0c-8984-098316104389) : pas plus de 20 pages, pas plus de 15.000 mots… et Microsoft travaille pour relever ces paramètres.
Voici comment je travaille sans pour autant me lancer dans la personnalisation d’un modèle de LLM avec Microsoft Azure AI Studio ou un autre service Microsoft Azure.
Voici comment s’achève ce billet décrivant mes premiers retours sur la performance de Copilot M365 et les contenus SharePoint.
D’autres billets suivront à chacune nouveauté majeure qui se produira sur ce thèmedans le prochain billet.Platform, j’ai publié un livre intitulé « SharePoint et la Power Platform ».