OpenSearchCon 2026: Perché gli agenti di IA hanno bisogno di più di un database vettoriale

Eva Wong

IceWhale author

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

OpenSearchCon 2026: Why AI Agents Need More Than a Vector Database - Zima Store Online

OpenSearchCon North America 2026 arriva mentre la “ricerca” diventa un problema molto più ampio del trovare documenti simili. Gli agenti IA devono recuperare prove, conservare il contesto utile, chiamare strumenti e spiegare che cosa è successo quando un'attività va storta.

Un database vettoriale risolve una parte del problema. Un agente serio ha bisogno anche di recupero preciso, metadati, aggiornamento, memoria, tracce di esecuzione e autorizzazioni. Il livello dati emergente per l'IA assomiglia meno a “embedding in un database” e più a ricerca + memoria + osservabilità.

OpenSearchCon 2026 mostra l'evoluzione della ricerca

OpenSearchCon North America 2026 si terrà dal 22 al 24 settembre a San Jose, in California.

L'agenda include ancora rilevanza, Lucene, operazioni sui cluster e osservabilità tradizionale, ma gran parte della discussione del 2026 ora si estende a RAG, recupero ibrido, prestazioni vettoriali, MCP e osservabilità degli agenti IA.

Questa direzione è in linea con la roadmap 2026 del progetto, che considera gli agenti IA una nuova categoria di utenti della ricerca e include contesto agentico, memoria, instradamento degli strumenti e MCP.

Il cambiamento importante non è che OpenSearch abbia aggiunto funzionalità di IA.

La ricerca sta diventando un'infrastruttura per i sistemi che recuperano informazioni e poi agiscono su di esse.

Un agente IA serio ha bisogno di due cronologie consultabili

La maggior parte dei tutorial sul RAG si concentra su una sola domanda:

Che cosa dovrebbe sapere il modello?

Gli agenti a esecuzione prolungata introducono un'altra domanda:

Che cosa ha fatto realmente l'agente?

Indice	Domanda principale	Dati tipici
Indice della conoscenza	Quali prove dovrebbe recuperare l'agente?	Documenti, segmenti, embedding, metadati, versioni, autorizzazioni
Indice di esecuzione	Che cosa è successo durante l'attività?	Chiamate al modello, recuperi, chiamate agli strumenti, latenza, token, errori, tentativi

Il primo migliora le risposte. Il secondo rende il sistema diagnosticabile.

Questo è importante perché un messaggio finale della chat può nascondere un flusso di lavoro non riuscito. Un agente può affermare che un'attività è completata anche se ha recuperato il contesto sbagliato, selezionato lo strumento errato o non ha mai eseguito l'azione prevista.

OpenSearchCon ha una sessione dedicata esattamente a questo problema: Watching AI Workers: osservabilità OpenSearch per OpenClaw e Hermes-agent.

Il caso di errore descritto è importante perché la soluzione non era una trascrizione della chat migliore. Era la telemetria operativa: invocazioni del modello, recupero del contesto e chiamate agli strumenti rappresentati come tracce.

Un agente crea due tipi di cronologia consultabile: ciò che sapeva e ciò che ha fatto.

Molti errori RAG si verificano prima che l’LLM veda qualcosa

Quando una risposta RAG è sbagliata, sostituire il modello linguistico è una reazione ovvia. Potrebbe però essere il livello sbagliato da correggere.

La sessione Fix Your Retrieval, Fix Your RAG di OpenSearchCon sostiene direttamente questa tesi: molti apparenti errori di generazione hanno origine nel livello di recupero, che decide quali prove arrivano al modello.

Errore di recupero	Cosa vede l’utente	Problema reale
Il documento sbagliato si posiziona per primo	Risposta irrilevante espressa con sicurezza	Classificazione
La fonte corretta ha un posizionamento troppo basso	Informazioni mancanti	Richiamo
Prevale la versione precedente	Risposta obsoleta	Aggiornamento e metadati
Il chunk perde il contesto	Risposta parzialmente corretta	Suddivisione in chunk e struttura
L’identificatore esatto scompare	Diagnosi tecnica errata	Recupero lessicale
Non esiste alcun set di test valutato	«Sembra migliore»	Valutazione del recupero

La regola per il debug è semplice:

il modello non può ragionare su prove che il recupero non ha mai inserito nel suo contesto.

Il RAG in produzione deve inoltre fornire un risultato aggiornato, non soltanto semanticamente simile. Un documento per la versione 2.0 del software può essere molto vicino nello spazio degli embedding alla versione 4.0, continuando però a fornire all’agente la procedura sbagliata.

I metadati utili per il recupero possono quindi includere:

la versione,
la data di pubblicazione,
il prodotto o l’ambiente,
lo stato del documento,
l’autorità della fonte,
e i permessi di accesso.

La qualità del recupero è la rilevanza nel contesto corretto.

La ricerca per parole chiave non ha perso contro la ricerca vettoriale

Il boom della ricerca vettoriale ha favorito una narrazione semplice: la ricerca per parole chiave era obsoleta e gli embedding ne erano il sostituto.

Il recupero tecnico rende questa distinzione molto meno netta.

Tipo di query	Ricerca lessicale	Ricerca vettoriale
Codice di errore	Eccellente	Variabile
Numero di prodotto/modello	Eccellente	Variabile
Nome di una funzione o di un’API	Eccellente	Dipende
Intento espresso in linguaggio naturale	Moderato	Eccellente
Formulazione concettualmente simile	Da debole a moderato	Eccellente

Una query come Errore CUDA 802 su RTX 5090 contiene sia significato semantico sia token esatti che non dovrebbero scomparire in una similarità approssimata.

Per questo OpenSearchCon continua a sottolineare l’importanza del recupero ibrido. La difficoltà non consiste semplicemente nell’eseguire insieme la ricerca per parole chiave e quella vettoriale; consiste nel decidere come normalizzare, classificare e combinare i relativi punteggi.

La scelta utile non è più tra parole chiave e vettori. È quanta precisione e quanto significato semantico richiede ogni query.

La ricerca vettoriale ha un proprio budget di memoria

Le discussioni sull’hardware per l’IA locale iniziano di solito dalla RAM e dalla VRAM del modello. Il RAG introduce un altro consumatore di memoria: il recupero.

Durante OpenSearchCon, le discussioni sulle sessioni di ricerca vettoriale trattano sempre più spesso memoria a grafo, compressione, richiamo, throughput e latenza P99 nel loro insieme. Con embedding di dimensioni maggiori, la memoria diventa parte dell’architettura della ricerca, anziché un semplice dettaglio implementativo.

Componente IA locale	Pressione sulla risorsa principale
LLM	RAM / VRAM
Modello di embedding	RAM / VRAM
OpenSearch	Heap della JVM e memoria di sistema
Indici vettoriali	Memoria e archiviazione
Cache dei documenti	Memoria
Strumenti dell’agente	CPU, RAM e risorse specifiche del servizio

L’implicazione pratica è semplice:

un server RAG locale necessita di un budget per il recupero oltre a un budget per il modello.

«Questo computer può caricare il mio modello?» non è più una guida sufficiente al dimensionamento quando lo stesso host incorpora anche documenti, gestisce indici ed esegue agenti.

Gli agenti trasformano l’osservabilità in parte del livello dati

L’osservabilità tradizionale chiede se una richiesta non è riuscita, quale servizio era lento e che cosa mostrano i log.

Un agente aggiunge chiamate al modello, decisioni di recupero ed esecuzione degli strumenti.

Software tradizionale	Sistema agentico
Richiesta	Attività dell’agente
Chiamata di funzione	Chiamata allo strumento
Latenza del servizio	Latenza del modello + recupero + strumento
Errore	Errore del modello, della ricerca o dello strumento
Uso dell’infrastruttura	Infrastruttura + uso dei token
Traccia distribuita	Traccia di esecuzione dell’agente

Gli attuali OpenSearch Agent Traces utilizzano le convenzioni OpenTelemetry per rappresentare le operazioni dell’agente, del modello linguistico, di recupero, di embedding e degli strumenti.

Questo rende possibili domande molto più specifiche:

Il recupero ha richiesto troppo tempo?
L’agente ha chiamato ripetutamente lo stesso strumento?
Un ciclo di nuovi tentativi ha aumentato l’uso dei token?
Il modello ha fatto una scelta valida, ma lo strumento non ha funzionato?
Una nuova versione dell’agente ha modificato il comportamento di esecuzione?

La memoria persistente crea un problema analogo di ciclo di vita. Conservare tutto per sempre aumenta l’uso dello spazio di archiviazione e consente al contesto obsoleto di rimanere ricercabile; eliminare in modo troppo aggressivo fa sì che l’agente debba reimparare ripetutamente le informazioni utili.

Ciò significa che la memoria dell’agente necessita di regole esplicite per:

che cosa diventa memoria a lungo termine,
che cosa può scadere,
che cosa appartiene a una cronologia di audit,
e che cosa dovrebbe smettere di influenzare i recuperi futuri.

La memoria dell’agente non è solo una funzionalità di recupero. È una politica del ciclo di vita dei dati.

La ricerca diventa un confine di sicurezza quando chi effettua la ricerca può agire

Una persona che cerca backup non riusciti e un agente che cerca backup non riusciti comportano rischi diversi.

L’essere umano può esaminare il risultato. L’agente può usare il risultato per chiamare un altro strumento.

OpenSearch include un server MCP che può esporre ricerca, PPL, SQL e informazioni sul cluster agli agenti compatibili.

Ricerca tradizionale	Ricerca agentica
Questo utente può accedere all’indice?	Che cosa può recuperare questo agente?
È possibile eseguire questa query?	Quali strumenti di ricerca può chiamare l’agente?
È possibile leggere questo record?	Quale azione potrebbe seguire dalla lettura?

Quando il recupero diventa parte di un ciclo d’azione, le autorizzazioni di ricerca diventano parte del perimetro delle capacità dell’agente.

Tre casi reali di IA self-hosted che mostrano perché il livello dati è importante

La distinzione tra modello, recupero e stato dell’agente diventa più facile da comprendere nei sistemi realmente self-hosted.

1. Un workspace RAG privato ha un carico di lavoro dei dati separato dall’inferenza

AnythingLLM è un esempio utile. L’applicazione può gestire documenti, embedding e recupero mentre il modello linguistico viene eseguito localmente, da remoto o tramite un’API.

L’attuale guida ai requisiti hardware per RAG di AnythingLLM rende esplicita la separazione: l’acquisizione dei documenti, gli embedding locali, i dati vettoriali e lo storage persistente hanno requisiti propri, mentre l’inferenza locale del modello deve essere dimensionata separatamente.

È esattamente l’errore che la discussione alla OpenSearchCon aiuta a chiarire.

Un sistema RAG non ha un unico requisito hardware. Ne ha almeno due:

il carico di lavoro del modello,
e il carico di lavoro della conoscenza e del recupero.

Con la crescita della raccolta di documenti, l’acquisizione, l’indicizzazione, i metadati e il backup possono diventare colli di bottiglia anche quando il modello linguistico non cambia.

2. Un agente attivo 24 ore su 24, 7 giorni su 7 crea uno stato di esecuzione persistente

OpenClaw illustra l’altro lato del modello dei due indici.

Un gateway OpenClaw self-hosted può mantenere conversazioni persistenti, eseguire chiamate agli strumenti, svolgere attività pianificate, ricevere webhook e coordinare più flussi di lavoro degli agenti. La guida al gateway privato per agenti IA considera l’agente come un servizio sempre attivo, anziché come una finestra di chat che scompare quando si chiude il laptop.

Questa persistenza crea domande operative che una normale chat non pone:

Quale strumento ha chiamato l’agente?
Quale attività non è riuscita durante la notte?
Quante volte è stata ritentata un’operazione?
Quale contesto è stato caricato prima della decisione?
L’agente ha segnalato il successo senza completare l’azione?

Ecco perché la sessione sull’osservabilità di OpenClaw/Hermes alla OpenSearchCon è particolarmente rilevante per gli agenti self-hosted. Quando l’agente opera senza supervisione, la cronologia delle esecuzioni diventa infrastruttura, non un dettaglio irrilevante del debugging.

3. La memoria persistente diventa parte dell’architettura del workspace

Un flusso di lavoro Hermes reale mostra un terzo modello. Invece di inserire tutto in un unico database opaco dell’agente, un workspace privato per agenti IA può separare il runtime dell’agente, la memoria Markdown leggibile dagli esseri umani, la cronologia di Git, i canali di comunicazione e lo storage sempre attivo.

Questa architettura è utile perché la “memoria dell’agente” non è necessariamente un unico archivio vettoriale monolitico.

Informazioni diverse possono richiedere regole del ciclo di vita differenti:

Dati	Motivo per conservarla
Contesto operativo	Continuità delle attività a breve termine
Note curate	Conoscenza a lungo termine
Cronologia di Git	Revisione e ripristino
Tracce dell’agente	Analisi operativa
Output grezzo degli strumenti	Evidenze temporanee o debug

La migliore architettura della memoria potrebbe non consistere nel «conservare tutto per sempre». Consiste nel decidere quale tipo di stato rappresenti effettivamente ogni informazione.

Quando ha davvero senso il self-hosting di OpenSearch?

Questi esempi non significano che ogni server AI locale debba installare OpenSearch.

Caso d’uso	Idoneità di OpenSearch
Chat con qualche decina di PDF	Probabilmente eccessivo
RAG per piccole note personali	Di solito esistono opzioni più semplici
Ampia raccolta di documenti in evoluzione	Utile
Recupero per parole chiave + semantico	Molto adatto
Più app che condividono un indice della conoscenza	Molto adatto
Log, tracce e ricerca su un’unica piattaforma	Molto adatto
Memoria degli agenti e analisi dell’esecuzione	Potenzialmente molto adatto

OpenSearch è di per sé un’infrastruttura stateful. Eseguirlo significa gestire indici, memoria JVM, spazio di archiviazione persistente, snapshot, conservazione, autorizzazioni, aggiornamenti e ripristino.

Il OpenSearch Observability Stack locale può essere eseguito tramite Docker Compose, ma i prerequisiti di installazione ufficiali richiedono già almeno 8 GB di RAM disponibile.

Prima di implementarlo, chiediti:

Quanti dati sto indicizzando effettivamente?
Ho bisogno di combinare il recupero per parole chiave e quello semantico?
La stessa piattaforma dati conterrà anche log, tracce o lo stato degli agenti?
Sono disposto a gestire un altro servizio stateful?

La domanda utile non è «posso eseguire OpenSearch a casa?». È «il mio stack AI ha una complessità di recupero e osservabilità sufficiente da giustificarlo?»

Dimensiona il server AI per qualcosa di più del modello

Quando l’IA locale va oltre un’interfaccia di chat, cambia la pianificazione dell’hardware.

Un server RAG o per agenti di dimensioni maggiori potrebbe aver bisogno di risorse per:

inferenza del modello,
embedding,
indici di ricerca,
archiviazione dei documenti,
database,
runtime degli agenti,
log e tracce,
e backup.

L’attuale guida al dimensionamento dell’hardware per Open WebUI illustra lo stesso schema: la memoria dell’applicazione, l’elaborazione dei documenti, gli embedding e lo spazio di archiviazione per il RAG sono separati dai requisiti di memoria o VRAM, molto più elevati, di un LLM locale.

Per i carichi di lavoro che richiedono realmente più memoria di sistema, dataset distribuiti su più unità e inferenza GPU compatibile su un’unica macchina, un server AI locale ricco di spazio di archiviazione può consolidare questi livelli. Tuttavia, l’hardware dovrebbe essere scelto in base al modello effettivo, al corpus vettoriale, al periodo di conservazione e alla concorrenza, non in base all’etichetta «server AI».

Più GPU non risolve un indice di ricerca sottodimensionato, e più spazio di archiviazione non risolve una memoria del modello insufficiente.

Il server AI ha bisogno di un livello dati, non solo di un modello più grande

Le discussioni sull’IA locale si concentrano naturalmente sui modelli, perché i modelli dominano le classifiche dei benchmark.

Ma i sistemi RAG e basati su agenti a esecuzione prolungata accumulano gradualmente un ulteriore livello infrastrutturale:

i documenti e i metadati,
gli indici lessicali e vettoriali,
la memoria dell’agente,
le integrazioni con gli strumenti,
i log e le tracce di esecuzione,
le autorizzazioni,
e le politiche di conservazione.

Il modello genera la risposta. Il livello dati determina quali elementi di prova lo raggiungono, quale contesto viene conservato e se qualcuno può spiegare cosa è successo quando l’agente si comporta in modo imprevisto.

Questa è la storia più ampia alla base di OpenSearchCon 2026.

Gli agenti di IA stanno trasformando la ricerca da funzionalità a infrastruttura.

Un agente serio ha quindi bisogno di risposte affidabili a due domande persistenti:

Che cosa dovrebbe sapere questo agente in questo momento?
Che cosa ha fatto davvero questo agente?

Un database vettoriale può aiutare con il primo aspetto. L’infrastruttura degli agenti in produzione deve prima o poi rispondere a entrambi.

Domande frequenti

Quando si terrà OpenSearchCon North America 2026?

OpenSearchCon North America 2026 si terrà dal 22 al 24 settembre a San Jose, in California. La conferenza tratterà la ricerca open source, l’osservabilità, il recupero vettoriale, il RAG e l’IA agentica.

OpenSearch è un database vettoriale?

OpenSearch può archiviare e cercare embedding vettoriali, ma è più ampio di un database vettoriale dedicato. Supporta anche la ricerca lessicale, il recupero ibrido, il filtraggio dei metadati, l’analisi e i carichi di lavoro di osservabilità.

OpenSearch è adatto al RAG?

Può essere un’ottima scelta quando il RAG richiede ricerca ibrida, filtri per metadati e versioni, valutazione della rilevanza o una raccolta di documenti ampia e in continua evoluzione. I sistemi RAG personali più piccoli possono essere più semplici da gestire con un’infrastruttura più leggera.

Che cos’è la ricerca ibrida in OpenSearch?

La ricerca ibrida combina segnali lessicali come BM25 con il recupero semantico o vettoriale. È particolarmente utile quando una query contiene sia identificatori tecnici esatti sia un intento più ampio espresso in linguaggio naturale.

OpenSearch può monitorare gli agenti di IA?

Sì. OpenSearch Agent Traces utilizza la telemetria basata su OpenTelemetry per esporre le chiamate ai modelli, i recuperi e l’utilizzo degli strumenti, insieme alle informazioni su latenza e token.

OpenSearch supporta MCP?

Sì. OpenSearch offre funzionalità MCP che consentono agli agenti compatibili di accedere alla ricerca, a PPL, SQL e ad altri strumenti per i dati. Le autorizzazioni restano importanti, perché le informazioni recuperate possono alimentare direttamente le azioni degli agenti.

Ho bisogno di OpenSearch per un server RAG locale?

Non necessariamente. Una piccola raccolta personale di documenti può solitamente utilizzare un’infrastruttura di recupero più semplice. OpenSearch diventa più interessante quando il sistema richiede indici più grandi e in evoluzione, ricerca ibrida, conoscenze condivise, osservabilità o più carichi di lavoro basati su agenti.

Quanta RAM richiede OpenSearch self-hosted?

I requisiti dipendono dalle dimensioni dell’indice, dalle dimensioni dei vettori, dal carico di query e dalle politiche di conservazione. L’attuale OpenSearch Observability Stack locale indica come prerequisito almeno 8 GB di RAM disponibile, mentre carichi di lavoro più intensivi con vettori e telemetria possono richiederne sostanzialmente di più.