" sans fermeture. Pourriez-vous s'il vous plaît fournir le texte complet à traduire ?sentence_embeddings = []
i = 0
while i < len(sentences):
print(f"Got {len(sentence_embeddings)}...")
data = {
"model": "jina-embeddings-v3",
"task": "text-matching",
"late_chunking": False,
"dimensions": 1024,
"embedding_type": "float",
"input": sentences[i:i+10]
}
response = requests.post(url, headers=headers, data=json.dumps(data))
for emb in response.json()['data']:
sentence_embeddings.append(array(emb['embedding']))
i += 10
Puis calculez le cosinus entre l'embedding de chaque phrase et celui de chaque autre phrase :
sent_cosines = []
for i, emb1 in enumerate(sentence_embeddings):
for j, emb2 in enumerate(sentence_embeddings):
if i != j:
sent_cosines.append(cos_sim(emb1, emb2))
Le résultat donne beaucoup plus de valeurs de cosinus : 40 075 230, comme résumé dans le tableau ci-dessous :
| Number of sentences | 6,331 |
|---|---|
| Number of cosines | 40,075,230 |
| Average | 0.254 |
| Std. Deviation | 0.116 |
Les cosinus phrase à phrase sont considérablement plus faibles en moyenne que ceux de document à document complet. L'histogramme ci-dessous compare leurs distributions, et vous pouvez facilement voir que les paires de phrases forment une distribution presque identique à celle des paires de documents mais décalée vers la gauche.
Pour vérifier que cette dépendance à la taille est robuste, calculons tous les cosinus entre les phrases et les documents et ajoutons-les à l'histogramme. Leurs informations sont résumées dans le tableau ci-dessous :
| Number of texts | 6,331 sentences & 1,460 documents |
|---|---|
| Number of cosines | 9,243,260 |
| Average | 0.276 |
| Std. Deviation | 0.119 |
La ligne verte ci-dessous représente la distribution des cosinus phrase-document. Nous pouvons voir que cette distribution se situe parfaitement entre les cosinus document-document et les cosinus phrase-phrase, montrant que l'effet de taille implique à la fois les textes plus grands et plus petits qui sont comparés.
Faisons un autre test en concaténant les documents par groupes de dix, créant ainsi 146 documents beaucoup plus volumineux et mesurant leurs cosinus. Le résultat est résumé ci-dessous :
| Number of texts | 146 documents |
|---|---|
| Number of cosines | 21,170 |
| Average | 0.658 |
| Std. Deviation | 0.09 |
C'est beaucoup plus à droite que les autres distributions. Un seuil de cosinus de 0,5 nous indiquerait que presque tous ces documents sont liés entre eux. Pour exclure les documents non pertinents de cette taille, nous devrions fixer le seuil beaucoup plus haut, peut-être jusqu'à 0,9, ce qui exclurait sans doute les bonnes correspondances parmi les documents plus petits.
Cela montre que nous ne pouvons pas du tout utiliser des seuils de cosinus minimaux pour estimer la qualité d'une correspondance, du moins pas sans tenir compte de la taille du document d'une manière ou d'une autre.
tagQu'est-ce qui cause le biais de taille ?
Le biais de taille dans les embeddings n'est pas comme les biais positionnels dans les modèles à contexte long. Il n'est pas causé par les architectures. Ce n'est pas non plus intrinsèquement lié à la taille. Si, par exemple, nous avions créé des documents plus longs en concaténant simplement des copies du même document encore et encore, cela ne montrerait pas de biais de taille.
Le problème est que les textes longs disent plus de choses. Même s'ils sont contraints par un sujet et un objectif, le but même d'écrire plus de mots est de dire plus de choses.
Les textes plus longs, du moins ceux que les gens créent normalement, produiront naturellement des embeddings qui "s'étendent" sur plus d'espace sémantique. Si un texte dit plus de choses, son embedding aura un angle plus faible avec d'autres vecteurs en moyenne, indépendamment du sujet du texte.
tagMesurer la pertinence
La leçon de cet article est que vous ne pouvez pas utiliser les cosinus entre vecteurs sémantiques par eux-mêmes pour déterminer si quelque chose est une bonne correspondance, mais seulement qu'il s'agit de la meilleure correspondance parmi celles disponibles. Vous devez faire autre chose que calculer des cosinus pour vérifier l'utilité et la validité des meilleures correspondances.
Vous pourriez essayer la normalisation. Si vous pouvez mesurer empiriquement le biais de taille, il peut être possible de le compenser. Cependant, cette approche pourrait ne pas être très robuste. Ce qui fonctionne pour un jeu de données ne fonctionnera probablement pas pour un autre.
L'encodage asymétrique requête-document, fourni dans jina-embeddings-v3, réduit le biais de taille dans les modèles d'embedding mais ne l'élimine pas. Le but de l'encodage asymétrique est d'encoder les documents pour qu'ils soient moins "étendus" et d'encoder les requêtes pour qu'elles le soient davantage.
La ligne rouge dans l'histogramme ci-dessous est la distribution des cosinus document-document utilisant l'encodage asymétrique avec jina-embeddings-v3 – chaque document est encodé en utilisant les drapeaux retrieval.query et retrieval.passage, et chaque embedding de requête de document est comparé à chaque embedding de passage de document qui ne provient pas du même document. Le cosinus moyen est de 0,200, avec un écart-type de 0,124.
Ces cosinus sont considérablement plus petits que ceux que nous avons trouvés ci-dessus pour les mêmes documents en utilisant le drapeau text-matching, comme montré dans l'histogramme ci-dessous.
Cependant, l'encodage asymétrique n'a pas éliminé le biais de taille. L'histogramme ci-dessous compare les cosinus pour les documents complets et les phrases utilisant l'encodage asymétrique.
La moyenne pour les cosinus de phrases est de 0,124, donc en utilisant l'encodage asymétrique, la différence entre le cosinus moyen des phrases et le cosinus moyen des documents est de 0,076. La différence de moyennes pour l'encodage symétrique est de 0,089. Le changement dans le biais de taille est insignifiant.
Bien que l'encodage asymétrique améliore les embeddings pour la recherche d'information, il n'est pas meilleur pour mesurer la pertinence des correspondances.
tagPossibilités futures
L'approche du reranker, par exemple jina-reranker-v2-base-multilingual et jina-reranker-m0, est une alternative pour évaluer les correspondances requête-document que nous savons déjà améliorer la précision des requêtes. Les scores du reranker ne sont pas normalisés, donc ils ne fonctionnent pas non plus comme des mesures de similarité objectives. Cependant, ils sont calculés différemment, et il pourrait être possible de normaliser les scores du reranker de manière à en faire de bons estimateurs de pertinence.
Une autre alternative est d'utiliser des grands modèles de langage, de préférence avec de fortes capacités de raisonnement, pour évaluer directement si un candidat est une bonne correspondance pour une requête. De manière simpliste, nous pourrions demander à un grand modèle de langage spécifique à la tâche : "Sur une échelle de 1 à 10, ce document est-il une bonne correspondance pour cette requête ?" Les modèles existants pourraient ne pas être bien adaptés à la tâche, mais l'entraînement ciblé et des techniques de prompting plus sophistiquées sont prometteurs.
Il n'est pas impossible pour les modèles de mesurer la pertinence, mais cela nécessite un paradigme différent des modèles d'embedding.
tagUtilisez vos modèles pour ce à quoi ils sont bons
L'effet de biais de taille que nous avons documenté ci-dessus montre l'une des limitations fondamentales des modèles d'embedding : ils sont excellents pour comparer des choses mais peu fiables pour mesurer la pertinence absolue. Cette limitation n'est pas un défaut de conception - c'est une caractéristique inhérente au fonctionnement de ces modèles.
Alors qu'est-ce que cela signifie pour vous ?
Premièrement, soyez sceptique envers les seuils de cosinus. Ils ne fonctionnent tout simplement pas. Les mesures de similarité par cosinus produisent des nombres à virgule flottante qui semblent tentants et objectifs. Mais ce n'est pas parce que quelque chose produit des nombres qu'il mesure quelque chose objectivement.
Deuxièmement, envisagez des solutions hybrides. Les embeddings peuvent efficacement réduire un grand ensemble d'éléments à des candidats prometteurs, après quoi vous pouvez appliquer des techniques plus sophistiquées (et plus intensives en calcul) comme les rerankers ou les LLM, ou même des évaluateurs humains pour déterminer la pertinence réelle.
Troisièmement, lors de la conception de systèmes, pensez en termes de tâches plutôt que de capacités. Le modèle objectivement le plus intelligent, avec les meilleurs scores sur les benchmarks est toujours un gaspillage d'argent s'il ne peut pas faire le travail pour lequel vous l'avez obtenu.
Comprendre les limitations de nos modèles n'est pas pessimiste - cela reflète un principe plus large dans les applications : comprendre ce que vos modèles font bien, et ce qu'ils ne font pas bien, est crucial pour construire des systèmes fiables et efficaces. Tout comme nous n'utiliserions pas un marteau pour serrer une vis, nous ne devrions pas utiliser des modèles d'embedding pour des tâches qu'ils ne sont pas capables de gérer. Respectez ce pour quoi vos outils sont bons.
