DONAU Versicherung: AI answers built on ke_search
For DONAU Versicherung, we have built an AI answer feature that is currently running in staging. It uses ke_search results as the basis for an answer generated by Gemini, in an environment configured to meet the project’s data protection requirements.
Retrieval and answer generation have distinct roles here: ke_search finds the content; the AI turns it into an answer. Semantic search changes the earlier step, determining which content is found. An answer feature can therefore work with an existing keyword search engine.
Use real queries to compare the results
Consider someone searching for “Can I pause my subscription?” when the relevant help page is titled “Putting your membership on hold”. A synonym rule could connect these terms. Semantic retrieval is worth considering when people express the same needs in many different ways and maintaining individual rules becomes time-consuming.
We review frequent queries, searches with no results and questions reaching the support team. With the people responsible for the content, we identify the pages that should answer each question. Missing information calls for new content. Where the information exists, we look at titles, synonyms and ranking. Personal details are removed before evaluation or excluded from collection.
We compare approaches using a fixed set of search tasks, measuring how often a relevant page appears in the first three results. We first improve the existing search rules, then compare the hybrid approach against that stronger baseline. Some queries are held back for the final evaluation, rather than used to tune the system.
We also record response times, behaviour under load and running costs. Results are documented alongside the model and version, content collection and hosting setup. The evaluation includes misspellings, different languages and questions the available content cannot answer.
Combine keyword precision with semantic retrieval
An embedding model represents queries and passages as numerical vectors. Similar meanings can then be matched even when the wording differs. We evaluate this using the languages and specialist terminology of the website itself.
Exact matching still matters for product codes, names and contract identifiers. Hybrid search combines keyword and vector results. We tune their weighting against the search tasks. The choice of technology also depends on the existing search engine and hosting environment.
- Solr for an existing TYPO3 integration
- If a site already uses EXT:solr, we first assess whether that integration can be extended. Apache Solr supports vector search, provided the installed version, index schema, model integration and retrieval logic are suitable. A move to another search platform may be unnecessary.
- Typesense and Meilisearch as alternatives
- Both engines support hybrid search and embedding integrations. Connecting them to TYPO3 involves transferring content, keeping it up to date and applying access rules. We compare search quality, integration effort and operational requirements before choosing an engine.
- MariaDB for a custom vector index
- MariaDB introduced a native vector type and vector search in 11.7, with general availability in 11.8 LTS. With a suitable database version and manageable load, this offers a route without a separate vector database service. Embedding generation, retrieval logic and the TYPO3 integration still need implementing; vector storage alone is not a complete search engine.
Keep TYPO3 in charge of publishing
We begin by defining which published pages, records and documents belong in search. Longer texts are split into meaningful passages. Each retains its source, language and URL so a result leads to the relevant page.
We connect index updates to publishing in TYPO3: new content is added, changes are reflected and withdrawn content is removed. Failed updates are retried and flagged. Access rules also apply to snippets, summaries and cached answers. Restricted content is filtered according to the visitor’s permissions before results are returned or passages are passed to a language model.
Run the embedding model and index in your own environment
For insurance companies, customer portals and internal knowledge bases, the location of content and query processing matters. A self-hosted embedding model and index allow retrieval without sending those texts to an external model API. We can set up the components in your infrastructure or with a hosting provider you choose.
EU hosting and the use of an external model service are separate decisions. An EU-hosted search engine that calls an external embedding API still sends text to that provider. We establish data flows, access rules and logging for each component, including any additional language model used to generate answers.
Better results do not require a chatbot
Semantic retrieval can sit behind a familiar results page, with titles, excerpts and filters leading people to the right content. An answer feature adds another step: a language model summarises the retrieved passages.
When building that feature, we link to the sources used and provide a fallback to the results list when the retrieved material is not sufficiently relevant. We test that decision with specialist questions, conflicting statements and gaps in the content. A source link alone does not establish that an answer is correct.
For contract terms and other binding information, the approved original remains authoritative. We work with the responsible teams to assess whether a summary is useful and sufficiently accurate for the task.
We start with real queries to establish which content people cannot find and why. The findings guide the next step: improve content and search rules, add semantic retrieval or generate answers from the results. Each approach is assessed against the same search tasks.
A search review for your TYPO3 website
We review your search queries and searches with no results, ideally covering the past 90 days, alongside the content they should lead to. You receive a prioritised recommendation: which changes to make now and where semantic search is worth testing.
We agree the scope and effort with you before starting. If search data is not yet available, we begin with common questions from your support and editorial teams.