Abbiamo ancora bisogno dei database vettoriali per la RAG con il rilascio da parte di OpenAI del suo retrieval integrato?
OpenAI ha fatto ancora una volta notizia con una serie di rilasci durante il suo DevDay, presentando il modello GPT-4 Turbo, la nuova Assistants API e una gamma di miglioramenti. L'Assistants API emerge come un potente strumento che aiuta gli sviluppatori a creare applicazioni IA su misura per esigenze specifiche. Consente inoltre loro di attingere a conoscenze aggiuntive, a una lunghezza del prompt maggiore e a strumenti per varie attività.
Sebbene gli OpenAI Assistants includano una funzionalità di retrieval integrata, non è perfetta — si pensi alle restrizioni sulla scala dei dati e alla mancanza di capacità di personalizzazione. È proprio qui che entra in gioco un retriever personalizzato. Sfruttando le capacità di function calling di OpenAI, gli sviluppatori possono integrare senza soluzione di continuità un retriever personalizzato, aumentando la scala delle conoscenze aggiuntive e adattandosi meglio a diversi casi d'uso. In questo post del blog, approfondiremo i vincoli del retrieval integrato di OpenAI e ti guideremo nella creazione di un retriever personalizzato utilizzando il database vettoriale Milvus.
Limitazioni del retrieval di OpenAI negli Assistants e il ruolo delle soluzioni di retrieval personalizzate
La funzionalità Retrieval integrata di OpenAI rappresenta un salto oltre la conoscenza intrinseca del modello, consentendo agli utenti di arricchirla con dati extra come informazioni proprietarie sui prodotti o documenti forniti dagli utenti. Tuttavia, si confronta con limitazioni notevoli.
Vincolo di scalabilità
OpenAI Retrieval impone vincoli sui file e sullo storage totale che potrebbero risultare insufficienti per repository documentali estesi:
Un massimo di 20 file per assistant
Un limite di 512MB per file
Una limitazione nascosta di 2 milioni di token per file, emersa durante i nostri test
Un limite di dimensione totale inferiore a 100GB per organizzazione
Per le organizzazioni con repository di dati estesi, queste limitazioni pongono delle sfide. Una soluzione scalabile che cresca senza soluzione di continuità senza raggiungere limiti di storage diventa indispensabile. Integrare un retriever personalizzato basato su un database vettoriale come Milvus o Zilliz Cloud (il Milvus gestito) offre una soluzione alternativa alle limitazioni sui file intrinseche del Retrieval integrato di OpenAI.
Mancanza di personalizzazione
Sebbene il Retrieval di OpenAI offra una comoda soluzione pronta all'uso, non può allinearsi costantemente alle esigenze specifiche di ogni applicazione, soprattutto per quanto riguarda latenza e personalizzazione dell'algoritmo di ricerca. Utilizzare un database vettoriale di terze parti offre agli sviluppatori la flessibilità per ottimizzare e configurare il processo di retrieval, soddisfacendo le esigenze di produzione e migliorando l'efficienza complessiva.
Mancanza di multi-tenancy
Il retrieval è una funzionalità integrata negli OpenAI Assistants che supporta solo l'uso da parte di singoli utenti. Tuttavia, se sei uno sviluppatore che mira a servire milioni di utenti con documenti condivisi e informazioni private degli utenti, la funzionalità di retrieval integrata non può aiutare. Replicare i documenti condivisi nell'Assistant di ciascun utente fa aumentare i costi di storage, mentre far condividere a tutti gli utenti lo stesso Assistant pone sfide nel supportare documenti privati specifici per utente.
Il grafico seguente mostra che archiviare documenti negli OpenAI Assistants è costoso ($6 per GB al mese; come riferimento, AWS S3 addebita $0.023), rendendo incredibilmente dispendioso archiviare documenti duplicati su OpenAI.
Prezzi dell'Assistants API da https://openai.com/pricing
Per le organizzazioni che custodiscono dataset estesi, è indispensabile un retriever scalabile, efficiente e conveniente che si allinei a specifiche esigenze operative. Fortunatamente, con la flessibile capacità di function calling di OpenAI, gli sviluppatori possono integrare senza soluzione di continuità un retriever personalizzato con gli OpenAI Assistants. Questa soluzione garantisce che le aziende possano sfruttare le migliori capacità di IA offerte da OpenAI mantenendo al contempo scalabilità e flessibilità per le loro esigenze uniche.
Sfruttare Milvus per il retrieval OpenAI personalizzato
Milvus è un database vettoriale open-source in grado di archiviare e recuperare miliardi di vettori in millisecondi. È anche altamente scalabile per soddisfare le esigenze aziendali degli utenti in rapida crescita. Con una scalabilità rapida e una latenza ultra-bassa, il database vettoriale Milvus è tra le scelte migliori per creare un retriever altamente scalabile e più efficiente per il tuo assistant OpenAI.
Come funziona un retriever OpenAI personalizzato
Creare un retriever personalizzato con OpenAI function calling e il database vettoriale Milvus
Iniziamo a creare il retriever personalizzato e a integrarlo con OpenAI seguendo la guida passo passo.
- Configura l’ambiente.
pip install openai==1.2.0
pip install langchain==0.0.333
pip install pymilvus
export OPENAI_API_KEY=xxxx # Enter your OpenAI API key here
- Crea un retriever personalizzato con un database vettoriale. Questa guida utilizza Milvus come database vettoriale e LangChain come wrapper.
from langchain.vectorstores import Milvus
from langchain.embeddings import OpenAIEmbeddings
# Prepare retriever
vector_db = Milvus(
embedding_function=OpenAIEmbeddings(),
connection_args = {'host': 'localhost', 'port': '19530'}
)
retriever = vector_db.as_retriever(search_kwargs={'k': 5}) # change top_k here
- Inserisci documenti aggiuntivi in Milvus. I documenti verranno analizzati, suddivisi in chunk e poi trasformati in embedding prima di essere inseriti nel database vettoriale. Gli sviluppatori possono personalizzare ogni passaggio per migliorare la qualità del retrieval.
from langchain.document_loaders import TextLoader
from langchain.text_splitter import RecursiveCharacterTextSplitter
# Parsing and chunking the document.
filepath = 'path/to/your/file'
doc_data = TextLoader(filepath).load_and_split(
RecursiveCharacterTextSplitter(chunk_size=1000, chunk_overlap=200)
)
# Embedding and insert chunks into the vector database.
vector_db.add_texts([doc.page_content for doc in doc_data])
Ora hai creato con successo un retriever personalizzato in grado di eseguire una ricerca semantica basata sui tuoi dati privati o proprietari. Successivamente, devi integrare questo retriever con OpenAI Assistants per abilitare la generazione di contenuti.
- Crea un Assistant con la funzionalità Function Calling di OpenAI. L’Assistant è istruito a utilizzare uno strumento di funzione chiamato
CustomRetrieverquando risponde alle query.
import os
from openai import OpenAI
# Setup OpenAI client.
client = OpenAI(api_key=os.getenv('OPENAI_API_KEY'))
# Create an Assistant.
my_assistant = client.beta.assistants.create(
name='Chat with a custom retriever',
instructions='You will search for relevant information via retriever and answer questions based on retrieved information.',
tools=[
{
'type': 'function',
'function': {
'name': 'CustomRetriever',
'description': 'Retrieve relevant information from provided documents.',
'parameters': {
'type': 'object',
'properties': {'query': {'type': 'string', 'description': 'The user query'}},
'required': ['query']
},
}
}
],
model='gpt-4-1106-preview', # Switch OpenAI model here
)
- L’Assistant esegue attività di risposta alle query in modo asincrono.
Runè un’invocazione di un Assistant durante un Thread. Durante l’operazione di run, l’Assistant decide se una funzione deve chiamareCustomRetrievere attende il risultato della chiamata di funzione.
QUERY = 'ENTER YOUR QUESTION HERE'
# Create a thread.
my_thread = client.beta.threads.create(
messages=[
{
'role': 'user',
'content': QUERY,
}
]
)
# Invoke a run of my_assistant on my_thread.
my_run = client.beta.threads.runs.create(
thread_id=my_thread.id,
assistant_id=my_assistant.id
)
# Wait until my_thread halts.
while True:
my_run = client.beta.threads.runs.retrieve(thread_id=thread.id, run_id=my_run.id)
if my_run.status != 'queued':
break
- Ora, l’Assistant è in attesa del risultato della chiamata di funzione. Esegui una ricerca vettoriale per la query e invia il risultato.
# Conduct vector search and parse results when OpenAI Run ready for the next action
if my_run.status == 'requires_action':
tool_outputs = []
for tool_call in my_run.required_action.submit_tool_outputs.tool_calls:
if tool_call.function.name == 'Custom Retriever':
search_res = retriever.get_relevant_documents(QUERY)
tool_outputs.append({
'tool_call_id': tool_call.id,
'output': ('\n\n').join([res.page_content for res in search_res])
})
# Send retrieval results to your Run service
client.beta.threads.runs.submit_tool_outputs(
thread_id=my_thread.id,
run_id=my_run.id,
tool_outputs=tool_outputs
)
- Estrai e analizza l’intera conversazione con OpenAI.
messages = client.beta.threads.messages.list(
thread_id=my_thread.id
)
for m in messages:
print(f'{m.role}: {m.content[0].text.value}\n')
Ecco fatto! Hai chattato con successo con il tuo OpenAI Assistant sui contenuti forniti sfruttando un retriever personalizzato basato su Milvus.
Conclusione
Sebbene lo strumento di retrieval integrato di OpenAI Assistants sia notevole, si scontra con limitazioni come vincoli di archiviazione, problemi di scalabilità e una mancanza di personalizzazione per le diverse esigenze degli utenti. Si rivolge solo a utenti individuali, creando sfide per applicazioni con milioni di utenti e documenti sia condivisi sia privati.
Creare un retriever personalizzato usando un database vettoriale robusto come Milvus o Zilliz Cloud (la versione completamente gestita di Milvus) si rivela utile per superare le sfide sopra descritte. Questo approccio offre maggiore flessibilità e controllo sulla gestione dei file tramite l’integrazione con OpenAI Assistant API.
Nei nostri prossimi post, confronteremo prestazioni, costi e funzionalità di OpenAI Retrieval e di un retriever personalizzato. Sveleremo inoltre i risultati dei benchmark e forniremo preziosi approfondimenti per gli sviluppatori alla ricerca di soluzioni ottimali per migliorare la qualità del retrieval. Resta sintonizzato!
Continua a leggere
DeepSeek-OCR Explained: Optical Compression for Scalable Long-Context and RAG Systems
Discover how DeepSeek-OCR uses visual tokens and Contexts Optical Compression to boost long-context LLM efficiency and reshape RAG performance.
How to Build an Enterprise-Ready RAG Pipeline on AWS with Bedrock, Zilliz Cloud, and LangChain
Build production-ready enterprise RAG with AWS Bedrock, Nova models, Zilliz Cloud, and LangChain. Complete tutorial with deployable code.
How to Build RAG with Milvus, QwQ-32B and Ollama
Hands-on tutorial on how to create a streamlined, powerful RAG pipeline that balances efficiency, accuracy, and scalability using the QwQ-32B and Milvus.