Vai al contenuto principale
Torna al blog

Drupal

Architettura RAG per Drupal: cosa sviluppare e cosa affidare a un servizio gestito

Mappa Search API, chunking, embedding, database vettoriali, LLM, citazioni e controlli di accesso in Drupal, poi decidi cosa sviluppare o affidare a un servizio.

Founder, Achla AIMichael Shamanoff
Pubblicato
Aggiornato

11 min di lettura

Modello di ponte in carta diviso tra strati visibili gestiti dal proprietario e un supporto gestito racchiuso.
Una decisione sull’architettura RAG assegna estrazione, recupero, generazione, citazioni e operazioni a responsabili diversi.

Un’architettura RAG per Drupal è più di un chatbot. Una soluzione nativa richiede normalmente estrazione dei contenuti, suddivisione in chunk, embedding, recupero vettoriale, configurazione di Search API, un LLM, citazioni, controlli di accesso, attività di aggiornamento, un’interfaccia e gestione operativa. Un servizio gestito per un sito pubblico sposta diversi livelli fuori da Drupal; il confine corretto dipende dall’accesso ai dati e da chi si assume la responsabilità dei guasti.

Michael Shamanoff Founder, Achla AI Per chi: proprietari, architetti e implementatori Drupal che valutano la ricerca semantica o risposte corredate di fonti. Metodo: pagine ufficiali dei progetti Drupal e file di prodotto Achla correnti, verificati il 3 agosto 2026, insieme a una matrice originale delle responsabilità e a una scheda di valutazione del progetto pilota. La stesura è stata assistita dall’IA; le affermazioni fattuali rilevanti sono collegate alle fonti nel registro allegato. Perché: le guide di installazione nominano i componenti, ma chi decide deve sapere anche chi gestisce ogni livello, come può guastarsi e quali requisiti escludono un percorso gestito basato sulla scansione pubblica.

L’architettura RAG per Drupal, livello per livello

RAG comprende due flussi. L’indicizzazione trasforma i contenuti in record recuperabili. Il flusso della query trasforma una domanda in recupero, contesto, generazione e prove verificabili.

Flusso di indicizzazione: dal contenuto ai chunk recuperabili

  1. Seleziona entità, campi e modalità di visualizzazione Drupal che contengono materiale sorgente utile.
  2. Estrai il testo conservando identità, lingua, URL, metadati di accesso e segnali di aggiornamento o eliminazione.
  3. Dividi i contenuti lunghi in chunk che mantengano un contesto sufficiente per restare significativi.
  4. Genera gli embedding e salvali in un backend con supporto vettoriale.
  5. Aggiorna, sostituisci o elimina i record quando cambiano i contenuti Drupal.

Il progetto ufficiale AI Search integra gli embedding vettoriali con Search API e documenta un backend vettoriale, chunking, soglie di punteggio, controlli di accesso alle entità dopo la query, ricerca ibrida e integrazione RAG. Sono componenti di base, non un modello operativo completo.

Flusso della query: dalla domanda alla risposta con citazioni

  1. Converti o indirizza la domanda verso il metodo di recupero scelto.
  2. Recupera i chunk candidati e applica soglie, filtri o logica di ricerca ibrida.
  3. Assembla il contesto per l’LLM senza perdere l’identità delle fonti o i vincoli di accesso.
  4. Genera una risposta oppure un risultato vuoto e onesto.
  5. Mostra le citazioni e registra prove sufficienti per diagnosticare il recupero separatamente dalla generazione.

Mantieni fonti recuperate, testo generato e citazioni visibili al visitatore come prove distinte: fonti pertinenti possono essere riassunte male, mentre una formulazione scorrevole può basarsi sulla fonte sbagliata.

Cosa fa Search API — e cosa non fa da solo

Search API è il framework di ricerca estensibile di Drupal. Definisce gli indici e lavora con backend, campi, processori, Views, filtri e facet. Da solo non sceglie un modello di embedding, non gestisce ogni backend, non assembla il prompt di un LLM, non genera una risposta, non progetta un’interfaccia chat e non valuta l’aderenza alle fonti.

La pagina ufficiale indica anche un importante limite di sicurezza: Search API non può fornire restrizioni di accesso generiche per ogni caso d’uso. I proprietari del sito restano responsabili di garantire che vengano indicizzati o mostrati solo gli elementi accessibili, anche se parti dell’ecosistema offrono modifiche node-access e controlli aggiuntivi.

Una pagina di risultati semantici non deve necessariamente diventare una chat. Decidi se i visitatori hanno bisogno di risultati semantici ordinati, di una risposta con citazioni, di una conversazione o di più interfacce.

Lo stato attuale dei progetti Drupal deve guidare la decisione sui rischi

Le etichette delle versioni e la copertura di sicurezza cambiano. Aggiorna questa tabella regolarmente e di nuovo prima di qualsiasi decisione di implementazione. I dati seguenti sono stati osservati sulle pagine ufficiali Drupal.org il 3 agosto 2026.

ProgettoStato della versione osservatoStato degli avvisi di sicurezza
Search API8.x-1.41, versione stabile per Drupal 10.3/11La versione stabile è coperta dalla policy degli avvisi di sicurezza di Drupal.
AI Search2.0.0-alpha2 e 1.3.0-alpha4; la pagina dichiara che non esiste una versione stabile supportataLe versioni stabili sono coperte, ma non ne era disponibile una; le versioni elencate sono alpha.
RAG Search1.0.5, senza suffisso alpha/betaIl progetto dichiara esplicitamente di non essere coperto dalla policy.
Drupal as RAG1.0.0-alpha5Il progetto dichiara esplicitamente di non essere coperto dalla policy.
AI RAG Search Chat1.0.7, senza suffisso alpha/betaIl progetto dichiara esplicitamente di non essere coperto dalla policy.

Un numero 1.0.x non sostituisce la copertura di sicurezza. Valuta separatamente maturità, manutenzione, versioni Drupal, dipendenze dai provider e stato della policy di sicurezza.

Percorso fai da te: i componenti che il tuo team deve gestire

Una soluzione nativa per Drupal mantiene un maggiore controllo vicino a Drupal, ma crea più responsabilità operative. Il progetto RAG Search mostra un indice vettoriale Search API che alimenta l’assemblaggio del prompt e un LLM, con cache esatta e semantica facoltative, limitazione della frequenza e nuovi controlli di accesso prima di fornire chunk memorizzati. L’esclusione dalla policy di sicurezza resta un avvertimento sostanziale.

Drupal as RAG dimostra un altro percorso con Drupal 11, PostgreSQL con pgvector e Ollama su un host locale o di rete. La versione osservata era alpha e non coperta, quindi è un esempio di architettura, non una raccomandazione.

LivelloCompitoResponsabile fai da teResponsabile gestitoSegnale di erroreTest minimo di accettazioneRiserva su dati/accesso
EstrazioneSelezionare e visualizzare le fontiTeam Drupal/contenutiOperatore del crawlerPagine mancanti o non valideConfrontare le fonti indicizzate con un inventario approvatoI campi privati non devono finire in un indice pubblico.
Chunking ed embeddingCreare rappresentazioni recuperabiliIngegnere IA/ricercaOperatore del servizioBasso richiamo o perdita di contestoSet con termini esatti e parafrasiCambi di provider o modello possono alterare i risultati.
Recupero vettorialeRestituire chunk pertinentiResponsabile ricerca/backendOperatore del servizioCandidati irrilevanti o vuotiRegistrare fonti e punteggi prima della generazioneFiltri e metadati di accesso devono sopravvivere.
Prompt e LLMProdurre testo vincolatoResponsabile applicazione IAOperatore del servizioRisposta non supportata o troppo sicuraCasi noti, ambigui e senza rispostaIl contesto recuperato non garantisce una formulazione corretta.
UI e citazioniMostrare risposta e proveTeam Drupal/frontendOperatore widget/servizioLink rotti o inventatiAprire ogni citazione; testare tastiera/mobileLe citazioni devono identificare la fonte davvero recuperata.
Aggiornamento ed eliminazioneTenere allineato l’indiceResponsabile code/operazioniOperatore crawler/indicePersistenza di contenuti vecchi o rimossiModificare/eliminare una pagina di prova e osservare l’indiceInvalidazione cache ed eliminazione richiedono un responsabile esplicito.

Il compromesso più ampio è trattato in ricerca IA aziendale rispetto al fai da te.

Percorso gestito: quali livelli si spostano fuori da Drupal

Un percorso gestito per un sito pubblico affida scansione, indicizzazione, recupero, chiamate al modello, consegna della risposta e parte del monitoraggio all’operatore del servizio. Drupal fornisce pagine pubbliche e uno script o connettore. Lo stack interno si riduce, ma il servizio non possiede la conoscenza nativa di campi, revisioni, ruoli e decisioni di accesso, a meno che siano implementati e verificati esplicitamente.

I file di prodotto Achla esaminati descrivono un connettore Drupal 10/11 distribuito tramite Composer, una matrice di validazione PHP 8.3 e aggiornamenti automatici indicati come disponibili all’ultima revisione del 16 luglio 2026. Il servizio gestito esegue la scansione e l’indicizzazione del sito pubblico e mostra tramite un widget risposte collegate alle fonti. Il widget supporta le modalità di posizionamento bubble, inline e attach.

Achla non è un backend Search API. È un percorso distinto di scansione pubblica e widget gestiti. Non deve essere presentato come soluzione per contenuti Drupal privati o autenticati, recupero consapevole dei ruoli, permessi a livello di riga o azioni transazionali in Drupal. Consulta la configurazione gestita senza sviluppatore per questo confine operativo.

Sviluppare o affidarsi a un servizio? Parti dai requisiti

RequisitoPreferisci un prototipo nativo per Drupal quando…Considera un percorso gestito per sito pubblico quando…
Confine dei contenutiIl recupero deve riflettere campi, revisioni, ruoli o contenuti autenticati di Drupal.La fonte approvata è intenzionalmente pubblica e scansionabile.
Investimento esistenteEsistono già indici Search API, provider e un team operativo.Il team non vuole gestire embedding, storage vettoriale, chiamate LLM e interfaccia delle risposte.
ControlloScelta dei provider, logica dei prompt, posizione dello storage e regolazione del recupero devono restare interni.Sono accettabili un contratto limitato e il vincolo ai contenuti pubblici.
InterfacciaViews, moduli, permessi o processi Drupal personalizzati sono essenziali.È sufficiente un widget con risposte citate o una ricerca pubblica incorporata.
Responsabilità degli incidentiIl team può diagnosticare code, accesso, recupero, generazione, cache e UI.L’operatore gestisce questi livelli e fornisce prove e fallback adeguati.

Includi infrastruttura, aggiornamenti, revisione di sicurezza, chiavi dei provider, osservabilità, operazioni sui contenuti, risposta agli incidenti e prova del corretto funzionamento delle restrizioni di accesso, non soltanto il costo della licenza.

Proteggere accesso, citazioni e comportamento di aggiornamento

I contenuti privati rappresentano una biforcazione architetturale netta. Il framework generico Search API non risolve automaticamente tutte le restrizioni. AI Search documenta controlli di accesso alle entità dopo la query; RAG Search documenta chiavi di cache basate sui ruoli e nuovi controlli di accesso alle fonti. Questi meccanismi specifici dei moduli devono comunque essere testati con ruoli reali, contenuti non pubblicati, permessi modificati e risposte memorizzate.

Il progetto AI RAG Search Chat mostra perché la superficie di produzione è più ampia del recupero: aggiunge pagine di ricerca e chat, sessioni, permessi, limitazione della frequenza, provider e fonti collegate. La versione 1.0.7 osservata non era coperta dalla policy degli avvisi di sicurezza di Drupal.

In qualsiasi architettura, conserva URL e identificatori delle fonti durante il chunking, verifica che ogni citazione sostenga la risposta, definisci un esito negativo onesto e testa la propagazione di aggiornamenti ed eliminazioni. Una risposta collegata alle fonti è più facile da verificare, ma recupero e citazioni non eliminano l’errore del modello. Usa questa guida per valutare l’affidabilità della ricerca IA.

Usa una scheda di valutazione riproducibile per il progetto pilota

Crea il set di valutazione da attività reali. Da venti a trenta domande rappresentative sono un metodo di pianificazione, non un benchmark o una soglia promessa.

  1. Registra la domanda, la pagina sorgente prevista, la classe di contenuto/accesso e un esito «non trovato» accettabile.
  2. Includi termini esatti, parafrasi, pagine in conflitto, contenuti obsoleti o rimossi e una domanda priva di risposta.
  3. Per un test nativo su contenuti privati usa account con ruoli diversi e considera fallito ogni caso che esponga una fonte non accessibile.
  4. Registra le fonti recuperate separatamente dal testo generato e dalle citazioni visibili al visitatore.
  5. Verifica l’aggiornamento dell’indice dopo modifica ed eliminazione, poi ripeti quando potrebbero essere coinvolte le cache pertinenti.
  6. Aggiungi test per tastiera, mobile, interruzione, risultato vuoto e fallback dell’interfaccia scelta.
  7. Assegna ogni errore a ingestione, recupero, generazione, citazione/UI, accesso o operazioni e indica chi lo risolve in ogni architettura.

Il pilota fallisce in caso di esposizione di contenuti riservati, fonti inventate, link di citazione non funzionanti, mancato riconoscimento di una risposta assente o contenuti eliminati che restano oltre la finestra di aggiornamento documentata. Non inventare un punteggio universale. La scheda delle prove RAG permette di separare affermazione, fonte, comportamento previsto e risultato osservato.

Errori architetturali comuni

  • Trattare un LLM come sistema di recupero invece di misurare le prove recuperate.
  • Indicizzare campi o contenuti privati senza conservare e testare le regole di accesso.
  • Perdere URL, lingua, revisione o identità dell’entità durante il chunking.
  • Testare le aggiunte ma non modifiche, eliminazioni, invalidazione della cache ed esiti negativi onesti.
  • Definire una versione «sicura» perché non ha un suffisso alpha, ignorando la copertura degli avvisi.
  • Chiamare un crawler pubblico backend Search API o integrazione per contenuti privati.
  • Confrontare il prezzo della licenza omettendo infrastruttura e responsabilità degli incidenti.

Un passo successivo pratico per un sito Drupal pubblico

Prototipa internamente quando campi e permessi nativi Drupal, controllo del provider e un’operatività Search API esistente sono requisiti centrali. Valuta una ricerca gestita per siti pubblici quando la fonte è deliberatamente pubblica e il team vuole che un altro operatore gestisca i livelli del servizio RAG.

Se servono risposte con citazioni sulle pagine e sui documenti Drupal pubblici senza gestire lo stack RAG dentro Drupal, valuta la configurazione Drupal di Achla. Achla non è un backend Search API e non è il percorso per contenuti privati descritto sopra.

Domande poste dai team Drupal

Ho bisogno di Search API?

Per un percorso nativo costruito intorno ai moduli Search API, sì. Un servizio gestito separato che esegue la scansione pubblica può usare un proprio indice. Sono architetture diverse; un connettore o widget non trasforma l’indice gestito in un backend Search API.

Ho sempre bisogno di un database vettoriale?

Non per ogni esperienza di ricerca. Una ricerca per parole chiave o facet può usare altri backend. Il modulo ufficiale AI Search usa backend vettoriali per il recupero semantico, mentre un servizio gestito può nascondere la propria infrastruttura dietro il confine del servizio.

La ricerca semantica può funzionare senza chat?

Sì. Il recupero semantico può restituire risultati ordinati in un’interfaccia di ricerca. Aggiungi la generazione soltanto quando una risposta scritta serve il compito, puoi conservare le fonti, gestire onestamente gli esiti negativi e testare la formulazione separatamente dal recupero.

E i contenuti privati?

Inserisci i requisiti di controllo dell’accesso nella decisione fin dall’inizio. Un progetto nativo può preservare i permessi Drupal se viene testato l’intero percorso di indicizzazione, recupero, cache e visualizzazione. Il percorso Achla descritto qui è limitato ai contenuti pubblici scansionabili.

Come confronto i progetti pilota?

Usa lo stesso set di domande, le stesse aspettative sulle fonti, casi di accesso, prove di aggiornamento, verifiche delle citazioni, condizioni dell’interfaccia e categorie di errore. Confronta prove e responsabilità, non una demo scelta dal fornitore o un punteggio universale non supportato.

Illustrazione condivisa

Una decisione sull’architettura RAG assegna estrazione, recupero, generazione, citazioni e operazioni a responsabili diversi.

*Una decisione sull’architettura RAG assegna estrazione, recupero, generazione, citazioni e operazioni a responsabili diversi.*