Ton article le dit très bien : les labs ont entraîné sur le code parce que le feedback est binaire. Ça compile ou ça plante. Pas d'ambiguïté. Et c'est précisément ce signal clair qui a permis le "transfer learning" vers le "raisonnement structuré". Mais il y a un paradoxe que tu traverse à mon avis : cette même propriété qui a fait du code le terrain d'entraînement idéal est exactement ce qui rend l'extrapolation compliquée dans notre monde "d'information" au sens théorie et pratique de l'information. Dans le code, "verify" veut dire faire passer un test. Dans l'information au sens le plus général, "verify " veut dire évaluer la fiabilité ou juger de la pertinence vs le monde réel, ou encore repérer ce qui manque dans un raisonnement qui a l'air complet. Aucun test unitaire au monde ne sait faire ça, mais je peux me tromper. Ton rticle met la vérification comme 4ème temps d'une boucle automatisable (read-process-output-verify), mais pour quiconque a déjà vérifié une information, c'est un peu comme mettre "jouer du piano" comme 4ème étape d'un tuto en cinq points, pour reprendre l'image ;)
Si je prends comme exemple la génération d'un document quelconque. L'agent cherche et lit des sources, les traite, et produit/génère. Le résultat a l'air solide. Mais pour moi c'est là que ça se complique, parce que le 4ème temps, celui qui fait la différence entre un document utile et un document inutile ou dangereux, n'est pas de la même nature que les trois précédents. Ce n'est pas une opération : c'est un jugement. Et un jugement, pour moi ça ne se code pas en Python ni ne se décrit in extenso en anglais/français. La cible à 15 000 milliards existe sûrement, mais elle repose sur l'hypothèse que "verify" est un verbe comme les autres dans la boucle.
Pour l'instant et de mon point de vue, "verify" c'est le verbe qui résiste. Même si les labs, par exemple Anthropic pour ne pas le nommer, tentent tant bien que mal à coup de "contitutions" et autres "rails guards" d'y parvenir. Mais s'ils y arrivaient vraiment, le problème alors serait bien plus compliqué : qui aurait la maitrise du jugement/verify au final ? L'humain ou un modèle guidé par une constitution "imposée" ? Ok je dévie ;)
Merci de ce commentaire détaillé ! Oui j’ai vu dans ta newsletter que tu étais sceptique :)
Tu as raison le verify est un nouveau bottleneck dans certains cas d’univers « ouvert » / sans « ground truth » (exemple : un contrat qui peut se rédiger de X façons). J’aurais dû le préciser
Néanmoins
1/ le point est pas de dire qu’on va automatiser les jobs mais remplacer le SaaS - mais peut être pas clair dans mon déroulé.
2/ Le verify c’est light pour justifier le SaaS sauf si justement ce SaaS se déplace > vers de la data propre qui boucle cette boucle, ou qui organise l auditabilité de ce jugement (qui / comment / pourquoi) etc… c’est le point de Benedict Evans et que j’évoque aussi
Alors pas totalement sceptique mais surtout assez interloqué par tout ce que j'ai pu voir passer et lire sur (je caricature à peine) : "le logiciel est mort", "tous les SaaS sont morts"...
Je pense que nos points de vue se rejoignent, mais corrige moi si ce n'est pas le cas : c'est le déplacement d'une couche et pas une disparition, seules des expressions de cette couche vont disparaitre (certains SaaS par ex)
1/ OK on est d'accord modulo le 2/
2/ Ma compréhension approximative des langues a dû me faire mal interpréter le passage avec lequel je suis en accord aussi
Oui, on est d accord sur l idée de « l’expression » (ou la valeur) du SaaS qui change
Et je te rassure je crois pas que ça soit une question d anglais mon texte n’est pas précis sur cette question … a dire vrai le cœur du message était plutôt en amont sur cette réalisation que le code était plus qu’une question de code, cette partie spécifique du SaaS est en soi un sujet
Pour moi l'emploi du mot "expression" englobe plus que la "valeur", mais tu as entièrement raison de recadrer car c'est principalement une problématique de "valeur" sous toutes ses formes
Sorry in french ;)
Ton article le dit très bien : les labs ont entraîné sur le code parce que le feedback est binaire. Ça compile ou ça plante. Pas d'ambiguïté. Et c'est précisément ce signal clair qui a permis le "transfer learning" vers le "raisonnement structuré". Mais il y a un paradoxe que tu traverse à mon avis : cette même propriété qui a fait du code le terrain d'entraînement idéal est exactement ce qui rend l'extrapolation compliquée dans notre monde "d'information" au sens théorie et pratique de l'information. Dans le code, "verify" veut dire faire passer un test. Dans l'information au sens le plus général, "verify " veut dire évaluer la fiabilité ou juger de la pertinence vs le monde réel, ou encore repérer ce qui manque dans un raisonnement qui a l'air complet. Aucun test unitaire au monde ne sait faire ça, mais je peux me tromper. Ton rticle met la vérification comme 4ème temps d'une boucle automatisable (read-process-output-verify), mais pour quiconque a déjà vérifié une information, c'est un peu comme mettre "jouer du piano" comme 4ème étape d'un tuto en cinq points, pour reprendre l'image ;)
Si je prends comme exemple la génération d'un document quelconque. L'agent cherche et lit des sources, les traite, et produit/génère. Le résultat a l'air solide. Mais pour moi c'est là que ça se complique, parce que le 4ème temps, celui qui fait la différence entre un document utile et un document inutile ou dangereux, n'est pas de la même nature que les trois précédents. Ce n'est pas une opération : c'est un jugement. Et un jugement, pour moi ça ne se code pas en Python ni ne se décrit in extenso en anglais/français. La cible à 15 000 milliards existe sûrement, mais elle repose sur l'hypothèse que "verify" est un verbe comme les autres dans la boucle.
Pour l'instant et de mon point de vue, "verify" c'est le verbe qui résiste. Même si les labs, par exemple Anthropic pour ne pas le nommer, tentent tant bien que mal à coup de "contitutions" et autres "rails guards" d'y parvenir. Mais s'ils y arrivaient vraiment, le problème alors serait bien plus compliqué : qui aurait la maitrise du jugement/verify au final ? L'humain ou un modèle guidé par une constitution "imposée" ? Ok je dévie ;)
Merci de ce commentaire détaillé ! Oui j’ai vu dans ta newsletter que tu étais sceptique :)
Tu as raison le verify est un nouveau bottleneck dans certains cas d’univers « ouvert » / sans « ground truth » (exemple : un contrat qui peut se rédiger de X façons). J’aurais dû le préciser
Néanmoins
1/ le point est pas de dire qu’on va automatiser les jobs mais remplacer le SaaS - mais peut être pas clair dans mon déroulé.
2/ Le verify c’est light pour justifier le SaaS sauf si justement ce SaaS se déplace > vers de la data propre qui boucle cette boucle, ou qui organise l auditabilité de ce jugement (qui / comment / pourquoi) etc… c’est le point de Benedict Evans et que j’évoque aussi
Alors pas totalement sceptique mais surtout assez interloqué par tout ce que j'ai pu voir passer et lire sur (je caricature à peine) : "le logiciel est mort", "tous les SaaS sont morts"...
Je pense que nos points de vue se rejoignent, mais corrige moi si ce n'est pas le cas : c'est le déplacement d'une couche et pas une disparition, seules des expressions de cette couche vont disparaitre (certains SaaS par ex)
1/ OK on est d'accord modulo le 2/
2/ Ma compréhension approximative des langues a dû me faire mal interpréter le passage avec lequel je suis en accord aussi
Oui, on est d accord sur l idée de « l’expression » (ou la valeur) du SaaS qui change
Et je te rassure je crois pas que ça soit une question d anglais mon texte n’est pas précis sur cette question … a dire vrai le cœur du message était plutôt en amont sur cette réalisation que le code était plus qu’une question de code, cette partie spécifique du SaaS est en soi un sujet
Pour moi l'emploi du mot "expression" englobe plus que la "valeur", mais tu as entièrement raison de recadrer car c'est principalement une problématique de "valeur" sous toutes ses formes