Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: Preference? Keyword Search or Semantic Search
22 points by ptrenko 5 days ago | hide | past | web | favorite | 14 comments
I'm thinking about self-service portals on websites here.

When you search in a help desk or a knowledge base, which gives the best results according to you?

Do you prefer something that is keyword + synonym like Algolia, or something that works kind of like Google (semantic understanding)?






Keyword search, if it goes poorly, just feels like I need to work harder to find the right keyword, not an actual failure of the system. Whereas when semantic search goes bad, it is infuriating and entirely the fault of the computer (especially when I've given it the precise word I need it to look for and the computer "thinks" it "knows better")

...or at least that's how the medium-to-savvy users will tend to feel about it. In making your decisions you need to think not just about what users think/say they want, but also how they'll react to the system's failure modes.


That's what we've noticed in our user trials of our system. There's nothing a user can do to make it work.

For self-service style portals I highly prefer a mix of keyword based search and good overall navigation, on this class of sites I usually know what I'm looking for and - at least from experience - common implementations of automatically induced semantic searches just seems to add noise without actually getting me closer to what I'm looking for.

Please note that my viewpoint is largely inspired by technical queries as opposed to generalized search though. In theory I'd love a mix of both with priority on keyword results under the presumption that semantic metadata is mostly curated by humans.


Hmm. I'm thinking about a feature which could re-use a customer service rep's email reply as solutions in a DB.

Of-course the sensitive info could be blacked out or the rep could willfully not add it to the solutions DB.


Semantic based search systems are really great at finding the original intent behind queries. Not everybody is good at finding the right keywords to express their ideas or intent. In such a scenario, semantic meaning based querying rewriting helps a lot.

However, semantic search is a hard machine learning problem and it requires a good volume of search queries so that they can be mapped to the results returned and mine for patterns.

What's the middle ground? You can show a machine learning based "related searches" as a hint in the sidebar. That way, you can help the user construct their search phrases.

Shamless plug: if you like Algolia but would like to host the search engine yourself and don't want to manage Elasticsearch, take a look at Typesense: https://github.com/typesense/typesense


Keyword is simpler to implement and should be fine, but be sure to follow up at least the head queries to make sure they're getting to the right content. Things like tracking the query through to the eventual contact page, so your support reps can inform your search index; ex people who search for X need the info on faq page Y. It's a waste of your customers' time and your reps' time when the customer gave you a good enough search term, and you didn't give them the information they could have used to fix their problem without opening a ticket.

What do you think about reusing ticket info? Like a feature where a rep can optionally add a BCC email ID while replying to a client that saves the response to the search database. Can help increase content without disturbing the workflow?

Private info like name, email Credit cards, pins can be blacked out.


In cases where I have a very specific error code or issue I'm looking into I prefer keyword based search, but in most situations where my search is broad or I am not exactly sure what is causing an error, semantic search gets me to an answer quicker.

Although between the two, I think I use keyword searching more an a regular basis. Even in semantic search engines, I tend to use a lot of quotes to get some keyword based results.


I prefer using a real search engine to get me the keywords to search for. Then I can find exactly what I want in the keywordsearch. With a sematic search engine on a small ammount of data I mostly find nothing or everything and have to scan through a lot of pages to maybe find what I'm searching.

I prefer a semantic-guided keyword search. The query itself is keyword based, but having semantic based suggestions can help fill in some keywords I'm missing. It's as resource intensive as a regular semantic search, bridges the knowledge gap for users who can't fully describe their query, but gives full power to those in the know. Best of both worlds.

Keyword search I find works good. Semantic search, if implemented at all, should be an optional feature with special syntax for describing the semantics, rather than trying to interpret arbitrary text and then it won't work.

I absolutely prefer keyword search. Semantic results are nothing but infuriating, particularly when I'm searching for something specific and the engine substitutes my query for something interpreted.

Google started out w/ algolia-style and then gradually added in semantic over time, you need large datasets for good quality semantic search

I prefer semantic, but it needs to be good semantic search. If it's done badly, the semantic results can sometimes be rather noisy. With keywords, the onus is on the user to know what to ask for (but you can't always count on that being the case).



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: