Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Marqo – Vectorless Vector Search

github.com

Post reply on HN
Print view View original

11–17 of 17 posts

Re: Show HN: Marqo – Vectorless Vector Search

#11

Post by jn2clark »

bryanrasmussen wrote: post #7

I guess if you wanted to do decompounding and stemming you should make the fields with the stemmed values and the decompounded values yourself and ... then implement it for the queries as well? Or is there a way to do that kind of thing somewhere in there?

At the moment you would need to do this yourself. It would be possible to have additional preprocessing to accommodate this though. Feel free to add a feature request here https://github.com/marqo-ai/marqo/issues. The other consideration is that you would want the distribution of the content and queries to match what the selected model was trained on.

Re: Show HN: Marqo – Vectorless Vector Search

#12

Post by jn2clark »

loxias wrote: post #10
jn2clark wrote: post #5

Earlier quoted context omitted.

I think it depends a bit on the definition of search here. It might satisfy a literal definition of search but not search as users would expect - which I think is the important point. IMHO vector similarity and vector search are conflated too much and solving search problems as users expect them requires more than similarity.

I think you might be on to something, in thinking about it in terms of the platform from the perspective of the end user, and what they build on it. I humbly posit that you might be better off, at least from a communications/marketing perspective, ditching the "vector search without vectors" verbage because that alienates the segment that, uh, for lack of a better term, loves and understands high dimensional applied…

Thanks for the feedback and questions - really appreciate it.

Re: Show HN: Marqo – Vectorless Vector Search

#13

Post by _false »

loxias wrote: post #10
jn2clark wrote: post #5

Earlier quoted context omitted.

I think it depends a bit on the definition of search here. It might satisfy a literal definition of search but not search as users would expect - which I think is the important point. IMHO vector similarity and vector search are conflated too much and solving search problems as users expect them requires more than similarity.

I think you might be on to something, in thinking about it in terms of the platform from the perspective of the end user, and what they build on it. I humbly posit that you might be better off, at least from a communications/marketing perspective, ditching the "vector search without vectors" verbage because that alienates the segment that, uh, for lack of a better term, loves and understands high dimensional applied…

Why not semantic search?

Re: Show HN: Marqo – Vectorless Vector Search

#14

Post by billythemaniam »

bryanrasmussen wrote: post #7

I guess if you wanted to do decompounding and stemming you should make the fields with the stemmed values and the decompounded values yourself and ... then implement it for the queries as well? Or is there a way to do that kind of thing somewhere in there?

I found that stemming the text before generating vectors helps increase recall and the vectors still capture context, etc. However it does hurt precision because some information is lost by stemming. The more recent vector training algorithms are better able to capture semantic, syntactic, and contextual similarity without a lot of preprocessing. So I have found that vectors can replace all the nonsense that used to be needed to increase recall: stemming, manual synonym lists, etc.

However vector similarity search only helps with the literal text search not ranking. Tf/idf, bm25, page rank, learn to rank ML, etc are still needed to rank documents. Whenever I find a new vector search engine, I always look to see what ranking features it has beyond vector similarity.

Re: Show HN: Marqo – Vectorless Vector Search

#15

Post by rmilejczz »

jn2clark wrote: post #5
loxias wrote: post #4

I get your larger point, but the errors and phrasing are a bit off putting. Vector similarity alone _IS_ enough for vector search. That's literally what "search" means in this context! Finding another vector within an epsilon bound given a metric. After the 3rd read, I understand the point you're trying to make I think, and I think you might be right. There might be room in the market for an integrator, an all in one…

I think it depends a bit on the definition of search here. It might satisfy a literal definition of search but not search as users would expect - which I think is the important point. IMHO vector similarity and vector search are conflated too much and solving search problems as users expect them requires more than similarity.

Definitely, RAG programs often grab lots of unneeded context and sometimes miss crucial context. Improving this would be huge imo, for example in something like cursor.

Re: Show HN: Marqo – Vectorless Vector Search

#16

Post by bryanrasmussen »

billythemaniam wrote: post #14
bryanrasmussen wrote: post #7

I guess if you wanted to do decompounding and stemming you should make the fields with the stemmed values and the decompounded values yourself and ... then implement it for the queries as well? Or is there a way to do that kind of thing somewhere in there?

I found that stemming the text before generating vectors helps increase recall and the vectors still capture context, etc. However it does hurt precision because some information is lost by stemming. The more recent vector training algorithms are better able to capture semantic, syntactic, and contextual similarity without a lot of preprocessing. So I have found that vectors can replace all the nonsense that used to…

I would want to do sort of similar to Lucene's support for both stemmed and non-stemmed fields together - so that you could rank the hit in the non-stemmed field higher than the hit in the stemmed field - so helping the precision.

In my experience this is more useful in complicated document searches.

Post reply on HN