Recupero vs Rappresentazione nei Sistemi di Conoscenza
La ricerca non è struttura della conoscenza
La maggior parte dei sistemi di conoscenza moderni ottimizza il recupero (retrieval), ed è comprensibile. La ricerca è visibile, facile da dimostrare e sembra magica quando funziona. Scrivi una domanda, ottieni una risposta.
Ma il recupero è solo metà del problema. La domanda più profonda è:
Qual è la forma della conoscenza prima che qualsiasi cosa tenti di recuperarla?
Questa è la rappresentazione — la struttura dietro la conoscenza:
- note
- pagine
- schemi
- grafi
- entità
- relazioni
- sintesi
- tassonomie
- confini delle fonti
- versioni canoniche
Il recupero chiede:
Posso trovare qualcosa di rilevante?
La rappresentazione chiede:
La conoscenza è organizzata in un modo che ha senso?
Questi non sono lo stesso problema. Un sistema RAG con una scarsa rappresentazione diventa un’interfaccia veloce verso un archivio disordinato. Può recuperare frammenti, ma non può correggere una struttura rotta. Può citare documenti, ma non può decidere quale sia canonico. Può assemblare il contesto, ma non può garantire che la conoscenza sottostante sia coerente.
Questo è il motivo per cui sistemi in stile LLM Wiki sono interessanti: spostano lo sforzo dal momento della query al momento dell’ingestione. Invece di recuperare solo blocchi quando un utente fa una domanda, tentano di pre-strutturare la conoscenza in pagine, concetti, sintesi e link. Questo non rende il RAG obsoleto — significa che il recupero e la rappresentazione sono livelli diversi, e i buoni sistemi di conoscenza hanno bisogno di entrambi.
La distinzione fondamentale
Il recupero riguarda l’accesso; la rappresentazione riguarda il significato.
| Livello | Domanda | Esempi |
|---|---|---|
| Recupero | Come trovo le informazioni giuste? | ricerca, embedding, BM25, riordinamento, store vettoriali |
| Rappresentazione | Come è strutturata la conoscenza? | note, wiki, grafi, schemi, ontologie |
| Ragionamento | Come uso la conoscenza? | sintesi, confronto, inferenza, presa di decisioni |
Un sistema debole salta spesso direttamente al recupero; un sistema forte chiede prima:
- Quali sono i concetti fondamentali?
- Qual è la fonte canonica?
- Quali relazioni sono importanti?
- Cosa cambia nel tempo?
- Cosa dovrebbe essere recuperato?
- Cosa dovrebbe già essere rappresentato?
Questa è la differenza tra la ricerca sui documenti e un vero sistema di conoscenza.
Perché il recupero è diventato dominante
Il recupero è diventato dominante perché si mappa bene sullo stack AI moderno. Un tipico pipeline RAG appare così:
- Carica documenti
- Dividili in blocchi (chunks)
- Genera embedding
- Archivia i vettori
- Recupera i blocchi rilevanti
- Riordinarli opzionalmente
- Inserirli in un prompt LLM
- Genera una risposta
Questo pipeline è pratico: è relativamente facile da costruire, funziona con documenti disordinati, scala a corpus di grandi dimensioni, evita il riaddestramento dei modelli e dà agli LLM accesso a informazioni attuali. Ecco perché il RAG è diventato il modello predefinito per “AI sui documenti”.
Ma c’è una trappola:
Il RAG migliora l’accesso alla conoscenza. Non migliora automaticamente la conoscenza.
Se il tuo contenuto è duplicato, superato, contraddittorio, suddiviso in blocchi in modo sbagliato o denominato male, il recupero metterà in evidenza questi problemi — spesso con molta confidenza.
Cosa significa rappresentazione
La rappresentazione è il modo in cui la conoscenza viene modellata prima che avvenga il recupero. Risponde a domande come:
- Questa conoscenza è memorizzata come documenti, note, entità o fatti?
- Le relazioni sono esplicite o implicite?
- Esistono pagine canoniche?
- Ci sono sintesi?
- I concetti sono collegati?
- Il sistema è organizzato per argomento, flusso di lavoro, tempo o proprietà?
- Un essere umano può mantenerlo?
- Una macchina può ragionare su di esso?
La rappresentazione non è decorazione — determina quali tipi di operazioni sono possibili.
Forme di rappresentazione
Documenti
I documenti sono la rappresentazione più comune. Gli esempi includono:
- articoli
- manuali
- report
- file README
- pagine di supporto
- post del blog
I documenti sono facili da scrivere per gli umani, ma spesso sono difficili da usare per le macchine perché mescolano fatti, narrazione, contesto, esempi, opinioni, sezioni superate e spiegazioni ripetute nello stesso contenitore. I documenti sono buoni contenitori, ma non sono sempre buone strutture di conoscenza.
Note
Le note sono più flessibili dei documenti. Possono essere:
- atomiche
- collegate
- private
- incomplete
- focalizzate sui concetti
Un sistema di note, come un PKM o un second brain, può rappresentare la conoscenza in evoluzione meglio di un repository di documenti rifiniti. Le buone note catturano il pensiero in corso; le cattive note diventano un cassetto della spazzatura irricercabile.
Wiki
I Wiki rappresentano la conoscenza come pagine mantenute. Un buon wiki ha:
- pagine stabili
- argomenti chiari
- link interni
- proprietà (ownership)
- risposte canoniche
- modelli di aggiornamento
Un wiki è più forte di un dump di documenti sciolti perché dà alla conoscenza una casa. “Checklist di deployment” vive in un unico posto. “Risposta agli incidenti” vive in un unico posto. “Architettura RAG” vive in un unico posto. Questo è importante perché il recupero funziona meglio quando la conoscenza ha una struttura stabile.
Grafi di conoscenza
I grafi di conoscenza rappresentano la conoscenza come entità e relazioni. Invece di memorizzare solo testo, modellano cose come:
- Persona lavora su Progetto
- Modello supporta ContextLength
- Pagina dipende da Concetto
- Servizio si connette a Database
- Strumento implementa Protocollo
I grafi sono potenti perché le relazioni diventano esplicite, il che aiuta con la traversata, l’analisi delle dipendenze, la risoluzione delle entità, la discendenza (lineage), il ragionamento e le raccomandazioni. Ma i grafi sono costosi da mantenere e non sono magici — un cattivo grafo è solo confusione strutturata.
Schemi e ontologie
Gli schemi definiscono la struttura attesa; le ontologie vanno oltre e definiscono tipi, relazioni e vincoli. Rispondono a:
- Quali tipi di cose esistono?
- Quali proprietà hanno?
- Come possono relazionarsi?
- Quali regole si applicano?
Questo è utile quando la correttezza è fondamentale, come nella conoscenza medica, nella conoscenza legale, nei cataloghi di dati aziendali, nelle tassonomie dei prodotti e nei sistemi di conformità. Il compromesso è la rigidità: più formale è la rappresentazione, più costoso è evolverla.
Rappresentazioni generate da LLM
I sistemi moderni usano sempre più gli LLM per creare rappresentazioni. Gli esempi includono:
- sintesi
- entità estratte
- pagine tematiche
- mappe concettuali
- FAQ sintetiche
- outline dei documenti
- link incrociati
- voci del glossario
È qui che si collocano i sistemi in stile LLM Wiki. Usano il modello non solo per rispondere alle query, ma per pre-elaborare e strutturare la conoscenza prima che la query avvenga. Il RAG dice “recupera blocchi rilevanti al momento della query”; LLM Wiki dice “compila strutture di conoscenza utili al momento dell’ingestione”. Entrambi i modelli possono coesistere nella stessa architettura.
Cosa significa il recupero
Il recupero è il processo di ricerca di informazioni rilevanti. I metodi di recupero comuni includono:
- ricerca per parola chiave
- ricerca full-text
- ricerca vettoriale
- ricerca ibrida
- filtraggio per metadati
- traversata del grafo
- riordinamento (reranking)
- riscrittura della query
- ricerca agentic
Il recupero non è una sola cosa — è uno stack stratificato di metodi complementari.
Ricerca per parola chiave
La ricerca per parola chiave corrisponde ai termini ed è ancora utile perché è prevedibile, debuggabile, veloce e buona per termini esatti, ID, messaggi di errore, nomi e codice. La sua debolezza è la discrepanza semantica: se l’utente cerca “come fermare le risposte ripetute” ma il documento dice “presence penalty”, la ricerca per parola chiave potrebbe perdere il risultato migliore.
Ricerca vettoriale
La ricerca vettoriale recupera per similarità semantica. È utile quando:
- la formulazione differisce
- i concetti sono vaghi
- gli utenti pongono domande in linguaggio naturale
- i documenti usano una terminologia incoerente
La sua debolezza è la precisione — la ricerca vettoriale può recuperare cose che sembrano correlate ma non sono effettivamente corrette, il che è particolarmente rischioso nei sistemi tecnici.
Ricerca ibrida
La ricerca ibrida combina il recupero per parola chiave e vettoriale, che è spesso migliore di ciascuno da solo. La ricerca per parola chiave cattura le corrispondenze esatte; la ricerca vettoriale cattura le corrispondenze concettuali. Per le basi di conoscenza tecniche, il recupero ibrido è di solito un’ottima impostazione predefinita.
Riordinamento (Reranking)
Reranking prende un insieme iniziale di risultati recuperati e li riordina usando un modello più potente. Questo migliora la qualità perché il primo passo del recupero è spesso ampio. Un modello tipico recupera 50 blocchi, li riordina ai primi 5 o 10, poi passa solo il miglior contesto all’LLM. Il riordinamento è uno dei modi più pratici per migliorare la qualità del RAG.
Recupero Agentic
Il recupero Agentic trasforma la ricerca in un processo. Invece di una singola query, un agente può:
- Porre una domanda iniziale
- Cercare
- Ispezionare i risultati
- Reformulare la query
- Cercare di nuovo
- Confrontare le fonti
- Sintetizzare una risposta
Questo è più vicino alla ricerca che alla semplice ricerca. È utile per domande complesse, ma è più lento e più difficile da controllare.
Il recupero senza rappresentazione è fragile
Un sistema di recupero può recuperare solo ciò che esiste. Non può correggere in modo affidabile:
- concetti non chiari
- pagine duplicate
- terminologia incoerente
- documentazione superata
- mancanza di proprietà della fonte
- affermazioni contraddittorie
- linking interno debole
- confini dei documenti errati
Questo è l’errore più comune nei progetti RAG: i team costruiscono un database vettoriale e si aspettano che diventi un sistema di conoscenza. Un database vettoriale non è un’architettura di conoscenza — è un livello di accesso.
La rappresentazione senza recupero è isolata
Esiste anche il fallimento opposto. Puoi avere una base di conoscenza magnificamente strutturata che nessuno riesce a trovare. Questo accade con:
- wiki sovradimensionati
- alberi di cartelle profondi
- tassonomie rigide
- documentazione indicizzata male
- sistemi di note privati senza scoperta
- grafi senza interfacce utilizzabili
La rappresentazione dà struttura alla conoscenza; il recupero dà portata alla conoscenza. Hai bisogno di entrambi.
La mappa dei compromessi
Velocità vs coerenza
Il recupero è veloce da costruire e la rappresentazione richiede più tempo. Se hai bisogno di un prototipo, il recupero vince; se hai bisogno di fiducia a lungo termine, la rappresentazione è più importante.
| Priorità | Punto di partenza migliore |
|---|---|
| Q&A veloce su molti documenti | Recupero |
| Conoscenza tecnica stabile | Rappresentazione |
| Ricerca esplorativa | PKM più recupero |
| Assistente aziendale | Corpus strutturato più RAG |
| Memoria dell’agente | Rappresentazione più recupero selettivo |
Un prototipo RAG puro può essere costruito rapidamente, ma un sistema di conoscenza affidabile richiede curatela.
Flessibilità vs coerenza
I documenti sciolti sono flessibili; la conoscenza strutturata è coerente. La flessibilità aiuta quando:
- il dominio cambia rapidamente
- la conoscenza è incompleta
- gli utenti stanno esplorando
- il sistema è personale
La coerenza aiuta quando:
- più persone si affidano a essa
- le risposte devono essere affidabili
- i flussi di lavoro dipendono da essa
- i sistemi AI la consumano
Più persone o agenti dipendono dalla conoscenza, più la rappresentazione è importante.
Richiamo (Recall) vs precisione
I sistemi di recupero spesso ottimizzano prima il richiamo, il che significa trovare qualsiasi cosa che potrebbe essere rilevante. Ma le buone risposte hanno bisogno di precisione, il che significa trovare la migliore evidenza piuttosto che semplicemente evidenza correlata. La rappresentazione migliora la precisione rendendo i concetti e i confini più chiari — una pagina ben strutturata è più facile da recuperare accuratamente rispetto a un paragrafo casuale sepolto all’interno di un lungo documento.
Costo al momento dell’ingestione vs costo al momento della query
Il RAG di solito sposta il lavoro al momento della query. Al momento della query, il sistema:
- riscrive la query
- recupera i blocchi
- riordina i risultati
- assembla il contesto
- chiede al modello di ragionare sui frammenti
I sistemi in stile LLM Wiki spostano più lavoro al momento dell’ingestione. Al momento dell’ingestione, il sistema:
- legge le fonti
- estrae i concetti
- scrive sintesi
- crea pagine
- collega idee correlate
- mantiene la struttura
| Architettura | Passo costoso | Vantaggio |
|---|---|---|
| RAG | Momento della query | Recupero flessibile |
| LLM Wiki | Momento dell’ingestione | Struttura pre-compilata |
| Grafo di conoscenza | Tempo di modellazione | Relazioni esplicite |
| Wiki | Tempo di manutenzione | Conoscenza canonica |
Nessuno di questi è universalmente migliore — ottimizzano costi diversi.
Perché esiste LLM Wiki
LLM Wiki esiste perché il recupero da solo spesso ripete il lavoro. In un normale sistema RAG, ogni query può costringere il modello a interpretare di nuovo i frammenti grezzi:
- Recupera blocchi su un argomento
- Chiedi all’LLM di inferire il concetto
- Genera una risposta
- Dimentica la sintesi
- Ripeti la prossima volta
LLM Wiki dice:
Smetti di ri-derivare la stessa sintesi. Compila.
Invece di memorizzare solo documenti grezzi, crea pagine strutturate che riassumono e connettono la conoscenza, il che può migliorare coerenza, riuso, efficienza dei token, leggibilità umana e manutenzione a lungo termine. Ma ha un costo: il sistema deve mantenere il wiki, e se il wiki è sbagliato, superato o allucinato, la struttura diventa pericolosa.
Allucinazione RAG vs cattiva rappresentazione
Le persone spesso incolpano l’LLM quando un sistema RAG dà una risposta sbagliata, e a volte questo è corretto. Ma molti fallimenti sono in realtà fallimenti di recupero o rappresentazione.
Modalità di fallimento 1. Documento corretto, blocco sbagliato
La risposta esiste, ma il chunking la divide male. Il modello riceve:
- metà di un paragrafo
- contesto mancante
- una tabella senza spiegazione
- una definizione senza vincoli
L’LLM riempie quelle lacune, il che sembra un’allucinazione, ma il problema più profondo è una rappresentazione rotta.
Modalità di fallimento 2. Blocco correlato, risposta sbagliata
La ricerca vettoriale recupera qualcosa semanticamente simile ma operativamente sbagliato. La query chiede del deployment in produzione; il blocco recuperato discute lo sviluppo locale. I termini si sovrappongono ma il significato differisce, quindi il modello risponde con istruzioni di configurazione locale per un problema di produzione. Questa è imprecisione del recupero.
Modalità di fallimento 3. Fonti contraddittorie
Due documenti sono in disaccordo — uno vecchio, uno nuovo. Il sistema di recupero restituisce entrambi, e l’LLM li fonde in una risposta confidenziale ma invalida. Questo non è solo un problema di recupero ma un problema di rappresentazione, perché la base di conoscenza manca di uno stato canonico.
Modalità di fallimento 4. Nessun modello concettuale
Il sistema ha molti documenti ma nessun modello del dominio. Non sa che:
- “memoria dell’agente” differisce da “RAG”
- “wiki” differisce da “PKM”
- “ricerca per embedding” differisce da “ricerca full-text”
- “deployment” differisce da “hosting”
Senza rappresentazione concettuale, il recupero diventa una corrispondenza approssimativa.
Modalità di fallimento 5. La struttura generata diventa falsa autorità
I sistemi LLM Wiki hanno la loro modalità di fallimento. Se un LLM genera una pagina pulita da fonti cattive, il risultato può sembrare più autorevole del materiale originale. Questo è pericoloso: un’allucinazione lucida è peggio di un documento sorgente disordinato. Qualsiasi rappresentazione generata ha bisogno di:
- link alle fonti
- revisione
- regole di aggiornamento
- marcatori di confidenza
- proprietà (ownership)
Implicazioni di design
Ottimizza il recupero quando il corpus è grande e dinamico
Il recupero dovrebbe essere la priorità quando:
- il corpus è enorme
- i documenti cambiano frequentemente
- gli utenti pongono molte domande imprevedibili
- hai bisogno di una copertura ampia
- una struttura perfetta è irrealistica
Esempi: basi di conoscenza di supporto, ricerca documenti aziendali, assistenti di ricerca, chat interna su molti file, discovery legale e bot di customer service. In questi casi, investi in un forte recupero:
- ricerca ibrida
- filtri per metadati
- riordinamento
- riscrittura della query
- citazione della fonte
- set di valutazione
Ottimizza la rappresentazione quando la coerenza è importante
La rappresentazione dovrebbe essere la priorità quando:
- la conoscenza deve essere affidabile
- le risposte devono essere coerenti
- i concetti sono riutilizzati spesso
- il dominio ha una struttura chiara
- più sistemi dipendono da essa
Esempi: conoscenza architetturale, documentazione del prodotto, regole di conformità, riferimenti API, runbook operativi, collezioni di ricerca curate e cluster di blog tecnici. In questi casi, investi in:
- pagine canoniche
- termini del glossario
- diagrammi
- link interni
- proprietà (ownership)
- versioning
- cadenza di revisione
Ottimizza entrambi quando i sistemi AI dipendono dalla conoscenza
Se un agente AI dipende dalla conoscenza, il recupero da solo di solito non è sufficiente. Gli agenti hanno bisogno di:
- contesto stabile
- regole di compito chiare
- memoria durevole
- riferimenti strutturati
- confini delle fonti
- comportamento di aggiornamento
Per i sistemi agentic, la rappresentazione diventa parte del design del sistema. Un agente di coding non ha bisogno solo di recuperare “alcuni documenti” — deve conoscere:
- convenzioni del progetto
- decisioni architetturali
- pattern dei comandi
- dipendenze vietate
- flusso di lavoro di testing
- regole di deployment
Parte di questo appartiene al RAG, parte alla memoria e parte alla documentazione strutturata del progetto.
Framework decisionale pratico
Se il problema è trovare informazioni
Ottimizza il recupero. Esempi:
- “Trova pagine rilevanti.”
- “Rispondi alle domande sui documenti.”
- “Cerca attraverso molti PDF.”
- “Localizza ticket di supporto simili.”
Usa:
- ricerca full-text
- ricerca vettoriale
- recupero ibrido
- riordinamento
- filtraggio per metadati
Se il problema è rendere la conoscenza coerente
Ottimizza la rappresentazione. Esempi:
- “Crea una spiegazione canonica.”
- “Risolvi le pagine duplicate.”
- “Definisci il modello di dominio.”
- “Costruisci una base di conoscenza stabile.”
Usa:
- pagine wiki
- mappe concettuali
- tassonomie
- grafi di conoscenza
- sintesi
- schemi
Se il problema è la sintesi ripetuta
Usa la rappresentazione compilata. Esempi:
- “Risponiamo alle stesse domande concettuali ripetutamente.”
- “Il sistema continua a riassumere le stesse fonti.”
- “Abbiamo bisogno di un livello di sintesi stabile.”
Usa:
- LLM Wiki
- sintesi curate
- pagine tematiche
- pagine generate revisionate dagli umani
Se il problema è la continuità adattiva
Usa la memoria. Esempi:
- “L’agente dovrebbe ricordare le preferenze dell’utente.”
- “L’agente di coding dovrebbe ricordare le convenzioni del progetto.”
- “L’assistente dovrebbe continuare il lavoro tra le sessioni.”
Usa:
- memoria dell’agente
- archivi delle preferenze
- memoria episodica
- memoria semantica
- memoria del progetto
Come questo si applica a un blog tecnico
Un blog tecnico può essere più di una sequenza di post — può diventare un sistema di conoscenza rappresentato. Gli articoli sono documenti, le categorie sono una tassonomia debole, i link interni sono spigoli del grafo, le pagine pilastro sono sintesi canoniche, le pagine delle serie sono percorsi curati e la ricerca è il recupero. Se pubblichi solo post isolati, il recupero deve lavorare più duramente. Se costruisci una forte rappresentazione, il recupero diventa più facile.
Questo significa:
- confini di cluster chiari
- slug stabili
- pagine canoniche
- pagine di confronto
- spiegatori in stile glossario
- link interni
- metadati strutturati
Questo è il motivo per cui l’architettura del sito è importante — non solo per il SEO, ma perché è rappresentazione della conoscenza. Il cluster Knowledge Management su questo sito è esso stesso un esempio di pubblicazione con priorità alla rappresentazione.
Come questo si applica al RAG
La qualità del RAG dipende fortemente dalla rappresentazione. Un corpus sorgente ben strutturato migliora:
- qualità dei blocchi
- accuratezza del recupero
- qualità delle citazioni
- coerenza delle risposte
- chiarezza della valutazione
Prima di costruire un pipeline RAG complesso, chiedi:
- I documenti sorgente sono attuali?
- I duplicati sono rimossi?
- I concetti importanti sono chiaramente denominati?
- Le pagine sono scodate correttamente?
- Le tabelle e i blocchi di codice sono recuperabili?
- Le risposte canoniche sono evidenti?
- I confini dei documenti hanno senso?
Se la risposta è no, embedding migliori aiuteranno solo fino a un certo punto.
Come questo si applica a LLM Wiki
LLM Wiki è un modello di priorità alla rappresentazione. È utile quando:
- il corpus è di piccole o medie dimensioni
- la conoscenza è abbastanza stabile da essere riassunta
- la sintesi ripetuta è costosa
- gli umani traggono beneficio da pagine leggibili
- vuoi struttura prima del recupero
È meno utile quando:
- il corpus è massiccio
- il contenuto cambia costantemente
- la freschezza è più importante della coerenza
- la governance è debole
- le sintesi generate non possono essere revisionate
LLM Wiki non è un sostituto per il RAG ma un livello diverso, e un sistema forte può usare entrambi:
- LLM Wiki crea sintesi strutturate.
- RAG recupera dalle fonti grezze e dalle pagine wiki.
- La revisione umana mantiene la rappresentazione affidabile.
Pattern architetturali suggeriti
Pattern 1. Prima il recupero
Usa quando la velocità è importante.
documenti
-> blocchi
-> embedding
-> recupero
-> risposta LLM
Buono per:
- prototipi
- ricerca ampia
- corpus di grandi dimensioni
- esperimenti iniziali
Debolezza: la coerenza dipende dalla qualità della fonte.
Pattern 2. Prima la rappresentazione
Usa quando la fiducia è importante.
fonti
-> pagine curate
-> link interni
-> base di conoscenza mantenuta
-> ricerca o RAG
Buono per:
- documentazione
- conoscenza tecnica
- contenuti a lungo termine
- conoscenza del team
Debolezza: richiede manutenzione.
Pattern 3. Conoscenza compilata
Usa quando la sintesi ripetuta è importante.
fonti grezze
-> estrazione LLM
-> sintesi generate
-> pagine tematiche
-> base di conoscenza revisionata
-> recupero
Buono per:
- sistemi LLM Wiki
- collezioni di ricerca
- basi di conoscenza personali
- domini stabili
Debolezza: la struttura generata deve essere auditata.
Pattern 4. Architettura di conoscenza ibrida
Usa quando si costruiscono sistemi seri.
documenti grezzi
-> livello di conoscenza strutturata
-> indice di ricerca
-> recupero e riordinamento
-> risposta AI
-> feedback e manutenzione
Buono per:
- RAG in produzione
- sistemi di conoscenza interni
- assistenti AI
- sistemi di pubblicazione tecnica
Debolezza: più componenti mobili.
Domande di valutazione
Per valutare il recupero, chiedi:
- Il sistema ha trovato la fonte giusta?
- Ha classificato la fonte giusta in alto?
- Ha recuperato abbastanza contesto?
- Ha evitato il contesto irrilevante?
- La risposta ha citato la fonte corretta?
Per valutare la rappresentazione, chiedi:
- La conoscenza è strutturata chiaramente?
- C’è una pagina canonica?
- I concetti sono denominati in modo coerente?
- Le relazioni sono esplicite?
- Il contenuto è mantenuto?
- Possono usarlo sia umani che macchine?
Non valutare un sistema di conoscenza solo per la qualità della risposta — una buona risposta può nascondere una cattiva struttura.
La regola opinionata
Se il tuo sistema fallisce occasionalmente, migliora il recupero. Se fallisce ripetutamente nella stessa area concettuale, migliora la rappresentazione.
Un cattivo recupero manca delle informazioni giuste. Una cattiva rappresentazione significa che le informazioni giuste non esistono realmente in una forma utilizzabile.
Conclusione
Il recupero e la rappresentazione risolvono problemi diversi: il recupero dà accesso, la rappresentazione dà struttura. Il RAG è potente perché rende la conoscenza esterna disponibile agli LLM al momento della query, ma il RAG non rende automaticamente la conoscenza coerente, canonica o mantenuta. Ecco perché i wiki, i sistemi PKM, i grafi di conoscenza e i sistemi in stile LLM Wiki sono ancora importanti.
Il futuro non è recupero vs rappresentazione ma sistemi di conoscenza stratificati:
- rappresentazione per la struttura
- recupero per l’accesso
- memoria per la continuità
- ragionamento per la sintesi
Se stai costruendo un sistema di conoscenza serio, non iniziare con il database vettoriale. Inizia con la forma della conoscenza, poi decidi come dovrebbe essere recuperata.
