Mon site SPIP

WsgiChatBot

2025-04-10T15:21:30Z

Cette application est un serveur HTTP au standard WSGI. Il est statique (restfull) : pour réaliser une conversation, ceci impose de gérer l'historique des échanges au niveau de l'application appelante. Loin d'être une contrainte, c'est au contraire une facilité permettant de gérer finement le contexte dans lequel sera analysée la question.

Tester WsgiChatBot (retour JSON)
Tester WsgiChatBot (réponse textuelle)

Routes

WsgiChatBot est un web service au standard WSGI (Web Server Gateway Interface) répondant en JSON à chaque question qui lui est posée par HTTP.

Les routes comprennent principalement :

GET /api/	Message d'accueil
GET /api/version/	Version du service
GET /api/ping	Test fonctionnel. Retourne le temps d'exécution (ms) ou 0 en cas d'erreur
GET /api/themes/	Liste les thèmes (ensemble de données d'une entité) disponibles.
GET /api/details/	Liste les différents niveaux d'élaboration de la réponse.
POST /api/post/	Exécute la requête passée par POST. paramètres du post : voir ci-dessous.

POST, action = 'query'

Tous les paramètres du post sont du type String.

Paramètre		Description
action	obligatoire	'query' : La seule action dans l'état actuel du développement.
theme	obligatoire	Espace de données (un répertoire sur le serveur).
prompt	obligatoire	La requête de l'utilisateur
detail	option	Niveau de détail de la réponse (voir la route 'details').
context	option	Contexte (ou historique) dans lequel la question est analysée.
language	option	Langage imposé pour la réponse.

La réponse au format JSON est un tableau de deux éléments :
– response : une chaîne au format MarkDown,
– ws_error : une chaine décrivant une éventuelle erreur.

Exemple d'appel (PHP)

$data = array( 'action' => 'query', 'theme' => $theme, // Theme du chat 'prompt' => $prompt, // Qu'est-ce que OAuthSD ? 'detail' => 'Normal', 'context' => $context, 'language' => "Français" ); $h = curl_init("localhost:5002/api/post"); # local curl_setopt($h, CURLOPT_POST, 1); curl_setopt($h, CURLOPT_POSTFIELDS, http_build_query($data)); curl_setopt($h, CURLOPT_RETURNTRANSFER, 1); curl_setopt($h, CURLOPT_TIMEOUT, 100); // 100 secondes $result = curl_exec($h);

Lancement du serveur WSGI en ligne de commande

Le script wsgi_chatbot.sh permet de lancer le serveur tout en s'assurant qu'il n'y a qu'un seul process en route :

#!/usr/bin/env bash # contourner l'erreur "ImportError: /lib64/libstdc++.so.6: cannot allocate memory in static TLS block" export LD_PRELOAD=/lib64/libstdc++.so.6 # stop any process running on port 5002 /usr/sbin/fuser -k 5002/tcp; # change to virtual python env cd /home/iadnc/domains/chat.ia.dnc.global/PythonApp source PythonAppVenv/bin/activate; # run nohup /home/iadnc/domains/chat.ia.dnc.global/PythonApp/wsgi_chatbot.py # pour debugger : pas de nohup

Il est important d'utiliser ce script pour éviter l'accumulation de process et la saturation de la mémoire du serveur.

Quelques détails du code

Lancement de l'application Flask comme serveur WSGI sécurisé et local

if __name__ == '__main__': # Connection behind a local proxy # @see: https://flask.palletsprojects.com/en/2.3.x/deploying/proxy_fix/ from werkzeug.middleware.proxy_fix import ProxyFix app.wsgi_app = ProxyFix( app.wsgi_app, x_for=1, # Header to determine the originating IP of the client. x_proto=1, # Trust the header for knowing whether the client used HTTP or HTTPS. x_host=1, # Trust the header for the original request's host value. x_prefix=1 # Trust the header for URL prefix adjustments. ) # Allow cross-origin requests, restrict to local clients. CORS(app, resources={r"/api/*": {"origins": ["http://localhost", "http://127.0.0.1"], "methods": ["GET", "POST"]}}) # Serve on localhost http_server = WSGIServer(('localhost', PORT_SERVER), app) try: http_server.serve_forever() # continuously listen for incoming requests. except Exception as e: # Handle server-level exceptions gracefully trace(f"Server error: {str(e)}")

Ce bloc de code :
– Configure l'application Flask pour fonctionner derrière un éventuel proxy tout en ajustant les attributs des requêtes.
– Autorise uniquement les clients locaux à effectuer des requêtes via les règles 'CORS'.
– Démarre un serveur WSGI sécurisé et local pour servir l'application.
– Intercepte toute exception pour ne pas stopper le serveur. Les erreurs sont inscrites dans Syslog.

Notes à propos de la sécurité :
– Bien qu'il s'agisse d'une connexion locale, la règle 'CORS' est nécessaire ; elle permet de plus de préciser les origines et les méthodes.
– Sans proxy inverse, ce serveur ne peut être interrogé que depuis 'localhost'. S'il existe un proxy inverse ouvert sur le WAN, celui-ci ne peut qu'être local et on peut lui faire confiance, d'où les attributs de requêtes naïfs. Il revient au proxy inverse d'assurer la sécurité de l'accès depuis le WAN.

Gestion de l'historique : paramètre 'context'

Ainsi qu'il est mentionné dans l'introduction, le service est statique. Pour donner l'illusion d'une conversation, l'application appelante doit passer par le paramètre 'context' une chaîne représentative de l'historique des échanges. Cette chaîne est stockée dans la session de l'utilisateur.

Elaboration de l'historique
L'expérience montre que, si on passe tout l'historique (depuis le lancement ou depuis le dernier Reset), il y a un 'effet d'entonnoir' : les question successives étant noyées dans l'historique, les réponses deviennent courtes et tendent à être identiques.
Différents procédés peuvent être appliqués :
– n'inclure dans l'historique que le dernier échange,
– inclure la première question et le dernier échange.
– cumuler les questions et les échanges,
etc.

Les questions et réponses doivent être balisées respectivement par les titres "User : " et "Assistant : "

Dans tous les cas, le volume de chaque échange doit être limité. Limiter la réponse de l'assistant à la première phrase peut s'avérer suffisant.

Exemple de construction d'un historique très simple :

 // Cumul des échanges, réponses réduites à la première phrase $short = strip_tags($reponse); $short = substr($short, 0, strpos($short, ".")) . "."; $newcontext = "User: " . $prompt . "\n Assistant: " . $short . "\n"; $newcontext = $context . "\n " . $newcontext; // cumul des Q/R session_set('context', $newcontext);

'Reset' de l'historique
Puisque le service n'a pas de mémoire des échanges et que l'historique doit être géré par l'application appelante, le 'Reset' de l'historique est géré par cette dernière. Cela peut se résumer à l'effacement du contexte dans la session de l'utilisateur.

Ingestion RAG : le script ingestcmd.py

2024-12-28T17:32:05Z

Le script ingestcmd.py est une commande interne utilisée par l'application SmartIngest pour effectuer les ajouts et les retraits de documents ou de pages Web. Les index des thèmes concernés sont mis à jour à la suite de ces mouvements.

En savoir plus sur le script ingestcmd.py : https://ia.dnc.global/documentation/aspects-techniques/Ingestion-RAG-le-script-ingestcmd-py

Documents sources

Les documents sources peuvent être :
– un site Web [1],
– un document HTML (mime type 'text/html'),
– un dossier local,
– un fichier local.

S'agissant de fichiers locaux (ou du contenu d'un dossier local), les types possibles sont, par leur extension : .csv, .docx, .epub, .mbox, .md [2], .mp3, .pdf, .ppt ... [3]. Un simple fichier .txt peut également être traité mais, à format élémentaire, rendu élémentaire.

Le format Markdown est préférentiel, sous le format décrit ici : https://www.markdownguide.org/basic-syntax/

Notez le fonctionnement différent selon la source :
– dans le cas d'un site Web, les documents extraits du site sont importés dans le dossier .../data/theme,
– dans tous les autres cas, les fichiers doivent se trouver dans le dossier .../data/theme : il n'y a pas d'importation.

Ingérer des documents

Usage :

.../ingestcmd.py  --source {dir, file,url} [--recurse] [--all] [--forwards]

Paramètres :

Argument		Description
theme	Requis en première position	Thème : espace de données spécifique. Un nom court, en minuscules, formé des caractères 'a-z', '-' et '_' , sans espace. Défaut : itego.
—source	Requis/Optionnel	Répertoire, fichier ou URL. Ce doit être des adresses absolues. Cet argument est requis pour toute autre action que —delete_document_by_filename.
—dynamic	Optionnel	Indique que le site est dynamique et que les scripts doivent être exécutés au chargement de la page.
—recurse	Optionnel	Ne s'applique que si la source est un répertoire. Indique que les sous-répertoires doivent être parcourus.
—all	Optionnel	Indique que tout les fichier doivent être traités indépendamment de leur âge, qu'ils aient été modifiés ou non. Attention : le paramètre —all est requis pour une première ingestion.
—forwards	Optionnel	Ne s'applique que si la source est un site Web. Indique de ne pas remonter vers la racine des documents. Par exemple, si l'URL est https://monsite.com/fr, le chemin /en ne sera pas parcouru. Voir également : article 13 .
—levels	Optionnel	S'applique si la source est un site Web ou un répertoire. Nombre de niveaux à parcourir.

Réponse :

Réponse	Description
Fatal error : N : erreur	L'exécution du script s'arrête sur l'erreur indiquée.
End, count : compte	L'exécution du script s'est terminée avec succès, le nombre de documents traités est indiqué par count.

Supprimer un document

Usage :

.../ingestcmd.py  --delete_document_by_filename {filename'}

Paramètres :

Argument		Description
—delete_document_by_filename	Optionnel	Supprime le document ayant le nom de fichier indiqué (tel que dans le dossier data du thème) et met à jour les index. Doit être utilisé sans autre argument que —source.

Réponse :

Réponse	Description
End, count : compte	L'exécution du script s'est terminée, count. = 1 indique le succès. En cas d'erreur, plus d'information dans le fichier nohup.

[1] Dans l'état actuel du développement, seuls les sites statiques (sans exécution de Javascript pour la génération du contenu) sont traités. Pour les sites et pages dynamiques, le développement est en cours.

[2] Ainsi que : .md , .markdown , .mkd , .mdown , .mdtxt , .mdtext

[3] .json en cours de développement.

ChattyWS

2024-12-27T18:55:10Z

ChattyWS est le démonstrateur d'un service web d'IA générative conçu pour être intégré à une application textuelle. Par exemple, il peut répondre aux questions, apporter automatiquement des corrections aux textes fournis et s'opposer aux contenus inappropriés. Et beaucoup plus encore ...

En savoir plus sur ChattyWS : https://ia.dnc.global/documentation/Outils-d-IA-textuels/ChattyWS

Les Thèmes et les Modes permettent de configurer ChattyWS afin d'effectuer toutes tâches d'IA générative sur les données de différentes entités.

Le démonstrateur est plus particulièrement configuré pour appliquer automatiquement des corrections au texte fourni et s'opposer aux contenus inappropriés.
Ceci en fait un composant idéal pour, par exemple :
– assurer la qualité de rédaction d'un site Web,
– assurer automatiquement la modération d'un forum,
– répondre à une question dans le cas d'une FAQ etc.

Thèmes

ChattyBot et ChattyWS utilisent les mêmes données matérialisés sur le serveur par un répertoire portant le nom du thème :
/home/iawiw/public_html/data/theme

Modes

ChattyWS est hautement configurable afin de répondre aux objectifs particuliers d'une application donnée.

Dans le cadre de ce démonstrateur, ChattyWS a permis de configurer les modes suivants :
- answer : L'assistant doit fournir une réponse à la question posée.
- summarize : L'assistant doit résumer et corriger un texte donné.
- correct : L'assistant doit corriger l'orthographe et la grammaire d'un texte.
- improve : L'assistant doit améliorer un texte en éliminant les répétitions.
- complete : L'assistant doit compléter une question en se basant sur un contexte donné.
- extend : L'assistant doit développer un texte en détaillant chaque phrase.

Tous les modes s'opposent à une question inappropriée (vulgarité, racisme, sexisme, conflictualité etc.) en générant un message d'erreur.

Tester ChattyWS : Réponse au format JSON à un POST

La page Test ChattyWS 1 présente un formulaire qui permet d'adresser une requête HTTP POST au web service.

Tester ChattyWS : modération et traduction

La page Test ChattyWS 2 présente un formulaire qui permet d'effectuer un traitement de modération et de traduction sur les données du thème 'securite'.

ChattyBot

2024-12-27T18:46:13Z

ChattyBot est un robot conversationnel. C'est une application Web autonome qui traite des données sanctuarisées dans un espace privé.

En savoir plus sur ChattyBot : https://ia.dnc.global/documentation/Outils-d-IA-textuels/ChattyBot

Thèmes

ChattyBot est capable de sécuriser les données de plusieurs entités en les isolant dans des espaces de données spécifiques, matérialisés sur le serveur par un répertoire portant le nom du thème.

Les thèmes disponibles dans le prototype comprennent actuellement (2024/12) :
– itego : (thème par défaut) intègre la totalité des données d'i-Tego diffusées sur le Web (plus de 500 pages A4).
– securite : Le contenu du site trankilis.com et des documents normatifs portant sur la sécurité du travail dans l'industrie et les contrôles techniques.
– thewiw-corporate : le contenu du site web de What is What
– thewiw-help : le contenu de l'aide en ligne (contenu périmé).

TesterChattyBot

Un démonstrateur de ChattyBot est sur le Web à l'adresse :
https://chat.ia.whatiswhat.cloud/

Le thème par défaut est "thewiw-help". ChattyBot peut être lancé sur un autre thème, par exemple "thewiw-corporate" :
https://chat.ia.whatiswhat.cloud/?theme=thewiw-corporate