La maggior parte delle knowledge base aziendali non ha bisogno di RAG

Il wiki interno dell'azienda gira su cinque comandi shell e un file indice gestito a mano. Nessun embedding, nessun database vettoriale, nessun processo di re-indicizzazione. Per una knowledge base di circa 200 documenti, questa soluzione è più rapida da costruire, meno costosa da gestire e più accurata di una tipica pipeline RAG. Il compromesso diventa conveniente solo oltre il migliaio di documenti, non prima.

Una nota su Karpathy e Obsidian

Due elementi hanno reso questo approccio evidente. Il primo è l'argomento che Andrej Karpathy sostiene con coerenza: gli agenti AI dovrebbero ricevere strumenti, non chunk recuperati. Il suo progetto AutoResearch, pubblicato a marzo 2026, lo dimostra concretamente: l'agente esegue codice invece di interrogare gli embedding e il progresso dipende dall'esecuzione. AutoResearch è trattato in dettaglio in un articolo precedente.

Il secondo elemento è Obsidian. Un vault di Obsidian è semplicemente una cartella di file markdown in chiaro. Nessun database proprietario, nessuno schema da migrare, nessun SDK da imparare. Combinato con il plugin REST API locale di Obsidian, l'intera knowledge base si trova dietro un normale endpoint HTTP che qualsiasi processo può leggere o scrivere. Questa combinazione rende banale il pattern "fornire strumenti all'agente": pochi comandi shell e si ottiene un LLM in grado di leggere, scrivere e cercare direttamente in una knowledge base strutturata.

Cosa gira in produzione

Il wiki interno conta oggi 22 pagine di conoscenza strutturata: entità (persone, aziende, progetti), concetti (framework e principi), fonti (note di ricerca grezze) e pagine di sintesi che le collegano. Ogni pagina rimanda ad altre tramite wikilink di Obsidian, e un file `index.md` alla radice, gestito a mano, elenca tutto per categoria con descrizioni di una riga.

L'agente non cerca nel vault tramite embedding. Esegue cinque comandi:

• `wiki read <path>`. Recupera una singola pagina markdown.
• `wiki write <path> -`. Crea o sovrascrive una pagina da stdin.
• `wiki append <path> <text>`. Aggiunge una riga a una pagina (usato per il log delle attività in corso).
• `wiki search <query>`. Interroga la ricerca full-text integrata di Obsidian.
• `wiki list <dir>`. Elenca i file in una directory.

L'intera implementazione è di circa 80 righe di bash e curl. Nessun database vettoriale, nessun modello di embedding, nessuna strategia di chunking, nessun reranker, nessun job di indicizzazione notturno. Aggiungere una nota significa scrivere il file: l'agente la raccoglie alla query successiva senza alcun passaggio intermedio nella pipeline.

Il file indice è il sistema di recupero

L'aspetto scomodo: l'agente parte da `wiki/index.md`. Quel sommario curato elenca ogni pagina con una descrizione di una frase, raggruppata per categoria. Da quella singola lettura di circa 400 token, l'agente sa già quali una o due pagine sono rilevanti.

Il passo successivo consiste in una o due letture mirate per recuperare integralmente le pagine pertinenti. Ogni pagina è compresa tra 200 e 800 token. La maggior parte delle query si conclude con due o tre letture e circa un migliaio di token di contenuto del vault nella finestra di contesto. È meno di quanto inietta una configurazione RAG predefinita, e il contenuto è coerente (pagine intere) anziché frammentato (chunk estratti dal contesto circostante).

Un indice ben mantenuto svolge il lavoro che un database vettoriale compie in una pipeline RAG: associa una query ai documenti giusti. La differenza è che un essere umano ha curato quella mappatura una volta sola, invece di un modello di embedding che la approssima a ogni query.

Confronto tra token e costi

Per una piccola knowledge base aziendale di circa 200 documenti, ecco i costi di una configurazione RAG predefinita rispetto al pattern basato su indice e accesso diretto ai file. I valori in token sono stime orientative basate su pattern di recupero tipici. I dati sull'infrastruttura provengono dai prezzi pubblici dei servizi gestiti più diffusi.

Il risparmio in token dipende dalla struttura del corpus e dai pattern di query. Il punto centrale è tutto ciò che scompare nella seconda colonna: nessuna voce per il database vettoriale nella fattura mensile, nessun modello di embedding da mantenere, nessuna sessione di debug sulla strategia di chunking quando le risposte cambiano. Per una knowledge base che sta comodamente nella testa di una sola persona, ognuna di quelle parti mobili è overhead privo di un beneficio corrispondente.

Cosa si smette di dover gestire

Il modo più efficace per sostenere questo pattern è elencare le decisioni che scompaiono:

• Strategia di chunking. Nessun dibattito su "dividiamo per paragrafo, per frase, per conteggio di token?". La pagina è l'unità.
• Selezione del modello di embedding. Nessun progetto di ricerca a confronto tra text-embedding-3-small e alternative fine-tuned.
• Operazioni sul database vettoriale. Nessun servizio gestito da monitorare, aggiornare o includere nel budget.
• Pipeline di re-indicizzazione. Nessun job batch notturno, nessun messaggio Slack con "l'indice è obsoleto".
• Harness di valutazione del recupero. Nessuna suite di test precision-and-recall da far girare accanto alla knowledge base.
• Ottimizzazione della ricerca ibrida. Nessuna pipeline BM25 più vettore più rerank da tenere in equilibrio.

Si tratta, in sostanza, dell'intero playbook operativo RAG, eliminato. Al suo posto: uno script shell e la disciplina di mantenere accurato un file indice. La disciplina è reale, ma è la stessa disciplina che rende un wiki utile agli esseri umani.

Quando RAG è ancora la scelta giusta

Questo pattern ha limiti precisi. Un indice mantenuto a mano comincia a cedere intorno ai 1.000 documenti, quando nessun essere umano riesce più a tenere la struttura in testa e il file indice diventa troppo lungo perché l'agente lo scansioni efficientemente a ogni query. Oltre quella soglia, gli embedding e un livello di recupero vero guadagnano la loro utilità.

Altri casi in cui RAG rimane lo strumento giusto:

• Corpus multimodali. PDF con tabelle, documenti scansionati, trascrizioni audio, report ricchi di immagini. Un vault markdown presuppone che tutto si riduca a testo.
• Aggiornamenti ad alta frequenza su larga scala. Se si indicizzano migliaia di documenti pubblici che cambiano ogni minuto e devono essere interrogabili immediatamente.
• Filtri strutturati al momento del recupero. Quando le query richiedono filtri strutturati (intervalli di date, autore, tipo di documento) integrati nel passaggio di recupero, un database vettoriale con metadati è la soluzione più pulita.
• Contenuto non affidabile o avversariale. Quando il corpus proviene da molti autori con interessi in conflitto e nessun singolo essere umano può essere incaricato di mantenere un indice curato.

Per la maggior parte delle knowledge base aziendali interne (wiki aziendali, documentazione di prodotto, sales playbook, guide di onboarding, procedure operative standard interne) nessuna di quelle condizioni si applica. Il corpus è ridotto, i contributori sono pochi, la struttura è stabile e chi mantiene la documentazione è chi ha più interesse a tenerla corretta. RAG è spesso la scelta predefinita sbagliata per i casi d'uso che si incontrano nella pratica.

Adatto alla maggior parte delle aziende

Per una piccola o media impresa che guarda alla propria documentazione esistente e si chiede come renderla interrogabile dall'AI, la risposta onesta è quasi sempre che non serve un database vettoriale. Servono un file indice, un breve script che legge e scrive i documenti, e un LLM con accesso agli strumenti. I componenti sono tutti off-the-shelf. Il lavoro sta nel mantenere l'indice affidabile.

I vendor di RAG-as-a-service non hanno torto sulla tecnologia; il disaccordo riguarda quando debba essere l'architettura predefinita. RAG è lo strumento giusto per problemi a una scala che la maggior parte delle aziende non raggiunge, su tipologie di contenuto che la maggior parte delle aziende non gestisce. Scegliere RAG come prima opzione porta talvolta a roadmap lunghe e costi infrastrutturali ricorrenti prima di realizzare il caso d'uso originale.

webvise costruisce strumenti AI interni su questo tipo di fondamenta pragmatiche: conoscenza strutturata, strumenti semplici, agenti che leggono e scrivono direttamente. Per chi sta valutando un progetto RAG per la documentazione del proprio team e vuole un secondo parere sulla reale giustificazione della complessità, contattaci per analizzare insieme il corpus prima di impegnarsi nell'infrastruttura.