XWiki AI Setup: LLM Application with a Local Model and RAG

XWiki with AI search across your own content? WZ-IT operates XWiki and sets up the LLM Application with a model on your own hardware or a managed GPU server, see XWiki managed hosting and AI solutions. Schedule a meeting

XWiki ships without AI. Anyone who wants a chat with source references, writing assistance in the editor or semantic search across their own pages installs the LLM Application from the xwiki-contrib project together with the Index for the LLM Application. Combined, they form a RAG system inside XWiki: pages are split into chunks, stored as vectors in Solr and passed to the language model as context with every question.

Step-by-step guides are scarce, and the official extension page lists partly outdated requirements. This article describes the state of version 0.10, released on 18 September 2026: requirements, installation, connecting Ollama or vLLM, indexing, access rights and the limits of the extension. All configuration steps follow the documentation on extensions.xwiki.org and the source code on GitHub. As of September 2026.

Table of contents

1. What the LLM Application is
2. Versions and requirements
3. Architecture: where model, index and rights live
4. Installation via the Extension Manager
5. Connecting a local model: Ollama and vLLM
6. Indexing wiki content: collections and RAG
7. Access rights: what the chat may see
8. MCP server and external integration
9. Limits and known issues
10. Our approach at WZ-IT
11. Further guides

What the LLM Application is

The "LLM" project bundles several extensions that share one version number (LLM project page). Its developers include Ludovic Dubost and Michael Hamann, and parts of the indexing work were funded by NGI Search as part of the WAISE project (WAISE proposal).

Install counts according to extensions.xwiki.org, as of September 2026. All extensions are licensed under the GNU Lesser General Public License 2.1 and marked as BETA. The documentation says so plainly: unexpected behaviour can occur.

The features of the LLM Application at a glance:

• Chat with a choice between the approved models, plus temperature and system prompt in the advanced settings.
• Quick tasks from a prompt database, for example summarising or translating. Custom prompts can be created with title, system and user prompt and temperature.
• Insert into the page: answers can be inserted at the cursor position in the editor or copied to the clipboard.
• Context from the index, as soon as the Index for the LLM Application is installed and at least one collection is assigned to a model.

Versions and requirements

Recent releases according to the LLMAI Jira project and the tags in the GitHub repository:

Anyone running 0.8 or 0.9 with several wikis in a farm should upgrade to 0.10 because of LLMAI-164.

The "16.2.0 and above" compatibility note on the LLM Application page is outdated for current versions. The README is authoritative with "Minimal XWiki version supported: XWiki 17.4.0". An installation on XWiki 16.x therefore needs a platform upgrade before AI can be introduced.

Architecture: where model, index and rights live

The LLM Application is a mediation layer. XWiki does not run chat models itself; it forwards requests to an inference server and exposes its own OpenAI-compatible REST API for that purpose (/rest/wikis/<wiki>/aiLLM/v1/chat/completions and /v1/models).

Three details from the version 0.10 source code matter for planning (application-ai-llm on GitHub):

1. Fixed vector length. The Solr core creates the vector field with 1,024 dimensions. Embeddings are brought to exactly this length before storage: longer ones are truncated, shorter ones padded with zeros. A model with 1,024 dimensions fits without loss.
2. Hybrid search without reranking. Since 0.7, vector search and keyword search run side by side. The results are concatenated and duplicate chunks removed, without a combined ranking and without a reranker. How this differs from Reciprocal Rank Fusion and cross-encoders is explained in the article on hybrid search and reranking.
3. Rights after the search. The rights check filters the chunks already retrieved. If many hits are removed, the model receives correspondingly less context.

Installation via the Extension Manager

Installation follows the usual XWiki route (LLM Application, Prerequisites & Installation Instructions):

1. Sign in with an account that has administration rights.
2. Search for "LLM Application" in the Extension Manager and install it. Dependencies such as the LLM Models API and the Chat WebJar are installed along with it.
3. For RAG, also install "Index for the LLM Application".
4. Only if embeddings are to be computed inside the XWiki process: install "LLM Internal Inference Server".
5. Restart XWiki. Without a restart the model list stays empty; this is the known bug XWIKI-21887, still open in September 2026.

The Extension Manager does not work without internet access on the XWiki server. The alternative is the manual route: download the XAR file, import it via Administration and Import, and install every dependent extension separately. For installations in isolated networks this is a separate task that recurs with every update.

After installation, "LLM Application" appears in the applications panel. In the editor, a toolbar button opens the chat. The button uses the same icon as "Paste"; according to the documentation there is no dedicated icon yet.

Connecting a local model: Ollama and vLLM

Configuration has two levels: servers and models. A server describes the endpoint, a model is the concrete approval for users.

Create a server (Administration, LLM Application configuration):

Typical URL prefix values:

The most common mistake with Ollama is the missing /v1/. Ollama serves its OpenAI-compatible API under /v1/, not at the root path (XWiki forum). The inference server has to be reachable from the XWiki server, not from the users' browsers: all requests go through XWiki.

Create models (below the chat in the LLM Application):

The LLM Application does not import models from the server automatically. This is intentional: admins should only offer approved models and be able to provide the same model with different collections under different names (XWiki forum). Descriptive names such as "IT handbook, with sources" work better than the technical model ID.

Which inference server fits depends on user count and hardware. Ollama suits getting started, vLLM suits many parallel requests; the comparison is in the article vLLM, Ollama or llama.cpp. How much GPU memory a model needs is covered in the article on VRAM sizing.

Indexing wiki content: collections and RAG

A collection is a bounded knowledge area with its own embedding model, chunking parameters and rights check (Index for the LLM Application). Admins find the link to the collections overview at the bottom of the LLM Application.

Chunking. The maxChars method searches within the maximum length for a heading, an empty line, a line break, a sentence end and a space, in that order, and splits at the first suitable point. A chunk can shrink to half the maximum size in the process. Which sizes work for German text with long sentences and tables is covered in the article on chunking strategies. The indexed chunks can be reviewed in a Live Data table of the collection, including embedding error messages.

Attachments. Documents in the internal store can have attachments whose text is extracted with Apache Tika. Scanned PDFs without a text layer yield no content; an OCR stage is not part of the extension.

Embedding model. Because of the fixed vector length of 1,024, models with exactly this dimension fit without loss:

For models such as multilingual-e5, the model configuration has the fields "Embedding Index Prefix" and "Embedding Query Prefix". A comparison of further models for German text is in the article best embedding models for German.

Changing the embedding model or the chunking parameters requires re-indexing the collection. Without re-indexing, changed chunking values only apply the next time a document is edited. Users on the forum also report embedding errors with individual models served by Ollama (XWiki forum); testing with a small space before the full indexing run is worthwhile.

Access rights: what the chat may see

The index documentation is unambiguous here: regular XWiki access rights are not checked at query time. Access is controlled on two levels, through the collection and through a rights check method per document.

With external, XWiki sends the document IDs, the XWiki user name and, where available, LDAP identifiers, OIDC accounts and JWT identities. Missing values or errors count as "no access".

In practice this means:

• Cut collections by audience. A single collection for the entire wiki with the public method gives every authorised user of the collection all content as context, including content from spaces they cannot open in the wiki.
• Choose xwiki for wiki spaces. Only this method mirrors page rights.
• Allow embedding models for both sides. The groups of the embedding model must include both the users whose edits are indexed and the users who ask questions in the chat.
• Guests only deliberately. "Allow guests" on models and collections opens access without sign-in; with API models this also incurs costs.

Why rights must be enforced in retrieval rather than through the prompt is explained in the article permissions in RAG systems.

MCP server and external integration

MCP server. Since version 0.8 the project includes a server for the Model Context Protocol, with an administration UI since 0.9. It makes wiki content accessible to AI agents and other MCP-capable clients. According to the version 0.10 source code:

As of September 2026 there is no dedicated documentation page for the MCP server on extensions.xwiki.org. Anyone installing the LLM Application should therefore review the MCP configuration and disable the endpoint if it is not needed. How approvals for writing agents can be designed is covered in the article AI agents: permissions and approvals.

Chat in other applications. The Chat WebJar provides a widget that can be embedded in other web applications with a script tag. For signing in external users there is the token authenticator: the application signs a JWT with an Ed25519 key, XWiki creates or updates the user and takes over groups from the token. The documentation recommends a unique group prefix so that an external application cannot set groups such as XWikiAdminGroup (Token-based authentication).

Limits and known issues

For a wiki where employees look things up in handbooks and policies, this feature set is often sufficient, provided collections and rights are cut cleanly. Anyone combining content from several systems, needing reranking or wanting to measure answer quality systematically adds a separate RAG layer next to the wiki. How such measurements are set up is described in the article on RAG evaluation.

Our approach at WZ-IT

We set up the LLM Application as a project with a fixed sequence, on your infrastructure or in an environment we operate in Germany. Support, consulting and implementation by WZ-IT.

1. Assessment. XWiki version, database, Solr, authentication and rights structure. If the version is below 17.4.0, we plan the platform upgrade first.
2. Decide on model hosting. A local model on the AI Cube inside your own network, on a managed GPU server from WZ-IT with NVIDIA RTX PRO 4000 Blackwell (24 GB) or RTX PRO 6000 Blackwell (96 GB), or a European model API. We run the inference server with vLLM or Ollama.
3. Collections and rights. Cut by audience, a rights check method that matches your permission structure, an embedding model for German content and a review of the MCP configuration.
4. Test answer quality. Reference questions from the business side, source checks and tuning of chunking and context prompt. As a bounded project we offer this as a RAG Proof of Value.
5. Operations on request. Updates of XWiki and the extension, monitoring and backups as XWiki managed hosting. If the LLM Application's feature set is not enough, we build an internal AI assistant that connects XWiki as one of several sources.

Further guides

• Atlassian Rovo alternative, self-hosted, wiki and AI layer without Atlassian Cloud.
• Onyx self-hosted: installation and comparison, a standalone AI search across several sources.
• Best embedding models for German, dimensions, licences and hosting compared.
• BookStack, Wiki.js, XWiki or Docmost, choosing the wiki before the AI question.
• What is RAG?, the basics of retrieval-augmented generation.
• AI solutions, the hub with all hosting options for models.

Want to make your XWiki content searchable with AI? We review your installation, connect a model on your own hardware or a managed GPU server and cut collections and rights to fit your wiki. Schedule a meeting

Sources

• XWiki Extensions, LLM project
• XWiki Extensions, LLM Application
• XWiki Extensions, Index for the LLM Application
• XWiki Extensions, LLM Internal Inference Server
• XWiki Extensions, Token-based authentication for the LLM Application
• XWiki Extensions, LLM Chat WebJar
• GitHub, xwiki-contrib/application-ai-llm
• XWiki Jira, LLMAI project
• XWiki Jira, LLMAI-164: keywordSearch is missing the wiki filter
• XWiki Jira, LLMAI-137: HTTP/2 upgrade headers with LM Studio
• XWiki Jira, XWIKI-21887
• XWiki forum, models from Ollama not auto-loaded
• XWiki forum, configuring the LLM Application with Ollama
• XWiki forum, indexing errors with Ollama embeddings
• XWiki Design, WAISE proposal
• Ollama, OpenAI compatibility
• vLLM, OpenAI-compatible server
• Hugging Face, BAAI/bge-m3
• Hugging Face, intfloat/multilingual-e5-large
• Hugging Face, sentence-transformers/all-MiniLM-L6-v2