It would be better to keep the behavior of all embedding stores the same. Score should be a number from 0 to 1.

In VertexAI is depends on the algorithm you are using when creating the index. The one use default in the unit tests is not recommended by Google. But happy to revert back and put a note in the unit tests.

which algorithms are supported and wich is the default one? can't find it in the code...

It is defined during index creation. Here is different algorithm that can be configured:

SQUARED_L2_DISTANCE

Euclidean (L2) Distance

L1_DISTANCE

Manhattan (L1) Distance

DOT_PRODUCT_DISTANCE

Default value. Defined as a negative of the dot product.

COSINE_DISTANCE

Cosine Distance. We strongly suggest using DOT_PRODUCT_DISTANCE UNIT_L2_NORM instead of the COSINE distance. Our algorithms have been more optimized for the DOT_PRODUCT distance, and when combined with UNIT_L2_NORM, it offers the same ranking and mathematical equivalence as the COSINE distance.

I am using the default one for testing!

Hmm... is index created automatically by your implementation or user manually creates it? I see that you create VertexAiEmbeddingIndex each time addAll() is called, but I can't find the code responsible for defining algorithm in your implementation...

But my initial point was that instead of using CosineSimilarity.between(embedding, referenceEmbedding), please use RelevanceScore.fromCosineSimilarity(CosineSimilarity.between(embedding, referenceEmbedding)). This way it will be in line with all other integrations. And it should work the same for both cosine similarity and dot product L2 normalization.

Each List has an index file attached to it. This index file is used by the matching engine to index it. If you create a batch mode index, then matching engine scan all the files to add the embeddings to the index. In short, an index is created in 2 phases, first create an index in matching engine (that is where you define the algorithm, ....), then you need to create files that represent a list of embeddings. I implemented the 2 phase, will probably do the first one but this one can be done manually using the UI.

For the relevance, yes I can do that and assume that the index is created with the right algorithm.

By the way I looked the implementation from the python's langchain and they are doing the same.

since you made returnFullDatapoint configurable, the check is needed here that the embedding is returned

It return an empty array. I think we should also return an empty embedding.

An empty Embedding makes no sense, if we don't have an embedding, it is better to return null

That's debatable. Same goes with strings and other empty/null entities.
Anyway, happy to return null instead of empty if no result.

LangChain implementation seem to upload embeddings to GCS bucket first and then update the index, providing a reference to the bucket (where to read embeddings from). But in your implementation you provide embeddings directly in the index, so it feels that uploading them to GCS is unnecessary. Could you please remove this line and test if it still works? Thanks!