ke_search_ai 

Classification

ke_search_ai

Version

Language

en

Copyright

2026

Author

ke_search_ai Dev Team

License

This document is published under the Open Content License

Rendered

Fri, 31 Jul 2026 09:25:59 +0000

The extension ke_search_ai extends the popular TYPO3 search extension ke_search with AI capabilities. It uses RAG (Retrieval-Augmented Generation) to provide users with a concise, AI-generated answer to their search query, placed directly above the traditional search results.

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.

Installation and setup 

vendor/bin/typo3 ke_search_ai:embeddingindex

vendor/bin/typo3 ke_search_ai:embeddingindex status

Configuration 

In the Extension Manager (ke_search_ai), open the category AI-generated results (RAG):

• Enable AI-generated results: Turn the feature on.
• LLM: API URL (default: https://api.mistral.ai/v1/chat/completions), API key, model (default: mistral-small-latest), answer language (e.g. de), max response tokens.
• Embeddings: Embedding API URL (default: https://api.mistral.ai/v1/embeddings), API key, model (default: mistral-embed).
• Retrieval: Top K (number of chunks, e.g. 5–10), minimum similarity score (0–1, default 0.4; 0 = no filtering; typical 0.4–0.6 to exclude irrelevant hits), max characters per chunk.
• Cache: Cache lifetime in seconds for the AI answer per search term (0 = no cache).
• Logging: Log level (default: WARNING). See Debugging.

API keys can be configured in the Extension Settings (Extension Manager → ke_search_ai). For deployment, you may use env:VARIABLE_NAME as the value (e.g. env:MISTRAL_API_KEY) to read from the environment.

YourVendor\YourExtension\EventListener\ModifyAiSystemPrompt:
  tags:
    - name: event.listener
      identifier: 'yourExtensionModifyAiSystemPrompt'
      event: Tpwd\KeSearchAi\AiGeneratedResults\Event\ModifyAiGeneratedSystemPromptEvent

public function __invoke(ModifyAiGeneratedSystemPromptEvent $event): void
{
    $event->setSystemPrompt(
        $event->getSystemPrompt() . ' Only use a maximum of two sentences.'
    );
}

Examples 

AI Overview 

Search with a term to see the AI-generated answer above the result list.

Placeholder during search 

While the answer is being generated (or when it is not yet cached), a skeleton placeholder is shown:

Note

The examples contain information sourced from Wikipedia articles. This content is available under the Creative Commons Attribution-ShareAlike License; additional terms may apply. See Wikipedia's Terms of Use for details. Wikipedia® is a registered trademark of the Wikimedia Foundation, Inc., a non-profit organization.

Caching 

The extension uses two TYPO3 caches to reduce API calls and improve response time:

1. AI-generated answer (cache identifier: kesearchai_results)

   The final text returned by the LLM is cached per search. Each cache entry is identified by a key derived from the search term, the Top K setting, the minimum similarity score setting, and the answer language (e.g. from the current site language). When a user searches with the same term and language and the entry is still valid, the answer is taken from the cache and no embedding or LLM request is made.

   Lifetime is set with Cache in the Extension Manager (aiCacheLifetime, in seconds; default 2592000 = 30 days). Set to 0 to disable this cache.

2. Query and index embeddings (cache identifier: kesearchai_embeddings)

   The same cache is used in two places:

   • At search time: When generating an answer, the search term is converted into a vector via the embedding API. That query vector is cached per search term (and per embedding API URL and model). If the same search term is used again before the cache entry expires, the embedding API is not called and the stored vector is reused for the similarity search.
   • When building the embedding index: The console command ke_search_ai:embeddingindex also uses this cache. For each index entry, the chunk text (title, abstract, content) is hashed and the resulting embedding is stored in the cache. When you run the command again (e.g. with --update), entries whose source text has not changed get their embedding from the cache instead of calling the embedding API. Duplicate or similar content across index entries also benefits from cache hits. The command’s --limit option counts only API calls; cache hits do not count toward the limit.

   Lifetime is configured with Embedding cache lifetime (aiEmbeddingCacheLifetime, default 2592000 seconds = 30 days). This reduces embedding API cost both for repeated search terms and when (re)building the embedding index.

Security 

RAG context and prompt injection

The retrieved index content (title, abstract, content) is passed as context to the LLM. Only index trusted content. If the index contains manipulated or untrusted text (e.g. instructions like “Ignore previous instructions…”), the model may follow them and alter the answer. Treat indexed content as part of the trusted prompt; avoid indexing user-generated or unmoderated content if you cannot accept this risk.

System prompt event

When using ModifyAiGeneratedSystemPromptEvent, do not inject user-controlled or unfiltered input into the system prompt. The system prompt should remain under your control; listeners must only add static or sanitized instructions so that the prompt stays trusted.

Cost Control 

• Caching: Set Caching (e.g. aiCacheLifetime = 2592000 = 30 days) to avoid repeated API calls for the same search term.
• Retrieval: aiTopK and aiMaxCharsPerChunk limit the context size and thus input tokens. aiMaxTokensResponse limits the answer length.
• Embeddings: One embedding call per search; at index time, one call per index entry. Use affordable embedding models (e.g. Mistral mistral-embed).

Debugging 

When the ke_search_ai extension log level is set to DEBUG (Extension Manager → ke_search_ai →

→ Log level), the extension logs detailed information to help analyze the RAG pipeline:

- Retrieval: The search term and the similarity scores of the top-k results (including UID and

title of the indexed records) are logged to help analyze why certain records were chosen as context.

- LLM API: Request (URL, model, max_tokens, system and user prompt; long text is truncated)

and response (answer content, truncated if long). If the API returns token usage (e.g. Mistral, OpenAI), prompt_tokens, completion_tokens and total_tokens are logged to help estimate costs.

- Embedding API: Request (URL, model, input length and a short preview of the text) and

response (number of dimensions). If the API returns token usage, prompt_tokens and total_tokens are logged.

Log entries are written to the file var/log/ke_search_ai.log. API keys are never logged.

By default, the log level is set to WARNING, meaning only errors and warnings are recorded.

Changelog