Embeddings cache regression (^h^h^h confusion) about lumos HOT 2 CLOSED

The UI/UX doesn't give any indication that the cache is skipped when highlighted content is parsed

I haven't thought about this thoroughly. That said, my instinct is that you could/should cache embeddings depending upon the size of the selection (@see still possible that a user "selects all" and even other large selection cases)

The issue was a legit logging of my experiences. I really thought there was a regression, and it wasn't until I rummaged around in the code that I discovered what was happening.

Bypassing the cache is probably the sort of behaviour that many would find reasonable in its simplicity, provided they knew what has happening.

Which is to say, yeah, some kind of indication would help!

from lumos.

A few comments...

1. My thinking behind skipping the cache when highlighted content is selected is that a typical use case would be to highlight "smaller" chunks of text on a page that didn't already have a dedicated content parser (e.g. an infrequently visited site). In this case, embedding should be quick and a user would likely move on to highlight a different part of the page, which means the previous chunk doesn't need to be cached.
2. It's still possible that a user "selects all" content (ctrl+a). In this case, vector search is still valuable.
3. I've updated the search logic to use a combination of cosine similarity and keyword fuzziness search.
4. The UI/UX doesn't give any indication that the cache is skipped when highlighted content is parsed. I can make some quick improvements here (e.g. documentation + messaging in app)

from lumos.