Deliver 'Google quality' search experiences with AI and Cloud

AI is at the heart of Google’s search power and similar capability can now be harnessed for our use, either baked into a search product or integrated as an API.

I see three broad approaches to search today where AI increasingly figures in the platform:

1. Traditional Search

Where it all started. You type in some words and get results back. Facets and autosuggest are common. Technically, this kind of experience typically still works the way it always has; an inverted index to match query keywords to content and ranks the results with a built-in algorithm like BM25. Some element of manual control is available to influence relevancy which can be executed well in the right hands. All search technology still works like this under the hood and many search deployments today are still at this point.

2. AI-enhanced Search:

Traditional Search but with the addition of AI in the form of machine-learning relevancy ranking using custom features, natural language processing (NLP) intent detection and content enrichment (e.g. entity extraction). May include question & answer capability. This should be the target maturity state for all new search deployments today but this level of capability in its full form is still aspirational for many organizations.

3. AI-powered Search (in the Cloud)

Automatic AI-enhanced search. Intelligent by design, only available in the Cloud and inherently based on a machine-learning approach. May add personalized results and support future use-cases automatically. Requires the minimal amount of effort to stand up a platform, AI does the rest. Ingesting the content still requires work but there are/will be accelerators to help the process. Manual control is increasingly less important. A default experience is available but still plenty of scope to customize and create your own.

Every large organization either has one or more Enterprise Search platform(s) or has tried to build one in the last two decades (with many failures). Most search we encounter, particularly legacy deployments, are of type (1). With the right expertise, it is entirely possible to do a good job of creating a Traditional Search solution in this way, delivering good user outcomes and paving the way to move to type (2) maturity.

I hear a lot of people asking about type (2) approaches and we include this as a target state in our Search Maturity Model during search strategy engagements (contact me if you want to know more about this). If you’re not aware of how AI can help enhance search on both the front end and back end check out the capabilities of NLP such as Google’s Cloud Natural Language API and specifically Google’s use of this in their use of and open-sourcing of BERT for intelligent query intent detection. This kind of power can be brought to bear in most search deployments to enrich content and make user interactions more natural.

The other area AI can enhance search is with a learning-to-rank relevancy model. The idea here is that machine learning can be applied to influence a traditional search relevancy model by scoring more highly (for example) those results which are associated with better overall outcomes. How you identify and measure those outcomes is a bigger discussion but suffice to say there is a lot of value to be had here. Moving beyond just a rules-based relevancy model can be a huge step for search.

Other technologies in type (2) such as Knowledge Graphs are increasingly common alongside core search tech. These can further enhance the search experience by capturing and modeling ‘facts’; real-world entities and their inter-relationships. You use one with Google every time to search about a thing; a person, place or concept, and Google gives you an answer. This is a fascinating area, particularly when combined with natural language interactions. If you want to see where Knowledge Graphs may start to support increasingly intelligent search and conversational use-cases I recommend reading this research from Google.

Type (1) or (2) solutions can be built from the ground up or rapidly deployed in the Cloud. Most vendors offering search today either support these kinds of AI-enhanced features out of the box will have them on their roadmap or can be integrated with any of the now democratized AI API’s in the front and back-end code.

Type (2) solutions are where all the search and AI tradecraft live and the tools available to create these are only getting better. If you’re deep into search you’ll have likely been spending most of your time here. Many vendor solutions today are Cloud-ready and this is becoming the norm for type (2). But this is by no means the end of the AI and search story.

A very interesting option appears as you move from type (2) to (3). This is where we start to see how AI and Cloud in-concert can automatically increase the intelligence of the experience through machine learning whilst at the same time reducing the architectural and management effort. Examples are Google’s relatively recent Cloud Search product and Amazon’s release of Kendra last week. Both combine their pre-existing Cloud AI capability and platforms to deliver a new option for Enterprise Search.

What is interesting though is not just where the type (3) capability is today but where it is likely going. New AI-powered intelligence developed by Google and Amazon for their broader Cloud offerings could seamlessly find its way into these new search platforms. I’m very interested in how this will play out. It promises to be the long-tail of search automation through AI.

For now though, the important difference between type(2) and (3) is about the use case and appetite for differentiation through a custom build. Type (2) applies everywhere there is a search box across both enterprise and digital products. It is here that the scope for innovation in search remains huge if you ‘roll-your-own’. Silicon Valley and digital leaders will continue to show us the way when it comes to innovation with AI and Search to improve customer experiences. Check out some of what AirBnB has been doing. In type (2) solutions you can follow this kind of path yourself if the desire to build and own it is there.

Type (3) feels like it is positioned on rapid time-to-value use-cases, specifically for the likes of Enterprise Search. This makes total sense. Whilst the connector framework layer is always going to take time and more silos equals more effort, type (3) leaves a lot of heavy search lifting to the Cloud and AI. Customizing the user experience to meet specific enterprise needs along with good choices for the search/AI configuration options (e.g. schemas) is where organizations will unlock the AI value quickly. We have seen in the past that a single Enterprise Search tool at scale can end up becoming unwieldy and it is better to split into multiple experiences behind a single search box to serve different use-cases. This is achievable but requires a robust search strategy.

All very interesting, then. So is the search over for search? I believe the big trends in the search are now clearer and the kind of differentiation I’m eluding to here will become a clear distinction. Some years back I posited that the future of search will be in the Cloud, that the barrier to entry will be reduced and it will all be supported by unbundled artificial intelligence deployed in this way. It looks like we are well on our way on that journey now but with two kinds of AI; the one you just embrace where it is proven to work well in your use-case and the one you create yourself, either from the ground-up or by standing on the shoulders of the Cloud giants. Either way the future is bright for search and there has never been a better time to move every search box out there closer to that vision to just ‘work like Google’.

Thanks for reading!