Pourtant, sous le vernis des relations publiques et de l'alignement politique national, se glisse un aveu de taille :

« Aujourd’hui, nous ne possédons pas encore les meilleurs modèles de langage, mais nous avons constamment réduit cet écart. »

Cette phrase est une clé de lecture fondamentale. Elle signe la fin de l'illusion. L’écart technologique sur le raisonnement général pur face aux géants américains ne se comble pas par la simple élégance de l'algorithme ; il se creuse sous le poids des gigawatts de serveurs et des milliards de dollars de capitalisation. Pour survivre face à la Silicon Valley, le champion européen de l'intelligence artificielle vient d'opérer un pivot stratégique discret, mais d'une envergure historique : la Palantirisation.

En choisissant de dépêcher des troupes d’ingénieurs d’élite directement chez ses clients pour faire plier ses modèles à leurs processus métiers complexes, Mistral AI abandonne discrètement le rêve de l’éditeur logiciel pur à marges infinies pour embrasser la réalité humaine, physique et réglementaire de l'économie européenne.

1. La capitulation du « Pure Software »

Pour mesurer l'ampleur de cette mue, il faut se souvenir de la promesse de départ. En juin 2023, la note stratégique d'amorçage de Mistral AI — un document fondateur de sept pages rédigé par des transfuges de Meta et de Google DeepMind — esquissait un modèle d’affaires à faire saliver les plus grands fonds de capital-risque de la planète. La startup promettait une stratégie « Open Core » articulée autour d’un effet de réseau gratuit (des modèles ouverts téléchargeables par tous) redirigeant vers leur plateforme payante d’API logicielles.

C’était la promesse du modèle SaaS classique appliqué à l'ère cognitive : un coût marginal d’inférence décroissant, des équipes ultra-légères, pas d'infrastructure physique à gérer, et des marges brutes de près de 80 %. C’est sur cette thèse de scalabilité pure que les investisseurs ont valorisé Mistral à hauteur de 12 milliards de dollars en moins de trois ans.

Mais l'IA en entreprise a une propriété physique tenace : elle ne s'auto-installe pas.

Brancher un modèle de langage générique sur un système informatique d'entreprise hérité des années 1990 (legacy), s'assurer que les données ne fuitent pas chez un sous-traitant cloud, nettoyer les bases de données sémantiques et orchestrer des flottes d'agents fiables demande un effort d'ingénierie humaine titanesque. L'IA n'est pas un logiciel fluide ; c'est une infrastructure lourde.

La réponse d'Arthur Mensch ? L'introduction officielle du modèle FDE :

« Nous les aidons avec des pro-services (FDE est le nom chic), car c’est essentiel pour assurer la réussite de nos clients. »

L'acronyme FDE — Forward Deployed Engineers — est le secret de fabrication jalousement gardé d'un autre géant de la tech américaine : Palantir Technologies. Ce modèle consiste à détacher des ingénieurs d’élite directement dans les bureaux du client (que ce soit une banque d'affaires, un constructeur aéronautique ou un ministère de la Défense) pour câbler le logiciel aux sources de données réelles.

Pour Palantir, ce modèle d’affaires a longtemps été boudé par Wall Street, qui y voyait une vulgaire activité de « société de services » à forte intensité de main-d’œuvre et à faible scalabilité. Mais aujourd'hui, c’est le seul qui fonctionne en Europe. En adoptant les FDE, Mistral admet que pour vendre de l'IA sur le Vieux Continent, il ne suffit pas de mettre à disposition une clé d'API. Il faut envoyer des hommes pour construire l'ouvrage d'art.

2. Le poids de la matière et la revente de kilowattheures

Le second axe de cette transformation est d'ordre physique et financier. Au cours du premier trimestre 2026, Mistral AI a contracté un emprunt d'un montant inédit de 830 millions de dollars auprès de la BNP Paribas. Le collatéral de cette dette ? Pas des actions, mais de la matière brute : 13 800 puces de calcul de dernière génération (les GPU Nvidia GB300).

Pour une startup logicielle, se charger d'une telle dette d'infrastructure est un pari extrêmement risqué. Si les puces dorment ou si le prix d'inférence mondial s'effondre sous le coup du dumping des tokens des géants de l'open-source (comme le chinois DeepSeek), l'entreprise risque l'asphyxie financière.

Pour honorer ses créances et générer du cash-flow immédiat, Mistral a dû descendre dans la cave. Elle est passée de créatrice de modèles à fournisseur d'électricité cognitive :

« Suite à notre investissement dans l’infrastructure de calcul, nous proposons également des services cloud d’IA hébergés. »

L'entreprise utilise désormais ses serveurs excédentaires pour faire de la revente de puissance de calcul pure (GPU-as-a-Service), louant ses puces à de grands groupes industriels européens comme ASML, Ericsson ou l'Agence Spatiale Européenne pour qu'ils y pré-entraînent leurs propres réseaux via sa plateforme de calcul Forge.

C'est une intégration verticale inversée remarquable. Pour financer ses modèles de pointe, Mistral doit se comporter comme un gestionnaire de réseau électrique, vendant du kilowattheure de calcul en même temps que du token d'intelligence.

3. La souveraineté d'orchestration : l'interdépendance du silicium

Le discours d'Arthur Mensch insiste lourdement sur un niveau de service et de sécurité « totalement découplé des fournisseurs américains ». C'est le cœur du positionnement marketing de la startup : offrir aux acteurs de l'industrie, de la santé et de l'État un environnement de confiance face à l'hégémonie de Microsoft et de Google.

Pour certains observateurs, ce grand écart entre un discours d'indépendance et la réalité matérielle (des puces Nvidia GB300 conçues en Californie et gravées à Taïwan par TSMC, une structure de capital à forte composante anglo-saxonne) relève de la contradiction.

C'est oublier une vérité fondamentale que la physique et la géopolitique des semi-conducteurs nous imposent : dans l'industrie de pointe, l'autarcie à 100 % est une chimère.

La fabrication d'une seule puce de calcul IA est le produit d'une interdépendance radicale et d'une symbiose de monopoles nationaux. Les États-Unis conçoivent le design logiciel, le Japon détient la chimie de pointe et le silicium ultra-pur, l'Allemagne produit les optiques de Zeiss et les lasers de Trumpf, et les Pays-Bas, via le monopole absolu d'ASML, assemblent les machines de lithographie EUV. Et même ces machines néerlandaises dépendent de brevets et de technologies d'origine américaine (comme les sources de lumière Cymer).

Dans ce réseau à clés d'accès dispersées, exiger de l'Europe ou de Mistral qu'ils possèdent la chaîne de bout en bout est un contresens. La souveraineté réelle ne réside pas dans l'autarcie, mais dans le contrôle de verrous stratégiques spécifiques.

C'est ce qu'il convient d'appeler la souveraineté d'orchestration.

En se positionnant sur l'hébergement physique sur site (on-premise via Vibe) et l'intégration métier sur mesure par des ingénieurs FDE, Mistral ne prétend pas fabriquer du silicium souverain. Elle sécurise la couche finale et la plus critique de la pile : celle qui touche aux données d'affaires, au savoir tacite et aux secrets industriels de ses clients. Vous louez peut-être des puces soumises aux législations d'exportation américaines, mais vous gardez le contrôle total sur l'intelligence décisionnelle et la compliance de votre organisation. C'est un levier de confiance inestimable, et le seul pragmatique pour les entreprises régulées et les États européens (comme le prouve l'accord de défense signé en janvier 2026 avec le Ministère des Armées).

Conclusion : Un pivot pragmatique et risqué

Le pivot « Palantir » de Mistral AI n'est pas un aveu de défaite. C'est un éclair de génie tactique et de pragmatisme européen.

En acceptant la réalité des contraintes physiques de la course au calcul brut généraliste, Mistral choisit de s'ancrer là où la valeur réelle et durable se capture sur notre continent : dans la plomberie des processus industriels critiques, l'orchestration locale d'agents et la garantie d'une conformité de terrain. L'IA d'action ne se gagnera pas uniquement dans des laboratoires de recherche simulant une intelligence pure à coups de téraflops, mais sur le terrain, en codant auprès des systèmes legacy de l'économie réelle.

Cependant, ce choix opérationnel a un coût. L'ingénierie de solutions et les ingénieurs déployés (FDE) pèsent lourdement sur la marge brute de l'entreprise et sont complexes à faire monter à l'échelle par rapport à un pur modèle de distribution d'API logicielle. Si la baisse globale des prix de l'inférence se poursuit, Mistral devra rapidement stabiliser ses revenus récurrents issus de sa suite logicielle d'orchestration pour amortir le remboursement de sa dette d'infrastructure de 830 millions de dollars.

L'Europe n'aura peut-être pas son OpenAI scalable aux marges infinies d'un monopole d'accès d'API. Mais si le pari d'Arthur Mensch réussit, elle aura son Palantir de l'IA : un acteur capable de mailler la puissance de calcul physique à la haute précision de l'intégration industrielle. C'est le triomphe de la lucidité d'usage sur le fantasme de l'autarcie.

Sources et Références

• [1] Strategical Seed Memo of Mistral AI (juin 2023) : "Mistral AI: generative AI at European scale", décrivant le business model de plateforme d'API logicielle Open Core à marges brutes scalables de type SaaS.

• [2] Benchmarks de Raisonnement d'Entreprise 2025-2026 : Évaluations d'inférence documentant l'écart persistant de 12 à 18 mois entre les modèles open-weights de Mistral AI et les capacités de raisonnement logique de GPT-4o, o1 ou Claude 3.5 Sonnet.

• [3] Palantir Technologies S-1 Registration Statement (2020) : Document d'introduction en bourse décrivant le modèle opérationnel des Forward Deployed Engineers (FDE).

• [4] Financement d'infrastructure BNP Paribas - Mistral AI (Q1 2026) : Structuration du crédit à hauteur de 830 millions de dollars garanti sur collatéral d'actifs physiques (13 800 GPU Nvidia GB300).

• [5] Accord-cadre Ministère des Armées - Mistral AI (janvier 2026) : Protocole de déploiement souverain de modèles de langage sur site pour les forces armées françaises.

Traduisons : OpenAI ne croît pas parce qu'elle trouve de nouveaux clients. Elle croît parce qu'elle branche de nouveaux serveurs. Son chiffre d'affaires n'est pas une métrique commerciale — c'est une fonction dérivée de sa consommation électrique. À 1,9 gigawatt, soit la puissance de deux réacteurs nucléaires, les revenus suivent les watts.

Ce fait change tout. Si le revenu de l'IA est indexé sur l'énergie, alors la question qui structure le marché n'est pas "qui a le meilleur modèle ?" mais "qui a le plus de mégawatts ?" Et cette question a des implications que la plupart des décideurs n'ont pas encore intégrées.

1. La cascade des pénuries

Le discours dominant traite chaque contrainte physique comme un problème isolé. Les puces manquent — on construit des fonderies. L'énergie manque — on signe des contrats. La mémoire manque — on investit. En réalité, ce que je vois dans les données de mars 2026, c'est une cascade séquentielle : chaque couche de la stack matérielle révèle sa pénurie au moment où la couche précédente est partiellement résolue.

Énergie. C'est la contrainte fondatrice, documentée depuis 2025. Les data centers consomment déjà 22 % du réseau électrique irlandais — un pays de 5,1 millions d'habitants. Les délais de raccordement au réseau haute tension : 5 à 7 ans. Chaque gigawatt contracté par un data center est physiquement indisponible pour une usine, un hôpital, un immeuble.

Puces. Nvidia concentre 1 000 milliards de dollars de capitalisation sur un parc de 20 millions de GPU. La monoculture est telle que Meta, OpenAI et Amazon conçoivent désormais leurs propres puces pour s'en affranchir — mais ces alternatives ne seront matures qu'en 2027-2028.

Mémoire. Le chairman de SK Group prédit des pénuries de mémoire HBM jusqu'en 2030. Ces puces-mémoire, soudées directement sur les GPU, sont le goulet le plus discret et le plus contraignant : sans HBM, le GPU le plus puissant reste un processeur sans données.

Stockage. En marge de la GTC 2026, Greg Matson, vice-président de Solidigm (filiale SK Hynix), déclare que les systèmes IA de fin 2026 nécessiteront 35 % de stockage SSD en plus. "Je pourrais vendre deux fois plus que ce que je vends aujourd'hui." Jensen Huang confirme : "Le système de stockage va être pilonné." Pénurie prévue : jusqu'en 2030.

Refroidissement. En mars 2026, Ecolab — une entreprise de traitement des eaux — a racheté CoolIT Systems pour 4,75 milliards de dollars, soit 8,6 fois le chiffre d'affaires. CoolIT conçoit des systèmes de refroidissement liquide pour les racks de GPU. La densité thermique des puces Blackwell dépasse ce que l'air peut dissiper. Le passage au refroidissement liquide n'est pas un choix technologique — c'est une contrainte thermodynamique. Et quand une entreprise de chimie de l'eau paie 8,6 fois le chiffre d'affaires pour entrer dans ce marché, c'est que le refroidissement est devenu une couche d'infrastructure critique, au même titre que l'électricité.

La cascade n'est pas un accident. C'est la conséquence mécanique d'une industrie qui construit plus vite qu'elle ne peut s'approvisionner. Chaque couche est traitée comme un problème séparé. En réalité, elles forment un système : résoudre la pénurie de puces accélère la pénurie de mémoire, qui révèle la pénurie de stockage, qui exacerbe le besoin de refroidissement, qui alourdit la facture électrique.

2. Le matching fantôme

Microsoft annonce avoir atteint son objectif : "matcher" 100 % de sa consommation électrique avec de l'énergie renouvelable, via 40 gigawatts de contrats d'achat (PPA) répartis dans 26 pays. Le chiffre est impressionnant. La mécanique, moins.

Un PPA est un contrat financier. Microsoft achète de la capacité renouvelable quelque part dans le monde et "matche" cet achat avec sa consommation globale. Mais les électrons ne se téléportent pas. Le data center de Dublin fonctionne sur le réseau irlandais — un réseau dont les data centers consomment 22 % et dont le mix inclut du gaz naturel comme backup. Le matching est annuel et agrégé, pas horaire et local. C'est une comptabilité carbone, pas de la physique.

Le signal le plus révélateur est un glissement sémantique. La responsable développement durable de Microsoft déclare que l'électricité "carbon-free" — comprendre : nucléaire — "jouerait un rôle croissant" d'ici 2030. Le vocabulaire passe de "renewable" à "carbon-free." Ce n'est pas anodin. C'est un aveu : le renouvelable intermittent — éolien, solaire — ne peut pas fournir le baseload qu'un data center exige 24 heures sur 24. Pour le prouver, Microsoft a signé un accord avec Constellation Energy pour redémarrer Three Mile Island, le site du plus grave accident nucléaire de l'histoire américaine. Quand on choisit de relancer TMI malgré la charge symbolique, c'est que la contrainte physique a pris le dessus sur le narratif.

Le certificat vert n'est pas l'électron vert. Et la distance entre les deux croît avec chaque gigawatt contracté.

3. L'effet d'éviction français

Pour un lecteur français, la cascade a une implication directe. En février 2026, Les Echos rapportaient que les data centers représentent désormais le premier poste d'investissement industriel en France : 67 milliards d'euros. Pour 2 800 emplois.

Faisons le calcul. Un emploi en data center "coûte" 23 millions d'euros d'investissement. Un emploi dans l'industrie manufacturière classique coûte 0,6 million d'euros. Le ratio d'inefficacité sociale est de 38 pour 1. Pour le prix d'un poste de technicien de data center, on pourrait créer 38 emplois en usine.

Les 125 milliards d'euros de "réindustrialisation" affichés par les statistiques officielles sont gonflés par ces investissements massifs en infrastructure numérique. Le problème n'est pas comptable — il est physique. Les délais de raccordement électrique haute tension sont de 5 à 7 ans. Chaque gigawatt verrouillé par un data center est un gigawatt physiquement indisponible pour une usine de batteries, une ligne de production automobile ou une fonderie de semiconducteurs. Ce n'est pas une addition à l'économie productive — c'est une soustraction.

L'image de la "Maladie Hollandaise" est tentante : un pays qui exporte sa ressource brute (l'électricité nucléaire bas-carbone) sous forme d'infrastructure pour l'IA étrangère, sans capturer la valeur ajoutée logicielle. Les puces restent américaines. Les modèles restent américains. La France fournit les watts.

Le contre-argument — et ses limites

Je dois nuancer. L'investissement en data centers n'est pas sans retombées. Les PPA de Microsoft, aussi comptables soient-ils, financent de la capacité renouvelable réelle : 19 GW déjà injectés dans des réseaux. L'accélération de la transition énergétique par la demande des hyperscalers est un effet systémique positif, même si les électrons physiques ne correspondent pas au marketing.

De même, la cascade des pénuries a un revers optimiste : chaque goulot crée un marché. Le refroidissement liquide, le stockage haute densité, la gestion thermique — ce sont des secteurs industriels où l'Europe a des compétences réelles. Schneider Electric (distribution électrique, 40 milliards d'euros de capitalisation) est déjà positionnée sur la plomberie de l'IA. Ecolab rachète CoolIT. Il y a de la valeur à capturer dans les couches physiques, même quand les couches logicielles sont américaines.

Et le contre-argument le plus solide : le stockage SSD est plus scalable que l'énergie. On construit des usines de NAND plus vite que des centrales. La cascade des pénuries n'est pas forcément permanente — elle pourrait se résoudre couche par couche, comme elle s'est révélée.

Mais ces nuances ne changent pas le diagnostic fondamental. La demande de compute IA croît de manière exponentielle. La capacité physique — réseau électrique, mémoire, stockage, refroidissement — croît de manière linéaire. L'écart se creuse. Et les décideurs qui pensent "abonnement SaaS" raisonnent sur le mauvais objet.

En conclusion

Dans mon article précédent, j'avais documenté le circuit financier circulaire qui alimente l'IA. Ce texte pose la question en amont : qu'est-ce que cet argent achète ?

La réponse est physique. Des watts. Des puces. De la mémoire. Du stockage. Du refroidissement liquide. Chaque couche révèle sa pénurie au moment où la précédente est partiellement levée. Le cloud n'est pas une abstraction — c'est du béton, du cuivre et de l'eau froide.

L'IA n'est pas un logiciel qu'on déploie. C'est une infrastructure qu'on alimente. Celui qui contrôle les watts contrôle l'inférence. Et pour l'instant, les watts sont en France — mais la valeur est en Californie.

La question, pour un décideur européen, n'est pas de savoir si l'IA va transformer son secteur. C'est de savoir s'il sera du côté de ceux qui capturent la valeur — ou de ceux qui fournissent l'électricité.

Sources :

1. Les Echos, "OpenAI a plus que triplé ses revenus sur un an", 20 janvier 2026

2. Stephen Nellis, "AI's demand for data could cause tight storage chip supplies, Solidigm executive says", Reuters, 20 mars 2026

3. Reuters, "Ecolab to buy CoolIT for $4.75 billion to tap into AI data center boom", 20 mars 2026

4. Padraic Halpin, "Microsoft to keep buying enough renewable energy to match all its electricity needs", Reuters (Dublin), 18 février 2026

5. Abu Sultan, "Microsoft says it is on pace to invest $50 billion in 'Global South' AI push", Reuters (Bengaluru), 18 février 2026

6. Mehdi Laghrari, "Le boom des data centers sauve l'investissement industriel en France", Les Echos, 6 février 2026

La réponse tient dans une phrase des Echos : "Une large partie de ces nouveaux capitaux injectés dans OpenAI ont vocation à financer l'achat du matériel auprès de Nvidia."

Le fournisseur finance son propre client. Le client achète au fournisseur avec l'argent du fournisseur. L'argent ne quitte jamais le circuit. C'est ce que les analystes financiers appellent du round-tripping — et c'est le mécanisme fondateur de l'économie de l'IA en 2025-2026.

1. L'anatomie d'une boucle

Le round-tripping de Nvidia n'est pas nouveau. En 2024, la même logique opérait déjà à plus petite échelle : environ 5 milliards de dollars investis dans des clients GPU. Ce qui a changé, c'est l'ordre de grandeur. De 5 à 42 milliards en un an. Pour comparaison, Intel Capital — le plus grand fonds de capital-risque corporate de l'histoire des semiconducteurs — a investi environ 20 milliards cumulés en trente-quatre ans d'existence. Nvidia a dépassé ce montant en un trimestre.

Et le mécanisme n'est pas caché. Au moment où Nvidia préparait son entrée au capital d'OpenAI, celle-ci annonçait 100 milliards de dollars de location de processeurs Nvidia. Ce n'est pas une coïncidence. C'est un bon de commande prépayé, déguisé en prise de participation.

Puis, en mars 2026, Jensen Huang a déclaré que ces investissements seraient "probablement les derniers." La justification officielle : OpenAI et Anthropic préparent leur introduction en bourse. La justification structurelle est ailleurs — le round-tripping a rempli sa fonction. Les labs sont désormais dépendants de l'architecture Nvidia (CUDA, NVLink, Blackwell). L'investissement en equity n'est plus nécessaire quand la dépendance technique suffit.

Mais il serait naïf de penser que le mécanisme s'est arrêté. Il a changé de mains.

2. L'investissement-facture

En février 2026, OpenAI a bouclé la plus grosse levée de fonds de l'histoire du capital-risque : 110 milliards de dollars, valorisation 730 milliards. Les investisseurs : Amazon (jusqu'à 50 milliards, dont 15 fermes et 35 conditionnels), SoftBank (30 milliards), Nvidia (30 milliards).

Chaque investisseur est aussi un fournisseur. Et c'est là que le mécanisme devient limpide.

Amazon investit jusqu'à 50 milliards en equity. En retour, OpenAI signe un contrat cloud de 100 milliards supplémentaires sur huit ans avec AWS — qui s'ajoute aux 38 milliards déjà contractés à l'automne 2025. Total : 138 milliards de factures cloud garanties. Pour chaque dollar d'equity investi, Amazon récupère jusqu'à 2,76 dollars de revenus cloud. Ce n'est pas un investissement — c'est un crédit fournisseur avec de l'equity en collatéral.

Le pattern est identique pour chaque participant :

• Amazon investit 50 milliards, vend 138 milliards de cloud

• Nvidia investit 30 milliards, vend des GPU

• SoftBank investit 30 milliards, revend le narratif à ses limited partners

Personne n'investit en tant qu'investisseur pur. La "levée de fonds record" est une opération de trésorerie multilatérale entre acteurs de la même chaîne de valeur.

Et le phénomène le plus révélateur est le hedge croisé. Amazon investit dans OpenAI et dans Anthropic (8 milliards). Microsoft investit dans OpenAI (135 milliards historiques) et dans Anthropic (15 milliards). Nvidia investit dans les deux. Chaque hyperscaler est au capital de tous les labs. La "compétition" entre OpenAI et Anthropic est financée par les mêmes fournisseurs d'infrastructure — qui récupèrent leur mise en contrats cloud quel que soit le lab qui "gagne."

Les hyperscalers ne parient pas sur l'IA. Ils vendent des pelles pendant la ruée vers l'or et financent les chercheurs d'or avec le produit des pelles.

3. Le recul silencieux

Ce qui rend ce mécanisme fascinant, c'est qu'il a laissé des traces visibles de sa propre fragilité.

En septembre 2025, Nvidia annonce un investissement de 100 milliards dans OpenAI. En janvier 2026, Jensen Huang qualifie les doutes de "complètement absurdes" : "Nous allons réaliser un investissement colossal dans OpenAI." En février, le Financial Times révèle que le montant est réduit à 30 milliards — une contraction de 70 %. Trois semaines entre le déni public et la correction.

Pourquoi cette contraction ? Parce que la boucle a atteint sa limite de visibilité. Les analystes financiers ont commencé à nommer ce que je décris ici : un "arrangement circulaire" où le fournisseur préfinance ses propres ventes. Le round-tripping fonctionne tant qu'il reste implicite. Une fois nommé, il devient un risque réputationnel.

Mais le mécanisme ne disparaît pas — il mute. Nvidia se retire du round-tripping direct parce que ses clients (Amazon, SoftBank) le font désormais à sa place. Amazon investit 50 milliards dans OpenAI et récupère 138 milliards en cloud. La boucle s'est déplacée d'un étage dans la chaîne de valeur. Le vendeur de puces laisse la place au vendeur de cloud. Le circuit reste fermé.

4. L'IPO comme socialisation

La prochaine étape est déjà visible. OpenAI vise une valorisation d'environ 1 000 milliards de dollars en bourse, possiblement dès fin 2026. Anthropic, valorisé 380 milliards après sa Series G de février, réfléchit aussi à une introduction.

L'IPO change le mécanisme sans le supprimer. Aujourd'hui, le round-tripping est financé par des investisseurs stratégiques (Nvidia, Amazon, SoftBank) qui récupèrent leur mise en factures. Demain, il sera financé par les marchés publics — des investisseurs retail qui achèteront des actions OpenAI sans savoir que le chiffre d'affaires repose en partie sur des flux circulaires entre investisseurs-fournisseurs. C'est la socialisation du round-tripping : le risque passe des bilans corporate aux portefeuilles d'épargnants.

Les marchés de dette ont déjà perçu le signal. En mars 2026, Reuters rapporte que les gestionnaires de CLOs (Collateralized Loan Obligations) vendent massivement leurs prêts au secteur logiciel. Le software représente 12 % des portefeuilles CLO américains — le plus grand sous-secteur. JPMorgan estime l'exposition à risque entre 40 et 150 milliards de dollars. Des prêts à Intuit, Dayforce, Citrix se sont échangés entre 89 et 98 centimes sur le dollar — des niveaux de stress inédits. Jim Egan, de Morgan Stanley, résume : "Software is a sector where there is more selling coming from CLO managers than there is buying." JPMorgan qualifie le logiciel de "secteur orphelin."

La dette ne spécule pas. Elle protège le principal. Quand les marchés de dette commencent à fuir un secteur, c'est un signal de conviction profonde — pas une panique passagère.

Le contre-argument — et ses limites

Je dois être honnête : le round-tripping n'est pas de la fraude. OpenAI a réellement besoin de compute massif. Amazon offre un service réel à un prix de marché. Les contrats cloud ne sont pas fictifs — ils reflètent une transaction économique sous-jacente. Et OpenAI négocie activement ses conditions : l'adoption des puces Trainium d'Amazon montre que le lab diversifie ses fournisseurs de silicium. Ce n'est pas un client captif qui accepte passivement.

De même, les valorisations ne sont pas sans fondement. Anthropic affichait 14 milliards de revenus annualisés en février 2026, déjà proche de 19 milliards en mars. OpenAI est dans des ordres de grandeur comparables. Les multiples sont élevés, mais pas absurdes pour une phase d'hyper-croissance.

Le risque n'est pas que le circuit soit fictif. C'est qu'il soit fragile. Si le marché du compute se détend — nouvelles puces, gains d'efficience, saturation de la demande d'inférence — les contrats cloud à huit ans deviennent des engagements à perte. Et l'equity qui les garantit ne vaut plus rien. L'histoire de la tech est remplie de boucles qui semblaient vertueuses tant que le marché montait — et qui se sont révélées circulaires quand il a tourné.

En conclusion

Ce que je décris ici n'est pas un complot. C'est un mécanisme. Un mécanisme où le fournisseur de puces finance les labs, les labs achètent des puces au fournisseur, les hyperscalers convertissent l'equity en factures cloud, et l'ensemble s'apprête à être transmis aux marchés publics via des IPO.

Dans mon article précédent, j'avais documenté le ratio 1:100 entre production de code et gouvernance — le vrai coût du code gratuit. Ce texte pose la question en amont : qui finance l'infrastructure sur laquelle ce code tourne ?

Tout le monde — et personne. Le vendeur de puces finance le lab. Le lab paie le cloud. Le cloud paie les puces. La boucle se referme. Bientôt, l'épargnant financera le + tout — via des IPO dont la valorisation repose sur des contrats entre investisseurs-fournisseurs.

Jensen Huang a eu l'intelligence de quitter la table quand le jeu est devenu visible. La question est de savoir si les prochains joueurs — les marchés publics — comprendront les règles avant de miser.

Sources :

1. Joséphine Boone, "IA : comment Nvidia assoit sa domination en arrosant les pépites du secteur à coups de milliards", Les Echos, 16 mars 2026

2. Juby Babu, "Le directeur général de Nvidia annonce la fin des investissements dans OpenAI et Anthropic", Reuters, 4 mars 2026

3. Joséphine Boone, "La fusée OpenAI boucle une levée de fonds record à 110 milliards de dollars avec le soutien d'Amazon", Les Echos, 27 février 2026

4. Les Echos / Financial Times, "Nvidia va investir trois fois moins que prévu dans OpenAI", 20 février 2026

5. Joséphine Boone, "Les nuages s'amoncellent au-dessus du champion de l'intelligence artificielle OpenAI", Les Echos, 5 février 2026

6. Anirban Sen, Paritosh Bansal, "Debt investors offloading exposure to software companies is latest sign of pain", Reuters, 17 mars 2026

7. GeekWire, "Filings: How Amazon's $50B OpenAI deal actually works", février 2026

8. Anthropic, "Anthropic raises $30 billion Series G", communiqué officiel, 12 février 2026

Le ratio est d'environ 1:100. Pour chaque minute de code IA, cent minutes de gouvernance humaine.

C'est ce ratio qui m'intéresse. Pas parce qu'il est choquant — mais parce qu'il est structurel.

La thèse

Le coût de production du code tend vers zéro. Le coût de sa gouvernance — sécurité, audit, fiabilité, compliance — reste constant ou augmente. Et plus la production s'accélère, plus l'écart se creuse.

Ce n'est pas un problème technique. C'est un problème d'architecture organisationnelle. Et il concerne tous ceux qui décident d'adopter l'IA en entreprise — pas seulement les développeurs.

1. Le ratio 1:100 — Quand le code est gratuit mais la confiance est chère

Chez Treasure Data, le CISO, le CTO, les responsables d'ingénierie et le CPO ont passé des semaines à construire le cadre qui permettrait à un ingénieur de coder en 60 minutes. Le cadre, c'est : contrôle d'accès hérité de la plateforme, données personnelles non exposables, clés API non surfaçables, pipeline de validation à trois niveaux.

Le pipeline lui-même est un hack de gouvernance intéressant :

• Niveau 1 : un reviewer IA (lui-même construit avec Claude Code) évalue chaque pull request contre une checklist structurée — alignement architectural, compliance sécurité, couverture de tests.

• Niveau 2 : le pipeline CI/CD classique — tests unitaires, intégration, analyse statique, linting.

• Niveau 3 : review humaine, uniquement quand les niveaux 1 et 2 signalent un risque.

Le principe opérationnel est formulé avec une clarté rare : "AI writes code, but AI does not ship code." L'IA produit — le pipeline décide si le produit passe. C'est une séparation des pouvoirs appliquée au code.

Mais ce qui a cassé est aussi instructif que ce qui a marché.

Treasure Data a rendu le produit accessible sans plan de lancement — pensant que personne ne le trouverait. Plus de 1 000 utilisateurs l'ont adopté en deux semaines, par découverte organique. La certification compliance n'était pas terminée. Le produit construit en 60 minutes a atteint les clients avant que la gouvernance ne soit prête.

Deuxième faille : quand les équipes non-techniques (commerciaux, gestionnaires de comptes) ont voulu contribuer, elles ont soumis des "skills" sans comprendre les critères d'approbation — créant un backlog ingérable. La démocratisation de la production de code sans l'expertise de jugement produit de la friction organisationnelle, pas de l'efficacité.

Le code était gratuit. La gouvernance était en retard. Et la production a débordé.

2. Ce qui marche en démo crashe à l'échelle

Anni Chen est tech lead chez Amazon, responsable des systèmes GenAI à grande échelle. Elle vibe code "chaque jour." Son témoignage, publié en février 2026, est précieux parce qu'il vient d'une praticienne senior à l'intérieur d'un hyperscaler — ni évangéliste, ni observateur extérieur.

Le gain est réel : un problème qui aurait pris une journée de recherche résolu en 15 minutes. Ratio 30:1 pour le brainstorming de solutions techniques. C'est cohérent avec les données macro : +4 % de productivité du travail dans l'UE selon le CEPR, +73 % dans les tâches cognitives de marketing selon Ju et Aral.

Mais Chen identifie la faille structurelle : "Les LLM font des hypothèses implicites que vous ne réalisez pas qu'ils font." Si vous ne spécifiez pas explicitement le multi-threading, le LLM produira "la version minimale qui marche" — et qui crashera à un million d'utilisateurs. Le prototype fonctionne en conditions contrôlées. La production révèle les contraintes que la démonstration masque.

Le non-technicien ne peut pas anticiper ces contraintes en amont. Le technicien anticipe proactivement. La différence n'est pas de vitesse. C'est de fiabilité à l'échelle.

Et la pression sociale rend la résistance impossible. Chen : "Quand vos pairs l'utilisent et codent plus vite, c'est difficile de résister. Si vous ne suivez pas le rythme, la collaboration devient difficile." Même ceux qui résistent "consomment de l'IA passivement" — les code reviews contiennent déjà du code généré par IA.

Steve Yegge, 40 ans de développement logiciel (Amazon, Google), auteur du livre Vibe Coding, complète le tableau avec un phénomène que personne ne mentionne : le drainage cognitif. "Je me retrouve à faire des siestes en journée, et je parle à des amis en startups qui font pareil." Sa conclusion opérationnelle : un employeur ne devrait pas attendre plus de 3 heures productives par jour d'un ingénieur qui vibe-code à vitesse maximale. Le cerveau qui orchestre 4 à 10 agents simultanément s'épuise plus vite que celui qui code manuellement.

Les 100x de productivité sont réels. Mais ils tiennent dans 3 heures. Et ils nécessitent un expert pour les valider.

3. L'escalier qu'on supprime

En février 2026, le ministère des Finances irlandais a publié la première étude gouvernementale quantifiant l'impact de l'IA sur l'emploi par tranche d'âge. Le résultat est asymétrique.

Dans les secteurs à haut risque IA (tech, finance), l'emploi des 15-29 ans a chuté de 20 % entre 2023 et 2025 — pendant que celui des 30-59 ans progressait de 12 %. Dans les secteurs à faible exposition IA, c'est l'inverse : les jeunes progressent plus vite que les seniors.

Ce croisement élimine l'hypothèse d'un "problème jeunes" générique. C'est un effet IA spécifique aux secteurs knowledge-intensive. Le mécanisme : les tâches d'apprentissage — recherche, synthèse, premières analyses, code de base — sont exactement celles que l'IA automatise en premier. Les juniors n'entrent plus parce que les tâches de junior n'existent plus.

Et c'est là que le ratio 1:100 prend une dimension temporelle.

Si le code est gratuit, la valeur humaine migre vers la gouvernance — audit, review, compliance, jugement. Mais cette expertise de gouvernance ne s'apprend pas dans un cours. On l'apprend en faisant le travail de junior pendant des années. En revoyant du code, en comprenant pourquoi un système crashe à l'échelle, en absorbant les contraintes implicites que les LLM ne formalisent pas.

Chen formule une métaphore limpide : "Le LLM présente tous les plats, et vous choisissez. Vous savez ce qui est bon parce que vous avez cuisiné." Mais si personne ne cuisine plus — parce que le vibe coding élimine le besoin de cuisiner — qui formera les futurs goûteurs ?

L'escalier qui permettait de devenir senior est en train d'être supprimé. Et avec lui, le pipeline de formation des personnes capables de faire la gouvernance que le ratio 1:100 exige.

4. Le gaspillage invisible

Un dernier angle complète le tableau. Guillaume Besson, CPO, a récemment nommé un problème que les praticiens connaissent mais que personne ne mesure : le gaspillage de raisonnement dans les agents IA.

On empile les tokens. On multiplie les appels API. On se réjouit d'un résultat correct sans regarder le coût du chemin emprunté. Un agent qui résout une tâche en 50 boucles de raisonnement là où 3 suffiraient produit le bon résultat — mais à un coût 15 fois supérieur.

Quand le token est bon marché (Gemini Flash, DeepSeek V3), le gaspillage est invisible. Quand le modèle est premium (Claude Sonnet, GPT-5), il devient un gouffre. Et dans les deux cas, il complique la gouvernance : comment auditer un raisonnement de 50 boucles dont 47 sont du brassage d'air ?

Le gaspillage de raisonnement est la face computationnelle du ratio 1:100. Plus l'agent produit de tokens inutiles, plus la gouvernance humaine doit filtrer, plus le coût de supervision augmente.

En conclusion — La gouvernance est le nouveau métier

Je ne crois pas que le vibe coding soit un piège. Les gains de productivité sont réels — PIB américain +3,7 %, productivité UE +4 %, ratio 30:1 chez Amazon. Les rejeter serait absurde.

Mais je crois que l'industrie fait une erreur de cadrage. Elle célèbre la vitesse de production — 60 minutes, 15 minutes, 6 600 commits — et sous-estime le coût de tout ce qui entoure la production : la gouvernance, la compliance, le jugement humain, la formation des personnes capables de juger.

Le ratio 1:100 de Treasure Data n'est pas une anomalie. C'est le vrai prix du code gratuit. Et ce prix ne baisse pas avec le temps — il augmente, parce que :

NaN. La production s'accélère — plus de code signifie plus de surface à auditer

NaN. Les non-techniciens entrent dans la boucle — la démocratisation multiplie les contributions à gouverner

NaN. L'escalier d'apprentissage disparaît — les futurs gouverneurs ne sont plus formés

NaN. Le gaspillage de raisonnement alourdit la charge de supervision

Treasure Data a compris quelque chose que beaucoup d'organisations n'ont pas encore vu : "AI writes code, but AI does not ship code." La valeur n'est plus dans l'écriture. Elle est dans le droit de publier.

Pour les organisations, la question n'est plus "faut-il adopter le vibe coding ?" — la pression sociale rend cette question obsolète. La question est : avons-nous investi dans la gouvernance au même rythme que dans la production ?

Pour la plupart, la réponse est non.

Sources :

• Sean Michael Kerner, "One engineer made a production SaaS product in an hour: here's the governance system that made it possible", VentureBeat, 23 février 2026

• Anni Chen (recueilli par Lee Chong Ming), "I'm an Amazon tech lead who uses AI to write code daily. There's one situation I hesitate to use it in", Business Insider, 18 février 2026

• Gergely Orosz, "Steve Yegge on AI Agents and the Future of Software Engineering", The Pragmatic Engineer, 10 février 2026

• Padraic Halpin, "AI adoption already hitting Irish graduate jobs, finance department says", Reuters, 18 février 2026

• Guillaume Besson, "L'efficience n'est pas la performance", LinkedIn, février 2026

• Erik Brynjolfsson, "The AI productivity take-off is finally visible", Financial Times, 15 février 2026

• Inaki Aldasoro et al., "How AI is affecting productivity and jobs in Europe", CEPR, 17 février 2026

1. Le constat : l'IA ne sait rien

Demandez à un LLM généraliste quel capteur surveiller quand la température primaire d'un réacteur nucléaire semble instable. Il vous répondra avec assurance. Il inventera un code capteur plausible. Il citera peut-être une norme ISO qui n'existe pas. Et il aura tort — de manière indétectable par un non-expert.

Ce n'est pas un défaut du modèle. C'est une conséquence structurelle de son architecture. Un LLM prédit le token suivant le plus probable. Il ne sait rien du domaine. Il n'a aucune représentation interne de ce qu'est un capteur, de ce que mesure ce capteur, de la loi physique qui relie cette mesure à une autre. Sans cette structure, il ne lui reste que la vraisemblance statistique — et en industrie critique, la vraisemblance tue.

Le réflexe courant est de demander un modèle plus puissant, plus de paramètres, plus de données d'entraînement. C'est la mauvaise question. Le problème n'est pas la puissance du modèle. C'est l'absence d'une architecture de données qui encode la connaissance de votre domaine — ce que la discipline appelle une ontologie.

2. Ce que les grands groupes ont appris

Avant de concevoir quoi que ce soit, j'ai étudié ce que faisaient ceux qui ont vingt ans d'avance. L'ingénierie ontologique n'est pas une invention récente. C'est une discipline formelle, avec ses méthodologies, ses standards et ses retours d'expérience industriels. Trois principes m'ont guidé.

Le Middle-Out (Airbus). Quand Airbus a voulu structurer les exigences de conception de ses ailes d'avion (projet OntoREM), les équipes n'ont ni commencé par une modélisation abstraite du monde (approche descendante, trop lente), ni par un inventaire exhaustif de toutes les données (approche ascendante, trop chaotique). Elles sont parties des concepts que les ingénieurs manipulent au quotidien — "maintenance", "réparabilité", "inspection" — puis ont généralisé vers le haut et spécialisé vers le bas. C'est l'approche Middle-Out : on ancre l'ontologie dans le vocabulaire réel de l'expert métier, pas dans une vision philosophique du réel ni dans les colonnes d'un tableur.

L'Engagement Ontologique Minimal (EDF). Le principe MOC (Minimal Ontological Commitment) stipule qu'une ontologie ne doit contenir que les axiomes strictement nécessaires au besoin. Chaque concept supplémentaire alourdit le raisonnement et ralentit le système. Dans le nucléaire, un exploitant du parc français utilise des ontologies OWL DL pour l'analyse automatisée des modes de défaillance (FMEA) : le raisonneur déduit les conséquences systémiques d'une panne en parcourant le graphe. Si l'ontologie est "obèse" — trop de concepts, trop de relations — le raisonneur ne termine pas en temps utile. Le MOC est la discipline qui empêche cela.

La réingénierie de l'existant (TotalEnergies). Le framework NeOn, appliqué par TotalEnergies via sa suite SousLeSens, part d'un constat pragmatique : le développement ontologique ex nihilo est un échec économique. L'industrie possède déjà des standards (ISO 15926), des schémas de bases de données, des taxonomies internes. Le Scénario 2 de NeOn consiste à transformer ces ressources non-ontologiques en modèles formels. On ne repart pas de zéro — on fédère l'existant.

Ces trois principes partagent une conviction : la sobriété est une architecture. Il ne s'agit pas de tout modéliser, mais de modéliser juste assez pour que le raisonnement fonctionne. C'est exactement ce que j'ai tenté d'appliquer.

3. Trois modules pour modéliser la physique d'un réacteur

Quand j'ai conçu le Knowledge Graph pour la surveillance de réacteurs nucléaires, j'ai appliqué le Middle-Out à la lettre : je suis parti de ce que l'ingénieur de surveillance pense quand il travaille. Il pense "puissance", "température primaire", "bore", "phase opérationnelle". Il ne pense pas en termes de schéma relationnel, ni en termes de colonnes Parquet.

L'ontologie tient en trois modules — conformément au MOC, pas un de plus que nécessaire.

Module A — Les actifs (la structure). Un réacteur appartient à un palier technologique (900 MWe, 1300 MWe, 1450 MWe). Le palier détermine le nombre de boucles primaires, donc le nombre de capteurs de température. C'est une contrainte physique, pas un paramètre configurable. Le graphe modélise : ReactorUnit → belongsToPalier → ReactorModel. Cinq types de composants, pas deux cents. Le MOC en action.

Module B — La métrologie (la mesure). Chaque capteur est lié au paramètre physique qu'il mesure, avec ses métadonnées : code technique, colonne dans le Data Lake, phase opérationnelle privilégiée. La relation clé est Sensor → measures → PhysicalParameter. C'est elle qui permet la résolution sémantique — transformer le mot "puissance" prononcé par l'ingénieur en code capteur technique. Les alias ("puissance", "power", "neutronique") sont stockés dans le graphe, pas dans le prompt du LLM. Si demain le vocabulaire change, on modifie le graphe. Ni le code, ni le modèle ne bougent.

Module C — La physique (les lois). C'est ici que l'ontologie devient "intelligente". Les paramètres physiques sont reliés par des règles causales, issues de la modélisation physique du réacteur : la concentration en bore inhibe la puissance neutronique ; la position des grappes de contrôle détermine le déséquilibre axial ; la phase opérationnelle active ou désactive certains paramètres. Ces relations — inhibits, determines, enables, disables — ne sont pas des corrélations statistiques. Ce sont des lois de la physique, codées comme des arêtes du graphe.

Pourquoi trois modules et pas un seul ? La modularité est un principe de l'IOF (Industrial Ontologies Foundry) : chaque module évolue indépendamment. Quand un nouveau palier de réacteur entre en service, seul le Module A change. Quand une nouvelle règle physique est identifiée, seul le Module C est mis à jour. Le reste du système continue de fonctionner.

Les conventions de nommage suivent le standard IOF : classes en PascalCase (NeutronicPower, ControlRod), propriétés en camelCase (monitorsParam, hasOperationalPhase). Ce n'est pas du formalisme pour le plaisir — c'est ce qui permet à un raisonneur automatique de traiter le graphe sans ambiguïté, et à un ingénieur qui n'a pas conçu l'ontologie de la comprendre en la lisant.

4. "Affiche la puissance" — Anatomie d'une requête en quatre couches

La meilleure façon de montrer ce que fait le Knowledge Graph, c'est de tracer une requête réelle, couche par couche. Un ingénieur tape en langage naturel : "Affiche la puissance sur [un réacteur du parc]."

Couche 1 — Le vocabulaire humain. Le LLM analyse la phrase. Il identifie un concept : "puissance". Il ne connaît pas encore le code technique du capteur. Mais il sait qu'il doit interroger le graphe.

Couche 2 — Le concept physique. Le graphe reçoit le mot "puissance" et le cherche dans les alias des paramètres physiques. Grâce à la liste d'alias enrichie en amont (['puissance', 'power', 'neutronique']), le mot humain est résolu vers le concept formel NeutronicPower — puis vers le capteur qui mesure ce paramètre. Ce n'est pas une recherche textuelle dans une base SQL. C'est une navigation sémantique : le graphe comprend que "puissance" et "neutronique" réfèrent au même paramètre physique.

Couche 3 — L'enrichissement contextuel. Le système ne renvoie pas un code brut. Il interroge le contexte autour du capteur : que mesure-t-il ? Quelles règles physiques le gouvernent ? Quels autres capteurs sont corrélés ? Le graphe renvoie que ce capteur correspond à la "chaîne neutronique large échelle" — pas juste un identifiant, mais une donnée qualifiée.

Couche 4 — La donnée brute. Le noeud Sensor dans le graphe contient une propriété dataColumnGold : l'adresse exacte de la donnée dans le Data Lake Parquet. L'assistant utilise cette adresse pour extraire les séries temporelles via DuckDB — en sub-seconde, zero-copy, 32 threads.

Le système a traversé : Vocabulaire humain → Concept physique → Capteur réel → Donnée brute. Quatre couches, chacune déterministe et traçable. À aucun moment le LLM n'a "deviné" le code capteur. À aucun moment il n'a halluciné. Chaque étape est explicable : on sait pourquoi "puissance" a mené à tel capteur, via quelle relation du graphe.

Et c'est précisément le point. La valeur n'est pas dans le LLM — un des modèles les plus légers du marché suffit. La valeur est dans l'ontologie qui le contraint.

Conclusion : les fondations ne changent jamais

Ce blog s'appelle Foundations. Quatre couches d'expertise empilées : les données, l'optimisation, la physique, la lucidité. J'ai commencé en 2021 par des tutoriels de séries temporelles en R (Couche 1). Quatre ans plus tard, je rédige des essais sur les limites de l'IA (Couche 4).

Ce que cette expérience m'a appris : même à la Couche 4, c'est la Couche 1 qui fait la différence. Le Knowledge Graph n'est pas une "fonctionnalité IA". C'est une architecture de données — un modèle formel qui encode les lois de votre métier avant que le moindre algorithme n'entre en jeu.

Un petit modèle contraint par une ontologie bien conçue surpasse un modèle puissant sans structure. L'intelligence d'un système IA industriel ne réside pas dans ses paramètres. Elle réside dans ses données — et dans la rigueur avec laquelle on les a structurées.

On ne s'évade jamais des fondations.

Sources

• Airbus/UWE, OntoREM — Ontology-driven Requirements Engineering Methodology, IEEE, 2009

• TotalEnergies, SousLeSens — A Comprehensive Suite for the Industrial Practice of Semantic Knowledge Graphs, ESWC, 2024

• EDF/Oxford, The Energy Management Adviser at EDF, Proceedings of the ISWC, 2013

• Thales, Towards the Deployment of Knowledge Based Systems in Safety-Critical Systems, ESWC, 2023

• Industrial Ontologies Foundry (IOF), Technical Principles, NIST/OAGi

• AI- and Ontology-Based Enhancements to FMEA for Advanced Systems Engineering, arXiv, 2024

1. Introduction

2. Partie 1 : Le Syndrome du "Bachotage" (L'Analogie de Sutskever)

3. Partie 2 : L'Aveu des Créateurs (L'Architecture de la Vitesse)

4. Partie 3 : Le Mur du Réel (L'Intelligence Spatiale)

5. Conclusion du Dossier : La Fin de l'Enfance

6. Le Glossaire Décomplexé

7. Sources & Lectures Recommandées

Introduction

En janvier 2026, nous faisons face à un paradoxe qui hante la Silicon Valley. Sur le papier, les Intelligences Artificielles n'ont jamais été aussi "intelligentes". Elles écrasent les examens (Evals), réussissent le concours du Barreau et résolvent des olympiades de mathématiques.

Pourtant, dès qu'il s'agit de s'intégrer dans l'économie réelle, le "premier de la classe" trébuche. Selon les dernières données, 95 % des projets d'IA en entreprise échouent à passer en production. Ilya Sutskever, co-fondateur d'OpenAI, résumait récemment ce malaise : "L'impact économique est dramatiquement en retard sur la performance aux examens".

Comment expliquer ce décalage ?

Nous avons commis une erreur classique de confusion entre la carte et le territoire. Nous avons construit des modèles excellents pour "bachoter" (mémoriser des réponses pour réussir un test), mais fragiles dès qu'il faut improviser face à la complexité du monde réel.

Dans ce dossier, nous allons déconstruire cette "illusion scolaire" en trois temps :

1. Le Symptôme : L'analogie de l'étudiant qui a tout appris par cœur mais ne comprend rien (Ilya Sutskever).

2. La Cause : L'aveu des créateurs du "Transformer" : nous avons construit des machines pour la vitesse, pas pour le raisonnement.

3. La Réalité : Pourquoi l'avenir de l'IA ne se joue plus dans les mots, mais dans le monde physique.

Bienvenue dans l'ère de la lucidité.

Partie 1 : Le Syndrome du "Bachotage" (L'Analogie de Sutskever)

Pour comprendre pourquoi l'IA trébuche dans l'économie réelle, il faut écouter Ilya Sutskever. Lors d'une interview rare en novembre 2025, il a utilisé une analogie simple pour expliquer ce paradoxe : la différence entre réussir un examen et maîtriser un métier.

Imaginez deux étudiants qui se préparent pour un concours de programmation :

• L'Étudiant n°1 (L'IA Actuelle) : Il s'entraîne pendant 10 000 heures. Il mémorise absolument tous les problèmes passés, toutes les techniques de preuve et toutes les variantes possibles. Il devient une encyclopédie vivante du concours. Le jour de l'examen, il obtient un score parfait.

• L'Étudiant n°2 (L'Humain / L'AGI) : Il s'entraîne beaucoup moins, peut-être 100 heures. Il ne connaît pas tout par cœur, mais il a compris la logique fondamentale ("the it factor"). Il réussit aussi l'examen, peut-être avec un score légèrement inférieur,.

La Question qui tue : Lequel des deux aura la meilleure carrière professionnelle 10 ans plus tard ?

Sutskever est formel : c'est l'étudiant n°2.

Pourquoi ? Parce que l'économie réelle n'est pas un examen standardisé. L'étudiant n°1 (nos modèles actuels) a optimisé la Forme (le score au test) en "sur-apprenant" des cas spécifiques,. Dès qu'il sort du cadre prévu (le "territoire" réel), il s'effondre car il ne possède pas la compétence fluide nécessaire pour généraliser.

C'est ce qui explique le phénomène de "jaggedness" (performance en dents de scie) : une IA peut écrire un sonnet parfait, mais échouer à corriger un bug simple sans en créer un nouveau, car elle ne comprend pas le code, elle prédit statistiquement la solution la plus probable basée sur son "bachotage" intensif.

En résumé : Nous avons confondu la capacité de mémorisation (10 000 heures de données) avec l'intelligence (la capacité d'adaptation).

Partie 2 : L'Aveu des Créateurs (L'Architecture de la Vitesse)

Si l'IA actuelle est cet étudiant qui "bachote" sans comprendre, ce n'est pas un accident. C'est un choix de conception. Pour comprendre pourquoi, il faut écouter Llion Jones, le co-auteur du papier fondateur de Google (Attention Is All You Need) qui a lancé la révolution de l'IA générative.

En janvier 2026, lors de la conférence DLD à Munich, il a fait un aveu surprenant : le "Transformer" (le moteur de ChatGPT) n'était pas une percée cognitive pour simuler l'intelligence. C'était une percée d'ingénierie pour satisfaire le matériel.

Le Péché Originel : Optimiser pour le GPU, pas pour le Cerveau

Avant 2017, les IA lisaient le texte comme nous : mot après mot, séquentiellement. C'était logique, mais trop lent pour les processeurs graphiques (GPU) qui aiment traiter des milliards de chiffres simultanément.

L'équipe de Google a donc posé un problème purement logistique : "Comment pousser les données à travers le matériel le plus vite possible ?".

La solution fut le Transformer. Au lieu de lire une phrase mot à mot, cette architecture permet d'ingérer tout le texte d'un coup, en parallèle.

• Le résultat : Une capacité d'ingestion de données phénoménale, permettant d'apprendre par cœur tout Internet.

• Le coût caché : Nous avons construit une machine optimisée pour la vitesse de traitement, en supposant que l'intelligence émergerait automatiquement de la quantité de données.

La conséquence : Le Raisonnement par le "Perroquet"

C'est ici que le bât blesse. Comme l'explique Jones, ces modèles sont forcés de "raisonner" en prédisant le mot suivant. Imaginez devoir résoudre un problème de maths complexe, mais avec une contrainte : vous ne pouvez pas réfléchir en silence dans votre tête. Vous devez écrire votre pensée mot après mot, sans pause, et chaque mot écrit détermine le suivant.

C'est un "goulot d'étranglement" artificiel. L'IA ne simule pas le monde ; elle simule la probabilité du langage qui décrit le monde. Elle n'a pas appris la physique ou la logique, elle a appris la grammaire de la physique et la syntaxe de la logique.

Nous avons confondu la carte (le texte) avec le territoire (la réalité).

Partie 3 : Le Mur du Réel (L'Intelligence Spatiale)

Si le langage n'est pas le mécanisme fondamental de la pensée, qu'est-ce qui l'est ? Pour répondre à cette question, il faut se tourner vers Fei-Fei Li, la "marraine de l'IA" qui a permis l'essor du Deep Learning avec ImageNet.

Dans son essai de novembre 2025, From Words to Worlds, elle pose un diagnostic sans appel sur les modèles actuels : ce sont des "forgerons de mots dans le noir" (wordsmiths in the dark). Ils sont éloquents, mais aveugles. Ils manipulent des concepts sans jamais avoir fait l'expérience de la réalité physique qu'ils décrivent.

La leçon de l'évolution : Voir avant de Parler

Fei-Fei Li nous rappelle un principe premier biologique : l'évolution n'a pas commencé par le langage. Pendant des centaines de millions d'années, l'intelligence s'est construite sur une boucle Perception-Action. Voir un obstacle, évaluer une distance, agir pour survivre. Le langage est venu bien plus tard, comme une couche d'abstraction posée sur cet échafaudage spatial.

L'erreur de l'industrie a été de vouloir construire le toit (le langage) sans les fondations (l'intelligence spatiale). C'est pourquoi nos modèles hallucinent : ils n'ont pas de "point d'ancrage" dans le monde réel. Ils connaissent le mot "chute", mais ils ne comprennent pas la gravité.

La Solution : Les "World Models"

La prochaine frontière n'est donc pas un chatbot qui parle mieux, mais une IA qui voit et simule le monde. C'est ce que Li appelle les "World Models". Contrairement aux LLM qui prédisent le mot suivant, ces modèles prédisent l'état futur du monde physique : "Si je lâche ce verre, il va tomber et se briser".

Conclusion du Dossier : La Fin de l'Enfance

En résumé, le décalage observé par Ilya Sutskever entre les examens (evals) et l'économie réelle s'explique simplement :

1. Le Symptôme : Nous avons créé des étudiants brillants qui bachotent sans comprendre (Sutskever).

2. La Cause : Nous les avons forcés à penser uniquement à travers des séquences de mots pour satisfaire nos processeurs (Jones).

3. L'Avenir : L'IA ne deviendra économiquement viable que lorsqu'elle sortira du texte pour comprendre la physique du monde (Li).

L'année 2026 ne sera pas celle où l'IA apprendra à mieux écrire, mais celle où elle devra apprendre à vivre dans notre réalité.

Le Glossaire Décomplexé

• Evals (Évaluations / Benchmarks) : Ce sont les "examens scolaires" de l'IA. Imaginez le Bac ou le concours du Barreau. Quand on dit qu'un modèle "réussit les evals", cela signifie qu'il a obtenu un score élevé à un test standardisé. Le piège ? Comme un étudiant qui bachote, réussir l'examen ne garantit pas qu'on saura faire le métier dans la vraie vie.

• Training vs Inférence :

    ◦ Training (Entraînement) : C'est la phase d'apprentissage (lire toute la bibliothèque). C'est long et coûteux.

    ◦ Inférence : C'est le moment où l'IA répond à votre question. C'est l'usage au quotidien.

• Transformer : C'est l'architecture logicielle (le "moteur") inventée par Google en 2017 qui a permis ChatGPT. Important : elle a été conçue pour traiter des données vite (ingénierie), pas forcément pour penser mieux.

• RL (Reinforcement Learning / Apprentissage par Renforcement) : La méthode où l'on "récompense" l'IA quand elle donne la bonne réponse. Le risque est le "Reward Hacking" : l'IA apprend à tricher pour avoir la récompense sans résoudre le problème de fond.

Sources & Lectures Recommandées

Pour aller plus loin dans la compréhension des mécanismes fondamentaux discutés dans cet article, voici les documents originaux sur lesquels s'appuie notre analyse.

1. Sur le "Mur du Scaling" et le paradoxe des Evals (Le Symptôme)

• Source : We're moving from the age of scaling to the age of research

• Intervenant : Ilya Sutskever (Co-fondateur, SSI)

• Contexte : Dwarkesh Podcast, 25 Novembre 2025

• Pourquoi lire/écouter : Pour comprendre l'analogie fondamentale des "deux étudiants" et pourquoi réussir un test ne signifie pas posséder une compétence économique réelle,.

2. Sur les limites architecturales des LLM (La Cause)

• Source : Closing the Intelligence Gap: The Next Wave of AI Breakthroughs

• Intervenant : Llion Jones (Co-auteur du papier "Attention Is All You Need", Sakana AI)

• Contexte : Conférence DLD26 (Munich), 22 Janvier 2026

• Pourquoi lire/écouter : Pour découvrir l'aveu technique selon lequel le Transformer a été conçu pour satisfaire le matériel (GPU), et non pour résoudre l'intelligence,.

3. Sur l'Intelligence Spatiale et les "World Models" (La Solution)

• Source : From Words to Worlds: Spatial Intelligence is AI’s Next Frontier

• Auteur : Dr. Fei-Fei Li (World Labs)

• Contexte : Essai publié sur Substack, 10 Novembre 2025

• Pourquoi lire : Pour saisir pourquoi l'avenir de l'IA passe par la vision et la 3D, et pourquoi les modèles actuels sont des "forgerons de mots dans le noir",.

4. Données économiques et contexte de marché

• Source : They Said AI Would Replace You By Now

• Auteur : Vanessa Wingårdh (TechButMakeItReal)

• Contexte : Analyse vidéo, 4 Janvier 2026

• Pourquoi regarder : Pour les statistiques sur le taux d'échec des projets IA en entreprise (95% selon le MIT) et le décalage entre les promesses marketing et la réalité de l'emploi,.

Comment expliquer une telle divergence sur une même réalité technologique ? Après avoir analysé les rapports financiers, les interviews techniques et les mouvements de capitaux de cette fin d'année, une conclusion s'impose. Ce n'est pas un simple débat d'experts. C'est une fracture structurelle entre deux mondes : la Physique (la difficulté réelle de la recherche) et la Finance (la nécessité absolue de justifier des investissements colossaux).

Voici pourquoi nous n'avons peut-être pas acheté une technologie, mais une narrative.

1. La Magie du Bilan : L'AGI comme "Permission de perdre de l'argent"

Pour comprendre l'urgence affichée par Sam Altman ou Elon Musk, il ne faut pas regarder leur code, mais leur comptabilité. En cette fin 2025, une anomalie financière est devenue trop grosse pour être ignorée.

Des entreprises comme OpenAI sont souvent comparées à des éditeurs de logiciels (SaaS) classiques. C'est une erreur fondamentale. Un SaaS a des marges infinies : une fois le logiciel créé, le vendre à un client de plus ne coûte presque rien. Or, l'IA est une industrie lourde. Chaque requête coûte de l'énergie et du calcul. Les chiffres sont brutaux : pour 4 milliards de revenus, OpenAI affiche environ 5 milliards de pertes.

Dans n'importe quel autre secteur, un modèle perdant 53% de son revenu serait sanctionné. Mais ici, le terme "AGI" agit comme un bouclier magique. Comme le notent les analystes financiers, la narrative de l'AGI permet d'acheter la "permission de perdre de l'argent à une échelle extraordinaire".

Ce système est soutenu par une "économie circulaire" fascinante. Nvidia investit dans des néo-clouds (comme CoreWeave ou Nebius), qui utilisent cet argent pour... acheter des puces Nvidia, gonflant ainsi le chiffre d'affaires du fabricant. Tant que la promesse d'une superintelligence imminente tient, cette boucle de financement tourne. Si l'horizon s'éloigne, la bulle de la dette risque d'éclater. C'est pourquoi les "vendeurs" sont condamnés à l'optimisme : leur survie financière en dépend.

2. La Physique du Réel : La fin de l'illusion du Scaling

Pendant que la finance exige de la vitesse, la science se heurte aux murs de la réalité. Ilya Sutskever, co-fondateur d'OpenAI et désormais à la tête de SSI, a jeté un pavé dans la mare en novembre : l'ère du simple "Scaling" (ajouter toujours plus de données et de puces) est terminée. Nous entrons dans "l'âge de la Recherche".

Les modèles actuels, aussi impressionnants soient-ils, restent des "forgerons de mots dans le noir". Ils peuvent écrire un poème sur la gravité, mais peinent à prédire la chute d'un verre d'eau. Fei-Fei Li, la créatrice d'ImageNet, nous rappelle une vérité biologique : l'intelligence ne naît pas du langage, mais de l'interaction spatiale avec le monde physique.

C'est là que réside la fracture. Les modèles actuels excellent à simuler la compétence (réussir un examen), mais échouent souvent dans la robustesse opérationnelle (le modèle corrige un bug pour en créer un autre). Pour Yann LeCun ou Demis Hassabis, atteindre une véritable intelligence générale nécessitera de nouvelles architectures capables de comprendre la cause et l'effet, et pas seulement de prédire le mot suivant. Ces percées ne se décrètent pas sur un calendrier trimestriel.

3. La Dilution Stratégique : Changer la définition pour gagner la course

Face à l'impossibilité physique de livrer une "Intelligence de niveau humain" dans les délais promis aux investisseurs (2026-2027), nous assistons à une manœuvre subtile : la redéfinition de l'objectif.

Regardez bien les déclarations récentes. Sam Altman et Dario Amodei (Anthropic) ont "silencieusement dilué" la définition de l'AGI. Ils ne parlent plus d'une conscience ou d'une polyvalence totale, mais d'un "stagiaire intelligent" ou d'un "assistant de recherche" capable de synthétiser de la littérature.

Pourquoi ce glissement sémantique ? Parce que c'est un objectif atteignable à court terme. En réduisant la barre, ils peuvent déclarer victoire, satisfaire les marchés et justifier les milliards engloutis, même si la technologie reste fondamentalement un outil statistique très performant plutôt qu'une nouvelle espèce intelligente.

Conclusion : N'achetez pas la narrative, achetez la physique

En 2026, la vraie révolution ne sera peut-être pas celle qu'on nous vend. Pendant que les regards sont fixés sur une hypothétique AGI, une transformation bien plus tangible s'opère : l'émergence de "l'IA Physique" et la souveraineté des infrastructures.

La leçon de cette fin d'année 2025 est claire : l'horizon court (l'imminence) est un impératif financier pour ceux qui vendent des pelles et des rêves. L'horizon long (la patience) est une réalité scientifique pour ceux qui cherchent à résoudre les énigmes de l'intelligence.

Pour vos stratégies d'entreprise, ignorez le bruit des annonces marketing. Ne misez pas sur un "Dieu numérique" qui viendrait tout résoudre l'année prochaine. Misez sur ce qui existe : des outils de productivité puissants mais imparfaits, dont la valeur dépendra de votre capacité à les intégrer dans le monde réel, avec ses contraintes physiques et économiques.

Sources et Citations :

Inside AI’s Circular Economy (Oct 2025).

How close is AGI (Dec 2025)

The Business of “Almost” AGI (Nov 2025).

Ilya Sutskever - Interview (Nov 2025).

Cette « superintelligence artificielle » qui se cacherait derrière le divorce entre Yann LeCun, Meta et Mark Zuckerberg, Les Echos, 13 novembre 2025.

From Words to Worlds, Fei-Fei Li (Nov 2025).

Si vous avez l'impression que votre IA "patine", qu'elle hallucine ou qu'elle manque de contexte, ce n'est probablement pas la faute du modèle. C'est la faute à quarante années de modélisation orientée vers les applications (comptabilité, ERP) qui se révèlent incompatibles avec les exigences cognitives de l'IA.

J'ai décortiqué un rapport de recherche exhaustif sur le sujet pour vous livrer une analyse chirurgicale des obstacles qui séparent vos données de l'IA, et les solutions pour les surmonter.

Le conflit : Transaction vs Déduction

Historiquement, nous avons conçu nos bases de données pour répondre à des questions binaires et connues à l'avance (ex: "Le produit X est-il en stock ?"). L'IA générative inverse cette logique : elle doit synthétiser une réponse complexe à partir de fragments dispersés.

C'est ici que se crée une "friction tectonique". Voici les quatre obstacles majeurs qui transforment cette friction en mur.

1. La logique est prisonnière du code

C'est l'obstacle le plus insidieux. Dans une architecture classique, la base de données est "bête" ; l'intelligence est dans le code (Java, C++, etc.). Le Modèle d'Objets Métiers (MOM) agit comme une structure exécutive rigide qui capture l'intelligence métier dans la couche applicative, dissociant ainsi totalement le sens de la donnée brute stockée.

• L'exemple : Une colonne "Statut" contient la valeur 'S'. Pour la base de données, c'est une lettre. Pour l'application, via une ligne de code, cela signifie "Suspendu mais récupérable".

• Le problème : L'IA connectée aux données ne voit que le 'S'. Elle n'a pas accès au code qui détient la clé de compréhension. Sans ce "principe d'organisation explicite", l'IA ne peut pas raisonner, elle ne peut que faire des corrélations statistiques.

2. L'échec du modèle relationnel

Paradoxalement, les bases de données relationnelles gèrent très mal les... relations profondes.

• Pour détecter une fraude ou comprendre un contexte complexe, l'IA doit faire des sauts de connexion (A est lié à B, qui est lié à C...).

• Au-delà de trois niveaux de profondeur (three-hop radius), les performances SQL s'effondrent.

• Conséquence : Pour ne pas écrouler le système, on nourrit l'IA avec des données "plates", amputées de leur contexte relationnel, la rendant myope aux signaux faibles.

3. L'archipel des silos

L'intelligence, c'est la capacité de lier des concepts disparates. Or, nos entreprises sont des archipels de données isolés (Salesforce, SAP, WMS) sans identifiants communs.

• L'ambiguïté sémantique : Sans contexte unifié, l'IA ne peut pas résoudre le sens des mots. Un terme technique dans un document de maintenance peut avoir un sens totalement différent à la finance. Sans savoir "qui parle", l'IA hallucine.

4. Le fossé structuré / non-structuré

C'est le défi critique de l'ère des LLM. D'un côté, les bases de données (chiffres), de l'autre, les documents (PDF, mails).

• Un rapport de maintenance contient souvent la causalité (ex: "Filtre encrassé -> Surchauffe pompe").

• Mais pour les bases traditionnelles, ce document est un "BLOB", une boîte noire illisible. L'IA peine à lier une ligne de l'ERP à la procédure PDF correspondante.

La preuve par l'exemple : Le cas de l'Aéronautique

Pour comprendre l'impact concret, prenons l'exemple d'un géant de l'aéronautique qui a voulu créer un "Copilote de Maintenance".

L'IA devait répondre à une question simple d'un mécanicien : "Comment réparer la fuite sur la pompe hydraulique ?". Le projet a failli échouer. Pourquoi ?

• La configuration de l'avion (quel numéro de série de pièce est installé ?) était dans l'ERP.

• La procédure de réparation était dans un PDF.

• L'IA, incapable de faire le pont rigoureux entre l'ID de la pièce (Structuré) et la mention textuelle dans le manuel (Non-structuré), hallucinait des procédures incompatibles.

La solution : Vers une navigation conceptuelle

Alors, comment sortir de l'impasse ? La réponse ne réside pas dans un meilleur modèle de langage, mais dans une meilleure mémoire numérique.

Le Graphe de Connaissances (Knowledge Graph)

C'est la pierre angulaire de la solution. Contrairement aux bases SQL, le graphe stocke la relation comme une donnée de première classe.

1. Logique explicite : La règle métier n'est plus cachée dans le code, elle est lisible dans le graphe.

2. Performance : Traverser 5 niveaux de relations se fait en millisecondes.

3. Pont sémantique : Le graphe est le seul modèle capable de relier proprement un nœud "Document PDF" à un nœud "Pièce ERP".

GraphRAG : L'avenir de l'IA en entreprise

La tendance actuelle est au GraphRAG (Graph Retrieval-Augmented Generation). Cette technique combine :

• La recherche vectorielle (pour l'intuition et le flou linguistique).

• La structure du graphe (pour la précision factuelle et le respect des liens causaux).

Cela permet à l'IA de "raisonner" en suivant un chemin précis : Machine X -> Ligne Y -> Produit Z -> Impact Financier, chose impossible avec une simple recherche par mots-clés.

Conclusion : Ne mettez pas une Formule 1 sur un chemin de terre

L'IA Générative agit comme un révélateur impitoyable du désordre de nos données. Tenter de déployer des LLM sophistiqués sur une architecture obsolète revient à construire une Formule 1 pour la faire rouler sur un chemin de terre : c'est possible, mais dangereux et économiquement non viable.

Votre prochain mouvement ? Cessez de concevoir vos modèles de données uniquement pour vos applications. Commencez à les concevoir pour vos agents cognitifs. Cela passe par l'investissement dans des couches sémantiques (Knowledge Graphs) et la libération des règles métier enfouies dans votre code historique.

C'est à ce prix que l'IA passera du statut de gadget coûteux à celui d'oracle industriel.

Aujourd’hui nous sommes le 13 mai 2025, et une question me trotte dans la tête :
“Et si l’AGI n’arrivait jamais comme on l’imagine ?”

Je sais, c’est une question un peu provocante, presque sacrilège dans un monde où chaque semaine apporte son lot de promesses, de modèles “révolutionnaires” et d’annonces tambour battant. Mais plus je creuse, plus un malaise s’installe.

Cela fait quelques mois que je veille intensément le sujet de l’AGI — cette fameuse Intelligence Artificielle Générale qui serait censée rivaliser avec l’intelligence humaine dans sa polyvalence et son adaptabilité. Mon point de départ ? Une série de vidéos de Sabine Hossenfelder, physicienne lucide à l’humour tranchant, et surtout dénuée d’illusions marketing.

Première claque : le modèle o3

Début janvier, OpenAI lance o3. Buzz immédiat. Les chiffres sont impressionnants :

• 87 % au test ARC-AGI, conçu pour évaluer des capacités abstraites proches de l’humain.

• Performances hallucinantes en génération de code.

• Raisonnement en chaîne de pensée (“Chain of Thought”).

Sur le papier, tout y est. Pourtant, à y regarder de plus près… tout y est justement trop. Trop beau, trop calibré, trop cher (jusqu’à 3 000 $ pour une tâche). Et surtout : trop semblable aux versions précédentes.

GPT-4.5, Claude 3.7, o3 : tous progressent, mais à la marge. Le consensus émerge doucement : on atteint les limites du passage à l’échelle. Les LLMs ne “scalent” plus de manière significative. Ce n’est plus une ligne droite vers l’AGI, c’est un plateau.

Deuxième claque : la définition d’AGI elle-même

Sam Altman le reconnaît : “AGI” est devenu un mot-valise. Chacun y met ce qu’il veut. Un assistant très compétent ? Un surhomme numérique ? Une IA qui fait de la physique quantique en écoutant Bach ? La confusion règne, et elle arrange bien les discours marketing.

Sabine pointe un élément crucial : réussir un test (même impressionnant comme ARC-AGI) ne signifie pas comprendre. o3 peut battre des records en reconnaissance de motifs… sans rien saisir du sens profond. C’est l’illusion d’intelligence. Une simulation de réflexion — pas la réflexion elle-même.

Troisième claque : les limites des LLMs

Les LLMs ne comprennent pas. Ils imitent. Et leur imitation a des angles morts criants :

• Ils n’apprennent pas après leur entraînement.

• Ils échouent sur des tâches logiques élémentaires (essayez de leur faire compter les “r” dans “strawberry”…).

• Ils n’ont aucune idée de ce qu’est le monde réel.

Yann LeCun le dit sans détour : “Ils ne savent pas débarrasser une table comme un enfant de 10 ans.” On y est.

Alors, on fait quoi ?

C’est là que les choses deviennent fascinantes. Loin des projecteurs, une révolution silencieuse s’opère. Deux pistes émergent avec sérieux :

1. Le raisonnement symbolique : injecter de la logique, des structures formelles, une mémoire organisée. C’est le retour du “noyau pensant”. DeepMind expérimente déjà avec AlphaProof et le “neurosymbolic AI”.

2. Les world models : des modèles qui ne prédisent pas juste le prochain mot, mais simulent la dynamique du monde réel. Genie 2 chez DeepMind, Cosmos chez NVIDIA : on parle ici d’intelligence incarnée, d’apprentissage dans des mondes simulés, de cognition située.

Et là, enfin, il y a de la substance. Il ne s’agit plus d’agrandir une boîte noire, mais de la repenser.

Mon point de vue ? Un tournant épistémologique

Ce que je sens, c’est qu’on quitte une phase quantitative pour entrer dans une phase qualitative.
Fini les records creux, place aux explorations profondes. Les années 2010 ont été celles du passage à l’échelle. Les années 2025–2030 pourraient bien être celles de la redécouverte des fondements de l’intelligence.

L’AGI n’arrivera pas par surprise, dans une update mineure d’un LLM. Elle émergera peut-être, un jour, d’un agencement fin entre perception, action, mémoire, logique… et modestie algorithmique.

Je termine ce billet avec cette intuition :
L’AGI ne sera pas une explosion. Ce sera une cristallisation.
Silencieuse, patiente, méthodique. Comme la recherche, en somme.
Et c’est peut-être pour le mieux.

Go to R-bloggers for R news and tutorials contributed by hundreds of R bloggers.

This is the second article of the Quantum Computing simulation with R series.

Introduction

Welcome back to our quantum journey! Today, we're delving into a phenomenon that lies at the heart of quantum computing's unique power - entanglement. At a high level, quantum entanglement is the deep and mysterious link that can exist between two qubits, no matter the distance that separates them. This powerful feature allows quantum computers to process a massive number of possibilities at once and solve certain problems much faster than classical computers.

But how do we get there? We'll start by exploring two-qubit gates, the essential quantum operations that can bring about entanglement. The most common of these gates, such as the CNOT gate, can modify the state of one qubit based on the state of another, creating a correlation between the two.

Next, we'll dive into the concept of the tensor product. When dealing with multiple qubits, we cannot simply consider them separately; we must take into account the joint system, described mathematically by the tensor product of the individual states. In some situations, the state of the whole system cannot be described by individual qubit states, and that's when we encounter true entanglement.

We'll contrast this with the notion of product states, which do not involve entanglement. In these cases, the state of the whole system can be factored into individual qubit states. However, the fascinating aspect of quantum systems is that product states and entangled states are not mutually exclusive categories; a quantum state can evolve from one to the other under the action of certain quantum gates.

Entanglement is a key resource in quantum computing and quantum information theory, as it is a prerequisite for quantum teleportation, quantum cryptography, superdense coding, and several types of quantum computing algorithms. The phenomenon of quantum entanglement allows quantum computers to perform complex calculations in parallel, providing them with immense computational power. However, managing and maintaining entanglement remains one of the main challenges in the practical implementation of quantum computing.

Get ready to delve into these deep waters where classical intuition may fall short, but a new, broader understanding awaits.

What is quantum entanglement?

Quantum entanglement is a profound physical phenomenon that occurs when a pair or a group of quantum particles interact in a way that the state of each particle cannot be described independently of the state of the others, regardless of the distance separating them. This implies that an alteration in the state of one entangled particle instantaneously affects the state of the other particle(s), no matter how far apart they are. This counterintuitive feature stems from the principles of quantum mechanics, notably the superposition principle.

In more technical terms, an entangled state cannot be factorized as a product of the states of its constituents; that is, it cannot be broken down into separate states for each particle.

Superposition and entanglement are two distinct concepts in quantum mechanics.

• Superposition refers to the fact that a quantum state can exist in multiple states at once. For example, a qubit could be in a superposition of the states |0⟩ and |1⟩, represented as α|0⟩ + β|1⟩, where α and β are complex numbers and |α|^2 + |β|^2 = 1. Superposition can occur with a single qubit.

• Entanglement refers to a special correlation that can exist between quantum states. When two qubits are entangled, the state of one qubit is immediately connected to the state of the other, no matter the distance between them. Entanglement is a property of a system of two or more qubits.

How do we create an entangled quantum state?

Although I have not introduced the CNOT gate yet, it is good to know why we apply it in the following example.

Example:

1. Start with a separable state, say |00⟩

2. Apply Hadamard gate to the first qubit: 1/√2 (|00⟩ + |10⟩)

3. Apply CNOT gate => 1/√2 (|00⟩ + |11⟩) is an entangled state

Let us perform these steps with the qsimulatR package

# Create qstate object |00>
> x <- qstate(nbits = 2)
> x
   ( 1 )    * |00> 
# Display superposition of bit 1 of |00> (the rightmost qubit)
# with the Hadamard gate
> H(1)*x
   ( 0.7071068 )    * |00> 
 + ( 0.7071068 )    * |01>
# Apply CNOT gate
> x <- CNOT(c(1,2))*(H(1)*x)
# control bit = bit 1, target bit (t) = bit 2
> x
   ( 0.7071068 )    * |00> # control = 0 then target = 0
 + ( 0.7071068 )    * |11> # control = 1 then target = 1
# Verify result with CNOT truth table
> truth.table(CNOT, nbits = 2)
  In2 In1 Out2 Out1
1   0   0    0    0 # CNOT(I00>) = |00>
2   0   1    1    1 # CNOT(|01>) = |11>
3   1   0    1    0
4   1   1    0    1

There are two notions here that were not included in my first article: the CNOT gate and a separable state.

The CNOT (Controlled-NOT) gate

Let us start by plotting the circuit of the previous result.

# qubitnames = c("|0>", "|0>") since we started with |00>
> qsimulatR::plot(x, qubitnames = c("|0>", "|0>"))

The Controlled-Not gate (CNot, controlled-X, CX, Feynman) is typically represented by the circuit diagrams [1]

The control bit • influences the state of the target bit ⊕, and the target bit has no influence on the state of the control bit e.g. it is not symmetric between the two qubits.

The gate flips (or NOTs) the target qubit if the control qubit is in state |1⟩, as shown in the CNOT truth table above where In1 is the control bit and In2 is the target bit.

The state of the target qubit becomes entangled with the control qubit, which means that the state of the control qubit is now related to the state of the target qubit (the back reaction).

This concept of "action and back reaction" is a reflection of the principle of entanglement in quantum mechanics, and the foundation of quantum gates being reversible e.g. if we know the final state of the two qubits, we can figure out their initial state.

In quantum computing, every operation is required to be reversible, meaning if we know the output state, we can exactly figure out the input state.

# the first bit is the control and the second bit the target.
> CNOT(c(1,2))
An object of class "cnotgate"
Slot "bits":
[1] 1 2
# you can switch the control and atrget bits
> CNOT(c(2,1))
An object of class "cnotgate"
Slot "bits":
[1] 2 1

> x <- qstate(nbits = 2)
> qsimulatR::plot(CNOT(c(2,1))*(H(2)*x), qubitnames = c("|0>", "|0>"))

In quantum logic, there are no pure control operations per se. There is no unambiguous distinction between control and target [1]. This means that after a CNOT operation, neither qubit can be said to have a purely "control" or "target" role because their states are intertwined - each qubit's state depends on the other's.

Now, what do we mean by separable qubit?

Product states

In quantum mechanics, a state is separable (or is a product state) if it can be written as a product of states of individual subsystems.

For a two-qubit system, a state is separable if it can be written in the form |ψ⟩ = |a⟩ ⊗ |b⟩, where |a⟩ and |b⟩ are states of the individual qubits, and ⊗ is the tensor product.

For instance, |00⟩, |01⟩, |10⟩, and |11⟩ are all separable states.

If you can factor the state into a product of two single-qubit states then the state is separable. If you can't, then the state is entangled.

For instance, the state α|00⟩ + β|11⟩ cannot be factored into a product of two single-qubit states unless either α or β is zero. Therefore, this state is entangled.

Tensor product

Tensor products of quantum state vectors are also quantum state vectors — and they represent independence among systems.

The tensor product |φ⟩⊗|ψ⟩ may alternatively be written as |φ⟩|ψ⟩ or as |φψ⟩.

$$|0>⊗|1> = \begin{pmatrix} 1 \\ 0 \end{pmatrix} ⊗ \begin{pmatrix} 0 \\ 1 \end{pmatrix} = \begin{pmatrix} 0 \\ 1 \\ 0 \\ 0 \end{pmatrix} = |01>$$

You can compute the tensor product between two quantum state vectors by applying the kronecker() function in R to qstate coefs.

> a <- qstate(1) # |0>
> b <- X(1)*a    # |1>
> kronecker(a@coefs, b@coefs)
[1] 0+0i 1+0i 0+0i 0+0i
> ab <- qstate(2, coefs = kronecker(a@coefs, b@coefs))
> ab
   ( 1 )    * |01>

Proving entanglement with CNOT gates

Based on the example provided in Chapter 2.1.10 from the book [2] by Bourreau et al., I am going to implement the detailed computation with the qsimulatR package. I hope you will get another sense of what entanglement means.

We start with two qubits

$$|x1>= \begin{pmatrix} 0.8 \\ 0.6 \end{pmatrix} \hspace{1cm} |x2>= \begin{pmatrix} 0.38 \\ 0.92 \end{pmatrix}$$

After applying the first CNOT gate we obtain

$$|x1>= \begin{pmatrix} 0.8 \\ 0.6 \end{pmatrix} \hspace{1cm} |x2>= \begin{pmatrix} 0.63 \\ 0.77 \end{pmatrix}$$

After applying the second CNOT gate we obtain

$$|x1>= \begin{pmatrix} 0.8 \\ 0.6 \end{pmatrix} \hspace{1cm} |x2>= \begin{pmatrix} 0.683 \\ 0.721 \end{pmatrix}$$

# Helper function: probabilities of a quantum state
qstateProbabilities <- function(x){
  probs <- Mod(z = x@coefs)^2
  names(probs) <- x@basis
  return(probs)
}

# qubit |x1>
> x1 <- qstate(1, coefs = as.complex(c(.8, .6)))
> x1
   ( 0.8 )    * |0> 
 + ( 0.6 )    * |1> 
> qstateProbabilities(x1)
 |0>  |1> 
0.64 0.36 
# qubit |x2>
> x2 <- qstate(1, coefs = as.complex(c(5/13, 12/13)))
> x2
   ( 0.3846154 )    * |0> 
 + ( 0.9230769 )    * |1> 
> 
> qstateProbabilities(x2)
     |0>      |1> 
0.147929 0.852071

Let us perform the tensor product |x1>⊗ |x2> = |x1x2> with the kronecker() function.

# quantum state |x1x2>
> x1x2 <- qstate(2, coefs = as.complex(kronecker(x1@coefs, x2@coefs)))
> x1x2
   ( 0.3076923 )    * |00> 
 + ( 0.7384615 )    * |01> 
 + ( 0.2307692 )    * |10> 
 + ( 0.5538462 )    * |11>

Now we apply the first CNOT gate and compute the probabilities for both qubits, |x1> and |x2>, to be in states |0> and |1>, respectively.

# First CNOT : CNOT(|x1x2>)
# x1 is the control bit thus bit 2
# x2 is the target bit thus bit 1
> res <- CNOT(c(2,1))*x1x2
> res
   ( 0.3076923 )    * |00> 
 + ( 0.7384615 )    * |01> 
 + ( 0.5538462 )    * |10> 
 + ( 0.2307692 )    * |11> 
> probs <- qstateProbabilities(res)
> probs
      |00>       |01>       |10>       |11> 
0.09467456 0.54532544 0.30674556 0.05325444 

# Prob(x1=|0>) => unchanged
> as.numeric(probs[1]+probs[2])
[1] 0.64
# Prob(x1=|1>) => unchanged
> as.numeric(probs[3]+probs[4])
[1] 0.36 
# Prob(x2=|0>) => updated to 0.4014201 > 0.147929
> as.numeric(probs[1]+probs[3])
[1] 0.4014201 
# Prob(x2=|1>) => updated to 0.5985799 < 0.852071
> as.numeric(probs[2]+probs[4])
[1] 0.5985799

This means that we obtain an updated |x2> with updated probabilities, we compute its coefficients knowing that coef = √prob. Consequently, we obtain an updated quantum state |x1>⊗ |x2> = |x1x2>

# Updated |x2>
> x2 <- qstate(nbits = 1, 
               coefs = as.complex(c(sqrt(probs[1]+probs[3]), 
                                    sqrt(probs[2]+probs[4]))))
> x2
   ( 0.6335772 )    * |0> 
 + ( 0.7736794 )    * |1> 
# Thus, quantum state |x1x2> is now
> x1x2 <- qstate(2, coefs = as.complex(kronecker(x1@coefs, x2@coefs)))
> x1x2
   ( 0.5068618 )    * |00> 
 + ( 0.6189436 )    * |01> 
 + ( 0.3801463 )    * |10> 
 + ( 0.4642077 )    * |11>

Now we apply the second CNOT gate and compute the probabilities for both qubits, |x1> and |x2>, to be in states |0> and |1>, respectively.

# Second CNOT : CNOT(|x1x2>)
# x1 is the control bit thus bit 2
# x2 is the target bit thus bit 1
> res <- CNOT(c(2,1))*x1x2
> res
   ( 0.5068618 )    * |00> 
 + ( 0.6189436 )    * |01> 
 + ( 0.4642077 )    * |10> 
 + ( 0.3801463 )    * |11> 
> probs <- qstateProbabilities(res)
> probs
     |00>      |01>      |10>      |11> 
0.2569089 0.3830911 0.2154888 0.1445112 
# Prob(x1=|0>) => unchanged
> as.numeric(probs[1]+probs[2])
[1] 0.64
# Prob(x1=|1>) => unchanged
> as.numeric(probs[3]+probs[4])
[1] 0.36
# Prob(x2=|0>) => updated to 0.4723976 > 0.4014201 > 0.147929
> as.numeric(probs[1]+probs[3])
[1] 0.4723976
# Prob(x2=|1>) => updated to 0.5276024 < 0.5985799 < 0.852071
> as.numeric(probs[2]+probs[4])
[1] 0.5276024

As before, we obtain an updated |x2> with updated probabilities, we compute its coefficients knowing that coef = √prob.

# Updated |x2>
> x2
   ( 0.6873119 )    * |0> 
 + ( 0.7263624 )    * |1>

Thus,

• the probability of (|x2> = |0>) increased from 0.15 to 0.47

• the probability of (|x2> = |1>) decreased from 0.85 to 0.53

And there is a reason for this! indeed, the (unchanged) probability of (|x1> = |1>) = 0.36 < 0.5 thus, |x1> is closer to state |0>. This means that applying the CNOT several times, with x1 as the control bit and x2 as the target bit, will make |x2> to converge to state |0> as well => entanglement!

Bell states

Remember the entangled state 1/√2 (|00⟩ + |11⟩) from the very first example in this article? it is called a Bell state.

All four of the Bell states represent entanglement between two qubits [3].

The collection of all four Bell states is known as the Bell basis. Any quantum state vector of two qubits can be expressed as a linear combination of the four Bell states [3]. For example,

$$|00> =\frac{1}{\sqrt{2}}|\phi^+> + \frac{1}{\sqrt{2}}|\phi^->$$

> x <- qstate(2) # |00>
> x <- CNOT(c(1,2))*(H(1)*x)
# Bell state |phi+>
> x
   ( 0.7071068 )    * |00> # control = 0 then target = 0
 + ( 0.7071068 )    * |11> # control = 1 then target = 1
# Try it with x = {|01>, |10>, |11>}
# I guess you have understood how we obtain the Bell states now
qsimulatR::plot(x)

References

[1] Crooks G. E., "Gates, States, and Circuits", Tech. Note 014v0.9.0 beta, 2023-03-01

[2] Bourreau E., Fleury, G., Lacomme P., "Introduction à l'informatique quantique, Apprendre à calculer sur des ordinateurs quantiques avec Python", Collection Blanche, Eyrolles, 2022

[3] Qiskit, Basics of Quantum Information, https://learn.qiskit.org/course/basics/single-systems

Go to R-bloggers for R news and tutorials contributed by hundreds of R bloggers.

This is the fourth article of the Quantum Computing simulation with R series.

Introduction

Grover's algorithm, named after its inventor Lov Grover, is one of the foundational algorithms in quantum computing, and understanding it is crucial for several reasons:

1. Quantum Speedup: Grover's algorithm provides a practical demonstration of "quantum speedup." It's used for unstructured search problems and offers a significant speed advantage over classical algorithms. In a database with N items, Grover's algorithm can find a target item in roughly √N steps, compared to N/2 steps on average for a classical algorithm. This quadratic speedup exemplifies the computational potential* of quantum computing.

2. Amplitude Amplification: Grover's algorithm introduces the key concept of amplitude amplification, a technique used to increase the probability amplitude of the desired states. This is central not only to Grover's algorithm but also to other quantum algorithms.

3. Quantum Gates and Operations: Implementing Grover's algorithm helps understand the application of various quantum gates and their combined operations. It makes use of the Hadamard gate to create superposition, and phase inversion and amplitude amplification to manipulate these superpositions.

4. Quantum Advantage in Practice: While some quantum algorithms require a fully fault-tolerant quantum computer to demonstrate quantum advantage, Grover's algorithm can provide quantum speedup on near-term quantum devices, which makes it particularly important for practical quantum computing.

5. Basis for Other Algorithms: Understanding Grover's algorithm lays the groundwork for learning more complex quantum algorithms. Many advanced algorithms use principles demonstrated in Grover's algorithm, such as the amplitude amplification technique.

(*) Although Grover's algorithm requires the entire search space to be in superposition, which may not be feasible for certain large-scale practical applications, it remains an important example of quantum speedup, and understanding it is crucial to understanding many other quantum algorithms.

The Basics of Grover's Algorithm

Grover's algorithm is designed to address the problem of unstructured search. By "unstructured" search, we mean that the algorithm is designed to search through an unordered, unsorted, or random list of elements where no particular structure or relationship among the elements can be exploited to simplify the search.

Grover's algorithm is highly versatile and not restricted to problems with unique solutions. It can efficiently handle problems with multiple solutions, enhancing the probabilities associated with all solution states, thereby increasing the likelihood of measuring a correct answer upon executing the algorithm.

Grover's algorithm involves two main steps that are repeated iteratively: the application of the oracle function, and the application of the Grover diffusion operator (amplitude amplification). See the figure below from Figgat et al. [1].

Here is a high-level overview of Grover's algorithm and its stages:

1. Initialization: The algorithm begins by initializing a quantum system of n qubits into a superposition of all possible states. This is done by applying a Hadamard gate to each qubit in the initial state |0>. As a result, we obtain an equal superposition of all 2^n possible states.

2. Oracle Application: In the second step, an "oracle" function is applied to the system. The oracle is a black box function that recognizes the solution(s) we are searching for. When it encounters a solution, it flips the sign of the state, leaving other states untouched. This marks the correct solution(s) with a phase difference.

3. Amplitude Amplification: After the oracle application, the amplitudes of the states are manipulated through a process called "amplitude amplification" or Grover diffusion operator. This process involves flipping the amplitudes of the states about the average amplitude, thus amplifying the amplitude (probability) of the marked state(s) while diminishing others.

4. Iteration: Steps 2 and 3 are iteratively repeated approximately √N times to increase the probability of measuring the marked state(s) (N is the total number of items in the list or the size of the search space).

5. Measurement: Finally, a measurement is performed. At this point, the system will most likely collapse into the marked state(s) — the solution(s) to the search problem.

Understanding the Oracle

An oracle, in the context of quantum computing, is a "black box" operation used in quantum algorithms that provides a solution to a specific problem instance. It's a key component in many quantum algorithms such as Grover's and Shor's algorithms. It encodes the problem we're trying to solve into a quantum state, and it can recognize a solution to the problem without revealing what the solution is.

In Grover's algorithm, the oracle is a function that marks the elements we are searching for. It's capable of recognizing whether a given input is a solution and flips the sign of the state if it is a solution.

The quantum oracle is implemented as a unitary transformation, which when applied to a particular quantum state, alters the state in some way dependent on the problem at hand. The rest of the quantum algorithm then uses this "marked" state to amplify the probability of measuring the system in the state corresponding to the solution, using the principles of quantum superposition and interference.

Oracles are hypothetical constructs used in the analysis of quantum algorithms. In practice, constructing an efficient oracle is often as hard as solving the problem itself classically. However, for certain problems, we can construct efficient quantum oracles, and this gives us quantum speedup over classical algorithms.

Example: 1-solution Grover algorithm

As an example, let's assume we have a list of four items, {0, 1, 2, 3}, and we know that item 2 is the solution to our problem. In binary representation, these items are {00, 01, 10, 11}. In this scenario, the quantum oracle will flip the sign of the amplitude of the state |10⟩ (which corresponds to item 2) while leaving all other states unchanged.

In quantum circuit terms, this can be realized by a controlled-Z gate acting on the two qubits of the system, with the target being the second qubit.

This process does not disclose the solution (item 2) to us directly, but it prepares the ground for the next stage of the algorithm, the amplitude amplification stage, which will make this solution more likely to be observed upon measurement.

When implementing Grover's algorithm for a problem with a unique solution, an extra qubit, often referred to as an "ancillary" or "auxiliary" qubit, is utilized. Therefore, we implement it on an (n+1)-qubit system, where the additional qubit assists in marking the solution state during the oracle operation.

# Here's the function that implements an oracle 
# marking item 2 = |10> as the solution 
oracle_item2 <- function(x){
# CCNOT = "controlled controlled NOT gate"
    x <- X(1) * (CCNOT(c(1,2,3))*(X(1) * x)) 
    return(x)
}

# item 1 = |00> + ancillary qubit => |000>
> item0 <- qstate(nbits = 2+1, coefs = c(1,0,0,0,0,0,0,0))
> item0
   ( 1 )    * |000> 
# item 1 = |01> + ancillary qubit => |001>
> item1 <- qstate(nbits = 2+1, coefs = c(0,1,0,0,0,0,0,0))
> item1
   ( 1 )    * |001> 
# item 2 = |10> + ancillary qubit => |010>
> item2 <- qstate(nbits = 2+1, coefs = c(0,0,1,0,0,0,0,0))
> item2 # the solution
   ( 1 )    * |010> 
# item 3 = |11> + ancillary qubit => |011>
> item3 <- qstate(nbits = 2+1, coefs = c(0,0,0,1,0,0,0,0))
> item3
   ( 1 )    * |011>

# The oracle function flip the 3rd qubit (or bit 3) to |1>
> oracle_item2(item0)
   ( 1 )    * |000> 
> oracle_item2(item1)
   ( 1 )    * |001> 
> oracle_item2(item2) # the oracle marks item 2, bit 3 flipped to |1>
   ( 1 )    * |110>    
> oracle_item2(item3)
   ( 1 )    * |011> 

> measure(oracle_item2(item0), bit = 3)$value
[1] 0
> measure(oracle_item2(item1), bit = 3)$value
[1] 0
> measure(oracle_item2(item2), bit = 3)$value # solution
[1] 1
> measure(oracle_item2(item3), bit = 3)$value
[1] 0

Now that we have verified that our oracle function oracle_item2 works, let us plot its circuit with any (2+1)-qubit system (nbits=3), here I used |000> as input. I also labeled the ancillary qubit as "j".

> qsimulatR::plot(oracle_item2(qstate(3)), qubitnames=c("q1","q2","j"))

See the figure below from Figgat et al. article [1]. It shows 1-solution oracles for a (3+1)-qubit system. The red square shows the equivalent item2-oracle for 3 qubits e.g. marked solution = |010>.

Oracle - Mathematical explanation

For our previous (2+1)-qubit system with solution = item 2 = |10>, we usually write the oracle's output quantum state as

$$|\psi'> = \frac{1}{2}|00> +\frac{1}{2}|01> \textbf{-}\frac{1}{2}\textbf{|10>} +\frac{1}{2}|11>$$

Thus, the oracle marks the solution by flipping its sign. This corresponds to a phase flip that can be achieved with a Z gate on a single qubit, and this is why you see a "Phase Oracle" implementation in the figure above e.g. a Controlled-Z (CZ) gate can be used to implement an oracle in Grover's algorithm without the need for an ancillary qubit, assuming your problem is defined in such a way that a single CZ operation can correctly mark your solution state(s).

Note: here we stick to the "Boolean Oracle" implementation because we will also be working with more than two qubits or dealing with situations where the solution state isn't simply marked by a single CZ operation. Thus, a more complex oracle involving multiple gates (like CCNOTs, ancillary qubits, and additional phase gates) may be required.

That said, let's get back to this phase flip performed by the oracle from a mathematical perspective: the oracle function is essentially performing a symmetry operation e.g. implementing a reflection about the axis corresponding to the state |0>.

$$|\psi'> =\textbf{S}_{|0>}.|\psi>$$

$$|\psi'> =({2|0\gt\lt0| - I})(|\psi>)$$

This symmetry is critical for the "amplitude amplification" process that follows the oracle operation in Grover's algorithm, where another reflection is performed about the superposition state, effectively amplifying the amplitudes of the solution state(s).

Grover diffusion operator

The Grover diffusion operator performs amplitude amplification is a procedure that manipulates these amplitudes to increase ("amplify") the amplitudes of desired states (i.e., solution states) while decreasing the amplitudes of undesired states. In essence, amplitude amplification increases the probability that a measurement will result in a desired state, making the correct solution more likely to be found when a measurement is made.

Thus, when the oracle is coupled with Grover's diffusion operator, the process iteratively moves the quantum system closer and closer to the desired solution state(s), improving the probability of measuring a solution when the quantum state is finally read out.

In the context of Grover's algorithm, amplitude amplification plays a crucial role in improving the algorithm's efficiency.

The combination of the oracle and the Grover diffusion operator forms the Grover iterator, and after approximately sqrt(N) iterations (where N is the total number of possible states), the quantum system is likely to be found in a solution state when a measurement is performed. Thus, Grover's algorithm can find a solution with high probability in O(sqrt(N)) steps, which is a significant speedup over classical algorithms that require O(N) steps for similar problems.

Here's a quick & dirty implementation of Grover's algorithm for item 2 = |10> as a solution, using qsimulatR.

# Initialization
x <- qstate(3)     # all 2+1 qubits initialized: |000>
x <- H(2)*(H(1)*x) # uniform superposition for bits 1 and 2
x <- H(3)*(X(3)*x) # ancillary qubit (bit 3) flipped to |1> before H 
# Oracle function
x <- oracle_item2(x)
# Grover diffusiion
for(i in c(1:3)) {
  x <- H(i) * x
}
x <- X(1) * (X(2) * x)
x <- cqgate(bits = c(1,2), gate = Z(2L)) * x # custom CZ gate
x <- X(1) * (X(2) * x)
for(i in c(1:2)) {
  x <- H(i) * x
}
> x
   ( -1 )    * |110> 
# N=2^2=4 is the special case where Grover's algorithm returns 
# the correct result with certainty after only a single iteration 
# Measure bit 1
> summary(measure(e1 = x, bit = 1)) # repetitions = 1 by default
Bit 1 has been measured 1 times with the outcome:
0:  1 
1:  0 
# Measure bit 2
> summary(measure(e1 = x, bit = 2))
Bit 2 has been measured 1 times with the outcome:
0:  0 
1:  1 
> allStatesProbabilities(x) # custom function, see previous article
|000> |001> |010> |011> |100> |101> |110> |111> 
    0     0     0     0     0     0     1     0  # Prob('10')=1

Let us plot Grover's algorithm final circuit for our example. I've added some comments manually (in blue) in the figure.

# The second qubit is measured and its value is stored in res$value
> res <- measure(e1 = x, bit = 2)
> res$value
[1] 1
# The wave function of the quantum state collapses, 
# the result of which is stored again as a qstate object in res$psi.
> qsimulatR::plot(res$psi, qubitnames = c("x1", "x2", "j"))

Grover diffusion operator - Mathematical explanation

The Grover diffusion operator effectively performs a reflection of the state vector about the mean amplitude. Imagine that each state in your superposition is a point in your high-dimensional state space, and the average amplitude of all states forms another point in that space. The diffusion operator "reflects" each point about this average point. In the two-dimensional case, this would be like reflecting a point about a line in a plane.

$$|\phi> =\textbf{S}|\psi>.|\psi'> =\textbf{S}|\psi>.(S_{|0>}.|\psi>)$$

$$|\phi> =(2|{\psi\gt\lt\psi|} - I)(S_{|0>}.{|\psi>})$$

In summary [2], for the first iteration:

• Superposition of |ψ⟩ => angle θ/2 between |ψ⟩ and |0⟩

• Oracle function (symmetry) => angle -θ/2 with respect to |0⟩

• Grover's diffusion operator (symmetry) => angle 3θ/2 with respect to |0⟩

Next iteration:

• Oracle function (symmetry) => angle -3θ/2 with respect to |0⟩

• Grover's diffusion operator (symmetry) => angle 5θ/2 with respect to |0⟩

Convert to Qiskit

Let us convert to Qiskit the result of the quantum state collapse res$psi with the qsimulatR export2qiskit function.

A circuit.py file will be created in the working directory. Important: the Qiskit Python code will not work! you need to perform some manual updates:

> res$psi
   ( -1 )    * |110> 
# check @ circuit in str(x)
> export2qiskit(res$psi)

# automatically generated by qsimulatR
qc = QuantumCircuit(3,1) # we want 2 classical bits for measurement
qc.h(0)
qc.h(1)
qc.x(2)
qc.h(2)
qc.x(0)
qc.ccx(0, 1, 2)
qc.x(0)
qc.h(0)
qc.h(1)
qc.h(2)
qc.x(1)
qc.x(0)
qc.z(0, 1) # error: because custom cqgate() export is not supported
qc.x(1)
qc.x(0)
qc.h(0)
qc.h(1)
qc.measure(1, 0) # we want to measure index 0 and index 1 resp.

Below I've provided the updated Qiskit code with corrections as comments (# new)

# new: imports
from qiskit import *
from qiskit.visualization import plot_histogram
# automatically generated by qsimulatR
qc = QuantumCircuit(3,2) # new
qc.h(0)
qc.h(1)
qc.x(2)
qc.h(2)
qc.x(0)
qc.ccx(0, 1, 2)
qc.x(0)
qc.h(0)
qc.h(1)
qc.h(2)
qc.x(1)
qc.x(0)
qc.ccz(0, 1, 2) # new: replaced by ccz gate
qc.x(1)
qc.x(0)
qc.h(0)
qc.h(1)
# new: Measure the first two qubits into the classical bits
qc.measure(0,0)
qc.measure(1,1)
# new: draw the circuit
qc.draw()

# ... Cont'd
# new: job execution with simulator backend
backend = BasicAer.get_backend('qasm_simulator')
job = execute(qc, backend)
job.result().get_counts() # result: {'10': 1024}
plot_histogram(job.result().get_counts())

Before concluding

As we delve into the fascinating world of quantum computing and begin to grapple with concepts such as Grover's algorithm, it's perfectly natural for certain questions to arise.

You might wonder, for example, why we initialize the ancillary 'j' qubit to |1>?, or why we use a CCZ gate and additional gates for the Grover diffusion process?

Remember, at this stage of our exploration, we are focusing on the key principles and operations without getting too lost in the mathematical underpinnings. These aspects are influenced by specific quantum mechanical properties and mathematical considerations that ensure the algorithm's optimal performance.

However, rest assured that as we progress in our quantum computing journey, and as your understanding deepens, these concepts will become more intuitive. The goal right now is to build a solid foundation, encourage curiosity, and nurture a passion for this transformative field.

Conclusion

In conclusion, Grover's algorithm, a cornerstone in quantum computing, provides an extraordinary advantage for unstructured search, making it an essential topic for those venturing into this field. The beauty of this algorithm lies in its simplicity and the fundamental quantum principles it employs, such as superposition, interference, and quantum entanglement.

In this article, we've explored the key elements that make Grover's algorithm tick, including the creation of a specific quantum oracle and the Grover diffusion operator, which is responsible for the algorithm's amplitude amplification process. By doing so, we've dived into the depth of the algorithm, visualizing it not just as a sequence of gates but rather as a dance of symmetries in the quantum space.

Alongside the theoretical understanding, we've delved into practical implementation using the qsimulatR package in R and how to convert our code to Qiskit. This exercise enhances our comprehension of the algorithm and gives us the hands-on experience necessary to embark on more complex quantum computing problems.

As we continue our journey in quantum computing, keep in mind that the principles and techniques employed in Grover's algorithm echo through many other quantum algorithms. Therefore, a solid grasp of this topic forms a vital stepping stone in your quantum computing journey.

References

[1] Figgat C., Maslov D., Landsman K.A., Linke N.M., Debnath S., Monroe C., "Complete 3-Qubit Grover search on a programmable quantum computer", Nature Communications, 8:1918|DOI:10.1038/s41467-017-01904-7| www.nature.com/naturecommunications, 2017

[2] Bourreau E., Fleury, G., Lacomme P., "Introduction à l'informatique quantique, Apprendre à calculer sur des ordinateurs quantiques avec Python", Collection Blanche, Eyrolles, 2022

Go to R-bloggers for R news and tutorials contributed by hundreds of R bloggers.

This is the third article of the Quantum Computing simulation with R series.

Introduction

The figure below is from the excellent book [1] by Bourreau et al.. It illustrates the structure of a quantum program as a quantum circuit. Just as classical programs consist of sequences of operations (like additions, multiplications, or logical comparisons) acting on bits, quantum programs consist of sequences of quantum gates acting on qubits.

Creating a quantum circuit is a fundamental process in quantum computing. Following the figure above, this process can be broken down into several steps as follows:

1. Qubits Declaration: This is the first step in setting up a quantum program and it involves specifying the number of qubits to be used. By declaring qubits, we are essentially setting up 'variables' that will be used in the quantum program. Classical bits can also be declared, and they often come into play when we need to store and manipulate the results of quantum measurements. In addition, auxiliary qubits (also known as ancillary qubits) are often declared to assist in quantum computations. These are used as "scratch space" during computation or for holding temporary values, and they do not typically contain meaningful data at the end of the computation. Just like regular qubits, they are declared at the start of your quantum program.

2. Qubits Initialization: After declaring qubits, the next step is to initialize them. All qubits in a quantum computer start from the |0⟩ state, however, we can use quantum gates, such as the Hadamard gate, to initialize our qubits into a superposition state.

3. Problem Specification with Quantum Gates: After initializing the qubits, we then specify our problem in the form of a quantum circuit. A quantum circuit is a series of quantum gates (operations) that are applied to our qubits in a particular order to perform computations. The gates transform the initial state of the qubits into another state. Different problems will require different quantum circuits, and the design of these circuits is a crucial aspect of quantum algorithm design.

4. Measurement to Obtain Results: The final step in a quantum program involves measuring the qubits to obtain results. Measurements in quantum computing are unique because they not only give you the state of the qubits (either |0⟩ or |1⟩ for each qubit) but also collapse the quantum state to the measured state. The results of the measurement are then read out to classical bits, which can be further processed on a classical computer if necessary. This step allows us to extract useful information from the quantum system into the classical world.

Quantum program compilation and execution

1. Create Your Quantum Algorithm: The first step in quantum programming is very similar to classic programming - you have to come up with an algorithm. Instead of typical if... then... else... type instructions, you'll be working with a quantum circuit filled with quantum gates, which act as the basic instructions for your algorithm.

2. Choose Your Environment and Language: Next, you'll need to select an environment and programming language for writing your quantum code. Many beginners start with Python because of its simplicity and the availability of quantum libraries, such as Qiskit from IBM or QLM from ATOS.

3. Transpile Your Code: After writing your code, you'll need to convert (or transpile) it into a language that quantum computers understand - this is often QASM (Quantum Assembly Language). The transpiler not only translates your code but also optimizes it, ensuring your quantum circuit runs as efficiently as possible. This optimization takes into account the specific properties of the quantum machine that will run the code.

4. Execute Your Quantum Circuit: The final step is to run your quantum circuit. You can do this in two ways - either on a classic computer using a quantum simulator or on a real quantum machine. Running a circuit on a simulator is useful for testing and learning, as it allows you to experiment with "perfect" qubits without the hardware limitations or noise issues of real quantum computers. However, to fully experience the power of quantum computing, you may want to run your code on a real quantum machine. This is typically done by sending your code over the internet to a quantum computer service, like the one provided by IBM through Qiskit. Once received, your code is placed in a queue and executed when the machine is available.

Our scope for this tutorial

The main objective of the Quantum Computing simulation with R is to learn how to write quantum programs using the qsmulatR package. Thus we will only focus on point "2. Choose Your Environment and Language" above by converting our R code into Qiskit with the qsimulatR::export2qiskit() function.

Here's a quick & dirty implementation with qsimulatR for a very famous quantum algorithm, try to identify the initialization, the problem specification and the measurement parts. The algorithm will be explained in the next article.

x <- qstate(3)
x <- H(2)*(H(1)*x)
x <- H(3)*(X(3)*x)
x <- X(1) * (CCNOT(c(1,2,3)) *(X(1) * x))
for(i in c(1:3)) {
  x <- H(i) * x
}
x <- X(1) * (X(2) * x)
x <- cqgate(bits = c(1,2), gate = Z(2L)) * x
x <- X(1) * (X(2) * x)
for(i in c(1:2)) {
  x <- H(i) * x
}
x
qsimulatR::plot(x, qubitnames = c("x1", "x2", "j"))
hist(measure(e1 = x, bit = 2, repetitions = 1))

Remember, quantum programming can seem daunting at first, but with practice and patience, you'll start to grasp these new concepts and begin to appreciate the immense potential that quantum computing offers. Happy coding!

References

[1] Bourreau E., Fleury, G., Lacomme P., "Introduction à l'informatique quantique, Apprendre à calculer sur des ordinateurs quantiques avec Python", Collection Blanche, Eyrolles, 2022

Go to R-bloggers for R news and tutorials contributed by hundreds of R bloggers.

This is the first article of the Quantum Computing simulation with R series.

Welcome to our series on quantum computing basics with the qsimulatR package. This is the first in a series of articles aimed at providing an accessible and practical introduction to the basics of quantum computing using the R language. If you are a beginner in quantum computing but have a working knowledge of R, you're in the right place!

Introduction

qsimulatR is a quantum computer simulator developed by Ostmeyer and Urbach [1], it provides an excellent package to learn, explore, and experiment with quantum computing basics in the comfort of the R programming environment. Not only does it simulate the behavior of a quantum computer, but it also allows you to construct quantum circuits, perform computations and convert the code to Qiskit, making it a powerful tool for quantum computing beginners.

In this article, we will explore single-system quantum states, delve into the concept of superposition, calculate state probabilities, and understand what happens during a quantum measurement. Along the way, we will also learn about essential quantum gates such as the Hadamard gate, Pauli gates (X, Z, Y), and Phase gates (S, T), as well as their geometric interpretations with the Bloch sphere.

While the qsimulatR package provides a succinct explanation in its vignette document [2], our goal in this series is to expand on these foundations and present them in a more beginner-friendly manner. We will make use of numerous examples, code snippets, and visual aids, all aimed at making your quantum computing journey more manageable and enjoyable.

So let's set off on this exciting journey of discovery into the world of quantum computing. Prepare to leave your classical computation instincts behind and enter a realm where seemingly impossible tasks become possible!

Quantum States

The term qubit (quantum bit) refers to a quantum system whose classical state set is {0, 1}. It is just a bit, but it can be in a quantum state [3].

A quantum state of a system is represented by a column vector characterized by these two properties:

1. The entries of a quantum state vector are complex numbers.

2. The sum of the absolute values squared of the entries of a quantum state vector must be equal to 1.

For a single qubit, the computational basis consists of two states: |0⟩ and |1⟩. These basis states are orthogonal, meaning they are independent of each other and can't be created by combining the other.

Thus, the following are the vectors of states |0⟩ and |1⟩ respectively,

$$\begin{pmatrix} 1 \\ 0 \\ \end{pmatrix} = |0> , \begin{pmatrix} 0 \\ 1 \\ \end{pmatrix} = |1>$$

Let us define |0> with the qsimulatR package:

> ket0 <- qstate(nbits = 1)
> ket0
 ( 1 )    * |0>

Let us now look at the structure of the |0> qstate object

> str(ket0)
Formal class 'qstate' [package "qsimulatR"] with 5 slots
  ..@ nbits  : int 1
  ..@ coefs  : cplx [1:2] 1+0i 0+0i
  ..@ basis  : chr [1:2] "|0>" "|1>"
  ..@ noise  :List of 4
  .. ..$ p    : num 0
  .. ..$ bits : int 1
  .. ..$ error: chr "any"
  .. ..$ args : list()
  ..@ circuit:List of 2
  .. ..$ ncbits  : num 0
  .. ..$ gatelist: list()

The values of the coefs slot confirm that |0> is indeed a vector with two complex entries (1, 0) = (1+0i, 0+0i).

Let us do the same thing for |1>. We can define |1> by explicitly creating the qstate object with coefficient vector (0, 1) or by applying a bit flip with an X gate to |0> (recommended). The Pauli X gate will be explained later in this chapter.

# create |1> with coefficient vector (0, 1).
> ket1 <- qstate(nbits = 1, coefs = c(0, 1))
> ket1
   ( 1 )    * |1> 

# apply bit flip with an X gate to |0> (recommended)
> ket1 <- X(1)*ket0
> ket1
   ( 1 )    * |1>

Let us now compute the sum of the absolute values squared of the entries of a quantum state vector. The square of the absolute value of the complex number a+ib is |a+ib|². In R, you can compute the squared value of the result of the Mod() function as follows:

# square of modules of complex entries
> Mod(ket0@coefs)^2
 1 0
# sum of square of modules of complex entries
> sum(Mod(ket0@coefs)^2))
 1

Superposition

The power of quantum computing lies in its use of quantum bits or "qubits," which, unlike classical bits, can exist in multiple states simultaneously thanks to a phenomenon known as superposition.

Superposition allows us to perform calculations on many states at the same time, and in fine allows exponential speed-up of quantum algorithms compared to classical ones [2].

Thus, in the quantum world, a qubit can exist in a state that is a linear combination of basis states |0> and |1>.

$$|\psi> = \begin{pmatrix} \frac{1+2i}{3} \\ -\frac{2}{3} \\ \end{pmatrix} = \frac{1+2i}{3}|0> -\frac{2}{3} |1>$$

The following quantum state |ψ⟩ is a superposition of |0> and |1> quantum states

> psi <- qstate(nbits = 1, coefs = c((1+2i)/3, -2/3))
> psi
   ( 0.3333333+0.6666667i )    * |0> 
 + ( -0.6666667+0i )        * |1>

We can check that |phi> is a valid quantum state vector by verifying that the sum of the absolute values squared of its entries is equal to 1.

> sum(Mod(psi@coefs)^2)
[1] 1

This confirms that the condition that the sum of the absolute values squared of any quantum state vector equals 1 is therefore equivalent to that vector having Euclidean norm equal to 1. That is, quantum state vectors are unit vectors with respect to the Euclidean norm [3].

Measuring quantum states

In quantum mechanics, the "collapse" of a quantum state, also known as "wave function collapse" or "projection postulate", refers to the process of going from a superposition of states to a single state. This happens when a measurement is made.

Let's now explore the intriguing phenomenon that occurs during the measurement of a quantum state, with particular attention to a type of measurement called a standard basis measurement.

The act of measuring a system in a quantum state won't yield a quantum state vector to the observer. Instead, what the observer witnesses is a classical state. This essentially portrays measurements as a bridge between the quantum and classical realms, enabling the extraction of classical information from quantum states.

The fundamental rule of quantum measurement, known as the Born rule, is quite straightforward: when you measure a quantum state, each classical state of the system has a probability of being the result. This probability is equal to the squared absolute value of the component in the quantum state vector that corresponds to that particular classical state.

Interestingly, this rule aligns with the prerequisite that the sum of the squared absolute values of the components in a quantum state vector equals 1. This implies that the probabilities of obtaining various classical states upon measurement collectively add up to 1.

Let us then compute the probabilities to obtain classical states 0 and 1 respectively when measuring the quantum state |ψ⟩

$$Prob(0) = \Bigl|\frac{1+2i}{3} \Bigr|^2 = \frac{5}{9}\hspace{1cm} Prob(1) = \Bigl|-\frac{2}{3} \Bigr|^2 = \frac{4}{9}$$

> psi
   ( 0.3333333+0.6666667i )    * |0> 
 + ( -0.6666667+0i )        * |1>
> res <- Mod(psi@coefs)^2
> names(res) <- psi@basis
> res
      |0>       |1> 
0.5555556 0.4444444

In qsimulatR you do not need to code the probabilities computation, we use the measure function instead. It performs repetitions measurements of the qubit bit.

> (measure(e1 = psi, bit = 1, repetitions = 100))
$bit
[1] 1

$repetitions
[1] 100

$prob
[1] 0.5555556 0.4444444

$value
  [1] 1 1 0 0 0 0 0 0 1 1 1 0 0 0 0 1 0 0 0 0 0 0 1 1 0 0 0 1 1 0 0 1 0 0 0 1 0 1 0 0 1 0 0 0 0 0 0 0 1 1
 [51] 1 1 1 1 1 1 0 0 0 1 0 0 1 1 0 0 1 1 0 1 0 1 0 0 0 0 1 0 0 1 0 0 0 0 0 0 0 0 0 0 1 0 1 0 1 0 0 1 0 0

attr(,"class")
[1] "measurement" "list"

qsimulatR displays summary of the measurement and its corresponding histogram.

> meas <- measure(e1 = psi, bit = 1, repetitions = 100)
> summary(meas)
Bit 1 has been measured 100 times with the outcome:
0:  58 
1:  42
>hist(meas)

The Bloch sphere

We introduce the Bloc sphere to help you understand the geometric interpretation of the H, X, Y, Z, S and T gates (unitary operations on qubits) explained later in this article.

We can write any normalized (pure) quantum state as

$$|\psi> = \cos(\frac{\theta}{2})|0> + e^{i\phi} \sin(\frac{\theta}{2})|1>$$

where the angle θ ε [0, 2π] determines the probability to measure |0> or |1> states, and the angle φ ε [0, π] describes the relative phase.

All normalized (pure) states can be illustrated on the surface of a sphere with radius r, where |r| = 1. We call this sphere the Bloch sphere.

IMPORTANT*: Please be aware that the angles used in the Bloch sphere are twice as big as in the Hilbert space. Example: in the Hilbert space,* z-axis basis states |0> and |1> are orthogonal e.g. the angle is π/2=90°, but in the Bloch sphere the angle between states |0> and |1> is π \= 180° (z-axis).

The coordinates of such a state |ψ⟩ are given by the Bloch vector r

$$\vec{r} = \begin{pmatrix} \sin(\theta)\cos(\phi) \\ \sin(\theta)\sin(\phi) \\ \cos(\phi) \end{pmatrix}$$

The following are the coordinates of vector r for the following states on their corresponding axis on the Bloch spere:

$$z-axis, |0>:\hspace{0.5cm} \theta=0, \phi=arbitrary \hspace{0.5cm}\Rightarrow \vec{r}=\begin{pmatrix} 0\\ 0\\ 1 \end{pmatrix}$$

$$z-axis, |1>:\hspace{0.5cm} \theta=\pi, \phi= arbitrary \hspace{0.5cm}\Rightarrow\vec{r}=\begin{pmatrix} 0\\ 0\\ -1 \end{pmatrix}$$

$$x-axis, |+>:\hspace{0.5cm} \theta=\frac{\pi}{2}, \phi=0 \hspace{0.5cm}\Rightarrow\vec{r}=\begin{pmatrix} 1\\ 0\\ 0 \end{pmatrix}$$

$$x-axis, |->:\hspace{0.5cm} \theta=\frac{\pi}{2}, \phi=\pi \hspace{0.5cm}\Rightarrow\vec{r}=\begin{pmatrix} -1\\ 0\\ 0 \end{pmatrix}$$

$$y-axis, |+i>:\hspace{0.5cm} \theta=\frac{\pi}{2}, \phi=\frac{\pi}{2} \hspace{0.5cm}\Rightarrow\vec{r}=\begin{pmatrix} 0\\ 1\\ 0 \end{pmatrix}$$

$$y-axis, |-i>:\hspace{0.5cm} \theta=\frac{\pi}{2}, \phi=\frac{3\pi}{2} \hspace{0.5cm}\Rightarrow\vec{r}=\begin{pmatrix} 0\\ -1\\ 0 \end{pmatrix}$$

Projections

Remember that for a normalized quantum state |ψ⟩

$$|\psi> = \cos(\frac{\theta}{2})|0> + e^{i\phi} \sin(\frac{\theta}{2})|1>$$

the angle θ determines the probability to measure |0> or |1> states, and here is how these probabilities are computed:

$$Prob(0) = \cos²\theta, \hspace{.05cm}Prob(1)=\sin^2\theta$$

We say that the Z-measurement corresponds to the projection of |ψ⟩ onto the z-axis. A Z-measurement, also referred to as a measurement in the computational basis, is a common operation in quantum computing. It is associated with the Pauli Z gate and essentially measures a quantum state in the basis states |0⟩ and |1⟩.

The projections of |ψ⟩ onto the z-axis are written as

$$ = Prob(0) \hspace{1cm} = Prob(1)$$

Example: consider the quantum state |ψ⟩

$$|\psi> = \frac{1+2i}{3}|0> -\frac{2}{3} |1>$$

$$=Prob(0) = \Bigl|\frac{1+2i}{3} \Bigr|^2 = \frac{5}{9}\hspace{1cm}$$

$$=Prob(1) = \Bigl|-\frac{2}{3} \Bigr|^2 = \frac{4}{9}$$

<0| is pronounced as "bra 0". It refers to the row vector obtained by taking the conjugate-transpose of the column vector |0>, where (in addition to transposing the vector from a column vector to a row vector) each entry is replaced by its complex conjugate [1].

$$

# <0| is a row vector
> bra0 <- Conj(t(ket0@coefs))
bra0
     [,1] [,2]
[1,] 1+0i 0+0i
# |ψ> is a column vector
> psi <- qstate(nbits = 1, coefs = c((1+2i)/3, -2/3))
> psi@coefs
[1]  0.3333333+0.6666667i -0.6666667+0.0000000i
# <0|ψ> is a matrix product = inner product between the two vectors
> bra0 %*% psi@coefs
                     [,1]
[1,] 0.3333333+0.6666667i
# Probabilty to obtain 0 after measurement   
> Mod(bra0 %*% psi@coefs)^2
          [,1]
[1,] 0.5555556

# Same thing for |1>
> ket1 <- X(1)*ket0
> bra1 <- Conj(t(ket1@coefs))
> bra1
     [,1] [,2]
[1,] 0+0i 1+0i
> bra1 %*% psi@coefs
              [,1]
[1,] -0.6666667+0i
> Mod(bra1 %*% psi@coefs)^2
          [,1]
[1,] 0.4444444

Hadamard gate

When running quantum algorithms we usually start with several quantum states initialized as |0>, and the first thing we do is to perform the superposition of each one of the initialized states. This is done with an operation called the Hadamard gate.

The Hadamard gate creates a uniform superposition of the quantum state.

Let us apply the H gate to |0>

> H(1)*qstate(1)
   ( 0.7071068 )    * |0> 
 + ( 0.7071068 )    * |1>

Notice that coefficients values are equal to 1/sqrt(2), we can generalize this to 1/sqrt(N) where N is the number of possible states which is N=2^nbits.

So far, we have only considered nbits=1 cases since we're working with single systems taking values from the set {0, 1} of possible classical states, thus the size of the set is N = 2^1 = 2.

Notice that the Hadamard operation is reversible e.g. if we apply H(1) twice we "come back" to |0>

# Parentheses are important !!
> H(1)*( H(1)*qstate(1) )
 ( 1 )    * |0>

Let us look at the structure of the H(1) operation

> str(H(1))
Formal class 'sqgate' [package "qsimulatR"] with 3 slots
  ..@ bit : int 1
  ..@ M   : cplx [1:2, 1:2] 0.707+0i 0.707+0i 0.707+0i ...
  ..@ type: chr "H"

Notice that the M slot is a complex matrix

> H(1)@M
             [,1]          [,2]
[1,] 0.7071068+0i  0.7071068+0i
[2,] 0.7071068+0i -0.7071068+0i

We say that the H(1) operation is represented by the unitary matrix M.

$$H = \frac{1}{\sqrt{2}} \begin{pmatrix} 1 & 1 \\ -1 & 1 \\ \end{pmatrix}$$

If you multiply M by its conjugate transpose you will obtain the identity matrix.

# Conj(t(H(1)@M)): conjugate transpose of M 
# e.g., transpose M and take the complex conjugate of each entry
> H(1)@M %*% Conj(t(H(1)@M))
     [,1] [,2]
[1,] 1+0i 0+0i
[2,] 0+0i 1+0i

Generally speaking, all allowable operations on quantum state vectors are presented by unitary matrices. Unitary matrices are a set of linear mappings which transform quantum state vectors to other quantum state vectors.

Here is the action of the Hadamard operation on a few qubit state vectors [1].

$$H |0> = |+>\hspace{0.5cm} H |1> = |->\hspace{0.5cm} H |+> = |0>\hspace{0.5cm} H |-> = |1>$$

# H|0>
> H(1)*qstate(1)
   ( 0.7071068 )    * |0> 
 + ( 0.7071068 )    * |1>
# H|1>
> H(1)*(X(1)*qstate(1))
   ( 0.7071068 )    * |0> 
 + ( -0.7071068 )    * |1> 
# H|+> = HH|0> = |0>
> H(1)*(H(1)*qstate(1))
   ( 1 )    * |0> 
# H|-> = HH|1> = |1>

H gate representation

In the quantum circuit model, wires represent qubits and gates represent operations acting on these qubits. We will discuss quantum circuits in this series but for now, let us present the plot function

> x <- qstate(1)
> x <- H(1)*x # H.|0>
> qsimulatR::plot(x, qubitnames="|0>")

Geometric interpretation of H

In terms of the Bloch sphere, the Hadamard gate interchanges the x- and z-axis, and inverts the y-axis [5].

The GIF images included in this article come from the Learning Quantum website [6].

Let us remind ourselves of the result of applying H(1) to |0>

> H(1)*qstate(1)
   ( 0.7071068 )    * |0> 
 + ( -0.7071068 )    * |1>

The result of this uniform superposition of |0> with the H gate can be labeled as "|+>" (the plus state) quantum state vector.

We say that the H(1) operation is used to exchange between the z-axis basis ({|0>, |1>}) and the x-axis basis {|+>, |->} in the Bloch sphere.

Pauli X gate - Bit Flip

Concerning the computational basis, the X gate is equivalent to a classical NOT operation, or logical negation.

The computation basis states are interchanged, so that |0⟩ becomes |1⟩ and |1⟩ becomes |0⟩.

Note: the X-gate is not a true quantum NOT gate, since it only logically negates the state in the computational basis.

Let us remind ourselves how we obtained |1> by performing a bit flip on |0>

# X.|0>
> X(1)*qstate(1)
 ( 1 )    * |1> 

# X is also reversible: we come back to |0>
> X(1)*(X(1)*qstate(1))
 ( 1 )    * |0>

# Let us look at the structure of X(1)
> str(X(1))
Formal class 'sqgate' [package "qsimulatR"] with 3 slots
  ..@ bit : int 1
  ..@ M   : cplx [1:2, 1:2] 0+0i 1+0i 1+0i ...
  ..@ type: chr "X"

# We notice the Pauli matrix in the M slot
> X(1)@M
     [,1] [,2]
[1,] 0+0i 1+0i
[2,] 1+0i 0+0i

# The matrix above is a unitary matrix
> X(1)@M %*% Conj(t(X(1)@M))
     [,1] [,2]
[1,] 1+0i 0+0i
[2,] 0+0i 1+0i

X gate representation

In the quantum circuit model, wires represent qubits and gates represent operations acting on these qubits. We will discuss quantum circuits in this series but for now, let us present the plot function

> qsimulatR::plot(X(1)*qstate(1), qubitnames="|0>")

Geometric interpretation of X

The X gate generates a half-turn in the Bloch sphere about the x-axis [5]. We say that for the X gate only the angle (θ, theta) matters, the phase (φ, phi) is arbitrary.

The GIF images included in this article come from the Learning Quantum website [6].

Pauli Z gate - Phase Flip

Let us perform a phase flip on the |0> and the |1> states respectively.

# Z.|0>
> Z(1)*qstate(1)
 ( 1 )    * |0> 

# Z.|1>
> Z(1)*(X(1)*qstate(1))
 ( -1 )    * |1>

# Let us look at the structure of Z(1)
> str(Z(1))
Formal class 'sqgate' [package "qsimulatR"] with 3 slots
  ..@ bit : int 1
  ..@ M   : cplx [1:2, 1:2] 1+0i 0+0i 0+0i ...
  ..@ type: chr "Z"

# We notice the Pauli matrix in the M slot
> Z(1)@M
     [,1]  [,2]
[1,] 1+0i  0+0i
[2,] 0+0i -1+0i

# The matrix above is a unitary matrix
> Z(1)@M %*% Conj(t(Z(1)@M))
     [,1] [,2]
[1,] 1+0i 0+0i
[2,] 0+0i 1+0i

Thus, applying the Z gate to an initialized qubit (|0>) will leave the qubits computational state unchanged when measured. For the |1> state, notice that the complex amplitude of the resulting state is displayed as "( -1 )".

Remember, that |0> and |1> are orthogonal in the Hilbert space. Thus, concerning the computational basis, the Z gate flips the phase of the |1⟩ state relative to the |0⟩ state.

Z gate representation

In the quantum circuit model, wires represent qubits and gates represent operations acting on these qubits. We will discuss quantum circuits in this series but for now, let us present the plot function

Geometric interpretation of Z

The Pauli Z gate generates a half-turn in the Bloch sphere about the z-axis.

The GIF images included in this article come from the Learning Quantum website [6].

Specifically, it maps 1 to -1 and leaves 0 unchanged. It does this by rotating around the Z axis of the qubit by π radians (180 degrees). By doing this it flips the phase of the qubit.

Pauli Y gate - Bit & Phase Flip

Let us perform a bit and phase flip on the |0> state and the |1> state respectively.

# Y.|0>
> Y(1)*qstate(1)
 ( 0-1i )    * |1> 

# Y.|1>
> Y(1)*(X(1)*qstate(1))
 ( 0+1i )    * |0>

# Let us look at the structure of Y(1)
> str(Y(1))
Formal class 'sqgate' [package "qsimulatR"] with 3 slots
  ..@ bit : int 1
  ..@ M   : cplx [1:2, 1:2] 0+0i 0-1i 0+1i ...
  ..@ type: chr "Y"

# We notice the Pauli matrix in the M slot
> Y(1)@M
     [,1] [,2]
[1,] 0+0i 0+1i
[2,] 0-1i 0+0i

# The matrix above is a unitary matrix
> Y(1)@M %*% Conj(t(Y(1)@M))
     [,1] [,2]
[1,] 1+0i 0+0i
[2,] 0+0i 1+0i

Concerning the computational basis, we interchange the |0> and |1> states and apply a relative phase flip.

The Y gate can be thought of as a combination of X and Z gates, Y = −iZX.

Y gate representation

In the quantum circuit model, wires represent qubits and gates represent operations acting on these qubits. We will discuss quantum circuits in this series but for now, let us present the plot function

Geometric interpretation of Y

The Pauli Y gate generates a half-turn in the Bloch sphere about the y-axis [5].

The GIF images included in this article come from the Learning Quantum website [6].

S gate - Phase gate Z90

Historically called the phase gate (and denoted by "P"), since it shifts the phase of the one state relative to the zero state [5].

Let us apply the S gate to the |0> and |1> states respectively.

# S.|0>
> S(1)*qstate(1)
 ( 1 )    * |0>

# S.|1>
> S(1)*(X(1)*qstate(1))
 ( 0+1i )    * |1>

# Let us look at the structure of S(1)
> str(S(1))
Formal class 'sqgate' [package "qsimulatR"] with 3 slots
  ..@ bit : int 1
  ..@ M   : cplx [1:2, 1:2] 1+0i 0+0i 0+0i ...
  ..@ type: chr "S"

# We notice the Pauli matrix in the M slot
> S(1)@M
     [,1] [,2]
[1,] 1+0i 0+0i
[2,] 0+0i 0+1i


# The matrix above is a unitary matrix
> S(1)@M %*% Conj(t(S(1)@M))
     [,1] [,2]
[1,] 1+0i 0+0i
[2,] 0+0i 1+0i

Note: S.H is applied to change from Z to Y basis

S gate representation

In the quantum circuit model, wires represent qubits and gates represent operations acting on these qubits. We will discuss quantum circuits in this series but for now, let us present the plot function

> qsimulatR::plot(S(1)*qstate(1), qubitnames="|0>")

Geometric interpretation of S

The S gate adds 90° rotation to the phase. It performs a half of the Z gate e.g., it is the square root of the Z-gate, SS = Z [5].

The GIF images included in this article come from the Learning Quantum website [6].

T gate - Phase gate

It performs a quarter of the Z gate and a half of the S gate.

Let us apply the S gate to the |0> and |1> states respectively.

#

T gate representation

In the quantum circuit model, wires represent qubits and gates represent operations acting on these qubits. We will discuss quantum circuits in this series but for now, let us present the plot function

Geometric interpretation of T

An eight-turn anti-clockwise about the z-axis [5].

The GIF images included in this article come from the Learning Quantum website [6].

Conclusion

xx

References

[1] Ostmeyer J., Urbach C., qsimulatR: A Quantum Computer Simulator, https://cran.r-project.org/web/packages/qsimulatR/

[2] qsimulatR package vignette, https://cran.r-project.org/web/packages/qsimulatR/vignettes/qsimulatR.html

[3] Qiskit, Basics of Quantum Information, https://learn.qiskit.org/course/basics/single-systems

[4] Qiskit, Summer School 2021, https://learn.qiskit.org/summer-school/2021/lec1-1-vector-spaces-tensor-products-qubits

[5] Crooks G. E., "Gates, States, and Circuits", Tech. Note 014v0.9.0 beta, 2023-03-01

[6] Learning Quantum, Single Qubit Gates, https://lewisla.gitbook.io/learning-quantum/quantum-circuits/single-qubit-gates

Go to R-bloggers for R news and tutorials contributed by hundreds of R bloggers.

Introduction

This article is the Part 3 of the series (Swarm) Portfolio Optimization. I assume you have read Part 2 - Notion of non-dominated solutions.

Here, I am going to take a step back and resolve a single-objective optimization with a Particle Swarm Optimization (PSO) algorithm before moving forward with multi-objective optimization introduced in Part 2 - Notion of non-dominated solutions.

The proposed code is not an optimized one. I wanted to differentiate this article from other R-related ones by implementing the PSO algorithm with tibbles: saving all the population information at each iteration in this format can be useful if you are willing to e.g., plot dynamic movement of the swarm, and perform further analyses.

The equations of motion

This chapter is based on Maurice Leclerc's book "Particle Swarm Optimization" [1]. There are tons of articles and bibliography on PSO and its variants. I will stick to a simple version for PSO, without informants, for the sake of clarity based on the algorithm described in the next chapter.

We are interested only in continuous problems with real variables. A search space is defined, for example, classically, like one (hyper)cube of the form [XMIN, XMAX]^D.

Initialization simply consists of initially randomly placing the particles according to a uniform distribution in this search space.

The particles have velocities. By definition, a **velocity ** is a vector or, more precisely, an operator, which, applied to a position, will give another position. It is in fact a displacement, called velocity because the time increment of the iterations is always implicitly regarded as equal to 1.

For the moment, let us be satisfied with deriving at random the values of the components of each velocity, according to a uniform distribution in:

The dimension of the search space is D. Therefore, the current position or location of a particle in this space at the moment t is given by a vector x(t), with D components.

Its current velocity is v(t). The best position or location found up to now by this particle is given by a vector p(t).

Lastly, the best position or location found by informants of the particle is indicated by a vector g(t).

In general, we will write simply x, v, p, and g.

The dth component of one of these vectors is indicated by the index d, for example xd.

With these notations, the equations of motion of a particle are, for each dimension d:

*c1 * is constant (confidence in its own movement) and it will be represented by the VELOCITY_FACTOR constant.

To use this model, the two parameters c1 and cmax (represented by the CMAX constant) must be defined. CMAX can be regarded as the ** maximum confidence granted by the particle to any performance transmitted by another. For each problem, “the right” values can be found only by experiment: both VELOCITY_FACTOR and CMAX must not be chosen independently and the following couple of values are recommended

• (VELOCITY_FACTOR = 0.7, CMAX = 1.47)

• (VELOCITY_FACTOR =** 0.8**, CMAX = 1.62)

The first product cmax . alea(0,1) in the first equation of motion will be denoted as C1 (confidence granted by the particle to its self-performance), and second one as C2 (confidence granted by the particle to the best particle performance). Note: C2 is supposed to be confidence granted by the particle to its best *informant *performance, but as stated earlier in this article we do not consider Leclerc's implementation with informants.

In practice, it is not desirable that too many particles tend to leave the search space as early as the first increment. We supplement the mechanism of **confinement **(which brings back the particle to the border of the search space) with a velocity modification. In this article we choose to perform a velocity component cancellation thus, the complete mechanism is described by the following operations:

The PSO algorithm

This chapter is based on a book Meta-heuristic and Evolutionary Algorithms for Engineering Optimization [2]

Generally speaking, the objective of the PSO algorithm is to minimize a function f(x) where x denotes a particle.

• We start with an initial population.

• For any particle, a position x is said to be better than a position y if **f(x)<f(y) **.

• Now the population is updated by the movement of particles around the search space.

• Each particle i remembers the best position Pi attained by it in the past.

• Also the swarm remembers the global best value G attained by any particle in the past.

• Each particle's movement is determined by its current velocity, its own best known position and the global best value of the swarm.

• The swarm is expected to move towards the global best solution or at least towards a satisfactory solution for which the function value is close to the global minimum.

The PSO algorithm implemented in this article is the following:

Single-objective optimization problem

We will use the same 4-asset portfolio (MSFT, AAPL, GOOG, NFLX) as in Part 2.

The goal is to find the optimal solution (or portfolio weights) for the single-objective optimization problem below. I have strikethrough the second objective function from Part 2, leaving only the minimization of the first objective function: the Value-at-Risk (VaR), relative to the mean, of the portfolio.

Packages

Load the same packages as in Part 2

library(PerformanceAnalytics)
library(quantmod)
library(tidyquant)
library(tidyverse)
library(timetk)
library(skimr) # not used in this article
library(plotly) # not used in this article
library(caret) # not used in this article
library(tictoc)

Parameters

Algorithm steps 1. (population size as NUMBER_PARTICLES) and 5. (w as VELOCITY_FACTOR) will be defined along with the other PSO parameters.

# PSO parameters
NUMBER_OF_ASSETS = 4   # D = 4 dimensions
NUMBER_PARTICLES = 40  # N = population size
VELOCITY_FACTOR = .7   # confidence in its own movement
XMIN = .05  # used for mechanism of confinement, not as constraint
XMAX = .80 # used for mechanism of confinement, not as constraint
CMAX = 1.47 # maximum confidence granted by the particle to any performance transmitted by another
VMAX = (XMAX-XMIN)/2
VMIN = (XMIN-XMAX)/2
MAX_ITERATIONS = 50

Data - Daily Returns

As explained in the code snippet below, if you have already saved as returns_daily_tbl.rds the 4 assets daily returns generated in Part 2 chapter "Collect prices, compute daily returns and clean data", you can load it directly and apply the formatTibble() function to generate the returns tibble that will be used in this article.

If you haven't saved the daily returns then run the code snippet in Part 2's chapter "Collect prices, compute daily returns and clean data" and don't forget to apply the formatTibble() function.

## Assets & Daily returns data ----

# Microsoft, Apple, Google, Netflix
assets <- c("MSFT", "AAPL", "GOOG", "NFLX")

returns_daily_tbl <- readRDS("<RDS file path>/returns_daily_tbl.rds")

returns <- returns_daily_tbl %>%
  formatTibble()

rm(returns_daily_tbl)

Initialization

Population tibble definition

At each iteration the program will generate a tibble with the following format: each line is a particle representing a portfolio of the 4 assets. Since there are 4 assets there will be 4 components for the location, velocity and best location of each particle.

• Columns x_1, x_2, x_3, x_4 are the location or position components of the particle.

• Column pRelVaR is the "relative to the mean" VaR (see Part 1) calculated with the previous locations (see function computeRelVaR() below).

• Columns v_1, v_2, v_3, v_4 are the velocity components of the particle.

• Columns p_1, p_2, p_3, p_4 are the best location components of the particle.

The Initial Population tibble

The initializePopulation function

The initializePopulation() function applies algorithm steps 2., 3., 4., 6., 7., and it will be run once.

You can save the resulting tibble (with saveRDS for instance) in order to rerun the program several times using the same initial population.

The initializePopulation() function calls the following three functions:

1. generateRandomLocations(): for steps 2. and 3.

2. generateRandomVelocities(): for step 4.

3. computeRelVaR(): for step 7., thus it needs the daily returns tibble.

Step 6. does not need a specific function, all best locationsp_ will be initialized with the initial locations x_ values.

Here's the reference initial population tibble used in this article and for other optimization scenarios e.g., changing parameter couple (VELOCITY_FACTOR, CMAX) and/or population size NUMBER_PARTICLES.

init_pop <- initializePopulation(returns = returns)

> init_pop
# A tibble: 40 x 13
      x_1    x_2   x_3   x_4 pRelVaR     v_1     v_2     v_3     v_4    p_1    p_2   p_3   p_4
    <dbl>  <dbl> <dbl> <dbl>   <dbl>   <dbl>   <dbl>   <dbl>   <dbl>  <dbl>  <dbl> <dbl> <dbl>
 1 0.137  0.0829 0.392 0.389    1.15 -0.266  -0.0821  0.210   0.245  0.137  0.0829 0.392 0.389
 2 0.604  0.106  0.144 0.146    1.10 -0.227  -0.360  -0.350  -0.0668 0.604  0.106  0.144 0.146
 3 0.341  0.350  0.176 0.133    1.10  0.257   0.0866  0.122  -0.0764 0.341  0.350  0.176 0.133
 4 0.0442 0.449  0.361 0.147    1.13 -0.260  -0.267   0.191  -0.342  0.0442 0.449  0.361 0.147
 5 0.144  0.103  0.399 0.355    1.14 -0.0740 -0.224   0.0213  0.155  0.144  0.103  0.399 0.355
 6 0.409  0.0956 0.296 0.200    1.10  0.0740  0.310  -0.293  -0.255  0.409  0.0956 0.296 0.200
 7 0.0575 0.316  0.198 0.429    1.14 -0.0175 -0.324  -0.106  -0.189  0.0575 0.316  0.198 0.429
 8 0.0716 0.363  0.111 0.454    1.14 -0.301  -0.0417 -0.0640 -0.156  0.0716 0.363  0.111 0.454
 9 0.0367 0.358  0.425 0.180    1.10 -0.128  -0.129   0.104  -0.293  0.0367 0.358  0.425 0.180
10 0.109  0.164  0.246 0.481    1.18  0.271  -0.0885 -0.160   0.121  0.109  0.164  0.246 0.481
# ... with 30 more rows

initializePopulation <- function(returns){
  
  ## Randomly generate locations of particles ----
  init_locations <- lapply(X = 1:NUMBER_PARTICLES, function(x){
    generateRandomLocations(n = NUMBER_OF_ASSETS, min = XMIN, max = XMAX)
  })
  init_locations <- init_locations %>%
    bind_rows()
  
  ## Randomly generate velocities of particles ----
  init_velocities <- lapply(X = 1:NUMBER_PARTICLES, function(x){
    generateRandomVelocities(n = NUMBER_OF_ASSETS, min = VMIN, max = VMAX)
  })
  init_velocities <- init_velocities %>%
    bind_rows()
  
  ## Initialize best locations as first locations ----
  init_bestlocations <- init_locations
  colnames(init_bestlocations) <- sapply(X = 1:NUMBER_OF_ASSETS, function(x) paste0("p_",x))
  
  ## Compute fitness function value, here pRelVaR, for each particle ----
  init_particles <- bind_cols(computeRelVaR(tbl = init_locations, returns = returns), 
                              init_velocities)
  
  init_particles <- bind_cols(init_particles, init_bestlocations)
  
  return(init_particles)
  
}

The generateRandomLocations function

The function returns a tibble withh n lines, each composed of the x_1, x_2, x_3, x_4 location components randomly generated with the runif() function. The min and max arguments default values will be overwritten with XMIN and XMAX values.

The locations must sum up to 1 (100%) since they represent the weigths of the assets.

generateRandomLocations <- function(n, min=.05, max=.75){
  
  tmp <- runif(n = n, min = min, max = max)
  
  # Weights must sum up to 1 (100%)
  nweights <- tmp/sum(tmp)
  
  new_cols <- list()
  for(x in 1:n) {
    new_cols[[paste0("x_", x, sep="")]] = nweights[x]
  }
  
  res <- as_tibble(new_cols)
  
  return(res)
}

The generateRandomVelocities function

The function returns a tibble withh n lines, each composed of the v_1, v_2, v_3, v_4 velocity components randomly generated with the runif() function. The min and max arguments default values will be overwritten with VMIN and VMAX values.

generateRandomVelocities <- function(n, min=-1, max=1){
  
  velocities <- runif(n = n, min = min, max = max)
  
  new_cols <- list()
  for(x in 1:n) {
    new_cols[[paste0("v_", x, sep="")]] = velocities[x]
  }
  
  res <- as_tibble(new_cols)
  
  return(res)
}

The computeRelVaR function

The computeRelVaR() function returns a tibble with NUMBER_OF_PARTICLES lines each composed of the x_1, x_2, x_3, x_4 locations and its "relative to the mean" VaR result.

The computeRelVaR() function calls the following three functions:

1. getWeigthedReturns(): as defined in Part 2

2. getMeanWeigthedReturns(): as defined in Part 2

3. getVaRValues(): a simplified version of Part 2's getObjectiveFunctionsValues function, it computes and returns VaR-related values by calling only the objectiveFunction1 as defined in Part 2.

computeRelVaR <- function(tbl, returns){
  
  lrelVaRValues <- lapply(1:nrow(tbl), function(x){
    
    weights <- unlist(tbl[x,c(1:NUMBER_OF_ASSETS)])
    
    returns %>%
      getWeigthedReturns(vecA = assets, vecW = weights) %>%
      getMeanWeigthedReturns() %>%
      getVaRValues(vecW = weights)
    
  })
  
  relVaRValues <- lrelVaRValues %>%
    bind_rows() %>%
    select(starts_with("x_"), pRelVaR)
  
  return(relVaRValues)
}

Find global best location

The following code snippet implements algorithm step 8.

It simply finds the particle within the initial population that has the **minimum **"relative to the mean" VaR.

g_particle <- init_pop[which(init_pop\(pRelVaR == min(init_pop\)pRelVaR)),]

Iterations and Updates

Main program

The code snippet below implements all remaining steps, from 9. to 12.

At each iteration we will save the corresponding population tibble with the iterations_data list. Its initialization is shown in the code snippet below.

iterations_data <- vector("list", MAX_ITERATIONS)

iterations_data[[1]] <- list(pop = init_pop, gb = g_particle)

The main program calls the computeNextLocation() function. This function computes the next location components x_1, x_2, x_3, x_4 based on the velocities v_1, v_2, v_3, v_4 which must be calculated by getVelocityMatrix() based on current best locationsp_1, p_2, p_3, p_4 and global best location.

The new locations tibble will used to calculate the "relative to the mean" VaR (pRelVaR) with the computeRelVaR() function, already described above.

Next, we must identfy if they are any particles with a smaller pRelVaR than the last iteration pRelVaR. If yes, then we must update their best position components p_1, p_2, p_3, p_4 with their new location components x_1, x_2, x_3, x_4, and "rebuild" the population tibble. Else, no best positions will be updated and the same population tibble will be used it next iteration hoping the the randomness introduced in getVelocityMatrix() will generate new locations with smaller pRelVaR.

In either case, we find global best particle with minimum pRelVaR and save it (g_particle). Then, we add the population tibble and globa best particle yo

# Iterations
iter <- 2
while(iter <= MAX_ITERATIONS){  
  
  # Compute next velocities and locations
  next_locvels <- computeNextLocation(tbl = iterations_data[[iter-1]]\(pop, gbest = iterations_data[[iter-1]]\)gb)
 
  # Get velocities tibble
  next_vels <- next_locvels$vels
  
 # Get new locations tibble
  next_fitnessval <- computeRelVaR(tbl = next_locvels$locs, returns = returns)
  
  # Get best locations tibble
  next_bestloc <- iterations_data[[iter-1]]$pop %>%
    select(starts_with("p_"))
  
  # Identify particles with smaller pRelVaR  than last iteration pRelVaR 
  update_idx <- which(next_fitnessval\(pRelVaR < iterations_data[[iter-1]]\)pop$pRelVaR)
  
  # For particles with smaller pRelVaR  than last iteration pRelVaR
  
  if(length(update_idx) > 0){
    
    # Update particles' pbest locations (p) with new locations => update pbest tibble
    
    next_bestloc[update_idx, ] <- next_fitnessval[update_idx, -which(colnames(next_fitnessval)=="pRelVaR")]
    
    newRelVaRloc <- computeRelVaR(tbl = next_bestloc, returns = returns)
    
    new_pop <-  bind_cols(bind_cols(newRelVaRloc, next_vels), next_bestloc)
    
  }else{
    
    # No updates : did not find particles with smaller pRelVaR  than last iteration pRelVaR
    new_pop <-  iterations_data[[iter-1]]$pop
    
  }
  
  # Find global best particle with minimum pRelVaR
  g_particle <- new_pop[which(new_pop\(pRelVaR == min(new_pop\)pRelVaR)),]
  
  iterations_data[[iter]] <- list(pop = new_pop, gb = g_particle)
  
  # iterations_data <- rlist::list.append(iterations_data, it_1 = list(pop = new_pop, gb = g_particle))
  
  iter <- iter + 1
}

# Find particle with solution x_1, x_2, x_3, x_4 with minimum pRelVaR

iterations_data[[MAX_ITERATIONS]]$gb

The computeNextLocation() function

It starts by calling the getVelocityMatrix(), decribed later, which will return particles' velocities as a matrix.

As stated by the second equation of motion, we must sum the velocities matrix to the current locations for which the tibble has been coverted to matrix.

Next, we must verify that the newly calculated locations values stay within the XMIN and XMAX bounds. If not, set its corresponding velocity coordinate to zero and bring the location coordinate value back to its limit, XMIN or XMAX according to the case (new location coordinate < XMIN or > XMAX).

Remember that locations represent the weights of the assets, thus they must sum up to 1 (100%). That is why the simply function asDistribution() is called. This is where I will introduce some flexibility to the algorithm since afetr calling this function you may encounter a location coordinate x_ which is actually smaller than XMIN. See "red" weight vaues in the Excel sheet run results shown at the end of the article.

Both updated locations and velocities matrices will be converted back to tibbles prior being returned within a list.

asDistribution <- function(vec){
  vec/sum(vec)
}

computeNextLocation <- function(tbl, gbest){
  
  velmat <- getVelocityMatrix(tbl = tbl, gbest = gbest)
  current_mat <- as.matrix(tbl %>% select(starts_with("x_")))
  res <- current_mat + velmat
  
  # Verify that weights are within min and max bounds
  
  if (length(which(res < XMIN)) > 0) { 
    velmat[which(res < XMIN)] = 0L
    res[which(res < XMIN)] = XMIN
    }
  
  if (length(which(res > XMAX)) > 0) {
    velmat[which(res > XMAX)] = 0L
    res[which(res > XMAX)] = XMAX
    }
  
  # Locations (assets weights) msut sum up to 1
  lnorm <- lapply(X = 1:nrow(tbl), 
                  FUN = function(x) asDistribution(res[x,]))
  
  # Convert to tibble
  locs <- lnorm %>% 
    bind_rows() %>%
    as_tibble()
  
  vels <- as_tibble(velmat)
  colnames(vels) <- sapply(X = 1:NUMBER_OF_ASSETS, FUN = function(x) paste0("v_",x))
  
  # Return tibbles within a list
  return(list(locs=locs, vels=vels))

}

The getVelocityMatrix() function

Here is where the famous equations of motion (explained above) take place and where randomness is introduced by calculating C1 and C2 parameters.

The getVelocityMatrix() breaks the population tibble into its main components (locations, best locations, and velocities) also as tibbles, and it will extract the best location of the current global best location particle as a vector.

Then the random parameters C1 and C2 will calculated by multiplying fixed parameter CMAX by runif(1, min=0, max=1).

Each particle velocity vetor will be calculated by applying the first equation of motion as R vector operations. The result will be the vector velocities.

We convert the vector velocities into a matrix velmat with number of lines as the number of particles and the number of columns as the number of assets.

Next, we must verify that the newly calculated velocties values stay within the VMIN and VMAX bounds. If not, bring the velocity coordinate back to its limit, VMIN or VMAX, according to the case.

Finally, return the velocities matrix .

getVelocityMatrix <- function(tbl, gbest){
  
  current_tbl <- tbl %>% select(starts_with("x_"))
  pbest_tbl <- tbl %>% select(starts_with("p_"))
  velocity_tbl <- tbl %>% select(starts_with("v_"))
  g <- as.numeric(gbest %>% select(starts_with("p_")))
  
  C1 <- CMAX*runif(1,0,1)
  C2 <- CMAX*runif(1,0,1)
  
  velocities <- lapply(X = 1:nrow(tbl), FUN = function(x){
                         
                         y <- as.numeric(current_tbl[x,])
                         v <- as.numeric(velocity_tbl[x,])
                         p <- as.numeric(pbest_tbl[x,])
                         
                         VELOCITY_FACTOR*v + C1*(p-y) + C2*(g-y)
                         
                       })
  
  velmat <- matrix(data = as.numeric(unlist(velocities)), 
                   nrow = nrow(tbl), 
                   ncol = NUMBER_OF_ASSETS)
  
  # Setting columns names to "x_" since it will sum with a location matrix
  colnames(velmat) <- sapply(X = 1:NUMBER_OF_ASSETS, FUN = function(x) paste0("x_",x))
  
  if (length(which(velmat < VMIN)) > 0) velmat[which(velmat < VMIN)] = VMIN
  if (length(which(velmat > VMAX)) > 0) velmat[which(velmat > VMAX)] = VMAX
  
  return(velmat)
}

Optimization results

Using the same initial population tibble (inti_pop) I have run 19 optimization scenarios with different population sizes (NUMBER_OF_PARTICLES) and 2 couples of (CMAX, VELOCITY_FACTOR) values.

The **minimum **"relative to the mean" VaR was 1.064213 with following solution of portfolio:

• **MSFT **= 0.434 (43.4%)

• **APPL **= 0.274 (27.4%)

• **GOOG **= 0.0378 (3.78%)

• **NFLX **= 0.255 (25.5%)

Below, the results and details of each of the 19 optimization scenarios sorted by ascending "relative to the mean" VaR values.

The "red" values in the portfolios (SOLUTIONS column) below correspond to ones being smaller than XMIN.

Conclusion

This article introduced the basics of the PSO algorithm with tibbles. The goal was to resolve a single-objective optimization problem by minimizing the "relative to the mean" VaR, the objective function.

This version of the algorithm did not use the notion of group of informants per particle (as introduced in [1]) thus, all particles "know" the best global location.

Although location limits XMIN and XMAX were defined we did not use them as optimization constraints. Since the location components (weights of assets) must sum up to 1 (100%) some flexibility was introduced while doing this computation.

In Part 4 we will come back to our multi-objective optimization problem introduced in Part 2 - Notion of non-dominated solutions

References

[1] Leclerc M., "Particle Swarm Optimization", Lavoisier, 2005

[2] Bozorg-Haddad O., Solgi M., Loaiciga H., "Meta-heuristic and Evolutionary Algorithms for Engineering Optimization"

Go to R-bloggers for R news and tutorials contributed by hundreds of R bloggers.

Introduction

This article is part of the series (Swarm) Portfolio Optimization. I assume you have read the Nonparametric VaR article or have solid notions about its calculation.

We will use the same 4-asset portfolio (MSFT, AAPL, GOOG, NFLX) as introduced in Nonparametric VaR.

We will

1. collect assets' prices, compute daily returns and clean data

2. format the daily returns tibble

3. compute weighted returns per asset

4. compute the mean of weighted returns per day

5. generate 1000 random 4-weight vectors or solutions or decision vectors

6. find the objective vectors corresponding to the non-nondominated solutions

7. visualize and distinguish the non-nondominated solutions from the dominated ones

As stated in the nonparametric VaR article, I like working with tibbles (and not time series R objects), that's why I use and recommend the tidyquant package.

Multi-objective optimization

Since the final goal of this series is the implementation of MOPSO, let us start with the mathematical concept behind multi-objective optimization as reminded in Mostaghim et al. paper [1]:

Our multi-objective problem

We want to use a multi-objective PSO approach to find VaR-efficient portfolios by solving the following optimization problem: [2]

where

Thus, we want to find a set of optimal solutions (weights w') to

• minimize de Value-at-Risk (VaR), relative to the mean, of the portfolio

• maximize the expected return of the portfolio

Our objective functions

We will define f1 as being the Value-at-Risk (VaR), relative to the mean, of the portfolio, and f2 as the expected return of the portfolio.

Finally, based on the mathematical explanation provided above we want to find the Pareto-optimal decision vectors (or weights) and their corresponding Pareto-optimal objective vector values (black squares in the figure below).

These Pareto-optimal decision vectors (or weights) are also called non-dominated solutions. In a MOPSO context they are also called archive-members.

Packages

Load the following packages:

library(PerformanceAnalytics)
library(quantmod)
library(tidyquant)
library(tidyverse)
library(timetk)
library(skimr)
library(plotly)
library(caret)
library(tictoc)

Collect prices, compute daily returns and clean data

This is the same code used in the Nonparametric VaR article.

# ASSETS
assets <- c("MSFT", "AAPL", "GOOG", "NFLX")

# TIME INTERVAL

end <- "2021-12-31" %>% ymd()
start <- end - years(5) + days(1)

# GET ASSETS' DAILY RETURNS

returns_daily_tbl <- assests %>%
  tq_get(from = start, to = end) %>%
  group_by(symbol) %>%
  tq_transmute(select = adjusted,
               mutate_fun = periodReturn, 
               period = "daily") %>%
  ungroup()

# PREPROCESSING - CLEAN

## Delete each asset first row (= 0)
rows_to_delete <- which(returns_daily_tbl$date == ymd("2017-01-03"))
returns_daily_tbl <- returns_daily_tbl[-rows_to_delete,] 

Daily returns tibble format

Let us put the tibble in the right format by renaming the columns and converting the symbol column to factor, here below the corresponding custom function:

formatTibble <- function(tbl){
  columnNames <- c("symbol", "date", "returns")
  res <- tbl %>%
    mutate(symbol = as.factor(symbol))
  colnames(res) <- columnNames
  
  return(res)
}

Get weighted returns

The next custom function getWeigthedReturns() multiplies a weight from the weight vector to its corresponding asset daily returns and outputs an updated tibble with new columns: weight and weighted.returns.

getWeigthedReturns <- function(tbl, vecA, vecW){
  # Generate by-symbol tibble with weighted returns
  # add by-symbol tibble to a list
  lsymboltbl <- lapply(X = 1:length(vecA), function(x){
    tbl %>%
      filter(symbol == vecA[x]) %>%
      mutate(weight = vecW[x]) %>%
      mutate(weighted.returns = returns * weight)
  })
  
  # Bind symbol tibble by rows
  res <- lsymboltbl %>% 
    bind_rows()
  
  return(res)
}

Compute mean of weighted returns

Our goal here is to generate the same tibble (portfolio) from which we calculated the expected return and the "relative to the mean" VaR in the Nonparametric VaR article. Thus, we group by date and calculate the mean of daily returns of the 4 assets.

getMeanWeigthedReturns <- function(tbl){
  res <- tbl %>%
    group_by(date) %>%
    summarise(mean.weighted.returns = mean(weighted.returns))
  
  return(res)
}

Objective function f1: VaR

Although the custom function calculates both absolute and relative VaR, we consider only the "relative to the mean" VaR as the output of objective function f1.

objectiveFunction1 <- function(tbl, p = .99){
  # Absolute VaR
  absoluteVaR <- tbl %>% 
    tq_performance(Ra = mean.weighted.returns,
                   performance_fun = VaR, 
                   p = p, 
                   method = "historical")
  
# Relative VaR: E(Rp) - q(Rp)
  relativeVaR <- mean(tbl\(mean.weighted.returns) - absoluteVaR\)VaR
  
  return(list(VaR = list(abolute = absoluteVaR$VaR,
                         relative = relativeVaR)))
}

Objective function f2: Expected return

Since we apply a minimization for both objective functions, the objectiveFunction2() custom function outputs a negative value for the expected return.

objectiveFunction2 <- function(tbl){
  # w'E(R)
  res <- mean(tbl$mean.weighted.returns)
  return(-res)
}

Other custom functions

We will generate 1000 random 4-weight solutions with the generateRandomWeightsVector() custom function. All four weights must sum to 1. I have also added a constraint to avoid generating 0-valued and 1-valued weights.

generateRandomWeightsVector <- function(n, min=.05, max=.75){
  
  tmp <- runif(n = n, min = min, max = max)
  nweights <- tmp/sum(tmp)
  
  new_cols <- list()
  for(x in 1:n) {
    new_cols[[paste0("w_", x, sep="")]] = nweights[x]
  }
  
  res <- as_tibble(new_cols)
  
  return(res)
}

We group the random solutions with their respective objective functions results in the same tibble with the following custom function:

getObjectiveFunctionsValues <- function(tbl, vecW){
  
  new_cols <- list()
  for(x in 1:length(vecW)) {
    new_cols[[paste0("w_", x, sep="")]] = vecW[x]
  }
  res <- as_tibble(new_cols)
  
  objf1val <- objectiveFunction1(tbl)
  objf2val <- objectiveFunction2(tbl)
  
  res <- res %>%
    mutate(absVaR = objf1val\(VaR\)abolute) %>%
    mutate(relVaR = objf1val\(VaR\)relative) %>%
    mutate(expRet = objf2val) %>%
    mutate(pAbsVaR = absVaR * 100) %>%
    mutate(pRelVaR = relVaR * 100) %>%
    mutate(pExpRet = expRet * 100)
  
  return(res)
}

The tibble generated by the function above will be used to find the non-dominated solutions using the following custom function:

getNonDominated <- function(tbl) {
  
  idxVar <- which(colnames(tbl) == "relVaR")
  idxExpR <- which(colnames(tbl) == "expRet")
  
  i <- order(tbl[, idxVar], tbl[, idxExpR], decreasing=FALSE)
  frontier <- rep(0, length(i))
  k <- 0; 
  y <- Inf
  for (j in i) {
    if (tbl[j, idxExpR] < y) {
      frontier[k <- k+1] <- j
      y <- tbl[j, idxExpR]
    }
  }
  return(frontier[1:k])
}

Main R code

The code within the tictoc ran for 2 minutes, I have a Windows laptop, i5 CPU (8 vCores), 16GB RAM.

## 1. Create random particles tibble ----

NUMBER_OF_ASSETS = 4
NUMBER_PARTICLES = 1000

lrandomparticles <- lapply(X = 1:NUMBER_PARTICLES, function(x){
  generateRandomWeightsVector(n = NUMBER_OF_ASSETS)
})
random_particles <- lrandomparticles %>%
  bind_rows()

# 1000 random solutions
> random_particles
# A tibble: 1,000 x 4
      w_1    w_2    w_3    w_4
    <dbl>  <dbl>  <dbl>  <dbl>
 1 0.424  0.431  0.0569 0.0873
 2 0.283  0.363  0.126  0.227 
 3 0.351  0.258  0.0496 0.341 
 4 0.266  0.218  0.431  0.0854
 5 0.225  0.304  0.329  0.142 
 6 0.298  0.0952 0.409  0.198 
 7 0.190  0.197  0.424  0.189 
 8 0.335  0.310  0.264  0.0912
 9 0.0437 0.430  0.274  0.252 
10 0.0981 0.413  0.0400 0.449 
# ... with 990 more rows

## 2. Generate particle & objective functions' results tibble ----

tic()
lparticlesObjFunResults <- lapply(1:NUMBER_PARTICLES, function(x){
  
  weights <- as.numeric(random_particles[x,])
  
  returns_daily_tbl %>%
    formatTibble() %>%
    getWeigthedReturns(vecA = assests, vecW = weights) %>%
    getMeanWeigthedReturns() %>%
    getObjectiveFunctionsValues(vecW = weights) %>%
    mutate(sharpe = expRet/relVaR)
  
})
toc()

particlesObjFunResults <- lparticlesObjFunResults %>% 
  bind_rows()

> particlesObjFunResults
# A tibble: 1,000 x 11
      w_1    w_2    w_3    w_4  absVaR relVaR    expRet pAbsVaR pRelVaR pExpRet sharpe
    <dbl>  <dbl>  <dbl>  <dbl>   <dbl>  <dbl>     <dbl>   <dbl>   <dbl>   <dbl>  <dbl>
 1 0.424  0.431  0.0569 0.0873 -0.0109 0.0113 -0.000396   -1.09    1.13 -0.0396 0.0352
 2 0.283  0.363  0.126  0.227  -0.0106 0.0110 -0.000387   -1.06    1.10 -0.0387 0.0352
 3 0.351  0.258  0.0496 0.341  -0.0107 0.0111 -0.000390   -1.07    1.11 -0.0390 0.0353
 4 0.266  0.218  0.431  0.0854 -0.0110 0.0113 -0.000355   -1.10    1.13 -0.0355 0.0314
 5 0.225  0.304  0.329  0.142  -0.0108 0.0112 -0.000367   -1.08    1.12 -0.0367 0.0329
 6 0.298  0.0952 0.409  0.198  -0.0106 0.0109 -0.000353   -1.06    1.09 -0.0353 0.0324
 7 0.190  0.197  0.424  0.189  -0.0108 0.0111 -0.000355   -1.08    1.11 -0.0355 0.0319
 8 0.335  0.310  0.264  0.0912 -0.0108 0.0111 -0.000373   -1.08    1.11 -0.0373 0.0336
 9 0.0437 0.430  0.274  0.252  -0.0107 0.0110 -0.000376   -1.07    1.10 -0.0376 0.0340
10 0.0981 0.413  0.0400 0.449  -0.0112 0.0116 -0.000396   -1.12    1.16 -0.0396 0.0340
# ... with 990 more rows

ndidx <- getNonDominated(tbl = particlesObjFunResults)

gp <- ggplot() +
  geom_point(particlesObjFunResults[ndidx,], mapping = aes(x = pRelVaR, y = pExpRet), color = "red") +
  geom_point(particlesObjFunResults[-ndidx,], mapping = aes(x = pRelVaR, y = pExpRet), color = "black")
ggplotly(gp) 

Be reminded that the objective function f2 outputs negative values for the portfolio expected returns (because we consider a minimization problem, see the figure of Pareto-optimal objective vector at the beginning of the article). Thus, we are actually displaying the frontier upsides down.

Below you will find the 16 non-dominated solutions (red points) along with their corresponding VaR (%) and expected return (%) results (expressed in percentage), keeping the negative sign of the expected return (%).

In the Nonparametric VaR article we considered an equally distributed weight set (25% weight for each asset) and obtained an expected return of 0.032% and a relative VaR of 1.08%. We see that the first 3 non-dominated solutions below provide a higher expected return (ignore the negative sign) with less risk.

> particlesObjFunResults[ndidx,] %>% 
    select(w_1, w_2, w_3, w_4, pRelVaR, pExpRet) %>% 
    arrange(pRelVaR)
# A tibble: 16 x 6
     w_1    w_2    w_3   w_4 pRelVaR pExpRet
   <dbl>  <dbl>  <dbl> <dbl>   <dbl>   <dbl>
 1 0.313 0.0748 0.386  0.226    1.07 -0.0355
 2 0.310 0.110  0.354  0.225    1.07 -0.0359
 3 0.283 0.138  0.347  0.232    1.07 -0.0360
 4 0.345 0.0844 0.318  0.252    1.08 -0.0361
 5 0.447 0.193  0.101  0.259    1.08 -0.0384
 6 0.359 0.256  0.0869 0.298    1.08 -0.0387
 7 0.420 0.338  0.0818 0.161    1.08 -0.0391
 8 0.458 0.310  0.0629 0.169    1.09 -0.0391
 9 0.378 0.394  0.0476 0.181    1.09 -0.0395
10 0.302 0.419  0.0466 0.233    1.10 -0.0396
11 0.244 0.481  0.0645 0.211    1.12 -0.0396
12 0.168 0.527  0.0759 0.230    1.12 -0.0397
13 0.217 0.446  0.0313 0.305    1.12 -0.0398
14 0.378 0.453  0.0408 0.128    1.12 -0.0398
15 0.175 0.600  0.0810 0.144    1.16 -0.0399
16 0.105 0.604  0.0752 0.216    1.17 -0.0399

Conclusion

In this article I wanted to illustrate the notion of non-dominated solutions applied to a portofolio optimization use case. Here we started by generating a random set of 1000 weight vectors in order to find the non-dominated solutions among this set of 1000 weight vectors. Our utimate goal will be to generate these weight vectors and non-dominated solutions with the MOPSO algorithm, but first we will explain other notions such as finding good local guides with the Sigma method [1].

References

[1] Mostaghim S., Teich J., « Strategies for Finding Local Guides in Multi-objective Particle Swarm Optimization (MOPSO) »

[2] Alfaro Cid E. et al., « Minimizing value-at-risk in a portfolio optimization problem using a multiobjective genetic algorithm », International Journal of Risk Assessment and Management, 2011

Go to R-bloggers for R news and tutorials contributed by hundreds of R bloggers.

Introduction

This is the first of a series of articles explaining how to apply multi-objective particle swarm optimization* (MOPSO) to portfolio management.

Notion of Value-at-Risk (VaR)

As per P. Jorion's book [1], "we can formally define the value at risk (VaR) of a portfolio as the worst loss over a target horizon such that there is a low, prespecified probability that the actual loss will be larger."

This definition involves two quantitative factors, the horizon and the confidence level.

Define c as the confidence level and L as the loss, measured as a positive number. VAR is also reported as a positive number.

A general definition of VAR is that it is the smallest loss, in absolute value, such that

Take, for instance, a 99 percent confidence level, or c = 0.99. VAR then is the cutoff loss such that the probability of experiencing a greater loss is less than 1 percent.

Computing VaR

The figure below comes from a Bionic Turtle video available in YouTube [2], it takes only 6 minutes, have a look!

• The nonparametric approach uses actual historical data, it is simple and easy to use. There is no hypothesis about the distribution of the data. This is the approach used in this article.

• The Monte Carlo simulation is about imagining hypothetical future data. It generates its own data i.e., given a model specification about the assets of the portfolio we run any number of trials in order to obtain a simulated distribution of data.

• The parametric approach uses the data (as an excuse) to find a distribution, usually a normal distribution which requires only two parameters: the mean and the standard deviation.

As per [3], "approaches to quantify VaR such as delta-normal, delta-gamma or Monte Carlo simulation method rely on the normality assumption or other prespecified distributions. These approaches have several drawbacks, such as the estimation of parameters and whether the distribution fit properly the data in the tail or not."

Computing nonparametric VaR with R

Example

Below is the example taken from Jorion's book [1]. I'm going to copie his explanation about the VaR computation, and then I will base my explanations and code on my interpretation of Jorion's book [1] explanations and figure.

Assume that this (the nonparametric VaR) can be used to define a forward-looking distribution, making the hypothesis that daily revenues are identically and independently distributed.

We can derive the VAR at the 95 percent confidence level from the 5 percent left-side “losing tail” in the histogram.

The figure (above), for instance, reports J.P. Morgan’s distribution of daily revenues in 1994. The graph shows how to compute nonparametric VAR.

Let W' be the lowest portfolio value at the given confidence level c.

From this graph, the average revenue is about $5.1 million. There is a total of 254 observations; therefore, we would like to find W' such that the number of observations to its left is 254 × 5 percent = 12.7.

We have 11 observations to the left of −\(10 million and 15 to the left of −\)9 million. Interpolating, we find W' = −$9.6 million.

The VaR of daily revenues, measured relative to the mean, is VAR = E (W) − W' = \(5.1 − (−\)9.6) = $14.7 million.

If one wishes to measure VaR in terms of absolute dollar loss, VaR then is $9.6 million.

Finally, it is useful to describe the average of losses beyond VaR, which is \(20 million here. Adding the mean, we find an expected tail loss (ETL) of \)25 million.*

Basis of my explanation

Let us consider that the daily returns ofthe figure correspond to a portfolio composed of four assets: Microsoft ("MSFT"), Apple ("AAPL"), Google ("GOOG"), and Netflix ("NFLX").

In order to display the histogram we should have a (final) tibble like this one:

# A tibble: 1,257 x 2
   date       mean.weighted.returns
   <date>                     <dbl>
 1 2017-01-04              0.000652
 2 2017-01-05              0.00204 
 3 2017-01-06              0.00184 
 4 2017-01-09              0.000355
 5 2017-01-10             -0.000607
 6 2017-01-11              0.00144 
 7 2017-01-12             -0.00159 
 8 2017-01-13              0.00228 
 9 2017-01-17             -0.000297
10 2017-01-18              0.000252
# ... with 1,247 more rows

The tibble above has a column called "mean.weighted.returns" which means that we have taken the weighted mean of the assets' daily returns. Here, the weights have been equally distributed e.g., 25% MSFT, 25% AAPL, 25% GOOG, and 25% NFLX.

OK, let us then generate this tibble.

R packages

library(PerformanceAnalytics)
library(quantmod)
library(tidyquant)
library(tidyverse)
library(timetk)
library(skimr)
library(plotly)

Get the data

Let us collect 5 years of data e.g., the prices of the four assets: Microsoft ("MSFT"), Apple ("AAPL"), Google ("GOOG"), and Netflix ("NFLX"). For this, we will use the tq_get() from tidyquant package.

I prefer to use the tidyquant package because I like to work with tibbles, I don't have to worry about the different time series data format (xts, ...).

We will directly compute the daily returns of the adjusted prices.

assests <- c("MSFT", "AAPL", "GOOG", "NFLX")

end <- "2021-12-31" %>% ymd()
start <- end - years(5) + days(1)

returns_daily_tbl <- assests %>%
  tq_get(from = start, to = end) %>%
  group_by(symbol) %>%
  tq_transmute(select = adjusted,
               mutate_fun = periodReturn, 
               period = "daily") %>%
  ungroup()

> returns_daily_tbl
# A tibble: 5,032 x 3
   symbol date       daily.returns
   <chr>  <date>             <dbl>
 1 MSFT   2017-01-03      0       
 2 MSFT   2017-01-04     -0.00447 
 3 MSFT   2017-01-05      0       
 4 MSFT   2017-01-06      0.00867 
 5 MSFT   2017-01-09     -0.00318 
 6 MSFT   2017-01-10     -0.000319
 7 MSFT   2017-01-11      0.00910 
 8 MSFT   2017-01-12     -0.00918 
 9 MSFT   2017-01-13      0.00144 
10 MSFT   2017-01-17     -0.00271 
# ... with 5,022 more rows

Clean the data

Because of the daily return calculation, the first row ("2017-01-03") of each asset will be zero. Let us delete these four rows, one per asset (or symbol).

rows_to_delete <- which(returns_daily_tbl$date == ymd("2017-01-03"))
returns_daily_tbl <- returns_daily_tbl[-rows_to_delete,]

Define the weights vector

wts_tbl <- returns_daily_tbl %>%
  distinct(symbol) %>%
  mutate(weight = c(.25, .25, .25, .25))

Apply the weights

Let us apply the weights by creating two new columns, weight and weighted.returns. The symbol column will be converted from character to factor.

returns_daily_weighted_tbl <- returns_daily_tbl %>%
  group_by(symbol) %>%
  mutate(weight = case_when(symbol == "MSFT" ~ as.numeric(wts_tbl[1,2]),
                            symbol == "AAPL" ~ as.numeric(wts_tbl[2,2]),
                            symbol == "GOOG" ~ as.numeric(wts_tbl[3,2]),
                            symbol == "NFLX" ~ as.numeric(wts_tbl[4,2]))) %>%
  mutate(weighted.returns = daily.returns * weight) %>%
  mutate(symbol = as.factor(symbol))

> returns_daily_weighted_tbl
# A tibble: 5,028 x 5
# Groups:   symbol [4]
   symbol date       daily.returns weight weighted.returns
   <fct>  <date>             <dbl>  <dbl>            <dbl>
 1 MSFT   2017-01-04     -0.00447    0.25       -0.00112  
 2 MSFT   2017-01-05      0          0.25        0        
 3 MSFT   2017-01-06      0.00867    0.25        0.00217  
 4 MSFT   2017-01-09     -0.00318    0.25       -0.000796 
 5 MSFT   2017-01-10     -0.000319   0.25       -0.0000798
 6 MSFT   2017-01-11      0.00910    0.25        0.00228  
 7 MSFT   2017-01-12     -0.00918    0.25       -0.00229  
 8 MSFT   2017-01-13      0.00144    0.25        0.000359 
 9 MSFT   2017-01-17     -0.00271    0.25       -0.000678 
10 MSFT   2017-01-18     -0.000480   0.25       -0.000120 
# ... with 5,018 more rows

Compute the mean

Group by date and take the mean of the 4 assets' weighted daily returns.

returns_daily_weighted_mean_tbl <- returns_daily_weighted_tbl %>%
  group_by(date) %>%
  summarise(mean.weighted.returns = mean(weighted.returns))

> returns_daily_weighted_mean_tbl
# A tibble: 1,257 x 2
   date       mean.weighted.returns
   <date>                     <dbl>
 1 2017-01-04              0.000652
 2 2017-01-05              0.00204 
 3 2017-01-06              0.00184 
 4 2017-01-09              0.000355
 5 2017-01-10             -0.000607
 6 2017-01-11              0.00144 
 7 2017-01-12             -0.00159 
 8 2017-01-13              0.00228 
 9 2017-01-17             -0.000297
10 2017-01-18              0.000252
# ... with 1,247 more rows

And that's it! we have finally obtained the tibble from which we will generate the histogram and calculate the VaR.

Display summary statistics

Let us define a skimr custom function to add the min and max values to the default summary statistics display of the previous tibble.

myskim <- skim_with(numeric = sfl(max, min), 
                    append = TRUE)

returns_daily_weighted_mean_tbl %>%
  myskim()

> returns_daily_weighted_mean_tbl %>%
     myskim()
-- Data Summary ------------------------
                           Values    
Name                       Piped data
Number of rows             1257      
Number of columns          2         
_______________________              
Column type frequency:               
  Date                     1         
  numeric                  1         
________________________             
Group variables            None      

-- Variable type: Date ------------------------------------------------------------------------------------------------------------------------------------------
# A tibble: 1 x 7
  skim_variable n_missing complete_rate min        max        median     n_unique
* <chr>             <int>         <dbl> <date>     <date>     <date>        <int>
1 date                  0             1 2017-01-04 2021-12-30 2019-07-05     1257

-- Variable type: numeric ---------------------------------------------------------------------------------------------------------------------------------------
# A tibble: 1 x 13
  skim_variable         n_missing complete_rate     mean      sd      p0      p25      p50     p75   p100 hist     max     min
* <chr>                     <int>         <dbl>    <dbl>   <dbl>   <dbl>    <dbl>    <dbl>   <dbl>  <dbl> <chr>  <dbl>   <dbl>
1 mean.weighted.returns         0             1 0.000372 0.00407 -0.0312 -0.00131 0.000547 0.00230 0.0264 ▁▁▇▂▁ 0.0264 -0.0312

From the skimr resut above we can see that the mean of mean.weighted.returns (or the portfolio Expected Return) is 0.000372 or 0.037%. You can also have a quick look at the displayed (mini) histogram provided.

Compute nonparametric VaR

To compute the absolute nonparametric VaR at 99% confidence level with use the tidyquant::tq_performance() function. Thus, you must specify:

• Ra: the column of asset returs (here, the mean.weighted.returns)

• performance_fun: the performnace function (here, the VaR)

• p: here, the confidence level (99%)

• method: for nonparametric VaR we use the *historical *method as explained at the beginning of the article.

VaR.tq <- returns_daily_weighted_mean_tbl %>% 
  tq_performance(Ra = mean.weighted.returns,
                 performance_fun = VaR, 
                 p = .99, 
                 method = "historical")

> cat("VaR @99% = ", VaR.tq$VaR)
VaR @99% =  -0.01050326

We obtain the absolute VaR @99% = -0.01050326, this is the cutoff loss such that the probability of experiencing a greater loss is less than 1 percent.

The relative (to the mean) VaR @99% should be 0.000372 - (-0.01050326) = 0.01087526, let us check:

> mean(returns_daily_weighted_mean_tbl\(mean.weighted.returns) - VaR.tq\)VaR
[1] 0.0108755

Here, for this fictitious example, we consider the holding period = 1 day. Since we are computing a nonparametric VaR for which no hypothesis of the distribution e.g., normality, has been made, we cannot apply the "VaR(T days) = VaR*SQRT(T)" rule.

Visualize nonparametric VaR

gp <- ggplot(returns_daily_weighted_mean_tbl, aes(x=mean.weighted.returns)) +
  geom_histogram(color="black", fill="white") +
  geom_vline(aes(xintercept=VaR.tq$VaR), color="blue", linetype="dashed", size=1)
ggplotly(gp)

Apply positions amount

Let us consider an investment of \(1,000,000 which has been equally distributed across all four assets e.g., 25% per asset thus, \)250,000 per asset.

The portfolio Expected Return is 0.000372 of \(1,000,000 = \)372

The absolute VaR @99% is -0.01050326 x \(1,000,000 = -\)10,503.26, this is the cutoff loss such that the probability of experiencing a greater loss is less than 1 percent.

The relative (to the mean) VaR @99% is \(372 - (-\)10,503.26) = $10,875.26

Change the weights

Say we apply the following weights to the four assets:

> wts_tbl2
# A tibble: 4 x 2
  symbol weight
  <chr>   <dbl>
1 MSFT     0.2 
2 AAPL     0.15
3 GOOG     0.15
4 NFLX     0.5

The portfolio Expected Return is $377

The absolute VaR @99% is -$11,228, this is the cutoff loss such that the probability of experiencing a greater loss is less than 1 percent.

The relative (to the mean) VaR @99% is $11,606

Consequently, by applying these new weights we have increased the VaR of the portfolio. Thus, in terms of risk management, this new set of weights was not a good choice.

Towards portfolio optimization

Now, in terms portfolio optimization when considering the following objective function which is the minimization of the VaR relative to the mean equation:

the investor preferences are expressed as a function of return and maximum loss, and a VaR-efficient frontier (made up of Pareto efficient portfolios) in the mean-VaR space has to be found. For this reason, we will use multiobjective PSO approach to find VaR-efficient portfolios by solving the following optimization problem: [3]

This is the goal of this series of articles covering the application of MOPSO algorithm to portfolio optimization.

References

[1] Jorion, Philippe "Value-at-Risk", Third Edition

[2] FRM: Three approaches to value at risk (VaR), Bionic Turtle, 16 juil. 2008, YouTube.

[3] Alfaro Cid E. et al., « Minimizing value-at-risk in a portfolio optimization problem using a multiobjective genetic algorithm », International Journal of Risk Assessment and Management, 2011

Note de l'auteur: cet article a pour objectif de partager mon travail sur la conception d'un outil d'optimisation de portefeuille destiné aux utilisateurs travaillant dans le domaine de la gestion de portefeuilles. L'outil est resté au stade "prototype" et n'a jamais fait partie d'aucune démarche commerciale. Il n'est jamais devenu un produit ... et avec un peu recul, je peux dire qu'il était plutôt destinés aux data scientists spécialisés dans la finance qu'aux asset managers. Par ailleurs, je ne suis pas un expert de la finance, je suis un passionné de la Swarm Intelligence. Les explications financières et scientifiques proviennent de sources dont les références bibliographiques sont indiquées à la fin de l'article.

1.1. Contexte scientifique

Le présent projet en Data Science propose une alternative à la méthode appliquée dans l’étude scientifique effectué par Alfaro Cid E. et al., voir référence [ALF], pour la minimisation du risque d’un portefeuille d’actifs financiers. En effet, dans [ALF] on propose une méthode de minimisation de la Value-at-Risk (valeur à risque) avec des algorithmes génétiques (GA). Dans notre étude, nous proposons une version modifiée d’un autre algorithme, également issu du domaine de la Swarm Intelligence (intelligence de l’essaim), appelé Particle Swarm Optimization (PSO) ou optimisation par essaims particulaires (OEP).

Nous essayons dans ce projet de démontrer que les portefeuilles (ou solutions) trouvés par PSO sont plus efficaces que ceux trouvés par GA vis-à-vis des solutions trouvées par une méthode classique de minimisation du risque. Pour ce faire, nous avons influencé le comportement standard de l’algorithme.

Par ailleurs, un outil permettant de générer les solutions de chaque algorithme sur une longue période, comprenant plusieurs tendances du marché, a été développé. L’outil permet ensuite d’appliquer les solutions trouvées à des scénarios correspondants à une tendance spécifique (soit une hausse soit une baisse) et ultérieure dans le temps et par conséquent, de valider l’efficacité des portefeuilles trouvés. Finalement, l’unexpected loss (ou perte inattendue) est calculée, c’est un indicateur essentiel qui permet de maîtriser le coût en capital exigé par les régulateurs.

Malgré l’existence d’outils permettant de calculer la VaR, ceux qui permettent de la minimiser sont inexistants sur l’Internet. Nous pensons que ce type de solution devrait peut-être exister dans le cercle très fermé des éditeurs logiciels financiers avec des développements customisés, cependant nous n’avons pas de connaissance à l’heure actuelle sur les méthodes et les types d’optimisation proposés par ces solutions.

La Value-at-Risk (VaR) est un indicateur très utilisé en gestion de risques financiers. Elle permet de mesurer un niveau de perte inattendue qui peut être dépassée à un horizon de temps donnée avec une probabilité donnée. Elle est fondamentale pour les investisseurs en bourse, les asset managers et également pour les banques et les assurances qui doivent couvrir leurs pertes inattendues par du capital (réglementation Bale, Solvency).

Minimiser la VaR est un « problème difficile » (terme définie dans [CLE]), en effet, la VaR est une fonction non convexe et non différentiable, par conséquent sa minimisation ne peut s’effectuer avec des méthodes classiques d’optimisation telles que la descente du gradient. Les algorithmes issus de la Swarm Intelligence s’adaptent bien à ce genre de « problèmes difficiles ».

L’optimisation appliquée est en réalité une optimisation multi-critère car non seulement on essaie de minimiser la VaR mais on cherche également à maximiser le rendement ou gain de portefeuilles d’actifs financiers.

1.1.1. Enjeux

• Une minimisation judicieuse de la VaR permet de maitriser le coût en capital exigé par les régulateurs.

• Des adaptations innovantes des algorithmes issus de la swarm intelligence permettent de réaliser de telles optimisations de la VaR.

• Concevoir une nouvelle démarche pour les acteurs du domaine financier leur permettant d’intégrer simultanément les solutions trouvées par plusieurs méthodes (classiques et issues de la Swarm Intelligence) et d’effectuer un choix de la meilleure solution.

1.2. Etat de l’art existant et disponible au début des travaux

1.2.1. Notion de « problème difficile »

Selon [CLE], « la difficulté d’un problème d’optimisation dans un espace de recherche donnée est la probabilité de ne pas trouver une solution en choisissant une position au hasard selon une distribution uniforme. C’est donc la probabilité d’échec au premier essai. »

Ci-dessous trois exemples extraits d’un jeu d’essai classique pour les problèmes d’optimisation. Ce sont des fonctions possédant un espace de recherche à deux dimensions (axes x1 et x2).

Figure 1 Deux problèmes difficiles (Tripod et Alpine) et un problème convexe (Parabole)

Le problème « Tripod » déroute de nombreux algorithmes qui se sont facilement piéger dans l’un ou l’autre des deux minimums locaux. Il présente des discontinuités brutales ce qui ne gêne en rien le PSO. La « Parabole » présente un seul minimum, de par son caractère stochastique, le PSO ne pourra pas être aussi efficace qu’un algorithme déterministe, tel que la descente du gradient.

L’objectif de ce sous-chapitre est de rappeler que la minimisation du VaR est un « problème difficile » pour lequel les algorithmes de la Swarm Intelligence sont plus adaptés que les algorithmes classiques tels que la programmation quadratique (QP).

1.2.2. Gestion de portefeuille : Le modèle de Markowitz

Le modèle de Markowitz fait la double hypothèse que :

1. Les marchés d'actifs financiers sont efficients.

• C'est l'hypothèse d'efficience du marché selon laquelle les prix et rendements des actifs sont censés refléter, de façon objective, toutes les informations disponibles concernant ces actifs.

1. Les investisseurs ont de l'aversion envers le risque.

• Ils ne seront prêts à prendre plus de risques qu'en échange d'un rendement plus élevé.

• À l'inverse, un investisseur qui souhaite améliorer la rentabilité de son portefeuille doit accepter de prendre plus de risques.

• L'équilibre risque/rendement jugé optimal dépend de la tolérance au risque de chaque investisseur.

1.2.3. Rendement et Volatilité d’un Portefeuille

On suppose généralement que la préférence de l'investisseur pour un couple risque / rendement peut être décrite par une fonction d'utilité quadratique. De plus, les évolutions du marché sont supposées suivre une distribution symétrique de Pareto.

Par conséquent, seuls le rendement attendu (l'espérance de gain) et la volatilité (l'écart type) sont les paramètres examinés par l'investisseur. Ce dernier ne tient pas compte des autres caractéristiques de la distribution des gains, comme son asymétrie ou même le niveau de fortune investi.

Le rendement d'un portefeuille est une combinaison linéaire de celui des actifs qui le composent, pondérés par leur poids ωi dans le portefeuille. Placé dans un univers incertain, l’investisseur ne peut pas calculer d’avance la rentabilité, car la valeur du titre en fin de période est aléatoire, ainsi que dans certain cas, la rémunération perçue durant la période. L’investisseur utilise alors, un rendement attendu qui est la moyenne des rendements possibles pondérés par leur possibilité de réalisation.

La volatilité du portefeuille (constatez le symbole grec « Sigma », ci-dessus) est une fonction de la corrélation entre les actifs qui le composent. Cette fonction n'est pas linéaire.

1.2.4. Les portefeuilles Sigma-efficient

Le portefeuille de variance minimale (Minimum Variance Portfolio) est le portefeuille efficient avec le risque « Volatilité » minimale, explications [CAP] :

• En supposant un grand nombre d'actifs financiers et toutes les combinaisons possibles, il est donc possible de calculer l'espérance et la variance du rendement prévisionnel d'un très grand nombre de portefeuilles.

• Chaque portefeuille aura donc des caractéristiques d'espérance et de variance différentes, en fonction du choix des actifs, des pondérations et des corrélations entre les actifs.

• Il est alors possible d'obtenir un graphique représentant le risque et le rendement de chaque portefeuille, et de déterminer une frontière d'efficience à partir des portefeuilles dominants/dominés.

• Chaque point sur la courbe bleue à partir du point rouge "Portefeuille à variance minimale" correspond à un portefeuille efficient ; c'est ce que l'on appelle la frontière d'efficience ou frontière de Markowitz.

Figure 3 Graphique illustrant une frontière efficiente et la solution (en rouge) représentant le portefeuille ou solution à variance minimale.

• Si un portefeuille se trouve dans la zone hachurée, il n'est pas efficient car il existe (1) un autre portefeuille apportant ce même niveau de rendement mais avec un risque plus faible ou (2) un autre portefeuille apportant un rendement supérieur pour le niveau de risque considéré.

• Chaque investisseur peut ensuite choisir n'importe quel portefeuille sur le demi-courbe bleue, en fonction du niveau de risque qu'il est prêt à supporter ou bien du rendement qu'il espère (maximisation de l'utilité de l'investisseur).

1.2.5. Les limites du modèle de Markowitz

Avec les ajustements récents, ce modèle s’est trouvé plusieurs limites soulevées par plusieurs praticiens de la théorie financière. Parmi ces limites, on note :

• Le modèle suppose la rationalité des investisseurs. Or, la réalité a prouvé qu’une croyance tout à fait irrationnelle peut être vu légitime par le seul fait qu’elle soit collectivement admise par un opérateur crédible ;

• Le modèle ne s’est pas intéressé à la décomposition du risque global du marché mais s’est limité à l’analyse et à l’évaluation du risque individuel ou spécifique ; d’où l’apparition d’un nouveau modèle d’évaluation des actifs financiers (MEDAF) ;

• Le modèle suppose également la normalité de la distribution des rentabilités, chose qui n’est pas toujours vérifiable dans la réalité. Cette limite a été résolue par l’apparition du modèle de « Dominance stochastique » qui s’applique à tout type de distribution ;

• La variance a été considérée comme une mesure simplificatrice de la fonction de la rentabilité, tandis que la « Dominance stochastique » admet une comparaison de la distribution entière ;

• La variance étant une mesure non parfaite du risque, une nouvelle technique de mesure a été développée en 1993, appelé Value-At-Risk (VaR). Cette technique permet de déterminer la perte maximale probabilisée sur un portefeuille quelconque.

1.2.6. La Value-At-Risk (Valeur à risque)

La VaR est une notion utilisée généralement pour mesurer le risque de marché d'un portefeuille d'instruments financiers. Elle correspond au montant de pertes qui ne devrait être dépassé qu'avec une probabilité donnée sur un horizon temporel donné. L'utilisation de la VaR n'est désormais plus limitée aux instruments financiers : on peut en faire un outil de gestion des risques dans tous les domaines.

La VaR est définie par rapport à un horizon de temps T et le seuil de confiance α (on parle par exemple de VaR 10 jours 95%).

La VaR T jours à une confiance α peut être définie (de manière équivalente) comme :

• La pire des pertes pouvant être constatée en T jours dans les α = 95% de cas les plus favorables

• La moindre perte pouvant être constatée en T jours dans les 1-α = 5% de cas les moins favorables

• Le montant au-delà duquel une perte survient en T jours avec une probabilité de 1-α = 5%

1.2.7. La VaR et les pertes inattendues

La VaR est un indicateur essentiel pour les régulateurs, en effet elle permet de maitriser le coût en capital exigé par ces derniers.

Basel II Operational Risk, AMA Quantitative Standards 669(b) : « Les autorités de contrôle demanderont à la banque de calculer ses exigences de fonds propres réglementaires en faisant la somme de la perte attendue (EL) et de la perte inattendue (UL), à moins que la banque ne puisse démontrer qu’elle intègre adéquatement le niveau de solvabilité dans ses pratiques commerciales internes. Autrement dit, pour fonder l'exigence de fonds propres réglementaire minimale sur UL uniquement, la banque doit être en mesure de démontrer, à la satisfaction de son autorité de contrôle nationale, qu'elle a mesuré et comptabilisé son exposition à l’EL ».

1.2.8. Notre approche par rapport aux études existantes

La référence principale est l’étude de l’équipe d’Alfaro Cid E. et al., « Minimizing Value-at-Risk in a portfolio optimization problem using a multiobjective genetic algorithm (GA) » [ALF]. Cette étude nous a servie de base pour la définition de la démarche et les objectifs à atteindre dans ce projet. Ce qui nous différencie de cette étude est l’utilisation d’un autre algorithme d’optimisation multi-critère issu également de la Swarm Intelligence, à savoir le multiobjective PSO (MOPSO).

L’étude de Yourdkhani S., « Portfolio Management by using Value-at-Risk (VaR) - A Comparison between Particle Swarm Optimization and Genetic Algorithms » [YOU], montre en effet une comparaison entre PSO et GA. Cependant, l’optimisation appliquée est monocritère (absence de maximisation de la rentabilité) et la comparaison est effectuée en termes de performances (rapidité et robustesse de l’algorithme). Ce qui nous différencie de cette étude est l’utilisation d’un algorithme d’optimisation multicritère et une comparaison en termes de l’efficacité des portefeuilles (solutions) ; nous proposons donc un comparatif lié au cas d’usage métier.

1.3. Objectifs techniques visés et Performances à atteindre

Nous souhaitons effectués un comparatif entre nos résultats et ceux de l’étude [ALF].

Le comparatif sera basé sur l’écart d’efficacité (ou erreur de substitution), définit dans [ALF], entre les portefeuilles VaR-efficient trouvés par les algorithmes de Swarm Intelligence (NSGA II et MOPSO, voir chapitre 3) et les portefeuilles Sigma-efficient trouvés par la méthode classique (programmation quadratique.

Il y a plusieurs niveaux d’écart d’efficacité :

• Ecart supérieur à -1% (VaR-efficient moins efficace mais proche de Sigma-efficient)

• Ecart supérieur à -0.5% (VaR-efficient moins efficace mais très proche de Sigma-efficient)

• Ecart supérieur à 0%

• Ecart supérieur à +0.5%

• Ecart supérieur à +1%

Nous cherchons à connaître la proportion de portefeuilles VaR-efficient qui se trouvent dans chaque écart défini ci-dessus.

D’autres indicateurs de performances sont utilisés : on calcule les différences (ou erreurs) entre les valeurs VaR des portefeuilles VaR-efficient et des portefeuilles Sigma-efficient :

• MSE (Mean Square Error)

• MAE (Mean Absolute Error)

1. Données In-samples, voir chapitre 1.5.2.2.3; l’objectif est de montrer qu’il existe un écart d’efficacité important en faveur des solutions trouvées par les algorithmes de la Swarm Intelligence (NSGA II et MOPSO) par rapport à celles de la méthode classique (programmation quadratique, QP). Ci-dessous les résultats obtenus par l’étude [ALF] :

Tableau 1 Résultats de l'équipe [ALF], comparatif NSGA-II vs QP pour les périodes à plusieurs tendances (in-samples)

1. Données Out-samples, voir chapitre 1.5.2.2.3 ; l’objectif est de tester les solutions trouvées dans le scénario précédents sur les valeurs d’actifs financiers correspondantes à des périodes spécifiques, de baisse ou de hausse, différentes et ultérieures à celles des données in-samples. On cherche à constater si cet écart d’efficacité en faveur des solutions trouvées par les algorithmes de la Swarm Intelligence (NSGA II et MOPSO) a pu être conservé. Ci-dessous les résultats obtenus par l’étude [ALF] :

Tableau 2 Résultats de l'équipe [ALF], comparatif NSGA-II vs QP pour les périodes à tendance unique (out-sample)

Figure 2 Les quatre périodes in-sample avec les période out-sample correspondantes

Finalement, nous comparons les écarts entre NSGA II et MOPSO en espérant montrer que la proportion des portefeuilles VaR-efficient trouvés par MOPSO par rapport à QP dans chaque niveau d’écart d’efficacité est plus importante que celle trouvée pour NSGA II par rapport à QP dans [ALF].

1.3.1. Algorithmes génétiques (AG ou GA)

Les algorithmes génétiques (Genetic Algorithms) tentent d’imiter informatiquement les procédés par lesquels la sélection naturelle opère, et de les appliquer pour résoudre divers problèmes, en entreprise ou dans le cadre de la recherche [LAR].

Ils fournissent un cadre pour étudier les effets de facteurs inspirés de la biologie, comme la sélection d’un compagnon, la reproduction, la mutation et le recouvrement d’information génétique.

Dans le monde des GA, la qualité des différentes solutions est comparée et les meilleures solutions potentielles évoluent pour produire des solutions plus optimales encore.

1.3.1.1. Non-dominated Sorting Genetic Algorithm-II (NSGA II)

De manière générale, les algorithmes évolutionnistes multi-objectif affectent un score à une solution selon qu’elle est dominée ou non par d’autres solutions de la population courante et éventuellement si elle domine d’autres solutions. Un exemple classique est NSGA II. Cet algorithme génétique utilise une méthode de ranking qui attribue aux solutions non-dominées (voir Annexe) de la population courante le meilleur score. Puis les solutions, qui ne sont dominées que par les solutions potentiellement efficaces, reçoivent le second meilleur score et ainsi de suite.

De cette manière, la population est organisée en couches où chaque couche contient des solutions non comparables entre elles

1.3.2. Algorithmes d’optimisation par essaims particulaires (OEP ou PSO)

Le modèle de base de l’optimisation par essaims particulaires (Particle Swarm Optimization) est défini de façon informelle en s’inspirant des échanges d’informations entre abeilles d’une ruche. Un fois qu’un bon site a été localisé par une abeille ouvrière, il est rapidement et efficacement exploité par d’autres [CLE].

Chaque particule (donc abeille) combine linéairement 3 éléments pour décider de son prochain déplacement :

• Sa vitesse actuelle

• La meilleure position qu’elle a trouvée jusqu’ici

• La meilleure position trouvée par ses informatrices

1.3.2.1. Multi-objective PSO (MOPSO)

Le Multi-objective PSO est la version multi-critère de PSO. Comme expliqué dans 3.1.1.1, cet algorithme se base également sur la notion de « domination » entre les solutions. On appelle « archive » (applicable également à NSGA II) l’ensemble de solutions non-dominées (voir Annexe) à un moment ou itération (ou génération) donnée lors de l’exécution de l’algorithme.

Il existe plusieurs méthodes pour la détermination de la non-dominance :

• Le calcul de la sigma-distance, voir [MOS]. C’est la méthode applicable à ce projet.

• Le calcul de la Enhanced Є-dominance, voir [HAO] et [MOS2]

1.4. Incertitudes techniques et scientifiques, verrous technologiques et problèmes à résoudre

1.4.1. Volumétrie

La volumétrie des données appliquée à ce projet est déterminée par la profondeur temporelle de la période in-sample, ici 10 ans. La volumétrie correspondante à une profondeur de 10 ans pour les 12 indices boursiers utilisés pouvait très bien être gérée sur un seul ordinateur portable avec une configuration de 16Go de mémoire vive et un processeur Intel i5.

Cependant, pour l’industrialisation d’une telle solution, il faut apporter un maximum de flexibilité dans la sélection du nombre d’indices et de profondeur temporelle de données lors de l’exécution des différents algorithmes d’optimisation. Par conséquent, nous avons intégré à notre solution un design de calcul distribué dans un environnement Big Data, illustré ci-dessous. Le développement et l’implémentation du calcul distribué de l’algorithme MOPSO reste un « next step » dans la roadmap de notre outil.

Figure 10 Design macro pour le calcul distribué dans un environnement Big Data

1.5. Travaux effectués

1.5.1. Projet Agile

Nous considérons que la psychologie du data scientist ne doit pas se calquer sur la psychologie type d’un développeur efficace ou d’un créateur de startup. Par conséquent, la méthode Agile, ici Scrum, a été adaptée à une démarche Data Science, donc aux cycles de réflexion R&D des data scientists. L’équipe est composée d’un data scientist expérimenté, également Scrum Master, et de trois data scientists junior. Chaque data scientist est responsable d’un algorithme (NSGA-II et MOPSO).

L’environnement technique de développement Data Science a été défini selon les compétences de chaque data scientist en langage R (environnement RStudio) ou en langage Python (environnement Jupyter notebook). L’interface graphique permettant de visualiser et de partager les résultats du benchmark a été développée avec le langage R Shiny

1.5.2. La démarche projet

1.5.2.1. Equipe et rôles

L’équipe est composée d’un data scientist expérimenté, également Scrum Master, et de trois data scientists junior. Chaque data scientist est responsable d’un algorithme (NSGA-II et MOPSO). Un responsable Financial Services de l’entreprise a été désigné comme Product Owner du projet.

En plus des objectifs expliqués dans l’introduction du présent document, nous considérons que la montée en compétences des data scientists junior est primordial pour le succès de l’activité. Par conséquent, les data scientists ont été assisté par le data scientist senior afin de comprendre « la philosophie », ainsi que les avantages et les inconvénients de l’algorithme dont il ou elle avait la responsabilité.

Chaque data scientist était responsable du choix et de l’utilisation d’une librairie spécifique pour exécuter l’algorithme ainsi que de la documentation associée à son travail.

A la fin de chaque itération (sprint) le data scientist junior doit fournir au data scientist senior les résultats des différents scénarios d’optimisation effectués avec les librairies. Le data scientist senior était chargé de collecter les résultats et de les intégrer à l’outil destiné aux asset managers (développé également par le data scientist senior).

Après constatation des limites (manque de flexibilité) des librairies utilisées par les data scientists junor, le data scientist senior décide de prendre en charge le développement de la modification du comportement standard de l’algorithme MOPSO.

1.5.2.2. Démarche Data Science

La démarche data science comprends plusieurs étapes et elle s’exécute de manière itérative, au sein d’un même sprint on peut effectuer soit une partie soit la totalité des étapes, tout dépend de la complexité du problème.

Les étapes de la démarche data science sont les suivantes et elles sont décrites ci-après :

• Collecte des données

• Qualité de la donnée

• Modélisation et optimisation

Les trois étapes précédentes ont été implémentées dans un environnement de programmation en langage R (RStudio).

La visualisation n’est pas une étape de la démarche data science, cependant elle est nécessaire pour le partage des résultats intermédiaires obtenus. L’interface graphique permettant de visualiser et de partager les résultats a été développée avec le langage R Shiny

1.5.2.2.1 Environnent Data Science

o Langage : R version 3.4.4 o IDE : RStudio 1.1.453 o Visualisation : RStudio Shiny Principaux packages utilisés o Collecte de données : package quantmod o Traitement des séries temporelles : package timeSeries o Calcul de la VaR, de la rentabilité et de la Frontière Efficiente avec méthode classique (programmation quadratique) : package fPortfolio

1.5.2.2.2 Collecte de données

Valeurs journalières ajustées (adjusted daily returns) de 12 indices boursiers entre 1990 et 2007 :

1. USA DJ Industrial (DJI)
2. USA SP500 (GSPC)
3. USA Nasdaq (IXIC)
4. Canada SPTSX (GSPTSE)
5. UK Footsie (FTSE)
6. France CAC 40 (FCHI)
7. Germany DAX (GDAXI)
8. Spain IBEX 35 (IBEX)
9. Holland AEX (AEX)
10. Sweden OMX (OMX)
11. Japan Nikkei 225 (N225)
12. Europe Euro Stoxx 50 (STOXX50E)

Source (publique) : Yahoo ! Finance. Collecte des données avec le package R quantmod.

1.5.2.2.3 Qualité de la donnée

Pour la période 1990-1993, trois indices boursiers présentaient une quantité importante de valeurs manquantes. L’équipe a décidé de supprimer toutes les « lignes » présentant des valeurs manquantes, par conséquent les valeurs des indices possédant des valeurs à ces dates ont été également supprimées afin de garder des données sans valeurs manquantes. Par conséquent les dates des valeurs de référence des 12 indices boursiers commencent à partir du mois de mars 1993 (au lieu de janvier 1990).

Préparation des données

Les packages R quantmod et timeSeries ont été utilisés afin d’obtenir les huit 8 datasets suivants (voir chapitre 1.3 pour rappel des objectifs des datasets) composés des valeurs hebdomadaires ajustées des 12 indices boursiers :

In-samples (échantillons d’entrée) : périodes de 10 comprenant plusieurs tendances :

1. In-sample 1990-1999
2. In-sample 1992-2001
3. In-sample 1994-2003
4. In-sample 1996-2005

Out-samples (échantillons de sortie) : période de 2 ans comprenant une seule tendance, ces données permettent de valider les portefeuilles (solutions) trouvées avec les In-samples :

1. Out-sample 2000-2001
2. Out-sample 2002-2003
3. Out-sample 2004-2005
4. Out-sample 2006-2007

1.5.2.2.4 Modélisation et optimisation

Le code écrit en langage R de l’algorithme MOPSO est une adaptation souhaitée et innovante de plusieurs spécifications PSO et MOPSO :

• La référence [CLE] apporte un paramétrage en termes des valeurs conseillées de la taille de l’essaim, de la confiance en soi, de la confiance en les autres et du confinement de l’espace de recherche.

Paramètre MOPSO Valeurs conseillées Confiance en soi (ω) 0.689343 Confiance en les autres (Cmax) 1.42694 Taille de l’essaim (N) 300 Nombre de générations (EXEC) 100

• La référence [MOS] apporte le pseudo-code général de la MOPSO, du calcul de la sigma-distance et le nombre de générations conseillé (ou nombre d’exécutions). Ci-dessous le pseudo-code, général de la MOPSO.

Par conséquent, nous avons influencé le comportement standard de l’algorithme, par rapport à celui disponible dans les packages les plus connus, tels que DEAP (Python), en effectuant un développement qui intègre ce que nous considérons comme les meilleurs atouts du PSO mono-critère et multi-critère. A notre connaissance, cette approche n’a jamais été tentée.

Fonctions à optimiser

On cherche à maximiser la rentabilité et à minimiser la VaR du portfolio. On utilise des fonctions existantes dans le package fPortfolio. En effet, ce dernier sera utilisé pour l’optimisation des portfolios Sigma-effcient utilisant la méthode classique (programmation quadratique), ainsi le comparatif des résultats sera fiable.

• Le calcul de la rentabilité du portfolio est effectué en prenant la moyenne du résultat de la fonction fPortfolio::pfolioReturn(timeSeries, weights).

• Le calcul de la VaR du portfolio est effectué avec la fonction fPortfolio::pfolioVaR(timeSeries, weights, alpha).

Avec

• *timeSeries *: les valeurs hebdomadaires des indices (soit in-sample ou out-sample) sous format de series temporelles.

• *weights *: c’est le portfolio (ou possible solution en question ou position d’une particule).

• *alpha *: c’est la confiance correspondante à la VaR, fixée à 95%

1.5.3. Données In-samples : Efficacité des portefeuilles VaR-efficient

Les résultats expliqués dans ce chapitre permettent de montrer le bien fondé de notre démarche scientifique. En effet, avant d’appliquer nos solutions (portefeuilles trouvés par MOPSO) sur des périodes à tendance unique, on chercher à effectuer le même type de comparatif « MOPSO vs Programmation Quadratique (QP) » que celui effectué par [ALF] dans le cas de NSGA-II.

1.5.4. Procédure

L’écart d’efficacité (ou erreur de substitution) définie au chapitre 1.3 a été calculé de la façon suivante :

A partir des portefeuilles trouvés par MOPSO, on calcule pour chaque valeur Return du couple (Return, VaR) correspondant, la VaR avec la fonction fPortfolio::efficientPortfolio(timeSeries, spec, constraints) où le paramètre spec inclut la définition de la valeur Return cible (avec setTargetReturn) égale à celle de MOPSO.

Ainsi on obtient pour la programmation quadratique (QP) le même nombre de portefeuilles que pour MOPSO et par conséquent, on peut effectuer une comparaison fiable des résultats.

1.5.5. Les graphes des résultats

La légende suivante s’applique aux quatre figures ci-dessous :

A gauche : portefeuilles VaR-efficient trouvés par l’équipe [ALF] avec NSGA II vs. portefeuilles Sigma-efficient

• Graphe noire continue = VaR-efficient

• Graphe noire en tiret = Sigma-efficient

A droite : portefeuilles VaR-efficient trouvés avec MOPSO vs. portefeuilles Sigma-efficient

• Graphe noire = VaR-efficient

• Graphe rouge = Sigma-efficient

1.5.6. Données In-samples 1990 – 1999

MOPSO a généré 12 solutions ou portefeuilles VaR-efficient.

La figure ci-dessous montre que l’efficacité des portefeuilles VaR-efficient trouvés par MOPSO est supérieure à celle de NSGA II, vis-a-vis des portefeuilles Sigma-efficient respectifs.

La proportion des portefeuilles VaR-efficient de MOPSO est de 100% pour tous les niveaux d’écart d’efficacité (ou erreur de substitution) définis dans le chapitre 1.3.

Les erreurs MSE, MAE et de substitution restent assez importantes : à 0.2%, 0.4% et 0.3% respectivement.

Figure 4 Résultats in-sample 1990-1999

1.5.7. Données In-samples 1992 – 2001

MOPSO a généré 20 solutions ou portefeuilles VaR-efficient. La figure ci-dessous montre que l’efficacité des portefeuilles VaR-efficient trouvés par MOPSO est supérieure à celle de NSGA II, vis-à-vis des portefeuilles Sigma-efficient respectifs.

La proportion des portefeuilles VaR-efficient de MOPSO est de 100% pour les 3 premiers niveaux d’écart d’efficacité (ou erreur de substitution) définis dans le chapitre 1.3 et de 45% et 20% pour les écarts supérieurs à 0.5% et à 1% respectivement.

Les erreurs MAE et de substitution sont assez importantes : 0.3% et 0.7% respectivement. Le MSE est à 0.096%.

Figure 5 Résultats in-sample 1992-2001

1.5.8. Données In-samples 1994 – 2003

MOPSO a généré 23 solutions ou portefeuilles VaR-efficient. La figure ci-dessous montre que l’efficacité des portefeuilles VaR-efficient trouvés par MOPSO est inférieure à celle de NSGA II, vis-à-vis des portefeuilles Sigma-efficient respectifs. C’est le seul scénario montrant ce cas. Une analyse est toujours en cours afin d’expliquer ce phénomène.

La proportion des portefeuilles VaR-efficient de MOPSO est de 100% pour les 2 premiers niveaux d’écart d’efficacité (ou erreur de substitution) définis dans le chapitre 1.3 et de 9%, 0% et 0% pour les écarts supérieurs à 0%, à 0.5% et à 1% respectivement. Le résultat est en effet très décevant.

Les erreurs MAE, MSE et de substitution sont malgré tout proches de 0% : 0.004%, 0.058% et -0.092%% respectivement

Figure 6 Résultats in-sample 1994-2003

1.5.9. Données In-samples 1996 – 2005

MOPSO a généré 16 solutions ou portefeuilles VaR-efficient. La figure ci-dessous montre que l’efficacité des portefeuilles VaR-efficient trouvés par MOPSO est supérieure à celle de NSGA II, vis-à-vis des portefeuilles Sigma-efficient respectifs.

La proportion des portefeuilles VaR-efficient de MOPSO est de 100% pour les 2 premiers niveaux d’écart d’efficacité (ou erreur de substitution) définis dans le chapitre 1.3 et de 69%, 13%, 6% pour les écarts supérieurs à 0%, à 0.5% et à 1% respectivement.

Les erreurs MAE, MSE et de substitution sont correctes : 0.06%, 0.17% et 0.23% %% respectivement.

Figure 7 Résultats in-sample 1996-2005

1.5.10. Résumé des résultats

Ci-dessous le résumé des résultats obtenus pour les portefeuilles VaR-efficient trouvés avec MOPSO vis-à-vis des portefeuilles Sigma-efficient obtenus avec la programmation quadratique.

Tableau 3 Résultats in-sample "MOPSO vs QP"

On peut constater que la proportion des portefeuilles VaR-efficient dont l’écart est supérieur à 0% par rapport aux portefeuilles Sigma-efficient et de 100%, 100%, 9% et 69% pour chaque ensemble de données in-sample respectivement.

Seule l’application des portefeuilles VaR-efficient sur les données in-sample 1994-2003 ont montré des résultats décevants avec seulement 9% des solutions à > 0%, ce qui est très loin d’une majorité de portefeuilles MOPSO.

1.5.11. Données Out-samples : Validation des portefeuilles VaR-efficient

Ci-dessous le résumé des résultats obtenus en appliquant les portefeuilles VaR-efficient de MOPSO (solutions in-samples) aux données out-samples ou périodes à tendance unique.

Tableau 4 Résultats out-sample "MOPSO vs QP

1.5.12. Fonctionnalités

L’outil, développé avec RStudio Shiny, permet aux asset managers de

• Collecter et stocker avec une fréquence journalière le cours des indices boursiers à partir des sources publiques (actuellement Yahoo ! Finance). Calculer les rendements journaliers, hebdomadaires et annuels

• Obtenir les portefeuilles optimisés avec des algorithmes « classiques » et ceux issus de la Swarm Intelligence (actuellement MOPSO).

• Appliquer les portefeuilles sur des périodes à tendance unique et effectuer un comparatif « Swarm Intelligence (actuellement MOPSO) vs QP » avec des indicateurs d’efficacité VaR-efficiency.

• Sélectionner la meilleure solution, en calculant les VaR et la perte inattendue (UL) selon le rendement désiré et comparer les résultats des différents algorithmes.

Figure 8 Fonctionnalités de l'outil destiné aux asset managers

Figure 9 Prises d'écran correspondantes à chaque fonctionnalité de l’outil

1.6. Réussites techniques, indicateurs de R&D

1.6.1. Acquisition de connaissances

Au moment de l’écriture de ce rapport, nous n’avons aucune connaissance d’outils ou de logiciels sur le marché permettant d’automatiser les tâches (1) calcul des portefeuilles avec différents algorithmes, (2) applications des solutions sur des périodes à une tendance, (3) comparatif des portefeuilles et (4) calcul de la VaR minimale et la perte inattendue (unexpected loss, UL).

1.6.2. Démarche réussie

Nous avons réussi à appliquer le même niveau de rigueur de la démarche décrite dans la référence [ALF]. Notre innovation se situe dans l’adaptation ou customisation d’un algorithme différent de celui utilisé dans [ALF], l’algorithme MOPSO (Multi-objective Particle Swarm Intelligence). En effet, nous avons influencé le comportement standard de l’algorithme, par rapport à celui disponible dans les packages les plus connus (tels que la librairie DEAP écrite en Python). Notre adaptation se situe dans le choix des valeurs des coefficients de confiance, dans le confinement de l’espace de recherche et dans la méthode pour la détermination des solutions « non dominées ».

Par ailleurs, nous souhaitons aller plus loin dans cette dernière avec une customisation de la méthode Є-Dominance.

1.7. Références bibliographiques

1.1.1. Livres blancs (white papers)

• [ALF] Alfaro Cid E. et al., « Minimizing value-at-risk in a portfolio optimization problem using a multiobjective genetic algorithm », International Journal of Risk Assessment and Management, 2011

• [YOU] Yourdkhani S., « Portfolio Management by using Value-at-Risk (VaR) - A Comparison between Particle Swarm Optimization and Genetic Algorithms », Life Science Journal, 2014

• [HAO] Hao J. et al., « Multi-objective Particle Swarm Optimization Algorithm based on Enhanced Є-Dominance », IEEE, 2006

• [MOS] Mostaghim S., Teich J., « Strategies for Finding Local Guides in Multi-objective Particle Swarm Optimization (MOPSO) »

• [MOS2] Mostaghim S., Teich J., « The rôle of Є-Dominance in Multi-objective Particle Swarm Optimization Methods »

1.1.2. Livres

• [CLE] Clerc M., L’optimisation par essaims particulaires, Hermès-Sciences, 2005

• [LAR] Larose D., « Exploration de données », Editions Vuibert, 2006

1.1.3. Sites web

• [EPI] Epiquant, Optimisation de portefeuille : Modèle Mean – Variance de Markowitz (avec R)

• [CAP] Captain Econimics, La théorie moderne du portefeuille : une introduction

1.8. Annexes

1.1.4. Notions de solutions non dominées

Ci-dessous une explication et une illustration de solutions non dominées (carrés noirs).

1.1.5. Théorie de rationalité avancée par Markowitz

Le problème posé par Markowitz est la recherche d’un portefeuille qui minimise la variance du rendement du portefeuille pour un niveau d’espérance de rentabilité donné.

Ce portefeuille est dit efficace, il a l’espérance de rentabilité la plus forte parmi les portefeuilles qui ont la même variance de rentabilité que lui.

Ainsi, le problème de l’investisseur face à plusieurs titre serait de déterminer la proportion de ses fonds à investir dans chaque titre pour former le portefeuille efficient qui correspond au mieux à ses goûts vis-à-vis du risque.

L’ensemble de tous les portefeuilles efficaces constitue la frontière efficace, encore appelée frontière efficiente de Markowitz (Prix Nobel d’économie en 1990), qui la dériva en 1952 et la généralisa en 1959.

Markowitz est classé comme le premier modélisateur de la relation « Risque / Rentabilité ».

Le modèle de Markowitz devient l’outil le plus préconisé par les opérateurs et ce grâce à son opérationnalité et sa technicité.

1.1.6. Les différents types de portefeuille

Portefeuille efficient (efficient portfolio)

Pour chaque rendement, il existe un portefeuille qui minimise le risque. À l'inverse, pour chaque niveau de risque, on peut trouver un portefeuille maximisant le rendement attendu. L'ensemble de ces portefeuilles est appelé frontière efficiente ou frontière de Markowitz.

Portefeuille à variance minimale (Global minimum risk or Minimum Variance Portfolio) C’est le portefeuille efficient avec le risque minimal.

Portefeuille à rentabilité maximale (Maximum Return Portfolio)

C’est le portefeuille qui pour un risqué donné (cible), possède la rentabilité maximale.

Portefeuille tangent ou de risque minimal (Minumum Risk or Tangency Portfolio)

Dans un univers comprenant des actifs risqués et un actif sans risque, le portefeuille tangent est le seul portefeuille risqué efficient puisqu'il est celui dont le ratio de Sharpe est le plus élevé. C’est le portefeuille efficient avec le ratio rendement/risque (ou ratio de Sharpe) le plus élevé.

Autres définitions

L'actif sans risque est un actif théorique qui rapporte le taux d'intérêt sans risque. Il est en général associé aux emprunts d'État à court terme. Cet actif possède une variance nulle, son rendement est donc connu à l'avance. Il n'est pas corrélé avec les autres actifs. Par conséquent, associé à un autre actif, il modifie linéairement l'espérance de rendement et la variance.

Le portefeuille devient donc:

En conséquence, l'espérance de rentabilité est constituée de l'actif sans risque augmenté d'une prime de risque.

Droite de marché des capitaux (Capital Market Line)

Elle représente la rentabilité attendue en ordonné et le risque en abscisse de l'ensemble des titres présents sur le marché. Si un titre se situe au-dessus de cette droite, il est sous-évalué. En effet, cela signifie qu'il rapporte plus que ce qui est attendu à un risque donné, donc investir !

L'intersection avec la droite des ordonnées représente le taux de rentabilité attendu sur les marchés pour un risque nul.

Go to R-bloggers for R news and tutorials contributed by hundreds of R bloggers.

Introduction

This is the sixth of a series of 6 articles about time series forecasting with panel data and ensemble stacking with R.

Through these articles I will be putting into practice what I have learned from the Business Science University training course 1 DS4B 203-R: High-Performance Time Series Forecasting", delivered by Matt Dancho. If you are looking to gain a high level of expertise in time series with R I strongly recommend this course.

The objective of this article is to learn how to build multi-level stacking ensembles with modeltime. In the figure below we start from the bottom by reminding us of each individual model or submodel performance from Part 4 (non-tuned models) and Part 5 (tuned models). Then we will define meta learners which learn from k-fold cross-validation predictions from all submodels. We can compare meta-learners' performance and select best meta-learners to be used for defining a weighted average ensemble to produce a final multi-level stacking model.

Prerequisites

I assume you are already familiar with the following topics, packages and terms:

• dplyr or tidyverse R packages

• k-fold cross-validation

• hyperparameter tuning from Part 4

• average and weighted ensembles from Part 5

Packages

The following packages must be loaded:

# 01 FEATURE ENGINEERING
library(tidyverse)  # loading dplyr, tibble, ggplot2, .. dependencies
library(timetk)  # using timetk plotting, diagnostics and augment operations
library(tsibble)  # for month to Date conversion
library(tsibbledata)  # for aus_retail dataset
library(fastDummies)  # for dummyfying categorical variables
library(skimr) # for quick statistics

# 02 FEATURE ENGINEERING WITH RECIPES
library(tidymodels) # with workflow dependency

# 03 MACHINE LEARNING
library(modeltime) # ML models specifications and engines
library(tictoc) # measure training elapsed time

# 04 HYPERPARAMETER TUNING
library(future)
library(doFuture)
library(plotly)

# 05 ENSEMBLES
library(modeltime.ensemble)

Reminder of individual models

Leu us remind us of the performance of each individual model or submodel. We do not consider the ensemble models from Part 5.

# Load all calibration tables (tuned & non-tuned models)
> calibration_tbl <- read_rds("workflows_NonandTuned_artifacts_list.rds")
> calibration_tbl <- calibration_tbl$calibration
> calibration_tbl %>% 
   modeltime_accuracy() %>%
   arrange(rmse)

# A tibble: 8 x 9
  .model_id .model_desc                       .type   mae  mape  mase smape  rmse   rsq
      <int> <chr>                             <chr> <dbl> <dbl> <dbl> <dbl> <dbl> <dbl>
1         7 PROPHET W/ REGRESSORS             Test  0.189  21.6 0.417  21.5 0.240 0.856
2         3 PROPHET W/ REGRESSORS - Tuned     Test  0.189  21.6 0.418  21.5 0.241 0.857
3         4 PROPHET W/ XGBOOST ERRORS - Tuned Test  0.191  25.7 0.421  19.9 0.253 0.780
4         8 PROPHET W/ XGBOOST ERRORS         Test  0.204  24.8 0.451  20.8 0.287 0.753
5         2 XGBOOST - Tuned                   Test  0.219  23.6 0.482  22.9 0.296 0.762
6         6 XGBOOST                           Test  0.216  25.0 0.476  22.4 0.299 0.747
7         1 RANGER - Tuned                    Test  0.231  26.1 0.509  24.6 0.303 0.766
8         5 RANGER                            Test  0.235  25.4 0.519  25.0 0.312 0.765

Stacking Algorithms

A stacking algorithm or meta-learner learns from predictions. The predictions come from k-fold cross-validations applied to each submodel. Once fed into the meta-learner tunable specification a hyperpameter tuning will be peformed for the meta-learner.

Generate predictions for meta-learners

Remember, for non-sequential models you must perform a k-fold cross-validation and not a time series cross-validation. Let us get resampeld predictions with modeltime_fit_resamples(). Here, k=10 folds.

set.seed(123)
resamples_kfold <- training(splits) %>%
  drop_na() %>%
  vfold_cv(v = 10)

tic()
submodels_resamples_kfold_tbl <- calibration_tbl %>%
  modeltime_fit_resamples(
    resamples = resamples_kfold,
    control   = control_resamples(
      verbose    = TRUE, 
      allow_par  = TRUE,
    )
  )
toc()

Setup parallel processing

Parallel processing is set and toggled on by running the following commands:

# Parallel Processing ----
registerDoFuture()
n_cores <- parallel::detectCores()

plan(
  strategy = cluster,
  workers  = parallel::makeCluster(n_cores)
)

Meta-learners specification

In this article we will use 3 meta-learners: Random Forest, XGBoost, and SVM.

Create a stacking algorithm specification with ensemble_model_spec(). Within the meta-learner specification we must provide the tunable parameters, the number of folds, and the size of the grid. We will also set grid search control parameters by activating verbose and allowing parallel processing.

For all meta-learners specifications we will define a k=10 folds and a grid size of 20.

Random Forest stacking algorithm

We perform tuning on 2 parameters: mtry and min_n.

We notice that the in-sample RMSE for the meta-learner is 0.125. Its performance on test data has RMSE = 0.230 and RSQ = 0.817.

tic()
set.seed(123)
ensemble_fit_ranger_kfold <- submodels_resamples_kfold_tbl %>%
  ensemble_model_spec(
    model_spec = rand_forest(
      trees = tune(),
      min_n = tune()
    ) %>%
      set_engine("ranger"),
    kfolds  = 10, 
    grid    = 20,
    control = control_grid(verbose = TRUE, 
                           allow_par = TRUE)
  )
toc()

i Model Parameters:
# A tibble: 1 x 8
  trees min_n .metric .estimator  mean     n std_err .config              
  <int> <int> <chr>   <chr>      <dbl> <int>   <dbl> <chr>                
1  1906    32 rmse    standard   0.176    10 0.00225 Preprocessor1_Model02

i Prediction Error Comparison:
# A tibble: 9 x 3
  .model_id  rmse .model_desc                      
  <chr>     <dbl> <chr>                            
1 1         0.196 RANGER - Tuned                   
2 2         0.183 XGBOOST - Tuned                  
3 3         0.207 PROPHET W/ REGRESSORS - Tuned    
4 4         0.179 PROPHET W/ XGBOOST ERRORS - Tuned
5 5         0.203 RANGER                           
6 6         0.203 XGBOOST                          
7 7         0.208 PROPHET W/ REGRESSORS            
8 8         0.207 PROPHET W/ XGBOOST ERRORS        
9 ensemble  0.125 ENSEMBLE (MODEL SPEC)           

modeltime_table(
  ensemble_fit_xgboost_kfold
) %>%
  modeltime_accuracy(testing(splits))

# A tibble: 1 x 9
  .model_id .model_desc                       .type   mae  mape  mase smape  rmse   rsq
      <int> <chr>                             <chr> <dbl> <dbl> <dbl> <dbl> <dbl> <dbl>
1         1 ENSEMBLE (RANGER STACK): 8 MODELS Test  0.166  21.8 0.367  18.2 0.230 0.817

XGBoost stacking algorithm

We perform tuning on 4 parameters: trees, tree_depth, learn_rate, loss_reduction.

We notice that the in-sample RMSE for the meta-learner is 0.0957. Its performance on test data RMSE = 0.251 and RSQ = 0.769.

tic()
set.seed(123)
ensemble_fit_xgboost_kfold <- submodels_resamples_kfold_tbl %>%
  ensemble_model_spec(
    model_spec = boost_tree(
      trees          = tune(),
      tree_depth     = tune(),
      learn_rate     = tune(),
      loss_reduction = tune()
    ) %>%
      set_engine("xgboost"),
    kfolds = 10, 
    grid   = 20, 
    control = control_grid(verbose = TRUE, 
                           allow_par = TRUE)
  )
toc()

# A tibble: 1 x 10
  trees tree_depth learn_rate loss_reduction .metric .estimator  mean     n std_err .config              
  <int>      <int>      <dbl>          <dbl> <chr>   <chr>      <dbl> <int>   <dbl> <chr>                
1  1717          8     0.0330        0.00876 rmse    standard   0.180    10 0.00175 Preprocessor1_Model10

i Prediction Error Comparison:
# A tibble: 9 x 3
  .model_id   rmse .model_desc                      
  <chr>      <dbl> <chr>                            
1 1         0.196  RANGER - Tuned                   
2 2         0.183  XGBOOST - Tuned                  
3 3         0.207  PROPHET W/ REGRESSORS - Tuned    
4 4         0.179  PROPHET W/ XGBOOST ERRORS - Tuned
5 5         0.203  RANGER                           
6 6         0.203  XGBOOST                          
7 7         0.208  PROPHET W/ REGRESSORS            
8 8         0.207  PROPHET W/ XGBOOST ERRORS        
9 ensemble  0.0957 ENSEMBLE (MODEL SPEC)  

> modeltime_table(
   ensemble_fit_xgboost_kfold
 ) %>%
   modeltime_accuracy(testing(splits))

# A tibble: 1 x 9
  .model_id .model_desc                        .type   mae  mape  mase smape  rmse   rsq
      <int> <chr>                              <chr> <dbl> <dbl> <dbl> <dbl> <dbl> <dbl>
1         1 ENSEMBLE (XGBOOST STACK): 8 MODELS Test  0.182  23.9 0.401  19.7 0.251 0.769

SVM stacking algorithm

We perform tuning on 3 parameters: cost, rbf_sigma, margin. Run ?svm_rbf for explanations.

We notice that the in-sample RMSE for the meta-learner is 0.172. Its performance on test data RMSE = 0.219 and RSQ = 0.823.

tic()
set.seed(123)
ensemble_fit_svm_kfold <- submodels_resamples_kfold_tbl %>%
  ensemble_model_spec(
    model_spec = svm_rbf(
      mode      = "regression",
      cost      = tune(),
      rbf_sigma = tune(),  
      margin    = tune()
    ) %>%
      set_engine("kernlab"),
    kfold = 10, 
    grid  = 20, 
    control = control_grid(verbose = TRUE, 
                           allow_par = TRUE)
  )
toc()

# A tibble: 1 x 9
   cost rbf_sigma margin .metric .estimator  mean     n std_err .config              
  <dbl>     <dbl>  <dbl> <chr>   <chr>      <dbl> <int>   <dbl> <chr>                
1  4.60    0.0110 0.0595 rmse    standard   0.172    10 0.00222 Preprocessor1_Model07

i Prediction Error Comparison:
# A tibble: 9 x 3
  .model_id  rmse .model_desc                      
  <chr>     <dbl> <chr>                            
1 1         0.196 RANGER - Tuned                   
2 2         0.183 XGBOOST - Tuned                  
3 3         0.207 PROPHET W/ REGRESSORS - Tuned    
4 4         0.179 PROPHET W/ XGBOOST ERRORS - Tuned
5 5         0.203 RANGER                           
6 6         0.203 XGBOOST                          
7 7         0.208 PROPHET W/ REGRESSORS            
8 8         0.207 PROPHET W/ XGBOOST ERRORS        
9 ensemble  0.172 ENSEMBLE (MODEL SPEC)  

> modeltime_table(
   ensemble_fit_svm_kfold
 ) %>%
   modeltime_accuracy(testing(splits))

# A tibble: 1 x 9
  .model_id .model_desc                        .type   mae  mape  mase smape  rmse   rsq
      <int> <chr>                              <chr> <dbl> <dbl> <dbl> <dbl> <dbl> <dbl>
1         1 ENSEMBLE (KERNLAB STACK): 8 MODELS Test  0.160  21.8 0.352  18.0 0.219 0.823

Multi-Level Stacks

The previous stacking approaches can be mutualized in a multi-level stack. We can combine meta-learners into a higher level of the stack which will be a normal (weighted) average ensemble as introduced in Part 5.

Below is a reminder of the previous stacking algorithms' performance:

modeltime_table(
  ensemble_fit_ranger_kfold, 
  ensemble_fit_xgboost_kfold,
  ensemble_fit_svm_kfold
) %>%
  modeltime_accuracy(testing(splits)) %>% 
  arrange(rmse)

# A tibble: 3 x 9
  .model_id .model_desc                        .type   mae  mape  mase smape  rmse   rsq
      <int> <chr>                              <chr> <dbl> <dbl> <dbl> <dbl> <dbl> <dbl>
1         3 ENSEMBLE (KERNLAB STACK): 8 MODELS Test  0.160  21.8 0.352  18.0 0.219 0.823
2         1 ENSEMBLE (RANGER STACK): 8 MODELS  Test  0.166  21.8 0.367  18.2 0.230 0.817
3         2 ENSEMBLE (XGBOOST STACK): 8 MODELS Test  0.182  23.9 0.401  19.7 0.251 0.769

Let us now define a weighted average ensemble model from the stacking algorithms as we did in Part 5. We will apply the ranking technique to calculate the weights.

First we create the accuracy results table on which we apply the ranking technique for weigths calculation, then we create the weighted average ensemble model with ensemble_weighted() by applying the weights, and finally, we evaluate the model.

loadings_tbl <- modeltime_table(
  ensemble_fit_ranger_kfold, 
  ensemble_fit_xgboost_kfold,
  ensemble_fit_svm_kfold
) %>% 
  modeltime_calibrate(testing(splits)) %>%
  modeltime_accuracy() %>%
  mutate(rank = min_rank(-rmse)) %>%
  select(.model_id, rank)

stacking_fit_wt <- modeltime_table(
  ensemble_fit_ranger_kfold, 
  ensemble_fit_xgboost_kfold,
  ensemble_fit_svm_kfold
) %>%
  ensemble_weighted(loadings = loadings_tbl$rank)

> stacking_fit_wt  %>% 
   modeltime_calibrate(testing(splits)) %>%
   modeltime_accuracy() %>%
   arrange(rmse)
# A tibble: 1 x 9
  .model_id .model_desc                   .type   mae  mape  mase smape  rmse   rsq
      <int> <chr>                         <chr> <dbl> <dbl> <dbl> <dbl> <dbl> <dbl>
1         1 ENSEMBLE (WEIGHTED): 3 MODELS Test  0.161  21.8 0.354  18.1 0.223 0.817

With RMSE = 0.223, the stacked ensemble algorithm outperformed all algorithms!

Forescast plot

Below the stacked ensemble algorithm's forecast plot on the test dataset for all industries, it looks good ! except for one industry the model seems to follow pretty well the trend and spikes of the actual data.

calibration_stacking <- stacking_fit_wt %>% 
  modeltime_table() %>%
  modeltime_calibrate(testing(splits))

calibration_stacking %>%
  modeltime_forecast(
    new_data    = testing(splits),
    actual_data = artifacts$data$data_prepared_tbl,
    keep_data   = TRUE 
  ) %>%
  group_by(Industry) %>%
  plot_modeltime_forecast(
    .facet_ncol         = 4, 
    .conf_interval_show = FALSE,
    .interactive        = TRUE,
    .title = "Forecast stacking level model (test data)"
  )

Next 12 months Turnover forecast

Let us now (finally!) perform the next 12 months Turnover forecast for all 20 industries as we promised in Part 1.

First, we must refit the stack-level weighted average model with the prepared dataset from Part 2. We do this with modeltime_refit().

Then we calculate the Turnover predictions over the next 12 months (values are still transformed). We do this with modeltime_forecast() and by setting new_data to the future dataset.

# Toggle ON parallel processing
plan(
  strategy = cluster,
  workers  = parallel::makeCluster(n_cores)
)

# Refit the model on prepared dataset
tic()
set.seed(123)
refit_stacking_tbl <- calibration_stacking %>% 
  modeltime_refit(
    data = artifacts$data$data_prepared_tbl,
    resamples = artifacts$data$data_prepared_tbl %>%
      drop_na() %>%
      vfold_cv(v = 10)
  )
toc()

# 12-month forecast calculations with future dataset

forecast_stacking_tbl <- refit_stacking_tbl %>%
  modeltime_forecast(
    new_data    = artifacts$data$future_tbl,
    actual_data = artifacts$data$data_prepared_tbl %>%
      drop_na(), 
    keep_data = TRUE
  )

# Toggle OFF parallel processing
plan(sequential)

We invert the Turnover values back to their original values with standardize_inv_vec() and expm1().

Finally, we plot the forecast for the next 12 months within the original scale of the Turnover measure.

lforecasts <- lapply(X = 1:length(Industries), FUN = function(x){
  forecast_stacking_tbl %>%
    filter(Industry == Industries[x]) %>%
    #group_by(Industry) %>%
    mutate(across(.value:.conf_hi,
                  .fns = ~standardize_inv_vec(x = .,
                                              mean = artifacts$standardize$std_mean[x],
                                              sd = artifacts$standardize$std_sd[x]))) %>%
    mutate(across(.value:.conf_hi,
                  .fns = ~expm1(x = .)))
})

forecast_stacking_tbl <- bind_rows(lforecasts)

forecast_stacking_tbl %>%
  group_by(Industry) %>%
  plot_modeltime_forecast(.title = "Turnover 1-year forecast",     
                          .facet_ncol         = 4, 
                          .conf_interval_show = FALSE,
                          .interactive        = TRUE)

Below a zoomed view of the same plot

Conclusion

In this article you have learned how to implement stacked ensemble models. A stacking algorithm or meta-learner learns from predictions. The predictions come from k-fold cross-validations applied to each submodel. Once fed into the meta-learner tunable specification, a hyperpameter tuning will be peformed for the meta-learner.

We defined three meta-learners: SVM, Random Forest, and XGBoost from which we defined a weighted average ensemble model (stack-level) using the same method as explained Part 5.

The stacked ensemble algorithm outperformed all algorithms.

References

1 Dancho, Matt, "DS4B 203-R: High-Performance Time Series Forecasting", Business Science University

Go to R-bloggers for R news and tutorials contributed by hundreds of R bloggers.

Introduction

This is the fifth of a series of 6 articles about time series forecasting with panel data and ensemble stacking with R.

Through these articles I will be putting into practice what I have learned from the Business Science University training course 1 DS4B 203-R: High-Performance Time Series Forecasting", delivered by Matt Dancho. If you are looking to gain a high level of expertise in time series with R I strongly recommend this course.

The objective of this article is learn how to create average and weighted ensembles using all (both non-tuned and tuned) model from Part 3 and Part 4. We will also check if any of these ensemble models can outperform the tuned Prophet Boost model.

Prerequisites

I assume you are already familiar with the following topics, packages and terms:

• dplyr or tidyverse R packages

• calibration table from Part 3 and Part 4

• model evaluation metrics: RMSE, R-squared, ...

Packages

The following packages must be loaded:

# 01 FEATURE ENGINEERING
library(tidyverse)  # loading dplyr, tibble, ggplot2, .. dependencies
library(timetk)  # using timetk plotting, diagnostics and augment operations
library(tsibble)  # for month to Date conversion
library(tsibbledata)  # for aus_retail dataset
library(fastDummies)  # for dummyfying categorical variables
library(skimr) # for quick statistics

# 02 FEATURE ENGINEERING WITH RECIPES
library(tidymodels) # with workflow dependency

# 03 MACHINE LEARNING
library(modeltime) # ML models specifications and engines
library(tictoc) # measure training elapsed time

# 04 HYPERPARAMETER TUNING
library(future)
library(doFuture)
library(plotly)

# 05 ENSEMBLES
library(modeltime.ensemble)

Load calibration tables

Load all calibration tables for all tuned & non-tuned models we have trained so far, nad remind ourselves of the accuracy results so far:

> calibration_tbl <- read_rds("workflows_NonandTuned_artifacts_list.rds")
> calibration_tbl <- calibration_tbl$calibration
> calibration_tbl %>% 
   modeltime_accuracy() %>%
   arrange(rmse)
# A tibble: 8 x 9
  .model_id .model_desc                       .type   mae  mape  mase smape  rmse   rsq
      <int> <chr>                             <chr> <dbl> <dbl> <dbl> <dbl> <dbl> <dbl>
1         7 PROPHET W/ REGRESSORS             Test  0.189  21.6 0.417  21.5 0.240 0.856
2         3 PROPHET W/ REGRESSORS - Tuned     Test  0.189  21.6 0.418  21.5 0.241 0.857
3         4 PROPHET W/ XGBOOST ERRORS - Tuned Test  0.191  25.7 0.421  19.9 0.253 0.780
4         8 PROPHET W/ XGBOOST ERRORS         Test  0.204  24.8 0.451  20.8 0.287 0.753
5         2 XGBOOST - Tuned                   Test  0.219  23.6 0.482  22.9 0.296 0.762
6         6 XGBOOST                           Test  0.216  25.0 0.476  22.4 0.299 0.747
7         1 RANGER - Tuned                    Test  0.231  26.1 0.509  24.6 0.303 0.766
8         5 RANGER                            Test  0.235  25.4 0.519  25.0 0.312 0.765

Average ensembles

Average ensembles is a fairly simple concept, its main advantage is that it does not require retraining. If you use the mean be aware of the individual performance of each model since the "average model" performance will be sensitive to "bad models" and outliers. To cope with this situation you can use the median (more robust than the mean). Do not use the median when all models are doing pretty well.

To create these two ensembles is pretty simple, all you have to do is to pipe the modeltime table with all workflows into the ensemble_average() and specify the type, either mean or median.

> ensemble_fit_mean <- submodels_tbl %>%
  ensemble_average(type = "mean")

> ensemble_fit_mean
-- Modeltime Ensemble -------------------------------------------
Ensemble of 8 Models (MEAN)

# Modeltime Table
# A tibble: 8 x 5
  .model_id .model     .model_desc                       .type .calibration_data   
      <int> <list>     <chr>                             <chr> <list>              
1         1 <workflow> RANGER - Tuned                    Test  <tibble [1,000 x 4]>
2         2 <workflow> XGBOOST - Tuned                   Test  <tibble [1,000 x 4]>
3         3 <workflow> PROPHET W/ REGRESSORS - Tuned     Test  <tibble [1,000 x 4]>
4         4 <workflow> PROPHET W/ XGBOOST ERRORS - Tuned Test  <tibble [1,000 x 4]>
5         5 <workflow> RANGER                            Test  <tibble [1,000 x 4]>
6         6 <workflow> XGBOOST                           Test  <tibble [1,000 x 4]>
7         7 <workflow> PROPHET W/ REGRESSORS             Test  <tibble [1,000 x 4]>
8         8 <workflow> PROPHET W/ XGBOOST ERRORS         Test  <tibble [1,000 x 4]>

> ensemble_fit_mean <- submodels_tbl %>%
  ensemble_average(type = "median")

-- Modeltime Ensemble -------------------------------------------
Ensemble of 8 Models (MEDIAN)

# Modeltime Table
# A tibble: 8 x 5
  .model_id .model     .model_desc                       .type .calibration_data   
      <int> <list>     <chr>                             <chr> <list>              
1         1 <workflow> RANGER - Tuned                    Test  <tibble [1,000 x 4]>
2         2 <workflow> XGBOOST - Tuned                   Test  <tibble [1,000 x 4]>
3         3 <workflow> PROPHET W/ REGRESSORS - Tuned     Test  <tibble [1,000 x 4]>
4         4 <workflow> PROPHET W/ XGBOOST ERRORS - Tuned Test  <tibble [1,000 x 4]>
5         5 <workflow> RANGER                            Test  <tibble [1,000 x 4]>
6         6 <workflow> XGBOOST                           Test  <tibble [1,000 x 4]>
7         7 <workflow> PROPHET W/ REGRESSORS             Test  <tibble [1,000 x 4]>
8         8 <workflow> PROPHET W/ XGBOOST ERRORS         Test  <tibble [1,000 x 4]>

Weigthed ensembles

Weighted ensembles can improve performance compared to average ensembles but we must decide of the weight values. One solution is to use a simple rank technique: create a rank column for which highest value is for the best model (lowest RMSE).

In the code snippet below we add the rank column and then we select .model_id and rank columns to define a loadings tibble which will be used for defining the weighted ensemble.

> calibration_tbl %>%
   modeltime_accuracy() %>%
   mutate(rank = min_rank(-rmse)) 
# A tibble: 8 x 10
  .model_id .model_desc                       .type   mae  mape  mase smape  rmse   rsq  rank
      <int> <chr>                             <chr> <dbl> <dbl> <dbl> <dbl> <dbl> <dbl> <int>
1         1 RANGER - Tuned                    Test  0.231  26.1 0.509  24.6 0.303 0.766     2
2         2 XGBOOST - Tuned                   Test  0.219  23.6 0.482  22.9 0.296 0.762     4
3         3 PROPHET W/ REGRESSORS - Tuned     Test  0.189  21.6 0.418  21.5 0.241 0.857     7
4         4 PROPHET W/ XGBOOST ERRORS - Tuned Test  0.191  25.7 0.421  19.9 0.253 0.780     6
5         5 RANGER                            Test  0.235  25.4 0.519  25.0 0.312 0.765     1
6         6 XGBOOST                           Test  0.216  25.0 0.476  22.4 0.299 0.747     3
7         7 PROPHET W/ REGRESSORS             Test  0.189  21.6 0.417  21.5 0.240 0.856     8
8         8 PROPHET W/ XGBOOST ERRORS         Test  0.204  24.8 0.451  20.8 0.287 0.753     5

> loadings_tbl <- submodels_tbl %>%
  modeltime_accuracy() %>%
  mutate(rank = min_rank(-rmse)) %>%
  select(.model_id, rank)

Then the weigths are created by passing models' rank to the ensemble_weighted() function. The newly created ".loadings" column are the weights, the sum of all weigths is equal to 1.

> ensemble_fit_wt <- submodels_tbl %>%
  ensemble_weighted(loadings = loadings_tbl$rank)

> ensemble_fit_wt$fit$loadings_tbl
# Modeltime Table
# A tibble: 8 x 2
  .model_id .loadings
      <int>     <dbl>
1         1    0.0556
2         2    0.111 
3         3    0.194 
4         4    0.167 
5         5    0.0278
6         6    0.0833
7         7    0.222 
8         8    0.139

Models evaluation

Finally, let us display the accuracy results by adding previous ensemble models to a modeltime table, calibrating the latter and piping it into the modeltime_accuracy() function. We sort by ascending RMSE.

modeltime_table(
  ensemble_fit_mean,
  ensemble_fit_median,
  ensemble_fit_wt
) %>%
  modeltime_calibrate(testing(splits)) %>%
  modeltime_accuracy(testing(splits)) %>%
  arrange(rmse)

# A tibble: 3 x 9
  .model_id .model_desc                   .type   mae  mape  mase smape  rmse   rsq
      <int> <chr>                         <chr> <dbl> <dbl> <dbl> <dbl> <dbl> <dbl>
1         3 ENSEMBLE (WEIGHTED): 8 MODELS Test  0.176  20.7 0.388  19.5 0.237 0.840
2         1 ENSEMBLE (MEAN): 8 MODELS     Test  0.189  21.8 0.417  20.6 0.255 0.819
3         2 ENSEMBLE (MEDIAN): 8 MODELS   Test  0.204  23.0 0.450  21.8 0.275 0.797

As per the table below the weighted average ensemble performs better than other two average ensembles.

Let us now check if it performs better than the individual workflows from Part 4.

We add the ensembles' calibration table to the non-tuned and tuned models' calibration table (calibration_tbl).

> calibration_all_tbl <- modeltime_table(
  ensemble_fit_mean,
  ensemble_fit_median,
  ensemble_fit_wt
) %>% 
  modeltime_calibrate(testing(splits)) %>%
  combine_modeltime_tables(calibration_tbl)

> calibration_all_tbl %>%
  modeltime_accuracy() %>%
  arrange(rmse)

# A tibble: 11 x 9
   .model_id .model_desc                       .type   mae  mape  mase smape  rmse   rsq
       <int> <chr>                             <chr> <dbl> <dbl> <dbl> <dbl> <dbl> <dbl>
 1         3 ENSEMBLE (WEIGHTED): 8 MODELS     Test  0.176  20.7 0.388  19.5 0.237 0.840
 2        10 PROPHET W/ REGRESSORS             Test  0.189  21.6 0.417  21.5 0.240 0.856
 3         6 PROPHET W/ REGRESSORS - Tuned     Test  0.189  21.6 0.418  21.5 0.241 0.857
 4         7 PROPHET W/ XGBOOST ERRORS - Tuned Test  0.191  25.7 0.421  19.9 0.253 0.780
 5         1 ENSEMBLE (MEAN): 8 MODELS         Test  0.189  21.8 0.417  20.6 0.255 0.819
 6         2 ENSEMBLE (MEDIAN): 8 MODELS       Test  0.204  23.0 0.450  21.8 0.275 0.797
 7        11 PROPHET W/ XGBOOST ERRORS         Test  0.204  24.8 0.451  20.8 0.287 0.753
 8         5 XGBOOST - Tuned                   Test  0.219  23.6 0.482  22.9 0.296 0.762
 9         9 XGBOOST                           Test  0.216  25.0 0.476  22.4 0.299 0.747
10         4 RANGER - Tuned                    Test  0.231  26.1 0.509  24.6 0.303 0.766
11         8 RANGER                            Test  0.235  25.4 0.519  25.0 0.312 0.765

Forescast plot

We have already plotted all tuned and non-tuned models' forecast in Part 4, here we plot only the average ensembles' forecast.

Conclusion

In this article you've learned how to create average (mean or median) ensembles and weighted average ensembles. The latter was created using the rank technique.

Since one of the average ensemble was the best model, we did not bother with improving ensemble models' performance with model selection e.g., selecting the top 5 models and/or suppressing redundant models such as the tuned and non-tuned Prophet models which have the same performance.

In Part 5, we will try to outperform the weighted average ensemble .

References

1 Dancho, Matt, "DS4B 203-R: High-Performance Time Series Forecasting", Business Science University

Go to R-bloggers for R news and tutorials contributed by hundreds of R bloggers.

Introduction

This is the fourth of a series of 6 articles about time series forecasting with panel data and ensemble stacking with R.

Through these articles I will be putting into practice what I have learned from the Business Science University training course 1 "DS4B 203-R: High-Performance Time Series Forecasting", delivered by Matt Dancho. If you are looking to gain a high level of expertise in time series with R I strongly recommend this course.

The objective of this article is to explain the end-to-end process of time series hyperparamter tuning for non-sequential machine learning models like Random Forest, XGBoost, Prophet, and Prophet Boost. k-fold cross-validation can be applied to non-sequential algorithms.

You will understand how to tune parameters for Prophet Boost by performing several tuning rounds to adjust and stabilize the performance of the model. The hyperparameter tuning process is the same for the other algorithms.

The provided code is highly redundant for the sake of clarity. There is a lot of room for optimization with custom functions.

Prerequisites

I assume you are already familiar with the following topics, packages and terms:

• dplyr or tidyverse R packages

• preprocessing recipes from Part 2

• model specification and workflows from Part 3

• k-fold cross-validation

• parameters of Random Forest, XGBoost, Prophet, and Prophet Boost algorithms

• grid search

• model evaluation metrics: RMSE, R-squared, ...

Packages

The following packages must be loaded:

# 01 FEATURE ENGINEERING
library(tidyverse)  # loading dplyr, tibble, ggplot2, .. dependencies
library(timetk)  # using timetk plotting, diagnostics and augment operations
library(tsibble)  # for month to Date conversion
library(tsibbledata)  # for aus_retail dataset
library(fastDummies)  # for dummyfying categorical variables
library(skimr) # for quick statistics

# 02 FEATURE ENGINEERING WITH RECIPES
library(tidymodels) # with workflow dependency

# 03 MACHINE LEARNING
library(modeltime) # ML models specifications and engines
library(tictoc) # measure training elapsed time

# 04 HYPERPARAMETER TUNING
library(future)
library(doFuture)
library(plotly)

Hyperparameter Tuning end-to-end process

The end-to-end process is as follows:

1. Get the resamples. Here we will perform a k-fold cross-validation and obtain a cross-validation plan that we can plot to see "inside the folds".

2. Prepare for parallel process: register to future and get the number of vCores.

3. Define the tunable model specification: explicitly indicate the tunable parameters.

4. Define a tunable workflow into which we add the tunable model specification and the existing recipe; update the recipe if necessary.

5. Verify that the system has all tunable parameters' range, some parameter such as mtry do not have its values range correctly initialized.

6. Define the search grid specification: you must provide type of grid (random or latin hypercube sampling) and its size.

7. Toggle on the parallel processing

8. Run the hyperparameter tuning by provding the tunable workflow, the resamples, and the grid specification.

9. Run several tuning rounds if you can e.g., if you have the time and resources and/or you are able to fix some parameter ranges.

10. After several tuning rounds, select the best model: with the lowest RMSE or with the higest R-squared, it may be same model or they can be different models.

11. (Re)fit the best model(s) with the training data by providing the tuned workflow.

Reminder of Part 3 results

Let us recall the non-tuned model evaluation results for the 4 machine learning algorithms:

# Load saved work from Part 3
> wflw_artifacts <- read_rds("workflows_artifacts_list.rds")

> wflw_artifacts$calibration$calibration_tbl %>%
   modeltime_accuracy(testing(splits)) %>%
   arrange(rmse)

# A tibble: 4 x 9
  .model_id .model_desc               .type   mae  mape  mase smape  rmse   rsq
      <int> <chr>                     <chr> <dbl> <dbl> <dbl> <dbl> <dbl> <dbl>
1         3 PROPHET W/ REGRESSORS     Test  0.213  22.9 0.470  22.9 0.267 0.846
2         4 PROPHET W/ XGBOOST ERRORS Test  0.203  27.1 0.448  20.6 0.283 0.750
3         2 XGBOOST                   Test  0.228  26.9 0.503  22.7 0.306 0.761
4         1 RANGER                    Test  0.244  25.6 0.538  25.3 0.322 0.763

Note: "RANGER" is the default engine for Random Forest modeltime::rand_forest().

Cross-validation plan

A k-fold cross-validation will randomly split the training data into k groups of roughly equal size (called "folds"). A resample of the analysis data consisted of k-1 of the folds while the assessment set contains the final fold. In basic k-fold cross-validation (i.e. no repeats), the number of resamples is equal to k.

It is important to understand that you may perform a k-fold cross-validation for all four machine learning models since they are non-sequential models. This is not the case for other models such as ARIMA, ETS (exponential smoothing) and NNETAR for which you should perform a time_series_cv() cross-validation.

Perform the resample with function rsample::vfold_cv() as shown in the code snippet below. You may also display the cross validation plan and its plot (here, for one Industry) with tk_time_series_cv_plan() and plot_time_series_cv_plan(), respectively.

# k = 10 folds
> set.seed(123)
> resamples_kfold <- training(splits) %>% 
  vfold_cv(v = 10)

resamples_kfold %>%
  tk_time_series_cv_plan() %>%
  filter(Industry == Industries[1]) %>%
  plot_time_series_cv_plan(.date_var = Month, 
                             .value = Turnover, 
                             .facet_ncol = 2)

Setup parallel processing

As per 1, "the future library allows for evaluating R expressions asynchronously. The doFuture package is an adapter that provides for running loops in parallel. The tune package manages the adapter process internally, so all we need to do is to set up doFuture".

# Registers the doFuture parallel processing
registerDoFuture()

# My laptop i5-8350U CPU has 8 threads (or vCores)
n_cores <- parallel::detectCores()

Prophet Boost

Prophet Boost - Identify tuning parameters

I've decided to tune the following parameters, you can run ?prophet_boost for a full description:

• changepoint_num (prophet): Number of potential changepoints to include for modeling trend.

• mtry (xgboost): An integer for the number of predictors that will be randomly sampled at each split when creating the tree models.

• trees (xgboost): An integer for the number of trees contained in the ensemble

• min_n (xgboost): An integer for the minimum number of data points in a node that are required for the node to be split further. tree_depth: An integer for the maximum depth of the tree (i.e. number of splits) (specific engines only).

• learn_rate (xgboost): A number for the rate at which the boosting algorithm adapts from iteration-to-iteration.

• loss_reduction (xgboost): A number for the reduction in the loss function required to split further.

• tree_depth (xgboost): An integer for the maximum depth of the tree (i.e. number of splits).

Define the tunable parameters with tune() within the model specification of prophet_boost(). Then, define a new tunable workflow for Prophet Boost (wflw_spec_rf_tune) by adding the tunable specification and the same recipe as in Part 3. Display the summary of the workflow as shown in the code snippet below.

> model_spec_prophet_boost_tune <- prophet_boost(

  mode = "regression",
  # growth = NULL,
  changepoint_num = tune(),
  #changepoint_range = NULL,
  seasonality_yearly = FALSE,
  seasonality_weekly = FALSE,
  seasonality_daily = FALSE,
  # season = NULL,
  # prior_scale_changepoints = NULL,
  # prior_scale_seasonality = NULL,
  # prior_scale_holidays = NULL,
  # logistic_cap = NULL,
  # logistic_floor = NULL,
  mtry = tune(),
  trees = tune(),
  min_n = tune(),
  tree_depth = tune(),
  learn_rate = tune(),
  loss_reduction = tune(),
  # sample_size = NULL,
  # stop_iter = NULL

) %>%
  set_engine("prophet_xgboost")

> wflw_spec_prophet_boost_tune <- workflow() %>%
  add_model(model_spec_prophet_boost_tune) %>%
  add_recipe(artifacts$recipes$recipe_spec)

> wflw_spec_prophet_boost_tune
== Workflow ===================================================================================================================================
Preprocessor: Recipe
Model: prophet_boost()

-- Preprocessor -------------------------------------------------------------------------------------------------------------------------------
5 Recipe Steps

* step_other()
* step_timeseries_signature()
* step_rm()
* step_dummy()
* step_normalize()

-- Model --------------------------------------------------------------------------------------------------------------------------------------
PROPHET Regression Model Specification (regression)

Main Arguments:
  changepoint_num = tune()
  seasonality_yearly = FALSE
  seasonality_weekly = FALSE
  seasonality_daily = FALSE
  mtry = tune()
  trees = tune()
  min_n = tune()
  tree_depth = tune()
  learn_rate = tune()
  loss_reduction = tune()

Computational engine: prophet_xgboost

Prophet Boost - Grid spec

Check parameters' range

The first thing to do is to display the parameters of the model with extract_parameter_set_dials(): you must check if there is any parameter with missing information about its values range.

As shown below, nparam[?] means that values range is missing for mtry parameter.

> extract_parameter_set_dials(model_spec_prophet_boost_tune)
Collection of 3 parameters for tuning

 identifier  type    object
       mtry  mtry nparam[?]
      trees trees nparam[+]
      min_n min_n nparam[+]

Model parameters needing finalization:
   # Randomly Selected Predictors ('mtry')

See `?dials::finalize` or `?dials::update.parameters` for more information.

Check the number of predictors looking at the recipe's summary.

> artifacts$recipes$recipe_spec %>% 
   update_role(Month, new_role = "indicator") %>%
   prep() %>%
   summary() %>% 
   group_by(role) %>% 
   summarise(n=n())
# A tibble: 3 x 2
  role          n
  <chr>     <int>
1 indicator     1
2 outcome       1
3 predictor    50

The new range update will be applied within the grid specifications in the next code snippet.

Grid search specification

Thanks to the dials package it is possible to define specifications for either Random Grid or Latin Hypercube Sampling (LHS).

We define a grid of size 20 e.g. 20 random values combinations of the 7 tunable parameters. Remember to set the seed to fix the grid since it uses a random process, you may have different values.

Since we have defined a 10-fold cross-validation there will be 20 predictions per fold and the mean of the performance metric (RMSE, R-squared, ...) will be calculated.

set.seed(123)
grid_spec_1 <- grid_latin_hypercube(
  extract_parameter_set_dials(model_spec_prophet_boost_tune) %>% 
    update(mtry = mtry(range = c(1, 50))),
  size = 20
)

> grid_spec_1
# A tibble: 20 x 7
   changepoint_num  mtry trees min_n tree_depth learn_rate loss_reduction
             <int> <int> <int> <int>      <int>      <dbl>          <dbl>
 1               6     9   145    26          5   2.50e- 7       1.89e- 6
 2              33    33  1538    18         14   5.55e- 6       2.17e- 2
 3               8    42    42    21          3   2.22e- 6       1.63e- 1
 4               0    23  1183     4         12   2.44e- 3       1.91e-10
 5              30    30  1261    25         11   1.34e- 9       1.90e- 8
 6              22     5  1882     3          7   1.45e- 8       1.01e- 7
 7              45    48   971    30          6   2.94e-10       5.34e- 3
 8              20     7   798    27         15   1.18e- 4       4.65e- 9
 9              14    22  1993    12          3   6.54e- 7       1.42e- 4
10              27    37  1620    35          8   3.16e- 2       7.35e- 8
11              23    45  1450     8          4   6.11e- 4       7.60e- 2
12              31     1  1756    14         13   8.92e- 8       2.41e- 3
13              37    19   402    39          9   2.28e- 9       4.83e- 4
14              39    46   245    31         11   2.60e- 8       9.67e- 7
15              42    13   336    37          2   6.48e- 3       5.83e-10
16              17    28  1311    34          8   2.41e-10       2.92e- 5
17              49    31   870    11          2   2.32e- 5       1.70e+ 1
18               4    13   575     8         13   2.68e- 4       1.09e+ 0
19              44    18  1097    20         10   3.33e- 5       5.98e+ 0
20              11    40   613    16          6   5.62e- 2       7.32e- 6

Prophet Boost - Tune Grid

Let us perform 3 tuning rounds with 3 different grid specifications. I will explain at each round why do we perform the corresponding grid spec:

• Round 1 with grid_spec_1

• Round 2 with grid_spec_2

• Round 3 with grid_spec_3

To tune the workflow with a grid you need to provide the resamples, the grid specification and some controls on the grid search process.

tic()
tune_results_prophet_boost_1 <- wflw_spec_prophet_boost_tune %>%
  tune_grid(
    resamples  = resamples_kfold,
    grid = grid_spec_1,
    control = control_grid(verbose = TRUE, 
                           allow_par = TRUE)
  )
toc()

> plan(strategy = sequential)

> tune_results_prophet_boost_1 %>% 
+     show_best("rmse", n = Inf)
# A tibble: 20 x 13
   changepoint_num  mtry trees min_n tree_depth learn_rate loss_reduction .metric .estimator  mean     n std_err .config      
             <int> <int> <int> <int>      <int>      <dbl>          <dbl> <chr>   <chr>      <dbl> <int>   <dbl> <chr>        
 1              11    40   613    16          6   5.62e- 2       7.32e- 6 rmse    standard   0.185    10 0.00372 Preprocessor~
 2              27    37  1620    35          8   3.16e- 2       7.35e- 8 rmse    standard   0.187    10 0.00378 Preprocessor~
 3               0    23  1183     4         12   2.44e- 3       1.91e-10 rmse    standard   0.192    10 0.00422 Preprocessor~
 4              42    13   336    37          2   6.48e- 3       5.83e-10 rmse    standard   0.308    10 0.00407 Preprocessor~
 5              23    45  1450     8          4   6.11e- 4       7.60e- 2 rmse    standard   0.360    10 0.00406 Preprocessor~
 6               4    13   575     8         13   2.68e- 4       1.09e+ 0 rmse    standard   0.550    10 0.00560 Preprocessor~
 7              20     7   798    27         15   1.18e- 4       4.65e- 9 rmse    standard   0.579    10 0.00588 Preprocessor~
 8              44    18  1097    20         10   3.33e- 5       5.98e+ 0 rmse    standard   0.606    10 0.00605 Preprocessor~
 9              49    31   870    11          2   2.32e- 5       1.70e+ 1 rmse    standard   0.614    10 0.00619 Preprocessor~
10              33    33  1538    18         14   5.55e- 6       2.17e- 2 rmse    standard   0.619    10 0.00617 Preprocessor~
11              14    22  1993    12          3   6.54e- 7       1.42e- 4 rmse    standard   0.623    10 0.00619 Preprocessor~
12              17    28  1311    34          8   2.41e-10       2.92e- 5 rmse    standard   0.623    10 0.00620 Preprocessor~
13              39    46   245    31         11   2.60e- 8       9.67e- 7 rmse    standard   0.623    10 0.00620 Preprocessor~
14              31     1  1756    14         13   8.92e- 8       2.41e- 3 rmse    standard   0.623    10 0.00621 Preprocessor~
15              22     5  1882     3          7   1.45e- 8       1.01e- 7 rmse    standard   0.623    10 0.00621 Preprocessor~
16              37    19   402    39          9   2.28e- 9       4.83e- 4 rmse    standard   0.623    10 0.00620 Preprocessor~
17               8    42    42    21          3   2.22e- 6       1.63e- 1 rmse    standard   0.623    10 0.00617 Preprocessor~
18              45    48   971    30          6   2.94e-10       5.34e- 3 rmse    standard   0.623    10 0.00619 Preprocessor~
19              30    30  1261    25         11   1.34e- 9       1.90e- 8 rmse    standard   0.623    10 0.00619 Preprocessor~
20               6     9   145    26          5   2.50e- 7       1.89e- 6 rmse    standard   0.624    10 0.00616 Preprocessor~

> tune_results_prophet_boost_1 %>% 
+     show_best("rsq", n = Inf)
# A tibble: 20 x 13
   changepoint_num  mtry trees min_n tree_depth learn_rate loss_reduction .metric .estimator  mean     n std_err .config      
             <int> <int> <int> <int>      <int>      <dbl>          <dbl> <chr>   <chr>      <dbl> <int>   <dbl> <chr>        
 1              11    40   613    16          6   5.62e- 2       7.32e- 6 rsq     standard   0.958    10 0.00191 Preprocessor~
 2              27    37  1620    35          8   3.16e- 2       7.35e- 8 rsq     standard   0.957    10 0.00195 Preprocessor~
 3               0    23  1183     4         12   2.44e- 3       1.91e-10 rsq     standard   0.956    10 0.00218 Preprocessor~
 4              23    45  1450     8          4   6.11e- 4       7.60e- 2 rsq     standard   0.893    10 0.00325 Preprocessor~
 5              42    13   336    37          2   6.48e- 3       5.83e-10 rsq     standard   0.888    10 0.00293 Preprocessor~
 6               4    13   575     8         13   2.68e- 4       1.09e+ 0 rsq     standard   0.855    10 0.00460 Preprocessor~
 7              20     7   798    27         15   1.18e- 4       4.65e- 9 rsq     standard   0.845    10 0.00511 Preprocessor~
 8              44    18  1097    20         10   3.33e- 5       5.98e+ 0 rsq     standard   0.835    10 0.00535 Preprocessor~
 9              33    33  1538    18         14   5.55e- 6       2.17e- 2 rsq     standard   0.832    10 0.00551 Preprocessor~
10              49    31   870    11          2   2.32e- 5       1.70e+ 1 rsq     standard   0.832    10 0.00549 Preprocessor~
11              14    22  1993    12          3   6.54e- 7       1.42e- 4 rsq     standard   0.830    10 0.00555 Preprocessor~
12              17    28  1311    34          8   2.41e-10       2.92e- 5 rsq     standard   0.830    10 0.00557 Preprocessor~
13              39    46   245    31         11   2.60e- 8       9.67e- 7 rsq     standard   0.830    10 0.00557 Preprocessor~
14              22     5  1882     3          7   1.45e- 8       1.01e- 7 rsq     standard   0.830    10 0.00557 Preprocessor~
15              45    48   971    30          6   2.94e-10       5.34e- 3 rsq     standard   0.830    10 0.00556 Preprocessor~
16              37    19   402    39          9   2.28e- 9       4.83e- 4 rsq     standard   0.830    10 0.00558 Preprocessor~
17               8    42    42    21          3   2.22e- 6       1.63e- 1 rsq     standard   0.830    10 0.00554 Preprocessor~
18              30    30  1261    25         11   1.34e- 9       1.90e- 8 rsq     standard   0.830    10 0.00557 Preprocessor~
19              31     1  1756    14         13   8.92e- 8       2.41e- 3 rsq     standard   0.830    10 0.00557 Preprocessor~
20               6     9   145    26          5   2.50e- 7       1.89e- 6 rsq     standard   0.829    10 0.00552 Preprocessor~

Round 1

Plot the tuning results for analysis. You may pipe the tuning results into feasts::autoplot() and generated and plot an interactive ggplot object with ggplotly, as shown in the code snippet below:

gr1<- tune_results_prophet_boost %>%
  autoplot() +
  geom_smooth(se = FALSE)

ggplotly(gr1)

This is the most important part of the process: as a data scientist, you will decide of the tuning strategy.

Try to spot the plot with a monotonic smooth fonction (blue line), descending for RMSE or ascending for R-squared. Here, it corresponds to "Learning Rate (log-10)" parameter. Update the grid spec with a new range of values for Learning Rate where the RMSE is minimal.

Generally speaking we will do the following steps for each tuning round

1. update or adjust the parameter range within the grid specification.

2. toggle on parallel processing

3. perform hyperparameter tuning with new grid specification

4. toggle off parallel processing

5. analyze best RMSE and RSQ results

6. go to 1.

Round 2

We fix learn_rate parameter range of values.

# 1. update or adjust the parameter range within the grid specification.
set.seed(123)
grid_spec_2 <- grid_latin_hypercube(
  extract_parameter_set_dials(model_spec_prophet_boost_tune) %>% 
    update(mtry = mtry(range = c(1, 50)),
           learn_rate = learn_rate(range = c(-2.0, -1.0))),
  size = 20
)

# 2. toggle on parallel processing
plan(
  strategy = cluster,
  workers  = parallel::makeCluster(n_cores)
)

# 3. perform hyperparameter tuning with new grid specification
tic()
tune_results_prophet_boost_2 <- wflw_spec_prophet_boost_tune %>%
  tune_grid(
    resamples  = resamples_kfold,
    grid = grid_spec_2,
    control = control_grid(verbose = TRUE, 
                           allow_par = TRUE)
  )
toc()

# 4. toggle off parallel processing
plan(strategy = sequential)

# 5. analyze best RMSE and RSQ results (here top 2)
> tune_results_prophet_boost_2 %>% 
+     show_best("rsq", n = 2)
# A tibble: 2 x 13
  changepoint_num  mtry trees min_n tree_depth learn_rate loss_reduction .metric .estimator  mean     n std_err .config       
            <int> <int> <int> <int>      <int>      <dbl>          <dbl> <chr>   <chr>      <dbl> <int>   <dbl> <chr>         
1               0    23  1183     4         12     0.0662       1.91e-10 rsq     standard   0.961    10 0.00217 Preprocessor1~
2              11    40   613    16          6     0.0938       7.32e- 6 rsq     standard   0.960    10 0.00171 Preprocessor1~

> tune_results_prophet_boost_2 %>% 
+     show_best("rmse", n = 2)
# A tibble: 2 x 13
  changepoint_num  mtry trees min_n tree_depth learn_rate loss_reduction .metric .estimator  mean     n std_err .config       
            <int> <int> <int> <int>      <int>      <dbl>          <dbl> <chr>   <chr>      <dbl> <int>   <dbl> <chr>         
1               0    23  1183     4         12     0.0662       1.91e-10 rmse    standard   0.179    10 0.00462 Preprocessor1~
2              11    40   613    16          6     0.0938       7.32e- 6 rmse    standard   0.181    10 0.00340 Preprocessor1~

Let us analyse the plot

gr2 <- tune_results_prophet_boost_2 %>%
  autoplot() +
  geom_smooth(se = FALSE)

ggplotly(gr2)

Round 3

We fix trees parameter range of values.

set.seed(123)
grid_spec_3 <- grid_latin_hypercube(
  extract_parameter_set_dials(model_spec_prophet_boost_tune) %>% 
    update(mtry = mtry(range = c(1, 50)),
           learn_rate = learn_rate(range = c(-2.0, -1.0)),
           trees = trees(range = c(1183, 1993))),
  size = 20
)

plan(
  strategy = cluster,
  workers  = parallel::makeCluster(n_cores)
)

tic()
tune_results_prophet_boost_3 <- wflw_spec_prophet_boost_tune %>%
  tune_grid(
    resamples  = resamples_kfold,
    grid = grid_spec_3,
    control = control_grid(verbose = TRUE, 
                           allow_par = TRUE)
  )
toc()

plan(strategy = sequential)

> tune_results_prophet_boost_3 %>% 
+     show_best("rmse", n = 2)
# A tibble: 2 x 13
  changepoint_num  mtry trees min_n tree_depth learn_rate loss_reduction .metric .estimator  mean     n std_err .config       
            <int> <int> <int> <int>      <int>      <dbl>          <dbl> <chr>   <chr>      <dbl> <int>   <dbl> <chr>         
1               0    23  1662     4         12     0.0662       1.91e-10 rmse    standard   0.179    10 0.00464 Preprocessor1~
2              11    40  1431    16          6     0.0938       7.32e- 6 rmse    standard   0.179    10 0.00363 Preprocessor1~

> tune_results_prophet_boost_3 %>% 
+     show_best("rsq", n = 2)
# A tibble: 2 x 13
  changepoint_num  mtry trees min_n tree_depth learn_rate loss_reduction .metric .estimator  mean     n std_err .config       
            <int> <int> <int> <int>      <int>      <dbl>          <dbl> <chr>   <chr>      <dbl> <int>   <dbl> <chr>         
1              11    40  1431    16          6     0.0938       7.32e- 6 rsq     standard   0.961    10 0.00174 Preprocessor1~
2               0    23  1662     4         12     0.0662       1.91e-10 rsq     standard   0.961    10 0.00220 Preprocessor1~

We obtain two best models, they show the same RMSE and RSQ values because there are rounded figures.

Select and fit the best model(s)

Please recall that we deal with workflows (not models directly) which incoporate a a model and a preprocessing recipe.

We finalize (finalize_workflow()) the tuning process by selecting the best model (select_best()) from round 3 tuning results (tune_results_prophet_boost_3) and finally, we refit the model (fit(training(splits))), and display accuracy results.

# Fitting round 3 best RMSE model
set.seed(123)
wflw_fit_prophet_boost_tuned <- wflw_spec_prophet_boost_tune %>%
  finalize_workflow(
    select_best(tune_results_prophet_boost_3, "rmse", n=1)) %>%
  fit(training(splits))

modeltime_table(wflw_fit_prophet_boost_tuned) %>%
  modeltime_calibrate(testing(splits)) %>%
  modeltime_accuracy()

# A tibble: 1 x 9
  .model_id .model_desc               .type   mae  mape  mase smape  rmse   rsq
      <int> <chr>                     <chr> <dbl> <dbl> <dbl> <dbl> <dbl> <dbl>
1         1 PROPHET W/ XGBOOST ERRORS Test  0.191  25.7 0.421  19.9 0.253 0.780

# Fitting round 3 best RSQmodel
set.seed(123)
wflw_fit_prophet_boost_tuned_rsq <- wflw_spec_prophet_boost_tune %>%
  finalize_workflow(
    select_best(tune_results_prophet_boost_3, "rsq", n=1)) %>%
  fit(training(splits))

modeltime_table(wflw_fit_prophet_boost_tuned_rsq) %>%
  modeltime_calibrate(testing(splits)) %>%
  modeltime_accuracy()

# A tibble: 1 x 9
  .model_id .model_desc               .type   mae  mape  mase smape  rmse   rsq
      <int> <chr>                     <chr> <dbl> <dbl> <dbl> <dbl> <dbl> <dbl>
1         1 PROPHET W/ XGBOOST ERRORS Test  0.223  26.2 0.492  22.3 0.308 0.722