7 posts tagged with "Semantic Search"

Open your analytics and look at what people type into your AEM site's search box. Not the page views: the queries. It's the only place on your site where visitors tell you, in their own words and unprompted, what they came for.

Now look at what you give them back: ten blue links, ranked by whether their words happened to appear in your authors' words. If they used a synonym, a typo, or a full sentence, they got nothing, and then they left, and no one filed a ticket about it.

That gap is the subject of the page we just published: turing.viglet.org/aem-search: AEM search, reimagined with AI, without the ceiling. This post is the longer version: not the feature list, but what actually becomes possible on an AEM site when search stops matching strings and starts understanding questions.

Retrieval-Augmented Generation (RAG) is only as good as what it retrieves. If the retrieval layer is a throwaway vector index built for one chatbot, you end up rebuilding it for every new use case. The better pattern: make your enterprise search index the retrieval layer, and expose it to AI through the Model Context Protocol (MCP) so any agent can use it as a tool.

That's what Viglet Turing does: your indexed Adobe AEM, WordPress, database, and file content becomes both a search experience and a grounded RAG/agent capability, on your own infrastructure.

Once your Adobe Experience Manager content is indexed into an enterprise search engine, the obvious next step is to move beyond keyword matching. A visitor who searches "places to stay near the mountains" should find a page titled "Alpine lodges and cabins", even though none of those words match. That's semantic search, and it's powered by embeddings.

This post builds on indexing AEM into Viglet Turing and shows how to add vector/semantic search and RAG on top, all open source, on your own infrastructure.

For the overview of AEM search with Viglet Turing, with a live demo, see turing.viglet.org/aem-search.

"Should we use Solr or Elasticsearch?" is one of the most common engineering questions when a search project starts. It's also slightly the wrong question. Solr and Elasticsearch are search engines: they index and rank documents. What most teams actually need is an enterprise search platform: connectors, facets, multi-language, semantic search, RAG, and an admin UI on top of that engine.

That's the distinction this post draws, and where Viglet Turing fits, because it's not a competitor to Solr/Elasticsearch. It runs on them.

Coveo is fully managed SaaS with strong ML relevance out of the box, priced per query or seat, and your index lives in Coveo's cloud. Lucidworks Fusion is a licensed, Solr-based platform you can run inside your own perimeter, with more pipeline control and more infrastructure to operate.

That is the short answer. If you run a large content portal (intranet, knowledge base, support site, or a public site on Adobe AEM), the sections below compare the two on pricing, data residency, connectors, semantic search and RAG, and add the open-source option, Viglet Turing, for teams that want neither a per-query bill nor a license.

We covered the open-source alternatives to Algolia and Coveo for AEM broadly; this one zooms into the enterprise-portal end of the market.

WordPress ships with a built-in search that runs a LIKE query against the posts table. It works for a handful of posts, but on a real content site it has no relevance ranking, no facets, no typo tolerance, no autocomplete, and it slows down as your database grows. Most teams reach for a SaaS layer (Algolia, ElasticPress + hosted Elasticsearch) and start paying per record and per query.

This guide shows the open-source alternative: indexing WordPress into Viglet Turing, an Apache-2.0 enterprise search platform you self-host, with faceted search, semantic navigation, and generative AI (RAG), and your content staying on your own infrastructure.

Adobe Experience Manager (AEM) ships with Oak/Lucene indexing that is excellent for authoring and repository operations, but it was never meant to power a public-facing search experience: faceted navigation, autocomplete, relevance tuning, multi-language sites, and increasingly, conversational (RAG) answers over your content.

Most teams reach for a SaaS layer (Algolia, Coveo, or Lucidworks) and pay per document and per query, while their content leaves their infrastructure. This guide shows the open-source alternative: indexing AEM into Viglet Turing, an Apache-2.0 enterprise search platform you self-host, with semantic navigation and generative AI built in.

For what AEM search with Viglet Turing looks like on a live site, start at turing.viglet.org/aem-search; this guide is the how-to behind it.