RAG e Vector Engine: La guida definitiva per OpenSearch

RAG, Vector Search, Embeddings: non sono più novità.

Non si tratta più di più tecnologie emergenti, ma di fondamenta. Ogni applicazione enterprise che vuole davvero sfruttare l’AI Generativa, parte da qui.

Il punto non è più se implementare o meno, ma come farlo senza far esplodere il budget o trasformare l’infrastruttura in un incubo operativo.

Se, poi, il tuo stack è su AWS, un’altra da porre è: quanto ti costa uscire dall’ecosistema per una funzionalità che hai già?

Amazon OpenSearch Service non nasce come vector database puro. Non deve esserlo. È l’orchestratore che fonde search testuale, vector search e integrazione nativa con Bedrock, SageMaker e Lambda. Qdrant vola. Pinecone semplifica. Ma aggiungere un servizio esterno ha un costo che sia operativo, economico o di complessità, che raramente viene messo in conto davvero.

Questo articolo non è teoria. È un deep-dive architetturale per chi vuole sistemi RAG production-ready. Provisioned vs Serverless. Configurazione indici k-Nearest Neighbors. Chunking strategy. Le scelte che fanno la differenza tra un prototipo che gira e un sistema che scala.

OpenSearch come Vector Database: molto più che ricerca testuale

Partiamo dalle basi. OpenSearch non nasce come vector database puro. È un fork open-source di Elasticsearch (2021), costruito per search e analytics. Il supporto vettoriale è arrivato dopo.

E allora perché usarlo?

I motivi concreti per scegliere OpenSearch

1. Hybrid search nativo.

I casi d’uso reali raramente richiedono solo similarity search vettoriale. Serve combinare ricerca semantica (vector), keyword search (BM25) e filtri sui metadata. OpenSearch fa tutto in una singola query. Zero orchestrazione esterna.

2. Ecosistema maturo.

Usi già OpenSearch o Elasticsearch per logging, monitoring, search? Aggiungere vector search significa estendere quello che hai, non costruire qualcosa di nuovo. Meno complessità operativa. Meno costi nascosti.

3. Integrazione AWS nativa.

Bedrock Knowledge Bases, SageMaker, Lambda, Kinesis. Stack AWS-centrico? L’overhead di integrazione è minimo.

Storage tiering. Con UltraWarm e Cold Storage tieni i vettori storici a costo ridotto. Hot tier solo per i dati più acceduti. Prova a farlo con Pinecone o Weaviate senza ginnastica architetturale.

Quando OpenSearch non è la risposta giusta

Siamo onesti. OpenSearch non è sempre la scelta giusta.

Ecco i casi in cui vale la pena guardare altrove:

Vuoi solo vector search puro?

Nessun hybrid search, nessuna integrazione con stack esistente?
Database purpose-built come Pinecone o Qdrant offrono latenze più basse, setup più semplice, esperienza developer ottimizzata per quel caso specifico. Se parti da zero con il solo obiettivo di fare similarity search, ha senso considerarli prima.
Vuoi restare AWS-nativo ma OpenSearch è troppo?
Amazon S3 Vectors (GA da fine 2025) è la risposta AWS per i casi semplici. Salvi i vettori direttamente su S3, interroghi con ANN query, paghi per quello che consumi. Zero infrastruttura.

è utile quando:

Hai dataset di piccole o medie dimensioni senza bisogno di hybrid search
La tua RAG è semplice: query semantiche su un corpus statico o poco aggiornato
Il team vuole prototipare in fretta, senza provisioning di cluster
Il budget è limitato: il costo per vettore è significativamente inferiore a OpenSearch

Non è utile quando:

Ti serve BM25 o hybrid search — S3 Vectors supporta solo similarity search
Hai requisiti di latenza stringenti o workload ad alto throughput
Vuoi controllo su algoritmo di indicizzazione, shard o replica

Requisito di portabilità multi-cloud?

Se il vincolo architetturale è evitare il lock-in AWS a tutti i costi, soluzioni come Weaviate o Milvus offrono più flessibilità di deployment. Ma se lavori già in AWS, e la maggior parte dei team enterprise lo fa, questo scenario raramente giustifica la complessità aggiuntiva.

Team senza esperienza OpenSearch?

Gestire shard allocation, replica, heap memory e configurazione degli indici richiede competenze operative che non si improvvisano. Se il team è piccolo e nessuno ha mai operato un cluster OpenSearch, il time-to-value di una soluzione managed come Pinecone può essere molto più basso, almeno nelle fasi iniziali.

Provisioned vs Serverless: quale deployment model fa per te?

Amazon OpenSearch Service offre due deployment model. La scelta impatta costi, performance e quanto dovrai gestire tu.

Provisioned Domains: controllo totale, responsabilità totale

Cluster tradizionali con nodi EC2. Scegli instance types, storage, shard count, replica. Massima flessibilità. Massima responsabilità.

Usalo quando:

Il traffico è prevedibile e hai bisogno di fine-tuning su performance (thread pool, cache, circuit breakers)
I volumi sono elevati e le Reserved Instances giustificano il risparmio (30-50% vs on-demand)
Hai requisiti di latenza stringenti (<50ms p99)

Instance sizing: non sbagliare.

Per workload vector-intensive, scegli memory-optimized instances (r6g, r7g). Gli indici k-NN divorano RAM. Un r6g.xlarge.search con 32GB RAM gestisce meglio le vector queries di un c6g.2xlarge con 16GB, anche con meno vCPU.

Serverless: semplice, ma non gratis

OpenSearch Serverless elimina la gestione dell’infrastruttura. Crei collections, indicizzi dati, AWS scala automaticamente. Paghi OCU (OpenSearch Compute Units) consumati.

Usalo quando:

Il traffico è imprevedibile o stai ancora sperimentando
Il team è piccolo e non ha expertise OpenSearch avanzata
Vuoi andare in produzione in fretta, senza tuning

Attenzione: Serverless ≠ economico.

Il pricing OCU-based può diventare caro per volumi elevati e costanti. Un cluster Provisioned con Reserved Instances costa il 40-60% in meno. Fai bene i conti prima di scegliere.

Configurazione indici k-Nearest Neighbors (k-NN): le scelte che contano

Il cuore del vector search su OpenSearch è il k-NN plugin. Configurarlo bene significa prendere decisioni architetturali che impattano performance, recall accuracy e costi.

Ci sono poi alcuni dettagli tecnici da scegliere per proseguire con il setup.

HNSW o IVF? Dipende dal tuo workload

OpenSearch supporta due algoritmi ANN (Approximate Nearest Neighbors). Non sono equivalenti.

HNSW (Hierarchical Navigable Small World)

Graph-based. Veloce nelle query, lento nell’indicizzazione
Recall accuracy elevata: 95-99%
Consuma più memoria — la struttura grafo vive in RAM
Ideale per workload query-intensive con requisiti di bassa latenza

IVF (Inverted File Index)

Clustering-based. Più veloce nell’indicizzazione
Recall leggermente inferiore: 90-95% con tuning
Usa meno memoria
Ideale per workload write-intensive e dataset molto grandi

NOTA: IVF richiede un training step obbligatorio. Prima di indicizzare, devi addestrare un modello con la Train API passando la definizione del metodo IVF. Il training richiede almeno nlist data point (meglio di più). Più complessità rispetto a HNSW, che non richiede training.

Space type: scegli la metrica giusta

La metrica di distanza (space_type) dipende dal modello di embedding che usi:

cosinesimil: Misura l’angolo tra vettori. Utile se i vettori non sono normalizzati e ti interessa solo l'orientamento, non la magnitudo.
innerproduct: Dot product. La scelta ideale per performance se usi vettori già normalizzati (come OpenAI o Cohere). Calcolare il dot product su vettori a lunghezza unitaria è matematicamente identico alla cosine similarity, ma molto più veloce perché risparmia a OpenSearch il calcolo della magnitudo a runtime.
l2 (Distanza Euclidea): Misura la distanza "in linea retta" tra i punti. Da usare quando la magnitudo (la lunghezza del vettore) ha un significato specifico per il tuo dominio, ad esempio in alcuni sistemi di raccomandazione dove la lunghezza del vettore riflette la frequenza, l'intensità o la confidenza dei dati, e non solo la loro somiglianza tematica.

Regola pratica: Usi OpenAI o modelli simili? Normalizza i vettori (o lascia che se ne occupi OpenSearch dalla versione 2.18+) e usa innerproduct per spingere al massimo le performance di query.

Tuning dei parametri: recall vs latenza

Il tuning di k-NN è un tradeoff continuo. Più recall = più latenza. Conosci i valori default attuali prima di toccare qualsiasi cosa.

ef_construction (HNSW, index-time)

Range: 100-512
Più alto = recall migliore, indicizzazione più lenta
Default attuale: 128 (attenzione: era 512 nelle versioni ≤ 2.11)

ef_search (HNSW, query-time)

Range: 50-500
Più alto = recall migliore, query più lenta
Default attuale: 100

m (HNSW)

Range: 8-64
Più alto = recall migliore, più memoria
Default attuale: 16

RAG Pipeline end-to-end: dalla teoria alla produzione

Infrastruttura pronta? Costruiamo la pipeline.

Step 1: Document Ingestion e Chunking

Il chunking è la variabile più sottovalutata. Chunk troppo piccoli perdono contesto. Troppo grandi aumentano noise e costi. Non esiste una risposta universale: dipende dai tuoi dati.

Di seguito i tre blocchi fondamentali.

1. Chunking con semantic awareness

self.splitter = RecursiveCharacterTextSplitter(

chunk_size=chunk_size,

chunk_overlap=chunk_overlap,

separators=["\n\n", "\n", ". ", " ", ""]

)

2. Generazione embeddings con Amazon Bedrock Titan

response = self.bedrock.invoke_model(

modelId=self.embedding_model,

body=json.dumps({"inputText": text})

)

embedding = json.loads(response['body'].read())['embedding']

3. Bulk indexing su OpenSearch

success, failed = helpers.bulk(

client,

actions,

chunk_size=batch_size,

raise_on_error=False

)

Da prototipo a produzione: le scelte sono tue

RAG e Vector Search non sono più esperimenti. Sono produzione.

OpenSearch ti dà gli strumenti. Ma gli strumenti non bastano: serve saper scegliere.

Provisioned o Serverless? HNSW o IVF? Chunking strategy? Non esiste una risposta universale. Esiste quella giusta per il tuo caso d’uso. E speriamo che questo articolo ti abbia dato le risorse per farti le domande giuste.

Se vuoi parlare di come implementare tutto questo nel tuo stack AWS, sai dove trovarci.

---
Fonti e riferimenti

Questo articolo si basa su documentazione ufficiale, best practice AWS e implementazioni reali in ambienti di produzione.

Documentazione AWS OpenSearch Service:

CloudFormation e IaC:

Terraform AWS OpenSearch Provider
AWS CloudFormation OpenSearch Resource Reference

Fabio Gabas

DevOps presso beSharp, amo progettare soluzioni di Machine Learning e Intelligenza Artificiale Generativa nel cloud. Dopo aver trascorso alcuni anni come chimico teorico, ho deciso di passare all'intelligenza artificiale con l'obiettivo di far fare ai computer il lavoro per me! Nel tempo libero mi piace ascoltare musica meno conosciuta e divertirmi a giocare ai giochi di carte collezionabili, in particolare Magic (...ma esistono davvero altri giochi di carte collezionabili?).