Comment by marginalia_nu | Hacker News Reader

Comment by marginalia_nu | Hacker News Reader

Parent Full thread

Feels like there's a pretty widespread problem that goes something like this:

* PO: We need search!

* PM to architect: Google how to implement search!

* Architect: googles "best search library 2023 java" Aha! Let's use Elasticsearch!

* PM to Team: Alright, I need a search feature next sprint. Architect googled for 5 minutes and says we should use elasticsearch!

* Team: Alright, integrating elasticsearch in a sprint should work. Bob, you work on loading the data, Eve, you work on rendering the search results.

* Team (2-3 weeks later): Another successful value delivery! Alright, what's next PM?

* PM: PO says we need a chat bot...

If it's not obvious why this is a problem, getting search to work well requires a lot of tweaking and tuning. You can't just slap a search engine into a product and expect it to work well. It's hilariously incompatible with the assembly line style of work that many software outfits employ these days. It also requires deep understanding of what a search engine does and how its algorithms work.

It's more about what the company considers core business and what not. Most often they don't see the website as being important enough to the business so they don't invest in it.

We have gotten used to almost flawless experiences from amazon shopping. Google search finds (or used to) results sometimes almost like magic, etc. The thing is, that's the core business. These companies invent new technologies and have huge teams because doing this is so hard.

Now take a random supermarket chain. Their knowledge is about physical stores. Their core business has taught them where to open a store and how to arrange things in it so that they maximize their sales in that environment. It's very hard and it takes a very long time to shift to an online model. You have to find people with the right competencies and the right leadership to convince the company to do this and this is actually very hard to do.

Look at the categories example. That, to me, screams backend database. The company has invested a lot of money into building business intelligence on top of their physical stores. That organization screams "perfectly curated data warehouse" and I imagine suggesting something like "we need to reorganize the way we store data" is going to be met with blank stares if not full on outrage.

> almost flawless experiences from amazon shopping

In my opinion its too fuzzy, which is usually the opposite problem I have with website searches (e.g. searching a news site for keywords of an article I know exits, but it's taking me too literally)

If I search for "iPhone 14 Pro case", I don't want to see cases for iPhone 15 __, or non-pro models. I've (to my own fault) bought way too many of the wrong product because I search for a specific model and don't read the title before ordering, only to realize that Amazon didn't give me exactly what I typed in.

> flawless experiences from amazon shopping

what kind of stiff are you buying you call this "flawless"? In my experience the Amazon search is worst there is. Search for "AAA batteries" and it will offer you AA and even N ones. Why on earth would anyone want that?

They even got the basics wrong. The other day I was searching for power bank under $5. Instead, many listings was $10+. How hard is it to get this right?

Because of horrible search quality I actively avoid Amazon when I can.

> almost flawless experiences from amazon shopping

It's pretty good, but there are some longtime flaws that blow my mind, such as the order of results when sorting by price. It never makes sense to me.

I think order by price might be ordering by the lowest available price at time of index. This could be an out of date price if the index isn't updated when other pricing is updated. It almost certainly doesn't include shipping, as that can vary depending on where the item is and where you are so it can't be indexed. Filtering by seller doesn't change the sorting, in my experience, and I think neither does filtering by condition.

So, if someone is selling a used item in poor condition with maximum shipping, that product is going to sort as a low priced item.

At least, that's my reverse engineered understanding.

There are actually plenty of non-ES products that are way easier to integrate and tune (and get better results with less effort).

- Typesense (https://github.com/typesense/typesense)

- Algolia

- Google Programmable Search Engine (https://programmablesearchengine.google.com/about/)

Intellectually, I knew this was common but I never stopped to consider how fortunate I am to work for a company who understands things like search are difficult.

It helps we have two internal departments whose primary jobs are data management and analysis. (Real statistics, not “AI”.)

A big reason why is Search today is an AI Librarian. That AI may be more or less smart, but at the end of the result that's what people mean when they say Search. They certainly do not mean a robust query language that will allow them to iteratively refine down a subset of matching documents in a corpus until the desired document is found.

I think if you remove the cariacature that approach isn't terrible, assuming there's no more suitable technology. Why not have a basic search and iterate, including iterating the technology choice. You can hide it behind a feature flag if you don't think it's ready.

The problem is that the sort of stuff you need to tune a search engine to actually perform well doesn't look like work. It simply can't be broken down into deliveries that provide incremental business value, and throughout the entire process it's going to look like a bunch of fiddling with numbers with nothing to show for it.

Does any product feature that requires care and maintenance easily fit the model of delivering incremental value?

But for a search engine, showing incremental value should be easy if you have a real product reason to do it. If you expect search to help people find content, then you look at statistics on engagement --- in aggregate did people use search, does it look like they found what they wanted, did they return and use search again. In specific, which queries seem popular and provide good results, which queries seem popular and don't provide good results. You provide incremental value by moving queries from the second to the first category, where possible. If you can kind of classify some of the less popular queries, there's value in improving results for those too, but classification is also hard.

Sometimes the numbers are easy... I participated in an application of search where a support request hit the FAQ before submission --- if search works, there should be fewer tickets and especially fewer tickets where the user can easily solve their own problem. Search in a shopping context should lead to more sales. Etc.

I think you may miss how many technology projects fail in companies. A company may have no internal knowledge or skill to make search better, so they get an outside contracting group that produces a shitty product that doesn't improve sales and costs an extraordinary amount for the lack of results.

Quite often the company won't make any more in those long tail sales, but instead better placement of the products they buy in mass.

Reply on news.ycombinator.com