Live data from Hacker News

What every software engineer should know about search

medium.com

51–57 of 57 posts

Re: What every software engineer should know about search

#51

Earlier quoted context omitted.

Cross between an RSS-reader and a search engine - it lets you subscribe to a topic instead of a site, so that you don't have to manage hundreds of subscriptions, and if a new discussion pops up somewhere on the web that's relevant to your interests, it'll find it and let you know. As forums get boring or off-topic and new ones spring up, it adjusts automatically, so you don't need to do the "Does anyone know of other…

Ah, so something like ElasticSearch percolater queries but applied to the web.

Yep, pretty much. The percolater queries are fairly handy in this instance, and one of the things we didn't really have at Google.

Re: What every software engineer should know about search

#52

Earlier quoted context omitted.

Ah, so something like ElasticSearch percolater queries but applied to the web.

Yep, pretty much. The percolater queries are fairly handy in this instance, and one of the things we didn't really have at Google.

I just read https://stackoverflow.com/questions/21536599/what-does-perco..., and was strongly reminded of Google Wave's "search for documents that haven't been created yet, and they show up when they appear" functionality.

Without trying to get too much off track, I gotta say that it would be so nice to be able to use the original theme data used in Wave (very obviously sans branding). Wave In A Box is... blech, in terms of design, I have to admit.

Re: What every software engineer should know about search

#53
post #49

Earlier quoted context omitted.

Google News topic search has an RSS. How is your product better ?

Google News concentrates mostly on news sites, which have an economic incentive to generate content that emotionally grabs you and spreads virally (i.e. clickbait). I get the sense that people are getting fairly outraged at all the outrage in the MSM & popular blog-based sites - I know I am - and are fatiguing of that. I'm concentrating on forums, blogs, and other user-generated content, which has no economic incenti…

> But the beauty of computers is that we can match content up to precisely the users that care about it.

In theory. I often wonder about pathologically impossible-to-query statistics like "who is snoring the loudest right now?" "show me a global map of everyone waking up right now (and a graph tracking how many people are waking up per second); and provide a second-to-second pinpoint of the person who feels the most refreshed." "what is the single most relevant set of webpages for this highly obscure, domain-specific query?" etc.

Heh, it sometimes takes me actual effort to calm myself down about the fact that, beyond a certain threshold, we literally cannot collect enough entropy (data) to direct a database to the most relevant results - and that we similarly won't connect users to the data they're most interested in, beyond that point.

I do totally get what you mean though.

Re: What every software engineer should know about search

#54
post #49

Earlier quoted context omitted.

Google News topic search has an RSS. How is your product better ?

Google News concentrates mostly on news sites, which have an economic incentive to generate content that emotionally grabs you and spreads virally (i.e. clickbait). I get the sense that people are getting fairly outraged at all the outrage in the MSM & popular blog-based sites - I know I am - and are fatiguing of that. I'm concentrating on forums, blogs, and other user-generated content, which has no economic incenti…

Very interesting. Indeed, Google News is silent on english-content on Factorio. But then how is your product better at finding specific forums ? Furthermore, why wouldn't I just add this particular forum's RSS to my reader?

Re: What every software engineer should know about search

#55
I have some experience in developing IR/search software ( https://github.com/phaistos-networks/Trinity ) and, the way I see it, it all comes down to accepting the following premises:

- It’s all about the relevance models. Specifically, BM25 and TF-IDF which are widely used by e.g Lucene and variants just won’t do. Specifically, they only word for large enough documents anyway.

- Indexing and Search algorithms and practices haven’t changed much in decades (though some novel ideas have been introduced not long ago). Lucene’s index encoding is compact and facilitates fast access, but even compared to the one made available by Google which is arguable simpler in design, doesn’t result in more than around 5% reduction in index size and postings list access time (according to my measurements that is). Posting lists intersections, unions and other such operations implementations are pretty much common across IR systems as well, with little room for improvement.

To get great results, you need really great relevance models(1), a great query rewrite system(2), and, because query rewrites usually expand a query to include multiple disjunctions (OR terms and phrases), your search engine needs to be particularly efficient at handling those(3).

You also need to care for spelling suggestions and personalisation/content biases and factors, but those are secondary concerns.

Re: What every software engineer should know about search

#56
post #26

Earlier quoted context omitted.

Separate out the concepts of "search infrastructure" (how documents and posting lists are stored in terms of bits on disk & RAM) and "ranking functions" (how queries are matched to documents). The former is basically a solved problem. Lucene/ElasticSearch and Google are using basically the same techniques, and you can read about them in Managing Gigabytes [1], which was first published over 2 decades ago. Google may…

> The former is basically a solved problem. That's a bit of a stretch :) The high-level architecture is quite mature and stable, but there's still a lot of research, both in academia and industry, on the data structures to represent indexes, on query execution (see all the work on top-k retrieval), and distributed search systems (for example query-dependent load balancing, novel sharding methods).

It's true that different index codecs are being designed with different tradeoffs (index size vs postings lists access time and cost), but the work is very incremental IMHO, no huge advances to speak of. Also, can you talk about the top-k challenges you mentioned? Priority queues are not optimal enough ?

Re: What every software engineer should know about search

#57

Earlier quoted context omitted.

what does your startup do?

Cross between an RSS-reader and a search engine - it lets you subscribe to a topic instead of a site, so that you don't have to manage hundreds of subscriptions, and if a new discussion pops up somewhere on the web that's relevant to your interests, it'll find it and let you know. As forums get boring or off-topic and new ones spring up, it adjusts automatically, so you don't need to do the "Does anyone know of other…

Are you considering adding sentiment analysis/clustering as one feature? You know, to let people read about different opinions, most often, they only need to read one post in each cluster.
Post reply on HN