Il y a une grande quantité de connaissances spécialisées qui ne sont pas sur Internet. Il n'est dans aucun livre ou base de données non plus. Il est distribué à travers les cerveaux humains, encodé dans les systèmes de fonctionnement, et intégré dans des processus que personne ne comprend pleinement.
Friedrich Hayek a formulé cela en 1945 mieux que quiconque depuis:
Il n'y a pas de doute qu'il y a un ensemble de connaissances très importantes mais non organisées qui ne peuvent pas être appelées scientifiques au sens de la connaissance des règles générales : la connaissance des circonstances particulières du temps et du lieu. Annexe
Il écrivait sur l'économie, mais l'observation est beaucoup plus générale. Une grande partie du monde s'appuie sur des connaissances locales, tacites et distribuées. Pensez au coordonnateur de la logistique qui gagne sa vie en sachant qu'il n'a pas été temporairement affecté sur une voie de camionnage. L'agent immobilier qui met en évidence des opportunités fugaces avant tout le monde. L'arbitre qui profite des différences de prix locales personne n'a encore remarqué. Chacun possède des connaissances qui, comme Hayek l'a dit, ne peuvent par nature entrer dans les statistiques et ne peuvent donc être transmises à aucune autorité centrale sous forme statistique.
C'est le problème de la connaissance. Pas une pénurie d'information, mais une reconnaissance que l'information la plus importante résiste à la centralisation.
Il décrit également, presque parfaitement, ce qui s'est passé dans les plus grands systèmes logiciels du monde.
La connaissance verrouillée dans le code d'exécution
Les systèmes COBOL d'ordinateur central traitent chaque jour des milliards de dollars de transactions. Ils ont été construits au fil des décennies par des milliers de développeurs, chacun répondant à leurs propres circonstances particulières : un changement réglementaire, un incident de production un mardi soir, une plainte de client au sujet d'une erreur d'arrondi dans l'intérêt trimestriel.
Personne n'a conçu ces systèmes dans leur ensemble. Ils ont grandi. Coucher par calque, patcher par patch, chaque développeur a apporté des connaissances locales à une base de code partagée. Les règles commerciales régissant l'approbation des transactions, le calcul des intérêts, le traitement des exceptions et les transitions de l'état des comptes étaient rarement rédigées de façon claire. Ils étaient intégrés dans le code, la disposition des données, les conventions d'appel, les habitudes opérationnelles et les correctifs de production. Alors que les auteurs originaux prennent leur retraite, une bonne partie de ces connaissances prennent leur retraite.
C'est le problème de connaissance de Hayek, rendu exécutable.
Les connaissances sont trop réparties entre des millions de lignes de code, trop implicites dans les interactions de programmes, et trop dépendantes de données et d'états spécifiques pour être capturées par une personne ou un document. Personne ne comprend tout. Le système le fait. Et pourtant ça marche. Chaque jour, elle traite les bonnes transactions, applique les bonnes règles et produit les bons résultats.
Pourquoi l'approche standard échoue
L'approche conventionnelle de la modernisation de l'ordinateur central est, en termes hayekien, une forme de planification centrale. Embaucher une grande équipe de consultants. Lisez le code. Documenter les règles commerciales. Réécrire le système à partir de la documentation.
Cela échoue pour la même raison que la planification centrale. L'abstraction perd les détails mêmes qui comptent.
Un consultant litSI WS-FICO-SCORE < 300et écrit : « Les scores de FICO inférieurs à 300 sont rejetés. Mais la vraie connaissance n'est pas dans cette phrase. Il est dans le comportement du système dans des conditions réelles. Que se passe-t-il quand cette vérification échoue à mi-chemin d'une transaction? Que se passe-t-il lorsque la zone de communication contient un état particulier? Que se passe-t-il lorsqu'un curseur est positionné sur un enregistrement spécifique et qu'un chemin d'exception est déclenché deux programmes plus tard? C'est là que vit la vraie règle.
La connaissance vit en partie dans le code, mais surtout dans le comportement du système en cours d'exécution sous contrainte.
Une réponse commune mais naïve est: pouvez-vous juste pointer une frontière LLM au COBOL et demander ce qu'il fait? Un LLM frontalier pointé sur un fichier COBOL peut souvent vous dire ce qu'un paragraphe semble faire isolément. Il ne peut pas vous dire de façon fiable ce qui se passe lorsque dix-sept programmes interagissent au moyen de tampons d'octets partagés, de zones de communication interprogrammes, de limites de transaction et de données en forme de production. La lecture ne suffit pas. Les connaissances importantes s'expriment par l'exécution.
Construire l'environnement, laisser l'IA explorer
L'alternative consiste donc à reproduire l'environnement dans lequel ces connaissances sont exprimées.
Plutôt que de demander aux humains de lire le code et de reconstruire les règles, vous construisez une réplique fidèle et instrumentée du système hérité : celle qui se comporte comme l'original mais fonctionne dans un environnement où chaque branche, chaque mutation, chaque état intermédiaire et chaque interaction peuvent être observés. Ensuite, vous laissez l'IA opérer dans cet environnement, en formant des hypothèses, en exécutant des expériences, en observant les résultats et en révisant sa compréhension.
C'est une orientation fondamentalement différente. Arrête de traiter la compréhension comme une tâche de lecture. Au lieu de cela, vous construisez un monde dans lequel la compréhension peut être découverte par l'interaction.
Dans uneessai précédent, J'ai soutenu que la leçon Bitter de Rich Sutton [6] s'applique à la compréhension de code. Les méthodes générales de calcul ont tendance à surperformer les méthodes construites autour d'abstractions réalisées par l'homme. Résumation, RAG, ontologies conçues manuellement, graphiques de connaissances : ce sont tous des tentatives de compresser la compréhension à travers des heuristiques qui travaillent jusqu'à un point, puis se cassent à une échelle et une complexité suffisantes. Voici la leçon Bitter appliquée à la modernisation.
Ne pas construire des systèmes de compression toujours plus clever pour la connaissance tacite. Construisez l'environnement dans lequel ces connaissances s'expriment et laissez faire l'exploration – en utilisant des méthodes générales comme la recherche et l'apprentissage.
Dans la pratique, cela signifie construire un jumeau comportemental de l'ancien système et donner aux agents d'IA les outils pour interagir avec lui: naviguer des écrans, envoyer des entrées, inspecter des données, observer des traces d'exécution, comparer des résultats et tester des conjectures sur la logique d'affaires contre le comportement réel du système.
Est-ce que c'est juste des tests dans des vêtements plus fantaisistes ? Pas vraiment. Les essais commencent par une spécification et vérifient si le système le satisfait. Cela commence sans spécification et essaie de le découvrir. La direction est inversée. Elle est plus proche de la méthode scientifique que de l'AQ.
Pourquoi construire le jumeau au lieu de lire le code ?
A première vue, construire une réplique fidèle sonne encore plus difficile que comprendre le code directement. Dans un sens, ça l'est. Mais c'est un autre genre de dur.
La lecture d'un grand système hérité et la reconstruction de son vrai comportement est un problème de jugement. Cela dépend de l'interprétation, du contexte tacite et de l'effort humain héroïque. Construire un jumeau fidèle est un problème d'ingénierie. Le but est de faire de la fidélité une propriété du système que vous construisez, pas un sous-produit de l'intuition de quelqu'un.
Cela signifie traduire le système hérité en une représentation dont le comportement peut être vérifié systématiquement, puis resserrer l'équivalence par des méthodes formelles et une validation différentielle continue. Exécutez les mêmes entrées à travers le système original et le jumeau. Comparer les sorties, les traces et les effets secondaires. Là où ils divergent, comblez l'écart. Avec le temps, vous transformez la fidélité en quelque chose de mesurable.
Cela est important parce qu'une fois l'infrastructure existante, chaque nouveau système devient explorable par la construction. Nous commercialisons un procédé fragile, manuel, irréductiblement contextuel pour un procédé basé sur l'ingénierie répétable.
Les laboratoires d'IA comprennent déjà le modèle
Une des leçons les plus claires de l'IA moderne est que les environnements battent les ensembles de données statiques.
DeepMind n'a pas atteint le surhumain Allez en construisant une base de données géante de commentaires d'experts. Ils ont construit un moteur de jeu et laisser l'agent apprendre en agissant en son sein. Lorsque AlphaGo Zero [2] a retiré entièrement les données du jeu humain et appris par l'auto-jouage, il a dépassé le système précédent. L'environnement était le programme.
Le même modèle apparaît ailleurs. SWE-bench [4] évalue les agents de codage dans les dépôts réels où ils peuvent inspecter le code, faire des modifications et exécuter des tests. WebArena [5] évalue les agents Web à l'intérieur des applications Web fonctionnant plutôt que les ensembles de données statiques des traces du navigateur. Les grands laboratoires se sont tous tournés vers des systèmes informatiques où le modèle exploite une véritable interface avec des captures d'écran, des mouvements de souris et des actions de clavier. Dans chaque cas, la capacité vient non seulement de plus de données, mais aussi d'agir à l'intérieur d'un monde structuré qui produit de la rétroaction.
Le modèle est déjà visible : si vous voulez qu'un système maîtrise un domaine, les descriptions sont souvent un mauvais substitut au domaine lui-même.
Ce principe s'applique autant aux logiciels d'entreprise qu'aux jeux, aux dépôts de code ou aux navigateurs.
Si vous voulez que l'IA comprenne un système bancaire vieux de quarante ans, ne pas simplement lui remettre des fichiers sources et demander un résumé. Donnez-lui un environnement où opérer.
La fidélité est tout le jeu
Bien sûr, cela ne fonctionne que si la réplique est fidèle. Si le jumeau diverge du système réel, la compréhension extraite sera erronée.
C'est pourquoi la vérification n'est pas seulement un bon à avoir, mais tout le jeu.
Le jumeau doit être validé en continu par rapport au système original par exécution parallèle. Les mêmes entrées devraient produire les mêmes sorties, les mêmes transitions d'état clés et le même comportement observable. Chaque écart est utile. Elle révèle où le modèle du système est incomplet et où l'environnement doit devenir plus précis.
Fait correctement, l'environnement devient un instrument progressivement plus tranchant pour extraire la compréhension.
C'est ce que nous construisons chez Hypercubic : pas des outils de documentation, pas des plates-formes d'analyse de code statique, mais des environnements fidèles et explorables où l'IA peut découvrir les connaissances qui n'ont jamais été écrites.
Nous aurons bientôt beaucoup plus à dire sur les détails.
Références
- Hayek, F.A. (1945).Utilisation des connaissances dans la société. American Economic Review, 35(4), 519-530.
- Silver, D. et al. (2017).Maîtriser le jeu de Go sans connaissance humaine.Nature, 550, 354-359.
- Équipe d'apprentissage ouverte, DeepMind. (2021).L'apprentissage ouvert conduit à des agents généralement capables.
- Jimenez, C.E. et al. (2023).SWE-bench: Les modèles linguistiques peuvent-ils résoudre les problèmes GitHub du monde réel?
- Zhou, S. et al. (2023).WebArena: Un environnement web réaliste pour la construction d'agents autonomes.
- Sutton, R. (2019).La leçon amère.