Je pensais moi aussi à la question du coût, et il semble en effet qu’il varie fortement selon la résolution des images d’entrée. Et je n’avais même pas pensé au lien entre la taille de l’image d’entrée et la vitesse de traitement ; c’est assez fascinant. Donc le recadrage permet aussi d’accélérer le traitement.
Et l’amélioration de la précision est vraiment impressionnante !
Les performances des VLM se sont beaucoup améliorées, mais malgré cela, est-ce qu’elles ne dépassent toujours pas, pour l’instant, celles d’un modèle YOLO entraîné pour un objectif unique ?
Merci d’avoir pris le temps de consigner par écrit le savoir-faire acquis en situation réelle.
Si je rencontre un problème similaire, je ne manquerai pas de m’inspirer des méthodes que vous avez utilisées.
Moi aussi, c’est quelque chose que je ressens souvent en ce moment..
Je me dis que beaucoup d’articles de blog sont probablement écrits à partir de l’expérience personnelle de leur auteur + avec l’aide de l’IA.
Les textes sont trop bien structurés et trop faciles à lire.
1) Doutes sur la crédibilité du texte : ça sent le marketing / le contenu généré par IA
En bref
« C’est trop bien ficelé, presque comme une fable morale » → certains soupçonnent un texte optimisé pour le type de “morality play” que HN adore
Le corps de l’article est truffé de liens vers des ressources payantes, d’où un fort courant d’opinion : « au fond, ce n’est pas juste un texte commercial ? »
Le style avec avalanche de listes et emojis est aussi pointé comme un signal d’« AI slop » (contenu IA bâclé)
Citation qui démonte tout (traduite)
« On dirait que tout le texte est là juste pour vendre les ressources mises en lien. Et avec toutes ces listes, ça fait vraiment AI slop. »
(Original : Seems like the whole thing is just there to sell you on the linked resources. And it feels like AI slop with all the lists.)
Verdict en une ligne
Avant même de savoir si le fond est juste ou faux, la première réaction a été : ça sent trop fort la vente + l’IA.
2) Critique du leadership / des architectes : le problème n’était pas la techno, mais la structure de décision
En bref
Beaucoup ont réagi par : « un architecte pour une équipe de 4 personnes ? » — pour eux, ça partait déjà de travers
En particulier, la figure de l’architecte qui ne code pas / du rôle DevOps séparé est souvent vue comme un goulot d’étranglement + une optimisation de CV
Le ton général n’est pas “les microservices ont tout cassé”, mais plutôt : “c’est une organisation où personne n’assume vraiment le déploiement, l’exploitation ou la gestion de crise qui a coulé la boîte”
Citation qui pique (traduite)
« Des architectes dont le boulot est de définir des “règles” et des “patterns” sans rien implémenter eux-mêmes, c’est presque toujours une très mauvaise idée. Concentrez-vous juste sur la mise en production... Si quelqu’un qui n’écrira même pas 10 lignes de code monopolise les décisions, c’est la catastrophe. »
(Original : Architects who's job it is to define 'rules' and 'patterns' without actually implementing anything are almost always a bad idea. Just focus on shipping...)
Verdict en une ligne
Pour beaucoup, le vrai problème n’était pas le MSA, mais une conception des rôles où il y a du pouvoir de décision sans responsabilité réelle.
3) Angle business : est-ce que le MSA a vraiment causé l’échec de la startup ?
En bref
Certains commentaires ne croient pas du tout au cadrage “l’architecture a tué la startup”
Leur idée centrale : si le PMF / la demande / la rétention client sont faibles, n’importe quelle stack peut mener dans le mur
En particulier, des détails comme « les clients partent immédiatement parce que le service est plus lent pendant deux jours ? » servent à sous-entendre que la valeur produit était peut-être faible dès le départ
Ils pointent aussi une contradiction interne du texte : on te dit “le MSA a tué la startup”, puis la conclusion devient “mais elle a survécu ?” → d’où un soupçon d’exagération narrative
Citation qui démonte tout (traduite)
« Je suis à peu près sûr que ce qui a tué votre startup, c’est d’avoir construit un produit dont personne ne voulait. C’est aussi absurde que de dire que choisir Python plutôt que Go a tué votre startup. »
(Original : Pretty sure making a product that people don’t want killed your startup. This is like saying using Python vs Go killed your startup...)
Verdict en une ligne
Il y avait clairement ce point de vue : l’architecture peut servir d’excuse, alors que la vraie cause est peut-être le marché, le produit ou la trésorerie.
4) Enseignements techniques : conseils utiles issus de l’expérience monolithe vs MSA
En bref
« Le MSA a une taxe de coûts fixes (complexité opérationnelle) » → beaucoup de retours d’expérience disent que cela peut être fatal pour une petite équipe
Mots-clés récurrents : premature distribution (distribution trop précoce), monolithe modulaire / modulith, et l’idée de “gagner” ses frontières (boundaries)
Les conditions dans lesquelles le MSA devient réellement nécessaire sont aussi formulées de manière réaliste : quand la taille de l’équipe augmente et que les conflits, les problèmes de déploiement ou les frictions organisationnelles apparaissent pour de vrai
À l’inverse, sur les problèmes de performance ou de montée en charge, certains conseillent de regarder d’abord les algorithmes, les goulots d’étranglement, le sharding ou le partitionnement, plutôt que de dire immédiatement “passons aux microservices”
Citation qui pique (traduite)
« Ce ne sont pas les microservices qui ont tué la startup, c’est la distribution trop précoce. Vous avez découpé avant que de vraies frontières n’existent, et vous n’avez récolté que de la latence et des coûts de coordination. Commencez par un monolithe modulaire, gagnez vos frontières, puis extrayez. »
(Original : Premature distribution killed the startup, not microservices... Start with a modular monolith, earn your boundaries, then extract.)
Verdict en une ligne
La leçon qui a vraiment fait consensus dans la communauté, c’était : « Commencez par un monolithe, et ne séparez en services que lorsque les frontières apparaissent naturellement. »
Bilan global de la communauté en une phrase
La plupart étaient d’accord avec l’idée “nous ne sommes pas Netflix”, mais en même temps, la suspicion était forte que ce texte lui-même vende une narration de “maladie de Netflix” — autrement dit du marketing / du contenu IA.
L’expression « conversion en problème de structure » était peut-être un peu abstraite.
Ce que je voulais dire dans l’article, c’est :
Before: "labellisation = intervention humaine = coût proportionnel"
After: "labellisation = pipeline = coûts variables minimisés après la mise en place initiale"
Autrement dit, j’ai transformé un problème de coût ponctuel en problème de construction de système.
La formulation « créer un nouveau modèle de travail » est également juste !
Plus précisément, on peut dire que j’ai « remplacé le travail humain par un pipeline logiciel » haha
Bonjour, merci d’avoir lu l’article avec intérêt !
Je comprends tout à fait le point que vous soulevez. Vous avez raison : le VLM est plus performant que YOLO, et des erreurs de YOLO peuvent entraîner la perte d’informations importantes. Cela dit, nous avons ajouté l’étape de crop pour les raisons suivantes.
Premièrement, il y a la question du coût. Si l’on envoie directement l’image entière au VLM, le traitement d’images haute résolution fait grimper les coûts de manière brutale. C’était la principale raison de l’introduction du crop.
Deuxièmement, il y a la question de la vitesse de traitement.
Pour traiter de grands jeux de données dans un délai réaliste, ce gain de vitesse était indispensable.
Troisièmement, il y a l’amélioration de la précision.
Le crop améliore en réalité la précision de jugement du VLM. Une image complète peut contenir un arrière-plan complexe, plusieurs personnages, du texte, des éléments décoratifs, etc., ce qui peut perturber le VLM sur l’objet à évaluer. Par exemple, il peut devenir difficile de savoir s’il s’agit d’un personnage sur une affiche en arrière-plan, de la figurine principale ou d’un autre personnage placé à côté. À l’inverse, avec le crop, seul l’objet cible est clairement isolé, ce qui permet au VLM de se concentrer uniquement sur cet objet pour prendre sa décision.
Bien sûr, les problèmes de non-détection ou de faux positifs de YOLO ne sont pas entièrement résolus. Cependant, nous avons atténué ce problème en fixant le confidence threshold de YOLO à 0.5 afin d’augmenter le recall, puis en éliminant les faux positifs aux étapes suivantes de filtrage CLIP et de vérification par Verifier. De plus, comme nous traitons de très grands volumes de données, même s’il subsiste quelques non-détections, nous pouvions tout de même obtenir statistiquement une quantité suffisante de données de haute qualité.
En définitive, l’objectif était de construire une pipeline pratique en trouvant un équilibre entre coût, vitesse et précision, et l’étape de crop a eu des effets positifs sur ces trois aspects.
Bonjour winterjung, merci de l’intérêt que vous portez à mon travail. Pour la fiabilité, j’utilise la valeur de confidence renvoyée directement par le VLM (GPT-4o). Comme vous l’avez indiqué, il y a une limite au fait que la base de calcul de la confidence de GPT-4o n’est pas claire et qu’elle n’est pas reproductible. Mais d’un point de vue pratique, en partant de l’hypothèse que la confidence renvoyée par le VLM est raisonnablement précise, j’ai implémenté le système de façon à décider, lors de la dernière étape de vérification (Verifier), s’il faut valider ou non sur la base d’un threshold.
Je ne savais absolument pas que les tokens d’entrée image du modèle got-4o-mini étaient excessivement chers, merci de me l’avoir signalé. Je l’ai immédiatement intégré au code haha
Oui, c’est en fait un article qui explique l’architecture pour montrer comment le produit est réellement construit.
J’en ai profité pour mettre cet article au propre en stabilisant la version 1.0 et en organisant la documentation.
Passer carrément au langage C3 est aussi une bonne idée. Comme il reprend la syntaxe du C avec un minimum de changements tout en ajoutant des fonctionnalités modernes, la migration est aussi facile.
Vous n’aurez sans doute pas envie de cliquer en voyant le titre… mais c’est, parmi les articles sur les relations entre les États-Unis et la Chine que j’ai lus récemment, celui que j’ai trouvé le plus intéressant.
C’est un billet publié sur Hacker News. La plupart des articles que je publie viennent de Hacker News.
https://news.ycombinator.com/item?id=46469845
Comme vous l’avez dit... je devrais effectivement ajouter la référence Hacker News.
Ça paraît chaque année en novembre, mais cette fois je le partage un peu tard.
Prévisions technologiques du CTO d’Amazon pour après 2025
Prévisions technologiques du CTO d’Amazon pour après 2024
Prévisions technologiques du CTO d’Amazon pour après 2023
Prévisions technologiques du CTO d’Amazon pour après 2022
Ce que je voulais dire, c’est que ce texte fait très IA et ne cite aucune référence, donc je préférerais qu’il ne soit pas partagé.
C’est excellent ^^
Merci pour votre réponse.
Je pensais moi aussi à la question du coût, et il semble en effet qu’il varie fortement selon la résolution des images d’entrée. Et je n’avais même pas pensé au lien entre la taille de l’image d’entrée et la vitesse de traitement ; c’est assez fascinant. Donc le recadrage permet aussi d’accélérer le traitement.
Et l’amélioration de la précision est vraiment impressionnante !
Les performances des VLM se sont beaucoup améliorées, mais malgré cela, est-ce qu’elles ne dépassent toujours pas, pour l’instant, celles d’un modèle YOLO entraîné pour un objectif unique ?
Merci d’avoir pris le temps de consigner par écrit le savoir-faire acquis en situation réelle.
Si je rencontre un problème similaire, je ne manquerai pas de m’inspirer des méthodes que vous avez utilisées.
Moi aussi, c’est quelque chose que je ressens souvent en ce moment..
Je me dis que beaucoup d’articles de blog sont probablement écrits à partir de l’expérience personnelle de leur auteur + avec l’aide de l’IA.
Les textes sont trop bien structurés et trop faciles à lire.
Euh... il y a quelque chose qui cloche, je trouve.
On dirait que cet article a été écrit par une IA.
1) Doutes sur la crédibilité du texte : ça sent le marketing / le contenu généré par IA
En bref
Citation qui démonte tout (traduite)
Verdict en une ligne
2) Critique du leadership / des architectes : le problème n’était pas la techno, mais la structure de décision
En bref
Citation qui pique (traduite)
Verdict en une ligne
3) Angle business : est-ce que le MSA a vraiment causé l’échec de la startup ?
En bref
Citation qui démonte tout (traduite)
Verdict en une ligne
4) Enseignements techniques : conseils utiles issus de l’expérience monolithe vs MSA
En bref
Citation qui pique (traduite)
Verdict en une ligne
« Commencez par un monolithe, et ne séparez en services que lorsque les frontières apparaissent naturellement. »
Bilan global de la communauté en une phrase
La plupart étaient d’accord avec l’idée “nous ne sommes pas Netflix”, mais en même temps, la suspicion était forte que ce texte lui-même vende une narration de “maladie de Netflix” — autrement dit du marketing / du contenu IA.
Parce que les États-Unis ont encore suffisamment d’IPv4. C’est aussi le cas chez nous.
Les routeurs ipTIME ne prennent pas en charge IPv6, n’est-ce pas ?
Quand on voit le prix de l'IPv4, on ne peut que pousser un soupir, mais c'est suffisant...
C’est plus utilisable qu’on ne le pense, mais comme le support tiers est meilleur sur Mac, on finit par ne pas l’utiliser.. haha
Merci pour cette excellente remarque !
L’expression « conversion en problème de structure » était peut-être un peu abstraite.
Ce que je voulais dire dans l’article, c’est :
Before: "labellisation = intervention humaine = coût proportionnel"
After: "labellisation = pipeline = coûts variables minimisés après la mise en place initiale"
Autrement dit, j’ai transformé un problème de coût ponctuel en problème de construction de système.
La formulation « créer un nouveau modèle de travail » est également juste !
Plus précisément, on peut dire que j’ai « remplacé le travail humain par un pipeline logiciel » haha
Bonjour, merci d’avoir lu l’article avec intérêt !
Je comprends tout à fait le point que vous soulevez. Vous avez raison : le VLM est plus performant que YOLO, et des erreurs de YOLO peuvent entraîner la perte d’informations importantes. Cela dit, nous avons ajouté l’étape de crop pour les raisons suivantes.
Premièrement, il y a la question du coût. Si l’on envoie directement l’image entière au VLM, le traitement d’images haute résolution fait grimper les coûts de manière brutale. C’était la principale raison de l’introduction du crop.
Deuxièmement, il y a la question de la vitesse de traitement.
Pour traiter de grands jeux de données dans un délai réaliste, ce gain de vitesse était indispensable.
Troisièmement, il y a l’amélioration de la précision.
Le crop améliore en réalité la précision de jugement du VLM. Une image complète peut contenir un arrière-plan complexe, plusieurs personnages, du texte, des éléments décoratifs, etc., ce qui peut perturber le VLM sur l’objet à évaluer. Par exemple, il peut devenir difficile de savoir s’il s’agit d’un personnage sur une affiche en arrière-plan, de la figurine principale ou d’un autre personnage placé à côté. À l’inverse, avec le crop, seul l’objet cible est clairement isolé, ce qui permet au VLM de se concentrer uniquement sur cet objet pour prendre sa décision.
Bien sûr, les problèmes de non-détection ou de faux positifs de YOLO ne sont pas entièrement résolus. Cependant, nous avons atténué ce problème en fixant le
confidence thresholdde YOLO à 0.5 afin d’augmenter le recall, puis en éliminant les faux positifs aux étapes suivantes de filtrage CLIP et de vérification par Verifier. De plus, comme nous traitons de très grands volumes de données, même s’il subsiste quelques non-détections, nous pouvions tout de même obtenir statistiquement une quantité suffisante de données de haute qualité.En définitive, l’objectif était de construire une pipeline pratique en trouvant un équilibre entre coût, vitesse et précision, et l’étape de crop a eu des effets positifs sur ces trois aspects.
Bonjour winterjung, merci de l’intérêt que vous portez à mon travail. Pour la fiabilité, j’utilise la valeur de confidence renvoyée directement par le VLM (GPT-4o). Comme vous l’avez indiqué, il y a une limite au fait que la base de calcul de la confidence de GPT-4o n’est pas claire et qu’elle n’est pas reproductible. Mais d’un point de vue pratique, en partant de l’hypothèse que la confidence renvoyée par le VLM est raisonnablement précise, j’ai implémenté le système de façon à décider, lors de la dernière étape de vérification (Verifier), s’il faut valider ou non sur la base d’un threshold.
Je ne savais absolument pas que les tokens d’entrée image du modèle got-4o-mini étaient excessivement chers, merci de me l’avoir signalé. Je l’ai immédiatement intégré au code haha
On a l’impression que c’est critiquer pour critiquer
Oui, c’est en fait un article qui explique l’architecture pour montrer comment le produit est réellement construit.
J’en ai profité pour mettre cet article au propre en stabilisant la version 1.0 et en organisant la documentation.
Passer carrément au langage C3 est aussi une bonne idée. Comme il reprend la syntaxe du C avec un minimum de changements tout en ajoutant des fonctionnalités modernes, la migration est aussi facile.
C’est donc le billet explicatif de https://fr.news.hada.io/topic?id=25061 publié sur ShowGN.
Vous n’aurez sans doute pas envie de cliquer en voyant le titre… mais c’est, parmi les articles sur les relations entre les États-Unis et la Chine que j’ai lus récemment, celui que j’ai trouvé le plus intéressant.