docs(15.9): describe what the Ollama client retries and what it does not

de/15.9/config/llm-ollama.rst

@@ -176,7 +176,7 @@ Alle verfügbaren Einstellungselemente für den Ollama-Client. Alle Einstellunge
      - Zu verwendendes Modell (muss in Ollama heruntergeladen sein)
      - ``gemma4:e4b``
    * - ``rag.llm.ollama.timeout``
-     - Anfrage-Timeout (Millisekunden)
+     - Antwort-Timeout (Lese-Timeout, Millisekunden). Eine Anfrage, die in dieses Timeout läuft, wird nicht wiederholt (siehe „Wiederholungsversuche")
      - ``60000``
    * - ``rag.llm.ollama.availability.check.interval``
      - Intervall der Verfügbarkeitsprüfung (Sekunden). Bei einem Wert von ``0`` oder kleiner wird die regelmäßige Verfügbarkeitsprüfung deaktiviert
@@ -194,7 +194,7 @@ Alle verfügbaren Einstellungselemente für den Ollama-Client. Alle Einstellunge
      - TCP-Verbindungs-Timeout (Millisekunden). Kann unabhängig von ``rag.llm.ollama.timeout`` angegeben werden
      - ``5000``
    * - ``rag.llm.ollama.retry.max``
-     - Maximale Anzahl von HTTP-Wiederholungsversuchen (bei ``429``- und ``5xx``-Fehlern)
+     - Maximale Anzahl der Versuche pro Anfrage an Ollama, einschließlich des ersten (siehe „Wiederholungsversuche")
      - ``3``
    * - ``rag.llm.ollama.retry.base.delay.ms``
      - Basisverzögerung des exponentiellen Backoffs (Millisekunden)
@@ -238,6 +238,35 @@ Mit ``rag.llm.ollama.max.concurrent.requests`` kann die Anzahl gleichzeitiger An
 Der Standardwert ist 5. Passen Sie diesen Wert entsprechend den Ressourcen des Ollama-Servers an.
 Bei zu vielen gleichzeitigen Anfragen kann der Ollama-Server überlastet werden und die Antwortgeschwindigkeit sinken.
 
+Wiederholungsversuche
+---------------------
+
+Jede Anfrage an Ollama wird höchstens ``rag.llm.ollama.retry.max``-mal versucht, der erste Versuch eingeschlossen (``1`` deaktiviert Wiederholungen). Die Anfrage wird erneut versucht, wenn:
+
+- Ollama HTTP ``429``, ``500``, ``502``, ``503`` oder ``504`` zurückgibt
+- die Anfrage fehlschlägt, bevor eine Antwort eintrifft, zum Beispiel weil die Verbindung abgelehnt oder zurückgesetzt wird, der Server die Verbindung ohne Antwort schließt oder innerhalb von ``rag.llm.ollama.connect.timeout`` keine Verbindung zustande kommt
+
+Vor dem zweiten Versuch wartet der Client ``rag.llm.ollama.retry.base.delay.ms``, und die Wartezeit verdoppelt sich mit jedem weiteren Versuch. Dazu kommt ein zufälliger Jitter von bis zu ±20 % der Basisverzögerung; eine einzelne Wartezeit beträgt nie mehr als 60 Sekunden.
+
+Folgende Fehler werden nicht wiederholt:
+
+- Ein Antwort-Timeout: Ollama hat die Anfrage angenommen, aber nicht innerhalb von ``rag.llm.ollama.timeout`` geantwortet. Ein weiterer Versuch würde nur erneut das volle Timeout abwarten
+- Jeder andere HTTP-Fehlerstatus, etwa ``400`` oder ``404``
+- Ein Fehler, den Ollama innerhalb einer gestreamten Antwort meldet
+
+Mit den Standardwerten (``retry.max`` ``3``, ``retry.base.delay.ms`` ``2000``, ``connect.timeout`` ``5000``, ``timeout`` ``60000``) betragen die Wartezeiten zwischen den Versuchen etwa 2 und 4 Sekunden. Eine Anfrage, die immer wieder fehlschlägt, wird daher abgebrochen nach:
+
+- etwa 6 Sekunden, wenn die Verbindung abgelehnt wird (3 Versuche)
+- etwa 21 Sekunden, wenn jeder Verbindungsaufbau in das Timeout läuft (3 × 5 Sekunden plus Wartezeiten)
+- etwa 6 Sekunden plus der Zeit, die Ollama für jede Fehlerantwort braucht, bei einem wiederholbaren HTTP-Status (3 Versuche)
+- 60 Sekunden bei einem Antwort-Timeout (1 Versuch)
+
+Diese Grenzen gelten für jede einzelne Anfrage an Ollama. Eine Frage im AI-Suchmodus sendet mehrere Anfragen, etwa zur Absichtserkennung und zur Antwortgenerierung, und jede hat eigene Versuche und ein eigenes Timeout.
+
+Antwortet ein Modell langsam, etwa weil es für die erste Anfrage noch geladen wird, erhöhen Sie ``rag.llm.ollama.timeout`` wie in „Empfohlene Konfiguration (Produktionsumgebung)". Ein höheres ``rag.llm.ollama.retry.max`` hilft nicht, da ein Antwort-Timeout nicht wiederholt wird.
+
+Der Ollama-Embedding-Client der semantischen Suche (``content_chunker.embedding.name=ollama``) wiederholt Anfragen auf dieselbe Weise. Seine Einstellungen sind ``content_chunker.embedding.ollama.timeout``, ``content_chunker.embedding.ollama.retry.max`` und ``content_chunker.embedding.ollama.retry.base.delay.ms`` in ``system.properties``, mit denselben Standardwerten (siehe :doc:`search-semantic`).
+
 Prompttypspezifische Einstellungen
 ===================================
 

en/15.9/config/llm-ollama.rst

@@ -176,7 +176,7 @@ All configuration options available for the Ollama client. All settings except `
      - Model name to use (must be already downloaded to Ollama)
      - ``gemma4:e4b``
    * - ``rag.llm.ollama.timeout``
-     - Request timeout (in milliseconds)
+     - Response (read) timeout (in milliseconds). A request that runs into it is not retried (see "Retries")
      - ``60000``
    * - ``rag.llm.ollama.availability.check.interval``
      - Availability check interval (in seconds). Setting a value of ``0`` or lower disables periodic availability checks
@@ -194,7 +194,7 @@ All configuration options available for the Ollama client. All settings except `
      - TCP connect timeout (in milliseconds). Configurable separately from ``rag.llm.ollama.timeout``
      - ``5000``
    * - ``rag.llm.ollama.retry.max``
-     - Maximum number of HTTP retry attempts (on ``429`` and ``5xx`` errors)
+     - Maximum number of attempts per request to Ollama, including the first (see "Retries")
      - ``3``
    * - ``rag.llm.ollama.retry.base.delay.ms``
      - Base delay for exponential backoff (in milliseconds)
@@ -238,6 +238,35 @@ Use ``rag.llm.ollama.max.concurrent.requests`` to control the number of concurre
 The default is 5. Adjust according to the resources of your Ollama server.
 Too many concurrent requests may overload the Ollama server and degrade response speed.
 
+Retries
+-------
+
+Each request to Ollama is attempted at most ``rag.llm.ollama.retry.max`` times, including the first attempt (``1`` disables retries). The request is attempted again when:
+
+- Ollama returns HTTP ``429``, ``500``, ``502``, ``503`` or ``504``
+- The request fails before a response arrives, for example because the connection is refused or reset, the server closes the connection without answering, or no connection is established within ``rag.llm.ollama.connect.timeout``
+
+Before the second attempt the client waits ``rag.llm.ollama.retry.base.delay.ms``, and the wait doubles for each further attempt. A random jitter of up to ±20% of the base delay is added, and a single wait never exceeds 60 seconds.
+
+The following failures are not retried:
+
+- A response timeout: Ollama accepted the request but did not answer within ``rag.llm.ollama.timeout``. Another attempt would only wait the full timeout again
+- Any other HTTP error status, such as ``400`` or ``404``
+- An error that Ollama reports inside a streamed response
+
+With the defaults (``retry.max`` ``3``, ``retry.base.delay.ms`` ``2000``, ``connect.timeout`` ``5000``, ``timeout`` ``60000``), the waits between attempts are about 2 and 4 seconds, so a request that keeps failing gives up after:
+
+- About 6 seconds when the connection is refused (3 attempts)
+- About 21 seconds when every connection attempt times out (3 × 5 seconds plus the waits)
+- About 6 seconds plus the time Ollama takes to return each error, for a retryable HTTP status (3 attempts)
+- 60 seconds for a response timeout (1 attempt)
+
+These limits apply to each request to Ollama. One question in AI search mode sends several requests, for example for intent detection and for answer generation, and each has its own attempts and timeout.
+
+If a model answers slowly, for example while it is still being loaded for its first request, raise ``rag.llm.ollama.timeout`` as in "Recommended Configuration (Production)". Raising ``rag.llm.ollama.retry.max`` does not help, because a response timeout is not retried.
+
+The Ollama embedding client for semantic search (``content_chunker.embedding.name=ollama``) retries the same way. Its settings are ``content_chunker.embedding.ollama.timeout``, ``content_chunker.embedding.ollama.retry.max`` and ``content_chunker.embedding.ollama.retry.base.delay.ms`` in ``system.properties``, with the same defaults (see :doc:`search-semantic`).
+
 Per-Prompt-Type Settings
 ========================
 

es/15.9/config/llm-ollama.rst

@@ -176,7 +176,7 @@ Todos los elementos de configuración disponibles para el cliente de Ollama. Tod
      - Nombre del modelo a usar (modelo descargado en Ollama)
      - ``gemma4:e4b``
    * - ``rag.llm.ollama.timeout``
-     - Timeout de solicitud (milisegundos)
+     - Timeout de respuesta (lectura) (milisegundos). Una solicitud que agota este timeout no se reintenta (consulte "Reintentos")
      - ``60000``
    * - ``rag.llm.ollama.availability.check.interval``
      - Intervalo de verificación de disponibilidad (segundos). Si se especifica ``0`` o un valor menor, se deshabilita la verificación periódica de disponibilidad
@@ -194,7 +194,7 @@ Todos los elementos de configuración disponibles para el cliente de Ollama. Tod
      - Timeout de conexión TCP (milisegundos). Se puede especificar de forma independiente a ``rag.llm.ollama.timeout``
      - ``5000``
    * - ``rag.llm.ollama.retry.max``
-     - Número máximo de reintentos HTTP (en errores ``429`` y de la familia ``5xx``)
+     - Número máximo de intentos por solicitud a Ollama, incluido el primero (consulte "Reintentos")
      - ``3``
    * - ``rag.llm.ollama.retry.base.delay.ms``
      - Retardo base del backoff exponencial (milisegundos)
@@ -238,6 +238,35 @@ Usando ``rag.llm.ollama.max.concurrent.requests``, puede controlar el número de
 El valor predeterminado es 5. Ajústelo según los recursos del servidor Ollama.
 Si el número de solicitudes simultáneas es demasiado alto, puede sobrecargar el servidor Ollama y reducir la velocidad de respuesta.
 
+Reintentos
+----------
+
+Cada solicitud a Ollama se intenta como máximo ``rag.llm.ollama.retry.max`` veces, incluido el primer intento (``1`` desactiva los reintentos). La solicitud se vuelve a intentar cuando:
+
+- Ollama devuelve HTTP ``429``, ``500``, ``502``, ``503`` o ``504``
+- La solicitud falla antes de recibir una respuesta, por ejemplo porque la conexión se rechaza o se restablece, el servidor cierra la conexión sin responder, o no se establece la conexión dentro de ``rag.llm.ollama.connect.timeout``
+
+Antes del segundo intento, el cliente espera ``rag.llm.ollama.retry.base.delay.ms``, y la espera se duplica en cada intento posterior. Se añade una variación aleatoria (jitter) de hasta ±20 % del retardo base, y una sola espera nunca supera los 60 segundos.
+
+Los siguientes fallos no se reintentan:
+
+- Un timeout de respuesta: Ollama aceptó la solicitud pero no respondió dentro de ``rag.llm.ollama.timeout``. Otro intento solo volvería a esperar el timeout completo
+- Cualquier otro código de estado de error HTTP, como ``400`` o ``404``
+- Un error que Ollama notifica dentro de una respuesta en streaming
+
+Con los valores predeterminados (``retry.max`` ``3``, ``retry.base.delay.ms`` ``2000``, ``connect.timeout`` ``5000``, ``timeout`` ``60000``), las esperas entre intentos son de unos 2 y 4 segundos, por lo que una solicitud que sigue fallando se abandona tras:
+
+- Unos 6 segundos cuando se rechaza la conexión (3 intentos)
+- Unos 21 segundos cuando todos los intentos de conexión agotan el timeout (3 × 5 segundos más las esperas)
+- Unos 6 segundos más el tiempo que Ollama tarda en devolver cada error, con un código de estado HTTP reintentable (3 intentos)
+- 60 segundos con un timeout de respuesta (1 intento)
+
+Estos límites se aplican a cada solicitud a Ollama. Una pregunta en el modo de búsqueda IA envía varias solicitudes, por ejemplo para la determinación de intención y para la generación de la respuesta, y cada una tiene sus propios intentos y su propio timeout.
+
+Si un modelo responde lentamente, por ejemplo mientras todavía se está cargando para su primera solicitud, aumente ``rag.llm.ollama.timeout`` como en "Configuración recomendada (entorno de producción)". Aumentar ``rag.llm.ollama.retry.max`` no ayuda, porque un timeout de respuesta no se reintenta.
+
+El cliente de embeddings de Ollama para la búsqueda semántica (``content_chunker.embedding.name=ollama``) reintenta de la misma manera. Su configuración es ``content_chunker.embedding.ollama.timeout``, ``content_chunker.embedding.ollama.retry.max`` y ``content_chunker.embedding.ollama.retry.base.delay.ms`` en ``system.properties``, con los mismos valores predeterminados (consulte :doc:`search-semantic`).
+
 Configuración por tipo de prompt
 =================================
 

fr/15.9/config/llm-ollama.rst

@@ -176,7 +176,7 @@ Tous les éléments de configuration disponibles pour le client Ollama. Tous, sa
      - Nom du modèle à utiliser (modèle déjà téléchargé dans Ollama)
      - ``gemma4:e4b``
    * - ``rag.llm.ollama.timeout``
-     - Délai d'expiration des requêtes (millisecondes)
+     - Délai d'expiration de la réponse (lecture, millisecondes). Une requête qui atteint ce délai n'est pas retentée (voir « Nouvelles tentatives »)
      - ``60000``
    * - ``rag.llm.ollama.availability.check.interval``
      - Intervalle de vérification de disponibilité (secondes). Une valeur inférieure ou égale à ``0`` désactive la vérification périodique de disponibilité
@@ -194,7 +194,7 @@ Tous les éléments de configuration disponibles pour le client Ollama. Tous, sa
      - Délai d'expiration de la connexion TCP (millisecondes). Peut être spécifié séparément de ``rag.llm.ollama.timeout``
      - ``5000``
    * - ``rag.llm.ollama.retry.max``
-     - Nombre maximal de tentatives HTTP (en cas d'erreur ``429`` ou de la série ``5xx``)
+     - Nombre maximal de tentatives par requête vers Ollama, première tentative comprise (voir « Nouvelles tentatives »)
      - ``3``
    * - ``rag.llm.ollama.retry.base.delay.ms``
      - Délai de base du backoff exponentiel (millisecondes)
@@ -238,6 +238,35 @@ Contrôle de la concurrence
 La valeur par défaut est 5. Ajustez-la en fonction des ressources du serveur Ollama.
 Un nombre trop élevé de requêtes simultanées peut surcharger le serveur Ollama et réduire la vitesse de réponse.
 
+Nouvelles tentatives
+--------------------
+
+Chaque requête vers Ollama est tentée au plus ``rag.llm.ollama.retry.max`` fois, première tentative comprise (``1`` désactive les nouvelles tentatives). La requête est tentée à nouveau lorsque :
+
+- Ollama renvoie HTTP ``429``, ``500``, ``502``, ``503`` ou ``504``
+- La requête échoue avant qu'une réponse n'arrive, par exemple parce que la connexion est refusée ou réinitialisée, que le serveur ferme la connexion sans répondre, ou que la connexion n'est pas établie dans le délai ``rag.llm.ollama.connect.timeout``
+
+Avant la deuxième tentative, le client attend ``rag.llm.ollama.retry.base.delay.ms``, et l'attente double à chaque tentative suivante. Une variation aléatoire (jitter) allant jusqu'à ±20 % du délai de base s'y ajoute, et une attente ne dépasse jamais 60 secondes.
+
+Les échecs suivants ne sont pas retentés :
+
+- Un délai d'expiration de la réponse : Ollama a accepté la requête mais n'a pas répondu dans le délai ``rag.llm.ollama.timeout``. Une nouvelle tentative ne ferait qu'attendre à nouveau tout le délai
+- Tout autre code d'erreur HTTP, par exemple ``400`` ou ``404``
+- Une erreur signalée par Ollama à l'intérieur d'une réponse en streaming
+
+Avec les valeurs par défaut (``retry.max`` ``3``, ``retry.base.delay.ms`` ``2000``, ``connect.timeout`` ``5000``, ``timeout`` ``60000``), les attentes entre les tentatives sont d'environ 2 et 4 secondes ; une requête qui continue d'échouer est donc abandonnée après :
+
+- Environ 6 secondes lorsque la connexion est refusée (3 tentatives)
+- Environ 21 secondes lorsque chaque tentative de connexion expire (3 × 5 secondes plus les attentes)
+- Environ 6 secondes plus le temps que met Ollama à renvoyer chaque erreur, pour un code HTTP retenté (3 tentatives)
+- 60 secondes pour un délai d'expiration de la réponse (1 tentative)
+
+Ces limites s'appliquent à chaque requête vers Ollama. Une question en mode de recherche IA envoie plusieurs requêtes, par exemple pour la détermination de l'intention et pour la génération de la réponse, chacune avec ses propres tentatives et son propre délai d'expiration.
+
+Si un modèle répond lentement, par exemple parce qu'il est encore en cours de chargement pour sa première requête, augmentez ``rag.llm.ollama.timeout`` comme dans « Configuration recommandée (environnement de production) ». Augmenter ``rag.llm.ollama.retry.max`` n'aide pas, car un délai d'expiration de la réponse n'est pas retenté.
+
+Le client d'embeddings Ollama de la recherche sémantique (``content_chunker.embedding.name=ollama``) procède de la même manière. Ses paramètres sont ``content_chunker.embedding.ollama.timeout``, ``content_chunker.embedding.ollama.retry.max`` et ``content_chunker.embedding.ollama.retry.base.delay.ms`` dans ``system.properties``, avec les mêmes valeurs par défaut (voir :doc:`search-semantic`).
+
 Configuration par type de prompt
 ====================================