Overview 

  • AI-generated search results based on RAG (Retrieval-Augmented Generation).
  • Sources list providing transparency for generated answers.
  • No external vector database required (embeddings are stored in the TYPO3 database).
  • Optimized performance through AJAX loading and multi-level caching.
  • Flexible AI provider support (Mistral AI, OpenAI, and other OpenAI-compatible APIs).
  • Privacy-aware: Only uses content from the search index that the user is allowed to see.

ke_search_ai uses a RAG pipeline (Retrieval-Augmented Generation) to show a short AI-generated answer above the normal search result list. It also shows the sources list on which the answer is based.

The normal search result list is shown below and untouched by this feature.

The AI-generated answer is based only on index entries that would appear in a standard search without a search phrase (same restrictions as the result list: starting points, time restrictions, fe_group, filters, language). The retrieval never runs over the full index. If the empty search cannot be executed or returns no results, no AI answer is shown (this avoids exposing group- or time-restricted content). The search service of ke_search is used to determine the allowed index entries (see Installation and setup).

An AI provider is required to create the embeddings and the answer.

An external vector database is not needed, the embeddings are stored in the TYPO3 database. While this reduces external dependencies, it may lead to performance issues with large indexes. This is addressed by loading the AI overview with AJAX to make sure the search result page is displayed as fast as possible.

Workflow 

  1. Data preparation: Index entries from tx_kesearch_index are converted into vectors (embeddings) via an embedding API and stored in the table tx_kesearchai_embeddings. This is done by the console command ke_search_ai:embeddingindex (manually or via Scheduler).
  2. Retrieval: When a user searches, the search term is also converted into a vector. A similarity search (cosine similarity) finds the most relevant stored chunks. The corresponding full text is loaded from the index and passed as context to the LLM.
  3. Generation: An LLM receives the search query and the retrieved excerpts and generates a short answer that is displayed above the result list. Default provider: Mistral AI (OpenAI-compatible API). See Mistral API.

Frontend 

Fluid: The variable resultListAdditionalRawContent is prepended with <div class="kesearch-ai-answer">…</div>, so the answer appears above the result list when the default template is used.

Performance note 

This version stores embeddings in a MySQL table and runs the similarity search in PHP. For very large indexes (e.g. > 10,000 entries), consider using --pid or --limit and plan indexing accordingly. A future extension could support an external vector database.