Knowledge base AI: fonti obsolete e contraddittorie

Manuali, FAQ e procedure condividono argomenti ma hanno date e owner diversi. Una risposta può recuperare un documento corretto nel testo ma superato nella validità. Una knowledge base AI amplifica l’ambiguità quando conserva versioni obsolete o contraddittorie senza owner, validità e precedenza.

Mostra perché aumentare retrieval e contesto peggiora la risposta se la politica delle fonti non esiste. Gli anti-pattern sono pericolosi proprio perché riducono l’attrito nel percorso ideale e spostano il costo sul primo caso non previsto; il controllo associato riguarda «inventariare documenti autorevoli».

Il sistema registra un successo mentre l’operatore vede un caso sospeso; l’evidenza da conservare è «conflitti che richiedono revisione». Rischio nominato: «indicizzare cartelle senza selezione». Perimetro operativo: «governare versione, efficacia e conflitti delle fonti». Segnale osservato: «owner ed efficacia temporale». Recupero ammesso: «escludere versioni superate». Checkpoint finale: «owner ed efficacia temporale». Il segnale da cercare è una correzione manuale che non torna nel sistema come evento o regola; il controllo associato riguarda «versioni sostituite e motivazione».

Per correggere «indicizzare cartelle senza selezione» si registra «owner ed efficacia temporale» nel sistema autorevole. L’owner riprende il lavoro soltanto dallo stato prodotto da «inventariare documenti autorevoli».

La complessità è stata spostata, non eliminata. Rischio nominato: «usare la data file come unica autorità». Perimetro operativo: «governare versione, efficacia e conflitti delle fonti». Segnale osservato: «versioni sostituite e motivazione». Recupero ammesso: «mostrare data e fonte nella risposta». Checkpoint finale: «versioni sostituite e motivazione». Il segnale da cercare è una correzione manuale che non torna nel sistema come evento o regola; il controesempio viene cercato in «conflitti che richiedono revisione».

Per correggere «usare la data file come unica autorità» si registra «versioni sostituite e motivazione» nel sistema autorevole. L’owner riprende il lavoro soltanto dallo stato prodotto da «aggiungere metadati di validità».

L’assenza di un errore visibile viene scambiata per affidabilità. Rischio nominato: «nascondere fonti all’utente». Perimetro operativo: «governare versione, efficacia e conflitti delle fonti». Segnale osservato: «gerarchia fra fonti». Recupero ammesso: «creare una coda per conflitti». Checkpoint finale: «gerarchia fra fonti». Il segnale da cercare è una correzione manuale che non torna nel sistema come evento o regola; qui la prova concreta è «aggiungere metadati di validità».

Per correggere «nascondere fonti all’utente» si registra «gerarchia fra fonti» nel sistema autorevole. L’owner riprende il lavoro soltanto dallo stato prodotto da «escludere versioni superate».

Caso isolato: «owner ed efficacia temporale». Operazione osservata: «mostrare data e fonte nella risposta». Deviazione forzata: «usare la data file come unica autorità».

Sintomo da smontare: «usare la data file come unica autorità». La correzione deve riportare l’eccezione nel sistema che possiede la regola; l’evidenza da conservare è «mostrare data e fonte nella risposta». Perimetro della prova: «governare versione, efficacia e conflitti delle fonti».

Controprova: «gerarchia fra fonti». Arresto: «nessun processo di rimozione». Passo ammesso dopo il recupero: «inventariare documenti autorevoli». Verbale finale: «Come si evita che l’assistente citi una procedura non più valida?»

Differenza decisiva: «Mostra perché aumentare retrieval e contesto peggiora la risposta se la politica delle fonti non esiste». Regola di chiusura: «Prima dell’indice serve una regola di pubblicazione: chi rende valida una fonte, che cosa sostituisce e quando deve sparire dai risultati».

All’inizio sembra una scorciatoia innocua. Rischio nominato: «nessun processo di rimozione». Perimetro operativo: «governare versione, efficacia e conflitti delle fonti». Segnale osservato: «conflitti che richiedono revisione». Recupero ammesso: «inventariare documenti autorevoli». Checkpoint finale: «conflitti che richiedono revisione». Il segnale da cercare è una correzione manuale che non torna nel sistema come evento o regola; il caso operativo si verifica con «mostrare data e fonte nella risposta».

Per correggere «nessun processo di rimozione» si registra «conflitti che richiedono revisione» nel sistema autorevole. L’owner riprende il lavoro soltanto dallo stato prodotto da «mostrare data e fonte nella risposta».

Dopo aver reso visibili i fallimenti, si interviene dal confine più piccolo; il controllo associato riguarda «aggiungere metadati di validità». Le azioni proposte mantengono separati processo, controllo e tecnologia.

Prima dell’indice serve una regola di pubblicazione: chi rende valida una fonte, che cosa sostituisce e quando deve sparire dai risultati. Il miglioramento è reale quando lo stesso caso può essere seguito dall’ingresso all’uscita senza ricostruzioni private; nel perimetro descritto conta «nascondere fonti all’utente».

Prima dell’indice serve una regola di pubblicazione: chi rende valida una fonte, che cosa sostituisce e quando deve sparire dai risultati. L’anti-pattern è davvero rimosso soltanto quando «nascondere fonti all’utente» non richiede più memoria privata e «escludere versioni superate» lascia la prova «versioni sostituite e motivazione».