AnythingLLM Max Tokens : corriger une réponse tronquée
Une réponse interrompue au milieu d’une phrase ne prouve pas un problème réseau. Vérifiez les réglages effectifs de Generic OpenAI, la raison de fin renvoyée par l’API et un essai ne modifiant qu’une variable.
Sommaire
Lorsqu’une longue réponse AnythingLLM s’arrête au milieu d’une phrase, vérifiez d’abord si Max Tokens a plafonné cette génération. Agrandir la fenêtre de contexte ou le délai du proxy ne constitue pas une correction équivalente. Il faut connaître le budget de sortie réellement envoyé, le finish_reason renvoyé par l’API et le résultat d’un nouvel essai ne changeant qu’une variable, tout en conservant les réglages initiaux.
Choisir une correction à partir de la fin de réponse
L’arrêt du texte à l’écran est un symptôme, pas un diagnostic. Dans OpenAI Chat Completions, length signifie que la limite de tokens indiquée dans la requête a été atteinte. stop peut correspondre à une fin naturelle ou à une séquence d’arrêt configurée. tool_calls indique un appel d’outil, pas la livraison d’une réponse finale. Avec une API compatible, vérifiez également le comportement du serveur concerné.
| Élément observé | Première piste | Action suivante |
|---|---|---|
L’API renvoie finish_reason=length et le budget effectif est vérifiable | Limite de sortie | Garder la même entrée et ne modifier que le budget de sortie, dans les limites admises |
| Le serveur signale explicitement un contexte trop grand ; la même tâche fonctionne avec moins d’historique ou de passages récupérés | Pression sur le contexte | Réduire l’entrée et vérifier la fenêtre réelle du modèle, plutôt qu’augmenter seulement la sortie |
| Délai dépassé, connexion réinitialisée, annulation ou flux terminé sans raison de fin visible | Connexion, annulation ou compatibilité du flux | Recouper les horaires et trouver la couche qui a terminé la requête ; l’absence d’un champ ne prouve pas une panne réseau |
La réponse renvoie stop, mais il manque une section ou un élément numéroté | Consignes, séquences d’arrêt et complétude | Examiner les omissions : fin normale ne veut pas dire tâche accomplie |
Le budget de sortie limite ce qu’une requête peut générer. La fenêtre de contexte concerne la quantité de contexte que le modèle peut traiter. Historique, instructions système et passages récupérés peuvent faire partie de l’entrée : l’adaptateur Generic OpenAI d’AnythingLLM les assemble. Une question courte peut donc produire une grosse requête, et saisir une fenêtre plus grande dans l’interface n’augmente pas les capacités du modèle côté serveur.
Un utilisateur dans l’issue #6703 a raconté avoir cherché du côté des délais du proxy inverse et de WebSocket avant d’identifier une limite de sortie. Ce témoignage justifie l’ordre des vérifications, mais ne prouve pas que votre installation présente la même cause.
Conserver les réglages et identifier le modèle effectivement appelé
Notez l’état initial avant toute modification. Relevez la version d’AnythingLLM, Desktop ou installation auto-hébergée, le fournisseur global, le fournisseur et le modèle sélectionnés dans l’espace de travail et le chat, l’utilisation éventuelle d’un agent, ainsi que les limites de contexte et de sortie. Masquez les clés dans les captures. Ne supprimez pas l’espace d’origine, les conversations ou les documents indexés pour réaliser cet essai.
Ouvrez la configuration du fournisseur LLM dans Settings et assurez-vous que le test utilise bien Generic OpenAI. La documentation officielle exige une compatibilité des fonctions de l’API comme du format des réponses d’inférence. Modifier Generic OpenAI ne configure pas une requête qui emprunte un autre fournisseur.
Le code officiel de l’interface consulté le 2026-10-16 comporte ces champs :
| Champ | Vérification |
|---|---|
Base URL, API Key, Selected Model | L’adresse qui fonctionnait, la clé correspondante et l’identifiant exact du modèle ; ne le déduisez pas de son nom affiché |
Model context window | La capacité de contexte configurée, et non le budget de la réponse |
Max Tokens | Le budget de génération, à examiner séparément |
Enregistrez puis rouvrez les réglages pour vérifier leur persistance. Si vous avez un accès autorisé aux requêtes sortantes, contrôlez aussi le model effectif et le champ limitant la sortie. Une capture montre l’interface, pas ce que le serveur a reçu. Testez séparément chat ordinaire et agent : les notes de Desktop v1.16.2 mentionnent une correction de Generic OpenAI qui ignorait max tokens dans les flux des agents.
Si vous utilisez déjà BetterToken, comparez à cette étape votre adresse, clé et modèle avec ses instructions Chat Completions ; il s’agit d’une référence de configuration, pas d’une garantie de compatibilité avec toutes les fonctions d’AnythingLLM ni de suppression des limites de sortie.
Distinguer la valeur 0, le nom du paramètre et la version
0 ne signifie pas sortie illimitée. Les notes de Desktop v1.17.0 indiquent que Generic OpenAI peut utiliser 0 pour ne pas envoyer max_tokens. Les valeurs par défaut et limites du serveur prennent alors le relais. Pour le diagnostic, un budget positif explicite accepté par le modèle rend la comparaison plus claire.
Dans l’adaptateur consulté le 2026-10-16, la sortie utilise GENERIC_OPEN_AI_MAX_TOKENS, tandis que la fenêtre utilise GENERIC_OPEN_AI_MODEL_TOKEN_LIMIT. Le champ de sortie s’appelle par défaut max_tokens ; GENERIC_OPEN_AI_MODEL_MAX_TOKEN_KEY permet un autre nom. Cela décrit le code consulté, sans promettre les mêmes commandes dans chaque version installée.
Ne renommez pas arbitrairement les paramètres de toutes les API compatibles. La référence actuelle d’OpenAI définit max_completion_tokens, dont le budget inclut la sortie visible et les tokens de raisonnement. Une réponse visible courte peut donc épuiser le budget. Vérifiez le champ accepté par votre serveur et votre modèle et ne changez le réglage que si votre version le prend en charge.
Sous Desktop, utilisez l’interface plutôt que de modifier .env à partir d’un extrait trouvé en ligne : le guide officiel réserve ces instructions à l’auto-hébergement ou à Docker. La v1.17.0 a aussi changé l’enregistrement des réglages de l’espace de travail. Vérifiez les valeurs en rouvrant la page, au lieu de chercher le même bouton dans toutes les versions.
Où trouver finish_reason et l’usage réel
Privilégiez la réponse du service de modèle à AnythingLLM. Pour Chat Completions sans streaming, examinez choices[0].finish_reason et le usage retourné. Pour un flux, trouvez le fragment portant la raison de fin et vérifiez que la séquence complète de terminaison du serveur est arrivée. Un champ vide dans le premier fragment n’est pas le statut final. Les définitions officielles des réponses précisent ces champs.
Dans l’interface web, ouvrez Network dans les outils du navigateur, conservez le journal puis reproduisez le problème une fois. Relevez heure, statut et réponse de la requête du chat. Cela observe le trajet navigateur–AnythingLLM, pas nécessairement la réponse brute du service de modèle.
Le gestionnaire de flux Generic OpenAI consulté le 2026-10-16 transforme une raison de fin non vide en un message propre à AnythingLLM avec close: true, sans transmettre la raison telle quelle à l’interface. En l’absence d’usage fourni par le serveur, le code prévoit aussi une estimation par comptage des fragments de texte. Une fin affichée et un nombre de tokens ne prouvent donc ni la complétude ni l’atteinte exacte du budget.
Récupérez la raison et l’usage d’origine dans les journaux du service ou les détails de requête auxquels vous avez accès. Sinon, donnez au responsable du déploiement l’heure et l’identifiant de la requête. Les notes de Desktop v1.16.2 décrivent l’accès aux journaux et au stockage par l’étiquette de version en haut de la fenêtre ; trouver le dossier ne garantit pas que cette version journalise le champ de fin original.
L’usage final peut manquer en streaming : OpenAI précise qu’une interruption ou une annulation peut empêcher la réception du dernier fragment usage. Notez « non disponible », pas zéro, et ne confondez pas une estimation de l’application avec les données de facturation.
Comparer une réponse courte et une longue sans perdre la configuration
Fixez d’abord le chemin de la requête, puis faites varier la longueur demandée. Utilisez un espace de test sans documents de base de connaissances. Gardez le même fournisseur, modèle, message système, température, budget de sortie et autres réglages. Démarrez une conversation vide pour chaque essai afin que le second n’hérite pas du premier. Commencez par le chat ordinaire, sans agents ni outils.
Test court A :
Donne 3 recommandations pour gérer la documentation d’un projet. Écris 2–3 phrases pour chacune. Une fois terminé, écris
[END]sur une ligne séparée.
Test long B :
Donne 20 recommandations pour gérer la documentation d’un projet. Écris 2–3 phrases pour chacune. Une fois terminé, écris
[END]sur une ligne séparée.
Envoyez la consigne et laissez la génération se terminer sans l’arrêter ni actualiser la page. En cas de délai dépassé ou de déconnexion, relevez l’heure plutôt que de multiplier les tentatives. Copiez l’intégralité des réponses affichées dans A.txt et B.txt. Notez aussi heure, modèle, budget effectif, raison de fin, origine du usage, présence du dernier numéro et de [END]. Ces nombres définissent l’exercice, pas les limites du modèle ni une longueur garantie.
Un A complet et un B incomplet montrent une difficulté dans le scénario de sortie longue ; cela ne prouve pas encore que Max Tokens en est la cause. Si B renvoie length, conservez sa consigne exacte et tous les autres réglages. Augmentez seulement le budget à une valeur explicite admise par le serveur et lancez C dans une conversation vide. Enregistrez C.txt. Les 20 éléments complets, le marqueur final et une fin différente de length étayent l’efficacité de ce changement dans ce cas.
Si B se termine déjà correctement, n’augmentez pas le budget sans raison. Comparez la même tâche réelle dans la conversation d’origine et dans une vide, en conservant le budget. Cherchez du côté du contexte lorsque le problème suit l’historique ou les passages récupérés. Rétablissez les réglages temporaires devenus inutiles et gardez les relevés initiaux. Les tests sur une API payante peuvent entraîner les frais habituels des requêtes.
Appliquer une correction ciblée, sans tout modifier à la fois
Limite de sortie confirmée : changer le budget et vérifier l’envoi
N’augmentez que le budget du chemin réellement utilisé, dans les limites du modèle. Si la valeur affichée change mais pas la requête, contrôlez fournisseur, enregistrement, version et différences entre chat et agent. Agrandir le contexte ne corrige pas un réglage de sortie qui n’a jamais atteint le serveur.
Contexte excessif : réduire l’entrée à tâche et budget constants
Répétez d’abord la même tâche longue dans un chat vide. Réduisez ensuite, séparément, les passages récupérés ou l’historique inutile. Si le serveur signale explicitement une limite de contexte, configurez la capacité réelle du modèle ; saisir un nombre plus élevé ne l’agrandit pas. Sans erreur explicite, une amélioration dans un chat vide laisse le contexte au stade d’hypothèse à vérifier.
Connexion ou streaming : localiser l’interruption avant de changer un délai
Comparez les journaux du navigateur, d’AnythingLLM et de l’API sur le même intervalle. Cherchez annulation, expiration ou fermeture de connexion. Si l’API a terminé mais que le navigateur n’a reçu qu’une partie, examinez transport intermédiaire et affichage. Si l’API elle-même a échoué, traitez d’abord son erreur. Ne modifiez le délai d’une couche que si les journaux la mettent en cause.
En auto-hébergement ou sous Docker, l’administrateur peut isoler le streaming. La configuration officielle prévoit GENERIC_OPENAI_STREAMING_DISABLED="true", uniquement pour Generic OpenAI ; redémarrez le service ou conteneur concerné après modification. Relancez la même consigne longue sans autre changement, puis restaurez la valeur initiale et redémarrez. Un succès sans streaming recentre l’enquête sur les chemins liés au flux, sans démontrer que le proxy est responsable. N’appliquez pas cette modification de .env à Desktop.
Confirmer la correction et préparer un signalement exploitable
Une réponse plus longue ne suffit pas. Vérifiez toutes les sections ou numérotations demandées, la dernière phrase complète et le marqueur final. Recoupez la raison de fin originale et les journaux de connexion pour exclure une nouvelle troncature. Ni stop ni [END] ne remplacent la vérification du contenu. Après le test simplifié, refaites également la tâche réelle qui échouait.
Si le problème persiste, transmettez au responsable version et déploiement, chat ou agent, identifiants du fournisseur et du modèle, réglages expurgés, consigne minimale, différences A/B/C, horaires et raison de fin obtenue. Retirez clés API, en-têtes d’authentification et texte de documents privés. Indiquez les champs non disponibles. L’enquête pourra ainsi porter sur une requête précise plutôt que repartir sur des modifications de proxy au hasard.
