However, I noted, that the base model is performing quite poorly on small text chunks (a few words) while the small version seems to be unaffected. Might this be some kind of side effect due to the way they deal with large contexts?
If you want to test, you can head over to SemanticFinder (https://do-me.github.io/SemanticFinder/), go to advanced settings, choose the Jina AI base model (at the very bottom) and run with "Find". You'll see that all other models perform just fine and find "food"-related chunks but the base version doesn't.
That's awesome and so much more practical than scrolling through HN.
It would also be possible to integrate semantic search so people don't necessarily need to know the keywords. If you're interested, feel free to ping me or take a look at https://github.com/do-me/SemanticFinder. In case I could just create a pre-indexed version based on your data dump which would be quite convenient to use.
My open source blog mainly with (geospatial) niche tutorials.
It's a pretty personal thing as I mostly (but not only) derive the blog posts from challenges I encounter during work or my PhD research. In this way it documents my learnings and serves as a quite verbose personal wiki.
Awesome project! From the website I wasn't quite able to tell where exactly and how AI comes into play.
I think apart from fuzzy searching headings a semantic search functionality for the whole text would be a really nice default feature. I implemented frontend-only semantic search with transformers.js here: geo.rocks/semanticfinder. The implementation is very straightforward and it would be easy to integrate in the browser, maybe as a plugin or similar.
SemanticFinder now offers an easier way of pre-indexing files. Just like in all ML-flows the embedding calculation is the computation-intense part, so if you do this beforehand and load it in your browser, calculating cosine similarity is trivial (for a few thousand iterations).
It has the nice side-effect that this also allows for external computation of embeddings where you might have faster hardware than you're client device.
One could add so many features like adding full-text search by checking if the index contains certain keywords.
For smaller documents (but also entire books) you can even perform everything in your browser with JS without any DB or backend using transformers.js. It's surprisingly fast.
I think this could be really useful for visually impaired people. Just imagine, that instead of colors and letters you'd have unique shapes or to keep it simple something like a raster with holes. Every bus stop could have one of those raster plates while the people would have a sort of "key", designed to fit in "their bus".
I came up with a very similar approach to explain HyperLogLog a while ago and see some parallels.
I guess the key/lock principle is very similar to both, bloom filter and HyperLogLog and could yield other benefits as well, like counting distinct buses passing a stop and map them for city. In this way, one could easily create a heat map of the cities best- and worst-served areas.