5. Codif TTC
Rôle de l’étape
run-ttc code les libellés avec un classifieur neuronal pré-entraîné (à l’aide du package torchTextClassifiers).
Le modèle utilisé est le classifieur basique (« flat ») . Il a été :
- entraîné sur des données de caisses (tickets de la grande distribution : hypermarchés / grandes surfaces uniquement) ;
- puis fine-tuné sur les annotations produites lors du test de l’enquête BDF de 2024.
C’est l’une des quatre prédictions « candidates » (avec LCS, RAG notices et RAG annotations) que l’arbitrage final combinera.
- Code :
codif-ttc/— classifieur basique (codif-ttc/src/classifiers/basic_classifier.py) - L’étape Argo construit depuis les sources comme les autres étapes :
git clonedu dépôt puisuv sync+uv run main.py predict-basic …danscodif-ttc/.
Entrées
| Argument | Chemin |
|---|---|
--file |
…/{run}/codif-regex/raw_test_without_regex.parquet |
--model |
mlflow-artifacts:/…/artifacts/model (paramètre de workflow ttc-model-uri) |
La prédiction porte sur la colonne l_pr_product (normalisation légère).
L’URI du modèle TTC est un paramètre de workflow (ttc-model-uri, défini dans argo/codif-pipeline.yaml) plutôt qu’une valeur codée en dur. La même URI est propagée à l’étape report, qui la loggue dans MLflow (paramètre ttc_model_uri) pour tracer quel modèle a servi à chaque run.
Traitement
Le classifieur est basique (« flat ») : il prédit directement le code COICOP à partir du libellé, sans cascade par niveaux. Architecture (codif-ttc/src/classifiers/basic_classifier.py, package torchTextClassifiers) :
- tokenisation par n-grammes de caractères (type fastText) : robuste aux abréviations et fautes des libellés de tickets (
bagu,tradit…) ; - un classifieur plat multi-classes sur l’ensemble des codes COICOP vus à l’entraînement (les codes techniques
98.x/99.xsont exclus des données d’entraînement) ; - le texte passe par le même prétraitement que
s_pr_product(unidecode, minuscules, retrait du bruit et des stopwords) avant tokenisation.
L’entraînement et le fine-tuning ont leurs propres sous-commandes (train-basic, fine-tune-basic dans codif-ttc/main.py) et leur propre workflow Argo (argo/ttc-pipeline.yaml) ; le modèle entraîné est stocké dans MLflow et référencé par l’URI ttc-model-uri. À noter : les codes des données d’entraînement sont tronqués au niveau 4 (codif-ttc/src/data/build_training_data.py), mais sans l’élagage des hiérarchies linéaires — le modèle peut donc prédire un code replié (ex. 11.2.0) ; c’est la normalisation de decide-coicop qui le ramène au code canonique.
Pour chaque produit, le classifieur renvoie les 10 meilleurs codes avec leur score de confiance (--top-k 10).
"bagu tradition u ble bretagne"
→ ttc_code_1 : 01.1.1.x (pain…) conf. ttc_conf_1
→ ttc_code_2 : … conf. ttc_conf_2
→ … jusqu'à ttc_code_10
Le modèle a été entraîné sur des données de caisses de la grande distribution puis fine-tuné sur le test BDF 2024. Il est donc le plus fiable sur les produits de supermarché/hypermarché ; il l’est moins sur les libellés issus d’autres circuits (petits commerces, restauration, services…). C’est l’une des raisons d’être de l’arbitrage final, qui croise TTC avec LCS et RAG.
Les colonnes produites sont predicted_code (+ confidence) et predicted_code_top2 … predicted_code_top10 (+ confiances), classées par confiance décroissante — renommées ttc_code_1..3 / ttc_conf_1..3 par decide-coicop, qui ne lit que le top-3 et utilise surtout le top-1 pour le court-circuit consensus.
Exemple sur le fil rouge
Libellé (l_pr_product) |
ttc_code_1 (illustratif) |
ttc_conf_1 |
|---|---|---|
bagu tradition u ble bretagne |
01.1.1 (pains et céréales) |
élevée |
max garden flowers balle surprise |
code jouet/jardin | plus faible (libellé ambigu) |
Quand la confiance top-1 est ≥ 0,90 et que tous les autres codes disponibles (LCS, RAG notices, RAG annotations) donnent le même code, l’arbitrage tranche sans appeler le LLM (voir decide-coicop).
Sorties
| Argument | Chemin |
|---|---|
--output |
…/{run}/run-ttc/predictions.parquet (predicted_code[_topN], confidence[_topN]) |
➡️ Étape suivante : 6. Codification RAG