Estou construindo um fluxo de trabalho de IA que usa um Vector Store Receiver conectado ao PGVector. Na maioria das vezes, ele recupera o documento correto, mas ocasionalmente um documento menos relevante é classificado acima do que eu realmente espero. Já confirmei que os documentos foram incorporados corretamente e o mesmo modelo de embedding é usado para indexação e consulta. Há algo a considerar para melhorar a qualidade da recuperação?
Qual é a mensagem de erro (se houver)?
Compartilhe seu fluxo de trabalho
(Selecione os nós na sua tela e use os atalhos de teclado CMD+C/CTRL+C e CMD+V/CTRL+V para copiar e colar o fluxo de trabalho.)
Se um documento menos relevante está sendo classificado mais alto, geralmente é porque a mensagem central do documento relevante foi “diluída” pelo texto ao seu redor no chunk, ou o chunk era muito pequeno para fornecer contexto suficiente.
Ajuste o Tamanho e Sobreposição do Chunk: No seu nó Text Splitter, experimente com o tamanho do chunk. Se os chunks forem muito grandes (por exemplo, >1000 tokens), eles contêm vários tópicos, tornando o vetor uma “média” de conceitos não relacionados. Se forem muito pequenos (<200 tokens), carecem de contexto. Tente um tamanho entre 400–800 tokens com uma sobreposição de 10–20%.
Adicione Contexto aos Chunks: Se você estiver dividindo PDFs grandes ou arquivos markdown, adicione o título do documento ou o cabeçalho da seção no início de cada chunk antes de fazer a incorporação. Você pode fazer isso usando um nó Edit Fields (Set) ou um nó Code logo antes do Vector Store Receiver. Isso força o modelo de incorporação a ancorar o vetor ao contexto específico do documento/seção.
Bancos de dados vetoriais calculam a distância entre pontos usando fórmulas matemáticas. Se a métrica não corresponder à forma como seu modelo de incorporação específico foi treinado, as classificações serão distorcidas.
Verifique o Nó PGVector: Na configuração do seu nó Vector Store Tool / PGVector, certifique-se de que a métrica de similaridade está definida como Cosine Distance (ou Cosine Similarity). A maioria dos modelos de incorporação modernos (como text-embedding-3-* do OpenAI, Cohere e Mistral) são otimizados para similaridade de cosseno. Se estiver definido como L2 (Euclidiana) ou Inner Product, pode fazer com que documentos irrelevantes obtenham pontuações mais altas.
Algo que vale a pena verificar é qual tipo de índice está na sua coluna PGVector? Se for ivfflat ou hnsw, significa que você está realmente fazendo uma busca aproximada de vizinho mais próximo. Se estiver usando as configurações padrão, “aproximado” pode acabar significando que a correspondência real mais próxima é perdida e não simplesmente deprioritizada.
Para ivfflat, verifique sua contagem de listas e aumente ‘probes’ no tempo de consulta. Mais probes se aproxima de uma busca exata, mas mesmo uma contagem de probe mais alta não é garantida como equivalente. Para hnsw, verifique ‘ef_search’. Essa é uma coisa rápida para descartar antes de tentar reranquear sua busca, especialmente porque poderia ser uma simples mudança SQL de uma linha.
Oi @Oluwanifemi
O nó de armazenamento vetorial tem modos de inserção, obtenção e recuperação, mas não tem substituição ou exclusão, então cada execução do seu fluxo de ingestão acrescenta uma cópia nova de cada fragmento em vez de atualizar as linhas que já estão lá. Cópias antigas quase idênticas competem com o fragmento atual e podem ocupar os primeiros slots do recuperador, o que aparece exatamente como um documento ocasionalmente errado vencendo. Conte as linhas e compare com o que uma única passagem de ingestão deveria produzir:
SELECT count(*) FROM your_table;
Se for um múltiplo do que você espera, limpe a tabela, indexe uma vez e delete as linhas de uma fonte antes de indexá-la novamente a partir de então.
Se você já descartou uma incompatibilidade de modelo de embedding, eu verificaria como os documentos estão sendo divididos em chunks. Muitos problemas de recuperação vêm de chunks contendo múltiplos tópicos, o que torna o embedding menos focado
Outra coisa a verificar é se seus documentos contêm muito texto repetido ou templates. Se cada registro começa com os mesmos parágrafos, os embeddings acabam ficando mais próximos do que você esperaria, dificultando para o PGVector classificar a melhor correspondência
Por fim, não confie muito na pontuação de similaridade em si. Compare os 5 melhores resultados. Se o documento correto aparece consistentemente perto do topo, mas não em primeiro lugar, geralmente é um problema de qualidade dos dados em vez de um problema com o PGVector
Não é um bug. Este é o comportamento normal da busca vetorial de estágio único: a similaridade de cosseno mede similaridade temática, não relevância. Quando dois chunks estão dentro de uma distância de cosseno de ~0,03, qual ranking primeiro é basicamente ruído. Seus embeddings estarem corretos não previne isso.
Solução (5 minutos, nativo no n8n desde 1.98):
No nó PGVector Vector Store, defina Limit como 20 (padrão é 4).
Options → Add option → Rerank Results → habilite.
Um conector Reranker aparece na parte inferior do nó — anexe um sub-nó Reranker Cohere, modelo rerank-v3.5.
Deixe a fiação do Vector Store Retriever e chain como está.
Por que funciona: seu modelo de embedding codificou os documentos sem nunca ver a query. O reranker é um cross-encoder — ele lê a query e o chunk juntos e calcula a relevância real. Muito lento para todo o corpus, ideal para 20 candidatos.
Defina Limit como um número simples, não uma expressão — n8n#14151 silenciosamente ignora expressões lá e volta para 4.