Cours6

# Outils de Traitement de Corpus
cours 6
-vertical-

# Rappel du cours précédent

<h2 class="r-fit-text">📏Métriques d'évaluation📏</h2>
<h2 class="r-fit-text">🔼Significativité des résultats⏫</h2>

-vertical-

<table class="r-stretch r-fit-text">
  <thead>
      <tr>
      <th>Type</th>
      <th>Naming Convention</th>
      <th>Examples</th>
      </tr>
      </thead>
      <tbody>
      <tr>
      <td>Function</td>
      <td>Use a lowercase word or words. Separate words by underscores to improve readability.</td>
      <td><code>function</code>, <code>python_function</code></td>
      </tr>
      <tr>
      <td>Variable</td>
      <td>Use a lowercase single letter, word, or words. Separate words with underscores to improve readability.</td>
      <td><code>x</code>, <code>var</code>, <code>python_variable</code></td>
      </tr>
      <tr>
      <td>Class</td>
      <td>Start each word with a capital letter. Don’t separate words with underscores. This style is called <a href="https://en.wikipedia.org/wiki/Camel_case">camel case or Pascal case</a>.</td>
      <td><code>Model</code>, <code>PythonClass</code></td>
      </tr>
      <tr>
      <td>Method</td>
      <td>Use a lowercase word or words. Separate words with underscores to improve readability.</td>
      <td><code>class_method</code>, <code>method</code></td>
      </tr>
      <tr>
      <td>Constant</td>
      <td>Use an uppercase single letter, word, or words. Separate words with underscores to improve readability.</td>
      <td><code>CONSTANT</code>, <code>PYTHON_CONSTANT</code>, <code>PYTHON_LONG_CONSTANT</code></td>
      </tr>
      <tr>
      <td>Module</td>
      <td>Use a short, lowercase word or words. Separate words with underscores to improve readability.</td>
      <td><code>module.py</code>, <code>python_module.py</code></td>
      </tr>
      <tr>
      <td>Package</td>
      <td>Use a short, lowercase word or words. Don’t separate words with underscores.</td>
      <td><code>package</code>, <code>pythonpackage</code></td>
      </tr>
</tbody>
</table>

-vertical-

# Cours 6

<h2 class="r-fit-text">Découper son corpus</h2>
<h2 class="r-fit-text">🤗Partager ses résultats🤗</h2>

-horizontal-

<h2 class="r-fit-text">Découper son corpus</h2>

Vous savez qu'il est nécessaire de découper son corpus en _train_, _test_ et parfois _dev_ (aussi appelé _validation_)

→ Est-ce que vous vous rappelez de pourquoi ?

-vertical-

### Pourquoi on découpe les corpus ?

<div class="r-stretch">
Les modèles de Machine Learning et Deep Learning apprennent des règles pour prédire des comportements sur les données d'un corpus.

→ ces données deviennent leur réalité.

Pour être sûr.e.s qu'un modèle n'a pas simplement appris par coeur à prédire le corpus de données qu'on lui a donné pour apprendre,  on veut le confronter à un autre jeu de données. C'est sur ces données là qu'on va appliquer les métriques d'évaluation (les mêmes que celles qu'on a appliquées à notre corpus mais pour notre modèle cette fois) : c'est la partition de <i>test</i>.
</div>

-vertical-

On a donc:
- La partition sur laquelle les modèles apprennent : la partition de _train_
- la partition sur lequelle on vérifie que le modèle généralise bien : la partition de _test_
- et la partition de _dev_

-vertical-

### A quoi sert la partition de _dev_ ?

<div class="fragment">
  Parfois, on a pas un modèle qui fonctionne du premier coup :
  
  il a sur-appris les données du _train_ et on s'en rend compte quand on passe sur le _test_ ...

Alors on change un peu les paramètres et on recommence...
</div>

<div class="fragment">
  ⚠️ Si on fait ça, on tue le principe de la partition <i>test</i> : on va utiliser le <i>test</i> pour affiner les règlages de notre modèle et on ne va plus savoir s'il généralise bien sur des données nouvelles !
</div>

-vertical-

### A quoi sert la partition de _dev_ ?

C'est donc tout l'objectif de la partition _dev_.

On va l'utiliser pour vérifier que notre modèle est opérationnel sur des données sur lesquels il n'a pas appris

Mais on va aussi pouvoir l'utiliser pour affiner certains paramètres et améliorer les résultats avec plusieurs itérations de traitements.

-vertical-

### Comment découper son corpus ?

Comme d'habitude, on se souvient que les modèles ont besoin d'énormément de données pour leur entrainement. On va donc vouloir garder une majorité des données pour l'entraînement. Il faut toutefois avoir un échantillon représentatif des données pour l'évaluation.

Par défaut, on donne 70% du corpus pour l'entrainement et 30% pour la validation.

-vertical-

### Comment découper son corpus ?

Des libraires adaptées au ML ou au DL donnent des outils pour découper les corpus.

On peut noter `scikit-learn` qu'on a déjà utilisé pour l'augmentation de données la semaine dernière

```
from sklearn.model_selection import train_test_split

X_train, X_test, y_train, y_test = train_test_split(
    X, y, test_size=0.05, random_state=0)
```

-vertical-

`Datasets` permet également de découper son corpus avec la méthode [`train_test_split`](https://huggingface.co/docs/datasets/v2.4.0/en/package_reference/main_classes#datasets.Dataset.train_test_split)

```
dataset.train_test_split(test_size=0.1)
```

-vertical-

### Les paramètres des fonctions de _split_

Les fonctions de _split_ ont de nombreux paramètres comme on peut le voir dans la doc.

- _shuffle_ : (par défault à _True_) mélange les entrées de notre corpus
  - → Pourquoi c'est important ?
  - Lorsqu'on a effectué notre nettoyage sur le corpus, on est passé par des étapes de tris : si notre corpus est toujours trié on va avoir un corpus de train et de test très mal équilibré

-vertical-

- _stratify_: mélange les entrées de notre corpus en fonction d'une colonne
  - → encore ?
  - trier aléatoirement notre jeu de donnée comporte toujours un risque que nos partitions soient mal équilibré. On peut donc forcer à avoir une bonne repartition de nos données en stratifiant sur une colonne en particulier

-horizontal-

<h2 class="r-fit-text">🤗Partager ses résultats🤗</h2>

-vertical-

Dans le cours 3, on a vu la bibliothèque `datasets` qui permet de charger des corpus de qualité directement depuis le *hub* de HuggingFace.

Maintenant qu'on a constitué notre propre corpus, on peut nous aussi le partager sur cette plateforme pour que d'autres personnes puissent utiliser notre travail.

-vertical-

On veut donner toutes les informations que l'on a collecté à propos de notre corpus aux personnes qui l'utiliseront :

pour ça on va renseigner la carte de notre corpus a.k.a. la *dataset card*

-vertical-

### Les cartes des datasets

Les _dataset card_ sont les README.md des corpus. Hugging face les présente comme suit

<blockquote class="r-stretch r-fit-text">Pour informer les utilisateurs sur la manière d’utiliser les données de manière responsable, il est judicieux d’inclure des informations sur tout biais potentiel dans l’ensemble de données. Généralement, les fiches d'ensemble de données aident les utilisateurs à comprendre le contenu de l'ensemble de données et donnent un contexte sur la manière dont l'ensemble de données doit être utilisé.
Les cartes des corpus sont des fichiers YAML</blockquote>

-vertical-

### Les cartes des datasets

> Vous pouvez également ajouter des métadonnées d'ensemble de données à votre carte. Les métadonnées décrivent des informations importantes sur un ensemble de données telles que sa licence, sa langue et sa taille. Il contient également des balises pour aider les utilisateurs à découvrir un ensemble de données sur le Hub et des options de configuration des fichiers de données. Les balises sont définies dans une section de métadonnées YAML en haut du fichier README.md.

</div>

-vertical-

### Les cartes des datasets

Vous puvez spécifier ces informations soit :

- à l'aide d'un fichier YAML : un language déclaratif créé sur `json`
- soit directement dans l'interface graphique de huggingface

-horizontal-

<h2 class="r-fit-text">Le point bonne pratique → Les _linters_ de code</h2>

Un _linter_ est une implementation de règles de code qui permet de vérifier automatiquement la qualité de votre code.

En python, les règles de code sont définies par la PEP (Python Extension Proposal) dont on a déjà beaucoup parlé.

Maintenant, les IDE embarquent des _linters_ directement dans leur interface ce qui leur permet de vous indiquer quand une variable est mal nommée par exemple.

-vertical-

On distingue deux types de _linters_ :

- les _linters_ logiques → qui corrigent les erreurs de code
- les _linters_ stylistiques → qui corrigent le code qui ne se conforme pas à la PEP

-vertical-

<table class="r-stretch r-fit-text">
  <thead>
    <tr>
    <th>Linter</th>
    <th>Category</th>
    <th>Description</th>
    </tr>
  </thead>
  <tbody>
    <tr>
    <td><a href="https://www.pylint.org/">Pylint</a></td>
    <td>Logical & Stylistic</td>
    <td>Checks for errors, tries to enforce a coding standard, looks for code smells</td>
    </tr>
    <tr>
    <td><a href="https://github.com/PyCQA/pyflakes">PyFlakes</a></td>
    <td>Logical</td>
    <td>Analyzes programs and detects various errors</td>
    </tr>
    <tr>
    <td><a href="https://github.com/PyCQA/pycodestyle">pycodestyle</a></td>
    <td>Stylistic</td>
    <td>Checks against some of the style conventions in PEP 8</td>
    </tr>
    <tr>
    <td><a href="https://github.com/PyCQA/pydocstyle">pydocstyle</a></td>
    <td>Stylistic</td>
    <td>Checks compliance with Python docstring conventions</td>
    </tr>
    <tr>
    <td><a href="https://github.com/PyCQA/bandit">Bandit</a></td>
    <td>Logical</td>
    <td>Analyzes code to find common security issues</td>
    </tr>
    <tr>
    <td><a href="http://mypy-lang.org/">MyPy</a></td>
    <td>Logical</td>
    <td>Checks for optionally-enforced static types</td>
    </tr>
  </tbody>
</table>

-vertical-

Pour aller plus loin, on peut utiliser les _formatters_

Des outils très utiles pour obtenir du code propre

→ Ils appliquent les conseils des _linters_ directement sur votre code.

On utilise majoritairement `black` pour le formattage de code

et `isort` pour le tri des paquets

```
pip install black
black src/*
```

```
pip install isort
python -m isort src/*
```

-vertical-

Pour aller *encore* plus loin :

Si vous ne voulez pas vous embêter à lancer les commandes `black` et `isort` à chaque fois que vous faites une modification de votre code (et c'est un bon reflexe : la qualité première de l'informaticien, c'est la flemme !)

Vous pouvez mettre en place un processus automatisé : 
- avant de commit votre code → avec des _hooks_
- au moment de tester votre code → avec l'intégration continue (CI)

-vertical-

### Les _hooks_

Les _hooks_ sont des programmes qui se lancent automatiquement à des moments spécifiques de l'execution de `git`

On peut lancer des programmes à pleins de moments différents :
- au moment du commit : `pre-commit`
- pour vérifier le format de votre message de commit : `prepare-commit-msg`
- pre-push , ... à chaque action en fait !

Mettre des [hooks](https://git-scm.com/docs/githooks) en place, c'est très simple :

-vertical-

On a deux méthodes

1. La plus simple : passer par le paquet `pre-commit` et écrire un fichier YAML de configuration

→ Il contient déjà des [_hooks_ tout prêts à être utilisés](https://pre-commit.com/hooks.html) !

2. La plus propre : Aller modifier le fichier `pre-commit` qu'il y a déjà dans votre repo `.git/hooks`

-vertical-

### Mettre des _hooks_ en place avec `pre-commit`

```
pip install pre-commit
```
```
repos:
-   repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v2.3.0
    hooks:
    -   id: check-yaml
    -   id: end-of-file-fixer
    -   id: trailing-whitespace
-   repo: https://github.com/psf/black
    rev: 22.10.0
    hooks:
    -   id: black
```

-vertical-

<div class="r-stretch">
### Mettre des _hooks_ en place : la voie classique

1. dans le dossier `hooks` de votre _repo_ git
2. créer un programme executable que vous nommez du nom du hook (`pre-commit` par exemple) avec les commandes que vous voulez faire passer pour votre hook
3. Le rendre executable avec `chmod +x` si nécessaire

```
#!/bin/bash

# On récupère les fichiers que l'on veut traiter
STAGED_FILES=$(git diff --cached --name-only --diff-filter=ACM | grep ".jsx\{0,1\}$")

if [[ "$STAGED_FILES" = "" ]]; then
  exit 0
fi

PASS=true

echo "\nlinting:\n"

# Check for black
which black &> /dev/null
if [[ "$?" == 1 ]]; then
  echo "\t\033[41mPlease install black\033[0m"
  exit 1
fi

# Check for isort
which isort &> /dev/null
if [[ "$?" == 1 ]]; then
  echo "\t\033[41mPlease install isort\033[0m"
  exit 1
fi

for FILE in $STAGED_FILES
do
  black "$FILE"
  isort "$FILE"

if [[ "$?" == 0 ]]; then
    echo "\t\033[32mLinting Passed: $FILE\033[0m"
  else
    echo "\t\033[41mLinting Failed: $FILE\033[0m"
    PASS=false
  fi
done

echo "\nValidation completed!\n"

if ! $PASS; then
  echo "\033[41mCOMMIT FAILED:\033[0m Your commit contains files that should pass black and isort but do not. Please fix the black errors and try again.\n"
  exit 1
else
  echo "\033[42mCOMMIT SUCCEEDED\033[0m\n"
fi

exit $?
``̀

</div>

-vertical-

### L'Intégration Continue

La CI est une bonne pratique de développement opérationnel (DevOps)

On peut mettre une [CI en place très facilement avec Gitlab](https://docs.gitlab.com/ee/ci/) en suivant ce [tutoriel](https://docs.gitlab.com/ee/ci/quick_start/#ensure-you-have-runners-available)

ou avec [Github](https://docs.github.com/fr/actions/learn-github-actions/understanding-github-actions)

-vertical-

Des ressources pour les bonnes pratiques de python :
- https://realpython.com/python-code-quality/
- https://realpython.com/python-pep8/

-vertical-

## Un exemple de process automatisés pour le TAL

→ Le projet Universal Dependencies

On peut retrouver les differentes étapes (_stage_) de la vérification des données sur leur [page](https://universaldependencies.org/validation-rules.html)

<div class="r-fit-text">
  <ol>
<li>Vérification du format des données (CoNLL-U)</li>
<li>Vérification des informations morphosyntaxique (Tous les _tags_ sont des _tag_ CoNLL-U, il ne manque pas de relation)</li>
<li>Vérification des relations (le sens des relations, ...)</li>
<li>Vérification des particularités de langues pour les <i>tags</i></li>
<li>Vérification des particularités de langues pour les <i>relations</i></li>
<li>Vérification que toutes les relations comportent les options voulues </li>
</ol>
<img src="/OutilsTraitementCorpus/slides/img/générique-spécifique.PNG">
</div>

-vertical-

## Un exemple de process automatisés pour le TAL

→ Le projet Universal Dependencies

La [sortie](http://quest.ms.mff.cuni.cz/udvalidator/cgi-bin/unidep/validation-report.pl) se présente comme un fichier de log.

-horizontal-

## Recap' du cours

Petit test

-horizontal-

1. Split son corpus en train, dev, test
2. Faire la carte de son Dataset
3. Optionnel : si vous pensez que votre corpus est intéressant → Le publier sur huggingFace

-vertical-

N'oubliez pas pour l'évaluation de votre repo, je vais surtout regarder si vous vous en êtes tenus aux points bonnes pratiques
- une bonne organisation de votre répertoire de travail
- les commit conventionnels
- les docstrings
- les conventions de nommage