La Maggior Parte delle Knowledge Base Aziendali Non Ha Bisogno di RAG

Gestiamo il wiki aziendale interno con cinque comandi shell e un file indice curato manualmente. Nessun embedding, nessun vector database, nessun job di re-indicizzazione. Per una knowledge base di circa 200 documenti, questa configurazione è più rapida da costruire, meno costosa da mantenere e più accurata di una tipica pipeline RAG. Il compromesso diventa conveniente solo oltre la soglia dei mille documenti, non prima.

Una Nota su Karpathy e Obsidian

Due elementi ci hanno reso questo approccio ovvio. Il primo è l'argomento costante di Andrej Karpathy: gli AI agent dovrebbero ricevere strumenti, non chunk recuperati. Il suo progetto AutoResearch, pubblicato a marzo 2026, lo dimostra concretamente: l'agent esegue codice invece di interrogare embeddings, e il progresso deriva dall'esecuzione. Abbiamo analizzato AutoResearch in dettaglio in un articolo precedente.

Il secondo elemento è Obsidian. Un vault Obsidian è semplicemente una cartella di file markdown normali. 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 "fornisci strumenti all'agent": bastano pochi comandi shell per ottenere un LLM capace di leggere, scrivere e cercare direttamente in una knowledge base strutturata.

Cosa Utilizziamo Concretamente

Il nostro 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 pagine tramite wikilinks di Obsidian, e un file `index.md` curato manualmente alla radice elenca tutto per categoria con descrizioni di una riga.

L'agent non cerca nel vault tramite embeddings. 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à).
• `wiki search <query>`. Usa la ricerca full-text integrata di Obsidian.
• `wiki list <dir>`. Elenca i file in una directory.

L'intera implementazione è circa 80 righe di bash e curl. Nessun vector database, nessun modello di embedding, nessuna strategia di chunking, nessun reranker, nessun job di indicizzazione notturna. Aggiungere una nuova nota significa scrivere il file. L'agent lo recepisce alla query successiva, senza alcun passaggio intermedio nella pipeline.

Il File Indice È il Sistema di Retrieval

Questa è la parte che abbiamo impiegato un po' ad ammettere. Quando l'agent riceve una domanda, non inizia recuperando nulla. Inizia leggendo `wiki/index.md`, che è un sommario curato scritto da un essere umano (o da un agent di manutenzione eseguito a intervalli regolari). L'indice elenca ogni pagina con una descrizione di una frase, raggruppata per categoria. Da quella singola lettura di circa 400 token, l'agent sa già quali una o due pagine sono rilevanti.

Il passo successivo sono una o due letture mirate per recuperare le pagine pertinenti per intero. Ogni pagina è 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 strappati dal loro contesto originario).

Un indice manutenuto svolge il lavoro che un vector database fa in una pipeline RAG: mappa una query ai documenti giusti. La differenza è che un essere umano ha curato la mappatura una volta sola, invece di un modello di embedding che la approssima a ogni query.

Il Confronto su Token e Costi

Per una piccola knowledge base aziendale di circa 200 documenti, ecco cosa costa una configurazione RAG predefinita rispetto al pattern basato su indice e accesso diretto ai file. I dati sui token si basano su quanto osserviamo nel nostro vault. I dati sull'infrastruttura provengono dai prezzi pubblici dei servizi gestiti più comuni.

Un risparmio per query di circa il 30-60% sui token è reale, ma non è il punto principale. Il punto principale è tutto ciò che scompare dalla seconda colonna. Nessuna voce vector database nella fattura mensile. Nessun modello di embedding da manutenere. Nessuna sessione di debug del tipo "abbiamo cambiato la strategia di chunking e le risposte sono cambiate". Per una knowledge base che entra comodamente nella testa di una persona, ognuno di questi componenti aggiuntivi è overhead senza un beneficio corrispondente.

Cosa Si Smette di Dover Gestire

Il modo più chiaro per argomentare a favore di questo pattern è elencare le decisioni che scompaiono:

• Strategia di chunking. Nessun dibattito su "dobbiamo dividere per paragrafo, per frase, per numero di token?". La pagina è l'unità.
• Selezione del modello di embedding. Nessun progetto di ricerca per confrontare text-embedding-3-small con alternative ottimizzate.
• Operazioni sul vector database. Nessun servizio gestito da monitorare, aggiornare o mettere a budget.
• Pipeline di re-indicizzazione. Nessun job batch notturno, nessun messaggio Slack del tipo "l'indice non è aggiornato".
• Harness di valutazione del retrieval. Nessuna suite di test su precision e recall che gira in parallelo alla knowledge base.
• Ottimizzazione della hybrid search. Nessuna pipeline BM25 più vector più rerank da tenere in equilibrio.

Questo è pressappoco l'intero playbook operativo di RAG, eliminato. Al suo posto: uno script shell e la disciplina di tenere aggiornato un file indice. La disciplina è reale, ma è la stessa disciplina che rende un wiki utile agli esseri umani in primo luogo.

Quando RAG Rimane la Scelta Giusta

Questo pattern ha limiti chiari. Un indice manutenuto comincia a cedere intorno ai mille documenti, quando un essere umano non riesce più a tenere la struttura in testa e il file indice diventa troppo lungo perché l'agent lo scansioni in modo efficiente a ogni query. Oltre quella scala, embedding e un layer di retrieval reale guadagnano la loro ragion d'essere.

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 scala. Se si indicizzano migliaia di documenti pubblici che cambiano ogni minuto e devono essere interrogabili immediatamente.
• Filtraggio per metadati al momento del retrieval. Quando le query richiedono filtri strutturati (intervalli di date, autore, tipo di documento) integrati nel passo di retrieval, un vector database con metadati è la soluzione più pulita.
• Contenuto non affidabile o avversariale. Quando il corpus proviene da molti autori con agende contrastanti e nessun essere umano può essere responsabile di mantenere un indice curato.

Per la maggior parte delle knowledge base aziendali interne (wiki aziendali, documentazione di prodotto, playbook commerciali, guide di onboarding, SOPs interni) nessuna di queste condizioni si verifica. Il corpus è piccolo, gli autori sono pochi, la struttura è stabile, e le persone che curano la documentazione sono quelle più interessate alla sua correttezza. RAG è la scelta predefinita sbagliata.

Cosa Significa per la Maggior Parte delle Aziende

Se la Sua azienda è di piccole o medie dimensioni e sta guardando la documentazione esistente chiedendosi come renderla interrogabile dall'AI, la risposta onesta è quasi sempre che non ha bisogno di un vector database. Ha bisogno di un file indice, di un breve script che legge e scrive i documenti, e di un LLM con accesso agli strumenti. I componenti sono tutti standard. Il lavoro sta nel tenere l'indice accurato.

Le aziende che vendono RAG-as-a-service non hanno torto sulla tecnologia. Hanno torto sulla scelta predefinita. RAG è lo strumento giusto per problemi a una scala che la maggior parte delle aziende non ha, su tipi di contenuto che la maggior parte delle aziende non gestisce. Sceglierlo per primo è il modo in cui i progetti AI interni finiscono con una roadmap di sei mesi e una fattura infrastrutturale ricorrente prima ancora di rispondere alla prima domanda reale.

In webvise, costruiamo strumenti AI interni su questa base pragmatica: conoscenza strutturata, strumenti semplici, agent che leggono e scrivono direttamente. Se sta valutando un progetto RAG per la documentazione del suo team e vuole un secondo parere sulla giustificazione della complessità, ci contatti e possiamo analizzare insieme il corpus reale prima di impegnarsi nell'infrastruttura.