La strategia come documento — Il settimo capitolo

Capitolo 6 — La strategia come documento, non come codice

Arriviamo all'insight che più di tutti, nel racconto di chi ha costruito RAG dal 2023 in poi, ricorre come "la cosa che avrei voluto capire dal primo giorno".

I framework tradizionali trattano la strategia di ricerca come codice Python. Vuoi, per i cataloghi tecnici, cercare prima per codice prodotto, poi per parole chiave, poi per vettori semantici, e solo in ultima istanza generare la risposta? Scrivi una funzione. Vuoi, per gli album fotografici, saltare del tutto la ricerca semantica tradizionale e affidarti a un reranker specializzato per immagini? Scrivi un'altra funzione. Vuoi, per i video aziendali, dividere l'audio dalla traccia visuale, trascriverli separatamente, trattarli come fonti distinte e poi ricomporli nella risposta finale? Altra funzione ancora. Ogni tipo di contenuto, ogni dominio, ogni cliente finisce per generare un ramo di codice che diverge dagli altri, fino al punto in cui modificare una strategia richiede un rilascio software, una code review, un ciclo di test, un deploy. Il tempo tra "ho un'idea su come migliorare la ricerca sui manuali tecnici" e "l'idea è in produzione" si misura in settimane. Per ogni idea.

L'insight alternativo è banale a dirsi e profondo nelle conseguenze: la strategia di ricerca non è codice. È un documento. Un JSON — un formato di testo strutturato che qualunque redattore, con mezz'ora di formazione, può leggere — che dice: "prima prova questo, poi quello, se il primo fallisce passa al terzo, rerankera così, rispondi con questo modello." Questo documento vive in un database, non in un repository. Si modifica da un'interfaccia, non da una pull request. Si versiona, si copia, si specializza per dominio. Una strategia per i cataloghi tecnici, una per gli album fotografici, una per i manuali di installazione, una per i video, una per l'audio, una per i contratti legali, una per i bilanci. Tutte coesistenti nello stesso sistema. Tutte modificabili in tempo reale.

Chi ha lavorato con questo approccio — chiamiamolo, senza troppa fantasia, Meta-RAG — racconta un cambio di velocità che va al di là dell'ingegneria. Una richiesta del cliente tipo "aggiungi una ricerca specifica per i codici prodotto che contengono sigle tipo CMP40M o RH1M" non è più un ticket di sviluppo da due settimane. È un nuovo passo aggiunto a una procedura JSON, testato a caldo su un ambiente di staging, promosso in produzione in un pomeriggio. La domanda "cosa cambia se usiamo un reranker diverso per le foto, mantenendo quello attuale per il testo?" si risponde modificando una riga di configurazione. L'esperimento costa nulla, il rollback costa nulla (basta ripristinare la versione precedente del documento), e la conoscenza accumulata — cosa funziona bene per un certo tipo di contenuto — diventa un patrimonio versionato e trasferibile, non il sapere tacito di chi ha scritto quel particolare ramo di codice e oggi è in ferie.

C'è anche un effetto sociale interessante, che emerge nelle organizzazioni che adottano questo approccio. Con le strategie come documento, il confine tra "sviluppatore" e "utente esperto" si sposta. Un bibliotecario digitale, un archivista aziendale, un esperto di dominio — il capo dell'ufficio tecnico, la responsabile della documentazione, il product manager che conosce come nessun altro le vere domande dei clienti — può leggere una strategia, capire cosa fa, suggerire modifiche, a volte scriverle direttamente. Non deve passare attraverso il funnel del ticket di sviluppo, non deve spiegare a uno sviluppatore cose che lo sviluppatore non sa (perché non sono nel suo mestiere saperle). Il RAG smette di essere un prodotto che consumi e diventa uno strumento che modelli sul tuo sapere organizzativo. Questo, nell'esperienza di chi lo ha provato, cambia il morale del progetto prima ancora dei numeri delle metriche.

Non è magia, e ha i suoi costi. Serve un motore che esegua queste strategie-come-documento in modo efficiente e sicuro. Serve un linguaggio di descrizione abbastanza ricco da coprire i casi reali e abbastanza povero da non diventare un altro Turing-completo travestito. Servono strumenti di versioning, di test, di rollback. Ma tutto questo è problema di chi costruisce il motore — una volta sola, e per tutti gli utenti. Il singolo cliente finale vede solo una cosa: la possibilità di evolvere la propria strategia di ricerca alla velocità del pensiero, invece che alla velocità del ciclo di rilascio software. E questa, per chi ci è dentro, è una rivoluzione silenziosa che non ha ancora trovato il suo nome sulle riviste di settore.

Chiusura — Il settimo capitolo, tra qualche mese

All'inizio del 2026, sommando le lezioni dei capitoli precedenti — le tabelle che si perdevano, i reranker bugiardi, le allucinazioni ereditate, le bollette cloud che crescevano più in fretta del valore, i framework promettenti ma rigidi — qualcuno, in Italia, ha iniziato a costruire un server RAG diverso. Scritto in Python, pensato per girare su hardware accessibile, capace di parlare con modelli cloud quando conviene e con modelli locali quando la privacy lo impone o il costo non torna. Un server in cui le strategie di ricerca sono documenti modificabili, il reranker è un processo locale su GPU, le tabelle non si perdono perché vengono trattate come cittadini di prima classe, le foto non ereditano oggetti da archivi polverosi di altre epoche, e il costo per query — sia in denaro che in dati esfiltrati verso terze parti — è conoscibile e controllabile al centesimo.

Non faremo il nome del progetto. Non è questo il pezzo per farlo, e non vogliamo trasformare un'inchiesta in una pubblicità. Ma se i capitoli precedenti ti hanno fatto riconoscere una situazione che stai vivendo — un chatbot aziendale che risponde con sicurezza a domande sbagliate, un progetto RAG che non decolla da mesi, una bolletta cloud che cresce più in fretta dell'utilità che produce, un dubbio crescente sul fatto che i tuoi documenti riservati stiano viaggiando in posti che non conosci —, allora vale la pena sapere che esiste un'altra strada, che è stata percorsa da qualcuno in Italia, e che nel 2026 ha iniziato a dare le prime risposte che ci si aspettava nel 2023.

La buona notizia è che l'AI aziendale, finalmente, sta uscendo dalla fase demo. La meno buona è che ci sta uscendo portandosi dietro tutte le cicatrici del tragitto: framework gonfi, dipendenze da provider, architetture monolitiche, dati sporchi, bug silenziosi e una certa tendenza del settore a vendere soluzioni prima ancora di aver capito il problema. Le abbiamo raccontate in sei capitoli. Il settimo — la storia di cosa succede quando finalmente qualcuno fa le cose bene, con pazienza, in italiano e in open source — lo scriveremo presto, con meno cautela sui nomi e più numeri sul tavolo.

Intanto, se sei arrivato fin qui, hai già fatto più autopsia del 90% dei decisori che in questo momento stanno firmando un contratto per un chatbot aziendale senza chiedere nessuna delle domande che ti sei fatto leggendo questi capitoli. È un punto di partenza migliore di quello da cui sono partiti loro. E nei prossimi mesi, la differenza tra chi queste domande se le è poste e chi no, diventerà molto visibile sulle fatture — e sulle risposte che la vostra AI darà ai vostri clienti.

Questa inchiesta è stata redatta nell'aprile 2026, basandosi sull'esperienza di diciotto mesi di progettazione, costruzione e ottimizzazione di sistemi RAG aziendali tra la fine del 2024 e l'inizio del 2026.