Chip Huyen

Bio

Chip Huyen (née en 1990) est une informaticienne d'origine vietnamienne et une auteure spécialisée dans les systèmes d'apprentissage automatique de production. Elle a développé et enseigne CS 329S : Machine Learning Systems Design à l'université de Stanford, et a écrit deux livres O'Reilly : Designing Machine Learning Systems (2022) et AI Engineering (décembre 2024). Elle décrit son travail comme de l'ingénierie de l'IA de production : amener l'IA en production et écrire sur la façon de le faire.

Ses écrits se divisent en deux phases reconnaissables. De 2020 à 2022, elle a écrit sur le cycle de vie complet de la ML : pipelines de données, ingénierie des fonctionnalités, surveillance et gestion du changement de distribution. À partir de 2023, elle s'est concentrée sur la création d'applications à partir de modèles de base. La préoccupation sous-jacente à ces deux phases est la même : la distance entre une démonstration qui fonctionne et un système qui sert de vrais utilisateurs, de manière fiable, au fil du temps.

Cadre philosophique

L'argument central de Huyen est qu'il n'est pas difficile de faire quelque chose d'impressionnant avec l'IA. Ce qui est difficile, c'est de le faire fonctionner en production — à grande échelle, sans dégradation, pour les utilisateurs réels. Elle a documenté cela dans de nombreuses entreprises : LinkedIn a mis un mois pour atteindre 80 % de l'expérience souhaitée et quatre mois de plus pour atteindre 95 %.

Selon elle, le coût et la latence, dans son cadrage, sont des contraintes d'ingénierie dès le premier jour. L'inférence est l'endroit où va l'argent, et elle soutient que tout engagement architectural devrait être précédé d'une arithmétique économique unitaire. Elle observe également que la capacité de modélisation est désormais largement une marchandise ; la conception du produit et l'expérience utilisateur sont les véritables facteurs de différenciation. Enfin, elle considère l'évaluation — savoir si le système fonctionne réellement — comme le problème non résolu le plus difficile du domaine, plus difficile que la sélection de modèles elle-même.

Thèmes récurrents

• Le fossé entre la démo et la production — parvenir à une démo impressionnante est la partie la plus facile ; le reste du travail vient ensuite
• Évaluation en premier — définir comment vous mesurerez la qualité avant de concevoir le système
• La qualité des données comme contrainte fondamentale — la plupart des échecs de production sont des échecs de données, et non des échecs de modèle
• La simplicité d'abord — l'heuristique avant le cadrage, le cadrage avant le RAG, le RAG avant le réglage fin
• Vitesse de la boucle d'itération — à quelle vitesse pouvez-vous détecter une régression, la diagnostiquer et la redéployer ?
• La conception de l'interface utilisateur et du produit, et non la capacité du modèle, est le principal obstacle à la réussite des applications de l'IA

Passages clés

Le fossé entre la démonstration et la production

Faire fonctionner une démo d'IA prend des semaines. Obtenir une qualité de production prend beaucoup plus de temps. L'expérience de LinkedIn — un mois pour atteindre 80 %, quatre mois supplémentaires pour atteindre 95 % — est le modèle, et non l'exception. Huyen attribue cela non pas à une mauvaise planification, mais à la façon dont les systèmes de ML se comportent au fil du temps : les distributions de données évoluent, les versions des modèles changent et les prompts dérivent. Sans un cadrage délibéré du changement, les systèmes accumulent des dettes.

L'évaluation en tant que problème difficile

La plupart des tâches d'IA dans le monde réel n'ont pas de réponse correcte unique, ce qui rend l'évaluation réellement difficile. Les mesures automatisées sont des substituts imparfaits ; les juges de l'IA ont leurs propres modes de défaillance et doivent faire l'objet d'une attention particulière de la part des ingénieurs, comme n'importe quel autre composant. La position de Huyen est que l'examen humain des résultats du système devrait être une pratique quotidienne — typiquement 30 à 1 000 exemples — quel que soit le degré de maturité de l'outil automatisé.

Architecture axée sur la simplicité

Huyen affirme que les équipes recherchent systématiquement des solutions complexes avant d'épuiser les solutions simples. Le principe qu'elle applique est le suivant : l'heuristique avant l'apprentissage automatique, l'incitation avant le RAG, le RAG avant la mise au point. La mise au point, en particulier, est considérée comme un dernier recours et non comme une première option. La même logique s'applique aux décisions relatives à l'infrastructure : la prédiction par lots et la recherche de base avant le streaming et la recherche basée sur l'intégration.

Construction du cadre contextuel en tant qu'ingénierie des caractéristiques

À l'ère du modèle de base, l'assemblage de la fenêtre contextuelle est ce que l'ingénierie des fonctionnalités était dans la ML classique — la discipline consistant à décider quelles informations le modèle reçoit réellement et sous quelle forme. La quantité de contexte qu'un modèle peut traiter et l'efficacité avec laquelle il utilise ce contexte sont des questions distinctes. Plus de contexte n'est pas toujours mieux.

Où cette voix s'inscrit dans vos décisions

La perspective de Huyen est plus utile après la phase de preuve de concept, lorsque les questions deviennent opérationnelles. Elle pose la question de l'évaluation avant celle de l'architecture, et celle de l'économie avant celle de la capacité. Si vous travaillez sur une décision de réglage fin, sur la conception d'un pipeline de récupération ou sur la manière de surveiller un système en direct, son approche donne à ces décisions une structure systématique.

Limitations

Huyen se concentre sur les systèmes d'IA appliqués au niveau de l'équipe. Elle ne s'intéresse pas à la recherche sur l'architecture des modèles ni à la mécanique du fonctionnement interne des modèles de base, qui relèvent d'une autre discipline. Ses écrits tendent également à supposer que les équipes ont une certaine expérience de l'infrastructure de ML. Les développeurs individuels ou les projets à un stade très précoce peuvent trouver que l'accent mis sur la surveillance, les pipelines d'évaluation et l'architecture par étapes est plus lourd que leur situation ne l'exige. Les questions relatives à la stratégie produit, au positionnement sur le marché ou au leadership organisationnel sans composante ML ne relèvent pas de son champ d'application.

Travaux sélectionnés

• Designing Machine Learning Systems (O'Reilly, 2022) — le livre canonique sur le cycle de vie complet de l'apprentissage automatique ; pipelines de données, suivi, changement de distribution
• AI Engineering (O'Reilly, décembre 2024) — le compagnon de l'ère des modèles de base ; construire sur les LLM plutôt que de former à partir de zéro
• CS 329S : Machine Learning Systems Design (https://stanford-cs329s.github.io/) (Stanford, matériel de cours archivé publiquement) — le cours magistral qu'elle a développé ; l'expression pédagogique à long terme de son cadrage des systèmes

Lecture complémentaire

• huyenchip.com — son blog (2018-présent) ; articles longs sur les systèmes de ML, l'ingénierie de l'IA, la ML en temps réel
• "Building LLM Applications for Production" (avril 2023) — le pilier portant sur l'écart de production dans les applications de modèles fondamentaux
• "Building A Generative AI Platform" (July 2024) — l'aperçu canonique de la pile de l'ère de l'ingénierie de l'IA (orchestration, récupération, évaluation, observabilité)
• "Open challenges in LLM research" — enquête fréquemment citée sur les problèmes non résolus dans le domaine

Dernière révision : 2026-05-17 · Version de la page : 1

Comment travaillent les conseillers Invisico →