PGVector Node: Similaridade vetorial com dados templateados e esclarecendo o parâmetro "Prompt"

Descreva o problema/erro/pergunta

Tenho um banco de dados vetorial e quero recuperar vetores semelhantes com base nos dados que tenho. Tenho 2 perguntas sobre a recuperação de dados vetoriais. A primeira é sobre os dados que possuo. Atualmente meus dados são como um modelo porque falam sobre um tópico específico. Abaixo está um exemplo dos meus dados:

1. primeiro dado:
Motivação Institucional:
A adaptação parece destinada a bridging between traditional licensed financial services with blockchain-native infrastructure to support diversified asset management and digital identity verification for retail and SME clients.

Objetivo da Adaptação:
Integrating decentralized digital identity frameworks into regulated financial service and investment workflows.

Raciocínio Institucional:
The partnership formalizes an operational shift toward embedding blockchain-native utility—specifically identity and tokenization—into an established licensed financial group. This suggests an institutional effort to modernize service delivery and asset accessibility by aligning regulatory compliant infrastructure with decentralized service protocols.

Capacidade Operacional:
Ability to leverage decentralized identity systems for service access, facilitate stablecoin-based settlement, and manage the tokenization of real-world assets within a regulated framework.

Transformação Operacional:
Formalization of a partnership to architect and deploy shared Web3 infrastructure, including digital identity verification, stablecoin settlement, and tokenization services, across the Inveo ecosystem.

2. segundo dado:
Motivação Institucional:
Esta adaptação parece destinada a bridging between traditional retail brokerage user interfaces with on-chain, non-custodial execution infrastructure, suggesting an operational shift toward supporting decentralized financial workflows for broader asset classes.

Objetivo da Adaptação:
Integrating decentralized perpetuals exchange infrastructure into self-custodial wallet environments.

Raciocínio Institucional:
O investimento sugere que eToro está operacionalmente integrando trading de perpetuais on-chain descentralizados em sua camada de experiência do usuário varejista existente. Ao combinar a infraestrutura de auto-custódia Zengo com o motor Extended derivatives, a instituição está se deslocando para um modelo operacional onde a execução on-chain não-custodial serve como backend para trading multi-ativo.

Capacidade Operacional:
A instituição está desenvolvendo a capacidade de oferecer aos usuários a capacidade de negociar futuros perpétuos em criptografia, ações, forex e commodities usando infraestrutura de carteira auto-custodial.

Transformação Operacional:
eToro iniciou uma parceria técnica entre a carteira de auto-custódia Zengo e o protocolo de perpetuais Extended para facilitar trading cross-asset dentro de um framework auto-custodial.

3. terceiro dado:
Motivação Institucional:
Parece destinada a estender pegadas operacionais regionais existentes—seguindo atividades anteriores relacionadas a zonas econômicas e câmbio—em infraestrutura de utilidade urbana planejada.

Objetivo da Adaptação:
Integration of blockchain and cryptocurrency infrastructure into the foundational urban planning of a planned digital-first city.

Raciocínio Institucional:
Esta parceria representa uma ação de um provedor de tecnologia para incorporar sua infraestrutura operacional diretamente no desenvolvimento fundacional de uma nova cidade, transitando de atividades de zona econômica regional existentes para infraestrutura digital urbana integrada.

Capacidade Operacional:
Ability to architect and deploy blockchain-based systems at a municipal urban scale.

Transformação Operacional:
The establishment of a formal agreement to provide technical support and infrastructural development services for a city-scale digital environment.

Note que os dados consistem em Motivação Institucional, Objetivo da Adaptação e assim por diante, e o início da frase é quase o mesmo. Minha pergunta é: esse tipo de dado poderia ser usado ao encontrar similaridade vetorial? Porque agora os dados que recebi estão entre 0 - 0,2, e 0,2 não é realmente relacionado aos dados que quero pesquisar.

A segunda pergunta diz respeito ao nó em si. No nó PGVector há uma caixa de prompt. Este prompt se comporta como um prompt de sistema ou como um prompt de usuário? A diferença entre prompt de sistema e prompt de usuário é que o prompt de sistema trata sobre instruções, enquanto o prompt de usuário geralmente consiste nos dados que quero pesquisar. Em certo sentido, devo colocar instruções lá ou devo colocar os dados que quero pesquisar lá?
Nota: atualmente coloquei parameter path lá e está se referindo aos dados que quero pesquisar.

Por favor, compartilhe seu fluxo de trabalho

Compartilhe a saída retornada pelo último nó

Informações sobre sua configuração n8n

  • versão n8n: 2.18.5
  • Banco de dados (padrão: SQLite): Postgres
  • configuração n8n EXECUTIONS_PROCESS (padrão: own, main): main
  • Executando n8n via (Docker, npm, n8n cloud, desktop app): Docker
  • Sistema operacional: Windows 11

Oi @ezraluandre
Vou responder a segunda pergunta primeiro, já que é a mais clara:
O campo “Prompt” no modo Get Many não é nem um prompt de sistema nem um prompt de usuário. É a consulta de busca. O n8n incorpora o que você coloca lá e executa a busca de similaridade contra seus vetores armazenados, então {{ $json.text }} apontando para o texto que você quer corresponder está correto. Não há divisão entre instrução e dados como em um LLM.
Para a primeira pergunta, dados modelados funcionam, mas esse scaffolding compartilhado provavelmente é o motivo de seus scores serem comprimidos. Cada registro começa com os mesmos rótulos (“Institutional Motivation:”, “Adaptation Objective:”, e assim por diante) e frases genéricas quase idênticas, então grande parte de cada incorporação é código comum a todos os registros. A parte distintiva (Inveo vs eToro vs uma cidade planejada) fica diluída e tudo fica próximo, então nada marca fortemente. Duas coisas para tentar:

  1. Remova os rótulos das seções e as aberturas genéricas antes de incorporar, e incorpore apenas o conteúdo substantivo para que o texto distintivo dirija o vetor. Incorporar cada seção como seu próprio registro em vez do bloco inteiro também ajuda.
  2. Confirme que exatamente o mesmo modelo de incorporação está conectado quando você insere e quando você consulta. Uma incompatibilidade de modelo é a razão usual para scores voltarem uniformemente baixos, já que o vetor de consulta e os vetores armazenados não compartilham mais o mesmo espaço.
    O score de cosseno bruto não é uma escala de relevância absoluta, a classificação é o que importa, mas 0 a 0,2 em toda a linha aponta para um desses dois problemas em vez de os dados serem inutilizáveis.