[Store][PG] Score is inverted?

[lyrixx]

Hello

I noticed something strange with the PG store.

When I query the store to get the similarity, I got 0 for a perfect match, and 1 for something really far.
Usually it's the opposite (1==match, 0==different).

And the minScore enforce my feeling. I don't understand why I would like to filter things that are too revalant: If I put 0.3 I will get document with a match of 0.3+ and so I'll discard all documents with a match from 0 to 0.3, so the best document.

ai/src/store/src/Bridge/Postgres/Store.php

Lines 79 to 85 in fb19713

	/**
	* @param array<string, mixed> $options
	* @param float|null $minScore Minimum score to filter results (optional)
	*
	* @return VectorDocument[]
	*/
	public function query(Vector $vector, array $options = [], ?float $minScore = null): array

Am I wrong? If not, I could submit a PR to return 1 - <current score>

[chr-hertel]

I agree that the scoring should be a float value between 0.0 to 1.0 with higher value meaning better result.

The distance on the other hand depends on the value range of the vectors themselves, right? And could be a wider range than only 0.0-1.0 - so I'm unsure about 1-distance as score

[OskarStark]

Similar to #187?

[DZunke]

Maybe it is not the same. The cosine distance in pgvector is <=>. In the pgvector store the utilized function is the L2 Distance with <-> and so the values differ from the expectation here. Maybe it should be changed instead of just changing the calculation?

[DZunke]

@lyrixx could the PR #197 solve your problem by allowing utilizing the cosine distance? I left L2 as default as it was the current coded default. By switching the algorithm you should get the expected values without the 1 - x calculation needed.

[DZunke]

As a summary from my PR discussions. The PR #197 does NOT solve the "problem" here because the assumptions for results where wrong, see #197 (comment). The filtering argument minScore gives the wrong assumption as the lower the score the better with L2 and Cosine. That is correct.

@chr-hertel brought the following argumentation in:

I think if there's something, that is explicitly part of the method signature, we should streamline the mechanism/behavior across the different implementations as part of the store abstraction. And if it's part of the $options array we would expect it too be leaky and fair to be vendor or option specific.

Meaning, if we want to keep the minScore as explicit argument, we should streamline the behavior no matter which store and option, e.g. score is always between 0.0 and 1.0 and the higher the number the more similar.

Are there other opinions in the room? Otherwise the idea would be to remove the minScore argument from the store query method and make it an option that can differ per store. The minScore wording is at least correct for the MongoDB implementation but for other implementations like MariaDB and Postgres it should be a maxScore.

The result would be that it would not be needed to recalculate the store results into another direction just to have the minScore wording right.

[OskarStark]

Indeed, I'd vote for the $options then and remove the $minScore parameter.