Les services IA de DnC

Ingestion : le RAG Manager

Bertrand Degoy — 2025-06-29T17:07:22Z

Les applications publiques de LLMs (ChatGPT, Le Chat etc.), ainsi que toute application s'appuyant sur les LLMs sous-jacents (OpenAI GPT, Mistral AI etc.), ont des bases de connaissances généralistes, très développées mais aussi figées, incluant des informations périmées ou contradictoires et peu fournies sur un domaine métier donné.

Le principe du RAG est de traiter les documents d'une entité. Pour ne pas tomber dans les défauts des LLMs, il faut pouvoir saisir facilement toute la documentation et surtout tenir à jour cette documentation de façon continue. C'est le rôle du RAG Manager.

Voyez l'application en action ici : RAG Manager (accès réservé).

Le Rag Manager couvre toute les étapes de la gestion des documents de l'ingestion à l'indexation, y compris la suppression des documents obsolètes et la création d'un index comprimé :

Le plus important peut-être : pouvoir nettoyer les données, d'où le chiffon ;).

Le dossier 'data' du thème
Tous les documents ingérés (sur lesquels a été construit l'index) se trouvent sur l'hôte dans le dossier .../data/'theme'/.
Le dossier .../data/'theme'/storage/ contient les différents fichiers composant l'index.
Le fichier 'theme'.txt en est une version comprimée et sérialisée de façon à être chargée rapidement par les applications.

Ajouter document(s)
Cette action permet de sélectionner un document dans un dossier local, de l'importer dans le répertoire des données et l'indexer. Il est également possible d'effectuer une sélection multiple.
Cette action n'assure pas l'enregistrement de l'index.

Ajouter Web
Cette action parcourt le site Web désigné, importe le contenu dans le dossier .../data/'theme'/ et assure l'indexation.
L'index est enregistré à la fin de l'action.
Dans l'état actuel du développement, le parcours est effectué avec le paramètre —forwards, mais sans les paramètres —all, —nostore, —dynamic, —plan etc. (voir Ingestion RAG : le script ingestcmd.py ).
En particulier, l'absence de —all permet de lancer l'action régulièrement pour incrémenter l'index avec les pages nouvelles ou modifiées.

Indexer
Cette action balaye le dossier data à la recherche de documents non-indexés et les indexe.
L'ajout d'un document, du contenu d'un répertoire ou de tout ou partie d'un site Web assure l'importation des documents dans le dossier .../data/'theme'/ et leur indexation. Mais il est également possible d'ajouter des documents par d'autres moyens tels qu'un téléversement. Ces documents ne sont pas indexés et devront l'être par l'action Indexer.
L'index est enregistré à la fin de l'action.

Réindexer
L'action Réindexer efface l'index en mémoire et sur le disque avant de ré-indexer tous les documents du dossier data/'theme'/.
L'index est enregistré à la fin de l'action.
Cette action n'est pertinente que dans certains cas d'erreur.
Noter que l'index sérialisé précédent est préservé pendant l'exécution afin d'éviter les ruptures de service.

Enregistrer
L'index est maintenu dans la mémoire de l'hôte. Pour le rendre persistant et accessible aux applications, il faut l'enregistrer après avoir ajouté des documents.
Ceci est fait systématiquement à la suite des actions Ajouter Web, Indexer et Réindexer.
L'enregistrement est une action relativement longue et coûteuse en ressources. C'est pourquoi, quand on ajoute un ou plusieurs documents, on laisse à l'utilisateur le soin de provoquer l'enregistrement.

Supprimer
La suppression des documents périmés est essentielle pour assurer des résultats fondés sur des données à jour. C'est une décision à prendre fichier par fichier.

A propos du Dashboard

Pourquoi un Dashboard ?
Les actions lancées depuis le RAG Manager sont pour la plupart exécutées en tâche de fond. Une fois la tâche lancée, on n'attend pas la fin de l'exécution - qui peut durer plusieurs minutes - pour revenir à la page principale. Le Dashboard permet de voir la progression des traitements et de vérifier leur bonne fin.

Le Dashboard affiche en temps réel des messages techniques, des retours système, ou des étapes de traitements.
Pour cela, le RAG Manager se connecte à la route /api/stream du Web Service IngestWSG qui génère un flux SSE (Server-Sent Events) de tous les messages générés au cours de l'exécution des actions.
– Chaque log généré par le Web Service est injecté dynamiquement sous forme de balises HTML (

)
– Les derniers messages s'affichent en haut grâce à une inversion du flux côté JavaScript
– L'utilisateur bénéficie d'une vue immédiate sur ce qui se passe sans recharger la page

Pourquoi une fenêtre indépendante est requise pour garantir la persistance du flux SSE ?

Lorsqu'un flux SSE est utilisé pour diffuser des messages en temps réel depuis un serveur vers le navigateur, celui-ci repose sur une connexion HTTP persistante attachée à un contexte `window` spécifique. Cette connexion présente plusieurs limites fonctionnelles dans un environnement Web :
– le DOM est rechargé à chaque navigation (ex. clic sur un lien, changement d'onglet, exécution d'une action AJAX non isolée), ce qui est exactement ce que l'on fait en lançant des actions.
– dans ce cas, le contexte JavaScript est détruit et la connexion SSE est interrompue.
– même lorsque le dashboard est inclus dans un INCLURE, une iFrame, appelé par fetch etc., le comportement reste identique : le flux est interrompu.

Solution retenue : une fenêtre autonome

Ouvrir une fenêtre indépendante via `window.open()` permet d'isoler le dashboard dans un contexte JavaScript propre et persistant. Cette approche présente plusieurs avantages :
– Le flux SSE reste actif tant que la fenêtre est ouverte, indépendamment des interactions dans la page principale.
– Le dashboard n'est affecté ni par la navigation SPIP, ni par les rechargements liés au squelette.

La recopie dans la page principale
Une communication bidirectionnelle est établie du dashboard vers la page principale via `postMessage` pour cloner la liste des messages, et dans l'autre sens après un changement de page afin de restituer les messages antérieurs.
Dès qu'un message est généré, il est :
– transmis à la fenêtre Dashboard ouverte avec window.open
– affiché dans une zone HTML (#log-miroir)
– trié dans l'ordre inverse (dernier en haut), avec scroll automatique en haut

Alternatives étudiées (non retenues)

Méthode	Persistance garantie	Recommandée ?
Intégration inline SPIP	Non	❌
Inclusion via iframe	Peu fiable	❌
Inclusion avec Javascript + Fetch	Peu fiable	❌
`window.open()` (fenêtre)	Oui	✅
SharedWorker (avancé)	Complexe, peu supporté	🔶 Expérimental

Après essais, ce choix d'architecture semble le seul capable de garantir la stabilité d'un outil de supervision en temps réel. Il permet de s'affranchir des limites imposées par le cycle de vie du DOM dans SPIP et assure une communication continue entre client et serveur.

A propos du verrouillage

Objectif du verrouillage
Empêcher certaines actions ou modifications liées à un thème lorsqu'une opération sensible est en cours (par exemple : ingestion, indexation, etc.). Le verrou agit comme un signal système pour bloquer l'accès ou désactiver certains éléments de l'interface.

Fonctionnement
1. Création du verrou côté serveur
– Un fichier .lock est placé dans /data/(theme)/storage/
– Présence de ce fichier = thème verrouillé
2. Détection côté PHP
– Via filtre_verrou_actif_dist($theme) :

$lockfile = $_SERVER['DOCUMENT_ROOT'] . "/data/$theme/storage/.lock";
return file_exists($lockfile);

Télécharger

3. Interrogation côté client
– Un script JS appelle régulièrement (polling) la page fonds/etat_verrou avec le nom du thème

$.get("?page=etat_verrou&theme=...", function(data) {
const verrou = (data.trim() == "true");
$(".statusdependant").prop("disabled", verrou);
});

Télécharger

– Si verrou actif → désactivation des boutons ciblés par .statusdependant

Erreurs et solutions

erreur ingestwsg : cURL error : Failed to connect to localhost port 5003 : Connection refused
Il est très probable que le Web Service IngestWsg ne soit pas lancé. Lancez le WS en ligne de commande avec le script ingestwsg.sh.
Vérifiez qu'une tâche CRON lance se script, par exemple chaque nuit.
Voici un exemple d'une séquence de démarrage. Les commandes :

$ cd /home/iazesite/domains/chat.ia.zesite.com/PythonApp
$ source PythonAppVenv/bin/activate
$ /home/iazesite/domains/chat.ia.zesite.coml/PythonApp/ingestwsg.sh

Télécharger

donnent :

Init class Ingestion 1.2.3 2025/06/03
 public_dir_fs= /home/iazesite/public_html/
 Using default Embeddings Model: BAAI
 Ready to start

erreur ingestwsg : HTTP Error 400 : Ingestion start error : Ingestion error, theme : load_data error, KeyError, '_collections_mappings'
Cette erreur résulte d'une incompatibilité entre versions de Python utilisées à différents moments de l'ingestion ou de l'exploitation des données. Il s'agit d'une obsolescence qui devrait disparaître.
La solution consiste à ré-indexer le thème.

Fatal error : embedding (embed_dimension) and vector dimensions (vector_dimension) should be the same
– embed_dimension : la dimension du modèle d'embeddings actuellement utilisé pour les requêtes au LLM,
– vector_dimension : la dimension des embeddings de l'index du thème considéré.
Cette erreur signifie que les modèles d'embeddings utilisés pour l'ingestion puis par les applications ont des dimensions différentes, ou qu'une nouvelle indexation utilise un modèle différent de la précédente.
La solution consiste à ré-indexer le thème.

WsgiChatBot

Bertrand Degoy — 2025-04-04T17:38:25Z

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.
GET /api/history/	Retourne l'historique de la conversation comprimé.
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').
history	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 trois éléments :
– response : une chaîne au format MarkDown,
– history : une chaîne au format JSON,
– ws_error : une simple chaîne décrivant une éventuelle erreur.

En l'absence d'un proxy inverse, WsgiChatBot ne répond qu'à l'hôte (localhost ou 127.0.0.1) sur le port 5002.

Exemple d'appel (PHP)

$data = array(
'action' => 'query',
'theme' => $theme, // Theme du chat
'prompt' => $prompt, // Qu'est-ce que OAuthSD ?
'detail' => 'Normal',
'history' => $history,
'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);

Télécharger

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

Télécharger

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)}")

Télécharger

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 un fichier contigu à l'application.

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 'history'

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

Exemple de chaîne 'history' :

history = "
User : What is the best way to learn Python ?
Assistant : Start with basic syntax and practice with small projects.

User : Can you suggest a beginner project ?
Assistant : Try creating a simple to-do list app using Python.
"

Elaboration de l'historique par le client
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.
– se limiter aux derniers é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 :

Elaboration de l'historique par le serveur
Le serveur ne peut stocker l'historique, mais il peut, après la requête courante, en élaborer une version synthétique.
Le client lit le nouvel historique à l'aide de la route GET history et se contente de le repasser au prochain appel.

'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.

Elaboration de l'historique par le serveur : développements

Managing token limits effectively is key when handling conversation history as a single string, especially with models like `mistralai-small`. Here's how you can optimize it :

### **1. Limit the Number of Past Exchanges**
Since models have a token limit, you should only keep **the most relevant past exchanges**. You can do this by :
– Keeping only the **last N exchanges** (e.g., last 3 conversations).
– Trimming older history beyond a certain character/token limit.

Example :
```python
MAX_TOKENS = 1024 # Adjust based on model limits

def trim_history(history) :
"""Trims conversation history if it exceeds max token limit."""
if len(history) > MAX_TOKENS :
# Keep only the last N exchanges
trimmed_history = "\n".join(history.split("\n")[-10 :]) # Keep last 10 exchanges
return trimmed_history
return history
```

— -

### **2. Use Summary-Based Compression**
Instead of keeping full conversations, generate **summarized versions** of prior exchanges and store those instead.

Example using OpenAI's GPT-4-turbo for summarization :
```python
import openai

def summarize_history(history) :
"""Generate a concise summary of past conversations."""
prompt = f"Summarize the following conversation for context preservation :\n\nhistory"

response = openai.ChatCompletion.create(
model="gpt-4-turbo",
messages=["role" : "system", "content" : prompt]
)

return response["choices"][0]["message"]["content"]
```

Then, when querying :
```python
history = summarize_history(history)
new_query = "What libraries would be useful for that project ?"
final_query = f"history\nUser : new_query"
```

— -

### **3. Use Rolling History Buffer**
Instead of maintaining **one big string**, store history as a **rolling buffer** that automatically removes older entries.

Example using Python `deque` :
```python
from collections import deque

chat_history = deque(maxlen=10) # Keep only the last 10 exchanges

def add_to_history(user_msg, assistant_msg) :
"""Adds conversation entries while maintaining rolling buffer."""
chat_history.append(f"User : user_msg")
chat_history.append(f"Assistant : assistant_msg")

# Example usage
add_to_history("Tell me about Python", "Python is a powerful programming language.")
add_to_history("How do I install it ?", "Use the official website or package manager.")

# Convert deque to a string before querying
formatted_history = "\n".join(chat_history)
print(formatted_history) # Keeps only the last 10 exchanges
```

— -

### **Which Approach Works Best ?**
– **Short conversations ?** → Keep last N exchanges (`trim_history()`).
– **Long conversations ?** → Use summarization (`summarize_history()`).
– **Dynamic conversations ?** → Use rolling history buffer (`deque`).

ChattyBot

Bertrand Degoy — 2024-11-27T13:30:00Z

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

RAG plutôt que Fine Tuning

Les données de l'entité (thème) sont traitées et conservées sur un serveur dédié. Ce serveur peut appartenir à l'entité (on premise).
Cela est rendu possible par l'application de la méthode RAG (Retrieval Augmented Generation ou génération augmentée de récupération).
RAG s'oppose aux méthodes d'entraînement du LLM comme le "fine tuning". Bien que ChattyBot fasse appel à des APIs pour une partie des traitements sémantiques, les données ne sont pas utilisées par celles-ci pour alimenter leur modèle de langage (LLM).

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 [1].

Séparer les données appartenant à des univers différents permet également d'éliminer l'hallucination, fléau de l'IA générative : la génération de réponses totalement incohérentes résultant de la confusion de concepts différents dans une même signature sémantique.

Les avantages exclusifs de ChattyBot

Outre la gestion de différents thèmes, ChattyBot offre des avancées techniques remarquables en présentant dans ses réponses :
– des images extraites des document.
– les sources utilisées pour l'élaboration de la réponse.
– au niveau de détail 'Long', des questions pertinentes pour aider l'utilisateur à creuser son sujet .

TesterChattyBot

Une application de ChattyBot est sur le Web à l'adresse :
https://chat.ia.whatiswhat.cloud/?theme=thewiw-help

[1] Les thèmes disponibles dans le prototype comprennent actuellement : "itego", "thewiw-help", "securite" ... :
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).
ardennes : intègre une extraction des données de DATAtourisme pour le département des Ardennes (plus de 2500 points d'intérêt), ainsi que quelques documents historiques et culturels pertinents.
securite : des documents portant sur la sécurité du travail dans l'industrie et les contrôles techniques.
thewiw : le contenu du site web de What is What et de son aide en ligne.

WsgiAgent

Bertrand Degoy — 2024-11-07T15:45:00Z

WsgiAgent 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 ...

WsgiAgent (ex ChattyWS) est un web service au standard WSGI (Web Server Gateway Interface) répondant à chaque question qui lui est posée par HTTP.
Comme ChattyBot, il intègre les données d'une entité selon la méthode RAG (Retrivial Augmented Generation).

Le service est construit en Python avec LLama Index et avec Flask + Gevent pour répondre au standard WSGI (Web Server Gateway Interface). Il est fait appel à des APIs pour l'analyse sémantique et la génération du texte.

Ce service est purement statique (RestFull) : aucun statut (état, paramètre) n'est mémorisé, il n'y a donc pas de session ni de cookie. C'est une différence importante avec ChattyBot qui prend en compte le dialogue antérieur dans le contexte de la question, ce qui nécessite session et cookie.

WsgiAgent est un service multilingue, répondant dans la langue dans laquelle il est interrogé et capable d'effectuer des traductions.

Les Thèmes et les Modes permettent de configurer WsgiAgent 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 WsgiAgent utilisent les mêmes données (le même Vector Store). Ces deux services sont capables 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 :
/home/iadnc/public_html/data/theme [1].

Les données de l'entité (thème) sont conservées sur le serveur d'i-Tego ou un serveur dédié à l'entité. Elles ne sont pas utilisées par OpenAI pour alimenter le modèle de langage (LLM). Cela est possible grâce à la méthode RAG (Retrieval Augmented Generation ou génération augmentée de récupération), contrairement à des méthodes d'entraînement du LLM comme le "fine tuning".

Différents thèmes pourraient être utilisés par une même entité pour segmenter des groupes de données. Cela peut être fait pour séparer des domaines très différents et éviter des hallucinations. Cela peut également être utilisé pour séparer des données réservées à l'usage interne de l'entreprise de celles destinées au public.

Modes

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

Dans le cadre de ce démonstrateur, WsgiAgent 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 tentant de détailler 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 WsgiAgent : Réponse au format JSON à un POST

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

Tester WsgiAgent : modération et traduction

La page Test WsgiAgent 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'.

La configuration de WsgiAgent pour cette application de démonstration est décrite ici : WsgiAgent 2 : exemple de configuration et de codage.

Lancement

Dans la configuration de ce démonstrateur, le lancement est effectué par l'exécution du script wsgitego.sh de la façon suivante :

#!/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 5000
/usr/sbin/fuser -k 5000/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/llama/test/wsgitego.py # pour debugger : pas de nohup

Télécharger

Une fois lancé, le service web fonctionne de façon continue.
Une bonne pratique est de configurer une tâche CRON pour lancer le script toutes les nuits.

Interrogation, proxy inverse

Pensé pour être intégré dans une application, ou être interrogé à travers un proxy inverse, ChattyWS ne répond qu'en local à l'URL :
localhost:5000/
Cela est favorable à la protection des données de l'entité et permet de restreindre l'usage, notamment pour maîtriser la cadence d'interrogation au niveau de l'application ou d'un proxy sécurisé.

Le prototype est accessible depuis le Web au travers d'un simple proxy inverse Apache à l'url :
https://wsgi.ia.dnc.global/

Comme il se doit, la sécurité est assurée par le proxy en TLS sur le port 443.

Routes

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

Les routes comprennent principalement :

GET /api/	Message d'accueil
GET /api/version/	Version de l'API
GET /api/themes/	Liste les thèmes (ensemble de données d'une entité) disponibles.
GET /api/get/ ?theme=&mode=&query=	Exécute la requête avec les paramètres passés par l'URL.
POST /api/post/	Exécute la requête passée par POST. paramètres : theme : facultatif - espace de données (un répertoire sur le serveur). Les thèmes du prototype sont actuellement :"itego", " ardennes" .... Défaut : "itego". mode : facultatif - type de traitement : "answer", "summarize", "correct", "improve", "complete", "extend". Défaut : "improve". instructions : facultatif - complément aux instructions générales. query : obligatoire - la requête (attention, doit être "URL encoded").

Exemple d'appel distant en PHP :

$data = array(
'theme' => $theme, // Theme du chat.
'mode' => $mode, // answer,summarize,correct,improve,complete,extend
'query' => $query, // Qu'est-ce que OAuthSD ?
);
$h = curl_init("https://wsgi.ia.dnc.global/api/post");
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);

Télécharger

Réponse

ChattyWS répond par un objet JSON "response", "chat_error".

response
La réponse est un texte codé UTF8 sans markup, faiblement structuré, ne comportant que :
– des retours à la ligne,
– parfois du markdown, par exemple : **Hôtel "Campanile" Charleville**,
– éventuellement, une numérotation des paragraphes.

Notes :
• Le mode answer permet d'insérer des instructions pour la recherche et la présentation. Se référer à la documentation générale traitant de la formulations des questions posées à ChattyBot (prompt).
• Une réponse structurée peut être produite en se fondant sur la définition de schémas de sortie (output schemas). Cependant, les schémas ne peuvent être définis que dans le cadre d'une application donnée.
• Le texte est encodé UTF-8.

chat_error

Erreurs détectées par IA

Les définitions de ce type d'erreurs et de leur libellé font partie de la configuration. Dans le cadre de ce démonstration, les erreurs suivantes ont été programmées :

Erreur 1 - Je manque de documentation pour répondre :
Il n'existe aucun document source sur lequel appuyer la réponse, ou la question sort totalement du thème.

Erreur 2 - Veuillez préciser la question :
La question n'est pas assez précise pour permettre la sélection de sources.

Erreur 3 - Formulation inappropriée :
La question est inappropriée ou comporte des mots grossiers.
Par "inappropriée" il faut entendre : injurieuse, déplacée, vulgaire, à connotation sexuelle, raciste, politique etc. Mais ce peut également être une question sans signification comme : "Tu y comprends quelque chose ?".

Il convient de noter que ChattyWS est plus strict que ChattyBot, car il ne s'agit pas d'un robot conversationnel, mais d'un automate répondant de manière pertinente à des questions, par exemple dans le cadre d'une FAQ.

Erreurs techniques à l'appel du web service

Ces erreurs sont générées par l'exécution du code. Par exemple : [2] :

ws_llmquery : cURL error : Failed to connect to localhost port 5000 : Connection refused.
S'agissant d'une connexion locale, il est très probable que le process ChattyWS.py soit arrêté, en cours de (re-)démarrage ou que les paramètres de la connexion soient erronés.

ws_llmquery : HTTP Error 400 : The browser (or proxy) sent a request that this server could not understand.
Requête erronée, vérifier la route et les paramètres.

Toutes les erreurs signalées par chat_error s'accompagnent d' une valeur de response nulle.

Configuration des traitements de ChattyWS

La possibilité de redéfinir les traitements en fonction d'objectifs donnés est une des originalités que l'on retrouve dans tous les développements d'IA de DnC.

Voici des informations utiles pour la configuration des traitements internes (system prompt) :

System prompt, instructions
Le système prompt est composé d'une suite d'instructions, dans l'ordre : instructions générales, instructions passées par URL ou instructions du mode.

Instructions générales
Les instructions générales définissent le rôle du robot, le contexte général et des instructions.
La définition par défaut peut être redéfinie par le paramètre general_instructions du fichier parametres.json.
Exemple :

You are a faithfull QA assistant, expert about {theme}. 
 If you don't have enough source material to support your answer on, say: 'Error 1 - I lack documentation to answer.
 If the question is not specific enough to allow source selection, say: 'Error 2 - Please clarify the question.
 If the question contains rude or inappropriate words, say: 'Error 3 - Inappropriate wording.'

Il faut noter que le mode 'answer' ne tient pas compte des instructions générales, mais seulement des instructions passées par URL ou, par défaut, des instructions du mode. Ceci afin de permettre la plus large latitude dans le fonctionnement du mode.

Instructions passées par URL
De manière facultative, des instructions peuvent être passées par le paramètre d'URL instructions lors de l'appel au web service. Elles complètent (ne remplacent pas) les instructions générales et se substituent aux instructions des modes du fichier parameters.json.

Instruction du mode
Ce sont les instructions particulières du mode. La définition par défaut (figée dans le code) peut être redéfinie par le paramètre mode_instructions du fichier parametres.json. Ceci est applicable à tous les modes. Il est recommandé d'utiliser cette possibilité avec discernement sous peine de s'écarter de l'objectif du mode.

Notes :
• Le robot ne retient aucun contexte (contrairement au ChattyBot). La question passée au Query engine n'est composée que des instructions définies ci-dessus et de la question passée en paramètre d'URL query.

fichier parameters.json

Le fichier se trouve dans le répertoire .../data/theme/configuration.
En plus des instructions, le fichier permet de définir des constantes propres au thème considéré.
Exemple pour le thème ardennes :

{
 "directory": "ardennes",
 "title": "Les Ardennes",
 "description": {
 "en": "Talk about the history and geography of the Ardennes (France) and the various tourist activities",
 "fr": "Parler de l'histoire et de la géographie des Ardennes (France) et des diverses activités touristiques"
 },
 "modes": "'answer','summarize','correct','improve','complete','extend'",
 "general_instructions": "You are a chatty tour guide, ...
 "mode_instructions": {
 "extend": " You are a faithfull QA assistant, expert about {theme}.\nContext information is below..."
 }
 }

[1] Les thèmes disponibles dans le prototype comprennent notamment : "itego", "ardennes", ... :
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).
ardennes : intègre une extraction des données de DATAtourisme pour le département des Ardennes (plus de 2500 points d'intérêt), ainsi que quelques documents historiques et culturels pertinents.
.

[2] Dans l'état actuel du développement, toutes les erreurs ne sont pas signalées par chat_error. C'est notamment le cas des dysfonctionnements internes signalés par une valeur de retour http_code = 500 ou des erreurs du groupe 4. Un test de la valeur de retour HTTP code = 200 est donc la meilleure façon de s'assurer qu'il n'y a pas d'erreur.