Notes d’ingénierie Naly : rédaction d’articles augmentée par la récupération avec sources persistées

Résumé

La génération augmentée par récupération donne au pipeline d’articles de Naly une mémoire de recherche plus fraîche et plus auditable que les seuls poids du modèle. Pour chaque note d’ingénierie ou tâche d’article d’intelligence de marché, le système peut rechercher sur le web et arXiv, conserver les URL des sources avec l’artefact généré, demander au modèle de répondre d’abord, puis rendre le résultat en HTML. Le but n’est pas l’automatisation pour elle-même ; c’est de publier des affirmations que les lecteurs peuvent retracer.

La thèse est simple : le RAG pour la rédaction d’articles doit être traité comme un système de preuves en production, non comme un schéma de chatbot. On peut pardonner une réponse faible à un chatbot ; un article publié devient une surface de confiance durable. L’implémentation de Naly doit donc respecter trois invariants : récupération avant rédaction, enregistrements de sources qui survivent après publication, et moteur de rendu qui préserve un Markdown lisible tout en évitant le HTML non sûr.

Où cela se situe dans Naly

Les tâches d’articles Naly se situent entre l’acquisition de recherche et la publication publique. La tâche commence par un sujet sélectionné, génère des intentions de recherche, récupère des matériaux web et arXiv, normalise les résultats en enregistrements de sources, puis demande à un modèle d’écrire un article centré d’abord sur la réponse à partir de cet ensemble de preuves borné. Le résultat n’est pas seulement de la prose. C’est un ensemble : contenu Markdown, HTML rendu, URL des sources, titres des sources, types de sources et suffisamment de métadonnées pour expliquer pourquoi chaque source a été utilisée.

Cela compte pour la boucle de confiance de Naly. La posture éditoriale plus large de Naly consiste à publier ce que les autres cachent : notes de décision, limites de calibration, échecs et preuves derrière les affirmations. La génération étayée par des sources rend cette posture opérationnelle. Les lecteurs ne devraient pas avoir à deviner si une déclaration vient des données d’entraînement d’un modèle, d’un document officiel, d’un article scientifique ou d’une assertion d’opérateur.

La couche RAG doit intervenir avant la rédaction, pas après. L’ajout de citations a posteriori est plus faible parce que le modèle a déjà formé ses affirmations. Dans une conception plus robuste, la récupération contraint le contexte de génération, et la génération produit des affirmations qui peuvent être vérifiées par rapport à l’ensemble récupéré. L’article visible peut rester concis, mais l’artefact stocké doit conserver la piste de recherche.

Mécanisme technique

Pour la rédaction d’articles, le flux RAG de Naly est un pipeline par lots :

La sélection du sujet crée une question de recherche bornée, par exemple comment la génération augmentée par récupération fonde la rédaction d’articles étayés par des sources.
La planification des requêtes étend cette question en requêtes web, requêtes de documents officiels et requêtes arXiv.
La récupération collecte de la documentation officielle, des articles primaires et des sources explicatives à fort signal.
La normalisation extrait le titre, l’URL canonique, le type de source, le contexte de publication ou de mise à jour lorsqu’il est disponible, ainsi que les extraits ou résumés pertinents.
La persistance des sources stocke le registre des URL avant la génération afin que l’article puisse être audité plus tard.
L’assemblage du prompt fournit au modèle le sujet, les faits d’implémentation propres à Naly, les contraintes d’écriture et les preuves récupérées.
La génération produit du Markdown avec un résumé centré d’abord sur la réponse, des modes de défaillance explicites et une section de références.
La validation vérifie que chaque référence dans l’article rendu correspond à un objet source stocké.
Le rendu convertit le Markdown en HTML pour le site tout en appliquant une sanitisation et des contrôles de production.

Cela est proche du schéma de récupération et de génération augmentée décrit dans le guide RAG de Vercel : récupérer d’abord le contexte pertinent, puis le combiner avec la question de l’utilisateur ou de la tâche avant la génération. La différence est que Naly n’optimise pas pour le support conversationnel. Il optimise pour une publication durable, où une URL source fait partie du modèle de données de l’article.

L’AI SDK est une couche d’orchestration naturelle pour ce type de tâche, car son interface de génération de texte prend en charge l’automatisation non interactive, les appels d’outils, les résultats multi-étapes et les métadonnées de sources lorsque les fournisseurs renvoient des sources URL. Même lorsqu’un fournisseur ne renvoie pas d’objets source natifs, Naly peut attacher sa propre liste de sources récupérées à l’artefact d’article et traiter les sources natives du modèle comme supplémentaires plutôt qu’autoritaires.

Ce que dit la littérature

La formulation originale du RAG par Lewis et al. posait bien le problème central : les modèles de langage paramétriques stockent des faits dans leurs poids, mais la mise à jour de ces connaissances et la fourniture de leur provenance restent difficiles. Leur modèle augmenté par récupération combinait un modèle séquentiel avec un index vectoriel dense et a produit une génération plus spécifique, diverse et factuelle qu’une référence uniquement paramétrique sur des tâches intensives en connaissances.

L’enquête ultérieure sur le RAG par Gao et al. généralise cette idée en une taxonomie : RAG naïf, RAG avancé et RAG modulaire. Le pipeline d’articles de Naly doit être modulaire. Récupération, classement, persistance des sources, construction du prompt, génération, validation des références et rendu sont des unités séparées avec des modes de défaillance distincts. Les traiter comme des unités séparées rend le système plus facile à déboguer lorsqu’un article cite une source faible ou en manque une meilleure.

Self-RAG ajoute une mise en garde importante. Asai et al. soutiennent que récupérer un nombre fixe de passages, que la récupération soit nécessaire ou non, peut dégrader la qualité de sortie. Pour Naly, cela signifie que la récupération top-k ne doit pas être un rituel. Un court article sur une fonctionnalité stable de framework peut nécessiter des docs officielles et un article ; un article très axé sur la littérature peut nécessiter plusieurs sources arXiv et une enquête. La profondeur de récupération doit suivre le risque associé aux affirmations.

RAGChecker fournit la leçon d’évaluation. Ru et al. soutiennent que les systèmes RAG ont besoin de diagnostics fins couvrant à la fois la récupération et la génération, surtout pour les réponses longues. Pour Naly, l’unité d’évaluation ne doit pas être seulement la qualité de l’article. Elle doit inclure le rappel de récupération, la pertinence des sources, le soutien des affirmations, la couverture des références et le fait que des affirmations non étayées se soient ou non glissées dans le Markdown final.

Compromis de conception

Le compromis central oppose un rappel élevé à un faible bruit. Une récupération plus large augmente les chances de trouver la bonne source, mais elle augmente aussi le risque que des extraits faibles entrent dans le prompt et orientent le modèle. Naly devrait privilégier une approche par étapes : collecte large, filtrage strict, puis contexte de prompt compact.

La persistance des sources améliore l’auditabilité, mais elle crée aussi du travail de stockage et de maintenance. Les URL dérivent, les articles scientifiques sont révisés et les pages de documentation se déplacent. L’enregistrement durable doit inclure l’URL canonique, l’horodatage de récupération, le titre, le type de source et, idéalement, un condensé de contenu ou une limite d’extrait. Cela permet à Naly de distinguer une erreur du modèle d’une source qui a changé.

L’écriture centrée d’abord sur la réponse améliore la valeur pour le lecteur, mais elle peut comprimer l’incertitude de manière trop agressive. L’article doit commencer par la conclusion tout en conservant une section ultérieure pour les modes de défaillance et les réserves. Le résumé centré d’abord sur la réponse est le point d’entrée ; ce n’est pas une autorisation d’aplatir les preuves.

Le HTML rendu améliore la distribution et l’expérience de lecture, mais il crée une frontière de sécurité. Marked est rapide et utile pour l’analyse du Markdown, mais sa documentation avertit explicitement qu’il ne sanitise pas le HTML de sortie. Un moteur de rendu d’articles Naly doit sanitiser le HTML généré et conserver la source Markdown de confiance disponible pour relecture.

Modes de défaillance

Échec de récupération : l’étape de recherche trouve des sources plausibles mais incomplètes. Cela arrive généralement lorsque le planificateur de requêtes est trop étroit ou utilise des termes produit qui diffèrent de ceux de la littérature. Atténuation : utiliser plusieurs styles de requêtes, inclure les docs officielles et exiger au moins deux sources primaires ou arXiv lorsque l’article formule des affirmations de recherche.

Blanchiment de citation : une source apparaît dans les références, mais elle ne soutient pas réellement la phrase à proximité. C’est pire que l’absence de citation, car cela crée une fausse confiance. Atténuation : valider les affirmations par rapport aux extraits de sources et rejeter les articles dont les références sont seulement thématiques.

Dérive des sources obsolètes : une page de documentation officielle change après publication. Atténuation : persister les métadonnées de source au moment de la génération et enregistrer l’étiquette de date. Pour les sources qui soutiennent des affirmations majeures, stocker un instantané ou un condensé lorsque les licences le permettent.

Sur-récupération : trop de segments poussent le modèle à résumer le contexte plutôt qu’à répondre à la thèse de l’article. Atténuation : utiliser le classement des sources, dédupliquer les documents quasi identiques et plafonner les preuves dans le prompt par pertinence pour les affirmations plutôt que par nombre brut.

Empoisonnement du contexte : des pages de spam, pages SEO générées ou résumés de faible qualité surpassent le matériau primaire. Atténuation : classer la documentation officielle, arXiv, les standards et les dépôts source au-dessus des commentaires secondaires, sauf si l’article porte explicitement sur la réception par l’industrie.

Risque du moteur de rendu : le Markdown généré peut inclure du HTML brut, des liens non sûrs ou des tableaux mal formés. Atténuation : sanitiser le HTML rendu, normaliser les liens, rejeter le contenu scriptable et exécuter des contrôles de production conformes aux recommandations de Next.js sur les performances, la sécurité, les métadonnées et l’accessibilité.

Notes d’implémentation

Compte tenu des faits d’exécution actuels de Naly, l’architecture propre est une tâche TypeScript qui utilise ai@6.0.0-beta.105 pour l’orchestration du modèle, des outils de récupération web et arXiv pour la collecte de preuves, Drizzle ORM avec Neon pour les enregistrements d’articles et de sources, marked@17.0.1 pour le rendu Markdown-vers-HTML, et Next.js 16 pour la surface de publication.

La base de données doit traiter les sources comme des lignes de première classe, non comme un bloc de texte Markdown. Un schéma pratique comporte une table d’articles, une table de jointure article-source et des champs de source pour l’URL, le titre, le type de source, l’horodatage de récupération, l’identifiant canonique tel qu’un ID arXiv lorsqu’il est disponible, et l’état d’extraction. L’enregistrement d’article peut alors pointer vers le Markdown, le HTML rendu, le résumé, les points clés et les métadonnées de publication.

Vercel Blob est utile pour les artefacts plus volumineux ou les sorties de rendu immuables, tandis que Postgres reste préférable comme registre interrogeable pour les sources et les métadonnées d’articles. Cette séparation maintient les requêtes d’audit peu coûteuses : lister chaque article qui a utilisé une source, chaque source utilisée par un article, et chaque article dont l’extraction de source a échoué.

Le prompt du générateur doit imposer la discipline des sources dans la forme de la sortie : aucune affirmation non étayée, aucune URL inventée, et une section de références dont les liens doivent correspondre à la liste de sources persistée. Le modèle peut écrire une prose fluide, mais la tâche doit posséder la vérité des sources. Si le modèle émet une référence qui n’a pas été récupérée, le validateur doit faire échouer l’article plutôt que le publier silencieusement.

Enfin, le comportement en production compte. Next.js fournit déjà des composants serveur, le fractionnement du code, le prérendu et des paramètres de cache par défaut, mais les pipelines de contenu généré ont toujours besoin d’une gestion explicite des erreurs, de contrôles de sécurité, de métadonnées et d’une attention aux Core Web Vitals. Le RAG aide Naly à écrire avec des preuves. L’ingénierie de production garantit que ces preuves atteignent les lecteurs rapidement, en sécurité et de façon répétée.