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.
Avant d’envoyer des logs à un éditeur, de les injecter dans un LLM externe ou de les archiver conformément au RGPD, une question se pose inévitablement : ces fichiers contiennent-ils des informations qui exposent mon infrastructure ?
Les logs de sécurité sont denses en données sensibles — adresses IP internes, noms d’hôtes, identifiants de comptes de service, clés API, adresses MAC. Et contrairement aux bases de données ou aux formulaires, leur format n’est jamais tout à fait uniforme : chaque équipement, chaque version de daemon, chaque intégration produit ses propres variantes.
Important Traduction du site Source
Cet article est la version Française de 9 RAG Architectures Every AI Developer Should Know: A Complete Guide with Examples par Auteur Inconnu.
9 Architectures RAG : Un Guide Complet Avec Des Exemples
TLDR Le RAG optimise les sorties des modèles linguistiques en les faisant référencer des bases de connaissances externes avant de générer des réponses. Le RAG convient le mieux aux environnements à faible risque où la vitesse est plus importante que la densité factuelle absolue.
Agents en Production · N°1
Dans la série LoRA Factory, nous avons construit une usine à agents spécialisés sur Phi-3.5-mini-instruct. Trois agents (OPNsense, WireGuard, CrowdSec), trois adapters LoRA, un pipeline d’entraînement automatisé.
Tout fonctionnait — jusqu’à ce que les limites du modèle de base se manifestent en production. Ce premier article de la série Agents en Production documente pourquoi et comment nous avons migré vers Qwen2.5-3B-Instruct.
Pourquoi changer de modèle de base ? Phi-3.5-mini est un excellent modèle compact.
Agents en Production · N°2
C’est le type de bug qu’on ne voit pas venir.
L’entraînement se termine normalement. La loss finale est bonne — 0.2532 pour OPNsense, comparable aux runs précédents. Pas d’anomalie dans les courbes. Le modèle a convergé.
Puis on lance la vérification fonctionnelle. Et le score tombe à zéro.
Score : 0/102 (0%) ❌ ADAPTATEUR NON VALIDÉ L’investigation La première réaction est de chercher un bug dans le script de vérification. On inspecte le chargement du modèle, l’application de l’adapter, le décodage.
Agents en Production · N°3
Après entraînement, la question n’est pas “quelle est la loss ?”, c’est “l’agent appelle-t-il la bonne fonction quand on lui donne une directive réelle ?”.
C’est cette distinction qui a motivé la construction d’un système de vérification comportementale, distinct et indépendant du pipeline d’entraînement.
Le format CAP v1 Le coordinateur communique avec les agents via un format structuré appelé CAP v1 (Coordinator-Agent Packet). C’est le format de production — ce que reçoit l’agent dans un déploiement réel.
Agents en Production · N°4
Les trois agents sont validés à 100%. La question devient : comment les servir simultanément sur un GPU de 12 Go déjà occupé par le coordinateur ?
Le problème du multi-agent sur GPU contraint L’architecture cible est simple :
Utilisateur │ ▼ Coordinateur (Qwen2.5-3B, port 3001) │ CAP v1 ├──→ OPNsense agent ├──→ WireGuard agent └──→ CrowdSec agent │ ▼ Tool-agent-server (port 3000) Le coordinateur et les agents-outils tournent sur le même GPU — une RTX 4070 Ti avec 12 Go de VRAM réels (11.
Fine-tuning NLP pour les logs · N°1
Fine-tuner un NER sur des logs serveur : méthodologie et choix du framework Un log serveur n’est pas du texte. C’est une séquence semi-structurée, produite par un démon, dans un format qui varie selon la version du logiciel, la configuration, et parfois l’humeur de l’admin qui a écrit le rsyslog.conf. Les modèles NLP généralistes — entraînés sur des corpus de presse et de Wikipedia — sont largement aveugles à ce type de données.
AnonyNER · N°1
Quand spaCy ne voit pas l’infrastructure : le problème NLP des logs de sécurité Avant d’envoyer des logs à un éditeur de logiciels pour investigation, à un LLM externe pour analyse, ou simplement de les archiver conformément au RGPD, une question s’impose : ces logs contiennent-ils des informations qui exposent mon infrastructure ?
La réponse est presque toujours oui. Et les outils NLP standards — aussi performants soient-ils sur le langage courant — sont largement aveugles aux entités spécifiques au domaine de la sécurité.
