00:00:00 Introduction à l’interview
00:01:00 Le parcours de Rinat chez Lokad et les défis de la supply chain
00:03:59 L’évolution de Lokad et les aperçus de simulation
00:07:07 Complexités de simulation et décisions basées sur des agents
00:09:15 Introduction des LLMs et optimisations de simulation
00:11:18 L’impact de ChatGPT et catégories de modèles
00:14:14 Les LLMs comme outils cognitifs en entreprise
00:17:10 Les LLMs améliorant les interactions avec les clients et les listings
00:20:30 Le rôle limité des LLMs dans les calculs de supply chain
00:23:07 Les LLMs améliorant la communication dans les supply chains
00:27:49 Le rôle de ChatGPT dans l’analyse des données et la production d’insights
00:32:39 Le traitement de texte par les LLMs et défis quantitatifs des données
00:38:37 Affinement de la recherche en entreprise et clôture des insights IA
Résumé
Dans un dialogue récent, Conor Doherty de Lokad a conversé avec Joannes Vermorel et Rinat Abdullin au sujet de l’impact de l’IA générative sur les supply chains. Vermorel, PDG de Lokad, et Abdullin, consultant technique, ont discuté de l’évolution de la prévision des séries temporelles à l’exploitation des Large Language Models (LLMs) comme ChatGPT. Ils ont exploré le potentiel des LLMs pour automatiser des tâches, améliorer la productivité et aider à l’analyse des données sans supprimer des emplois. Alors que Vermorel restait prudent quant aux LLMs en planification, tous deux ont reconnu leur utilité pour composer des solutions. L’interview a souligné le rôle transformateur de l’IA dans la gestion de la supply chain et l’importance d’intégrer les LLMs avec des outils spécialisés.
Résumé Étendu
Dans une interview récente, Conor Doherty, responsable des communications chez Lokad, s’est engagé dans une discussion stimulante avec Joannes Vermorel, PDG et fondateur de Lokad, et Rinat Abdullin, consultant technique chez Trustbit et ancien CTO de Lokad. La conversation s’est centrée sur le domaine en pleine expansion de l’IA générative et ses implications pour la gestion de la supply chain.
Rinat Abdullin, évoquant son passage chez Lokad, a rappelé les premiers défis rencontrés par l’entreprise, notamment l’alignement entre la technologie et ce que le client voulait et avait réellement besoin, ainsi que la nécessité de rendre les données complexes de la supply chain compréhensibles et fiables. Joannes Vermorel a confirmé que les racines de Lokad se trouvaient dans la prévision des séries temporelles, un élément essentiel dans l’optimization de la supply chain.
Au fur et à mesure de la conversation, Abdullin a détaillé l’évolution de la technologie de Lokad, soulignant la tension entre l’explicabilité et la performance des modèles de machine learning. Il a partagé ses expériences dans l’utilisation de simulations pour démystifier des systèmes complexes, ouvrant la voie à des méthodes computationnelles plus optimisées.
La discussion s’est ensuite orientée vers les Large Language Models (LLMs), Vermorel notant leur récente montée en popularité. Abdullin a évoqué ses premières expériences avec les modèles de langage et leur évolution vers des outils conviviaux comme ChatGPT. Il a souligné le potentiel transformateur des LLMs, les comparant à un département d’assistants capable d’accomplir une variété de tâches, de la rédaction de documents à l’automatisation de la recherche d’informations au sein de vastes silos.
Abdullin a abordé les inquiétudes concernant le remplacement d’emplois par les LLMs, affirmant qu’ils accroissent l’efficacité des employés plutôt que de les remplacer. Il a cité des exemples où la productivité a été multipliée par dix, voire par cent. Il a également noté que, bien que les supply chains aient été lentes à adopter les LLMs, les départements marketing les ont rapidement utilisés pour les interactions avec les clients et la réduction des coûts.
Joannes Vermorel a développé le potentiel des LLMs pour automatiser les communications ouvertes avec les partenaires de la supply chain, économisant du temps sur les courriels de routine et permettant de se concentrer sur des tâches plus complexes. Il a salué la finesse linguistique des LLMs dans l’ajustement du ton des communications, une tâche qui peut être chronophage pour les humains.
Abdullin a mis en avant les capacités avancées d’analyse de données de ChatGPT, qui permettent aux décideurs d’analyser des données complexes sans nécessiter de compétences en programmation. Cependant, Joannes Vermorel est resté sceptique quant à l’IA générative en planification de supply chain, soulignant que les LLMs sont mieux adaptés pour générer des analyses et rapports jetables.
Rinat Abdullin a suggéré que les LLMs pourraient être utilisés en complément d’outils spécialisés pour obtenir de meilleurs résultats, en particulier à l’intersection des domaines numérique, textuel et du code. Joannes Vermorel a confirmé, précisant que les LLMs sont mieux adaptés pour composer des programmes résolvant des problèmes plutôt que pour les résoudre directement.
Pour conclure, Rinat Abdullin a encouragé les entreprises à adopter les LLMs, car ils peuvent apporter une valeur significative lorsqu’ils sont combinés à des outils spécialisés. Conor Doherty a clôturé l’interview en remerciant Joannes et Rinat pour leurs éclairages sur le domaine dynamique de l’IA générative et son rôle dans la configuration de l’avenir de la supply chain.
Transcription Complète
Conor Doherty: Bienvenue à nouveau sur Lokad TV. Les avancées réalisées en IA générative au cours des 12 derniers mois constituent un exploit extraordinaire de progrès technologique. Les LLMs, ou large language models, sont passés d’une niche à un usage grand public en moins d’un an. Pour expliquer cette importance, notamment dans un contexte de supply chain, se trouve le tout premier CTO de Lokad, Rinat Abdullin. Rinat, bienvenue chez Lokad.
Rinat Abdullin: C’est un plaisir et un honneur d’être de retour. J’étais chez Lokad quand tout a commencé dans une petite pièce, je crois, à l’université. Et parmi toutes les entreprises avec lesquelles j’ai travaillé depuis, y compris sept startups, Lokad a été l’endroit le plus challengeant et gratifiant de ma vie.
Conor Doherty: Il n’est pas nécessaire de parler directement de Joannes, mais quand tu disais que c’était le plus challengeant, qu’est-ce qui rendait exactement Lokad si difficile ? Et ensuite, par contraste, quelle est la difficulté des projets futurs ?
Rinat Abdullin: Nous étions une startup à l’époque, et c’était une combinaison intéressante entre la recherche du bon alignement entre les technologies et ce que le client voulait réellement, et le véritable besoin de ce dernier. Équilibrer ce triangle fut toujours un défi puisque les technologies étaient alors naissantes. Nous étions parmi les premiers grands clients d’Azure, venants tout juste de commencer à développer une bibliothèque distribuée pour traiter un grand nombre de prévisions des séries temporelles de clients. Il n’y avait aucun support ; tout devait être construit à partir de zéro, et ce parcours a duré de nombreuses années. Cela s’est poursuivi avec la création d’un DSL personnalisé pour autonomiser les experts de Lokad, et cela continue encore aujourd’hui. C’est l’une des faces du triangle. La deuxième était que les clients souhaitaient obtenir de meilleurs chiffres, qu’ils voulaient voir leur entreprise fonctionner de manière prévisible sans argent immobilisé dans le stock. En même temps, ils désiraient que ces chiffres soient compréhensibles car, si vous fournissez aux clients des chiffres issus d’une boîte noire magique, les cadres pourraient dire : “Oui, ça marche”, tandis que les experts de supply chain dans les warehouses locaux diraient : “Je ne comprends pas ces chiffres. Je ne fais pas confiance aux formules, et mon intuition, forgée par 10-20 ans d’expérience, me dit que non, cela ne marchera pas, donc je vais ignorer cela.” Et, évidemment, vous ne pouvez pas licencier tout le monde. Équilibrer ces trois aspects a été un défi chez Lokad et avec tous les clients avec lesquels j’ai travaillé par la suite.
Joannes Vermorel: En écoutant Rinat, on évoquait le fait que nous travaillions avec des séries temporelles, est-ce exact ?
Rinat Abdullin: Oui, Lokad a littéralement été fondée en tant que service de prévision des séries temporelles, donc je m’y connais en séries temporelles, même si nous nous en sommes éloignés par la suite. Nous avons toujours travaillé avec des séries temporelles, qui constituent un élément de base. La tension concernant l’explicabilité dont il a été question a finalement été résolue, mais plus d’une décennie après la fondation de Lokad. Nous avons dû adopter la programmation différentiable afin d’obtenir enfin des modèles de machine learning explicables. Cela est arrivé très tard. Pendant des années, nous avions le choix entre des modèles bruts qui étaient en boîte blanche mais peu performants, ou des modèles de machine learning meilleurs mais en boîte noire, créant de nombreux problèmes opérationnels. Parfois, ils n’étaient pas naturellement meilleurs selon toutes les dimensions du problème. Ce fut une lutte immense, et le parcours de Lokad a été presque une décennie de combats acharnés. J’ai vécu la première moitié de ces combats pendant environ cinq ans, puis d’autres ont continué à se battre pour les étapes suivantes. Ce fut une très longue série de problèmes massifs à résoudre.
Conor Doherty: Merci, Rinat. Pour revenir à toi, quand nous essayons d’expliquer ce que fait Lokad, c’est à travers une série d’articles très longs, de conférences et de discussions comme celle-ci. Mais quand on tente de rendre le machine learning explicable dans ce contexte, comment t’y prends-tu ?
Rinat Abdullin: L’une des approches qui a très bien fonctionné lorsque j’ai aidé à organiser un hackathon pour une entreprise logistique internationale a été celle des simulations. Quand on parle de logistique internationale, il y a de nombreuses variables en jeu. Vous avez des cargaisons devant être transportées entre plusieurs emplacements en utilisant divers modes de transport. Vous avez des compagnies de camionnage et d’autres entreprises qui se font concurrence sur le marché ouvert pour les livraisons de cargaisons de l’emplacement A à l’emplacement B. Ensuite, il y a les itinéraires réels de livraison, comme les routes, les réseaux ferroviaires, voire la livraison du dernier kilomètre. Au fur et à mesure que les camions transportent les cargaisons entre ces emplacements, il y a retards, embouteillages, et la cargaison peut arriver dans un entrepôt en dehors des heures d’ouverture, ou bien la zone de déchargement de l’entrepôt peut être saturée.
Nous voulions modéliser toute cette complexité de manière accessible aux étudiants ou aux nouveaux employés. Ce que nous avons fait était assez brut. C’est peut-être très similaire à la façon dont les anciens chercheurs tentaient de modéliser le nombre pi en lançant une pièce dans une simulation. Nous avons donc construit une carte virtuelle de l’Europe avec des routes principales, et dans cette carte, les routes avaient des longueurs, le temps s’écoulait, les camions allaient et venaient, et les compagnies de camionnage pouvaient décider quelle cargaison prendre et s’ils la livreraient à temps. C’était le point d’entrée pour les participants au hackathon, car ils pouvaient programmer des agents pour prendre des décisions telles que : “Je suis le chauffeur de camion A, et je vais prendre cette cargaison de l’emplacement A à l’emplacement B.” Mais il y avait une subtilité : lorsqu’un camion transporte une cargaison d’un emplacement à un autre, comme dans la réalité, cela coûte de l’argent. Pour gagner de l’argent, il faut payer des taxes, du carburant, et veiller à ce que le conducteur se repose.
Parce que c’est une simulation, il n’est pas nécessaire d’utiliser des formules complexes ; vous reproduisez la réalité de manière brute. Vous exécutez simplement un script batch pour des NPC ou dans un jeu de manière séquentielle, et vous pouvez obtenir de nombreuses règles explicables sur une feuille de papier. Cet univers était si compréhensible pour les gens que nous avons en réalité conçu deux niveaux de difficulté. Au premier niveau, les entreprises se contentaient de conduire des camions pour gagner le maximum d’argent. Au deuxième niveau, les prix du carburant augmentaient légèrement, les entreprises devaient compenser les émissions de CO2, et les chauffeurs de camion pouvaient se fatiguer. Si un chauffeur conduisait pendant plus de 12 ou 14 heures, le risque d’accident augmentait. Lorsqu’un accident survenait, le chauffeur entrait en repos, et le camion ne faisait essentiellement rien, perdant ainsi du temps.
Nous avons pu lancer rapidement de nombreuses simulations et dire : “Hé, équipes, les décisions que vos agents prenaient dans ce monde virtuel correspondaient à la distribution du délai d’approvisionnement, à la distribution des prix, aux marges et au nombre d’accidents enregistrés par vos agents.” C’est essentiellement l’approche que j’adopte lorsque j’ai besoin d’expliquer un environnement complexe. On commence d’abord par la simulation, car elle est ludique et permet d’expliquer facilement les règles, sans recourir à la programmation différentielle. Mais quand vous lancez cette simulation, c’est en réalité une analyse de Monte Carlo qui suit les dépendances dans des systèmes complexes. Cela signifie que, par exemple, dans certains cas, vous n’obtenez pas une distribution simple en surface, mais, en raison des interférences entre plusieurs éléments du système, vous observez des motifs d’interférences dans les distributions externes. Cela ressemble à une boîte noire, mais les gens peuvent comprendre les règles, les modifier, et alors, par exemple, si une entreprise comprend finalement comment fonctionne cet environnement et qu’elle apprécie les chiffres obtenus – même si la simulation prend toujours du temps –, il existe alors un moyen d’optimiser le calcul en disant : “D’accord, voici les chiffres de la simulation, passons à la programmation différentielle directement avec les probabilités pour obtenir les mêmes résultats, mais plus rapidement.” C’est tout simplement une optimisation de performance.
Joannes Vermorel : Ce qui est très intéressant, c’est que durant l’année dernière, une nouvelle classe d’outils, les LLMs, est devenue disponible, et c’est très intéressant parce que cela représente littéralement une classe entière de technologies qui existent depuis environ une demi-décennie, mais qui étaient très spécialisées et que seuls des experts pouvaient réellement évaluer en raison du fait qu’à l’époque, il s’agissait surtout d’un potentiel théorique. Peut-être, Rinat, comment vois-tu le changement apporté par l’introduction de cette classe d’outils, les LLMs ? Comment compares-tu cela ? Nous avions différentes classes d’outils pour le machine learning en entreprise, comme la classification, la régression, les simulations Monte Carlo. C’étaient des classes d’outils qui pouvaient être mises ensemble, et maintenant nous avons une autre classe d’outils complètement différente, les LLMs. Peut-être, pour le public qui ne serait pas familier avec les LLMs à part ChatGPT, comment abordes-tu cela dans le contexte des enterprise software, des workflows d’entreprise ? Quelle est ta vision globale à ce sujet ?
Rinat : Je suis en contact avec les modèles de langage depuis 2015, avant l’apparition du chatbot qui les a popularisés. Tu as raison, ils étaient vraiment de niche. Ils étaient utilisés dans les traducteurs automatiques, la reconnaissance vocale, et dans les modèles de langage qui corrigent les fautes d’orthographe ou aident à trouver un texte dans de vastes corpus. Lorsqu’ils sont apparus via ChatGPT, leur popularité a explosé. L’une des raisons est qu’ils ont été entraînés pour être utiles et obéissants envers les utilisateurs.
Et c’est en fait parfois la raison pour laquelle ils sont si irritants, car lorsque tu veux obtenir un résultat du modèle et qu’il commence à s’excuser, en disant « je suis désolé » de façon répétée, cela peut être frustrant. Dans ma manière de voir, je sépare essentiellement les modèles à grande échelle en deux catégories. D’une part, les modèles qui travaillent principalement avec des nombres, donc on parle de régressions, de Monte Carlo, de réseaux de neurones. D’autre part, la classe des modèles, qui sont les large language models (LLMs) : oui, ils travaillent avec des nombres, mais en surface, ils travaillent avec du texte, de larges textes non structurés, et c’est là que réside leur véritable utilité.
Ces modèles permettent de brancher directement une machine ou une automatisation dans les interactions humaines. Par exemple, avec les régressions ou les séries temporelles, il faut insérer le modèle quelque part au milieu des processus digitaux de l’entreprise. Il y a une base de données d’un côté, un moteur de prévision au milieu, et peut-être une base de données ou un CRM ou un ERP de l’autre côté. Dans le meilleur des cas, tu obtiens un rapport, mais ce sont toujours des nombres. Avec les LLMs, tu te branches directement au cœur du processus d’entreprise, au milieu des workflows humains.
Cela ouvre tellement de possibilités, surtout puisque l’implémentation de quelque chose qui était complètement impossible ou très coûteux il y a une décennie ne demande pas beaucoup d’efforts. Par exemple, personnellement, quand je travaille avec les LLMs, je commence à avoir l’impression d’avoir mon propre département privé d’assistants. Ils sont polyglottes, full-stack, parfois naïfs, mais ils sont aussi intelligents, et ils ne se plaignent jamais. Par exemple, leur demander de déplacer un bouton sur une maquette ou de réécrire une lettre à un magistrat en Allemagne est très utile, très obéissant, parfois un peu idiot, mais ils peuvent accomplir de grandes choses.
Dans les cas d’adoption des LLMs en entreprise que j’ai observés, cela se fait surtout dans ce qu’ils appellent la digitalisation des entreprises. Cela aide les sociétés à automatiser des workflows centrés sur la recherche de texte dans un vaste corpus. Par exemple, une entreprise possède beaucoup de données, elle dispose de ses bases de connaissances, mais ces bases restent essentiellement des silos. Cela peut être des RFCs, des questionnaires, ou une Wikipédia que personne ne met vraiment à jour, et les gens doivent réaliser une activité qui nécessite parfois de trouver de l’information dans des endroits obscurs. Cela demande du temps, des efforts, et surtout de l’énergie cognitive.
Ce que les LLMs peuvent faire, c’est accomplir un travail préparatoire. Ils peuvent rédiger des articles, mener des recherches sur les données privées de l’entreprise en disant : « D’accord, tu compiles cette réponse pour l’entreprise, donc en te basant sur les workflows de ton entreprise et les prompts codés, voici mon brouillon. » Pour chaque élément de cette checklist de réponse, ils peuvent montrer d’où provient l’information. Ainsi, la personne n’a plus besoin d’effectuer le travail de routine et peut se consacrer à un travail intellectuellement plus exigeant consistant à vérifier si le modèle a bien fait quelque chose. Cela permet de faire évoluer de façon massive l’efficacité d’une entreprise.
Lorsque ChatGPT est apparu, les gens craignaient vraiment que les LLMs et l’IA leur volent leur emploi, mais ce n’est pas le cas. Crois-moi, j’aide des clients à créer des produits alimentés par les LLMs et le ML depuis un bon moment, et il faut beaucoup d’efforts pour produire quelque chose qui pourrait remplacer un humain. C’est presque impossible. Mais ce que les LLMs peuvent faire, c’est rendre les employés existants plus efficaces, parfois jusqu’à 10 à 100 fois plus efficaces. Ce sont des cas exceptionnels. Ils rendent simplement les gens plus efficaces, mais ils ne pourront jamais les remplacer. Il doit toujours y avoir des personnes dans la boucle.
Conor : Merci, Rinat. Joannes, qu’en penses-tu ? Je veux dire, quand j’observe les supply chains, je dirais qu’elles fonctionnent à peu près moitié-moitié. La moitié des personnes utilisent des tableurs, et l’autre moitié communique de manière banale avec des partenaires, des fournisseurs, des clients, etc. Les tableurs, c’est vraiment question d’automatiser la décision de quantité, c’est ce que fait Lokad depuis une décennie. La deuxième partie n’était pour la plupart pas automatisée parce que, avant l’avènement des LLMs, il n’existait aucune technologie réellement plausible pour y répondre.
Rinat : D’après mon expérience, les supply chains adoptent les LLMs au cœur du processus de manière un peu lente. Les LLMs commencent plutôt à s’immiscer par l’extérieur. Ainsi, un cas courant est que les départements marketing sont généralement les premiers adoptants. Lorsqu’une entreprise a, par exemple, une interface avec les utilisateurs, la limite entre l’entreprise et les utilisateurs, les clients, c’est là que j’ai vu l’adoption la plus massive. Par exemple, il existe des marketplaces qui vendent des produits à leurs clients, et elles veulent rendre cette interaction plus agréable et peut-être réduire le coût de cette interaction avec les clients.
Il est déjà tout à fait faisable de construire des systèmes qui parcourent automatiquement les catalogues de produits un par un, sans relâche, 24 h/24 et 7 j/7, et qui détectent, « D’accord, ceci est un produit, mais il a été saisi de manière incorrecte par le vendeur de la supply chain. » Pourquoi ? Parce que j’ai fouillé sur Internet, j’ai trouvé les spécifications de ce produit, qui sont similaires, j’ai aussi trouvé la description PDF du fabricant du produit, et d’après moi, environ la moitié d’Internet a ce numéro correct, alors que toi, tu as ce numéro erroné. Voici les références. Merci de prendre une décision si tu dois le corriger automatiquement. « Oh cher manager, j’ai vu que vous avez corrigé cette description de produit, cette propriété du produit. Voulez-vous que je régénère la description du produit pour avoir le numéro mis à jour, non seulement le numéro mais aussi le texte ? » Et pendant que tu y es, j’ai créé trois descriptions de produit pour que tu puisses choisir celle qui a du sens. J’ai également créé un texte marketing SEO, mis à jour les mots-clés sur ton moteur de publication, et j’ai aussi réalisé une annonce sur Twitter et LinkedIn.
Un autre point d’interface entre les clients et les détaillants qui se branchent à la supply chain, c’est la fiche produit sur les marketplaces. Imagine que tu es un vendeur qui doit travailler avec de nombreuses marketplaces, et que ton catalogue compte 10 000 articles avec de petites variations, comme des pièces de voiture ou des pièces d’avion. Tu veux automatiser ce processus, surtout si tes propres stocks changent assez rapidement. C’est tout à fait faisable, et j’en ai déjà vu l’exemple. Par exemple, tu obtiens quelques images du produit, surtout s’il s’agit de produits réutilisés, notamment dans la mode, cela fonctionne très bien. Tu les passes par une reconnaissance d’images, qui performe mieux lorsqu’elle est entraînée sur la mode et le style. Tu obtiens les textes, les descriptions, tu choisis les encadrés, redimensionnes automatiquement les images, et à partir de cela, tu génères une description pour les personnes.
Ensuite, vient l’un des aspects les plus sympathiques. Tu crées également une description cachée augmentée par LLM qui est utilisée pour la recherche sémantique. Qu’est-ce que cela signifie ? Ainsi, lorsqu’un client d’une plateforme de mode cherche une pièce de vêtement, il ne cherchera pas toujours, par exemple, une chemise de style bohème avec des dragons, en taille M et à moins de 10 $. Il cherchera plutôt, « Hé, je vais à une soirée ce soir, et mes amis seront là, que puis-je porter pour compléter mon short ? » Si tu disposes de descriptions de produit et d’explications sémantiques extraites par les LLMs à partir du produit, et que tu les recherches, mais pas en texte intégral parce que qui sait comment les gens écrivent « bohème », mais que tu utilises une recherche par embeddings, qui est essentiellement une recherche vectorielle, c’est-à-dire une recherche sur le sens du texte, et non sur le libellé exact, alors tu obtiendras des résultats qui, de l’extérieur, semblent presque magiques car le modèle commence d’une manière ou d’une autre à suggérer ce que tu voulais demander, et non ce que tu as dit.
Conor : Merci, Rinat. Joannes, quelles sont tes impressions ? Je veux dire, quand j’observe les supply chains, je dirais qu’elles fonctionnent à peu près moitié-moitié. La moitié des personnes utilisent des tableurs, et l’autre moitié passe son temps en communications banales avec des partenaires, des fournisseurs, des clients, etc. Pour les tableurs, il s’agit vraiment d’automatiser la décision de quantité, c’est ce que fait Lokad depuis maintenant une décennie. La seconde partie n’était pour la plupart pas automatisée parce que, jusqu’à l’avènement des LLMs, il n’existait aucune technologie réellement plausible pour répondre à cela.
Joannes : C’est-à-dire que ce qui requiert de la communication, que ce soit dans un workflow très resserré qui peut ensuite être automatisé – automatisé via, disons, l’EDI pour transmettre une commande. Nous allons avoir un pont qui transmet la commande, et ensuite nous avons un problème non textuel. Mais ce n’est pas exactement ce que les gens veulent dire quand ils affirment passer la moitié de leur temps sur des tableurs et l’autre moitié à gérer des partenaires, des clients, des transporteurs, des fournisseurs. C’est plus du genre : « Pourriez-vous accélérer cette commande et, si oui, à quel tarif ? » C’est plus flou et ouvert.
Il faut prendre ce cas particulier et rédiger un email à ce sujet, en clarifiant en quelque sorte l’intention, ce qui est en jeu, et cela prend une demi-heure. Puis tu recommences avec une situation différente, un problème différent, et tu rédiges un autre email. Tu te retrouves avec un service des achats où tout le monde, pendant huit heures de travail, passe quatre heures sur ses tableurs et quatre heures à écrire 20 emails à 20 partenaires. Là, je vois un énorme potentiel d’amélioration. Lokad automatise littéralement déjà la première partie, mais avec les LLMs, il y a un énorme potentiel pour automatiser largement, mais pas complètement, la seconde partie. Essentiellement, permettre aux gens, je dirais, de donner leur soutien pour composer automatiquement des communications qui seront reçues par tes partenaires. Le LLM a été utilisé pour fournir une version assez contextualisée de l’énoncé du problème et de ce que nous attendons du partenaire.
Si l’énoncé du problème a des limites bien définies, alors tu as l’EDI ; cela devient simplement une partie de ton workflow entièrement mécanisé. Mais je parle de ce qui reste, des choses qui ne sont pas tout à fait alignées, comme lorsque tu commandes 1 000 unités et qu’ils te livrent 1 050. Tu ne vas pas rejeter la commande parce qu’ils ont livré 50 unités de trop. Tu apprécies ce fournisseur, alors tu vas accepter et valider la commande, tu la recevras, et tu paieras pour 1 050 unités au lieu de 1 000. Mais tu souhaites communiquer de manière polie à ton fournisseur que tu préférerais qu’il respecte l’accord initial, qui était de livrer 1 000 unités et non 1 050. Il y a une nuance ici : tu ne veux pas perturber le workflow ; c’est quasi-correct, mais tu veux tout de même faire comprendre que ce n’est pas acceptable de toujours livrer 5 % de plus pour que le fournisseur puisse te facturer un peu plus.
C’est exactement le genre de situation dans laquelle les LLMs excellent, ce genre de communication douce où il faut transmettre un message. Il faudrait du temps pour équilibrer la formulation afin que ce ne soit pas trop agressif, tout en faisant comprendre au partenaire que tu as une forte préférence pour qu’il respecte strictement la quantité initialement convenue. C’est le genre de tâche où quelqu’un pourrait tergiverser pendant une heure sur un email pour rédiger ce paragraphe, et c’est précisément le genre de chose que, avec les LLMs modernes, ils font en quelques secondes. Le type d’intelligence que possèdent ces LLMs est avant tout linguistique, et si tu veux établir le bon ton, ils ont presque des capacités surhumaines. Ils ne sont pas forcément super intelligents au point de saisir la vue d’ensemble ou la direction globale, mais si tu veux obtenir le même texte avec une nuance un peu plus appuyée, comme « je veux le même texte mais un peu plus agressif, ou un peu plus doux, ou un peu plus soutenant », ils sont excellents pour cela.
Il te faudrait peut-être 20 minutes pour le faire pour une demi-page, et un LLM peut le faire littéralement en quelques secondes. C’est exactement le genre de chose qui peut constituer un énorme gain de productivité pour ces ajustements subtils pour lesquels les gens passent littéralement des heures. Si l’on prend cela à un niveau supérieur, imagine une entreprise qui a des milliers de communications de ce type concernant des cas particuliers tout au long de la journée. C’est une nouvelle capacité qu’apportent les LLMs. Pour les chefs d’entreprise, pour les parties prenantes, pour avoir une vue d’ensemble, cela demande des efforts, mais maintenant nous avons des LLMs qui sont très efficaces pour analyser d’énormes quantités de textes non structurés et en détecter des motifs. Imagine qu’un LLM puisse réellement lire des centaines de rapports ou d’emails ou d’échanges concernant le fait de ne pas envoyer 5 % supplémentaires et, à la fin de la journée, fournir un résumé succinct aux dirigeants en disant : “Hé, il semble que nous ayons ici un schéma récurrent dans lequel de plus en plus de fournisseurs, la semaine dernière, ont essayé de nous envoyer plus de stocks.”
Comme tu le sais, ChatGPT possède une capacité incroyable appelée advanced data analytics, et c’est littéralement comme avoir un département d’analystes de données sous ton contrôle. Ils ne sont pas experts en supply chain, donc tu auras toujours besoin de Lokad pour cela, mais ce que tu peux faire, c’est leur poser des questions simples comme : “Voici mon fichier de base de données, voici mon fichier Excel, effectue une analyse pour moi et repère les tendances.” C’est la partie incroyable qui est possible principalement en ligne. Tu ne peux pas l’exécuter localement ou via l’API, mais ChatGPT va proposer des théories, écrire du code, l’exécuter, peut-être rencontrer des erreurs, les corriger, afficher les résultats, et même créer un graphique pour toi. L’ensemble du processus, depuis le moment où tu lui envoies un tableur Excel et une question jusqu’au joli graphique, est entièrement automatisé. Il s’auto-corrige, s’auto-répare, et tu obtiens de très bons résultats. Cela offre aux décideurs une capacité à analyser les données par eux-mêmes, même si les données sont stockées dans des systèmes complexes, pour les visualiser sans avoir besoin de connaître Python, JavaScript, C ou SQL. Je trouve que c’est vraiment responsabilisant et que cela ouvre de nouvelles opportunités commerciales et crée de la nouvelle valeur pour l’entreprise.
Conor: Il y a environ six mois, nous avons eu une discussion sur l’IA générative et son rôle dans la supply chain, et dans l’ensemble, nous étions quelque peu sceptiques. Quand vous écoutez ce qui a été décrit concernant les progrès réalisés au cours des six derniers mois, avez-vous toujours le même point de vue, ou vous êtes-vous adouci un peu ?
Joannes: Ma position reste profondément sceptique sur certains aspects. Mon scepticisme était essentiellement une réaction à la part des concurrents de Lokad qui disent, “Nous allons simplement appliquer ChatGPT directement à des téraoctets de données transactionnelles, et ça marchera.” Mon opinion est non, je ne pense pas. Je reste très sceptique car ce n’est littéralement pas le cas. Si vous affirmez que ce que vous pouvez faire est de lister quelques tableaux avec des schémas, ou de faire en sorte que l’outil interroge automatiquement le schéma de la base de données pour calculer des analyses jetables comme la taille moyenne du panier, alors c’est une proposition complètement différente. Par le passé, cela aurait dû être traité par l’équipe de business intelligence. Je parle de choses basiques comme, quelle est la taille moyenne du panier, combien de temps en moyenne conservons-nous nos clients, combien d’unités avons-nous vendues en Allemagne — des questions très basiques. Dans les grandes entreprises, vous avez généralement des dizaines de personnes dans les divisions BI produisant des rapports jetables toute la journée. Pour ce genre de choses, je crois que les LLMs peuvent réellement aider, mais ce n’est absolument pas ce que proposent nos concurrents. Ils disent, “Vous avez ces modèles, vous leur donnez votre base de données d’un téraoctet, vous leur donnez accès à Twitter et Instagram, et vous avez votre planification, votre prise de décision, le tout, et c’est entièrement automatisé.” Je dis non, pas même près du tout. Nous sommes dans le monde de la fantaisie.
Rinat: En ce qui concerne votre réponse à ce défi, j’ai deux réflexions à partager. D’abord, sur le processus d’utilisation des LLMs pour traiter de grandes quantités de données, je travaille avec divers LLMs depuis un bon moment. L’une des premières questions que les clients posent habituellement est de savoir s’ils peuvent exécuter quelque chose comme ChatGPT localement dans leurs locaux. Pour y répondre, il faut comparer les performances des LLMs dans différentes configurations et évaluer les coûts. Les LLMs sont assez coûteux. Exécuter un mégaoctet de texte à travers les LLMs pour une prédiction pourrait coûter quelques euros, selon le modèle. Si vous souhaitez l’exécuter localement sur les modèles les plus performants, cela pourrait vous coûter 10 € ou peut-être 20 €.
Et c’est ce que fait GPT-3.5 ; c’est très bon marché. Mais le fait est que l’exécution de téraoctets ou de pétaoctets de données à travers les LLMs n’est même pas possible. Deuxièmement, les LLMs sont terribles avec les chiffres. Si quelqu’un demande à un LLM d’effectuer des calculs mathématiques ou de lister des nombres premiers, c’est une mauvaise utilisation. Les LLMs sont des modèles linguistiques ; ils possèdent une vaste base de connaissances et sont très intelligents, bien qu’ils aient encore des limites. Vous ne demandez pas à un LLM de résoudre directement un problème mathématique ; vous lui demandez de formuler le problème, puis le calcul est confié à un kernel Python spécialisé ou à autre chose qui fera bien mieux que de gaspiller l’opération sur un LLM.
Les choses les plus intéressantes se produisent au carrefour de différents domaines. Par exemple, nous avons, d’une part, le vaste domaine numérique, d’autre part, du texte ou des cas limites doux et flous, et enfin le code comme troisième volet. Le code n’est pas des chiffres, ce n’est pas du texte, c’est structuré tout en étant vérifiable, et les LLMs sont exceptionnellement bons pour s’en occuper. Cela crée de nouveaux cas qui pourraient être applicables à la supply chain, repoussant encore plus loin l’applicabilité de solutions comme Lokad.
Par exemple, un cas où j’ai appliqué les LLMs pour analyser de grandes quantités de texte, au-delà des capacités des LLMs, consiste à formuler le problème pour le LLM. Par exemple, trouver du texte dans des centaines de gigaoctets de rapports annuels à travers le monde ou aider à résoudre un problème numérique sans effectuer le calcul réel. Vous élaborez une théorie sur la manière de l’aborder parce que vous êtes intelligent, vous connaissez le contexte, et ce sont les contrôles que je vous donne.
Lorsqu’il s’agit de rechercher dans une énorme base de données, je demande au LLM, dans une syntaxe spécifique, de proposer des recherches par embedding sur lesquelles je travaillerai, de générer une liste de mots-clés d’arrêt, ou une liste blanche de mots-clés qui améliorent le résultat. Ensuite, un autre système, dédié à cela et très performant pour traiter à grande échelle, prendra cette requête bien formulée provenant du LLM et l’exécutera. C’est là que se situe la meilleure partie, car les LLMs sont capables de perfectionner les recherches.
Vous revenez vers le LLM et dites, “Voici mon problème initial, voici ce que vous en avez pensé, voici la requête que vous avez formulée, et voici les résultats décevants que vous avez renvoyés. Veuillez ajuster et adapter.” Parce que travailler avec les LLMs est pratiquement gratuit, vous itérez peut-être dix fois, peut-être faites-vous une chaîne de réflexion, peut-être un arbre de réflexion, avec de bonnes décisions et de mauvaises décisions, et ensuite, cela s’améliore. Il en va de même pour les domaines numériques. Par exemple, les responsables supply chain veulent trouver une idée pour mieux équilibrer leurs stocks. En théorie, ils peuvent dire, “Voici une petite simulation de mon environnement, qui est peut-être suffisamment bonne, et voici comment vous pouvez l’ajuster. Maintenant, veuillez effectuer une résolution de contraintes floues et essayer de proposer des idées qui pourraient m’aider à mieux équilibrer mes stocks.”
C’est la possibilité qui s’ouvre lorsque vous commencez à combiner plusieurs domaines : le numérique, le code et le texte, et que vous utilisez ensemble les meilleurs outils disponibles pour chaque domaine.
Conor: Merci, Rinat. Joannes, qu’en penses-tu ?
Joannes: Juste pour clarifier pour le public, l’intéressant est que pour de nombreux problèmes, la manière d’aborder la situation avec un LLM est de dire, “Veuillez composer un programme qui résoudra le problème.” Vous ne demanderez pas, “Je veux que vous résolviez le problème.” Vous direz, “Composez un programme, et ensuite j’examinerai le programme.” Il existe d’autres astuces, comme fournir au LLM un compilateur pour vérifier si le programme compile ou un outil qui vous permet d’exécuter le programme un peu pour vérifier que le résultat est cohérent.
Il ne s’agit pas que le LLM résolve le problème directement ; c’est médiatisé. Le LLM produit un programme, puis utilise autre chose qui reste une sortie textuelle car, si vous utilisez un compilateur, ce dernier tentera de compiler le programme. Si cela ne fonctionne pas, il fournit un message d’erreur. Les LLMs adorent traiter les messages d’erreur et corriger les problèmes associés. Nous sommes bien dans le domaine du texte.
Pour la supply chain, la plupart des situations seront médiatisées. Nous voulons que le LLM compose le programme qui résoudra ce que nous essayons de faire. Par exemple, avec le problème initial de trouver le chiffre d’affaires en Belgique de l’année dernière pour des clients de plus d’un million d’EUR, le LLM ne récupérera pas les données directement depuis la base de données. Il composera une requête SQL qui sera exécutée par votre base de données elle-même. Encore une fois, médiation.
Qu’est-ce que cela signifie pour les logiciels d’entreprise ? Disposez-vous, au sein de votre environnement de logiciels d’entreprise, de plateformes qui supportent l’exécution de votre supply chain, du moins la couche décisionnelle, avec une capacité programmatique ? Le LLM ne prendra pas les données transactionnelles brutes pour produire le résultat ; il prendra l’énoncé du problème, produira un programme, et il est très polyvalent quant au type de programme qu’il peut produire. Mais ensuite, quelque chose dans votre environnement doit exécuter le programme. Quel type d’environnement de programmation pouvez-vous fournir au LLM ?
Les logiciels d’entreprise classiques ne fournissent aucun environnement en tout cas. Ils se contentent d’une base de données avec un langage que vous pouvez utiliser, mais la seule manière d’interagir avec, par exemple, un grand ERP censé vous permettre d’optimiser vos stocks, est de régler manuellement les niveaux minimum et maximum de stock levels ou les paramètres de safety stock produit par produit. Le LLM peut vous indiquer la recette à appliquer, mais si vous voulez l’appliquer, vous devrez passer par les réglages manuels de l’ERP. Si l’ERP fournit une API, il peut composer un programme qui vous permettra de le faire à grande échelle via l’API, mais c’est toujours très lourd comparé à une solution native programmatique. Cela restera médiatisé par le framework.
Cela nécessite des changements profonds et introduit la programmabilité de la solution en tant que citoyen de première classe. Autopromotion sans complexe, Lokad dispose d’une plateforme programmatique. Nous ne l’avons pas fait pour les LLMs ; c’était en grande partie le fruit du hasard, mais nous l’avons fait il y a 10 ans pour adopter cette mentalité programmatique au cœur de la plateforme et en tant que citoyen de première classe. C’était le hasard, et non une visionnaire perspicacité sur ce qui se passerait dans dix ans avec les LLMs.
Conor: Merci, Joannes. Je suis conscient du temps de chacun, donc comme d’habitude, Rinat, je te rends la parole pour une dernière réflexion. Y a-t-il quelque chose que tu souhaites dire à tous ceux qui regardent ?
Rinat: Il y a eu quelques bulles dans l’histoire, comme la bulle dot-com et la bulle financière. Les LLMs et l’IA pourraient aussi être une bulle, ou alors non. Même ma mère connaît ChatGPT et sait comment l’utiliser, ce qui est intéressant. J’encourage tout le monde à ne pas avoir peur de nos maîtres machines, car Skynet ne fonctionnera pas si facilement. En tant que personne qui essaie de stabiliser ces choses en production, c’est beaucoup d’efforts, et cela ne fonctionne pas de manière fiable facilement. Alors, d’abord, n’ayez pas peur des LLMs, et ensuite, adoptez-les simplement. Les LLMs associés aux humains et aux entreprises peuvent créer beaucoup plus de valeur, surtout lorsqu’ils sont complétés par des outils spécialisés comme la prévision de Lokad qui s’intègre vraiment bien dans l’environnement.
Conor: Merci, Rinat. Joannes, merci beaucoup pour ton temps. Rinat, merci beaucoup de nous avoir rejoints à nouveau. Et merci à tous de nous avoir regardés. On se revoit la prochaine fois.
