Una pipeline editoriale locale deve tenere distinti tre lavori: misurare caratteristiche del testo, recuperare riferimenti pertinenti e generare suggerimenti. Possono convivere nello stesso prodotto, ma non hanno le stesse metriche né richiedono necessariamente lo stesso modello.
Nel lavoro su piattaforme editoriali come AI Multisite, considero utile questa separazione perché rende più chiaro cosa sta valutando la redazione. Un suggerimento può suonare simile alla voce dell’autore e aver cambiato un fatto; un classificatore può riconoscere l’argomento senza aver riconosciuto lo stile.
Definire che cosa significa “stile” nel prodotto
Partirei da caratteristiche leggibili: lunghezza delle frasi, punteggiatura, ricorrenze lessicali, forme sintattiche e struttura dei paragrafi. Non tutte hanno lo stesso valore per ogni corpus. Il profilo di una rubrica può inoltre riflettere il lavoro della redazione, oltre a quello del singolo autore.
La ricerca Topic or Style? studia proprio il peso di argomento e stile nell’attribuzione autoriale. Il Topic Confusion Task propone una valutazione che mette in evidenza questa interferenza. Ne ricavo un criterio progettuale: il test deve includere autori che scrivono di temi diversi e temi trattati da autori diversi.
Un embedding semantico può aiutare a recuperare esempi pertinenti, ma non lo chiamerei automaticamente “vettore dello stile”. Prima occorre dimostrare che catturi le proprietà che il prodotto vuole usare.
Disegnare una richiesta completa
Il CMS invia il testo e il tipo di intervento richiesto. Il backend verifica utente e tenant, seleziona i riferimenti autorizzati e prepara il contesto. Il servizio di inferenza produce un suggerimento; il backend ne controlla formato e limiti prima di mostrarlo alla persona che sta scrivendo.
Inizierei da un compito ristretto, per esempio proporre una versione più breve di un paragrafo preservando nomi, numeri e attribuzioni. Conserverei originale e proposta affiancati. Una variazione delle citazioni o l’introduzione di un fatto nuovo deve essere visibile, non nascosta dentro un punteggio di somiglianza.
Per ogni richiesta registrerei versione del modello, template e configurazione. Nei log operativi eviterei il testo integrale degli articoli; gli eventuali campioni per la valutazione avrebbero accessi e conservazione definiti separatamente.
Valutare il risultato con la redazione
Preparerei una rubrica di valutazione con criteri separati: fedeltà ai fatti, utilità dell’intervento, rispetto della voce e correzioni necessarie. Gli errori sui fatti non devono essere compensati da un buon giudizio sullo stile.
Il campione finale deve restare distinto dagli esempi usati per adattare prompt e soglie. Includerei testi brevi, lunghi e fuori dalla distribuzione più comune. Per le valutazioni umane, nasconderei quando possibile il nome del modello e controllerei i disaccordi tra valutatori.
Dimensionare memoria e attesa sul carico reale
Il prompt comprende articolo, istruzioni e riferimenti; il contesto richiesto comprende anche l’output previsto. Una singola prova con un testo medio non descrive il comportamento di più redattori che inviano richieste insieme.
Misurerei richieste concorrenti, lunghezze e tempi per fascia di carico. La documentazione delle metriche vLLM distingue attesa in coda, fasi di inferenza e latenza: l’endpoint HTTP del CMS aggiunge altro lavoro, quindi il suo tempo totale va misurato a parte.
Un p95 di latenza è un percentile delle durate osservate, non la somma dei p95 di ogni fase. Analogamente, per un throughput il lato lento della distribuzione sta nei valori bassi. Dichiarare definizione, unità e campione evita confronti numerici ingannevoli.
Il confine dei dati deve valere anche durante un picco
Se il requisito è elaborazione esclusivamente locale, una coda lunga deve produrre attesa, rifiuto controllato o rinvio. Non deve attivare un provider esterno. Un eventuale percorso cloud richiede una policy compatibile con quei dati, definita prima della richiesta e applicata dal backend.
Controllerei anche embedding, telemetria, strumenti e servizi di supporto: scaricare i pesi sul server non rende locale l’intero processo. Accesso privato e autorizzazione tra tenant sono poi controlli distinti.
Il criterio di adozione è l’insieme di qualità editoriale, tempi accettabili e gestione sostenibile. I test sui modelli locali e il dimensionamento della memoria sono due parti della verifica; nessuna delle due, da sola, dimostra che la pipeline sia pronta.