RAG aziendale su misura: come progettarlo con un partner

Un sistema di RAG aziendale su misura non nasce scegliendo un vector database. Nasce guardando i documenti che l’azienda ha davvero: preventivi in PDF scansionati male, procedure interne aggiornate tre anni fa, un wiki tecnico con quattro versioni contraddittorie della stessa policy. È qui che i sistemi generalisti si rompono, e non perché il modello linguistico sia scarso: perché il recupero delle informazioni è un problema di dominio, non di modello. Questo articolo entra nelle scelte architetturali che vanno personalizzate, chunking, embeddings, re-ranking, valutazione, e spiega perché servono in affiancamento, non in autonomia.

In questo articolo scoprirai:

• Perché un RAG generalista fallisce sui documenti aziendali
• L'audit dei dati: il punto di partenza di ogni RAG aziendale
• Chunking: la scelta che decide la qualità del retrieval
• Embeddings e re-ranking: dove si guadagna precisione
• Come si misura un RAG aziendale prima del go-live
• Cosa fa un partner che un prodotto inscatolato non fa
• Quando il self-service basta (e quando non basta)

Perché un RAG generalista fallisce sui documenti aziendali

Le basi del funzionamento sono già coperte nella nostra guida su cos’è il RAG e come funziona: qui diamo per acquisito il meccanismo e guardiamo dove si spacca in produzione. I failure mode documentati sui deployment enterprise sono ricorrenti e sorprendentemente banali. Il chunking a lunghezza fissa separa clausole correlate, tabelle e istruzioni operative in frammenti scollegati: un contratto tagliato al limite di token perde il legame tra condizione ed eccezione. Il parsing dei PDF introduce errori prima che l’embedding cominci: header mancanti, gerarchie rotte, paragrafi frammentati. E poi c’è la deriva degli embedding, per cui una query sulla policy di credito restituisce documenti di cybersecurity solo perché lessicalmente vicini.

Il quarto failure mode è il più controintuitivo: la finestra di contesto ampia non aiuta, peggiora. Riempire il prompt di quaranta chunk “per sicurezza” produce il classico effetto lost-in-the-middle, in cui il modello ignora il fatto rilevante sepolto a metà. Il problema non è quanto contesto passi, è quanto contesto inutile passi.

Un prodotto generalista fa scelte ragionevoli in media su tutti i domini. Ma “in media” è esattamente ciò che non serve a un’azienda con un vocabolario proprio, una struttura documentale propria e utenti che fanno sempre le stesse trenta domande. È la stessa logica che spinge a valutare agenti AI custom contro soluzioni off-the-shelf: la differenza non è nelle feature, è in quanto la configurazione aderisce al caso reale.

L’audit dei dati: il punto di partenza di ogni RAG aziendale

Il primo lavoro di un progetto RAG non è tecnico. È inventariale. Bisogna sapere quanti documenti esistono, in quale formato, chi li aggiorna, quali sono autorevoli e quali sono zombie che nessuno ha mai archiviato. Un corpus con tre versioni della stessa procedura produrrà risposte contraddittorie qualunque sia l’architettura di retrieval, perché il sistema non ha modo di sapere quale versione conti, a meno che qualcuno non gliel’abbia detto tramite metadati.

L’audit produce quattro output concreti. Primo: una mappa delle fonti con un giudizio di autorevolezza, che diventerà un peso nel re-ranking. Secondo: l’elenco dei formati problematici, scansioni, tabelle complesse, allegati Excel, che richiedono un pipeline di parsing dedicato. Terzo: il modello di permessi, perché in azienda non tutti possono leggere tutto e il controllo accessi va applicato durante il recupero, non filtrando la risposta a valle. Quarto: un set di domande reali raccolte da chi risponde oggi a mano, che diventerà il dataset di valutazione.

Questa fase è anche quella che dice se il progetto è pronto a partire, o se prima serve mettere ordine: il tema che affrontiamo nell’articolo su come capire se la tua azienda è pronta per un agente AI. Salta l’audit e ogni scelta successiva diventa una scommessa. E se i documenti vivono dentro un ERP o un CRM, il problema si allarga all’integrazione con i sistemi legacy, dove la difficoltà è spesso l’estrazione, non l’AI.

Chunking: la scelta che decide la qualità del retrieval

Il chunking è la decisione più sottovalutata e quella con il ritorno più alto. La tensione di fondo è nota: chunk piccoli (128-256 token) alzano la precisione ma perdono il contesto attorno, chunk grandi (512-1024) conservano il contesto ma diluiscono la precisione. Non esiste un valore giusto in assoluto, esiste un valore giusto per quel tipo di documento.

Chunking semantico e strutturale: quando conviene

Il chunking semantico calcola gli embedding frase per frase e apre un nuovo chunk dove la similarità cosinusoidale tra gruppi adiacenti scende sotto una soglia: taglia dove il significato cambia, non dove finiscono i token. Il costo è reale: indicizzare così è 3-10 volte più lento del taglio a lunghezza fissa. In molti casi conviene invece lo split strutturale, che segue la forma del documento: sugli heading per la documentazione, per funzione o classe nel codice, per clausola nei testi legali. Il default prudente per la prosa resta 512-1024 token con confini consapevoli della struttura e un 10-15% di sovrapposizione tra chunk adiacenti.

Contextual retrieval: il chunk che sa da dove viene

Un chunk letto in isolamento perde ciò che lo rendeva comprensibile. “Il fatturato è cresciuto del 3% sul trimestre precedente” non dice di quale azienda né di quale anno. Il contextual retrieval risolve anteponendo a ogni chunk 50-100 token di contesto generati leggendo il documento intero, prima di indicizzarlo. I numeri pubblicati da Anthropic sono tra i più solidi disponibili: gli embedding contestuali da soli riducono il tasso di fallimento del recupero del 35% (dal 5,7% al 3,7%), combinati con BM25 contestuale del 49%, e aggiungendo il re-ranking del 67% (all’1,9%). Aggiungere metadati va nella stessa direzione: Atlan riporta 82,5% di precisione contro 73,3% del recupero sul solo contenuto.

Embeddings e re-ranking: dove si guadagna precisione

Il disallineamento tra modello di embedding usato in indicizzazione e in query è un errore silenzioso: il sistema risponde, sembra funzionare, e recupera sistematicamente il documento sbagliato. Vale la regola banale e spesso violata: lo stesso modello, la stessa versione, e una re-indicizzazione completa quando cambia. Su domini con lessico specialistico, farmaceutico, assicurativo, meccanico, gli embedding generalisti confondono termini che per l’azienda sono opposti, e qui il valore di un partner è saper scegliere tra modello generalista, modello di dominio e ricerca ibrida.

Il re-ranking è il secondo stadio: un cross-encoder rilegge le coppie query-passaggio e le riordina. Modelli open source come bge-reranker-v2-m3 (Apache 2.0, multilingue, 0,6B parametri) coprono bene i casi on-premise; sul fronte commerciale Cohere Rerank, arrivato alla versione 4 a dicembre 2025, copre oltre cento lingue e viene proposto come filtro di precisione che riduce i token passati al modello. La documentazione tecnica di Cohere lo descrive esattamente così: un secondo stadio che riordina i risultati di una prima ricerca, non un sostituto di quella ricerca.

La regola pratica consolidata nel 2026 è recuperare ~20 candidati, re-rankarli a 5 e passarne 3-5 al modello: re-rankare 100+ candidati raramente ripaga, perché il segnale sta nella testa della distribuzione. E vale la pena ricordare l’ordine delle cause: il re-ranking non ripara un recupero cieco. Se i 20 candidati non contengono la risposta, riordinarli non la fa comparire. Prima si sistema il chunking, poi si aggiunge il re-ranker.

Come si misura un RAG aziendale prima del go-live

Senza misurazione, “funziona” è un’opinione. La pratica minima è costruire un golden dataset di 50-100 domande reali con i documenti sorgente corretti e le risposte ideali, output diretto dell’audit, e misurare separatamente le due fasi.

Metriche di retrieval e di generazione

Sul recupero si guardano precision@k, recall@k e F1@k (se recuperi 10 chunk e 7 sono pertinenti, precision@10 = 0,7), insieme a MRR e NDCG. Redis indica come riferimento un MRR sopra 0,8, che significa risposta pertinente nelle prime una-due posizioni. Sulla generazione, la faithfulness, la quota di affermazioni effettivamente sostenute dal contesto, è la metrica cardine: sopra 0,9 per applicazioni medicali, legali o finanziarie, sopra 0,8 come minimo di produzione. L’answer relevancy va tenuta sopra 0,7-0,8, e una context recall sotto 0,8 è un allarme: significa che il modello non ha l’informazione necessaria e sta per inventarla.

Framework e benchmark: cosa usare davvero

Ragas è lo standard di fatto per faithfulness, response relevancy, context precision e recall; ARES di Stanford genera dati sintetici quando il ground truth è scarso; LangSmith gestisce gli LLM-as-a-Judge e il tracking degli esperimenti. I benchmark pubblici, RAGBench, CRAG, LegalBench-RAG, WixQA, T²-RAGBench, servono a confrontare architetture, ma su un corpus aziendale specifico danno poco segnale: è per questo che nel 2026 la prassi è il giudice LLM tarato sul dominio, con controlli umani a campione. La misurazione va poi in CI/CD, con soglie che bloccano il deploy quando la qualità peggiora: è l’unico modo per accorgersi di una regressione prima che se ne accorga un cliente. Lo stesso principio di misurabilità che rende sensato parlare di ROI dell’AI generativa invece di aspettarselo.

Onboarding assistito: cosa fa un partner che un prodotto inscatolato non fa

Messe in fila, queste decisioni spiegano perché l’onboarding di un RAG serio è un progetto e non un’attivazione. Nessuna delle scelte viste sopra ha una risposta universale: dipendono dai documenti, dal lessico, dalle domande, dai permessi. Un prodotto self-service deve necessariamente fissare quei parametri a valori medi, perché non conosce il tuo corpus. È il motivo per cui, su questo tipo di sistemi, il servizio conta più del modello.

È l’approccio con cui è costruito Mimír AI Agent: la configurazione parte dall’audit dei dati del cliente e le scelte di chunking, embedding e re-ranking vengono tarate in affiancamento, con un set di valutazione costruito sulle domande che quell’azienda riceve davvero. Non è un SaaS che si attiva con una carta di credito, ed è una scelta deliberata: la parte difficile è l’aderenza al dominio, e quella richiede qualcuno che guardi i documenti. Su cosa aspettarsi concretamente da questo tipo di percorso abbiamo scritto la guida alla consulenza su agenti AI per PMI, e sui numeri di tempo e budget l’articolo su costi e onboarding di un chatbot aziendale personalizzato.

Quando il self-service basta (e quando non basta)

Sarebbe disonesto sostenere che serva sempre un partner. Se il corpus è piccolo e pulito, un centinaio di pagine di documentazione in Markdown, aggiornate da un solo team, senza vincoli di riservatezza, un prodotto self-service funziona bene e costa una frazione. Lo stesso vale per i proof of concept: partire da uno strumento pronto per capire se il caso d’uso regge è spesso la scelta più razionale.

Il discorso cambia quando si sommano tre o più di queste condizioni: documenti eterogenei e mal formattati, lessico di dominio, permessi differenziati per ruolo, requisiti di citazione della fonte per compliance, integrazione con sistemi gestionali, volumi che rendono costoso ogni chunk inutile passato al modello. In quello scenario il self-service non fallisce per un limite di funzionalità, fallisce perché nessuno ha guardato i dati. La scelta tra i due modelli la sciogliamo in agente AI chiavi in mano o self-service, e su come si costruisce concretamente un sistema tarato sul cliente in agenti AI su misura.

La domanda utile, allora, non è “RAG su misura o prodotto pronto”, ma: quanto della qualità del mio sistema dipende da scelte che solo chi conosce i miei documenti può fare? Se la risposta è “molto”, il tempo speso in audit è il miglior investimento del progetto.

Fonti:

• Appinventiv — perché i sistemi RAG falliscono nei deployment enterprise
• Atlan — strategie di chunking per il RAG
• RAG best practices 2026 — split strutturale e parametri di default
• Anthropic — Contextual Retrieval: dati sulla riduzione del failure rate
• BAAI bge-reranker-v2-m3 su Hugging Face
• Cohere Rerank — pagina di prodotto
• Cohere — documentazione tecnica di Rerank
• Redis — valutazione di un sistema RAG e soglie di riferimento
• Ragas — metriche disponibili
• Towards Data Science — precision@k, recall@k e F1@k nelle pipeline RAG
• Label Your Data — valutazione del RAG e benchmark pubblici
• Contextual AI — RAG e fine-tuning a confronto per l’AI enterprise