10 ms·
T-Wand: beating Lucene in less than 600 lines of code
- diego 5y agoI'm not sure if this is a troll. It seems the author did not spend much time learning Lucene, it already does everything he needs and better. Of course Lucene does tf-idf! If you are not getting the results you want, you must not be indexing right or must have something misconfigured. Lucene lets you tweak relevance, speed, index space efficiency, etc in a million ways.
- grumpyprole 5y agoPerhaps the OP just wanted a simple custom algorithm that would be easy to integrate? I do not understand why rejecting a million-lines-of-code dependency implies the person is a troll?
- diego 5y agoI meant as in "beating Lucene" without trying to use Lucene properly. It's like trying to use a spoon to cut a steak and then saying that you can beat silverware with your teeth.
- huahaiy 5y agoSend a PR with Lucene properly used. It's an open source project, and I said I welcome any contribution in the article. Please do.
- bryanrasmussen 5y agoI think you are almost be definition trolling when you write beating X (millions lines of code) with 600 lines. 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.
- Cavallium 5y agoThe funny thing is that the benchmarks that he wrote are more problematic than the T-WAND code itself. 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
- deleted 5y ago[deleted]
- codetrotter 5y agoI think the heading is fine. They are beating Lucene in the context of their particular problem. 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.
- huahaiy 5y agoI do not want to tweak Lucene. I don't want a huge dependency. I don't want Lucene. Period. 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?
- galaxyLogic 5y agoThis is part of Datalevin, an interesting open source Datalog database: https://github.com/juji-io/datalevin https://github.com/juji-io/datalevin
- ekzhu 5y agoI cannot continue reading after this following “declaration”… Author should take a look at the Wikipedia page for TF-IDF. > 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).
- rory_isAdonk 5y agoYeah beyond the cringe of thinking a Ph.D really means anything, its just highlights the pure lack of Lucene knowledge.
- speedgoose 5y agoA Ph.D means a lot for many people. It's years of work to make the science progress a tiny little bit on a topic you enjoy (supposedly). I think it's a lot harder and meaningful than writing scalable and reliable code as a team in a software company, just to give one example to compare with.
- tgv 5y agoBut a phd in HCI has very little relevance to information retrieval or computational linguistics.
- johncearls 5y ago
- twhitmore 5y agoInteresting. I can't say Lucene gives great results for relevance on a large database, eg. Confluence. 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.
- fizx 5y agoLucene has the concept of "minimum match," [1] which is what you're playing with. You can implement your algorithm on top of this relatively trivially, by re-querying with min_match=n, min_match=n-1, etc until you get results. If you wrote a Lucene plugin to do this, it would also be small (<600 lines) and fast. 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/current/query-dsl-minimum-should-match.html https://www.elastic.co/guide/en/elasticsearch/reference/curr...
- huahaiy 5y agoThe industry has not "chosen" to not do what T-Wand does, the industry did not have that option because T-Wand just comes out. Now with T-Wand, the industry has that choice to make. It is easy to implement T-Wand in the existing Lucene code base, and I would hope so. Otherwise, it would be a shame.
- jhgb 5y ago> Most search engines use something called a vector space model, where both user queries and documents are reduced to vectors (i.e. a fixed number of numbers). That is to say, the search engines are not looking at the meanings of the queries or the documents. Instead, they turned them both into some numbers. The search problem, is reduced to a problem of finding the similarity between the numbers representing the query and the numbers representing the documents. 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.
- teraflop 5y agoTechnically the author's description of how Lucene's ranking works is accurate. 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.
- jhgb 5y agoHmm. I'll have to think about it but I don't quite see yet how this ensures that for example all documents containing all four words of a four-word query will be ranked ahead of documents containing three or fewer words of the query. Mere angle between two vectors would for example mean that a "document" consisting of three words of the query could be ranked higher than a document with thousands of words containing all four words of a query, even if the document vectors had tf-idf weighs as components. That clearly is a viable notion of similarity, but that's also clearly not what the type of search alluded to in the article is attempting to do. 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.
- ot 5y agoThe author deeply misunderstands how WAND works, and "T-WAND" is just WAND. Once a pivot is found, you don't have to advance all the iterators that precede it, but just enough to disprove the current document, at which point a new pivot is chosen (this is equivalent to the heuristic described in the article). 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).
- huahaiy 5y agoFeeling smug? 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.
- Cavallium 5y agoThe benchmarks in question have several implementation issues, I reported them on GitHub. https://github.com/juji-io/datalevin/issues/created_by/cavallium https://github.com/juji-io/datalevin/issues/created_by/caval...
- huahaiy 5y agoI would appreciate if you also send a PR to address these issues, since clearly you know more about benchmarking than me. 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?
- Cavallium 5y agoI never had the interest to "talk down Datalevin", I criticized the results because the title was quite misleading in the tones and the benchmarks were not rigorous enough to express conclusive statements.
- huahaiy 5y agoIt's a personal blog post. If the title is not "misleading", which it is not, you would not see it, would you?
- ysleepy 5y agoThe tone of the article makes it incredibly annoying and the author 100% lands on the hall of shame list of ridiculous benchmarks he mentioned. 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.
- huahaiy 5y agoIt would really be a sad joke if one dismisses a good technology just because he does not like the tone of the author of the said technology. 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?
- Lapsa 5y agoGiven I'm quite a newb at this field - found article interesting despite having (probably deserved) criticism.
- antocv 5y agoThe critics are all Lucene developers or deeply invested in that. The criticism boils down to well "Simply just know Lucene and handle the million lines of code by writing plugins and configurations to get the same result as OP", except with worse performance.
- Cavallium 5y agoThat's not true. The real problem is that he is implying that his software is faster than Lucene showing data from a benchmark that has substantial flaws. The reason why the majority of criticism comes from Lucene users is because they generally have a higher knownledge about this field than the people that read this article without having the basic knowledge to form any kind of criticism
- huahaiy 5y agoIncorrect. The benchmark is fine. Your so-called "fundamental" flaws are just superficial things, such as using a different time measure, using a different benchmark library, passing in a thread pool, and so on. These are immaterial for relative comparison, unless proven otherwise. 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.
- Cavallium 5y agoI already explained to you why I didn't open more than one PR to the project, I'm not trolling anyone: without knowing Clojure the only contribution that I could do without spending literally days of work is just the use of System.nanoTime() instead of System.currentTimeMillis(). The reason why I don't write the other benchmarks in Java is because reimplementing anything from zero costs precious time, that I don't have. If you don't have time too, instead of closing the issues and calling me a troll, you can just say that; you are taking some valid critiques as a personal attack. 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.
- gajus 5y agoRelated, I recently published https://github.com/gajus/liqe https://github.com/gajus/liqe, although not 600 lines of code
- lsiebert 5y agoSo if someone created a document consisting of just these search terms (and nothing else) in the search order, that's always going to be the highest ranked item, right, despite a lack of any added information, right? 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.
- huahaiy 5y agoCorrect. That is also what all search engines will currently do.
- ptspts 5y agoAs a user, when I write a search query as a space-separated list of n words, I expect to see documents which contain all of those words (or synonyms). I absolutely don't want to see documents which contain only n-1 of the specified words. I know exactly what I want, and the reason I've added the last word to the query is that there were too many generic, boring, irrelevant results without it.
- Cavallium 5y agoYou completely misunderstood what this project does. This kind of libraries do not force you to return results in a specific way. Generally they allow the programmer to customize how the results are scored and chosen.
- huahaiy 5y agoI don't think he misunderstood anything. 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.
- ibejoeb 5y agoTangential, but it reminds me of GNU parallel's man page example one-liner for regex-matching giant texts, which goes on to say: > 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?highlight=lucene#limiting-factor-cpu https://www.gnu.org/software/parallel/parallel.html?highligh...
- kordlessagain 5y agoEvery single document “page” humans index has three “interesting” dimensions: the height and width of the page the words appear on, plus another for the font size. 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.
- huahaiy 5y agoI would appreciate people who claims that "the author does not know Lucene enough" to send a Pull Request, where Lucene is configured to do the same thing that T-Wand does, that is to guarantee documents containing more query terms to rank higher than those containing less query terms. 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.
- Cavallium 5y agoI opened a PR to use the more precise timers. This would not improve the performance of any of the tests, but it will improve their time accuracy. 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.
- huahaiy 5y agoMerged your PR. Thank you! If you do not know Clojure, that's fine, just outline what you want to do in Java, I can translate that into Clojure. Thanks. 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.
- 5y ago
- huahaiy 5y agoFor what its worth, a final advise for those fresh graduates and college students. Don't take too seriously what your learned from books in school. They are not the gold standard the society measures things by. You got the wrong impression if you think your professors taught you that. They knew better. Don't take too much pride in your degree or in your specializations. They are nothing. 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.
- huahaiy 5y agoOne observation I have to make: this community of information retrieval seems to be very thin-faced and cannot seem to accept outside contributions. I hope I am wrong. 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.