Scelta di un database vettoriale per la ricerca di RNA su Reddit

Questo post è stato scritto da Chris Fournie, Staff Software Engineer di Reddit, ed è stato pubblicato originariamente su Reddit; viene ripubblicato qui con l'autorizzazione.

Nel 2024, i team di Reddit hanno utilizzato una serie di soluzioni per eseguire la ricerca vettoriale approssimata del vicino (ANN). Da Vertex AI Vector Search di Google e sperimentando l'uso della ricerca vettoriale ANN di Apache Solr per alcuni insiemi di dati più grandi, alla libreria FAISS di Facebook per insiemi di dati più piccoli (ospitati in side-car in scala verticale). Un numero sempre maggiore di team di Reddit desiderava una soluzione di ricerca vettoriale ANN ampiamente supportata, che fosse economicamente vantaggiosa, dotata delle funzionalità di ricerca desiderate e in grado di scalare i dati alle dimensioni di Reddit. Per rispondere a questa esigenza, nel 2025 abbiamo cercato il database vettoriale ideale per i team di Reddit.

Questo post descrive il processo utilizzato per selezionare il miglior database vettoriale per le esigenze di Reddit oggi. Non descrive il miglior database vettoriale in assoluto, né l'insieme più essenziale di requisiti funzionali e non funzionali per tutte le situazioni. Descrive ciò che Reddit e la sua cultura ingegneristica hanno valutato e dato priorità nella scelta di un database vettoriale. Questo post può servire da ispirazione per la vostra raccolta e valutazione dei requisiti, ma ogni organizzazione ha la propria cultura, i propri valori e le proprie esigenze.

Processo di valutazione

In generale, le fasi di selezione sono state:

1. Raccogliere il contesto dai team

2. Valutazione qualitativa delle soluzioni

3. Valutare quantitativamente i migliori contendenti

4. Selezione finale

1. Raccolta del contesto dai team

Sono stati raccolti tre elementi di contesto dai team interessati a eseguire la ricerca vettoriale di RNA:

• Requisiti funzionali (ad esempio, ricerca vettoriale e lessicale ibrida? Query di ricerca a range? Filtraggio per attributi non vettoriali?)

• Requisiti non funzionali (ad esempio, può supportare 1B vettori? Può raggiungere una latenza <100ms P99?)

• I database vettoriali erano già interessati ai gruppi di lavoro.

Intervistare i team per conoscere i requisiti non è banale. Molti descriveranno le loro esigenze in termini di come stanno attualmente risolvendo un problema, e la vostra sfida consiste nel capire e rimuovere questo pregiudizio.

Ad esempio, un team utilizzava già FAISS per la ricerca vettoriale di RNA e ha dichiarato che la nuova soluzione doveva restituire in modo efficiente 10.000 risultati per ogni chiamata di ricerca. Dopo un'ulteriore discussione, il motivo dei 10.000 risultati era che avevano bisogno di eseguire un filtraggio post-hoc, e FAISS non offre il filtraggio dei risultati ANN al momento della query. Il loro problema reale era che avevano bisogno di filtrare, quindi qualsiasi soluzione che offrisse un filtraggio efficiente sarebbe stata sufficiente, e la restituzione di 10.000 risultati era semplicemente un workaround necessario per migliorare il richiamo. Idealmente, vorrebbero pre-filtrare l'intera collezione prima di trovare i vicini.

Anche la richiesta dei database vettoriali che i team stavano già utilizzando o a cui erano interessati è stata preziosa. Se almeno un team ha espresso un parere positivo sulla propria soluzione attuale, è segno che il database vettoriale potrebbe essere una soluzione utile da condividere in tutta l'azienda. Se i team avevano solo opinioni negative su una soluzione, allora non dovevamo includerla come opzione. Accettare le soluzioni a cui i team erano interessati è stato anche un modo per assicurarsi che i team si sentissero inclusi nel processo e ci ha aiutato a formare un elenco iniziale di contendenti principali da valutare; ci sono troppe soluzioni di ricerca vettoriale RNA nei database nuovi ed esistenti per testarle tutte in modo esaustivo.

2. Valutazione qualitativa delle soluzioni

Partendo dall'elenco di soluzioni a cui i team erano interessati, per valutare qualitativamente quale soluzione di ricerca vettoriale ANN si adattava meglio alle nostre esigenze, abbiamo

• Abbiamo ricercato ogni soluzione e valutato il grado di soddisfazione di ogni requisito rispetto all'importanza ponderata del requisito stesso.

• Abbiamo eliminato le soluzioni in base ai criteri qualitativi e alla discussione.

• Abbiamo scelto le N soluzioni migliori da testare quantitativamente.

Il nostro elenco iniziale di soluzioni per la ricerca vettoriale di RNA comprendeva:

• Milvus

• Qdrant

• Weviate

• Ricerca aperta

• Pgvector (utilizza già Postgres come RDBMS)

• Redis (già utilizzato come archivio e cache KV)

• Cassandra (già utilizzato per la ricerca non-ANN)

• Solr (già utilizzato per la ricerca lessicale e sperimentato con la ricerca vettoriale)

• Vespa

• Pinecone

• Vertex AI (già utilizzato per la ricerca vettoriale ANN)

Abbiamo quindi preso tutti i requisiti funzionali e non funzionali menzionati dai team, più altri vincoli che rappresentano i nostri valori e obiettivi ingegneristici, li abbiamo inseriti in un foglio di calcolo e ne abbiamo valutato l'importanza (da 1 a 3, come mostra la tabella riassuntiva qui sotto).

Per ogni soluzione che stavamo confrontando, abbiamo valutato (su una scala da 0 a 3) quanto ciascun sistema soddisfacesse quel requisito (come mostrato nella tabella seguente). L'attribuzione dei punteggi in questo modo era in qualche modo soggettiva, per cui abbiamo scelto un sistema e abbiamo fornito esempi di punteggi con motivazioni scritte, chiedendo ai revisori di fare riferimento a tali esempi. Abbiamo inoltre fornito le seguenti indicazioni per l'assegnazione di ciascun punteggio: assegnare questo valore se:

• 0: Nessun supporto/prova di supporto ai requisiti

• 1: Supporto di base o inadeguato del requisito

• 2: Requisito ragionevolmente supportato

• 3: Robusto supporto al requisito che va oltre le soluzioni comparabili.

Abbiamo quindi creato un punteggio complessivo per ogni soluzione sommando il prodotto del punteggio del requisito di una soluzione e l'importanza di quel requisito (ad esempio, Qdrant ha ottenuto un punteggio di 3 per la combinazione di ri-ranking/score, che ha un'importanza di 2, quindi 3 x 2 = 6, ripetere l'operazione per tutte le righe e sommare il tutto). Alla fine si ottiene un punteggio complessivo che può essere usato come base per classificare e discutere le soluzioni e i requisiti più importanti (si noti che il punteggio non viene usato per prendere una decisione finale, ma come strumento di discussione).

Nota dell'editore: questa recensione era basata su Milvus 2.4. Da allora abbiamo lanciato Milvus 2.5, Milvus 2.6 e Milvus 3.0 è alle porte, quindi alcuni numeri potrebbero essere obsoleti. Tuttavia, il confronto offre sempre spunti importanti e rimane molto utile.

Categoria	Importanza	Qdrant	Milvus (2.4)	Cassandra	Weviate	Solr	Vertex AI
Tipo di ricerca
Ricerca ibrida	1	3	2	0	2	2	2
Ricerca per parola chiave	1	2	2	2	2	3	1
Ricerca approssimativa NN	3	3	3	2	2	2	2
Ricerca di gamma	1	3	3	2	2	0	0
Riarrangiamento/combinazione dei punteggi	2	3	2	0	2	2	1
Metodo di indicizzazione
HNSW	3	3	3	2	2	2	0
Supporta più metodi di indicizzazione	3	0	3	1	2	1	1
Quantizzazione	1	3	3	0	3	0	0
Hashing sensibile ai luoghi (LSH)	1	0	0Nota: Milvus 2.6 lo supporta.	0	0	0	0
Dati
Tipi di vettore diversi da float	1	2	2	0	2	2	0
Attributi di metadati su vettori (supporta attributi multipli, grandi dimensioni del record, ecc.)	3	3	2	2	2	2	1
Opzioni di filtraggio dei metadati (può filtrare sui metadati, ha un filtro pre/post)	2	3	2	2	2	3	2
Tipi di dati degli attributi dei metadati (schema robusto, ad esempio bool, int, string, json, array)	1	3	3	2	2	3	1
Limiti degli attributi dei metadati (query di intervallo, ad esempio 10 < x < 15)	1	3	3	2	2	2	1
Diversità dei risultati per attributo (ad esempio, ottenere non più di N risultati da ogni subreddit in una risposta)	1	2	1	2	3	3	0
Scala
Centinaia di milioni di indici vettoriali	3	2	3		1	2	3
Indice del vettore miliardi	1	2	2		1	2	2
Vettori di supporto almeno 2k	2	2	2	2	2	1	1
Vettori di supporto maggiori di 2k	2	2	2	2	1	1	1
P95 Latenza 50-100ms @ X QPS	3	2	2	2	1	1	2
P99 Latenza <= 10ms @ X QPS	3	2	2	2	3	1	2
99,9% di disponibilità recupero	2	2	2	3	2	2	2
99,99% di disponibilità indicizzazione/stoccaggio	2	1	1	3	2	2	2
Operazioni di archiviazione
Ospitabile in AWS	3	2	2	2	2	3	0
Multi-Regione	1	1	2	3	1	2	2
Aggiornamenti a tempo zero	1	2	2	3	2	2	1
Multi-Cloud	1	3	3	3	2	2	0
API/Librerie
gRPC	2	2	2	2	2	0	2
API RESTful	1	3	2	2	2	1	2
Vai alla biblioteca	3	2	2	2	2	1	2
Biblioteca Java	2	2	2	2	2	2	2
Pitone	2	2	2	2	2	2	2
Altri linguaggi (C++, Ruby, ecc.)	1	2	2	3	2	2	2
Operazioni di runtime
Metriche di Prometheus	3	2	2	2	3	2	0
Operazioni di base del DB	3	2	2	2	2	2	2
Upserts	2	2	2	2	1	2	2
Operatore Kubernetes	2	2	2	2	2	2	0
Paginazione dei risultati	2	2	2	2	2	2	0
Incorporazione della ricerca per ID	2	2	2	2	2	2	2
Restituzione delle incorporazioni con l'ID del candidato e i punteggi del candidato	1	3	2	2	2	2	2
ID fornito dall'utente	2	2	2	2	2	2	2
Capacità di effettuare ricerche in un contesto batch su larga scala	1	2	1	1	2	1	2
Backup / Istantanee: supporta la possibilità di creare backup dell'intero database.	1	2	2	2	3	3	2
Supporto efficiente di indici di grandi dimensioni (distinzione tra archiviazione fredda e calda)	1	3	2	2	2	1	2
Supporto/Comunità
Neutralità del fornitore	3	3	2	3	2	3	0
Robusto supporto per le API	3	3	3	2	2	2	2
Supporto del fornitore	2	2	2	2	2	2	0
Velocità della comunità	2	3	2	2	2	2	0
Base utenti di produzione	2	3	3	2	2	1	2
Sensazione di comunità	1	3	2	2	2	2	1
Stelle Github	1	2	2	2	2	2	0
Configurazione
Gestione dei segreti	2	2	2	2	1	2	2
Fonte
Fonte aperta	3	3	3	3	2	3	0
Lingua	2	3	3	2	3	2	0
Comunicati	2	3	3	2	2	2	2
Test a monte	1	2	3	3	2	2	2
Disponibilità di documentazione	3	3	3	2	1	2	1
Costo
Costo Efficace	2	2	2	2	2	2	1
Prestazioni
Supporto per la regolazione dell'utilizzo delle risorse per CPU, memoria e disco	3	2	2	2	2	2	2
Sharding multi-nodo (pod)	3	2	2	3	2	2	2
Avere la capacità di sintonizzare il sistema per bilanciare la latenza e il throughput	2	2	2	3	2	2	2
Partizione definita dall'utente (scritture)	1	3	2	3	1	2	0
Multi-tenant	1	3	2	1	3	2	2
Suddivisione	2	2	2	3	2	2	2
Replica	2	2	2	3	2	2	2
Ridondanza	1	2	2	3	2	2	2
Failover automatico	3	2	0 Nota: Milvus 2.6 lo supporta.	3	2	2	2
Bilanciamento del carico	2	2	2	3	2	2	2
Supporto GPU	1	0	2	0	0	0	0
		Qdrant	Milvus	Cassandra	Weviate	Solr	Vertex AI
Punteggi complessivi della soluzione		292	281	264	250	242	173

Abbiamo discusso i punteggi complessivi e dei requisiti dei vari sistemi e abbiamo cercato di capire se avevamo ponderato in modo appropriato l'importanza dei requisiti e se alcuni requisiti erano così importanti da dover essere considerati vincoli fondamentali. Uno di questi requisiti che abbiamo identificato è se la soluzione fosse open-source o meno, perché volevamo una soluzione in cui potessimo essere coinvolti, contribuire e risolvere rapidamente i piccoli problemi che si presentavano alla nostra scala. Contribuire e utilizzare software open-source è una parte importante della cultura ingegneristica di Reddit. Questo ha eliminato le soluzioni solo in hosting (Vertex AI, Pinecone) dalla nostra considerazione.

Durante le discussioni, ci siamo resi conto che alcuni altri requisiti chiave erano di importanza fondamentale per noi:

• Scala e affidabilità: volevamo vedere prove di altre aziende che utilizzavano la soluzione con oltre 100 milioni di vettori o addirittura 1B.

• Comunità: Volevamo una soluzione con una comunità sana e molto dinamica in questo settore in rapida maturazione.

• Tipi di metadati e filtri espressivi per consentire un maggior numero di casi d'uso (filtraggio per data, booleano, ecc.)

• Supporto di più tipi di indici (non solo HNSW o DiskANN) per migliorare le prestazioni dei nostri numerosi casi d'uso.

Il risultato delle nostre discussioni e l'affinamento dei requisiti chiave ci ha portato a scegliere di testare (in ordine) quantitativamente:

1. Qdrant

2. Milvus

3. Vespa e

4. Weviate

Purtroppo, decisioni come questa richiedono tempo e risorse, e nessuna organizzazione dispone di quantità illimitate di entrambi. Dato il nostro budget, abbiamo deciso di testare Qdrant e Milvus e di lasciare i test di Vespa e Weviate come stretch goal.

Qdrant vs Milvus è stato anche un interessante test di due architetture diverse:

• Qdrant: Tipi di nodi omogenei che eseguono tutte le operazioni del database vettoriale di RNA.

• Milvus: tipi di nodi eterogenei (Milvus; uno per le query, un altro per l'indicizzazione, un altro ancora per l'inserimento dei dati, un proxy, ecc.)

Quale dei due è stato facile da configurare (un test della documentazione)? Quale dei due è stato facile da eseguire (un test delle caratteristiche di resilienza e della pulizia)? E quale funzionava meglio per i casi d'uso e la scala che ci interessavano? A queste domande abbiamo cercato di rispondere confrontando quantitativamente le soluzioni.

3. Valutazione quantitativa dei principali contendenti

Volevamo capire meglio il grado di scalabilità di ciascuna soluzione e, nel processo, sperimentare come sarebbe stato impostare, configurare, mantenere ed eseguire ciascuna soluzione su scala. A tal fine, abbiamo raccolto tre set di dati di documenti e vettori di query per tre diversi casi d'uso, abbiamo configurato ciascuna soluzione con risorse simili all'interno di Kubernetes, abbiamo caricato i documenti in ciascuna soluzione e abbiamo inviato carichi di query identici utilizzando K6 di Grafana con un esecutore a rampa di velocità di arrivo per riscaldare i sistemi prima di raggiungere un throughput target (ad esempio, 100 QPS).

Abbiamo testato il throughput, il punto di rottura di ogni soluzione, la relazione tra throughput e latenza e la reazione alla perdita di nodi sotto carico (tasso di errore, impatto sulla latenza, ecc.). Di fondamentale interesse è stato l'effetto del filtraggio sulla latenza. Abbiamo anche effettuato semplici test sì/no per verificare che una funzionalità presente nella documentazione funzionasse come descritto (ad esempio, upserts, delete, get by ID, amministrazione utente, ecc.) e per sperimentare l'ergonomia di tali API.

I test sono stati effettuati su Milvus v2.4 e Qdrant v1.12. A causa dei vincoli di tempo, non abbiamo messo a punto o testato in modo esaustivo tutti i tipi di impostazioni dell'indice; sono state utilizzate impostazioni simili per ogni soluzione, con una preferenza per un elevato richiamo di RNA, e i test si sono concentrati sulle prestazioni degli indici HNSW. Anche le risorse di CPU e memoria sono state assegnate a ciascuna soluzione.

Nella nostra sperimentazione, abbiamo riscontrato alcune differenze interessanti tra le due soluzioni. Nei seguenti esperimenti, ogni soluzione aveva circa 340M vettori post Reddit di 384 dimensioni ciascuno, per HNSW, M=16 e efConstruction=100.

In un esperimento, abbiamo riscontrato che, a parità di throughput della query (100 QPS senza ingestione allo stesso tempo), l'aggiunta del filtraggio influiva maggiormente sulla latenza di Milvus rispetto a Qdrant.

Latenza delle query con il filtraggio

In un altro caso, abbiamo riscontrato un'interazione molto maggiore tra ingestione e carico delle query su Qdrant rispetto a Milvus (mostrato sotto a throughput costante). Ciò è probabilmente dovuto alla loro architettura; Milvus divide gran parte della sua ingestione su tipi di nodi separati da quelli che servono il traffico di query, mentre Qdrant serve sia il traffico di ingestione che quello di query dagli stessi nodi.

Latenza delle interrogazioni a 100 QPS durante l'ingest

Quando abbiamo testato la diversità dei risultati per attributo (ad esempio, ottenendo non più di N risultati da ogni subreddit in una risposta), abbiamo scoperto che a parità di throughput, Milvus aveva una latenza peggiore di Qdrant (a 100 QPS).

Latenza post query con diversità dei risultati

Abbiamo anche voluto verificare l'efficacia di ciascuna soluzione quando sono state aggiunte più repliche di dati (cioè il fattore di replica, RF, è stato aumentato da 1 a 2). Inizialmente, considerando RF=1, Qdrant è stato in grado di fornire una latenza soddisfacente a fronte di un throughput maggiore rispetto a Milvus (i QPS più elevati non sono mostrati perché i test non si sono conclusi senza errori).

Qdrant ha una latenza RF=1 per un throughput variabile

Milvus ha una latenza RF=1 per un throughput variabile.

Tuttavia, aumentando il fattore di replica, la latenza p99 di Qdrant è migliorata, ma Milvus è stato in grado di sostenere un throughput superiore a quello di Qdrant, con una latenza accettabile (Qdrant 400 QPS non mostrato perché il test non è stato completato a causa dell'elevata latenza e degli errori).

Milvus registra una latenza RF=2 per un throughput variabile

Qdrant presenta una latenza RF=2 per un throughput variabile

A causa dei vincoli di tempo, non abbiamo avuto tempo sufficiente per confrontare il richiamo della RNA tra le soluzioni sui nostri set di dati, ma abbiamo preso in considerazione le misurazioni del richiamo della RNA per le soluzioni fornite da https://ann-benchmarks.com/ su set di dati pubblicamente disponibili.

4. Selezione finale

Dal punto di vista delle prestazioni, senza una grande messa a punto e utilizzando solo HNSW, Qdrant sembra avere una latenza grezza migliore in molti test rispetto a Milvus. Milvus, tuttavia, sembrava in grado di scalare meglio con l'aumento delle repliche e aveva un migliore isolamento tra ingestione e carico delle query grazie alla sua architettura a più nodi.

Dal punto di vista operativo, nonostante la complessità dell'architettura di Milvus (più tipi di nodi, affidamento a un log esterno write-ahead come Kafka e a un archivio di metadati come etcd), è stato più facile eseguire il debug e la correzione di Milvus rispetto a Qdrant quando una delle due soluzioni si è trovata in uno stato negativo. Milvus ha anche un ribilanciamento automatico quando si aumenta il fattore di replica di una collezione, mentre in Qdrant open-source è necessario creare o eliminare manualmente gli shard per aumentare il fattore di replica (una funzione che avremmo dovuto costruire noi stessi o utilizzare la versione non open-source).

Milvus è una tecnologia più "a forma di Reddit" rispetto a Qdrant; condivide maggiori somiglianze con il resto del nostro stack tecnologico. Milvus è scritto in Golang, il nostro linguaggio di programmazione backend preferito, e quindi è più facile per noi contribuire rispetto a Qdrant, che è scritto in Rust. Milvus ha un'eccellente velocità di progetto per la sua offerta open-source rispetto a Qdrant, e soddisfa un maggior numero di requisiti chiave.

Alla fine, entrambe le soluzioni hanno soddisfatto la maggior parte dei nostri requisiti e in alcuni casi Qdrant ha avuto un vantaggio in termini di prestazioni, ma abbiamo ritenuto di poter scalare ulteriormente Milvus, di sentirci più a nostro agio nell'utilizzarlo e che fosse più adatto alla nostra organizzazione rispetto a Qdrant. Avremmo voluto avere più tempo per testare Vespa e Weaviate, ma anche loro potrebbero essere stati selezionati per motivi organizzativi (Vespa è basata su Java) e di architettura (Weaviate è di tipo single-node come Qdrant).

Aspetti salienti

• Mettete in discussione i requisiti che vi vengono forniti e cercate di eliminare i pregiudizi sulle soluzioni esistenti.

• Assegnare un punteggio alle soluzioni candidate e usarlo per informare la discussione sui requisiti essenziali, non come un punto di arrivo assoluto.

• Valutate quantitativamente le soluzioni, ma lungo il percorso prendete nota di ciò che significa lavorare con la soluzione.

• Scegliete la soluzione che si adatta meglio alla vostra organizzazione dal punto di vista della manutenzione, dei costi, dell'usabilità e delle prestazioni, non solo perché la soluzione è la più performante.

Ringraziamenti

Questo lavoro di valutazione è stato svolto da Ben Kochie, Charles Njoroge, Amit Kumar e da me. Grazie anche ad altri che hanno contribuito a questo lavoro, tra cui Annie Yang, Konrad Reiche, Sabrina Kong e Andrew Johnson, per la ricerca qualitativa delle soluzioni.

Note dell'editore

Vogliamo ringraziare sinceramente il team di ingegneri di Reddit, non solo per aver scelto Milvus per i loro carichi di lavoro di ricerca vettoriale, ma anche per aver trovato il tempo di pubblicare una valutazione così dettagliata e corretta. È raro vedere questo livello di trasparenza nel modo in cui i team di ingegneri reali confrontano i database, e il loro articolo sarà utile a chiunque nella comunità Milvus (e non solo) stia cercando di dare un senso al crescente panorama dei database vettoriali.

Come ha detto Chris nel post, non esiste un unico database vettoriale "migliore". Ciò che conta è se un sistema si adatta al vostro carico di lavoro, ai vostri vincoli e alla vostra filosofia operativa. Il confronto di Reddit riflette bene questa realtà. Milvus non è al top in tutte le categorie, e questo è del tutto prevedibile visti i compromessi tra i diversi modelli di dati e gli obiettivi di prestazione.

Una cosa che vale la pena di chiarire: La valutazione di Reddit ha utilizzato Milvus 2.4, che all'epoca era la versione stabile. Alcune funzionalità, come LSH e diverse ottimizzazioni degli indici, non esistevano ancora o non erano mature nella versione 2.4, quindi alcuni punteggi riflettono naturalmente quella vecchia base. Da allora, abbiamo rilasciato Milvus 2.5 e poi Milvus 2.6, ed è un sistema molto diverso in termini di prestazioni, efficienza e flessibilità. La risposta della comunità è stata forte e molti team hanno già effettuato l'aggiornamento.

Ecco una rapida panoramica delle novità di Milvus 2.6:

• Utilizzo della memoria ridotto fino al 72% e query 4 volte più veloci con la quantizzazione a 1 bit RaBitQ

• Riduzione del 50% dei costi con l'archiviazione intelligente a livelli

• Ricerca full-text BM25 4 volte più veloce rispetto a Elasticsearch

• Filtraggio JSON 100 volte più veloce con il nuovo Path Index

• Una nuova architettura a zero dischi per una ricerca più fresca a costi inferiori

• Un flusso di lavoro più semplice "data-in, data-out" per incorporare le pipeline

• Supporto per oltre 100K collezioni per gestire ambienti multi-tenant di grandi dimensioni

Se desiderate un resoconto completo, ecco alcuni buoni follow-up:

• Blog: Presentazione di Milvus 2.6: Ricerca vettoriale accessibile su scala miliardaria

• Note di rilascio di Milvus 2.6:

• VDBBench 1.0: Benchmarking del mondo reale per i database vettoriali - Blog Milvus

Avete domande o volete un approfondimento su una qualsiasi funzionalità? Unitevi al nostro canale Discord o inviate problemi su GitHub. È anche possibile prenotare una sessione individuale di 20 minuti per ottenere approfondimenti, indicazioni e risposte alle vostre domande tramite Milvus Office Hours.