T-Wand: beating Lucene in less than 600 lines of code
yyhh.org
yyhh.org
> As someone who has a Ph.D. in Human-computer Interaction ;-), I feel like I am entitled to define a condition of "good" in relevance here. I hereby declare that:
>> A good top-K algorithm should rank a document containing more user query terms higher than a document containing less number of user query terms.
> This makes perfect sense. Right?
Also, “most search engines” don’t use vector space model as the only way to rank result, for example, page rank.
Edit: in some search scenarios finding the documents with the most query terms make sense, but Lucene can also rank using this metric. Still, applaud the author's effort in digging into research literature. Search relevance is very hard and standard off the shelf metrics like TF-IDF and page rank are often not enough. Good search usually requires deep understanding of the specific subject domain and hand-tuning tons of signals, many of which aren't even strictly based on search terms (e.g., previously purchased products on a store's website, geographic location, trending results).
I also do know a lot about IR, because I taught Information Retrieval class for 3 years when I was teaching in university, I read research papers, and I just come up with a new search algorithm.
It's just that some people cannot accept that there are people who can cross fields with ease, make contributions quickly, and move on to the next field that pit their interests.
Yes, I am one of those people. In addition to HCI, I also published in the following areas: VR, DB, NLP, IR and Psychology. Sorry to hurt your feelings, but it is what it is. Accept it and move on.
I wrote a blog post for lay people to read. I am under no obligation to do an extensive literature review, I only need to mention the essentials.
You just cannot seem to swallow the fact that someone who does not have a Ph.D in IR or computational linguistics can come in to contribute quickly then move on to something else. It hurts your feelings deeply, does it? Heed my advice, just get over it, don't take your degree or your specialization too seriously. It does not matter.
What did I miss?
The PhD flex in jest by the blog post's author is a bit awkward but I don't know that I would characterize it as smug.
Any insight into why the author is perceived as smug would be appreciated.
I could see calling it audacious. But, our industry advances on audacity.
I am obviously a Chinese.
In the eyes of racists, Chinese Americans are supposed to be timid and does not make any noises, but I do make noises, so I am perceived as a smug today because I said I am a Ph.D, something else next time I said something else.
It's not complicated.
OK, re-reading it, there are a few hints (a Chinese proverb, your nickname, etc.). But nothing "obvious".
Probably not the explanation we are looking for here.
It's good for you that you are not a racist (it's sad that such a normal thing has to be a compliment, but it is a compliment. Good for you.), but racists do look for these cues and make their judgement based on these.
It's an unfortunate current state of affairs that we have to live with. Ignoring it does not make it going away though. If you don't like it, you got to call it out whenever you see it, which I hope you do, instead of being taken back by it, as you seems to be.
Why do you have to use a throwaway account to say this, I am curious.
Relevance is really subjective, domain specific, requires intense amount of measurement and testing and many different ranking signals. Lucene is a toolbox for crafting many of these signals.
For example, he says
> However, as you can see, this vector space model does not explicitly require a higher ranking document to contain more query terms than a lower ranking one.
Well the way you get a higher similarity in a vector-space model is matching more terms. The caveat being that IDF and field length makes you also consider a term's specificity. So if you search for 'luke skywalker' you care more about the 'skywalker' match than the 'luke' match. But a match on BOTH 'luke skywalker' would score higher (field lengths being constant)
https://lucene.apache.org/core/3_5_0/scoring.html
"Lucene scoring is the heart of why we all love Lucene. It is blazingly fast and it hides almost all of the complexity from the user. In a nutshell, it works. At least, that is, until it doesn't work, or doesn't work as one would expect it to work. Then we are left digging into Lucene internals or asking for help on java-user@lucene.apache.org to figure out why a document with five of our query terms scores lower than a different document with only one of the query terms."
See? Lucene people know about it but they just do not think it is a problem.
But I do.
T-Wand, though also uses vector space model, makes sure it is the case.
Those settings aside, arguably there are cases where fewer term matches could be more relevant.
For the search “Luke skywalker”
A tweet for example mentioning the term “Skywalker” once has much higher “Star Wars” aboutness than a move that uses skywalker one page and Luke pages apart.
That is the information density of Star Wars type content is far higher in the tweet, whereas eventually a book ends up using most English somewhere.
You had a wrong understanding. Now you are corrected. Let's move on.
Nobody said anything about "fewer term matches could not be more relevant". You are just making up straw men here. That's not the discussion we are having.
What I said is this, from a user point of view, it's not good to have a document containing fewer query terms to rank higher. This is a fact that even Lucene acknowledge (at least when they were version 3.5.0.). You have nothing to counter this fact.
There’s been extensive research justification behind the vector-space model. BM25 is the 25th iteration of a model and well tuned BM25 holds the highest non nueral performance on many tasks including question answering[1]. Research has long found including factors other than total term matches matters. Such as IDF[2] and field length[3].
Have you benchmarked your relevance assumptions similarly? If so I’d love to see them and learn more!
1 - https://www.elastic.co/blog/improving-search-relevance-with-...
2- https://www.researchgate.net/publication/238123710_Understan...
I was simply motivate my work, pointing out it's a problem that the current generation of search engine does not address.
What is "relevance", it is of course a context sensitive question.
You talk as if BM25 is the gold standard when it is not.
The research on this is all over the place. I just read an article that says that BM25 is way worse than alternative language models. You don't have to look far, for example this one that talks about Wand:
https://dl.acm.org/doi/10.1145/2537734.2537744
You know why I quit academia? It is useless arguments and virtual signalings like these.
I'd rather go out and build a damn thing that people like to use.
I merely pointed out that there's a problem, and I have a solution. I did not claim that my problem and my solution solve all problems. Isn't this obvious?
In my problem, my solution beats Lucene. It's as simple as that.
So if Lucene wants to be this infinitely configurable search library, it would be advisable to offer my solution as an option, or offer an better one that does something similar.
So far I have not seen any takers, only excuses.
"Better Relevance"
and I am simply saying, arguably, you can't make that claim without evidence.
(That said, I do find much to like about the article and the WAND / T-WAND explanation. I'm only pointing out you can't claim 'better relevance' without a benchmark to go with it.)
It is actually smug, to suggest the author, in this case, me, a computer scientist and a past professor who taught Information Retrieval class for more than 3 years, and who just came up with a new search algorithm, to "take a look at Wikipedia page for TF-IDF".
In case you have not read the article due to your smugness, my search algorithm also uses TF-IDF and vector space model.
Please do not dis-understand what is going on here: I am running a startup, and I am also old enough to not care about publications as much as people who are younger or in academia.
That's why I chose to reveal this in a blog post instead of hiding it until after my paper is published. Understood?
People have chosen not to do this because (1) it adds complexity, and (2) the bold declaration you made (A good top-K algorithm should rank a document containing more user query terms higher than a document containing less number of user query terms) turns out to be only somewhat true in practice. It's pretty common for pagerank and other non-linguistic ranking signals etc to trump linguistic preciseness.
That said, everything is a tradeoff, and the industry has clearly chosen to return more candidates than strictly necessary, then prune them after the fact with better ML & relevance, rather than trying to construct the perfectly minimal candidate set while missing some possible results.
[1] See https://www.elastic.co/guide/en/elasticsearch/reference/curr...
It is easy to implement T-Wand in the existing Lucene code base, and I would hope so. Otherwise, it would be a shame.
I do not understand why rejecting a million-lines-of-code dependency implies the person is a troll?
because when you say 'beating' the implication is it does what X does better - as opposed to just matching my use case with 600 lines and not big dependency import.
this usage of beating is going to rile up (i.e troll) everyone familiar with the subject who can see thousands of ways you did not beat it.
Any additional features that a product has but which you don’t need for a particular purpose is a downside, not an upside.
They’re not claiming to beat Lucene for the general case of everything Lucene is capable of.
He didn't use any benchmarking library, and he used System.currentTimeMillis instead of the high precision timer available with System.nanoTime.
He also instantiated the IndexSearcher without specifying any executor and he instantiated the legacy query parser on every lucene search
I am writing a database, full-text search is just a *minor* feature.
Why should I bringing in a huge dependency for a minor feature when my whole code base is orders magnitude smaller than that?
The order in which iterators are tested against the pivot can be term cardinality ordering (which is one of the heuristics described in the original paper AFAIR). Then, the pivot documents are a subset of what the article calls the current "tier" (union of the k rarest terms).
You fundamentally misunderstand both Wand and T-Wand.
I suggest you to read my article and the papers again.
The novelty of T-Wand, is not in sorting the rows on idf, which T-Wand actually does NOT do, but in adding some filtering conditions that are not previously reported in the literature.
You missed that, so you missed the whole point. Smugness hurts.
I see that you work on Facebook Search and I know you are one of the authors in this field, I can see why your feelings are hurt.
It's okay. There are always people smarter than you are, who can come into a completely new field, spend a few weeks, and come up with something new that you could not come up with when you have spent your whole career on.
It's OK. When you are older, you will learn to accept that. You can only work with what life gives you.
Please take my ideas and put that in Faceook Search, because it presently sucks.
BTW, you should have put the PDF of your paper on the Web, then I would have read it, instead of only recognizing your name, put it on arxiv like everyone else, if you want people to read it.
Also, that's why I post it on hacker news instead of publishing first in a conference. Because there will be more people reading it. Not many people read papers.
https://github.com/juji-io/datalevin/issues/created_by/caval...
Contributing to open source project is good, right?
BTW, Lucene is an open source project, Datalevin is also an open source project. Contributing to either would be equally good.
Even if you only want to contribute to Lucene for some reasons, a better contribution would be to integrate T-Wand in Lucene, rather than trying to talk down Datalevin. Would you agree?
tf-idf and phrase search alone make lucene 10x better, not speaking of the compression, fuzzy search, advanced query features etc.
I love new search engines like tantivy etc, but this is, due to the tone, a sad joke.
Besides, the said technology does do tf-idf and fuzzy search, and will soon have phrase search, and other features, if enough people request them.
Datalevin is an open source project, not unlike Lucene. What's the difference? Not like the tone?
To those who says "I like Lucene because it does Tf-idf", please be assured that T-Wand also does tf-idf and uses vector space model.
To those who say "T-Wand is just Wand", please be reminded that you are just repeating what the article was saying. Of course T-Wand is Wand, but you miss the technical contribution of T-Wand, which is clearly laid out in "What's new in T-Wand" section of the article. Of course, it is understandable if you are not able to judge the merit of that contribution, for that's the job of the peer review panel, which I do not expect Hacker News readers to be. This work will be submitted to a peer reviewed conference with more experiments added and all trade-offs discussed.
This may come as a disappointment to some, but the paper will not have a comparison with Lucene, for it would be scientifically unsound.
However, it should be easy for Lucene to add T-Wand as an option, and I do hope so.
I highlighted some other problems related to the Lucene benchmark, but since I can't program in Clojure I can't fix them with a PR: I opened 3 issues to describe what can be done to address them.
To be honest, all your proposed changes would not make material difference, for algorithmic differences cannot be made up by implementation details.
As has already been demonstrated, T-Wand is implemented in a much slower language, Clojure. Clojure is implemented on top of JVM, it cannot possibly beat the same algorithm written in optimized Java. The only way to make a difference is to change the algorithm. So all your suggestions would not make a difference.
This is not an isolated case. They rejected some industry changing contributions when they first came out.
For example, I remember that Google PageRank paper was outright rejected by SiGIR. Lucky for us, that paper was rejected, shattering the dream of an easy academia career for the two Google founders. Otherwise, we would probably still be searching with hotbots (remember that?).
The WAND paper was published in CIKM, a lowly conference in some people's eyes, I guess that's not the first venue they tried to publish that work in, because I worked at IBM Research before, I knew for a fact that CIKM was not in the first tier of the venues to publish, definitely not for the IR PIC.
Very interesting. I wonder what have caused this. My wild guess is that this may has something to do with early mistreatment the pioneering IR people received from the wider CS community, because their field was probably considered "soft" and not hard enough. For instance, even today, IR papers are not full of theorems and proofs, unlike some other CS fields, such as database. Their revengeful attitude got passed down to their students, as we can see here. And their reasons for dismissing other people's work are all the same: this is not new, we have done this before. But you have not, because the proof is in the systems you build and the papers you publish.
It does not have to be this way. HCI is even softer, but HCI is the most open field in CS, anyone can publish, you can prove theorems, or you can present user studies, anything goes. Funding? Not a problem. Because it is so open, HCI can work with anyone and on any projects. I remember that my advisor had so much funding, he basically paid me to whatever I wanted when I was in school. I am deeply in gratitude for that openness.
There's the kind of library Lucene wants to be, a configurable library. But there are other libraries do not want that.
In this case, Datalevin is a database system, full-text search is just but a feature, I do not want users to configure full-text search in Datalevin as much as they like in Lucene. I want the default to be good, which Lucene's is not.
If you do not learn this now, your managers who maybe only has an associate degree from a community college, or from a school you look down on, will make you learn that soon enough.
These are not important things. An important thing is to keep an open mind and keep learning, so you are continuously employable. You can congratulate yourself when you are as old as me and can still do new things.
I don't see how this is true for concordance-like searches (Trados-like, which seems to be what the article is concerned with - preferring the documents with all query words present in it, otherwise the documents with the most query words present in it, etc.). This sounds more like description of similarity useful for metric space indices or something like that.
But the catch is that Lucene's default "vector space model" treats each document as a very high-dimensional vector, where the components are the words in the document (scaled using tf-idf). Under this definition, "similarity" reduces to a normalized dot-product of the query vector and the document vector. So in practice, it does roughly what you want: documents that match more query words end up getting more non-zero terms in their similarity score, which leads to a higher ranking.
Plus, your description definitely isn't something I would have been able to divine from the description from the article. Thanks for rephrasing it in comprehensible English.
So, what is a document anyway? Is a file handle just another type of dimension? Or, is a picture on the page part of the page document, or is it its own document?
Humans use arbitrary dimensions to tokenize the document’s bits, so to speak.
My dad could read a book (a big document) in blocks or chunks. In thinking of it that way it become apparent that groups and positions of data may constitute their own document boundaries and that info may be used in both the indexing and search pipelines to build relevance and relatedness.
Forgive me if this is a dumb question, Clojure isn't a language I know at all so it was a little hard to parse the code, I couldn't figure out if there was something that indicated a minimum levenshtein distance threshold for documents, but I feel like only looking at documents which are longer than the search query would also be a reasonable optimization.
> If the problem is too big to be solved by this, you are probably ready for Lucene.
https://www.gnu.org/software/parallel/parallel.html?highligh...
However there is a large space between algorithmic assumptions and what "relevance" actually is to the user. This article may improve, but my feeling is -- both for search and for the article -- that more context is needed.
I have repeated asked you to send the code that does things properly in your mind, and you refused to do so.
So you are just trolling. Please stop hinder the progress of the industry through pointless trolling. Makes some positive contributions instead, and I have pointed out repeatedly how to make a positive contribution in this case. Please do.
You are a university student, I am a seasoned computer scientist, past researcher and professor, I am busying running a startup. This will be the last time I will say this to you: please consider contributing something positive to the world.
It's true that I'm just an university student and you are a scientist, a researcher, a professor, and an enterpreneur, but it doesn't mean that I can't be knowledged as you in very narrow fields. I'm currently running a personal project that uses Lucene since four years ago, with about 8 billion messages and 340 million chats stored in a distributed lucene index, so I'm not the regular troll or a person that just talks without knowing anything. I surely can't critique your T-WAND algorithm, that it seems to be good in your use case, but with all the humilty in the world I can say to have the minimum knowledge required to spot some weird usages of Lucene APIs.
Instead, you keeps giving all kind of excuses. You said you do not have time, but somehow you have time to write long wall of text like this. If you are not trolling, what you are doing then?
I pointed out to you why your suggestions will not make differences, some I have already tried. For example, initializing a query parser only once, but that would crash Lucene. Clearly, you do not know about this, so your knowledge of Lucene is not as good as you think you know.
Fair?