PGVector Node : similarité vectorielle avec données de modèle et clarification du paramètre « Prompt »

Questions
1

Décrivez le problème/l’erreur/la question

J’ai une base de données vectorielle et je souhaite récupérer des vecteurs similaires en fonction des données que j’ai. J’ai 2 questions concernant la récupération de données vectorielles. La première porte sur les données que j’ai. Actuellement, mes données ressemblent à un modèle car elles traitent un sujet particulier. Voici un exemple de mes données :

1. première donnée :
Motivation institutionnelle :
L'adaptation semble destinée à combler le fossé entre les services financiers agréés traditionnels et l'infrastructure native de la blockchain pour soutenir la gestion diversifiée des actifs et la vérification numérique d'identité pour les clients de détail et PME.

Objectif de l'adaptation :
Intégrer des cadres d'identité numérique décentralisés dans les flux de travail des services financiers réglementés et des investissements.

Raisonnement institutionnel :
Le partenariat formalise un changement opérationnel vers l'intégration de l'utilité native de la blockchain — en particulier l'identité et la tokenisation — dans un groupe financier agréé établi. Cela suggère un effort institutionnel pour moderniser la prestation de services et l'accessibilité des actifs en alignant l'infrastructure conforme à la réglementation avec les protocoles de services décentralisés.

Capacité opérationnelle :
Capacité à exploiter les systèmes d'identité décentralisés pour l'accès aux services, à faciliter le règlement basé sur les stablecoins et à gérer la tokenisation des actifs du monde réel dans un cadre réglementaire.

Transformation opérationnelle :
Formalisation d'un partenariat pour concevoir et déployer une infrastructure Web3 partagée, incluant la vérification numérique d'identité, le règlement en stablecoins et les services de tokenisation, dans l'écosystème Inveo.

2. deuxième donnée :
Motivation institutionnelle :
Cette adaptation semble destinée à combler le fossé entre les interfaces utilisateur traditionnelles du courtage de détail et l'infrastructure d'exécution sur chaîne et non-dépositaire, suggérant un changement opérationnel vers le soutien des flux de travail financiers décentralisés pour des classes d'actifs plus larges.

Objectif de l'adaptation :
Intégrer l'infrastructure des échanges de contrats perpétuels décentralisés dans les environnements de portefeuille auto-dépositaire.

Raisonnement institutionnel :
L'investissement suggère qu'eToro intègre opérationnellement le trading de contrats perpétuels décentralisés sur chaîne dans sa couche d'expérience utilisateur existante. En combinant l'infrastructure d'auto-garde Zengo avec le moteur Extended dérivés, l'institution se tourne vers un modèle opérationnel où l'exécution non-dépositaire sur chaîne sert de backend pour le trading multi-actifs.

Capacité opérationnelle :
L'institution développe la capacité à offrir aux utilisateurs la possibilité de trader des contrats futurs perpétuels sur les crypto-monnaies, les actions, le forex et les matières premières en utilisant l'infrastructure de portefeuille auto-dépositaire.

Transformation opérationnelle :
eToro a lancé un partenariat technique entre le portefeuille d'auto-garde Zengo et le protocole de contrats perpétuels Extended pour faciliter le trading multi-actifs dans un cadre auto-dépositaire.

3. troisième donnée :
Motivation institutionnelle :
Semble destinée à étendre les empreintes opérationnelles régionales existantes — suivant les activités précédentes liées aux zones économiques et aux échanges — vers l'infrastructure d'utilité urbaine planifiée.

Objectif de l'adaptation :
Intégration de l'infrastructure blockchain et des crypto-monnaies dans la planification urbaine fondamentale d'une ville numérique planifiée et d'abord.

Raisonnement institutionnel :
Ce partenariat représente un mouvement d'un fournisseur de technologie pour intégrer son infrastructure opérationnelle directement dans le développement fondamental d'une nouvelle ville, passant des activités de zones économiques régionales existantes vers une infrastructure numérique urbaine intégrée.

Capacité opérationnelle :
Capacité à concevoir et déployer des systèmes basés sur la blockchain à l'échelle urbaine municipale.

Transformation opérationnelle :
L'établissement d'un accord formel pour fournir des services de soutien technique et de développement infrastructurel pour un environnement numérique à l'échelle d'une ville.

Notez que les données consistent en Motivation institutionnelle, Objectif de l’adaptation et ainsi de suite, et le début de la phrase est presque identique. Ma question est : ce type de données pourrait-il être utilisé lors de la recherche de similarité vectorielle ? Car en ce moment, les données que j’obtiens sont comprises entre 0 et 0,2, et 0,2 n’est vraiment pas liée aux données que je souhaite rechercher.

La deuxième question concerne le nœud lui-même. Sur le nœud PGVector, il y a une boîte d’invite. Cette invite se comporte-t-elle comme une invite système ou comme une invite utilisateur ? La différence entre l’invite système et l’invite utilisateur est que l’invite système porte sur les instructions, tandis que l’invite utilisateur consiste généralement dans les données que je souhaite rechercher. En ce sens, dois-je placer des instructions là ou les données que je souhaite rechercher ?
Remarque : je place actuellement le chemin des paramètres là et il fait référence aux données que je souhaite rechercher.

Veuillez partager votre flux de travail

Partagez le résultat renvoyé par le dernier nœud

Informations sur votre configuration n8n

  • Version n8n : 2.18.5
  • Base de données (par défaut : SQLite) : Postgres
  • Paramètre n8n EXECUTIONS_PROCESS (par défaut : own, main) : main
  • Exécution de n8n via (Docker, npm, n8n cloud, application bureau) : Docker
  • Système d’exploitation : Windows 11
2

Salut @ezraluandre
Je vais d’abord répondre à la deuxième question puisqu’elle est plus claire :
Le champ « Prompt » en mode Get Many n’est ni un system prompt ni un user prompt. C’est la requête de recherche. n8n intègre tout ce que tu mets là et exécute la recherche de similarité par rapport à tes vecteurs stockés, donc {{ $json.text }} pointant vers le texte que tu veux mettre en correspondance est correct. Il n’y a pas de séparation entre instruction et données ici comme avec un LLM.
Pour la première question, les données modélisées fonctionnent, mais cet échafaudage partagé explique probablement pourquoi tes scores sont comprimés. Chaque enregistrement commence par les mêmes étiquettes (« Institutional Motivation: », « Adaptation Objective: », etc.) et une formulation standard quasi identique, donc une grande partie de chaque embedding est du texte passe-partout commun à tous les enregistrements. La partie distinctive (Inveo vs eToro vs une ville planifiée) est diluée et tout se retrouve regroupé, donc rien ne score fortement. Deux choses à essayer :

  1. Supprime les étiquettes de section et les ouvertures standard avant l’embedding, et intègre uniquement le contenu substantiel pour que le texte distinctif pilote le vecteur. Intégrer chaque section en tant qu’enregistrement distinct au lieu du bloc entier aide aussi.
  2. Vérifie que le même modèle d’embedding est connecté quand tu insères et quand tu interroges. Une incompatibilité de modèle est la raison habituelle pour laquelle les scores reviennent uniformément bas, puisque le vecteur de requête et les vecteurs stockés ne partagent plus le même espace.
    Le score de cosinus brut n’est pas une échelle de pertinence absolue, c’est le classement qui compte, mais 0 à 0,2 partout indique l’un de ces deux problèmes plutôt que le fait que les données soient inutilisables.