- (Marc Lelarge) Allez-vous échanger avec des équipes plus
"info/compilation" à Inria, pour collaborer sur KeOps ?

Ce serait merveilleux !
Le principal obstacle, c'est l'intérêt de leur part pour notre cas
d'application "spécifique".
J'ai notamment discuté de ces sujets avec Oleksandr Zinenko (de l'équipe
d'Albert Cohen à l'ENS) et ai pu voir que le cadre des "matrices
symboliques" ne les intéressait pas plus que ça : c'est une notion qui
parle surtout aux gens qui font des méthodes à noyaux, etc.
Heureusement, nous commençons maintenant à avoir une bonne base
d'utilisateur. Cela démontre qu'il s'agit d'une "niche" importante, et
générera je l'espère de l'intérêt.


- (Marc Lelarge) Sur KeOps, quid de Julia ?

C'est tout à fait possible, et envisagé.
Le c?ur est 100% codé en C++, avec des binders pour PyTorch, NumPy,
Matlab et R, sans aucune dépendance stricte à Python. Nous avons
privilégié Python parce que c'est ce que nous utilisons au quotidien, et
standard en analyse de données - mais nous avons déjà entamé des
discussions pour l'écriture d'une interface Julia.


- (Marc Lelarge) Mais alors, cela veut dire que vous avez recodé toute
l'autodiff à la main ?

En effet. C'était incontournable, pour des raisons bas niveau et assez
techniques : le code KeOps final est comparable à un "shader" GPU, et il
n'existe aucun outil stable permettant de différentier ce type de
programme efficacement.


- (Sonia Ben Mokhtar) Quelle structure d'équipe pour KeOps ?

Ce n'est pas un projet que l'on peut développer seul !
J'ai eu la chance de travailler avec Joan Glaunès et Benjamin Charlier
depuis 2017.
Nous sommes maintenant dans une phase d'expansion et d'ouverture de
l'équipe, avec le recrutement à temps partiel d'un ingénieur de
recherche (pour R-KeOps) et, de mon côté, l'encadrement d'un groupe de
six élèves à l'Imperial College (Nyström, méthodes approchées pour la
recherche de plus proches voisins).
Il s'agit d'une dynamique qui se poursuivra naturellement dans les
années à venir.


- (Sonia Ben Mokhtar) Combien d'utilisateurs pour KeOps ?

La bibliothèque a été téléchargée 50,000 fois (43k pour Python, 7k pour R).
En aboutissement d'un travail mené depuis 2017, KeOps a atteint un bon
stade de maturité en 2019, avec une vraie diffusion et des publications
(NeurIPS, JMLR) en Décembre 2020.
Aujourd'hui, la bibliothèque est téléchargée 2-3,000 fois par mois : on
peut estimer notre base d'utilisateur à un petit millier, tant en
utilisation "directe" qu'au travers de bibliothèques de plus haut niveau.


- En vous restreignant à la médecine, n'avez-vous pas peur de couper les
ailes de KeOps ?

KeOps est bien découplée de mon travail en santé - il n'y a presque
aucune référence à l'anatomie computationnelle dans notre documentation.
Garder une motivation médicale/géométrique originale est très important
pour moi.
Combiner la maintenance d'un logiciel à large diffusion avec un travail
de fond demande un investissement conséquent, mais c'est le type
d'activité que je veux entreprendre (Cf. Alexandre Gramfort :
scikit-learn + optimisation et neurosciences).


- KeOps a-t-il des applications au-delà du médical, par exemple sur les
jeux vidéos ?

À vrai dire, la majorité de nos utilisateurs n'a aucun lien avec la
médecine !
En particulier, de nombreux utilisateurs travaillent aujourd'hui  en
méthodes à noyaux / processus Gaussiens, tant à INRIA (Alessandro Rudi,
équipe Sierra) que dans l'industrie (Facebook).

En ce qui concerne l'industrie du jeu vidéo, je crois que KeOps n'est
pas vraiment l'outil adapté.
Mon impression est qu'en "computer graphics", les problèmes sont
généralement bien définis (comme pour le "ray tracing") et que les
industriels sont prêts à investir les six mois de développement C++
nécessaires à la création d'implémentations optimales.

L'utilité de KeOps est de permettre de développer "en 5mn" des codes qui
sont au moins "comparables" à de coûteuses implémentations optimales
(avec un facteur 2 ou 3, sans doute) : c'est un outil qui est plus
adaptée dans un contexte de recherche, ou pour les entreprises qui n'ont
pas à leur disposition une équipe de codeurs experts en développement GPU.


- (Francis Bach - pile comme Gabriel hier, mais j'ai mieux répondu...)
Quel rapport entre KeOps/GPU et les stats sur les données de l'assurance
maladie ?

Ces données correspondent à un échantillonnage à 1% de nos cartes
vitales (660k individus, anonymisés).
Ce sont donc des séries temporelles de prises de médicaments, etc.
Sur ces données, les méthodes classiques en pharmaco-vigilance (comme
WCE) travaillent en deux temps :
1. Extraction de features sur ces séries temporelles.
2. Modèles statistiques standards, semblables à des régressions logistiques.

KeOps accélère la première étape, qui se prête très bien à une
implémentation GPU.


- (Francis Bach) Quelles contributions méthodologiques au deep
learning géométrique ?

Avant tout, j'ai permis de débloquer le développement de modules
d'interactions à grande échelle (que l'on appelle des "layers de
convolutions" dans le domaine).
En pratique, aujourd'hui, les chercheurs ont deux options :
- Se restreindre à l'utilisation de graphes de K-plus proches voisins,
très locaux.
- Utiliser des convolutions à grande échelle, ce qui est très compliqué
en PyTorch. On ne peut pas vraiment travailler avec plus de 2,000
points, et il faut donc investir six mois dans l'implémentation d'un
module de convolution ad hoc (comme par exemple aux Mines) - ce qui fait
généralement un bon papier.

KeOps automatise cette deuxième famille d'approches, en nous permet de
créer très simplement des modules adaptés à nos problèmes - comme par
exemple pour mon travail sur les protéines en biologie.


- (Emmanuel Thomé) Dans cette équipe de médecins, comment allez-vous
éviter de devenir le "data scientist de service" ?

En effet : si je partais par exemple aux États-Unis ou dans un endroit
que je ne connais pas, ce serait un vrai danger.
Heureusement, étant localisée à Paris où j'ai effectué toutes mes
études, HeKA me propose aujourd'hui d'avoir "le beurre et l'argent du
beurre" : un travail direct avec des médecins, tout en restant fortement
connecté aux communautés du transport optimal et de l'analyse de forme à
INRIA Paris et sur le plateau de Saclay.
C'est donc un risque calculé, que je vois plutôt comme une "immersion"
en milieu médical.

(Commentaire : "J'aime bien la métaphore du stage linguistique en
immersion !")



- (Emilie Chouzenoux) La preuves de positivité pour la divergence de
Sinkhorn sont-elles instructives ? Peuvent-elles servir à aller plus
loin ? Quelle utilité, théorique et pratique ?

Tout à fait, il y en a même deux !

- Ma preuve, qui repose sur une borne "des plus proches voisins". L'idée
est que puisque le transport optimal correspond à une projection des
plus proches voisins "sous contraintes",  on devrait pouvoir minorer la
distance de transport par une distance "de Hausdorff". C'est le cas, et
la positivité de cette quantité découle d'une propriété de convexité.

- Celle de François-Xavier Vialard, qui repose sur une minoration par
une norme à noyaux (ou "Sobolev"). Cette dernière sature dès que les
mesures s'éloignent trop l'une de l'autre, mais nous permet de bien
quantifier la régularité du comportement du transport entropique lorsque
les mesures sont très proches l'une de l'autre.

Ces deux preuves nous renseignent sur des aspects complémentaires des
divergences de Sinkhorn : l'une est pertinente à grande échelle, l'autre
"à convergence".

Pour aller plus loin, un groupe de chercheurs de ma génération utilise
aujourd'hui ces résultats pour étudier la théorie du transport
entropique sur des bases solides - presque comme avec une distance.

Au point de vue pratique (qui compte beaucoup pour moi), il s'agit d'un
résultat significatif : les figures de "biais entropique" sont
parfaitement documentées dans des articles publiés à CVPR (en vision par
ordinateur) il y a vingt ans et cités des milliers de fois. La solution
d'alors était d'utiliser une heuristique d'annealing : pour recaler un
nuage de point sur un autre, on commençait par le compacter puis à le
"déplier" lentement. Ce n'était pas une solution très pratique.
Le "débiaisage" est nettement plus stable : on sait aujourd'hui
travailler de manière robuste avec ces outils.



- (Emilie Chouzenoux) Comment gérer / prioriser ces projets ?

Dans un premier temps (2 ans), je souhaite me concentrer sur les projets
cliniques afin de m'intégrer à l'équipe.

Sur le plus long terme, je ferai la distinction entre les projets que je
porte "sur mes épaules" (métriques de Wasserstein, modèles d'anatomie)
et ceux pour lesquels j'aurai plutôt un rôle de consultant.
C'est quelque chose que j'ai appris à faire à Londres (Cf. mon travail
en biologie), et qui me permettra de consacrer mon énergie aux projets
qui nécessitent spécifiquement mon expertise en transport/anatomie.



- Comment évaluer la qualité des métriques/Hamiltoniens apprises sur des
espaces de formes ?

C'est une excellente question - pour moi, le principal défi de
l'anatomie computationnelle sur la décennie 2020-2030.
C'est un problème qui ne se posait pas trop lorsqu'il ne s'agissait que
de régler un ou deux paramètres à la fois. Mais maintenant que la boîte
de Pandore est ouverte, il est essentiel de s'assurer que l'on ne fait
pas n'importe quoi.

Un premier axe de réponse, c'est de s'assurer que les
géodésiques/splines de nos espaces correspondent bien à des trajectoires
observées. Après tout, le première critère de construction/qualité de
ces métriques est que leurs géodésiques génèrent des évolutions plausibles.
Il s'agit d'une approche assez "deep learning", proche des données.

(Petit trou de mémoire de 15s...)

Une seconde réponse, c'est de chercher à normaliser des métriques "a
posteriori". Par exemple, chercher à s'assurer que les translations
(locales) et autres trajectoires plausibles soient bien des géodésiques.
C'est un travail que j'ai commencé à entreprendre, et que j'aimerais
poursuivre.


+ 3-4 autres questions, que j'ai un peu oublié.



Globalement, alors que je m'attendais à être "cuisiné" sur des aspects
techniques complexes pendant 20mn par 2-3 membres du jury (tant sur
l'interaction avec les stats qu'avec la médecine), l'essentiel de la
discussion à porté sur KeOps et les aspects géométriques. Je crois que
les aspects de développement logiciel ont bien plu aux membres les plus
"info" du jury, en permettant de les impliquer à la discussion.