Suite directe du bilan v3.16. Ce cycle couvre trois corpus successifs (v3.17, v3.18, v3.19) et trois problèmes distincts : améliorer URL_URI qui plafonnait à 80.9%, corriger SCHEDULED_TASK à 0%, et isoler un nouveau label KEY_FINGERPRINT du label FILE_HASH.
Corpus v3.17 — Diagnostic URL_URI Analyse des faux négatifs L’article précédent concluait sur URL_URI à 80.9% avec 66 FN. Le script analyze_fn.py donnait :
Total FN URL_URI : 66 Labels prédits à la place de URL_URI : — 66 (100.
Suite directe du bilan v3.11. Ce cycle a trois étapes : migration de l’architecture tok2vec vers un transformer, diagnostic systématique des faux négatifs par label, puis correction ciblée des causes racines identifiées. Résultat : F1 global 88% → 95,9%.
Contexte v3.12→v3.14 — Entre v3.11 et v3.14, trois cycles d’amélioration ont produit des résultats décevants : ajout de 500 exemples synthétiques EC2 pour HOSTNAME (+2 points de recall), tentatives de rééquilibrage des labels PID et MAC_ADDRESS.
Suite directe du bilan v3.1. L’évaluation par label avait identifié deux labels critiquement faibles : PROCESS_NAME (F1=61.8%) et PROTOCOL (F1=50%). Cause : pas assez de logs exposant ces entités dans le corpus d’entraînement. Ce cycle corrige ça en intégrant deux nouveaux datasets open source.
Nouveaux datasets CTU-13 — Stratosphere IPS Le dataset CTU-13 contient des captures réseau binetflow (CSV) avec des flows légitimes et malveillants étiquetés. Format :
SrcAddr,DstAddr,Proto,Sport,Dport,State,TotPkts,TotBytes,...,Label 147.32.84.59,62.107.124.67,tcp,25857,7726,CON,6,396,...,flow=Background Un script de conversion (extract_ctu13_flows.
AnonyNER est le composant NER du projet Victor — un modèle spaCy entraîné spécifiquement sur des entités sensibles de logs de sécurité. La version 3.1 marque un changement d’échelle significatif : passage de 12 à 30 labels, corpus multiplié par 8, et pour la première fois une évaluation complète par label sur un jeu de test indépendant.
Cet article est un bilan technique, pas un tutoriel. L’objectif est de montrer où en est le modèle, ce qui fonctionne réellement, et ce qui reste à faire pour une utilisation en production.
AnonyNER · N°2
Cartographier les logs disponibles : le problème du corpus pour l’anonymisation Entraîner un agent d’anonymisation pose un problème paradoxal : les données les plus utiles à l’entraînement sont précisément celles que personne ne partage. Les logs réels de production contiennent exactement les entités sensibles qu’on cherche à détecter — et c’est pour ça qu’ils restent dans les datacenters.
Cette contrainte a des conséquences directes sur la qualité des modèles. Cet article recense les corpus disponibles, leur niveau de sanitisation, leur densité en entités sensibles, et la façon dont on peut les compléter par des données synthétiques.
AnonyNER · N°3
Entraîner un NER sécurité : du corpus annoté au modèle en production Les entités de sécurité que spaCy standard ne détecte pas ne sont pas impossibles à apprendre — elles sont simplement absentes de ses données d’entraînement. La solution n’est pas de remplacer spaCy par un LLM lourd, mais d’entraîner le composant NER de spaCy sur des exemples spécifiques au domaine.
Ce chemin — annotation LLM-assistée → fine-tuning spaCy → modèle production léger — est à la fois robuste et déployable sans GPU.
LoRA Factory · N°2
Apprendre à l’IA à “Réfléchir” : Le Moteur de Traces ReAct Dans l’article précédent, nous avons vu comment lora-factory transforme des spécifications OpenAPI en contrats techniques rigides via Pydantic. Aujourd’hui, nous plongeons dans le “carburant” de nos experts : la donnée synthétique de haute qualité.
Entraîner un modèle sur de simples couples “Question -> Appel API” est l’erreur la plus commune dans le monde du fine-tuning. Cela crée des modèles “parrots” (perroquets) qui s’effondrent dès que la requête utilisateur s’écarte du script nominal ou contient des ambiguïtés.
