Enterprise Search: Setting Up Your Own Enterprise Search

A colleague is looking for the quote that was sent to a client three months ago. She types “Maintenance Contract Quote” into the search field and gets: nothing. Yet the document is in the system. It is just titled “Hosting Service Level Agreement.” Different words, same thing, no results.

Almost every company is familiar with this scenario. It highlights two factors that are crucial for a good enterprise search: are the relevant sources even searchable, and does the search method match the query?

An enterprise search system searches various data sources across the entire company, from PDFs in the document repository to the wiki and line-of-business systems. There are various types of searches.

Full-text search is the classic method. It creates an index of all words and finds documents that contain the search terms. This type of search is fast and precise for exact terms such as product numbers, error codes, or proper nouns. Fuzzy search can also account for typos and alternative spellings, so that “Wartunsgvertrag” will still find “Wartungsvertrag.” Its weakness: it compares character strings and is blind to anything phrased differently.

Semantic search is all about the meaning behind the words. Texts are translated into numerical sequences (embeddings) using an AI model and vector technology, which represent their meaning. “Maintenance Contract Offer” and “Hosting Service Level Agreement” then appear close to each other, even though they don’t share a single word. This solves exactly the problem described in the introduction. However, semantic doesn’t automatically mean better: where an exact term is crucial, such as a file number or an error code, purely semantic search often falls short.

Hybrid search combines the results from keyword and semantic searches into a single list, thereby capturing both the exact product number and the relevant query. That is why we choose this option for most projects. It offers the best compromise. We describe in detail how we technically merge the two result lists in our wiki entry on hybrid search.

If you want to go a step further, you can add a language model on top. Instead of simply listing documents, this model formulates a response and cites the sources. This pattern is called RAG (Retrieval Augmented Generation). Technically, the language model often invokes the search via a function call, using it as a tool to retrieve the correct information before responding. This ensures that the language model’s responses remain tied to the actual company documents. Through Natural Language Understanding, the system can also interpret entire questions in everyday language rather than just individual keywords. Conversational search additionally enables a dialogue in which users can ask follow-up questions and clarify their queries, similar to a chat. Both features are particularly helpful for people who don’t think in terms of search terms.

Setting up your own enterprise search system may seem like a lot of work, but it can be done in manageable steps. The typical process looks like this:

Step 1: Create the data foundation and connect sources

The relevant sources must be connected, including document repositories, wikis, line-of-business systems, and, as needed, email programs or CRMs. Most systems offer interfaces or connectors for this purpose, allowing content to be imported automatically and on a regular basis. The challenge here is to format the various file formats and data types so that the search engine can find them.
One thing is worth doing right from the start: cleaning up. Outdated documents, duplicate entries, and inconsistent naming conventions reduce the quality of search results. A search is only as good as the content it searches through.

The type of search best suited for a given use case depends on what and how you want to search; for guidance, you can review the search types explained earlier in this article. Because full-text search and semantic search each have their own distinct strengths, they are usually combined into a hybrid search. We use this type of search in most of our projects.

The technology you choose depends on the volume of data, your team, and your desired operational overhead. There are specialized search technologies such as Elasticsearch, Opensearch, or Meilisearch, but often the search can also be built on top of a database that’s already running, such as PostgreSQL. This saves on costs and infrastructure and aligns with the principle of starting small.

Once the search function has been fully implemented, there is still an optimization phase with many variables to adjust: How many results should be displayed? What types of results? How should they be sorted? And in a hybrid search, how heavily should the full-text results be weighted compared to the semantic results? These adjustments determine whether the search is perceived as good in everyday use.

To ensure that adjustments aren’t made based on gut feeling, there are two key metrics.

• Precision measures accuracy: How many of the displayed results are actually relevant?
• Recall measures completeness: How many of the relevant documents did the search actually find?

These two metrics are often in conflict with one another. If more results are displayed, recall increases, but precision decreases because there are more irrelevant results. The right balance depends on the specific use case. In practice, you set up a test set for this purpose: a collection of typical search queries along with their expected results. This allows you to measure, after every change, whether the search has improved or deteriorated. Test, measure, and fine-tune, not just once, but as an integral part of operations. After all, new data sources, updated content, and evolving requirements must be continuously taken into account.

An enterprise search system accesses potentially sensitive data, so security must be considered from the very beginning, not just at the end.

A well-defined authorization concept is essential. The search should only show a user results for documents that they are authorized to access. Existing access rights must therefore be integrated into the search; otherwise, the search field becomes a data leak.

A second fundamental decision is whether to use on-premises or cloud solutions. Those who keep data in their own data center or with a hosting provider in Germany retain full data sovereignty and significantly increase data security. This becomes particularly relevant as soon as a language model comes into play: It should be clear where the data flows for processing. Language models can now also be operated entirely on-premises, so that no data leaves the company. A GDPR-compliant and data-secure solution that keeps AI processing on European infrastructure or directly in-house is the decisive factor for many companies.

There is no one-size-fits-all solution; what matters is that the solution fits your data, your team, and your security requirements, not that it offers the most features. If you start small with your most important data sources, integrate them seamlessly, and measure results consistently, you’ll quickly have a search solution that finally finds what’s already available within your company.