Creare RAG con il database vettoriale Milvus distribuito autonomamente e Snowpark Container Services
Jiang Chen, Head of Ecosystem & AI Platform presso Zilliz, ha recentemente discusso di come possiamo integrare perfettamente Milvus con Snowflake in un intervento al Unstructured Data Meetup. In particolare, ha esplorato come costruire un sistema di Retrieval Augmented Generation (RAG) con il database vettoriale Milvus e la sua integrazione con l’ecosistema Snowflake utilizzando lo Snowpark Container Service (SPCS).
< Guarda l’intervento di Jiang Chen su Youtube >
Questo post riepilogherà i punti chiave di Jiang e tratterà tre argomenti importanti.
Per prima cosa, discuteremo dell’utilizzo di Milvus per la ricerca vettoriale, un passaggio essenziale per costruire un sistema RAG. Poi discuteremo di come integrare Milvus in Snowflake con SPCS. Infine, discuteremo anche del panorama futuro del RAG. Prima di approfondire gli argomenti, esploriamo come l’AI abbia trasformato il recupero delle informazioni.
Come l’AI rivoluziona il processo di recupero delle informazioni
Il progresso e la popolarità dell’AI hanno cambiato rapidamente l’intero panorama del recupero delle informazioni. Prima dell’ascesa dell’AI, il recupero delle informazioni si basava in larga misura su modelli statistici e metodi di corrispondenza delle parole chiave come il tagging. Ad esempio, il proprietario di un negozio online avrebbe dovuto inserire manualmente tag per ciascun prodotto in categorie predefinite. Se avesse un catalogo enorme di prodotti, questo processo non sarebbe pratico.
Allo stesso modo, come clienti, dovremmo inserire i tag appropriati per ottenere esattamente il prodotto che desideriamo. Il problema è che, se inseriamo un tag non esatto ma con un significato simile al prodotto che vogliamo, il recupero delle informazioni tramite il metodo del tagging non riuscirà a fornirci i prodotti appropriati. In altre parole, il metodo del tagging non considera il significato semantico di una query.
L’AI rivoluziona il modo in cui utilizziamo i dati non strutturati
L’AI rivoluziona il modo in cui utilizziamo i dati non strutturati
La nascita dei modelli di embedding ha trasformato completamente il modo in cui recuperiamo le informazioni. La maggior parte dei modelli di embedding utilizza la famosa architettura Transformer come backbone. Il modello Transformer sfrutta diversi blocchi encoder-decoder, ciascuno contenente uno strato di attenzione specializzato. Questo strato consente al modello di percepire il significato semantico di ciascun token di input rispetto all’intera sequenza di input, rendendo i modelli di embedding in grado di inferire il significato semantico delle parole in input.
Architettura Transformer
Architettura Transformer
I modelli di embedding trasformeranno query, immagini o descrizioni testuali nelle loro rappresentazioni numeriche chiamate embedding vettoriali. Un embedding vettoriale porta con sé un significato semanticamente ricco dell’input che rappresenta, e possiamo confrontare la similarità tra due embedding vettoriali tramite la similarità del coseno o la distanza coseno. Se la similarità è alta, allora due embedding vettoriali hanno un significato simile, e viceversa.
Testi grezzi in embedding vettoriali.png
Testi grezzi in embedding vettoriali
Grazie a queste potenti caratteristiche, i modelli di embedding rendono l'implementazione del concetto di recupero delle informazioni molto più semplice e flessibile.
Generazione aumentata dal recupero (RAG)
Il rapido avanzamento dei modelli di embedding e l'ascesa dei modelli linguistici di grandi dimensioni (LLM) hanno portato alla nascita di RAG, un metodo di recupero delle informazioni molto sofisticato. RAG è progettato per migliorare la qualità delle risposte di un LLM fornendo all'LLM un contesto pertinente proveniente da una knowledge base interna insieme alla query. L'LLM utilizzerà quindi il contesto fornito per rispondere alla query.
Architettura RAG
Architettura RAG
In un'applicazione RAG, utilizziamo i modelli di embedding scelti per trasformare i nostri dati e la query di input in embedding. Quindi, calcoliamo la somiglianza tra l'embedding della nostra query e gli embedding dei nostri dati. I dati più simili alla nostra query verranno quindi passati a un LLM come contesto insieme alla nostra query. In definitiva, il nostro LLM può generare una risposta alla query in base al contesto fornito. In questo modo, possiamo migliorare l'accuratezza delle risposte di un LLM senza la necessità di eseguirne il fine-tuning.
Integrazione di Milvus Vector Database e Snowflake con Snowpark Container Service
Milvus è un database vettoriale open-source che consente di archiviare un'enorme quantità di embedding vettoriali utili per applicazioni RAG ed eseguire ricerche vettoriali su di essi in una frazione di secondo. Esistono diverse opzioni per installare e utilizzare Milvus:
- Milvus Lite: Una versione leggera di Milvus adatta alla prototipazione rapida. Milvus Lite non richiede un server; puoi eseguirlo sul tuo dispositivo. Il processo di installazione è semplice quanto usare un comando pip install.
!pip install "pymilvus>=2.4.2"
from pymilvus import MilvusClient
client = MilvusClient("milvus_demo.db")
- Milvus in Docker: Se vuoi utilizzare il tuo database vettoriale Milvus in produzione e hai solo una piccola quantità di dati, puoi eseguirlo come container Docker. Il processo è anche semplice, poiché devi solo eseguire questi comandi nella tua riga di comando:
# Download the installation script
$ curl -sfL <https://raw.githubusercontent.com/milvus-io/milvus/master/scripts/standalone_embed.sh> -o standalone_embed.sh
# Start the Docker container
$ bash standalone_embed.sh start
# In your Python IDE
from pymilvus import MilvusClient
client = MilvusClient(
uri="<http://milvus:19530>",
)
- Milvus in Kubernetes: Questa opzione è adatta se disponi di enormi quantità di dati o se le tue applicazioni RAG hanno un numero enorme di utenti. Puoi archiviare fino a 100 miliardi di vettori con Kubernetes. Il processo di installazione con Kubernetes è un po' più complicato rispetto a quello di Milvus Lite e Docker. Pertanto, consulta la documentazione di installazione per informazioni dettagliate.
Milvus offre un'integrazione perfetta con i toolkit AI più popolari come OpenAI, HuggingFace, Cohere, LangChain, LlamaIndex e Snowflake. Queste integrazioni rendono semplice creare i tuoi sistemi RAG o altre applicazioni GenAI. Questa sezione ti mostrerà come eseguire Milvus all'interno dell'ecosistema Snowflake.
Milvus offre un'integrazione perfetta con tutti i toolkit AI più popolari
Milvus offre un'integrazione perfetta con tutti i toolkit AI più popolari
Snowflake è una piattaforma di data warehousing che ti consente di archiviare, elaborare e analizzare i dati in modo efficiente e affidabile. Con l'introduzione di Snowpark Container Service (SPCS), ora puoi eseguire applicazioni containerizzate all'interno dell'ambiente Snowflake. In questo modo, la tua app può interagire con i dati archiviati all'interno di Snowflake, consentendoti di creare un'ampia gamma di applicazioni, incluso un sistema RAG.
In questa sezione, creeremo prima un'app con Milvus che esegue una ricerca vettoriale. Successivamente, containerizzeremo l'applicazione usando Docker ed eseguiremo il container all'interno di Snowflake con SPCS.
Per iniziare, creiamo un'app Milvus per eseguire una ricerca vettoriale con Jupyter Notebook. Se vuoi seguire passo passo, consulta questo repository per il notebook completo e lo script per creare il modello di embedding.
from pymilvus import MilvusClient
from pymilvus import DataType
import os
import mode
# init client
client = MilvusClient(
uri="<http://milvus:19530>",
)
# init model
model = model.Onnx()
# Create a collection in quick setup mode
client.create_collection(
collection_name="quick_demo",
dimension=model.dimension,
)
print("Collection Created!")
Nel codice sopra, abbiamo creato una collection chiamata “quick_demo” all'interno di un database vettoriale Milvus e caricato il modello per trasformare i testi in embedding. Useremo ALBERT come nostro modello di embedding, che mappa un testo di input in un embedding vettoriale a 768 dimensioni.
Successivamente, inserisci alcuni dati testuali nella nostra collection “quick_demo”.
# Data from which embeddings are to be generated
docs=[
"Artificial intelligence was founded as an academic discipline in 1956.",
"Alan Turing was the first person to conduct substantial research in AI.",
"Born in Maida Vale, London, Turing was raised in southern England.",
]
# Insert data into the collection
data=[]
for i in range(len(docs)):
data.append({
'id': i,
'vector': model.to_embeddings(docs[i]),
'doc_str': docs[i]
})
res = client.insert(
collection_name="quick_demo",
data=data
)
Nel codice sopra, trasformiamo i nostri testi di input in embedding con ALBERT e li archiviamo all'interno della collection con i loro ID e testi grezzi.
Ora, se abbiamo una query come “Chi ha iniziato la ricerca sull'AI?” e vorremmo ottenere il contesto rilevante che potrebbe contenere la risposta pertinente alla nostra query, possiamo eseguire facilmente una ricerca vettoriale con Milvus come segue:
# Search with a text query
query = "Who started AI research?"
query_embeddings = model.to_embeddings(query)
res = client.search(
collection_name="quick_demo",
data=[query_embeddings],
limit=1,
output_fields=["doc_str"],
)
print(res)
"""
Expected output:
"Alan Turing was the first person to conduct substantial research in AI."
"""
E questo è tutto per la nostra app Milvus.
A questo punto, abbiamo un Jupyter Notebook per eseguire una ricerca vettoriale con Milvus. Supponiamo di voler containerizzare questo notebook per eseguirlo all'interno dell'ecosistema Snowflake. La prima cosa che dobbiamo fare è configurare il ruolo e i privilegi per creare ed eseguire il servizio fornito da Snowflake.
Per prima cosa, scarica SnowSQL seguendo le istruzioni nella pagina della documentazione sull’installazione di SnowSQL. Poi, esegui il seguente comando nel terminale:
snowsql -a ${instance_name} -u ${user_name}
dove il formato di ${instance_name} è ${org_name}-${acct_name}, e puoi trovare informazioni su questi due campi all’interno del tuo account Snowflake. Ora possiamo configurare il ruolo e i privilegi con i seguenti comandi all’interno della shell SnowSQL:
USE ROLE ACCOUNTADMIN;
CREATE SECURITY INTEGRATION SNOWSERVICES_INGRESS_OAUTH
TYPE=oauth
OAUTH_CLIENT=snowservices_ingress
ENABLED=true;
USE ROLE ACCOUNTADMIN;
GRANT BIND SERVICE ENDPOINT ON ACCOUNT TO ROLE SYSADMIN;
USE ROLE SECURITYADMIN;
CREATE ROLE MILVUS_ROLE;
USE ROLE USERADMIN;
CREATE USER milvus_user
PASSWORD='milvususerok'
DEFAULT_ROLE = MILVUS_ROLE
DEFAULT_SECONDARY_ROLES = ('ALL')
MUST_CHANGE_PASSWORD = FALSE;
USE ROLE SECURITYADMIN;
GRANT ROLE MILVUS_ROLE TO USER milvus_user;
Poiché Snowflake è una piattaforma di data warehousing, interagiamo con tutti gli oggetti all’interno di Snowflake tramite un comando simile a una query SQL, come puoi vedere sopra. Successivamente, possiamo creare il data warehouse e il database all’interno di Snowflake con i seguenti comandi:
USE ROLE SYSADMIN;
CREATE OR REPLACE WAREHOUSE MILVUS_WAREHOUSE WITH
WAREHOUSE_SIZE='X-SMALL'
AUTO_SUSPEND = 180
AUTO_RESUME = true
INITIALLY_SUSPENDED=false;
USE ROLE SYSADMIN;
CREATE DATABASE IF NOT EXISTS MILVUS_DEMO;
USE DATABASE MILVUS_DEMO;
CREATE IMAGE REPOSITORY MILVUS_DEMO.PUBLIC.MILVUS_REPO;
CREATE OR REPLACE STAGE YAML_STAGE;
CREATE OR REPLACE STAGE DATA ENCRYPTION = (TYPE = 'SNOWFLAKE_SSE');
CREATE OR REPLACE STAGE FILES ENCRYPTION = (TYPE = 'SNOWFLAKE_SSE');
--GRANT ROLE PRIVILEGES--
USE ROLE SECURITYADMIN;
GRANT ALL PRIVILEGES ON DATABASE MILVUS_DEMO TO MILVUS_ROLE;
GRANT ALL PRIVILEGES ON SCHEMA MILVUS_DEMO.PUBLIC TO MILVUS_ROLE;
GRANT ALL PRIVILEGES ON WAREHOUSE MILVUS_WAREHOUSE TO MILVUS_ROLE;
GRANT ALL PRIVILEGES ON STAGE MILVUS_DEMO.PUBLIC.FILES TO MILVUS_ROLE;
--CONFIGURE ACL--
USE ROLE ACCOUNTADMIN;
USE DATABASE MILVUS_DEMO;
USE SCHEMA PUBLIC;
CREATE NETWORK RULE allow_all_rule
TYPE = 'HOST_PORT'
MODE= 'EGRESS'
VALUE_LIST = ('0.0.0.0:443','0.0.0.0:80');
CREATE EXTERNAL ACCESS INTEGRATION allow_all_eai
ALLOWED_NETWORK_RULES=(allow_all_rule)
ENABLED=TRUE;
GRANT USAGE ON INTEGRATION allow_all_eai TO ROLE SYSADMIN;
Per eseguire un’app containerizzata all’interno di Snowflake, dobbiamo creare l’immagine Docker della nostra app sulla nostra macchina locale. In questo progetto, dobbiamo creare due diverse immagini Docker: una per istanziare il database vettoriale Milvus e una per eseguire il file notebook che abbiamo creato sopra.
Tuttavia, abbiamo bisogno di un Dockerfile per creare un’immagine Docker. Per semplificare le cose, clona il seguente repo. Troverai tutti i file necessari per crearere le due immagini di cui abbiamo bisogno in questo repo. Dopo aver clonato il repo, puoi creare le due immagini Docker con i seguenti comandi nel tuo terminale locale:
cd ${repo_git_root_path}
docker build --rm --no-cache --platform linux/amd64 -t milvus ./images/milvus
docker build --rm --no-cache --platform linux/amd64 -t jupyter ./images/jupyter
Quindi, possiamo aggiungere tag appropriati alle due immagini appena create con i seguenti comandi:
docker login ${instance_name}.registry.snowflakecomputing.com -u ${user_name}
docker tag milvus ${instance_name}.registry.snowflakecomputing.com/milvus_demo/public/milvus_repo/milvus
docker tag jupyter ${instance_name}.registry.snowflakecomputing.com/milvus_demo/public/milvus_repo/jupyter
Infine, possiamo inviare le immagini a SPCS con i seguenti comandi:
docker push ${instance_name}.registry.snowflakecomputing.com/milvus_demo/public/milvus_repo/milvus
docker push ${instance_name}.registry.snowflakecomputing.com/milvus_demo/public/milvus_repo/jupyter
Ora che abbiamo caricato le immagini su SPCS, l’unica cosa che dobbiamo fare è creare due servizi di computing, uno per ciascuna immagine, come puoi vedere nei seguenti comandi all’interno della shell SnowSQL:
USE ROLE SYSADMIN;
CREATE COMPUTE POOL IF NOT EXISTS MILVUS_COMPUTE_POOL
MIN_NODES = 1
MAX_NODES = 1
INSTANCE_FAMILY = CPU_X64_S
AUTO_RESUME = true;
CREATE COMPUTE POOL IF NOT EXISTS JUPYTER_COMPUTE_POOL
MIN_NODES = 1
MAX_NODES = 1
INSTANCE_FAMILY = CPU_X64_S
AUTO_RESUME = true;
All’interno del repo che abbiamo clonato in precedenza c’è una cartella chiamata “specs.” All’interno di quella cartella ci sono due file YAML, uno per ciascuna immagine. Apri ogni file YAML e modifica ${org_name}-${acct_name} nel campo image in base al tuo account Snowflake.
Successivamente, usando SnowSQL, carica i file YAML modificati con i seguenti comandi:
PUT file://${path/to/jupyter.yaml} @yaml_stage overwrite=true auto_compress=false;
PUT file://${path/to/milvus.yaml} @yaml_stage overwrite=true auto_compress=false;
E infine, possiamo creare i servizi per entrambe le immagini come segue:
USE ROLE SYSADMIN;
USE DATABASE MILVUS_DEMO;
USE SCHEMA PUBLIC;
CREATE SERVICE MILVUS
IN COMPUTE POOL MILVUS_COMPUTE_POOL
FROM @YAML_STAGE
SPEC='milvus.yaml'
MIN_INSTANCES=1
MAX_INSTANCES=1;
CREATE SERVICE JUPYTER
IN COMPUTE POOL JUPYTER_COMPUTE_POOL
FROM @YAML_STAGE
SPEC='jupyter.yaml'
MIN_INSTANCES=1
MAX_INSTANCES=1;
Ora, se digiti il comando SHOW SERVICE, dovresti vedere il seguente output:
SHOW SERVICES;
+---------+---------------+-------------+----------+----------------------+--------------------------------------------------------+-----------------
| name | database_name | schema_name | owner | compute_pool | dns_name | ......
|---------+---------------+-------------+----------+----------------------+--------------------------------------------------------+-----------------
| JUPYTER | MILVUS_DEMO | PUBLIC | SYSADMIN | JUPYTER_COMPUTE_POOL | jupyter.public.milvus-demo.snowflakecomputing.internal | ......
| MILVUS | MILVUS_DEMO | PUBLIC | SYSADMIN | MILVUS_COMPUTE_POOL | milvus.public.milvus-demo.snowflakecomputing.internal | ......
+---------+---------------+-------------+----------+----------------------+--------------------------------------------------------+-----------------
Ora siamo pronti a eseguire il database vettoriale Milvus e testare il nostro notebook all’interno di Snowflake. Per prima cosa, concedi al ruolo che abbiamo creato in precedenza l’autorizzazione per accedere all’app containerizzata.
USE ROLE SECURITYADMIN;
GRANT USAGE ON SERVICE MILVUS_DEMO.PUBLIC.JUPYTER TO ROLE MILVUS_ROLE;
Successivamente, controlla l’endpoint del nostro container del notebook all’interno di Snowflake con il seguente comando:
USE ROLE SYSADMIN;
SHOW ENDPOINTS IN SERVICE MILVUS_DEMO.PUBLIC.JUPYTER;
Endpoint Jupyter, come mostrato in ingress_url
Endpoint Jupyter, come mostrato in ingress_url
Se tutto funziona correttamente, puoi vedere una colonna chiamata “ingress_url” come output. Apri il browser, copia e incolla quell’“ingress_url” e dovresti vedere l’avvio di Jupyter. Puoi quindi aprire il file notebook all’interno del container ed eseguire normalmente ogni cella del notebook.
Il panorama futuro di RAG
RAG è una tecnica molto popolare al giorno d’oggi. Tuttavia, la sua applicazione attuale è tutt’altro che perfetta. Secondo Jiang Chen, ecco diverse previsioni riguardo all’uso futuro e al miglioramento delle applicazioni RAG.
Valutazione continua e osservabilità
Costruire RAG è diventato più semplice grazie alla disponibilità di varie piattaforme o librerie che semplificano e astraggono il processo di sviluppo RAG. Ad esempio, possiamo creare un prototipo RAG in pochi minuti con l’aiuto di tre diverse piattaforme: Milvus, LangChain e OpenAI.
Tuttavia, spesso affrontiamo sfide quando spostiamo un'applicazione basata su RAG dal prototipo alla produzione. In produzione, i nostri sistemi RAG devono gestire milioni o persino miliardi di documenti, rendendo fondamentale monitorare continuamente la qualità delle risposte generate dal nostro LLM
Valutazione continua del sistema RAG
Valutazione continua del sistema RAG
Prima di implementare miglioramenti per aumentare la qualità del nostro RAG, è importante stabilire un approccio sistematico per valutarlo e migliorarlo continuamente.
Alcuni elementi chiave di questo approccio sistematico includono:
Costruire un'infrastruttura dedicata al miglioramento: In questa infrastruttura, possiamo implementare vari metodi per migliorare la qualità del RAG e poi confrontare le loro risposte tramite A/B testing.
Pianificare un ciclo di rilascio: Una volta trovato un approccio che migliora la qualità del RAG in base al nostro caso d'uso, dobbiamo pianificare come rilasciarlo e integrarlo nel nostro sistema per sostituire quello vecchio senza interrompere l'esperienza utente.
Implementare un sistema di osservabilità: Dobbiamo anche costruire un sistema per osservare le prestazioni del nostro RAG in produzione e determinarne l'efficacia. Se le prestazioni sono insoddisfacenti, possiamo esplorare e implementare miglioramenti attraverso l'infrastruttura dedicata al miglioramento.
RAG multi-modale
Finora, abbiamo utilizzato principalmente RAG nel natural language processing. Ciò significa che usiamo il testo come prompt o query, e anche le risposte del nostro LLM sono sotto forma di testo.
Tuttavia, il panorama del RAG potrebbe cambiare in futuro con l'introduzione del RAG multi-modale. Il RAG multi-modale è possibile grazie alla crescita dei modelli di embedding multi-modali negli ultimi anni. Negli ultimi anni, la ricerca ha concluso che i Transformer possono elaborare come input il linguaggio naturale e altre modalità, come immagini e suoni.
I modelli Vision Transformers (ViT) e DETR hanno dimostrato che i Transformer possono essere utilizzati come potenti modelli di classificazione delle immagini e rilevamento degli oggetti. Basandosi su ViT, OpenAI ha introdotto un modello multi-modale chiamato CLIP, che può calcolare la similarità tra due input di modalità diverse: testo e immagine.
Le capacità multimodali mostrate da questi modelli basati su Transformer possono servire come fondamento per future applicazioni RAG multimodali. In questo sistema, possiamo usare una combinazione di testo e immagine come query, e l'LLM genererà un'immagine basata sulle nostre query multimodali.
Ad esempio, supponiamo di voler che il nostro LLM generi un'immagine che assomigli molto a un'immagine di query fornita. Possiamo arricchire la nostra immagine di query con una descrizione testuale per perfezionare ulteriormente il tipo di immagini che vogliamo che il nostro LLM generi, come puoi vedere nella visualizzazione qui sotto:
Applicazione RAG multi-modale, combinazione di query testuali e immagini
Applicazione RAG multi-modale, combinazione di query testuali e immagini
Nella visualizzazione sopra, abbiamo chiesto ai nostri modelli di embedding di restituire immagini che assomiglino all'immagine in alto a sinistra, e abbiamo aggiunto un prompt testuale, come "un'immagine di una montagna durante la golden hour," accanto all'immagine in alto a sinistra. I risultati sono le altre tre immagini generate sulla base della query multi-modale.
Questo approccio multi-modale al RAG apre nuove possibilità per un recupero e una generazione delle informazioni più intuitivi ed espressivi, combinando i punti di forza sia delle modalità testuali sia di quelle visive.
Un buon RAG nasce da buoni dati
La qualità del nostro sistema RAG dipende fortemente dalla qualità dei dati che abbiamo nel nostro database. Pertanto, quando la risposta generata dal nostro RAG non è ottimale, non dovremmo affrettarci a concludere che il modello debba essere migliorato. Per prima cosa, dobbiamo sempre controllare la qualità dei nostri dati.
Come forse già saprai, la qualità della risposta del RAG dipende dai contesti passati insieme alla query. Se il nostro LLM non riesce a trovare risposte appropriate alla query dai contesti forniti, allora non sorprende che la qualità della risposta generata dal nostro sistema RAG sia scarsa.
Pertanto, prima di scegliere di migliorare i modelli di embedding e l'LLM nel nostro sistema RAG, dovremmo sempre porci le seguenti domande:
Abbiamo i dati giusti nel nostro database?
Abbiamo raccolto nel nostro database tutti i dati disponibili dalle fonti di dati?
Abbiamo implementato il giusto processo di pulizia dei dati prima di passarli ai modelli di embedding?
Abbiamo implementato l'approccio di chunking appropriato per i nostri dati?
Abbiamo implementato i metodi corretti di pre-elaborazione dei dati (ad es., parsing PDF, parsing OCR) per i nostri dati?
Affrontare i problemi legati ai dati è un primo passo cruciale per ottimizzare le prestazioni di un'applicazione basata su RAG. Solo dopo aver verificato la qualità dei dati dovremmo considerare di perfezionare i modelli di embedding, l'LLM o altri componenti del sistema RAG.
Agenti: routing delle query con sottoquery
Attualmente, un sistema RAG comune recupera contesti rilevanti per una determinata query da testi ed embedding salvati all'interno di un database interno. Tuttavia, questo approccio potrebbe evolversi, poiché il contesto potrebbe essere recuperato da database interni e fonti esterne, come le ricerche web.
Visualizzazione degli agenti per il routing delle query
Visualizzazione degli agenti per il routing delle query
La ricerca in quest'area è ancora in corso, ma l'aggiunta di un cosiddetto "agente" all'interno di un sistema RAG potrebbe aiutare a determinare la fonte appropriata del contesto per una determinata query.
Ad esempio, data una query come "Chi ha avviato la ricerca sull'IA?" l'agente può decidere se il RAG sia necessario o meno per rispondere a quella domanda. In caso contrario, il sistema può lasciare che l'LLM generi direttamente una risposta alla query senza alcun contesto aggiuntivo.
Se il RAG è ritenuto necessario, l'agente dovrebbe determinare la fonte del contesto, che si tratti di un database interno o di una fonte esterna. Un altro approccio consiste nel far aggregare all'agente informazioni da varie fonti in un unico contesto riassunto che possa essere utilizzato dall'LLM per generare una risposta appropriata.
Conclusione
Le potenti prestazioni degli LLM nel generare risposte testuali simili a quelle umane hanno cambiato l'intero panorama del recupero delle informazioni. L'introduzione del RAG è progettata per migliorare l'accuratezza delle risposte degli LLM fornendo loro contesti rilevanti per una determinata query. Questi contesti sono in genere archiviati come embedding, che devono essere memorizzati in un database vettoriale come Milvus.
In quanto database vettoriale open-source con capacità avanzate di ricerca vettoriale, Milvus offre un'integrazione perfetta con i più diffusi toolkit di IA, come Snowflake. Con lo Snowpark Container Service (SPCS) di Snowflake, gli utenti possono ora eseguire Milvus all'interno dell'ecosistema Snowflake, consentendo loro di interagire facilmente con Milvus utilizzando i dati archiviati in Snowflake.
Continua a leggere
Zilliz Cloud Now Available in AWS Asia Pacific (Seoul)
Zilliz Cloud is now available in AWS Seoul — low-latency vector search, in-country data residency, and one-step migration for Korean AI teams. 31 regions across 5 clouds.
Vector Databases vs. Object-Relational Databases
Use a vector database for AI-powered similarity search; use an object-relational database for complex data modeling with both relational integrity and object-oriented features.
Similarity Metrics for Vector Search
Exploring five similarity metrics for vector search: L2 or Euclidean distance, cosine distance, inner product, and hamming distance.