Ainda precisamos de bancos de dados vetoriais para RAG com o lançamento da recuperação integrada da OpenAI?
A OpenAI mais uma vez ganhou destaque com uma série de lançamentos durante seu DevDay, revelando o modelo GPT-4 Turbo, a nova Assistants API e uma variedade de melhorias. A Assistants API surge como uma ferramenta poderosa que ajuda desenvolvedores a criar aplicações de IA sob medida para atender a necessidades específicas. Ela também permite que eles acessem conhecimento adicional, maior comprimento de prompt e ferramentas para várias tarefas.
Embora os OpenAI Assistants venham com um recurso de recuperação integrado, ele não é perfeito — pense em restrições quanto à escala de dados e falta de capacidade de personalização. É exatamente aqui que um recuperador personalizado entra para ajudar. Ao aproveitar os recursos de chamada de funções da OpenAI, os desenvolvedores podem integrar perfeitamente um recuperador personalizado, ampliando a escala do conhecimento adicional e atendendo melhor a diversos casos de uso. Nesta postagem do blog, vamos nos aprofundar nas limitações da recuperação integrada da OpenAI e orientar você na criação de um recuperador personalizado usando o banco de dados vetorial Milvus.
Limitações da recuperação da OpenAI nos Assistants e o papel das soluções de recuperação personalizadas
O recurso de Retrieval integrado da OpenAI representa um salto além do conhecimento inerente do modelo, permitindo que os usuários o ampliem com dados extras, como informações proprietárias de produtos ou documentos fornecidos pelo usuário. No entanto, ele enfrenta limitações notáveis.
Restrição de escalabilidade
O OpenAI Retrieval impõe restrições de arquivos e armazenamento total que podem ficar aquém para repositórios extensos de documentos:
Um máximo de 20 arquivos por assistente
Um limite de 512MB por arquivo
Uma limitação oculta de 2 milhões de tokens por arquivo, descoberta durante nossos testes
Um limite de tamanho total inferior a 100GB por organização
Para organizações com repositórios de dados extensos, essas limitações representam desafios. Uma solução escalável que cresça perfeitamente sem atingir tetos de armazenamento torna-se imprescindível. Integrar um recuperador personalizado alimentado por um banco de dados vetorial como Milvus ou Zilliz Cloud (o Milvus gerenciado) oferece uma alternativa para as limitações de arquivos inerentes ao Retrieval integrado da OpenAI.
Falta de personalização
Embora o Retrieval da OpenAI ofereça uma solução conveniente pronta para uso, ele não consegue se alinhar consistentemente às necessidades específicas de cada aplicação, especialmente em relação à latência e à personalização do algoritmo de busca. Utilizar um banco de dados vetorial de terceiros dá aos desenvolvedores a flexibilidade para otimizar e configurar o processo de recuperação, atendendo às necessidades de produção e aumentando a eficiência geral.
Falta de multi-inquilinato
Retrieval é um recurso integrado nos OpenAI Assistants que oferece suporte apenas ao uso por usuário individual. No entanto, se você é um desenvolvedor que pretende atender milhões de usuários com documentos compartilhados e informações privadas dos usuários, o recurso de recuperação integrado não pode ajudar. Replicar documentos compartilhados para o Assistant de cada usuário aumenta os custos de armazenamento, enquanto fazer todos os usuários compartilharem o mesmo Assistant apresenta desafios para dar suporte a documentos privados específicos de cada usuário.
O gráfico a seguir mostra que armazenar documentos nos OpenAI Assistants é caro ($6 por GB por mês; para referência, a AWS S3 cobra $0.023), tornando o armazenamento de documentos duplicados na OpenAI incrivelmente desperdiçador.
Preços da Assistants API de https://openai.com/pricing
Para organizações que abrigam conjuntos de dados extensos, é imprescindível um recuperador escalável, eficiente e econômico que se alinhe a demandas operacionais específicas. Felizmente, com o recurso flexível de chamada de funções da OpenAI, os desenvolvedores podem integrar perfeitamente um recuperador personalizado com os OpenAI Assistants. Essa solução garante que as empresas possam aproveitar os melhores recursos de IA alimentados pela OpenAI, mantendo escalabilidade e flexibilidade para suas necessidades únicas.
Aproveitando o Milvus para recuperação personalizada da OpenAI
Milvus é um banco de dados vetorial de código aberto que pode armazenar e recuperar bilhões de vetores em milissegundos. Ele também é altamente escalável para atender às necessidades de negócios em rápido crescimento dos usuários. Com escalabilidade rápida e latência ultrabaixa, o banco de dados vetorial Milvus está entre as principais escolhas para criar um recuperador altamente escalável e mais eficiente para o seu assistente da OpenAI.
Como funciona um recuperador personalizado da OpenAI
Criando um recuperador personalizado com chamada de função da OpenAI e o banco de dados vetorial Milvus
Vamos começar a criar o recuperador personalizado e integrá-lo à OpenAI seguindo o guia passo a passo.
- Configure o ambiente.
pip install openai==1.2.0
pip install langchain==0.0.333
pip install pymilvus
export OPENAI_API_KEY=xxxx # Insira sua chave de API da OpenAI aqui
- Crie um recuperador personalizado com um banco de dados vetorial. Este guia usa o Milvus como banco de dados vetorial e LangChain como wrapper.
from langchain.vectorstores import Milvus
from langchain.embeddings import OpenAIEmbeddings
# Prepare o recuperador
vector_db = Milvus(
embedding_function=OpenAIEmbeddings(),
connection_args = {'host': 'localhost', 'port': '19530'}
)
retriever = vector_db.as_retriever(search_kwargs={'k': 5}) # altere top_k aqui
- Ingira documentos extras no Milvus. Os documentos serão analisados, divididos em blocos e então transformados em embeddings antes de serem ingeridos no banco de dados vetorial. Os desenvolvedores podem personalizar cada etapa para melhorar a qualidade da recuperação.
from langchain.document_loaders import TextLoader
from langchain.text_splitter import RecursiveCharacterTextSplitter
# Analisando e dividindo o documento em blocos.
filepath = 'path/to/your/file'
doc_data = TextLoader(filepath).load_and_split(
RecursiveCharacterTextSplitter(chunk_size=1000, chunk_overlap=200)
)
# Gerando embeddings e inserindo blocos no banco de dados vetorial.
vector_db.add_texts([doc.page_content for doc in doc_data])
Agora, você criou com sucesso um recuperador personalizado capaz de operar pesquisa semântica com base nos seus dados privados ou proprietários. Em seguida, você deve integrar esse recuperador ao OpenAI Assistants para habilitar a geração de conteúdo.
- Crie um Assistant com o recurso Function Calling da OpenAI. O Assistant é instruído a usar uma ferramenta de função chamada
CustomRetrieverao responder a consultas.
import os
from openai import OpenAI
# Configure o cliente OpenAI.
client = OpenAI(api_key=os.getenv('OPENAI_API_KEY'))
# Crie um 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', # Altere o modelo da OpenAI aqui
)
- O Assistant executa tarefas de perguntas e respostas de forma assíncrona.
Runé uma invocação de um Assistant durante uma Thread. Durante a operação de execução, o Assistant decide se uma função precisa chamarCustomRetrievere aguarda o resultado da chamada de função.
QUERY = 'ENTER YOUR QUESTION HERE'
# Crie uma 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
- Agora, o Assistant está aguardando o resultado da chamada de função. Faça uma busca vetorial para a consulta e envie o resultado.
# 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
)
- Extraia e analise a conversa completa com a 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')
Pronto! Você conversou com sucesso com seu OpenAI Assistant sobre o conhecimento fornecido, aproveitando um recuperador personalizado alimentado pelo Milvus.
Conclusão
Embora a ferramenta de recuperação integrada dos OpenAI Assistants seja impressionante, ela enfrenta limitações como restrições de armazenamento, problemas de escalabilidade e falta de personalização para diversas necessidades dos usuários. Ela atende apenas a usuários individuais, apresentando desafios para aplicações com milhões de usuários e documentos compartilhados e privados.
Criar um recuperador personalizado usando um banco de dados vetorial robusto como Milvus ou Zilliz Cloud (a versão totalmente gerenciada do Milvus) mostra-se útil para superar os desafios acima. Essa abordagem oferece maior flexibilidade e controle de gerenciamento de arquivos por meio da integração com a API do OpenAI Assistant.
Em nossos próximos posts, compararemos o desempenho, o custo e os recursos do OpenAI Retrieval e de um recuperador personalizado. Também revelaremos resultados de benchmark e forneceremos insights valiosos para desenvolvedores que buscam soluções ideais para melhorar a qualidade da recuperação. Fique ligado!
Continue lendo
Stop Building AI Data Infra for the Wrong Stage
Learn how AI data infrastructure should evolve from prototype to enterprise scale, and when Vector Lakebase becomes the right architecture for AI apps.
How Zilliz Saw the Future of Vector Databases—and Built for Production
An inside look at how Zilliz built vector databases for real-world use, focusing on scalability, stability, and running them reliably at scale.
Demystifying the Milvus Sizing Tool
Explore how to use the Sizing Tool to select the optimal configuration for your Milvus deployment.