I sistemi di Retrieval-Augmented Generation smettono di funzionare bene proprio quando la domanda si fa più articolata. Chiunque abbia provato a chiedere a un LLM "chi è il responsabile del team che ha sviluppato la feature X, e quali progetti correlati ha seguito l'anno scorso?" sa che i contesti piatti restituiti dai database vettoriali spesso producono risposte sconnesse. HG-RAG, un framework di nuova concezione, ribalta l'approccio: invece di pescare da un ammasso informe di documenti, percorre un grafo di conoscenza organizzato in modo gerarchico, recuperando il contesto dalle relazioni stesse tra i dati.

Il punto di partenza è un'entità nominata estratta dalla query, che funge da ancora. Da lì il sistema espande il contesto verso l'alto (nodi genitori), lateralmente (vicini relazionali) e, quando serve, verso il basso (nodi figli). Il risultato è un retrieval che rispetta la struttura semantica del dominio, anziché affidarsi alla sola similarità vettoriale. I test, condotti su tre scale di mondo (da 18 a 800 nodi) e quattro tipi di interrogazione — local fact, hierarchical, neighborhood e multi-hop — raccontano un vantaggio netto sulla baseline densa: meno fatti inventati, più coerenza locale, e una marcia in più su tutti i ragionamenti che richiedono più salti logici.

Per chi gestisce deployment on-premise, il segnale è forte. Tantissime organizzazioni hanno già messo ordine nei propri dati con grafi aziendali, tassonomie prodotto o ontologie regolatorie. HG-RAG permette di usare quegli stessi grafi senza spostare le informazioni su servizi esterni di vector embedding, mantenendo il controllo pieno su dove risiedono i dati. In uno scenario on-prem, l'infrastruttura deve però reggere due carichi: il motore di inference del modello e la navigazione del grafo, che può diventare onerosa quando i salti sono molti e la base di conoscenza è grande. La memoria diventa un fattore critico: mantenere il grafo in RAM (o in VRAM se usiamo un LLM locale) limita la scala, ma garantisce latenze prevedibili.

Dietro a tutto questo c'è una partita più ampia. Il mondo RAG si sta dividendo tra chi spinge su retrieval sempre più densi e chi cerca di iniettare struttura esplicita, con i grafi che tornano prepotentemente in scena. HG-RAG non è il primo tentativo, ma è il primo a mostrare con chiarezza che l'approccio gerarchico funziona su scala contenuta e con query complesse, senza dover cedere alle allucinazioni da contesto rumoroso. Per le realtà che stringono accordi di riservatezza ferrei o che operano in settori regolati, la differenza non è teorica: un grafo ben modellato e consultato localmente riduce il rischio di leak informativi e rende l'intero sistema revisionabile.

L'analisi dei trade-off resta comunque centrale. Un retrieval piatto è più semplice da scalare e da manutenere; un grafo, invece, paga un costo iniziale di modellazione e richiede competenze specifiche per restare aggiornato. HG-RAG non risolve questo dilemma, ma offre un percorso netto per chi ha già investito in conoscenza strutturata. Se il vostro stack self-hosted include già un graph database e un runtime per LLM, l'integrazione promette ritorni immediati in precisione, con un impatto contenuto sui costi operativi. Come sempre in questi casi, la scelta non è tra vettore e grafo, ma su quali query deve rispondere l'applicazione e con quale tipo di sovranità si vuole proteggere la conoscenza.