La bibliothèque de Karpathy et le biais non audité
Andrej Karpathy, l'un des architectes intellectuels les plus influents du mouvement d'intelligence artificielle moderne, a récemment publié une proposition qui fait son chemin parmi les équipes d'ingénierie et les leaders de produit : une architecture alternative aux systèmes RAG (Retrieval-Augmented Generation) qu'il appelle 'LLM Knowledge Base'. L'idée centrale est de remplacer les bases de données vectorielles et les processus de récupération dynamique par une bibliothèque de fichiers markdown qu'un modèle de langage maintient, met à jour et organise de manière autonome au fil du temps.
C'est une proposition techniquement élégante. Elle réduit la latence, élimine la complexité des index vectoriels et génère un répertoire de connaissances qui devient plus cohérent avec l'utilisation. Pour toute équipe ayant lutté avec des pipelines RAG instables, cela semble être un soulagement immédiat.
Mais il existe une question que les équipes d'ingénierie formulent rarement avant d'implémenter une nouvelle architecture, et que les directions ne formulent jamais ensuite : qui a défini le corpus initial et selon quels critères de pertinence ?
L'architecture élégante qui cache une décision politique
Une bibliothèque de markdown maintenue par IA n'est pas neutre par définition. Tout système de connaissance commence par un acte éditorial : quelqu'un décide quels documents entrent en premier, quelles sources sont autorisées, quels sujets méritent un archivage propre et lesquels sont subsumés sous d'autres. Cette décision initiale n'est pas technique. Elle est profondément politique dans le sens organisationnel du terme : elle reflète la hiérarchie des valeurs, les angles morts et les priorités de ceux qui l'ont prise.
Ce que propose Karpathy est de sophistiquer et d'automatiser la couche de mise à jour, mais cela ne résout pas le problème d'origine. Le modèle apprendra à maintenir la cohérence de ce qui était déjà biaisé depuis le début. Un fichier markdown qui décrit "comment fonctionne le client typique" écrit par une équipe homogène d'ingénieurs à San Francisco codifie une vision particulière de qui est ce client, quelle langue il parle, quel appareil il utilise, quel niveau d'alphabétisation numérique il possède et à quelle tranche horaire il opère. Le modèle le mettra à jour avec diligence. Ce qu'il ne fera pas, c'est le remettre en question.
Il ne s'agit pas d'une critique à l'égard de Karpathy ni de l'architecture elle-même. C'est un diagnostic de l'écart qui existe entre l'excellence technique et la robustesse organisationnelle. Les équipes qui implémentent cette solution sans auditer le corpus fondateur construisent une mémoire institutionnelle qui amplifie leurs propres limitations perceptuelles à grande échelle, à la vitesse que l'automatisation permet.
L'ironie opérationnelle est que plus le système est efficace pour maintenir la bibliothèque, plus il consolidera rapidement ces biais comme vérité de référence.
Le coût réel d'une mémoire corporative homogène
Il existe suffisamment de preuves pour affirmer que les équipes dirigeantes avec une faible diversité d'origine et de perspective prennent des décisions avec des angles morts systématiques, et non occasionnels. McKinsey, dans ses études sur la diversité au sein des équipes de direction, a documenté des corrélations entre homogénéité et capacité réduite d'anticipation sur les marchés émergents. Mais ce qui est plus pertinent pour cette analyse, c'est le mécanisme, non la statistique.
Lorsque une équipe homogène construit une base de connaissance institutionnelle — que ce soit en markdown, dans une wiki d'entreprise ou lors de l'intégration de nouveaux employés — ce qu'elle produit est une codification de son modèle mental partagé. C'est précisément le contraire de ce dont une organisation a besoin pour détecter des disruptions. Les disruptions viennent des marges : d'utilisateurs que le produit n'a pas pris en compte, de marchés qui semblaient secondaires, de besoins que l'équipe n'a jamais eu parce qu'elle ne les a jamais vécu.
Une bibliothèque de connaissance maintenue par IA qui part de ce corpus homogène ne résout non seulement pas le problème : elle l'institutionnalise avec une couche d'automatisation qui lui donne une apparence d'objectivité. Les documents sont bien écrits, la structure est cohérente, le modèle les met à jour avec constance. Tout semble rigoureux. Mais la question de savoir quels marchés, quels utilisateurs et quels cas d'utilisation ont été exclus de l'index depuis le premier jour reste sans réponse.
Le risque financier concret est que l'organisation construise des décisions de produit, d'expansion et d'attention client sur une base de connaissances qui exclut systématiquement les segments à fort potentiel de croissance : précisément ceux que l'entreprise ne comprend pas encore bien.
Ce que la proposition ouvre pour ceux qui savent lire
Réduire cette analyse à une simple mise en garde serait une erreur. L'architecture que Karpathy décrit a un potentiel organisationnel qui va au-delà de l'optimisation technique, à condition que les leaders interviennent au niveau de la couche que les ingénieurs tendent à considérer comme résolue.
Une bibliothèque de markdown maintenue par IA est, en essence, une mémoire institutionnelle vivante. Si le corpus fondateur est construit avec une diversité de perspectives délibérée — équipes de marchés émergents, utilisateurs de contextes à faible bande passante, opérateurs parlant des langues autres que l'anglais, voix de la périphérie organisationnelle et non seulement du centre — alors le système a la capacité de maintenir cette richesse actualisée et cohérente au fil du temps. Cela est quelque chose que aucune wiki d'entreprise traditionnelle ne parvient à réaliser car elle dépend de l'effort volontaire de ceux qui ont le moins d'incitation à documenter.
L'argument commercial est direct : une base de connaissances qui représente la complexité réelle des marchés où l'entreprise opère prend de meilleures décisions à moindre coût opérationnel qu'une qui ne représente que la perspective de l'équipe fondatrice. Non pas parce qu'elle est plus juste, mais parce qu'elle intègre davantage d'informations pertinentes dans sa structure.
L'intervention que la direction doit exiger avant d'approuver toute implémentation de cette architecture est simple et ne requiert aucune expertise technique : un inventaire de qui a contribué aux documents fondateurs, quelles géographies ils représentent, quelles langues sont présentes dans le corpus de référence et quels types d'utilisateurs ont été considérés dans les cas d'utilisation documentés. Si cette liste est courte et homogène, la décision d'investissement doit être conditionnée à son élargissement avant la mise en œuvre.
La table de design comme variable de risque
L'industrie a tendance à évaluer les architectures d'IA selon des benchmarks techniques : latence, précision de récupération, cohérence sémantique, coût par appel. Ce sont des métriques légitimes et nécessaires. Mais il existe une variable qui n'apparaît dans aucun benchmark et qui détermine l'utilité réelle du système à long terme : la composition de l'équipe qui a pris les décisions de design.
Un système RAG avec une précision de récupération élevée construit sur un corpus biaisé récupère des informations biaisées avec une grande efficacité. Une bibliothèque de markdown impeccablement organisée qui ne documente que l'expérience d'un sous-ensemble d'utilisateurs fournit des réponses cohérentes pour ce sous-ensemble et échoue silencieusement pour le reste. L'échec silencieux est le plus dangereux car il ne génère pas d'alerte : le système répond, l'équipe suppose que cela fonctionne, et l'organisation continue de prendre des décisions sur des informations incomplètes sans le savoir.
La proposition de Karpathy mérite une attention technique et mérite d'être mise en œuvre. Mais elle mérite également que les leaders qui l'approuvent comprennent qu'ils prennent une décision sur l'architecture de connaissance institutionnelle, pas seulement sur l'infrastructure logicielle. Cette distinction change qui doit être dans la salle lors de la définition du corpus initial, et change les critères avec lesquels on évalue le succès du système six mois après son lancement.
Les conseils qui approuvent cet investissement sans auditer la diversité des perspectives autour de la table de design paient pour une mémoire institutionnelle qui se souviendra, avec grande efficacité, exactement de ce que leur équipe la plus homogène savait déjà.
