Manutenzione della LLM Wiki: Deriva, Contraddizioni e Revisione

Un Wiki LLM fallisce quando vecchi fatti rimangono plausibili, le contraddizioni diventano lucide e i riassunti generati si allontanano dalle loro fonti.

La manutenzione è il vero prodotto di qualsiasi sistema di conoscenza compilata. Creare pagine wiki è semplice rispetto al mantenerle affidabili nel corso di mesi di ingestione, modifiche, riscritture e nuove fonti.

Questo articolo copre l’aspetto operativo dei sistemi Wiki LLM: rilevamento delle derive, controlli delle contraddizioni, disciplina delle citazioni, linting, revisione Git e flussi di lavoro di manutenzione. Si presume che tu abbia già compreso il modello di base descritto in LLM Wiki - Conoscenza Compilata Che RAG Non Può Sostituire: le fonti grezze vengono compilate in pagine Markdown durevoli che umani e agenti possono interrogare in seguito. La visione calma ma opinata è che un Wiki LLM senza manutenzione è solo un cimitero di conoscenze dall’aspetto più curato.

Cosa Rende Diversa la Manutenzione del Wiki LLM

I wiki tradizionali marciscono perché le persone smettono di aggiornarli. I sistemi RAG subiscono derive perché il corpus cambia, i blocchi (chunks) diventano obsoleti, i metadati sono deboli e il recupero continua a trovare frammenti plausibili ma datati. La ragione più profonda è che recupero e risoluzione rappresentano problemi diversi: il recupero può essere ri-eseguito contro dati freschi, ma una rappresentazione che hai già compilato deve essere attivamente mantenuta onesta.

Un Wiki LLM ha un diverso modalità di fallimento. Può sembrare pulito anche quando è errato.

Le pagine potrebbero essere ben formattate. I link potrebbero funzionare. I riassunti potrebbero suonare equilibrati. Ma sotto quella superficie ordinata, il sistema potrebbe aver perso fatti critici, fuso concetti incompatibili, citato riassunti invece di fonti, o preservato una decisione vecchia come se fosse ancora valida.

È per questo che la manutenzione del Wiki LLM deve verificare sia la struttura che il significato.

L’Obiettivo della Manutenzione

L’obiettivo non è rendere ogni pagina perfetta. Questo è troppo costoso e di solito porta a sistemi abbandonati.

L’obiettivo è mantenere il wiki utile, ispezionabile e recuperabile.

Un Wiki LLM mantenuto dovrebbe rendere facile rispondere a queste domande:

• Quali fonti supportano questa affermazione?
• Quando è stata revisionata per l’ultima volta questa pagina?
• Questo concetto è cambiato?
• Ci sono pagine in conflitto?
• Questo riassunto è ancora attuale?
• L’agente ha riscritto più del dovuto?
• Possiamo annullare un aggiornamento errato?
• Un umano può capire perché la pagina dice quello che dice?

Se la risposta è no, il problema non è solo la qualità del contenuto. È il design del sistema.

Un Semplice Ciclo di Manutenzione

Un Wiki LLM utile ha bisogno di un ciclo ripetibile. Il ciclo dovrebbe essere abbastanza semplice da essere eseguito spesso e abbastanza rigoroso da catturare le derive prima che diventino invisibili.

Questo ciclo non è glamour. Questo è il punto.

Un sistema di conoscenza diventa durevole attraverso una manutenzione noiosa: preservazione delle fonti, revisione esplicita, struttura prevedibile e aggiornamenti piccoli e sicuri. Lo stesso istinto guida le note evergreen: una nota o una pagina wiki aumenta di valore solo se qualcuno continua a raffinarla invece di lasciarla marcire dopo la prima bozza.

Tipi di Deriva in un Wiki LLM

La deriva della conoscenza non è una sola cosa. Diversi tipi di deriva richiedono controlli diversi. Un buon sistema di manutenzione dovrebbe nominarli chiaramente.

Deriva delle Fonti

La deriva delle fonti si verifica quando il materiale sorgente sottostante cambia.

Ad esempio, uno strumento rilascia una nuova versione, una politica viene aggiornata, un’API cambia o un fornitore depreca una vecchia funzionalità. La vecchia pagina wiki potrebbe essere ancora accurata per la versione precedente, ma errata per l’uso corrente.

La deriva delle fonti è pericolosa perché la vecchia affermazione potrebbe essere ancora vera in un contesto storico. Il problema non è che l’affermazione sia falsa. Il problema è che non risponde più alla domanda attuale.

Risposta di manutenzione:

• Registrare le date delle fonti
• Registrare le date dell’ultima revisione
• Segnalare chiaramente le pagine specifiche per versione
• Collegare le vecchie pagine alle pagine che le sostituiscono
• Evitare di mescolare vecchie e nuove versioni senza etichette

Deriva dei Concetti

La deriva dei concetti si verifica quando il significato di un termine cambia nel tempo.

Questo è comune nell’IA e nell’architettura software. Termini come “agente”, “memoria”, “RAG”, “flusso di lavoro”, “utilizzo degli strumenti”, “output strutturato” e “ingegneria del contesto” possono cambiare significato rapidamente.

Un wiki può accidentalmente preservare diversi significati dello stesso termine senza spiegare la differenza. Questo crea pagine confuse che suonano coerenti ma combinano idee incompatibili.

Risposta di manutenzione:

• Mantenere pagine di glossario
• Aggiungere sezioni “significato in questo wiki”
• Separare i concetti sovraccaricati in pagine distinte
• Collegare esplicitamente i significati correlati
• Evitare che il modello fonda silenziosamente i termini

Deriva della Terminologia

La deriva della terminologia è più piccola della deriva dei concetti ma comunque dannosa.

Si verifica quando il wiki usa più nomi per la stessa cosa: “Wiki LLM”, “base di conoscenza compilata”, “wiki mantenuto dall’IA”, “wiki mantenuto dall’agente” e “base di conoscenza Markdown”.

Alcuna variazione è accettabile. Troppa variazione interrompe la ricerca, il collegamento e la revisione.

Risposta di manutenzione:

• Definire nomi canonici delle pagine
• Mantenere alias nel front matter o nei metadati della pagina
• Reindirizzare le pagine duplicate
• Eseguire lint per titoli quasi duplicati
• Usare testo ancorato coerente nei link interni

Deriva delle Decisioni

La deriva delle decisioni si verifica quando una decisione passata rimane documentata ma non riflette più la pratica attuale.

Ad esempio, una pagina potrebbe dire che il progetto usa il RAG vettoriale per tutte le ricerche di documenti, mentre le pagine più recenti descrivono un flusso di lavoro Wiki LLM. Entrambe le affermazioni potrebbero essere storicamente vere, ma il wiki deve mostrare quale è quella attuale.

Questo è importante per le note di architettura, i processi di ingegneria, la strategia dei contenuti e gli strumenti interni. La stessa disciplina si applica ai registri delle decisioni nello sviluppo guidato dall’IA: una pagina di decisione è affidabile solo se le scelte superate sono contrassegnate come superate piuttosto che sovrascritte silenziosamente.

Risposta di manutenzione:

• Contrassegnare le decisioni come proposte, accettate, superate o rifiutate
• Mantenere le date delle decisioni
• Collegare le decisioni superate alle sostituzioni
• Preservare il contesto storico
• Evitare di cancellare le vecchie decisioni senza traccia

Deriva delle Citazioni

La deriva delle citazioni si verifica quando una pagina cita una fonte, ma l’affermazione non corrisponde più a ciò che la fonte dice.

Questo può accadere dopo una riscrittura. La citazione rimane in posizione, ma la frase intorno ad essa cambia. La pagina sembra ancora supportata da fonti, ma la citazione non supporta più l’affermazione.

Questa è una delle modalità di fallimento più gravi del Wiki LLM perché crea falsa fiducia.

Risposta di manutenzione:

• Verificare il supporto alle citazioni a livello di affermazione
• Evitare di citare solo riassunti
• Mantenere le fonti grezze
• Richiedere citazioni per le affermazioni importanti
• Segnalare i paragrafi con fonti ma senza supporto diretto
• Revisionare le modifiche alle citazioni nei diff Git

Deriva della Struttura

La deriva della struttura si verifica quando il wiki perde lentamente navigabilità.

Vengono create nuove pagine invece di aggiornare quelle vecchie. Le pagine indice rimangono indietro. Appaiono pagine duplicate. Le pagine orfane si accumulano. Le pagine correlate smettono di collegarsi a vicenda.

Il wiki contiene ancora conoscenza utile, ma trovarla e fidarsi di essa diventa più difficile.

Risposta di manutenzione:

• Eseguire lint per le pagine orfane
• Mantenere le pagine indice
• Rilevare argomenti duplicati
• Richiedere backlink per le pagine canoniche
• Archiviare piuttosto che disperdere
• Mantenere ruoli delle cartelle chiari

I File di Manutenzione Core

Un Wiki LLM non dovrebbe affidarsi alla memoria, alle sensazioni o al prompting ripetuto. Ha bisogno di file operativi che dicano agli umani e agli agenti come mantenerlo.

Una struttura pratica potrebbe essere così:

llm-wiki/
  raw/
    sources/
    transcripts/
    documents/
  wiki/
    index.md
    concepts/
    entities/
    projects/
    decisions/
  maintenance/
    review-log.md
    lint-report.md
    stale-pages.md
    contradiction-report.md
  rules/
    AGENTS.md
    schema.md
    style-guide.md
    citation-policy.md
    source-policy.md

I nomi esatti non contano. I ruoli sì.

Il wiki ha bisogno di archiviazione delle fonti, pagine compilate, artefatti di revisione e regole che sopravvivano tra le sessioni.

AGENTS.md

AGENTS.md dovrebbe spiegare come l’agente è autorizzato a lavorare.

Dovrebbe rispondere a domande come:

• L’agente dovrebbe aggiornare le pagine esistenti prima di crearne di nuove?
• Quando dovrebbe chiedere una revisione?
• Come dovrebbe citare le fonti?
• Può riorganizzare le cartelle?
• Può riscrivere le vecchie pagine?
• Cosa dovrebbe fare con le contraddizioni?
• Cosa non dovrebbe mai cancellare?

Una regola utile è:

Preferisci aggiornamenti piccoli e supportati da fonti rispetto a riscritture ampie.

Questa sola frase previene molte cattive abitudini di manutenzione. Disegna anche un confine utile rispetto alla memoria degli agenti: la memoria modella come un agente si comporta nel momento, mentre il file delle regole del wiki modella cosa l’agente è autorizzato a cambiare nella base di conoscenza condivisa.

schema.md

schema.md dovrebbe definire la struttura della pagina.

Ad esempio:

# Titolo della Pagina

## Riassunto
Riassunto breve e attuale.

## Affermazioni Chiave
- Affermazione con riferimento alla fonte.
- Affermazione con riferimento alla fonte.

## Stato Attuale
Attuale, storico, superato, bozza o incerto.

## Dettagli
Spiegazione compilata principale.

## Pagine Correlate
Link interni.

## Fonti
Riferimenti alle fonti grezze.

## Note di Revisione
Data dell'ultima revisione e revisore.

Uno schema non deve essere rigido. Ma senza uno schema, il wiki diventa un mucchio di saggi inconsistenti. Lo schema dà all’agente qualcosa da preservare.

citation-policy.md

La politica delle citazioni dovrebbe dire cosa richiede una fonte. Al minimo, richiedere citazioni per:

• Affermazioni tecniche
• Confronti
• Comportamento del prodotto
• Dichiarazioni specifiche per versione
• Risultati dei benchmark
• Prezzi
• Affermazioni legali o di conformità
• Affermazioni sullo stato attuale
• Affermazioni copiate o derivate da una fonte

Una buona politica delle citazioni dice anche cosa non fare. Non citare una pagina compilata come se fosse la fonte originale. Non allegare citazioni a paragrafi che non supportano. Non mantenere una citazione dopo aver riscritto un’affermazione a meno che la fonte non la supporti ancora.

La disciplina delle citazioni è la differenza tra un Wiki LLM utile e una fiducia decorativa.

source-policy.md

La politica delle fonti dovrebbe definire come vengono archiviate le fonti grezze.

Ad esempio:

• Mantenere i file originali quando possibile
• Preservare URL e date di accesso
• Archiviare le note copiate separatamente dai riassunti generati
• Registrare il tipo di fonte
• Contrassegnare le fonti a bassa fiducia
• Evitare di sovrascrivere il materiale grezzo
• Mantenere le fonti superate quando spiegano decisioni storiche

Questa politica protegge il wiki da un errore comune: riassumere una fonte, scartare l’originale e trattare poi il riassunto come prova.

Questo non è gestione della conoscenza. È compressione con perdita di dati.

Cosa un Linter per Wiki LLM Dovrebbe Verificare

Un linter dovrebbe verificare prima la struttura. I problemi strutturali sono più facili da automatizzare e spesso rivelano problemi semantici più profondi.

I controlli strutturali utili includono:

• Link interni rotti
• Pagine orfane
• Titoli duplicati
• Sezioni delle fonti mancanti
• Date di revisione mancanti
• Pagine senza backlink
• Sezioni vuote o segnaposto
• Pagine molto lunghe senza struttura di sezioni
• Pagine senza link in arrivo da un indice
• Convenzioni di denominazione incoerenti
• Front matter non valido
• Pagine “attuali” obsolete più vecchie di una soglia di revisione

Questi controlli non provano che la conoscenza sia vera. Provano che il wiki è ancora manutenibile. Questo è un punto di partenza necessario.

Controlli Semantici

I controlli semantici sono più difficili ma più preziosi.

I controlli semantici utili includono:

• Affermazioni senza supporto diretto dalle fonti
• Due pagine che fanno affermazioni incompatibili
• Vecchie decisioni presentate come attuali
• Concetti duplicati con nomi diversi
• Una pagina di concetto che mescola diversi significati
• Riassunti che omettono vincoli noti
• Affermazioni “migliori” o “consigliate” senza criteri
• Affermazioni specifiche per versione senza etichette di versione
• Pagine che contraddicono fonti più recenti

Questi controlli non dovrebbero riscrivere automaticamente il wiki. Dovrebbero di solito produrre un rapporto per la revisione.

Il pattern più sicuro è:

Rileva automaticamente.
Spiega chiaramente.
Aggiorna deliberatamente.
Revisiona i cambiamenti rischiosi.

Rilevamento delle Contraddizioni

Il rilevamento delle contraddizioni non è solo chiedere a un LLM se due pagine si contraddicono.

Questo può aiutare, ma è troppo vago. Un approccio migliore è confrontare le affermazioni.

Un flusso di lavoro per le contraddizioni potrebbe essere così:

Questo funziona meglio perché molte contraddizioni apparenti non sono contraddizioni reali.

Una pagina potrebbe descrivere la versione 1.0 e un’altra la versione 2.0. Una pagina potrebbe descrivere l’uso personale e un’altra l’uso enterprise. Una pagina potrebbe descrivere l’obiettivo di design e un’altra la realtà dell’implementazione.

Il rapporto di contraddizione dovrebbe includere:

• Affermazioni in conflitto
• Pagine coinvolte
• Riferimenti alle fonti
• Contesto di data o versione
• Spiegazione probabile
• Risoluzione suggerita
• Se è richiesta la revisione umana

Non lasciare che l’agente risolva silenziosamente le contraddizioni fondendo entrambe le affermazioni in un compromesso vago. Questo crea un nonsenso liscio.

Come Risolvere le Contraddizioni

Ci sono diversi modi validi per risolvere una contraddizione.

• Se un’affermazione è obsoleta, contrassegnarla come superata e collegarla alla pagina più recente.
• Se entrambe le affermazioni sono vere in contesti diversi, separare il contesto chiaramente.
• Se le fonti sono in disaccordo, preservare il disaccordo e spiegarlo.
• Se la pagina wiki ha inventato o generalizzato eccessivamente un’affermazione, rimuovere o restringere l’affermazione.
• Se la contraddizione riflette una decisione reale non risolta, creare o aggiornare una pagina di decisione.

L’obiettivo non è rimuovere tutta la tensione. Qualche tensione è utile. Un buon wiki mostra dove la conoscenza è consolidata e dove è ancora incerta.

Revisione delle Pagine Obsolete

Ogni pagina compilata dovrebbe avere uno stato di revisione.

Un semplice blocco di metadati può essere sufficiente:

status: current
last_reviewed: 2026-07-10
review_after: 2026-10-10
source_confidence: medium

Per argomenti in rapida evoluzione, usa finestre di revisione brevi. Per concetti stabili, usa finestre più lunghe.

L’intervallo è meno importante dell’abitudine. Una pagina senza data di revisione è una pagina che alla fine mentirà silenziosamente.

Aggiornamenti Consapevoli delle Fonti

Quando arriva una nuova fonte, l’agente non dovrebbe semplicemente scrivere una nuova pagina di riassunto.

Dovrebbe chiedersi:

• Questo aggiorna un concetto esistente?
• Supera una fonte precedente?
• Contraddice una pagina esistente?
• Aggiunge una nuova entità o termine?
• Cambia una raccomandazione?
• Richiede un aggiornamento dell’indice?
• Influenza le pagine di decisione?

Un buon flusso di ingestione aggiorna il wiki come un grafo, non come una pila di riassunti isolati.

Questo è perché una fonte può toccare molte pagine. Questo è normale. La sfida di manutenzione è rendere questi aggiornamenti piccoli, revisionabili e tracciabili.

Revisione con Diff Git

Git è uno dei migliori strumenti di manutenzione per un Wiki LLM.

Non perché Git sia alla moda, ma perché la conoscenza generata ha bisogno di una storia dei cambiamenti revisionabile. Un diff Git mostra cosa l’agente ha cambiato, cancellato, spostato o riformulato.

Usa Git per revisionare:

• Nuove pagine
• Sezioni cancellate
• Affermazioni cambiate
• Citazioni cambiate
• Pagine rinominate
• Aggiornamenti degli indici
• Modifiche ai link
• Modifiche dello stato
• Riscritture ampie

L’abitudine di revisione più importante è ispezionare le cancellazioni. Gli LLM spesso rimuovono dettagli rendendo la prosa più pulita.

Una prosa pulita non è sempre conoscenza migliore.

Strategia di Commit Sicura

Evita commit giganti come:

Aggiorna wiki

Usa commit che spiegano l’operazione:

ingest: aggiungi note della fonte per il rilascio dell'embedding Qwen
maint: contrassegna il vecchio confronto dello store vettoriale come superato
lint: correggi i link interni rotti nelle pagine RAG
review: aggiorna le citazioni della pagina Wiki LLM
refactor: separa il concetto di memoria dell'agente dalla memoria a lungo termine

Questo dà a futuri umani e agenti una storia utile.

I messaggi di commit sono parte del sistema di conoscenza. Spiegano perché il wiki è cambiato.

Livelli di Revisione

Non ogni pagina ha bisogno dello stesso livello di revisione. Usa la revisione basata sul rischio.

Modifiche a basso rischio:

• Correzione di link rotti
• Pulizia del formato
• Aggiunta di backlink
• Aggiunta di voci dell’indice
• Correzione di refusi
• Aggiunta di alias

Modifiche a rischio medio:

• Aggiunta di riassunti delle fonti
• Creazione di nuove pagine di concetto
• Aggiornamento delle raccomandazioni
• Fusione di pagine duplicate
• Modifica dello stato della pagina

Modifiche ad alto rischio:

• Cancellazione di affermazioni
• Riscrittura di pagine canoniche
• Modifica dei registri delle decisioni
• Aggiornamento di affermazioni su sicurezza, legali, prezzi o benchmark
• Risoluzione delle contraddizioni
• Contrassegnazione dei contenuti come attuali o superati

Le modifiche ad alto rischio dovrebbero ricevere una revisione umana. Potresti essere tu, un maintainer o un proprietario del dominio.

L’agente può preparare il cambiamento, ma non dovrebbe essere sempre l’autorità finale.

Una Dashboard di Manutenzione

Una semplice dashboard di manutenzione può vivere in Markdown.

Esempio:

# Dashboard di Manutenzione Wiki LLM

## Necessita di Revisione
- wiki/concepts/agent-memory.md - revisione in ritardo
- wiki/projects/search-index.md - trovate affermazioni in conflitto

## Pagine Obsolete
- wiki/tools/ollama.md - ultima revisione 120 giorni fa
- wiki/concepts/rag.md - argomento in rapida evoluzione, revisione dovuta

## Link Rotti
- wiki/index.md -> wiki/concepts/old-page.md

## Pagine Orfane
- wiki/entities/vendor-x.md

## Rapporti di Contraddizione
- reports/contradictions/2026-07-10-agent-memory.md

## Ingestioni Recenti
- raw/sources/2026-07-09-new-paper.md

Questo non è un pannello amministrativo fancy. È una superficie di lavoro.

Per molti sistemi solisti o di piccoli team, una dashboard Markdown è sufficiente.

Metriche per un Wiki LLM Sano

Puoi tracciare la salute del wiki senza sovraingegnerizzarlo.

Le metriche utili includono:

• Numero di pagine
• Pagine senza fonti
• Pagine senza date di revisione
• Pagine oltre la data di revisione
• Link interni rotti
• Pagine orfane
• Titoli o alias duplicati
• Rapporti di contraddizione aperti
• Rapporti di contraddizione risolti
• Età media delle pagine per cluster
• Fonti grezze non ancora ingestite
• Pagine modificate senza revisione umana
• Pagine canoniche modificate negli ultimi 30 giorni

Queste metriche non sono numeri di vanità. Ti dicono se il sistema sta diventando più facile o più difficile da fidare.

Un wiki in crescita con pagine orfane in aumento e revisioni obsolete non sta compounding la conoscenza. Sta compounding il debito di manutenzione.

Prompt di Manutenzione

I prompt di manutenzione dovrebbero essere stretti. I prompt ampi producono riscritture ampie.

Prompt di Lint Strutturale

Revisiona la struttura del wiki.

Verifica per:
- link interni rotti
- pagine orfane
- titoli di pagina duplicati o quasi duplicati
- pagine mancanti delle sezioni delle fonti
- pagine mancanti dei metadati last_reviewed
- pagine indice che non collegano alle nuove pagine

Non riscrivere il contenuto.
Produce un rapporto Markdown con i risultati e le correzioni suggerite.

Prompt di Revisione delle Citazioni

Revisiona le citazioni per la pagina selezionata.

Per ogni affermazione importante:
- identifica la fonte di supporto
- verifica se la fonte supporta direttamente l'affermazione
- segnala le affermazioni con supporto debole, mancante o non corrispondente
- non riscrivere la pagina ancora

Restituisci una tabella con:
affermazione, citazione attuale, livello di supporto, problema, azione suggerita.

Prompt di Controllo delle Contraddizioni

Controlla questa pagina per contraddizioni rispetto alle pagine correlate.

Passaggi:
1. Estrai le principali affermazioni dalla pagina.
2. Trova pagine correlate attraverso link, backlink, alias e ricerca.
3. Estrai affermazioni potenzialmente in conflitto.
4. Classifica ogni conflitto come:
   - contraddizione reale
   - differenza di versione
   - differenza di ambito
   - differenza di terminologia
   - incertezza non risolta
5. Raccomanda una risoluzione.

Non modificare i file finché il rapporto di contraddizione non è revisionato.

Prompt di Revisione delle Pagine Obsolete

Revisiona questa pagina per l'obsolescenza.

Verifica:
- date
- affermazioni specifiche per versione
- comportamento degli strumenti
- raccomandazioni
- link a pagine superate
- fonti più recenti della data di revisione della pagina
- affermazioni contrassegnate come attuali senza supporto recente

Restituisci:
- mantieni attuale
- aggiornamento necessario
- contrassegna come storico
- contrassegna come superato
- dividi in pagine versionate

Prompt di Aggiornamento Sicuro

Aggiorna la pagina wiki selezionata usando la fonte fornita.

Regole:
- preservare la struttura esistente utile
- non rimuovere le affermazioni supportate a meno che la fonte non sia superata
- aggiungere citazioni per le nuove affermazioni
- contrassegnare esplicitamente l'incertezza
- aggiornare le pagine correlate solo quando necessario
- aggiungere una nota di revisione che spiega cosa è cambiato
- mantenere il diff piccolo

Questi prompt non sono magia. Sono guard rail. Il vero valore deriva dal rendere l’azione di manutenzione esplicita.

Errori Comuni di Manutenzione

Il primo errore è lasciare che l’agente riscriva troppo.

Le riscritture ampie sembrano produttive perché rendono le pagine più lisce. Rendono anche più difficile vedere cosa è cambiato e più facile perdere dettagli precisi.

Il secondo errore è trattare i riassunti generati come fonti.

Un riassunto può essere utile, ma non è la prova. Mantenere le fonti grezze e citarle quando le affermazioni contano.

Il terzo errore è creare nuove pagine invece di aggiornare quelle vecchie.

Questo produce concetti duplicati, raccomandazioni in conflitto e confusione nella ricerca. L’agente dovrebbe cercare prima, aggiornare secondo e creare nuove pagine solo quando il concetto è genuinamente nuovo.

Il quarto errore è cancellare il contesto storico.

Vecchie decisioni, esperimenti falliti e raccomandazioni superate possono essere preziose. Contrassegnarle chiaramente invece di cancellarle.

Il quinto errore è dimenticare gli indici.

Una pagina che non è collegata dal posto giusto è mezzo persa. La manutenzione degli indici non è lavoro di cancelleria. È architettura di navigazione.

Il sesto errore è usare la stessa politica di revisione per ogni pagina.

Una pagina concettuale stabile e un confronto di strumenti in rapida evoluzione non dovrebbero avere lo stesso programma di revisione.

Archiviare, Superare o Cancellare

La maggior parte delle pagine obsolete non dovrebbe essere cancellata immediatamente.

Una pagina superata dovrebbe collegare alla sostituzione.

Ad esempio:

Stato: superato
Superato da: wiki/concepts/agent-memory-architecture.md
Motivo: Questa pagina usava una definizione più vecchia di memoria dell'agente prima che il progetto separasse memoria della sessione, memoria dell'utente e conoscenza compilata.

Questo preserva il contesto e riduce la confusione.

La cancellazione dovrebbe essere rara e revisionabile. I sistemi di conoscenza hanno bisogno di potatura, ma la potatura invisibile è pericolosa.

Le Pagine Canoniche Hanno Bisogno di Cura Extra

Ogni Wiki LLM sviluppa eventually pagine canoniche.

Queste sono pagine che definiscono concetti fondamentali, scelte architetturali, flussi di lavoro o vocabolario del progetto. Sono più importanti delle note ordinarie perché molte altre pagine dipendono da esse.

Esempi:

• Cos’è il Wiki LLM
• RAG vs conoscenza compilata
• Memoria dell’agente
• Politica delle fonti
• Flusso di lavoro di revisione
• Architettura del progetto
• Glossario
• Indice

Le modifiche alle pagine canoniche dovrebbero richiedere una revisione più rigorosa.

Un piccolo errore su una pagina oscura è locale. Un piccolo errore su una pagina canonica può distorcere l’intero wiki.

Quanto Spesso Dovresti Eseguire la Manutenzione

Per un Wiki LLM attivo, esegui una piccola manutenzione frequentemente e una manutenzione profonda occasionalmente.

Il programma dovrebbe corrispondere al rischio. Un wiki di ricerca personale può essere più leggero. Un wiki usato per la pubblicazione tecnica, il supporto clienti o le decisioni di ingegneria ha bisogno di più disciplina.

Usare un Wiki LLM per la Pubblicazione Tecnica

Per un blog tecnico o un sito di documentazione, il Wiki LLM può diventare lo strato di conoscenza dietro la pianificazione degli articoli.

Può tracciare:

• Spiegazioni canoniche
• Definizioni ripetute
• Opportunità di link interni
• Confronti obsoleti
• Lacune degli articoli
• Cluster di argomenti
• Note delle fonti
• Decisioni sulla struttura
• Affermazioni che necessitano verifica

Questo è utile, ma alza la barra della manutenzione.

Se il wiki alimenta articoli pubblicati, allora le pagine wiki obsolete possono diventare contenuto pubblico obsoleto. Se il wiki contiene contraddizioni, quelle contraddizioni possono filtrare negli articoli. Se le citazioni sono deboli, le bozze generate erediteranno quella debolezza. I riassunti delimitati, l’estrazione basata su schema e i loop di revisione umana descritti in AI per la Gestione della Conoscenza: Flussi di Lavoro Reali Che Reggono sono un buon modello per mantenere quel pipeline editoriale onesto.

Per i flussi di lavoro di pubblicazione, tratta il Wiki LLM come un sistema editoriale, non solo come un taccuino privato. Un giardino digitale rende questo esplicito mostrando ai lettori quali pagine stanno ancora crescendo e quali sono mature, che è esattamente il tipo di segnale di stato che un Wiki LLM ben mantenuto dovrebbe anche esporre.

La Manutenzione Non è Opzionale

Un Wiki LLM è attraente perché promette conoscenza compounding.

Ma il compounding funziona solo se la vecchia conoscenza rimane utile. Altrimenti, il sistema compounding il rumore, non il洞察.

L’onere della manutenzione non scompare perché è coinvolto un agente. Cambia forma.

Gli umani non dovrebbero dover fare ogni compito tedioso. Gli agenti possono controllare i link, trovare le pagine obsolete, confrontare le affermazioni, redigere rapporti e proporre aggiornamenti. Ma gli umani hanno ancora bisogno di impostare la politica, revisionare i cambiamenti rischiosi e decidere cosa il wiki è autorizzato a significare.

Questo è il vero patto.

Conclusione

La manutenzione del Wiki LLM riguarda il mantenere la conoscenza compilata onesta.

Le pratiche importanti non sono complicate: preservare le fonti, citare le affermazioni, mantenere gli indici attuali, rilevare le contraddizioni, revisionare i diff Git, contrassegnare le pagine obsolete e evitare riscritture ampie non revisionate.

Un buon Wiki LLM non fa finta di essere magicamente autocorrettivo. Rende la correzione più facile.

Questo è lo standard a cui puntare: non conoscenza perfetta, ma conoscenza ispezionabile che può essere revisionata, riparata e fidata nel tempo.