🥡 The Tech Away | Issue #5
De la veille tech à emporter | Novembre 2024
Au menu ce mois-ci :
📰 Le Accelerate/DORA State of Devops 2024 est paru
🏷️ Une solution de Google pour détecter le contenu généré par IA ?
🧮 Démontrer mathématiquement que S3, ça marche, avec la méthode formelle
📰 Le DORA State of DevOps 2024 est paru
Comme chaque année, ce mois-ci sort le State of DevOps 2024 du DORA (le DevOps Research and Assessment group), une étude que je suis avec intérêt depuis bientôt 10 ans pour tenter de comprendre ce qui fait le succès d’une organisation performante.
Le millésime 2024 consiste en un rapport de 120 pages qui s’intéresse aux thématiques suivantes cette année : l’épuisement professionnel (burnout), la satisfaction au travail, le flow (au sens de Csikszentmihalyi, la capacité d’un individu à se plonger dans un état de concentration maximal pour réaliser des tâches) ou encore la productivité des individus, des équipes et de l’organisation.
Je vous invite évidemment à lire cet ouvrage, ou au moins les key findings résumés en début de rapport, mais voici ce que je retiens du rapport, l’ayant lu non pas encore en totalité mais par morceaux :
C’est une édition qui parle beaucoup plus d’IA qu’à l’accoutumé (203 occurrences du mot “IA” dans ce rapport). Et pour cause, 81% des organisations sondées pour cette étude partagent avoir priorisé les initiatives permettant d’intégrer de l’IA dans leurs produits ou services cette année.
Il est intéressant de noter que si les répondants perçoivent une hausse de leur productivité grâce à l’IA qui leur permet de produire plus de code plus vite, l’étude anticipe pour les prochaines années un risque : produire plus de code peut amener à vouloir livrer en production des lots de code plus grand, ce qui va à contre-sens de la capability Working in Small Batches.
Since AI allows respondents to produce a much greater amount of code in the same amount of time, it is possible, even likely, that changelists are growing in size. DORA has consistently shown that larger changes are slower and more prone to creating instability.
Je note aussi que l’étude anticipe que l’IA pourra aider les organisations à produire une documentation de meilleure qualité, et c’est un effet de bord souhaitable quand on se rappelle que le State of DevOps 2022 traçait déjà à l’époque une corrélation entre documentation de qualité et performance
De nouvelles métriques à suivre : cela fait quelques années que le DORA suspecte que le Change Failure Rate (CFR) est une métrique qui masquait d’autres signaux utiles. Le rapport propose de suivre en complément du Mean Time to Repair (MTTR) 2 nouvelles métriques plus fines :
Le Failed deployment recovery time : le temps nécessaire pour rétablir le fonctionnement du système après un déploiement qui a échoué
Le rework rate : sur une période donnée, c’est le nombre de déploiement en production qui n’étaient pas prévus mais qui ont été tout de même réalisés pour corriger un bug rencontré par les utilisateurs.
Le rapport est disponible derrière un formulaire sur le site de Google Cloud, gratuitement - lien
Et vous, qu’est-ce que vous avez retenu d’important de ce rapport ?
🏷️ Une solution de Google pour détecter le contenu généré par IA ?
A la fin du mois d’octobre, Google DeepMind a fait paraître dans la revue Nature un papier intitulé Scalable watermarking for identifying large language model outputs soulignant à quel point il devient difficile de savoir si du contenu a été généré par une IA. Google propose dans ce papier une solution simple à ce problème : intégrer un filigrane lors de la génération du contenu 🏷️
Bien sûr, l’idée n’est pas de rajouter un filigrane aussi grossier que je celui que j’ai inséré dans l’image ci-avant, d’autant plus que le papier parle de contrôle sur du texte généré. L’implémentation de ce mécanisme de filigrane proposée dans ce papier, SynthIDText, consiste à définir une clef (secrète) de filigrane qui sera encodée dans le texte produit par le LLM. La promesse de cette implémentation est que le filigrane ne doit pas nuire à la qualité du texte généré ni ne nécessiter de ré-entraîner le modèle (puisque le filigrane intervient uniquement en phase de sampling, à la prédiction du token).
Tout ceci peut déjà être testé sur HuggingFace, avec une librairie (Google/SyntId-Text) pour générer du texte “filigrané”. Et on notera aussi cette autre librairie (transformers.SynthIDTextWatermarkDetector) qui va de pair : il s’agit d’un détecteur probabiliste Bayesien capable de prédire 3 classes (filigrane, non filigrane ou incertain) à partir d’une chaîne de caractères en entrées.
Evidemment, ce ne sont que des outils, encore faut-il que l’usage se propage, que les acteurs proposant des solutions de génération de texte (comme ChatGPT ou Perplexity) commencent à s’en servir et y voient un intérêt.
Et vous, est-ce que vous croyez à ce genre d’approches pour distinguer le vrai du AI-generated ?
🧮 Démontrer mathématiquement que S3, ça marche, avec la méthode formelle
Je me suis intéressé ce mois-ci à un papier rédigé par des ingénieurs chez AWS en 2021 : Using Lightweight Formal Methods to Validate a Key-Value Storage Node in Amazon S3
Ce papier détaille la démarche de test réalisée par ces ingénieurs sur ShardStore, une implémentation de moteur de stockage clef-valeur pour le service S3 sous forme d’arbre LSM (Log-Structured Merge-tree), réalisée avec des approches de méthode formelle : on parle ici de tests automatisés capable de prouver mathématiquement que des parties du code de ShardStore sont correctes et qui ont permis ici de détecter, avant d’aller en production, 16 bugs critiques que l’équipe aurait eu du mal à trouver autrement.
L’approche consiste à définir des propriétés souhaitées sur le système (propriétés de persistance, comportement souhaité en cas de panic/crash, propriétés sur la sérialisation des données) avec un certain formalisme mathématique, implémenter des tests avec des approches comme le property-based testing, puis injecter du chaos (disk IO failures, resource exhaustion, actions concurrentes sur le système, …) pour vérifier si ces propriétés sont respectées.
Je pratique le TDD mais je ne me suis jamais vraiment initié à la formal method, ce papier sur un cas logiciel concret et complexe m’a aidé à y voir un peu plus clair. Si ce paradigme vous intrigue, je vous conseille de suivre le contenu de Hillel Wayne, une référence sur ce sujet que j’ai découvert en 2019 dans le talk ci-après Beyond Unit Tests: Taking Your Testing to the Next Level, où il démontre l’usage de la librairie Hypothesis pour faire du property-based testing avec des tests paramétrés :
Le papier d’AWS : Using Lightweight Formal Methods to Validate a Key-Value Storage Node in Amazon S3
Hillel Wayne - Beyond Unit Tests: Taking Your Testing to the Next Level
Blog de Hillel Wayne, qui écrit souvent sur la formal method
Et vous, est-ce que vous pratiquez la formal method dans vos projets ? Je suis preneur de retours d’expérience sur ce sujet !