Haystack o LlamaIndex: 113 MB separano due modi di costruire il RAG

Haystack e LlamaIndex, nel test di installazione di Markaicode su ambienti Python 3.12 separati in Ubuntu, occupavano rispettivamente 163 MB con 40 pacchetti e 276 MB con 69 pacchetti: i 113 MB di differenza misurano le dipendenze installate, senza stabilire la latenza delle query, la memoria usata dal servizio in esecuzione o la pertinenza dei documenti recuperati.

Per un RAG documentale, LlamaIndex è una scelta sensata quando il lavoro più impegnativo consiste nell’acquisire e preparare fonti diverse. Haystack è più adatto quando il team vuole definire e seguire esplicitamente i passaggi tra ricerca, ordinamento dei risultati, generazione e agente. Il criterio decisivo è quale parte del sistema cambierà più spesso e chi dovrà mantenerla.

Che cosa costa davvero l’installazione

La dimensione iniziale è utile per capire quante dipendenze entrano nel progetto. Più pacchetti significano più componenti da registrare, aggiornare e sottoporre a controlli di compatibilità, ma lo spazio su disco da solo non quantifica il lavoro necessario per mantenerli. La misura riguarda inoltre le installazioni confrontate: un servizio completo può richiedere in seguito lettori, modelli di embedding, convertitori e integrazioni con il proprio archivio.

LlamaIndex distribuisce un pacchetto iniziale insieme a integrazioni installabili separatamente; Haystack parte da un nucleo al quale si aggiungono i componenti richiesti dal progetto. Perciò il confronto cambia se si confrontano configurazioni applicative diverse. Il dato resta un buon ingresso nella decisione quando conta contenere la superficie delle dipendenze, purché la scelta del framework tenga conto anche dei connettori e dei passaggi che il servizio dovrà eseguire.

Fonti documentali: il connettore è solo l’inizio

Con LlamaIndex il percorso dai dati alla ricerca ruota attorno a documenti, nodi, indici e query engine. Un documento può provenire, per esempio, da un file, da un’API o da un database; la sua suddivisione produce nodi che conservano contenuto e metadati utili alla ricerca. Questa struttura offre un modello comune quando il corpus comprende formati diversi e richiede trasformazioni prima dell’indicizzazione.

L’ampiezza dei connettori è preziosa se evita codice specifico per ogni sorgente, ma la loro presenza non risolve automaticamente l’ingestione. Occorre sapere se il lettore conserva identificatori, date, permessi e altri metadati necessari al servizio, e come tratta aggiornamenti e documenti duplicati. Una fonte acquisita facilmente può diventare costosa da mantenere se perde le informazioni con cui si dovranno filtrare o sostituire i contenuti.

Anche Haystack gestisce l’indicizzazione: convertitori, pulizia, suddivisione e scrittura nel document store possono formare una pipeline dedicata. Il team rende esplicito come ogni documento attraversa questi passaggi, con più lavoro di composizione quando aumentano i formati. Se le sorgenti sono poche e stabili, tale percorso può essere semplice da governare; se cambiano spesso, il tempo speso su lettori e conversioni pesa di più nella scelta.

Quando serve vedere ogni passaggio della query

La documentazione delle pipeline Haystack descrive componenti aggiunti con add_component e collegati con connect, che controlla la compatibilità di ingressi e uscite; lo stesso grafo può includere rami e cicli. Questo rende individuabile il punto in cui una query viene trasformata, inviata a un retriever o passata a un generatore. Quando cambia una fase, il collegamento da modificare è visibile nella pipeline.

Il costo di questa chiarezza è mantenere componenti e connessioni man mano che il flusso cresce. Per un percorso breve, la composizione esplicita può richiedere più codice di un query engine costruito su un indice LlamaIndex. Quest’ultimo accelera il passaggio dal corpus alle risposte, ma il comportamento può dipendere da scelte fatte nell’ingestione, nell’indice, nel retriever e nel backend. Se persone diverse intervengono su queste fasi, è utile valutare quanto sia facile ricostruire il percorso di una singola query.

Retrieval ibrido: chi controlla la fusione

La ricerca ibrida combina risultati lessicali e semantici, ma i due framework espongono il controllo in punti diversi. Per LlamaIndex, la tabella dei vector store distingue il supporto alla ricerca ibrida e ai filtri sui metadati per ciascun backend: queste capacità non sono uniformi tra le integrazioni. La scelta dell’archivio entra quindi nella scelta dell’architettura, soprattutto se le query devono rispettare filtri o combinare modalità di ricerca.

In Haystack, l’esempio di DocumentJoiner collega un retriever BM25 e uno basato su embedding a un componente che riunisce i documenti; tra le modalità disponibili figurano la fusione dei punteggi e quella basata sui ranghi. Il team può così individuare il punto in cui i risultati confluiscono e scegliere come trattare documenti presenti in entrambi gli elenchi. L’indicizzazione deve comunque alimentare entrambe le ricerche: nel caso dell’esempio, il retriever semantico richiede documenti con embedding.

Per valutare la pertinenza contano le query e i documenti del servizio, oltre alla regola di fusione. Una configurazione può favorire i termini esatti, un’altra i passaggi semanticamente vicini; nessuna delle due proprietà discende dalla dimensione dell’installazione. Haystack rende esplicita la fusione nel grafo, mentre con LlamaIndex bisogna chiarire quali capacità offre il backend scelto e dove viene configurato il retriever.

Più tenant: configurazione e separazione dei dati

In un servizio per clienti diversi, modello e trasformazioni possono variare per richiesta. La guida a Settings di LlamaIndex definisce Settings come configurazione globale persistente nell’applicazione e mostra come passare configurazioni locali, tra cui modello di embedding e trasformazioni, alle interfacce che le usano. Quando un valore dipende dal tenant, passarlo esplicitamente evita che una modifica a un’impostazione condivisa influenzi richieste concorrenti.

Haystack rende espliciti i componenti della pipeline e gli input forniti all’esecuzione. Questo aiuta a vedere quale retriever riceve una richiesta, ma la configurazione del flusso non equivale all’isolamento dei documenti. In entrambi i casi occorre decidere se usare archivi separati o filtri coerenti con i permessi del backend. Se una ricerca ibrida ha più rami, il vincolo del tenant deve valere per ciascun ramo che recupera documenti, prima che i risultati vengano uniti.

Agenti e manutenzione del ciclo

Quando un agente può scegliere strumenti, ripetere un’operazione o passare il risultato a una verifica, Haystack permette di inserire parti del comportamento in rami e cicli della pipeline. LlamaIndex offre workflow per orchestrare passaggi e agenti attorno alle proprie astrazioni per i dati. La differenza pratica riguarda dove il team vuole fissare le regole: nei collegamenti fra componenti oppure nella logica del workflow e dell’agente.

Un ciclo esplicito facilita l’individuazione delle fasi da osservare e modificare, ma aggiunge collegamenti da mantenere. Un agente che lavora su documenti già acquisiti e indicizzati può invece trarre vantaggio dalla continuità delle astrazioni di LlamaIndex. In entrambi i casi il costo operativo comprende aggiornamenti delle integrazioni, comportamento dei retriever e controllo dei documenti passati alla risposta, oltre alle dipendenze installate.

Quale scegliere per il servizio RAG

Se cambiano spesso fonti e formati, LlamaIndex offre un percorso centrato sull’ingestione, a condizione che i connettori conservino i metadati richiesti. Se il lavoro si concentra su retrieval ibrido, instradamento e controllo dei passaggi dell’agente, Haystack offre una pipeline in cui tali decisioni restano esplicite. Per un servizio multi-tenant, la scelta va completata con configurazioni per richiesta e isolamento dei documenti: sono requisiti dell’applicazione, qualunque sia il framework adottato.

Leggi anche:

• LangChain o LlamaIndex: nei benchmark il framework non decide da solo
• RAG o fine-tuning: aggiornare i fatti non richiede sempre addestramento
• Un RAG sui documenti non basta: senza citazioni gli errori restano invisibili