Reprise du message précédent :
 
A la différence de beaucoup de bibliothèques Python, les outils dont tu parles sont backés par de grandes sociétés et ça change tout.
 
TF --> Google
Java --> Oracle
Linux --> Red Hat et SUSE
 
Il faut aussi comprendre le niveau des enjeux... Quand il s'agit de calculer un taux d'exposition qui quantifie le risque de faillite d'un acteur dont la chute pourrait entraîner la chute de tout le secteur financier, forcément tu fais un peu plus attention à la façon dont sont calculés tes indicateurs que lorsqu'il s'agit de recommander des fringues sur Zalando

C'est complètement con. Tu fais des bug aussi, sûrement plus, tu perd du temps et à la fin tu te fais piner par un mec qui vend un produit qui marche....

Cela n’empêche pas les clash potentiels.

Mec t'inquiète niveau enjeux je bosse pour un truc plus critique que la finance encore Simplement on le fait bien
TF n'est pas backé par Google, c'est un truc OS, tu n'a aucune garantie avec, sauf que les dev ne sont pas trop charlot. Ça tourne pourtant dans des voitures autonome....
J'ai vraiment l'impression que votre truc est un problème de compétence. Matlab désolé c'est bugué de partout, quand je vois des mecs utilisé des macros VBA pour des calculs complexes c'est pareil...Alors comme on a peur et que les décideur ne  comprennent rien, ils vont vers une "marque", old school, qui les rassures...et après ils ont des produits de merde

Le seul truc plus critique, c'est la bourse, et vu les salaires que ta boîte pratique je ne pense pas que tu bosses dans ce milieu
 
Les types qui développent Linux sont des gens salariés de Red Hat hein... Que Red Hat paie grâce aux contrats de maintenance qu'elle vend aux grandes entreprises... Linux, c'est pas une oeuvre de charité.

Non
Et linux est plein de bug. Tous les logiciel sont plein de bug. Le seul truc est de bien tester et comprendre ce qu'il y a dedans. Mais on va préférer une boite noire qu'un truc OS ouvert ou tu peux regarder dedans car "c'est pas backé". Tu crois que les dev de sckitlearn sont qui? Des charlot de 16ans?

 
Le problème avec le régulateur, c'est que quand il te tombe dessus, il épluche tout. Il va relever toutes les erreurs de ton process, de A jusqu'à Z. On a l'exemple concret de Transamerica. Pour infos ils ont écopé d'une accusation de négligences pour n'avoir pas pris de mesures afin de garantir le bon fonctionnement des modèles quantitatifs, et notamment l'absence de process de validation de modèles  

Vu les salaires de merde ça doit être dans le nucléaire ou un autre secteur en faillite

Là désolé mais non, MATLAB fonctionne globalement très très bien. Je l'ai suffisamment utilisé pour le savoir et j'ai vécu de l'intérieur les cycles de release, je peux te dire que c'est archi professionnel.

Ce sont des chercheurs justement. Tu sais, ceux dont tu as dit plus tôt qu'ils codent comme des pieds

 
Docuentation qui n'a jamais été lue par un data scientist  

C'est impossible d'utiliser de l'OS et d'être ok avec les process du régulateur?

Bon ok scikitlearn oui Mais tu prend keras par exemple c'est du gros niveau les dev, et c'est pas "backé". Et j'ai dis "la majorité" pas tous.

On en revient aux compétences.  

 
En fait le processus de contrôle ne se passe jamais en amont avec le régulateur. Le régulateur énonce des principes et des bonnes pratiques. Mais laisse le champ aux boîte de développer selon leur propres choix (heureusement d'ailleurs). Par contre, si jamais il y'a une plainte (ce qui se passe généralement au début d'un process de contrôle du régulateur), tu dois pouvoir montrer que tu es clean de chez clean. Sur tous les points. Autre exemple avec AXA Rosenberg, ou ils se sont même vus reprocher de "ne pas avoir communiqué à temps" leur(s) erreur(s) de modèle aux clients.  

 
Mais aussi et surtout à la culture de l'entreprise.    Beaucoup d'entreprises mettent le risque (opérationnel, de modèle, etc.) au second plan face à l'aspect développement et commercialisation. Jusqu'à ce que le régulateur leur tombe dessus  

OK c'est vraiment une histoire de compétences internes pour moi. Vous avez embauché que des quant "diva" des mecs qui ont dûs faire des super études de math, qui sont sûrement hyper fort en théorie, mais avec un faible niveau et intérêt en dev, c'est la même erreur que font beaucoup de gens en ML. Du coup le code est merdique et vous êtes obligé de fachoter sur les outils.

 
Attention à ce que tu racontes, y'a des MVA hein

 
https://python-poetry.org/  

Oui et non. C'est pas que ça. Je vais essayer d'être plus clair.
En banque la révolution a eu lieu, grâce (a cause) de la crise financière de 2009 et du régulateur. Grosso modo, avant 2009 les quant-traders (ça existait encore  ) étaient les rois, et le risque était vu comme une simple chambre du Back-office. Le risque émettait des avis, et le trader décidait de suivre ou non les avis.
Depuis ça a totalement changé. Le risque en banque, c'est le patron. Le risque est partout, dans tous les process (au début jusqu'à la fin). Exemple avec les modèles de pricing : aujourd'hui les Quant dev et models développent conjointement avec les Quant Risk leurs modèles. Et si un modèle n'est pas validé par le risque, il ne rentre pas en prod. Vraie révolution depuis 2009.

Et concernant les banques, j'ai vu des bibliothèques de pricing en C/C++ être développées from scratch. D'ailleurs c'est bien pour cela qu'on paye les Quant non ? Pour créer des modèles et non faire des copier/coller de code  

 
Lourd    

 
Et donc comme le dev à fait le EK y'a magiquement aucun bug
 
Votre débat sur du code fiable ou pas, l'aspect important c'est la methodologie d'usage plus que l'identité du developpeur nn ?

De ce que j'ai vu, un outil interne qui cherche à reproduire une partie (mais en mieux ! ) de ce que le marché propose fini en application legacy dont personne ne veut reprendre la maintenance / refactorisation à sa charge. Et ça dans des secteurs comme l'aérospatiale, la finance de marché, l'assurance, les ministères, l'automobile ...

Utiliser et chaîner correctement différents frameworks me semble plus intelligent à court (vitesse d'intégration, scalabilité) et moyen terme (trouver des compétences, faire évoluer les outils) que chercher à recréer la roue (bon si on parle de 100 lignes de code ou d'une boîte dont le métier est de créé ces frameworks c'est différent )

Dans le cas du deep learning (je connais pas autre chose) on a pas trouvé d'autres solutions que d'avoir une team dédié pour ça. Bosser sur nos outils/fmwk

Nous aussi en deep learning, on finit par développer notre propre architecture.
Chainer des frameworks existants c'est utile pour des prototypes (et on a commencé comme ca), mais petit a petit on a voulu optimiser et donc remplacer des trucs, et c'est quand meme mieux pour la flexibilité et l'efficacité (en temps de calcul je veux dire) de tout maitriser.

+1

Lol, on en apprend tous les jours

Ptite question vite fait  

Mettons que j'ai des images dont la distribution en terme de classe est :

Si je fais des copies des classes minoritaires pour avoir grosso modo le même nombre d'images par classe :

La redondance d'info ça va flinguer l'apprentissage ou pas ? Jme disais qu'avec suffisamment de data augmentation, au final ces doublons ne seront pas vraiment identiques donc ça devrait beaucoup aider. Non ?

Après y'a la solution de faire en sorte d'avoir des mini batchs équilibrés mais ça implique trifouiller la bibliothèque pour gérer le loading et g la flemme  

Par expérience, si tu copies (sans autre transformation) certaines instances pour équilibrer tes classes, ça ne devrait pas avoir beaucoup d'influence sur tes perfs. Donc non tu ne devrais pas flinguer l'apprentissage en faisant ça, mais tu n'observeras pas non plus une véritable amélioration.
 
En revanche, les augmentations que tu utilises et la manière avec laquelle tu les utilises peuvent avoir un impact non-négligeable. Tu fais tes augmentations en live pendant l'entraînement ou tu génères un nouveau dataset augmenté avant entraînement ?

J'utilise le framework Detectron2, ça se fait à la volée, au lieu de donner X au modèle tu donnes f(X) avec une proba i d'appliquer la transformation f

Dans ce cas ça devrait aider ouais, même pas sûr que tu aies besoin de copier des exemples des classes sous-représentées (notamment si tes augmentations sont pas très différentes entre elles)

Je regardais les métriques et y'a 2 classes où ça apprends pas, pour ça que j'essaie  

Utilise soit une loss pour rééquilibrer soit un sur-echantillonage dans tes batch.

Nc le polytechnicien qui recopie le tutorial pytorch  

C’est pas comme ça que tout le monde fait ?  

transfers learning tutorial
 
Les fonctions de dataloader / display originelles

Je vois plusieurs approches de mon côté:

1) tu embauche un stagiaire IA ou tu assigne un des 4 mecs de ton équipe "Data" , il prend un machin sur github, tune un peu le truc fait un proto a 85-90% de perfo et ça va jamais en prod
2) tu mandate un cabinet plus ou moins haut (sicara, BCG gamma) ou bas (capgemini, ssii divers) de gamme, pour faire ça, ça fait un proto à 85-90%, ca va rarement en prod avec les premiers, jamais avec les seconds
3) tu achète un produit à une boite qui le fait déjà à une boite: proto 1-6 mois puis déploiement à l'échelle 3mois -1ans, ça va potentiellement en prod, ça te coûte 500k-1Meur strict minimum
4) tu développe une vrai team d'IA chez toi avec une R&D , une prod etc.... Ca te prend 2ans 5Meur d'invest minimum.

Voilà c'est pas un problème du passé, loin de là

Ça me parait pas déconnant.  
 
Pour les bons cabinets de conseil on doit commencer à en avoir qui savent amener en production en ayant compris qu’un projet d’IA c’est plus que de la data science sur Jupyter ou TF.  
 
Par contre 500k mini c’est beaucoup non. J’aurais dit moins en capex, par contre prévoir un opex annuel.

Je vous trouve un peu pessimistes pour le coup...
 
Faire de la reconnaissance d'objet dans l'industrie, c'est plutôt mainstream. Ça existe quasiment sur étagère...

 C'est long et les profil sont chère. Un datascientist correct avec 2-3 ans d'xp c'est très facilement 1000€/j si tu prend en conseil. Chez Gamma ca va être 2-3x ça.
Sachant qu'un projet comme un détecteur d'objet sur une ligne d'assemblage c'est, imo, facile 1ans a 2 ans homme+hardware+license ca va vite....