Tenho um workflow para RAG, mas não está funcionando. Após fazer upload de texto no banco de dados Supabase (o workflow termina com sucesso), quando pergunto ao LLM sobre algo que foi enviado para o Supabase, a IA dá uma resposta errada (ela me diz algo como: Não sei do que você está falando).
Alguém sabe como corrigir esse problema?
Meu workflow aqui
@Quent falha clássica de recuperação RAG: o upload funcionou mas a busca não retorna nada, então o agente não tem contexto e diz “Não sei.” Quase sempre é um destes dois:
-
Incompatibilidade do modelo de embedding (a causa #1). O modelo que você usa para fazer embedding na inserção deve ser exatamente o mesmo modelo no lado da consulta, um modelo ou dimensão diferente coloca os vetores em um espaço diferente então a busca por similaridade retorna zero resultados. Verifique se ambos os nós de Embeddings usam o modelo idêntico.
-
O Vector Store não está conectado ao agente como um retriever, ou o Query Name não está configurado para match_documents.
Se ambos já estão alinhados, cole o workflow e vou identificar, mas em 9 de 10 casos é o modelo de embedding diferindo entre inserção e consulta.
Acho que configurei o LLM corretamente. E acho que o problema é exatamente com o Supabase porque quando estou observando no banco de dados do Supabase, não vejo os embeddings enviados
@Quent isso reduz as possibilidades: sucesso mas nenhuma linha significa que estão sendo gravadas em um lugar que você não está procurando. O ponto principal: o nó Supabase Vector Store ignora o campo table-name e sempre escreve em uma tabela literalmente chamada documents (peculiaridade conhecida). Então verifique especificamente a tabela documents; se você criou ou está verificando uma tabela com nome diferente, suas linhas estão em documents.
Também confirme que a tabela documents tem a estrutura do quickstart (id, content, metadata, embedding vector(N)) com a dimensão correspondendo ao seu modelo de embedding; se essa coluna está faltando nada persiste.
Se em vez disso você vê um erro de RLS/policy, mude a credencial para sua chave service_role (ela ignora RLS). Mas verifique a tabela documents primeiro, é geralmente onde elas estão.
Não, não existe tabela documents. Verifiquei os buckets no storage mas não encontrei lá, também verifiquei as tabelas no db mas não encontrei
Melhor do que quando eu faço upload de texto no Supabase – nunca vejo a interação do nó Supabase com o modelo incorporado
@Quent essa é a causa. O nó Supabase Vector Store precisa de um sub-nó Embeddings conectado a ele, a pequena porta “Embeddings” embaixo do nó. Se nada estiver conectado lá, o nó não tem um modelo para transformar seu texto em vetores, então o insert não armazena nada utilizável, o que é exatamente por isso que você nunca vê ele interagir com um modelo de embedding.
Conecte um nó Embeddings (Embeddings OpenAI ou qualquer outro provedor) àquela porta no nó Vector Store, depois execute novamente, você verá linhas com embeddings chegarem na tabela de documentos. Uma ressalva para depois: use exatamente o mesmo modelo de embeddings no lado da consulta também, ou a recuperação não vai fazer matching.
Se você não vir a tabela documents no Supabase, significa que a tabela nunca foi criada - o n8n não vai criar automaticamente para você. Vá em Supabase > SQL Editor e execute isto:
create extension if not exists vector;
create table documents (
id bigserial primary key,
content text,
metadata jsonb,
embedding vector(1536)
);
create index on documents using ivfflat (embedding vector_cosine_ops);
Nota: altere 1536 para corresponder à dimensão do seu modelo de embedding (OpenAI text-embedding-3-small = 1536, text-embedding-3-large = 3072). Depois que a tabela existir, execute novamente seu workflow de upload e você deve ver as linhas aparecerem na tabela documents em Table Editor.
Agora vejo a tabela documents, mas não vejo as linhas dessa tabela. Quando fiz upload do texto na minha tabela workflow, não preencheu minha tabela.
Hey @Quent, como a tabela existe mas ainda tem zero linhas, é provável que o insert em si esteja falhando silenciosamente.
Verificações rápidas:
Clique no nó Vector Store após uma execução e verifique seu output real, um checkmark verde no workflow nem sempre significa que o nó realmente escreveu dados.
Confirme que está definido como modo “Insert”, não “Retrieve”.
Tente a chave service_role em vez de anon, o RLS pode bloquear silenciosamente inserts sem um erro visível.
Se isso não mostrar nada, uma captura de tela do output real da execução do nó (não apenas a canvas) ajudaria a identificar o problema rapidamente.
Concordo com @achamm, incompatibilidade de embedding é de longe a causa #1.
Duas coisas extras que vale a pena verificar se os fixes dele não resolverem:
- Dimensão da coluna de vetores do Supabase: quando você criou a tabela, a coluna
embeddingtem um tamanho fixo (ex:vector(1536)). Se seu modelo de embedding gera um tamanho diferente, as inserções podem falhar silenciosamente ou a busca retorna nada. Execute\d documentsno editor SQL do Supabase para confirmar que a dimensão corresponde ao seu modelo. - Chunking + top_k: se seus chunks são muito grandes (páginas completas) ou seu
top_ké muito baixo (como 1), o retriever pode puxar um chunk que na verdade não contém a resposta. Tente chunks de ~500 tokens e top_k = 4-5 para começar.
Compartilhe o workflow se ainda estiver falhando depois disso!
Eu já resolvi esse problema. Obrigado a todos
