Note di ingegneria Naly: redazione di articoli RAG con priorità alle fonti per una pubblicazione persistente e verificabile

TL;DRLa generazione aumentata dal retrieval (RAG) trasforma la pipeline degli articoli di Naly in un sistema editoriale ancorato alle fonti invece che in una composizione basata sulla memoria del modello. Ogni richiesta di bozza raccoglie prima prove web e arXiv, normalizza e persiste gli URL delle fonti e poi chiede al modello di produrre una bozza answer-first e l’articolo HTML finale. Questo sposta il rischio da "il modello può allucinare?" a "il layer di retrieval è completo e tracciabile", offrendo agli editori artefatti stabili, job ripetibili e affermazioni pubbliche difendibili.

Abstract

Il RAG in Naly dovrebbe essere progettato attorno a persistenza delle fonti e contratti deterministici. Il 27 giugno 2026, l’affidabilità pratica dipende meno da un modello più grande e più dal fatto che gli artefatti di retrieval siano interrogabili, versionati e validati prima della pubblicazione. Questa nota propone un design a doppio piano: un piano delle evidenze per retrieval/storage e un piano di generazione per la stesura, quindi argomenta come questa architettura migliori direttamente la fiducia editoriale e la gestione degli incidenti.

Dove si colloca in Naly

Naly esegue questo come sottosistema di contenuti in produzione all’interno di uno stack Next.js 16.0.7 App Router (next + react), dove la pubblicazione degli articoli fa parte dei percorsi di codice runtime anziché di un passaggio offline separato di stesura. Il percorso del job dell’articolo è dove vanno applicati tutti i vincoli: un job non viene "scritto" finché non esistono i record delle fonti, la struttura del riepilogo è valida e l’HTML viene materializzato.

L’allineamento dello stack è intenzionale:

next@16.0.7 + I React Server Components ospitano il rendering triggerato dal job nello spazio server, in linea con i contratti di output lato server per gli articoli.
drizzle-orm@0.44.7 + @neondatabase/serverless@1.0.2 definiscono tabelle tipizzate e persistenti per job e fonti, così ogni claim può essere tracciato.
ai@6.0.0-beta.105 fornisce alla generazione controlli sull’output consapevoli dello schema.
marked@17.0.1 converte i riepiloghi Markdown generati in HTML renderizzato per la pubblicazione.
@vercel/blob@2.0.0 salva gli asset generati come URL durevoli per il riuso.
Lo strumento Anthropic può essere aggiunto come provider alternativo nel medesimo perimetro contrattuale, ma non come via d’uscita dai vincoli strutturati.

Ciò sostituisce un modello "genera poi correggi" con un ciclo di scrittura basato sulle fonti: retrieval, validazione, generazione, rendering e pubblicazione devono passare tutti prima che l’articolo diventi visibile.

Meccanismo tecnico

Un design robusto di Naly ha cinque fasi delimitate:

Piano delle prove e orchestrazione delle query

Definire lo specifico job con topic, finestra temporale e policy di evidenza.
Eseguire sia la ricerca web sia la ricerca arXiv per fonti primarie.
Deduplicare per URL canonico e normalizzare protocollo, host e query string.

Livello di persistenza delle fonti

Conservare i metadati per URL (url, URL canonicalizzato, stato fetch, timestamp di fetch, titolo, excerpt, tipo di fonte).
Conservare gli snippet orientati al modello separatamente dai payload grezzi, così i ri-esecuzioni restano deterministiche anche se le pagine upstream cambiano.
Aggiungere checksum per ogni fonte per rilevare eventuali drift.

Formazione del contesto e vincoli

Costruire un contesto di retrieval ordinato per pertinenza e recenza.
Richiedere ID fonte espliciti nel contratto del prompt.
Imporre la forma dell’output answer-first (intro claim, evidence bullets, risk caveats, uncertainty), più riferimenti alle fonti ordinati.

Generazione strutturata con schema rigoroso

Usare output strutturato in modo che risposte malformate o non conformi allo schema falliscano velocemente e vengano ritentate con contesto più stretto.
Mantenere la generazione nel contesto server e rifiutare draft che reclamano fatti non supportati senza ID fonte mappati.

Render, pubblicazione e verifica

Convertire il Markdown validato in HTML e persistere sia markdown sia HTML.
Memorizzare in cache l’output finale solo dopo la validazione riuscita.
Emettere campi operativi e di audit: conteggio fonti, claim rifiutati, numero di retry, e latenza di generazione.

Il cambiamento di design più importante è la separazione delle preoccupazioni: qualità del retrieval e qualità della generazione sono domini di errore differenti con metriche diverse. I React Server Components si adattano a questa separazione perché il rendering può rimanere deterministico mentre retrieval e generazione avvengono in task asincroni controllati.

Cosa dice la letteratura

La letteratura RAG recente supporta questo pattern architetturale. Una survey del 2024 sull’architettura RAG descrive come i sistemi retrieval-augmented riducano il drift dei fatti condizionando la generazione su evidenze esterne, ma segnala trade-off in complessità di pipeline e coordinazione modulare [Gupta et al., 2024]. Una survey di follow-up del 2025 aggiunge che l’affidabilità dipende ora da retrieval adattivo, controllo del decoding e valutazione end-to-end, più che dalla sola qualità della generazione [Sharma, 2025].

Per il controllo qualità in produzione, la survey del 2025 incentrata sulla valutazione divide esplicitamente la valutazione in metriche interne retriever/generator e metriche del sistema esterno; questa decomposizione è particolarmente utile per le pipeline editoriali perché un "cattivo articolo" può significare scelta errata delle fonti anche quando la qualità linguistica è alta [Gan et al., 2025]. Le ricerche specifiche sulla groundedness sono anche andate verso livelli di detection che classificano il supporto delle affermazioni usando contesto recuperato e controlli stile NLI, rafforzando il valore pratico della validazione post-generazione [Gerner et al., 2025].

In breve, i paper convergono su una tesi: il RAG non è solo un modo per iniettare contesto, è un contratto di ingegneria tra retrieval e generazione. Naly dovrebbe quindi ottimizzare il contratto, non solo il prompt.

Trade-off di design

Freshness vs determinismo: TTL più stringenti riducono la stalezza ma aumentano il costo di re-fetch. Persistendo gli snapshot si può mantenere un rendering deterministico pur rivalidando le finestre di freschezza.
Recall vs precision nel retrieval: un recupero più ampio può aumentare la copertura ma introdurre rumore; un filtro di rilevanza in seconda fase protegge la qualità dei claim.
Rigidità dello schema vs fluidità della prosa: schemi di output rigidi migliorano l’affidabilità automatica ma possono ridurre la libertà stilistica. Il pattern answer-first mantiene la leggibilità preservando le guardrail.
Velocità del rendering statico vs auditabilità: l’HTML pre-renderizzato migliora le prestazioni di delivery e riduce il calcolo ripetuto, ma solo se gli artefatti delle fonti usati sono riferimenti immutabili.
Complessità vs costo operativo: ogni passaggio di validazione aggiunto (controlli sulle fonti, controlli di schema, persistenza artefatti) aumenta la latenza. Le linee guida Next in produzione su caching, boundary di route e verifica al build time sono fondamentali per mantenere tutto operativo.

Modalità di failure

Source drift: gli URL restituiscono 404/soft-change dopo la creazione del job. Mitigazione: chiave canonica + hash snapshot + catena di fallback delle fonti.
Eccesso di retrieval: recall elevato con precisione bassa provoca sintesi plausibili ma non supportate. Mitigazione: richiedere vincoli evidence-first e bloccare claim senza match con fonti.
Errore di formattazione del modello: mismatch di schema o JSON troncato in generazione. Mitigazione: validazione schema rigorosa e retry con contesto ridotto.
Race di doppia pubblicazione: lavoratori concorrenti possono pubblicare artefatti parziali. Mitigazione: chiavi di idempotenza dei job, transizioni di stato a livello di riga (pending -> drafting -> validated -> published).
Regressioni nel rendering: Markdown malformato o trasformazioni HTML non sicure. Mitigazione: percorso di marked conversione deterministico e test sull’output HTML legati a manifest campione.
Illusioni di cache: dati dinamici obsoleti nell’output server possono desincronizzare testo pubblicato e indice delle fonti. Mitigazione: allineare la strategia di rendering delle route con una policy di freschezza runtime esplicita ed evitare cache implicite dove è richiesta freschezza delle evidenze.

Note di implementazione

Per un rollout pratico, trattarlo come un contratto di pubblicazione:

Definire tabelle fonti in Drizzle con vincoli espliciti: unicità URL per host/percorso canonico, enum dello stato di fetch e colonne checksum.
Usare in modo coerente un driver path compatibile con Neon per il comportamento serverless; la documentazione Drizzle descrive opzioni runtime-specifiche e neon-* opzioni del driver.
In generazione, applicare contratti di output strutturato e fallire sugli oggetti non validi prima del rendering.
Usare le linee guida Next.js per server boundaries, pagine di errore, caching e metadata SEO delle route degli articoli così la pubblicazione resta osservabile e veloce.
Persistere i blob generati (ad esempio immagini di copertina, allegati, esportazioni) tramite Vercel Blob con policy di accesso esplicita e naming deterministico per evitare collisioni.
Eseguire controlli operativi prima della pubblicazione: conteggio minimo di fonti, diversità minima delle fonti, freschezza delle evidenze e tasso minimo di completamento per i claim mappati.

Questo è lo spostamento chiave: l’articolo non è più giudicato in base all’astuzia del modello; è giudicato da quanto evidenza e generazione restano sincronizzate durante retry e redeploy.