Embedding models
ollama.com
ollama.com
I went overkill on one simple task: write a good H1. The process is adaptable for tweets, emails or any other short blob of text. Here's the process:
Input: Choose authors (e.g., Stephen King).
Direction: Select topic or phrase.
Generation: Script creates variations in each author’s voice.
Evaluation: Variations compete to eliminate weak entries.
Ranking: Rank variations by wins and losses.
I mean, I can imagine text embeddings in a 2D plane. Documents about lions and documents about tigers are close together, as they're both big cats. Documents about bears are relatively further away, forming a triangle with two long sides and one short side.
But wouldn't a single document about lions, tiger and bears end up at the middle of the triangle? And wouldn't that mean that when a user searches for lions, the document about tigers is closer than the document about lions, tigers and bears?
How does the system know how much context is required, though? If I ask “Steve wears turtlenecks, what company does Steve work at?” then a paragraph about a Steve who likes turtlenecks and a paragraph about a Steve who works at MS would both be highly relevant but when combined they would result in the wrong answer.
I do wonder if there is some additional cleverness that’s possible with fast, long-context LLMs, maybe a summarizing/preprocessing step that can slice up the document into a sensible hierarchy of topics that can be used as the embeddings source. Never seen this in practice though.
An embedding is essentially a set of neuron activations, the number of combinations of activations is much bigger than the number of neurons themselves. An embedding could store "A+B" as well as being able to store "A" and "B", but it is a little complex to understand what particular activations mean.
But it might also help to understand that most often your embedding smaller chunks of data, specifically for the reason of specificity. A lot of embedding models have a hard limit of 512 tokens or so.
Embedding text that is incredibly short, or much longer than that, tends to decrease the quality precisely because of what you’re talking about. Although I don’t think to the extent you’re imagining
In your simplified example of a 2D plane, yeah, you are right, I think.
However that's why we have more than two dimensions. E.g. If we just have a few more dimensions, we could have one dimension per attribute "lion-ness", "bear-ness", "tiger-ness" of the document, so going higher on the "lion-ness" dimension doesn't have any impact on the other two dimensions, and the conflict is resolved.
Of course in practice, we can't spare one dimension per animal, and that's where embedding models come in, which take care of mapping a string of text into a high-dimensional vector space, and in the process compresses topics, context, etc.. If that model were to be constructed badly, it is possible that we may actually end up with such a bug as you described, where mention of multiple topics produces a not-so-optimal embedding.
Another part that's also relevant in practice is that embedding vectors can be very sensitive (depending on model used) to how you "chunk" (= divide the input string). E.g. if you create chunks where each sentence that is about a bear, a tiger and a lion are separated you will of course get clearer embeddings regarding the individual animals. If you chunk all of them together you will probably receive an "apex-predator"-like embedding, that performs better if you are doing vector search on a more generalized level. That can indeed cause a challenge if you'd like to implementa generalized search that can handle both individual word retrieval as well as concept based retrieval.