Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is free and source-available on Github. Star git...
For further actions, you may consider blocking this person and/or reporting abuse
want to push back here - semantic search is great for vague conceptual queries but it breaks on exact-match needs. search for a specific error code or a method name you half-remember. keyword search wins there.
Yes, makes sense Mykola
Right - and the fix most teams find too late is hybrid: BM25 for copy-paste queries, semantic for intent. Running both from the start beats retrofitting the second one after your first prod miss.
The bare phrase test humbling you is the most honest part of this. "Chocolate milk" and "milk chocolate" at 0.980 with no surrounding context basically proves context isn't optional for short queries, it's doing all the heavy lifting.
The 0.583 vs 0.066 gap on the shoes query is a clean demo though.
Aight
Turns out you and I have the same idea :D, I also created a Note app just for semantic searching, and I am also using MiniLM for embedding content.
It was born from the desire to look for notes that I had taken quickly without naming and I take quite a lot of notes that make the space look messy
Just my pet project here - this is completely local, no network requesting, LLM will be downloaded and run locally
notes.kanelabs.io.vn/
Nice bud, looks neat :)
The part I always end up wrestling with after the embeddings click into place is recall on the queries that don't look like anything in the index, like rare phrasings or internal jargon. Semantic search nails "comfy shoes for standing all day," but I've watched it quietly miss exact-match intent like a product SKU or an error code, which is why I still keep a keyword path in the loop. How are you measuring retrieval quality once it's live, or is it mostly eyeballed right now?
Yesss
The k-nearest neighbor framing is the clearest mental model I have seen for this. "Grab the stuff parked closest to you" is the kind of description that actually sticks.
The chocolate milk vs milk chocolate result is the part that reveals the limits honestly. 0.751 vs 0.727 â the model knows they are different but it is not as confident as you would expect. That gap shrinks further with longer contexts and domain-specific embeddings. For general-purpose semantic search this is fine; for anything with high-stakes retrieval (legal, medical, code search), you often need domain-fine-tuned embeddings to close that gap, or a hybrid approach that combines keyword BM25 with semantic similarity.
The context sensitivity point about "football" in London vs Dallas is well put, but it raises a harder problem: how does the retrieval system know which context to apply? User location is one signal, but query intent is harder. The same user searching "bank" might mean financial institution or river bank depending on whether they are researching geography or personal finance in the same session.
This gets particularly tricky in agent memory systems where the "context" is not just the query but the accumulated episodic state of a session. Embeddings trained on static text corpora do not inherently know what your robot was doing three steps ago. That is why the embedding layer increasingly needs to be paired with structured metadata â session IDs, timestamps, agent state flags â that the retrieval system can use to re-rank results.
Curious whether you have seen approaches that handle this well, or whether the consensus is still that embedding models will eventually learn session-aware representations from enough agent interaction data?
The git-lrc pitch at the top and bottom feels slightly disconnected from the semantic search content. Is there a thread you could tie between them?
Got it Oge, will do from next time, thanks for the feedback though :)