Let me rephrase the relevant bit: it doesn't make sense (as far as I can see) to store the value to be compared inside the object. Apart from anything else that makes it harder to have multiple comparators, for no obvious benefit.

In my suggested interface your example would look like:

my $cmp1 = $embedding->comparator($embed1);
my $diff2 = $cmp1->($embed2);   # Compares $embed2 to $embed1
my $diff3 = $cmp1->($embed3);   # Compares $embed3 to $embed1
my $diff4 = $cmp1->($embed4);   # Compares $embed4 to $embed1
# ... etc ...
[download]

But you could also simultaneously have a second comparator, without needing a whole second object for it:

my $cmp2 = $embedding->comparator($embed2);
# classify target embeddings according to which they are most similar 
+to
for my $next_embed (@targets) {
  my $diff1 = $cmp1->($next_embed);
  my $diff2 = $cmp2->($next_embed);
  if ($diff1 > $diff2) {
    push @closer_to_embed1, $next_embed;
  } else {
    push @closer_to_embed2, $next_embed;
  }
}
[download]

Generally it is preferable for instances of a class to represent one thing: in this case an instance represents "the interface to a given model via an API". At the point you store a comparison vector, it represents "the interface to a given model via an API _and_ something that knows how to compare against one particular embedding" - that's a mash-up of two very different things.

My suggested approach is the smallest change I could see that avoids the mash-up. Another approach would be to expose make_vector and compare_vector methods; then there is no need for the object to have special mechanisms to cache the vector. Yet another approach would be for embedding itself to return an object of a new type, would could tell you the string, array or vector representations of the embedding as needed. (But at that point you'd really want the existing class to be called AI::Interface or AI::Embedder so that this new object can be an actual AI::Embedding.)