Note ingegneristiche di Naly: scrittura di articoli retrieval-augmented con fonti persistenti

Abstract

La generazione retrieval-augmented dà alla pipeline di articoli di Naly una memoria di ricerca più fresca e più verificabile dei soli pesi del modello. Per ogni nota ingegneristica o lavoro di articolo di market intelligence, il sistema può cercare sul web e su arXiv, conservare gli URL delle fonti insieme all'artefatto generato, chiedere al modello di rispondere prima di tutto e renderizzare il risultato come HTML. Il punto non è l'automazione fine a sé stessa; è pubblicare affermazioni che i lettori possono rintracciare.

La tesi è semplice: il RAG per la scrittura di articoli dovrebbe essere trattato come un sistema di evidenze di produzione, non come un pattern da chatbot. A un chatbot si può perdonare una risposta debole; un articolo pubblicato diventa una superficie di fiducia durevole. L'implementazione di Naly ha quindi bisogno di tre invarianti: retrieval prima della stesura, registri delle fonti che sopravvivono dopo la pubblicazione e un renderer che preservi Markdown leggibile evitando HTML non sicuro.

Dove si colloca in Naly

I job degli articoli di Naly si collocano tra l'acquisizione della ricerca e la pubblicazione pubblica. Il job parte da un argomento selezionato, genera intenti di ricerca, recupera materiale dal web e da arXiv, normalizza i risultati in registri di fonte e poi chiede a un modello di scrivere un articolo answer-first a partire da quell'insieme delimitato di evidenze. L'output non è solo prosa. È un pacchetto: contenuto Markdown, HTML renderizzato, URL delle fonti, titoli delle fonti, tipi di fonte e metadati sufficienti a spiegare perché ogni fonte è stata usata.

Questo conta per il ciclo di fiducia di Naly. La postura editoriale più ampia di Naly è pubblicare ciò che gli altri nascondono: memo decisionali, limiti di calibrazione, fallimenti e le evidenze dietro le affermazioni. La generazione supportata da fonti rende operativa quella postura. I lettori non dovrebbero dover indovinare se un'affermazione provenga dai dati di addestramento di un modello, da un documento ufficiale, da un paper o da un'affermazione dell'operatore.

Il layer RAG appartiene alla fase prima della stesura, non dopo. L'aggiunta di citazioni a posteriori è più debole perché il modello ha già formato le affermazioni. In un design più solido, il retrieval vincola il contesto di generazione, e la generazione produce affermazioni che possono essere verificate rispetto all'insieme recuperato. L'articolo visibile può restare conciso, ma l'artefatto archiviato dovrebbe conservare la traccia di ricerca.

Meccanismo tecnico

Per la scrittura di articoli, il flusso RAG di Naly è una pipeline batch:

La selezione dell'argomento crea una domanda di ricerca delimitata, per esempio come la generazione retrieval-augmented fonda su fonti la scrittura di articoli.
La pianificazione delle query espande quella domanda in query web, query su documenti ufficiali e query arXiv.
Il retrieval raccoglie documentazione ufficiale, paper primari e fonti esplicative ad alto segnale.
La normalizzazione estrae titolo, URL canonico, tipo di fonte, contesto di pubblicazione o aggiornamento quando disponibile, e snippet o abstract rilevanti.
La persistenza delle fonti archivia il registro degli URL prima della generazione, così l'articolo può essere auditato in seguito.
L'assemblaggio del prompt fornisce al modello l'argomento, i fatti implementativi specifici di Naly, i vincoli di scrittura e le evidenze recuperate.
La generazione produce Markdown con un abstract answer-first, modalità di fallimento esplicite e una sezione di riferimenti.
La validazione controlla che ogni riferimento nell'articolo renderizzato corrisponda a un oggetto fonte archiviato.
Il rendering converte Markdown in HTML per il sito, applicando al tempo stesso sanitizzazione e controlli di produzione.

Questo è vicino al pattern di retrieval e augmented generation descritto nella guida RAG di Vercel: recuperare prima il contesto rilevante, poi combinarlo con la domanda dell'utente o del job prima della generazione. La differenza è che Naly non ottimizza per il supporto conversazionale. Ottimizza per una pubblicazione durevole, in cui un URL di fonte è parte del modello dati dell'articolo.

L'AI SDK è un layer di orchestrazione naturale per questo tipo di job perché la sua interfaccia di generazione testuale supporta automazione non interattiva, chiamate a strumenti, risultati multi-step e metadati delle fonti quando i provider restituiscono fonti URL. Anche quando un provider non restituisce oggetti fonte nativi, Naly può allegare la propria lista di fonti recuperate all'artefatto dell'articolo e trattare le fonti native del modello come supplementari anziché autorevoli.

Cosa dice la letteratura

La formulazione originale del RAG di Lewis et al. inquadrava bene il problema centrale: i modelli linguistici parametrici conservano fatti nei pesi, ma aggiornare quella conoscenza e fornire provenienza restano operazioni difficili. Il loro modello retrieval-augmented combinava un modello sequenziale con un indice vettoriale denso e ha trovato una generazione più specifica, diversificata e fattuale rispetto a una baseline solo parametrica su compiti ad alta intensità di conoscenza.

La successiva survey sul RAG di Gao et al. generalizza quell'idea in una tassonomia: naive RAG, advanced RAG e modular RAG. La pipeline di articoli di Naly dovrebbe essere modulare. Retrieval, ranking, persistenza delle fonti, costruzione del prompt, generazione, validazione dei riferimenti e rendering sono unità separate con modalità di fallimento separate. Trattarle come unità separate rende il sistema più facile da debuggare quando un articolo cita una fonte debole o ne manca una migliore.

Self-RAG aggiunge una cautela importante. Asai et al. sostengono che recuperare un numero fisso di passaggi, che il retrieval sia necessario o meno, può degradare la qualità dell'output. Per Naly, questo significa che il retrieval top-k non dovrebbe essere un rituale. Un breve articolo su una funzionalità stabile di un framework può aver bisogno della documentazione ufficiale e di un solo paper; un articolo ricco di letteratura può richiedere più fonti arXiv e una survey. La profondità del retrieval dovrebbe seguire il rischio delle affermazioni.

RAGChecker offre la lezione di valutazione. Ru et al. sostengono che i sistemi RAG abbiano bisogno di diagnostiche a grana fine sia sul retrieval sia sulla generazione, specialmente per risposte long-form. Per Naly, l'unità di valutazione non dovrebbe essere solo la qualità dell'articolo. Dovrebbe includere recall del retrieval, rilevanza delle fonti, supporto alle affermazioni, copertura dei riferimenti e l'eventuale ingresso di affermazioni non supportate nel Markdown finale.

Trade-off progettuali

Alta recall contro basso rumore è il trade-off centrale. Più retrieval aumenta la probabilità di trovare la fonte giusta, ma aumenta anche la probabilità che snippet deboli entrino nel prompt e orientino il modello. Naly dovrebbe preferire un approccio a fasi: raccolta ampia, filtraggio rigoroso, poi contesto di prompt compatto.

La persistenza delle fonti migliora l'auditabilità, ma crea anche lavoro di archiviazione e manutenzione. Gli URL cambiano, i paper vengono revisionati e le pagine di documentazione si spostano. Il registro durevole dovrebbe includere URL canonico, timestamp del fetch, titolo, tipo di fonte e idealmente un digest del contenuto o un confine dell'estratto. Questo permette a Naly di distinguere un errore del modello da una fonte cambiata.

La scrittura answer-first migliora il valore per il lettore, ma può comprimere l'incertezza in modo troppo aggressivo. L'articolo dovrebbe aprire con la conclusione preservando una sezione successiva per modalità di fallimento e caveat. Il riepilogo answer-first è il punto di ingresso; non è una licenza per appiattire le evidenze.

L'HTML renderizzato migliora distribuzione ed esperienza di lettura, ma crea un confine di sicurezza. Marked è veloce e utile per il parsing di Markdown, ma la sua documentazione avverte esplicitamente che non sanitizza l'HTML in output. Un renderer di articoli Naly dovrebbe sanitizzare l'HTML generato e mantenere disponibile la fonte Markdown fidata per la riproduzione.

Modalità di fallimento

Mancato retrieval: la fase di ricerca trova fonti plausibili ma incomplete. Di solito succede quando il pianificatore di query è troppo stretto o usa termini di prodotto diversi da quelli della letteratura. Mitigazione: usare più stili di query, includere la documentazione ufficiale e richiedere almeno due fonti primarie o arXiv quando l'articolo fa affermazioni di ricerca.

Riciclaggio della citazione: una fonte appare nei riferimenti, ma non supporta davvero la frase vicina. Questo è peggio che non avere alcuna citazione perché crea falsa fiducia. Mitigazione: validare le affermazioni rispetto agli snippet delle fonti e respingere gli articoli in cui i riferimenti sono soltanto tematici.

Deriva delle fonti obsolete: una pagina di documentazione ufficiale cambia dopo la pubblicazione. Mitigazione: persistere i metadati della fonte al momento della generazione e registrare l'etichetta della data. Per le fonti che sostengono affermazioni importanti, archiviare uno snapshot o un digest dove la licenza lo consente.

Over-retrieval: troppi chunk fanno sì che il modello riassuma il contesto invece di rispondere alla tesi dell'articolo. Mitigazione: usare il ranking delle fonti, deduplicare documenti quasi identici e limitare le evidenze nel prompt in base alla rilevanza per le affermazioni invece che al conteggio grezzo.

Avvelenamento del contesto: pagine spam, pagine SEO generate o riepiloghi di bassa qualità superano nei ranking il materiale primario. Mitigazione: classificare documentazione ufficiale, arXiv, standard e repository sorgente sopra il commento secondario, salvo che l'articolo riguardi esplicitamente la ricezione nel settore.

Rischio del renderer: il Markdown generato può includere HTML grezzo, link non sicuri o tabelle malformate. Mitigazione: sanitizzare l'HTML renderizzato, normalizzare i link, respingere contenuti eseguibili tramite script ed eseguire controlli di produzione coerenti con le linee guida Next.js su performance, sicurezza, metadati e accessibilità.

Note di implementazione

Dati i fatti runtime attuali di Naly, l'architettura pulita è un job TypeScript che usa ai@6.0.0-beta.105 per l'orchestrazione del modello, strumenti di retrieval web e arXiv per la raccolta di evidenze, Drizzle ORM con Neon per i registri di articoli e fonti, marked@17.0.1 per il rendering da Markdown a HTML, e Next.js 16 per la superficie di pubblicazione.

Il database dovrebbe trattare le fonti come righe di prima classe, non come un blob di testo Markdown. Uno schema pratico ha una tabella articoli, una tabella di join articolo-fonte e campi fonte per URL, titolo, tipo di fonte, timestamp di retrieval, identificatore canonico come l'arXiv ID quando disponibile, e stato di estrazione. Il record dell'articolo può quindi puntare a Markdown, HTML renderizzato, riepilogo, punti chiave e metadati di pubblicazione.

Vercel Blob è utile per artefatti più grandi o output di rendering immutabili, mentre Postgres resta migliore come registro interrogabile per fonti e metadati degli articoli. Questa separazione mantiene economiche le query di audit: elencare ogni articolo che ha usato una fonte, ogni fonte usata da un articolo e ogni articolo in cui l'estrazione delle fonti è fallita.

Il prompt del generatore dovrebbe richiedere disciplina sulle fonti nella forma dell'output: nessuna affermazione non supportata, nessun URL inventato e una sezione di riferimenti i cui link devono corrispondere alla lista di fonti persistita. Il modello può scrivere prosa fluida, ma il job dovrebbe possedere la verità sulle fonti. Se il modello emette un riferimento che non è stato recuperato, il validatore dovrebbe far fallire l'articolo invece di pubblicarlo in silenzio.

Infine, il comportamento in produzione conta. Next.js fornisce già server components, code splitting, prerendering e default di caching, ma le pipeline di contenuti generati hanno comunque bisogno di gestione esplicita degli errori, controlli di sicurezza, metadati e attenzione ai Core Web Vitals. Il RAG aiuta Naly a scrivere con evidenze. L'ingegneria di produzione assicura che quelle evidenze raggiungano i lettori rapidamente, in sicurezza e ripetutamente.