Notes techniques Naly : rédaction d’articles RAG centrée sur les sources pour une publication persistante et auditable

TL;DRLa génération augmentée par récupération (RAG) transforme le pipeline d’articles de Naly en un système de publication fondé sur des sources au lieu d’une composition reposant sur la mémoire du modèle. Chaque demande d’ébauche collecte d’abord des preuves web et arXiv, normalise et persiste les URL sources, puis demande au modèle de produire d’abord un brouillon en mode « réponse » et l’article HTML final. Cela déplace le risque de « le modèle peut-il halluciner ? » vers « la couche de récupération est-elle complète et traçable ? », offrant aux éditeurs des artefacts stables, des tâches rejouables et des affirmations publiques défendables.

Résumé

Le RAG dans Naly doit être conçu autour de la persistance des sources et de contrats déterministes. Le 27 juin 2026, la fiabilité pratique dépend moins d’un modèle plus puissant que de l’interrogeabilité, de la versionnage et de la validation des artefacts de récupération avant publication. Cette note propose un design bi-plan : un plan de preuve pour la récupération/le stockage et un plan de génération pour la rédaction, puis montre comment cette architecture améliore directement la confiance éditoriale et la gestion des incidents.

Où cela se situe dans Naly

Naly l’exécute comme un sous-système de contenu de production dans une stack Next.js 16.0.7 App Router (next + react), où la publication d’articles fait partie des chemins de code runtime plutôt que d’une étape de rédaction hors ligne séparée. Le parcours job-article est l’endroit où toutes les contraintes doivent être imposées : un article n’est pas « écrit » tant que les enregistrements sources n’existent pas, que la structure de résumé est validée et que le HTML est matérialisé.

L’alignement de la stack est intentionnel :

next@16.0.7 + Les React Server Components hébergent le rendu déclenché par les tâches côté serveur, ce qui correspond aux contrats de sortie côté serveur pour les articles.
drizzle-orm@0.44.7 + @neondatabase/serverless@1.0.2 définit des tables de jobs et de sources persistantes et typées, afin que chaque affirmación puisse être tracée.
ai@6.0.0-beta.105 fournit à la génération des contrôles de sortie sensibles au schéma.
marked@17.0.1 convertit les résumés Markdown générés en HTML rendu pour la publication.
@vercel/blob@2.0.0 stocke les actifs générés sous forme d’URL durables pour réutilisation.
Les outils Anthropic peuvent être ajoutés en tant que fournisseur de modèle alternatif dans la même enveloppe de contrat, mais pas comme une solution de secours pour contourner les contraintes structurées.

Cela remplace un modèle « générer puis relire » par une boucle d’écriture fondée: la récupération, la validation, la génération, le rendu et la publication doivent tous réussir avant que l’article ne soit visible.

Mécanisme technique

Un design robuste de Naly comporte cinq étapes bornées :

Plan de preuve et orchestration des requêtes

Définir la spécification de tâche avec le sujet, la fenêtre de dates et la politique de preuve.
Exécuter à la fois la recherche web et la recherche arXiv pour les sources primaires.
Dédupliquer par URL canonique et normaliser le protocole, l’hôte et la chaîne de requête.

Couche de persistance des sources

Stocker les métadonnées par URL (url, URL canonicalisée, statut de récupération, horodatage de récupération, titre, extrait, type de source).
Stocker séparément les extraits orientés modèle et les charges utiles brutes afin que les relances restent déterministes même si les pages en amont évoluent.
Ajouter des sommes de contrôle par source pour détecter la dérive.

Mise en forme du contexte et contraintes

Construire un contexte de récupération ordonné par pertinence et récence.
Exiger des IDs sources explicites dans le contrat de prompt.
Imposer une forme de sortie centrée sur la réponse (intro claim, evidence bullets, risk caveats, uncertainty), plus des références sources ordonnées.

Génération structurée avec schéma strict

Utiliser une sortie structurée pour que les réponses malformées ou non conformes au schéma échouent rapidement et soient relancées avec un contexte plus strict.
Conserver la génération dans le contexte serveur et rejeter les brouillons qui avancent des faits non couverts sans IDs sources mappés.

Rendu, publication et vérification

Convertir le Markdown validé en HTML et persister à la fois markdown + HTML.
Mettre en cache la sortie finale uniquement après validation réussie.
Émettre des champs analytiques et d’audit : nombre de sources, affirmations rejetées, nombre de relances et latence de génération.

Le changement de design le plus important est la séparation des préoccupations: la qualité de récupération et la qualité de génération sont des domaines de défaillance distincts avec des métriques différentes. Les React Server Components de Next.js conviennent à cette séparation car le rendu peut rester déterministe tandis que la récupération et la génération se déroulent dans des tâches asynchrones contrôlées.

Ce que dit la littérature

La littérature RAG récente soutient ce modèle d’architecture. Une revue de 2024 sur l’architecture RAG décrit comment les systèmes augmentés par récupération réduisent la dérive factuelle en conditionnant la génération sur des preuves externes, mais note des compromis en matière de complexité de pipeline et de coordination modulaire [Gupta et al., 2024]. Une revue de suivi de 2025 ajoute que la robustesse dépend désormais de la récupération adaptative, du contrôle de décodage et de l’évaluation de bout en bout, plutôt que de la qualité de génération seule [Sharma, 2025].

Pour le contrôle qualité en production, la revue d’évaluation de 2025 scinde explicitement l’évaluation en métriques internes de récupérateur/générateur et métriques système externes ; cette décomposition est particulièrement utile pour les pipelines d’articles, car « mauvais article » peut signifier mauvais choix de source même quand la qualité linguistique est élevée [Gan et al., 2025]. Les travaux centrés sur la grounding ont également évolué vers des couches de détection qui classent le support des affirmations à l’aide du contexte récupéré et de vérifications de type NLI, renforçant la valeur pratique de la validation post-génération [Gerner et al., 2025].

En bref, les articles convergent vers une seule thèse : le RAG n’est pas seulement une manière d’injecter du contexte, c’est un contrat d’ingénierie entre récupération et génération. Naly doit donc optimiser ce contrat, pas seulement le prompt.

Trade-offs de design

Fraîcheur vs déterminisme: des TTLs plus stricts réduisent l’obsolescence mais augmentent le coût de re-téléchargement. La persistance des snapshots permet de conserver un rendu déterministe tout en révalidant quand même les fenêtres de fraîcheur.
Rappel vs précision dans la récupération: une récupération plus large peut augmenter la couverture mais introduit du bruit ; un second filtre de pertinence protège la qualité des affirmations.
Rigueur de schéma vs fluidité de style: des schémas de sortie stricts améliorent la fiabilité machine mais peuvent réduire la liberté stylistique. Le schéma « réponse d’abord » préserve la lisibilité tout en maintenant les garde-fous.
Vitesse de rendu statique vs auditabilité: le pré-rendu HTML améliore la performance de livraison et réduit le calcul répété, mais seulement si les artefacts sources utilisés sont des références immuables.
Complexité vs coût opérationnel: chaque étape de validation ajoutée (vérifications de source, vérifications de schéma, persistance d’artefacts) ajoute de la latence. Les recommandations de production Next.js sur le cache, les frontières de route et la vérification au moment de build sont essentielles pour conserver la viabilité opérationnelle.

Modes de défaillance

Dérive des sources: des URL retournent 404/soft-changes après la création de la tâche. Mitigation : clé canonique + hash de snapshot + chaîne de sources de secours.
Excès de récupération: un fort rappel avec une faible précision entraîne une synthèse plausible mais non appuyée. Mitigation : exiger des contraintes evidence-first et bloquer les affirmations sans correspondance source.
Échec de formatage de modèle: incompatibilité de schéma ou JSON tronqué lors de la génération. Mitigation : validation stricte du schéma et relance avec contexte réduit.
Courses de double publication: des workers concurrents peuvent publier des artefacts partiels. Mitigation : clés d’idempotence de tâche, transitions d’état au niveau ligne (pending -> drafting -> validated -> published).
Régressions de rendu: markdown mal formé ou transformations HTML non sûres. Mitigation : conversion marked déterministe et tests de sortie HTML liés à des manifestes d’échantillon.
Illusions de cache: des données dynamiques périmées dans la sortie serveur peuvent désynchroniser le texte publié et l’index des sources. Mitigation : aligner la stratégie de rendu des routes avec une politique explicite de fraîcheur runtime et éviter les caches implicites quand la fraîcheur des preuves est requise.

Notes d’implémentation

Pour un déploiement pratique, traitez cela comme un contrat de publication contractuel :

Définir des tables sources dans Drizzle avec des contraintes explicites : unicité des URL par hôte/chemin canonique, enums de statut de récupération et colonnes de sommes de contrôle.
Utiliser de manière cohérente un pilote compatible Neon avec le comportement d’exécution serverless ; la documentation Drizzle décrit à la fois les options spécifiques au runtime et les neon-* options de pilote.
En génération, appliquer des contrats de sortie structurés et échouer sur les objets invalides avant le rendu.
Utiliser les recommandations de production Next.js pour les limites serveur, les pages d’erreur, la mise en cache et les métadonnées SEO des routes d’articles afin que la publication reste observable et rapide.
Persister les blobs générés (p. ex. images de couverture, pièces jointes, exports) via Vercel Blob avec une politique d’accès explicite et un nommage déterministe pour éviter les collisions.
Émettre des contrôles opérationnels avant publication : nombre minimum de sources, diversité minimale des sources, fraîcheur des preuves et taux de complétion minimal pour les affirmations mappées.

C’est le changement majeur : l’article n’est plus évalué sur l’ingéniosité du modèle ; il est évalué sur la cohérence entre preuves et génération sous les relances et les redéploiements.