ATELIER Ops
Du brief au dossier de production, sourcé, vérifié et validé

- de précision « soutenue » par la vérification automatique (0,41 avec la citation seule)
- 0,90
- des phrases fausses ou partielles signalées
- 96 %
- phrase non soutenue validée à tort
- 0 / 31
- tests automatisés (14 avant), recette navigateur 12 / 12
- 30
- Le problème
- Passer d’une idée à un contenu tournable demande toujours les mêmes étapes : chercher, cadrer, écrire, vérifier, faire valider.
- Pour qui
- Un créateur ou une petite équipe marketing ; utilisé sur LaRefVlog et présenté avec un jeu de données d’exemple (startup « Nacre »).
- Le résultat
- Un assistant local et multi-utilisateur qui livre un dossier de production sourcé et validé nommément, en 34 à 83 s sur un M1 Pro ; chaque affirmation est vérifiée face à sa source (précision « soutenue » 0,90 contre 0,41 avec la citation seule, 0 / 31 phrase non soutenue validée à tort).
Contexte
Passer d’une idée à un contenu tournable demande toujours les mêmes étapes : retrouver l’information, choisir un angle, écrire les accroches, prévoir les plans, vérifier ce qu’on raconte, faire valider.
Premier usage : LaRefVlog. La solution est aussi présentée avec un jeu de données d’exemple pour une petite équipe : la startup « Nacre ».
Ce que j’ai construit
- Un LoRA MLX sur Qwen3-4B quantifié qui extrait les champs du brief ; il n’est utilisé que si le brief est structuré, sinon le modèle de base répond.
- RAG hybride : embeddings E5 en ONNX, FTS5/BM25, fusion RRF, filtrage par espace avant classement.
- Contrats de sortie Pydantic, contrôles de citations, de durée, de débit de parole et de chiffres non sourcés.
- Vérification automatique de chaque affirmation face au passage cité : cross-encodeur multilingue réimplémenté en NumPy sur CPU, sans PyTorch, 1,3 s par phrase. Une affirmation non soutenue bloque la validation tant qu’un relecteur ne l’a pas corrigée ou confirmée.
- Multi-utilisateur : comptes (mots de passe scrypt), quatre rôles par espace, sessions avec CSRF, jetons d’API pour CLI et MCP ; isolation entre espaces testée, y compris par identifiants forgés.
- Révisions, approbation nommée, invalidation si une source change ; temps machine et humain horodatés, export CSV et protocole de mesure ; FastAPI, file persistante, verrou GPU.
Architecture 7 briques
- 01 · EntréeBriefObjectif, public, canal, durée ; sinon, demande de précisions
- 02 · ModèleExtractionQwen3-4B + LoRA si brief structuré, sinon modèle de base
- 03 · DonnéesRecherche hybrideE5 (ONNX) et FTS5/BM25, fusion RRF, filtrée par espace
- 04 · ModèleRédactionModèle de base : accroches, scènes minutées, voix-off, sources
- 05 · OutilContrôlesPydantic, chaque phrase face à sa source (cross-encodeur CPU), durée, débit de parole, chiffres
- 06 · HumainValidationRôles par espace, approbation nommée, invalidée si une source change
- 07 · SortieExportDossier Markdown ; exporter n’est pas publier
Fabrication 6 étapes
- BriefObjectif, public, canal, durée.
- ExtractionLoRA si brief structuré, sinon modèle de base.
- RechercheCharte, fiche produit, notes de l’espace.
- RédactionAccroches, scènes minutées, voix-off, sources.
- ContrôlesChaque phrase face à sa source, durée, chiffres, promesses.
- ValidationRévision, approbation nommée, export.
Décisions le choix, la raison, l’alternative écartée
- D1Deux rôles pour le LLM : un LoRA pour extraire le brief, le modèle de base pour rédiger.
La tâche stable s’apprend dans les poids ; les faits changeants des marques restent dans la base documentaire.
ÉcartéUn seul modèle affiné pour tout, faits compris.
- D2Router vers le LoRA seulement si le brief compte au moins trois libellés explicites.
Mesuré sur sondes inédites : en formulation libre, le modèle de base fait mieux (4/6 champs corrects contre 3/6) ; le routeur confie chaque brief au meilleur des deux.
ÉcartéImposer l’adaptateur à tous les briefs.
- D3Vecteurs en float32 dans SQLite, recherche exacte fusionnée à FTS5/BM25 par RRF.
Adapté à un corpus local modeste ; un grand volume justifierait un index vectoriel dédié et ses mesures.
ÉcartéUne base vectorielle dédiée dès le départ.
- D4Aucun dossier simulé à la place d’une réponse invalide : JSON validé, une seule tentative de correction.
Une erreur visible vaut mieux qu’un faux dossier présentable.
ÉcartéCombler les trous avec un gabarit.
- D5Pas de relance silencieuse : au redémarrage, les tâches en cours passent à « interrompues ».
Une action interrompue se relance explicitement ; la file en attente, elle, est conservée.
ÉcartéUne reprise automatique.
- D6Vérifier chaque phrase face au passage cité avec un cross-encodeur réimplémenté en NumPy, sur CPU.
Une citation existante ne prouve pas que la phrase dit vrai : la vérification fait passer la précision « soutenue » de 0,41 à 0,90 et signale 96 % des phrases fausses ou partielles, pour 1,3 s par phrase et sans PyTorch.
ÉcartéContrôler seulement l’existence de la citation.
Résultats
Vérification affirmation ↔ source (partie test : 80 paires, passages jamais vus en calibration)
| Mesure | Citation seule | Vérification automatique |
|---|---|---|
| Précision « soutenue » | 0,41 | 0,90 |
| Phrases fausses ou partielles signalées | — | 96 % |
| Phrases non soutenues validées à tort | — | 0 / 31 |
| Coût sur CPU (M1 Pro) | — | 1,3 s par phrase |
Modèle de base contre LoRA v3 (premier passage)
| Protocole | Base | LoRA v3 |
|---|---|---|
| Régression : JSON valide | 7/8 | 7/8 |
| Régression : champs corrects | 6/8 | 7/8 |
| Sondes inédites : JSON valide | 5/6 | 5/6 |
| Sondes inédites : champs corrects | 4/6 | 3/6 |
Le LoRA progresse sur les briefs structurés (champs corrects : 6/8 → 7/8) ; un routeur l’active sur ces briefs et confie les formulations libres au modèle de base.
Livrables 6
- Application web locale multi-utilisateur (FastAPI, interface responsive) : comptes scrypt, quatre rôles par espace, CSRF, jetons ; serveur MCP authentifié à 4 outils.
- Vérification automatique affirmation ↔ source, statuts par phrase dans l’interface et l’export ; temps machine et humain horodatés, export CSV et protocole de mesure.
- Adaptateur LoRA v3 (2,6 Mo, 160 étapes) et sa carte de modèle, base et LoRA comparés sur chaque protocole.
- Deux dossiers exportés : LaRefVlog et le jeu d’exemple « Nacre ».
- 30 tests automatisés (isolation par identifiants forgés comprise) et recette navigateur 12 / 12 ; rapports d’entraînement et d’évaluation en JSON.
- Présentation interactive du projet, consultable hors ligne.
Environnement
Matériel et conditions de mesure
- Testé sur macOS Apple Silicon (MacBook Pro M1 Pro, 16 Go) avec MLX : 34 à 83 s par dossier.
- Servie sur 127.0.0.1 par défaut ; l’écoute réseau exige TLS, des hôtes autorisés et au moins un compte. Aucune API externe après le téléchargement des poids ; vérification sur CPU, 489 Mo de mémoire au plus.
Reproduire commandes du README
Code privé : accès en lecture sous accord de confidentialité, ou démo en direct de 30 minutes. Demander l’accès →
python3 -m venv .venv
.venv/bin/pip install -r requirements-lock.txt
.venv/bin/pip install --no-deps -e '.[dev]'
.venv/bin/atelier download
.venv/bin/atelier seed
.venv/bin/atelier serve
.venv/bin/python -m pytest tests -q- Testé sur macOS Apple Silicon (M1 Pro, 16 Go) avec MLX.
- Le premier téléchargement des poids pèse plusieurs Go ; ensuite, aucune API externe.
Galerie 6
Ce que ce projet change pour vous
Le même savoir-faire, sur votre sujet.
Un assistant de préparation privé
Connecté à vos documents et à votre circuit de relecture, sur votre machine : on commence par un seul format et un jeu de sources maîtrisé.
Un pilote mesuré
Cinq briefs préparés à la main puis avec l’outil, même exigence de relecture : temps jusqu’au dossier approuvable et erreurs factuelles comparés, sans gain inventé.
Adapter un modèle à votre tâche
Un LoRA étroit sur une tâche stable, routé seulement là où il fait mieux : je mesure base contre adaptateur avant toute mise en service.