Avons-nous encore besoin de bases de données vectorielles pour le RAG avec la sortie par OpenAI de sa récupération intégrée ?
OpenAI a une nouvelle fois fait les gros titres avec une série de lancements lors de son DevDay, dévoilant le modèle GPT-4 Turbo, la nouvelle Assistants API et toute une gamme d’améliorations. L’Assistants API s’impose comme un outil puissant aidant les développeurs à concevoir des applications d’IA sur mesure répondant à des besoins spécifiques. Elle leur permet également d’exploiter des connaissances supplémentaires, une longueur de prompt plus importante et des outils pour diverses tâches.
Bien que les OpenAI Assistants disposent d’une fonctionnalité de récupération intégrée, elle n’est pas parfaite — pensez aux restrictions sur l’échelle des données et au manque de capacité de personnalisation. C’est précisément là qu’un récupérateur personnalisé intervient pour aider. En exploitant les capacités d’appel de fonctions d’OpenAI, les développeurs peuvent intégrer de manière transparente un récupérateur personnalisé, augmentant l’échelle des connaissances supplémentaires et s’adaptant mieux à divers cas d’utilisation. Dans cet article de blog, nous examinerons les contraintes de la récupération intégrée d’OpenAI et vous guiderons dans la création d’un récupérateur personnalisé à l’aide de la base de données vectorielle Milvus.
Limites de la récupération d’OpenAI dans les Assistants et rôle des solutions de récupération personnalisées
La fonctionnalité de récupération intégrée d’OpenAI représente un bond en avant par rapport aux connaissances inhérentes du modèle, permettant aux utilisateurs de l’enrichir avec des données supplémentaires telles que des informations produit propriétaires ou des documents fournis par les utilisateurs. Cependant, elle se heurte à des limites notables.
Contrainte d’évolutivité
OpenAI Retrieval impose des contraintes de fichiers et de stockage total qui peuvent s’avérer insuffisantes pour de vastes référentiels de documents :
Un maximum de 20 fichiers par assistant
Un plafond de 512MB par fichier
Une limitation cachée de 2 millions de tokens par fichier, découverte lors de nos tests
Une limite de taille totale inférieure à 100GB par organisation
Pour les organisations disposant de vastes référentiels de données, ces limites posent des défis. Une solution évolutive qui se développe de manière transparente sans atteindre de plafonds de stockage devient impérative. L’intégration d’un récupérateur personnalisé alimenté par une base de données vectorielle comme Milvus ou Zilliz Cloud (le Milvus géré) offre une solution de contournement aux limitations de fichiers inhérentes à la récupération intégrée d’OpenAI.
Manque de personnalisation
Bien que la récupération d’OpenAI offre une solution prête à l’emploi pratique, elle ne peut pas toujours s’aligner sur les besoins spécifiques de chaque application, notamment en ce qui concerne la latence et la personnalisation de l’algorithme de recherche. L’utilisation d’une base de données vectorielle tierce offre aux développeurs la flexibilité d’optimiser et de configurer le processus de récupération, afin de répondre aux besoins de production et d’améliorer l’efficacité globale.
Manque de multi-tenant
La récupération est une fonctionnalité intégrée aux OpenAI Assistants qui ne prend en charge que l’usage par des utilisateurs individuels. Cependant, si vous êtes un développeur cherchant à servir des millions d’utilisateurs avec à la fois des documents partagés et des informations privées propres aux utilisateurs, la fonctionnalité de récupération intégrée ne peut pas vous aider. Répliquer les documents partagés dans l’Assistant de chaque utilisateur augmente les coûts de stockage, tandis que faire partager le même Assistant à tous les utilisateurs pose des défis pour prendre en charge les documents privés spécifiques à chaque utilisateur.
Le graphique suivant montre que le stockage de documents dans OpenAI Assistants est coûteux ($6 par GB par mois ; à titre de référence, AWS S3 facture $0.023), ce qui rend le stockage de documents dupliqués sur OpenAI incroyablement gaspilleur.
Tarification de l’Assistants API depuis https://openai.com/pricing
Pour les organisations hébergeant de vastes ensembles de données, un récupérateur évolutif, efficace et rentable, aligné sur des exigences opérationnelles spécifiques, est impératif. Heureusement, grâce à la capacité flexible d’appel de fonctions d’OpenAI, les développeurs peuvent intégrer de manière transparente un récupérateur personnalisé avec OpenAI Assistants. Cette solution garantit que les entreprises peuvent exploiter les meilleures capacités d’IA alimentées par OpenAI tout en conservant l’évolutivité et la flexibilité nécessaires à leurs besoins uniques.
Exploiter Milvus pour une récupération OpenAI personnalisée
Milvus est une base de données vectorielle open source capable de stocker et de récupérer des milliards de vecteurs en quelques millisecondes. Elle est également hautement évolutive afin de répondre aux besoins commerciaux en forte croissance des utilisateurs. Grâce à une mise à l’échelle rapide et à une latence ultra-faible, la base de données vectorielle Milvus figure parmi les meilleurs choix pour créer un récupérateur hautement évolutif et plus efficace pour votre assistant OpenAI.
Fonctionnement d’un récupérateur OpenAI personnalisé
Créer un récupérateur personnalisé avec l’appel de fonction OpenAI et la base de données vectorielle Milvus
Commençons à créer le récupérateur personnalisé et à l’intégrer à OpenAI en suivant le guide étape par étape.
- Configurer l’environnement.
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
- Créer un récupérateur personnalisé avec une base de données vectorielle. Ce guide utilise Milvus comme base de données vectorielle et LangChain comme 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
- Ingérer des documents supplémentaires dans Milvus. Les documents seront analysés, divisés en morceaux, puis transformés en embeddings avant d’être ingérés dans la base de données vectorielle. Les développeurs peuvent personnaliser chaque étape afin d’améliorer la qualité de la récupération.
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])
Vous avez maintenant créé avec succès un récupérateur personnalisé capable d’effectuer une recherche sémantique basée sur vos données privées ou propriétaires. Ensuite, vous devez intégrer ce récupérateur aux Assistants OpenAI afin de permettre la génération de contenu.
- Créer un Assistant avec la fonctionnalité Function Calling d’OpenAI. L’Assistant reçoit l’instruction d’utiliser un outil de fonction appelé
CustomRetrieverlorsqu’il répond aux requêtes.
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 effectue des tâches de questions-réponses de manière asynchrone.
Runest une invocation d’un Assistant au cours d’un Thread. Pendant l’opération d’exécution, l’Assistant décide si une fonction doit appelerCustomRetrieveret attend le résultat de l’appel de fonction.
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
- Maintenant, l’Assistant attend le résultat de l’appel de fonction. Effectuez une recherche vectorielle pour la requête et soumettez le résultat.
# 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
)
- Extrayez et analysez la conversation complète avec 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')
Et voilà ! Vous avez réussi à discuter avec votre OpenAI Assistant à propos des connaissances fournies en tirant parti d’un récupérateur personnalisé alimenté par Milvus.
Conclusion
Bien que l’outil de récupération intégré d’OpenAI Assistants soit impressionnant, il se heurte à des limites telles que les contraintes de stockage, les problèmes d’évolutivité et le manque de personnalisation pour répondre à des besoins utilisateurs variés. Il ne s’adresse qu’aux utilisateurs individuels, ce qui pose des défis pour les applications comptant des millions d’utilisateurs et des documents à la fois partagés et privés.
Créer un récupérateur personnalisé à l’aide d’une base de données vectorielle robuste comme Milvus ou Zilliz Cloud (la version entièrement gérée de Milvus) s’avère utile pour surmonter les défis ci-dessus. Cette approche offre une flexibilité accrue et un meilleur contrôle de la gestion des fichiers grâce à l’intégration de l’OpenAI Assistant API.
Dans nos prochains articles, nous comparerons les performances, le coût et les capacités d’OpenAI Retrieval et d’un récupérateur personnalisé. Nous dévoilerons également les résultats de benchmarks et fournirons des informations précieuses aux développeurs à la recherche de solutions optimales pour améliorer la qualité de la récupération. Restez à l’écoute !
Continuer à lire
Will Amazon S3 Vectors Kill Vector Databases—or Save Them?
AWS S3 Vectors aims for 90% cost savings for vector storage. But will it kill vectordbs like Milvus? A deep dive into costs, limits, and the future of tiered storage.
Vector Databases vs. Time Series Databases
Use a vector database for similarity search and semantic relationships; use a time series database for tracking value changes over time.
What is the K-Nearest Neighbors (KNN) Algorithm in Machine Learning?
KNN is a supervised machine learning technique and algorithm for classification and regression. This post is the ultimate guide to KNN.