Contrôle de la Randomistaion : Temperature et Top P
Lors de la génération de texte par un LLM, deux paramètres clés régulent l'équilibre entre créativité et fiabilité : la Temperature et le Top P (échantillonnage par noyau). Ils modulent la distribution de probabilité des tokens suivants, influençant ainsi le choix du modèle.
Temperature : Degré de « Risque »
La Temperature ajuste la forme de la distribution de probabilité sur l'ensemble du vocabulaire. Mathématiquement, elle modifie le tenseur des logits avant l'application de la fonction softmax.
- Température basse (T < 1) : La distribution devient plus « pointue ». Les tokens ayant une probabilité initiale élevée voient leur dominance accentuée, tandis que les tokens rares deviennent presque impossibles. La sortie est plus conservatrice et déterministe.
- Température élevée (T > 1) : La distribution s'aplatit. L'écart entre les probabilités des différents tokens se réduit, accordant ainsi plus de chances aux tokens initialement peu probables. Cela augmente la diversité et le potentiel créatif, au prix d'un risque d'incohérence.
- Extrêmes : T=0 équivaut à un échantillonnage glouton (toujours choisir le token le plus probable). T→∞ uniformise les probabilités, menant à un tirage quasi-aléatoire.
Top P (Échantillonnage par Noyau) : Sélection du Bassin de Tokens
Plutôt que de modifier toutes les probabilités, Top P définit un seuil de probabilité cumulative. Le modèle ne considère que le plus petit ensemble de tokens dont les probabilités cumulées atteignent ce seuil.
- Top P élevé (proche de 1) : Le bassin de sélection est large, conservant potentiellement des tokens avec des probabilités individuelles faibles. Cela favorise la diversité.
- Top P bas (proche de 0) : Le bassin est restreint aux tokens les plus probables. La sortie est plus restreinte et prévisible.
Combinaison typique : Utiliser une température modérée (0.7-0.9) avec un Top P modéré (0.8-0.95) permet souvent d'obtenir un bon équilibre entre cohérence et originalité.
Capacités Avancées des Modèles Conversationnels
Accès en Temps Réel (Recherche en Ligne)
Pour dépasser la date de coupure des données d'entraînement, les systèmes intègrent un mécanisme de récupération d'informations externes. Lorsqu'une question nécessite des données récentes, le système la décompose en requêtes de recherche, interroge une API moteur de recherche (ex: Google), et injecte les résultats obtenus comme contexte dynamique pour le LLM. Ce dernier résume et intègre ensuite l'information pour fournir une réponse actualisée.
Traitement de Documents (RAG)
Grâce à la technique RAG (Retrieval-Augmented Generation), le système peut analyser des fichiers uploadés (PDF, Word...). Le contenu est segmenté en blocs de texte, converti en vecteurs numériques via un modèle d'embedding, puis stocké dans une base de données vectorielle. À la réception d'une question, celle-ci est également vectorisée. Une recherche de similarité effectuée dans la base permet de retrouver les segments de document les plus pertinents, qui sont fournis au LLM pour générer une réponse précise et ancrée dans les données du document.
Mémoire et Personalisation
Les LLM étant fondamentalement sans état, la continuité conversationnelle est assurée par une stratégie de mémoire en couches. La « mémoire à court terme » est constituée en envoyant un historique récent des échanges (la fenêtre de contexte) au modèle à chaque tour. Pour les informations nécessitnat une rétention à long terme (préférences utilisateur), le système utilise des algorithmes d'extraction pour les identifier et les stocker dans une base dédiée. Ces informations sont rappelées lors des interactions futures pour personnaliser les réponses du modèle.
Intégration par API : Exemples Pratiques
Analyse de Sentiment
L'API DashScope (Model-as-a-Service d'Alibaba Cloud) permet d'accéder à divers modèles dont DeepSeek-V3. L'intégration se fait en installant la librairie dashscope, en configurant une clé API via une variable d'envirronement, puis en construisant une requête structurée.
Exemple de code pour classifier le sentiment d'un commentaire produit :
import os
import dashscope
# Configuration de l'API
cle_api = os.getenv("DASHSCOPE_API_KEY")
dashscope.api_key = cle_api
texte_commentaire = "Le son de cet appareil est incroyable, une qualité inattendue."
contexte_messages = [
{"role": "system", "content": "Vous êtes un analyste de sentiment. Répondez par un seul mot : Positif ou Négatif."},
{"role": "user", "content": texte_commentaire}
]
# Appel au modèle DeepSeek-V3 via l'API DashScope
reponse_api = dashscope.Generation.call(
model='deepseek-v3',
messages=contexte_messages,
result_format='message'
)
# Extraction du résultat
resultat_final = reponse_api.output.choices[0].message.content
print(resultat_final)
Les principaux paramètres de la fonction call() incluent model, messages (la liste des dictionnaires rôle-contenu) et temperature. La réponse est un objet dont on extrait le contenu via le chemin .output.choices[0].message.content.
Appels de Fonctions (Function Calling)
Cette fonctionnalité permet au LLM de demander l'exécution de fonctions externes définies par l'utilisateur. Le flux de travail implique une communication en plusieurs étapes :
- L'utilisateur pose une question nécessitant une action externe.
- Le modèle analyse la question et, s'il détermine qu'une fonction est requise, génère un appel structuré avec les arguments appropriés (nom de la fonction, paramètres en JSON).
- L'application côté serveur exécute la fonction appelée (ex: interroger une API météo) et obtient un résultat.
- Le résultat de la fonction est renvoyé au modèle dans un nouveau message de type « function ».
- Le modèle intègre ce résultat pour formuler la réponse finale à l'utilisateur.
Exemple de code illustrant un système de consultation météo :
import json
import os
import dashscope
cle_api = os.getenv("DASHSCOPE_API_KEY")
dashscope.api_key = cle_api
# Définition d'une fonction fictive pour la démonstration
def obtenir_meteo_actuelle(lieu, unite="celsius"):
donnees = {"lieu": lieu, "temperature": 22, "unite": unite, "previsions": ["Ensoleillé"]}
if "Paris" in lieu:
donnees["temperature"] = 18
elif "Lyon" in lieu:
donnees["temperature"] = 20
return json.dumps(donnees)
# Schéma des fonctions disponibles pour le modèle
catalogue_fonctions = [
{
"name": "obtenir_meteo_actuelle",
"description": "Récupère la météo actuelle pour une localisation donnée.",
"parameters": {
"type": "object",
"properties": {
"lieu": {"type": "string", "description": "La ville, ex: Paris, France"},
"unite": {"type": "string", "enum": ["celsius", "fahrenheit"]}
},
"required": ["lieu"]
}
}
]
# Exécution de la conversation avec appel de fonction
requete_utilisateur = "Quel temps fait-il à Paris ?"
historique = [{"role": "user", "content": requete_utilisateur}]
# Premier appel au modèle
reponse = dashscope.Generation.call(
model='qwen-max',
messages=historique,
functions=catalogue_fonctions,
result_format='message'
)
message_modele = reponse.output.choices[0].message
historique.append(message_modele)
# Vérification si le modèle demande un appel de fonction
if hasattr(message_modele, 'function_call') and message_modele.function_call:
appel_fonction = message_modele.function_call
nom_fonction = appel_fonction['name']
arguments = json.loads(appel_fonction['arguments'])
# Exécution de la fonction côté application
resultat_fonction = obtenir_meteo_actuelle(
lieu=arguments.get('lieu'),
unite=arguments.get('unite')
)
# Envoi du résultat de la fonction au modèle
historique.append({
"role": "function",
"name": nom_fonction,
"content": resultat_fonction
})
# Second appel au modèle pour obtenir la réponse finale
reponse_finale = dashscope.Generation.call(
model='qwen-max',
messages=historique,
functions=catalogue_fonctions,
result_format='message'
)
message_final = reponse_finale.output.choices[0].message
print("Réponse finale:", message_final.content)