🤖 AI

Empirical Computation: Prompting versus Programming

Ce document de vision propose l'« informatique empirique » comme un nouveau paradigme où les grands modèles de langage résolvent des problèmes computationnels via le prompting plutôt que par la programmation traditionnelle, soutenant que leurs capacités et limites uniques exigent que la communauté du génie logiciel développe de nouvelles théories fondamentales et de nouvelles techniques pour analyser la correction et les frontières fondamentales.

Auteurs originaux : Eric Tang, Jing Liu, Marcel Böhme

Publié 2026-07-08

📖 5 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Eric Tang, Jing Liu, Marcel Böhme

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous avez deux façons de réaliser une tâche : la Programmation et le Prompting.

L'ancienne méthode : La Programmation (L'architecte rigoureux)

Considérez la programmation traditionnelle comme l'embauche d'un architecte strict qui suit les règles à la lettre. Vous lui donnez un plan avec des mesures précises, des matériaux spécifiques et un plan étape par étape.

Comment cela fonctionne : Vous dites à l'ordinateur exactement comment résoudre un problème, comme trier une liste de nombres. Vous dites : « Utilise cet algorithme spécifique (le Tri Fusion), prends ces entrées, et suis ces règles. »
Le résultat : Si l'architecte fait une erreur, vous pouvez trouver la brique défectueuse exacte dans le plan, la réparer, et savoir avec certitude que le bâtiment tiendra correctement la prochaine fois.
La limite : Le temps nécessaire pour construire dépend de la complexité des mathématiques. Trier une immense liste de nombres prend un temps prévisible basé sur la taille de la liste (spécifiquement, $O(n \log n)$ ).

La nouvelle méthode : Le Prompting (L'artiste intuitif)

Maintenant, imaginez que vous engagez un artiste brillant et intuitif à la place. Vous ne lui donnez pas de plan. Vous dites simplement : « Hé, voici un tas de nombres désordonnés, pourrais-tu les trier pour moi ? »

Comment cela fonctionne : Vous utilisez le langage naturel (un « prompt ») pour décrire le problème. L'« ordinateur » (un Grand Modèle de Langage ou LLM) ne suit pas un ensemble de règles strictes. Au lieu de cela, il devine la réponse la plus probable en se basant sur tout ce qu'il a déjà lu sur Internet. C'est comme un chef qui goûte une soupe et devine les ingrédients plutôt que de suivre une recette.
Le résultat : La réponse arrive vite, mais c'est une supposition, pas une garantie. C'est la réponse la « plus probable », pas la réponse « prouvée correcte ».

Ce que l'article a découvert : La surprise « empirique »

Les auteurs de cet article ont mené des expériences pour voir comment cet « Artiste Intuitif » se comporte sur des problèmes mathématiques classiques comme le tri de nombres ou la recherche d'éléments dans une liste. Voici ce qu'ils ont découvert :

1. Le temps ne fonctionne pas de la même manière

Programmation : Si vous doublez le nombre d'éléments à trier, le temps nécessaire augmente d'une manière mathématique spécifique.
Prompting : Le temps nécessaire au LLM pour trier des nombres augmente de manière linéaire (juste une ligne droite) à mesure que la liste s'allonge. Pourquoi ? Non pas parce que les mathématiques sont plus complexes, mais parce que le LLM doit lire et écrire plus de mots (tokens) pour gérer la liste plus longue. C'est comme lire un livre plus long ; cela prend plus de temps pour lire les mots, pas parce que l'histoire est plus complexe.

2. La précision chute à mesure que les choses s'étendent

Programmation : Un programme correct est correct à 100 % à chaque fois.
Prompting : Le LLM est excellent pour les petites tâches, mais il s'embrouille à mesure que la liste grandit.
- Pour une liste de 50 nombres, le LListe a réussi environ 90 % du temps.
- Pour une liste de 150 nombres, il n'a réussi qu'environ 58 % du temps.
- Si vous lui demandez de trouver un motif spécifique dans une chaîne courte, il peut échouer presque immédiatement si la chaîne devient légèrement plus longue.
- Le mode « Réflexion » : Lorsque le LLM est autorisé à « réfléchir » (raisonner étape par étape) avant de répondre, il reste très précis, mais cela prend beaucoup plus de temps.

3. Le jeu de langage

Programmation : Peu importe que vous écriviez le code en anglais ou en allemand ; l'ordinateur lit les symboles de la même manière.
Prompting : Le LLM est biaisé par ce qu'il a lu sur Internet.
- Si vous demandez au LLM de trier des nombres écrits en anglais (« one, two, three »), il fait du bon travail.
- Si vous lui demandez de trier des nombres écrits en allemand (« eins, zwei, drei »), il échoue presque totalement.
- Pourquoi ? Le LLM a vu des millions d'exemples anglais sur Internet, mais beaucoup moins d'exemples allemands. C'est comme demander à un chef de cuisiner un plat qu'il n'a jamais vu auparavant ; il pourrait se tromper.

4. Le problème de la « brique défectueuse »

Programmation : Si un programme échoue, vous pouvez trouver le bug, corriger le code, et le problème est résolu pour toujours.
Prompting : Si le LLM donne une mauvaise réponse, vous ne pouvez pas facilement trouver « le bug ». Vous ne pouvez pas pointer une ligne de code spécifique pour la corriger. Vous pouvez essayer de changer votre prompt ou de lui demander de « réfléchir plus intensément », mais il n'y a aucune garantie que cela fonctionnera la prochaine fois. C'est comme essayer de réparer un rêve en changeant l'humeur du rêveur.

La grande conclusion

L'article soutient que nous entrons dans une nouvelle ère appelée « Calcul Empirique ».

Dans l'ancien monde, nous faisions confiance aux ordinateurs parce qu'ils suivaient des règles strictes (cadre rationaliste). Dans ce nouveau monde, nous faisons confiance aux ordinateurs parce qu'ils font des « suppositions éclairées » basées sur les données (cadre empirique).

Les auteurs appellent les ingénieurs logiciels à cesser d'analyser ces systèmes d'IA comme des programmes classiques. Nous avons besoin de nouveaux outils pour mesurer, tester et comprendre comment ces « machines à deviner » fonctionnent, car les anciennes règles de mathématiques et de logique ne s'appliquent plus totalement à elles. Nous devons découvrir comment faire confiance à un résultat qui est « probablement vrai » plutôt qu'à un résultat qui est « certainement vrai ».

Résumé Technique : Calcul Empirique : Prompting versus Programmation

Énoncé du Problème

Le papier identifie un changement de paradigme dans la résolution de problèmes computationnels : le passage de la programmation (spécification d'algorithmes et de structures de données précises) au prompting (fourniture de descriptions informelles en langage naturel à des modèles de langage étendu ou des agents). Alors que l'informatique traditionnelle repose sur des procédures déterministes avec une correction vérifiable et des bornes de complexité bien définies (par exemple, $O(n \log n)$ pour le tri), le « calcul empirique » repose sur l'échantillonnage de sorties issues d'une distribution de probabilité.

Le problème central est que les capacités et les limites de cette nouvelle forme de calcul ne peuvent être comprises dans le cadre rationaliste classique de l'informatique. Spécifiquement :

Absence de Déterminisme : Les sorties ne sont pas générées de manière procédurale mais sont le résultat « empiriquement le plus probable », ce qui les rend susceptibles d'hallucinations et d'erreurs qui ne peuvent être localisées ou réparées via un débogage traditionnel.
Ambiguïté de l'Entrée : Contrairement à la programmation, qui exige des contrats formels (types, formats), le prompting accepte des entrées informelles où l'interprétation dépend du contexte et de la distribution d'entraînement du modèle.
Complexité Incertaine : Le comportement du temps d'exécution semble déconnecté de la complexité computationnelle classique, corrélant plutôt avec la tokenisation et le comportement d'inférence du modèle.
Écart de Vérification : Les techniques actuelles du génie logiciel (SE) (analyse statique, vérification formelle) sont mal équipées pour analyser des systèmes où aucun programme explicite n'existe à vérifier.

Méthodologie

Les auteurs ont mené des expériences préliminaires pour caractériser l'efficacité et la correction du calcul empirique à travers cinq problèmes computationnels classiques :

Tri (Sorting) : Ordre croissant de nombres aléatoires.
Recherche (Searching) : Trouver un index dans des listes triées et non triées.
Plus Longue Sous-chaîne Palindromique (Longest Palindromic Substring) : Trouver la séquence palindrome la plus longue dans une chaîne.
Problème de la Somme de Sous-ensembles (Subset Sum Problem - SSP) : Trouver un sous-ensemble de nombres dont la somme égale une valeur cible.

Configuration Expérimentale :

Modèle : Les expériences ont utilisé le modèle à poids ouverts gemma-4-26b-a4b tournant localement sur un MacBook Pro (M5 Pro, 48 Go de RAM) pour éliminer la latence réseau.
Configurations : Trois modes ont été testés :
- Par Défaut (Default) : Température = 1.0.
- Déterministe (Deterministic) : Température = 0.0.
- Réflexion (Thinking) : Mode de raisonnement activé.
Métriques :
- Efficacité : Temps pour la solution et temps pour la première solution correcte.
- Correction : Proportion d'essais retournant la réponse mathématiquement correcte.
Variables : Taille de l'entrée ( $n$ ), précision du nombre, et représentation linguistique (chiffres vs mots dans diverses langues : anglais, allemand, coréen, japonais, etc.).
Vérité de Terrain (Ground Truth) : Pour les problèmes non triviaux (Sous-chaîne, SSP), de simples programmes Python ont généré les bonnes réponses pour la validation.

Résultats Clés

1. Efficacité vs Complexité Classique

Contrairement à la théorie classique, le temps d'exécution du calcul empirique ne suit pas strictement la complexité algorithmique du problème (par exemple, $O(n)$ vs $O(n \log n)$ ).

Mise à l'échelle Linéaire : Pour le tri, la recherche et le SSP, le temps pour la solution a augmenté linéairement avec la taille de l'entrée ( $O(n)$ ) dans tous les modes. Les auteurs attribuent cela à l'augmentation linéaire des tokens d'entrée/sortie plutôt qu'à la logique computationnelle.
Dépendance aux Tokens : Le temps nécessaire pour incrémenter un nombre était comparable à la prédiction de texte clair à partir d'un hash SHA-512, suggérant que le temps d'exécution est piloté par la tokenisation et les mécanismes d'inférence plutôt que par la difficulté du problème.
Coût du Mode Réflexion (Thinking Mode) : Activer la « réflexion » (raisonnement) a considérablement augmenté le temps d'exécution (jusqu'à 275s pour trier 150 éléments) mais a maintenu une correction élevée.

2. Correction et Taille d'Entrée

Sensibilité à la Taille : Dans les modes Par Défaut et Déterministe, la correction s'est dégradée rapidement à mesure que la taille de l'entrée augmentait.
- Pour le tri de 50 entiers, la correction est tombée à environ 50% (probabilité d'un pile ou face).
- Pour le tri de 150 entiers, la correction est tombée à environ 58% (malgré l'augmentation linéaire du temps).
- Pour le problème de la Somme de Sous-ensembles, la correction a approché zéro pour des listes de longueur 10.
- Pour le problème de la Sous-chaîne, la correction est tombée proche de zéro pour des chaînes de longueur 5.
Résilience du Mode Réflexion : Lorsque les capacités de raisonnement étaient activées, la correction restait élevée (>90%), même pour des entrées plus grandes, bien que dans les limites de tokens/temps.

3. Impact de la Représentation en Langage Naturel

L'étude a examiné comment la langue utilisée pour représenter les nombres affecte la correction.

Biais de Représentation des Données : La correction dépend fortement de la représentation de la langue dans les données d'entraînement du modèle.
Haute vs Basse Représentation : Trier des nombres écrits en anglais (bien représentés) donnait une correction >95% pour la taille 20. En revanche, trier des nombres écrits en allemand (sous-représentés) donnait <1% de correction pour la même taille.
Conclusion : Le calcul empirique n'est pas agnostique à la langue ; il est biaisé en faveur des langues et des formats prévalents dans le corpus d'entraînement.

4. Caractéristiques des Erreurs

Contrairement aux programmes traditionnels où les fautes peuvent être localisées sur des lignes de code spécifiques, les erreurs en calcul empirique sont non déterministes. L'LLM peut :

Ajouter des nombres non présents dans l'entrée.
Retirer des nombres présents dans l'entrée.
Dupliquer des nombres.
Échouer à trier la liste entière.
Tronquer de grandes entrées.

Principales Contributions

Définition du Calcul Empirique : Le papier introduit formellement le « calcul empirique » comme un domaine distinct où les solutions sont générées via le prompting et l'échantillonnage plutôt que par exécution procédurale.
Caractérisation Empirique : Il fournit la première mesure systématique de l'efficacité et de la correction des LLM résolvant des problèmes algorithmiques classiques, révélant que le temps d'exécution est corrélé à la tokenisation plutôt qu'à la complexité algorithmique.
Identification des Limites : L'étude démontre que sans modes de raisonnement, le calcul empirique ne parvient pas à passer à l'échelle de manière fiable avec la taille de l'entrée et est hautement sensible à la représentation linguistique des entrées.
Appel pour de Nouveaux Fondements de SE : Les auteurs soutiennent que la communauté du génie logiciel (SE) doit développer de nouveaux outils pour l'« analyse de programme empirique » (raisonnement statistique, contrefactuel ou causal) afin d'analyser, d'estimer et de prédire la correction de ces systèmes.

Signification et Vision

Le papier pose que la communauté du génie logiciel ne peut pas s'appuyer sur les cadres rationalistes classiques ou les outils d'analyse de programme existants pour garantir la fiabilité du calcul piloté par l'IA. À mesure que les LLM et les agents deviennent intégrés à la résolution de problèmes computationnels, le domaine doit évoluer pour répondre à :

Comment analyser la correction en l'absence d'un programme formel.
Comment définir et tester les limites du calcul empirique.
Comment améliorer la correction pour des instances de problèmes spécifiques sans introduire de régressions.

Les auteurs présentent cela comme un domaine de recherche opportun et riche, appelant au développement de techniques d'« analyse de programme empirique » pour combler le fossé entre la nature probabiliste des LLM et les exigences rigoureuses du génie logiciel. Le papier ne prétend pas résoudre ces problèmes mais vise à établir le domaine et à souligner le besoin urgent de nouveaux fondements théoriques et pratiques.