From 6f0ccbd535d6ce4846b6465262194a828a68e567 Mon Sep 17 00:00:00 2001 From: gwen Date: Mon, 14 Sep 2026 09:39:43 +0200 Subject: [PATCH] doc(choixllm) --- doc/ChoixLllm.md | 23 ++++++++++++++++++++ doc/ChoixLllmAgentique.md | 45 +++++++++++++++++++++++++++++++++++++++ doc/ChoixLllmQuery.md | 24 --------------------- doc/Experiments.md | 25 +++++++++++++++++++++- 4 files changed, 92 insertions(+), 25 deletions(-) create mode 100644 doc/ChoixLllmAgentique.md delete mode 100644 doc/ChoixLllmQuery.md diff --git a/doc/ChoixLllm.md b/doc/ChoixLllm.md index b1906b0..2022927 100644 --- a/doc/ChoixLllm.md +++ b/doc/ChoixLllm.md @@ -27,4 +27,27 @@ Voici une sélection de modèles pour différents niveaux de matériel, du plus Pour lancer l'un de ces modèles, utilisez simplement la commande : `ollama run deepseek-r1:7b` (en remplaçant `7b` par la taille choisie). +--- +question: quel distilled 7b prendre sachant que je vais faire demander au llm de faire des query sur un storage (db graph ou nsql) + +--- + +Pour votre cas d'usage précis (génération de requêtes pour bases de données graph ou NoSQL), un modèle standard comme `deepseek-r1:7b` risque d'être insuffisant. La version `deepseek-r1:7b-qwen`, qui supporte le **function calling**, est un bien meilleur point de départ . + +Voici un comparatif pour vous aider à choisir : + +| Modèle | Atout principal pour votre cas | Inconvénient / Point d'attention | +| :--- | :--- | :--- | +| **`deepseek-r1:7b`** (standard) | Raisonnement général puissant, utile pour décomposer une requête complexe. | **Ne supporte pas nativement le function calling**, ce qui complexifie l'intégration avec votre storage. Vous devrez "bricoler" une solution pour extraire la requête . | +| **`deepseek-r1:7b-qwen`** (avec function calling) | **Support natif du function calling**. Conçu pour appeler des outils externes (comme votre base de données), la sortie est structurée et facile à interpréter . | Moins de recul sur ses performances spécifiques pour le Text-to-SQL/NoSQL, mais c'est l'architecture la plus adaptée. | +| **`prav719/deepseek-7B-text-to-sql-flash-attention-2`** (fine-tuné) | **Spécialisé Text-to-SQL**. Fine-tuné sur cette tâche précise, il devrait être plus performant et fiable pour générer des requêtes . | Nécessite plus de configuration (fichier Modelfile) pour fonctionner avec Ollama. L'usage est moins "plug-and-play". | + +### 💡 Mon conseil + +1. **Pour une approche rapide et intégrée** : Testez en premier le modèle `deepseek-r1:7b-qwen` sur Ollama. La commande est `ollama run deepseek-r1:7b-qwen` . Sa capacité à comprendre et à formater un appel d'outil est un atout majeur pour votre projet. +2. **Pour un projet ambitieux ou professionnel** : Si le modèle généraliste n'est pas assez fiable, envisagez d'utiliser le modèle fine-tuné `prav719/deepseek-7B-text-to-sql-flash-attention-2`. Il a été entraîné spécifiquement pour la génération de requêtes SQL, ce qui devrait vous donner de meilleurs résultats, quitte à passer un peu plus de temps sur la configuration initiale . + +### ⚠️ Important : le "prix" du raisonnement + +Les modèles DeepSeek R1 sont des "modèles de raisonnement". Cela signifie qu'ils génèrent une chaîne de pensée (entre balises `think`) avant de répondre . C'est excellent pour la précision, mais cela ralentit le temps de réponse et allonge les réponses. C'est un compromis à garder en tête par rapport à un modèle plus direct comme Llama . diff --git a/doc/ChoixLllmAgentique.md b/doc/ChoixLllmAgentique.md new file mode 100644 index 0000000..316916a --- /dev/null +++ b/doc/ChoixLllmAgentique.md @@ -0,0 +1,45 @@ +--- + +mon use case est : (je demande à l'agent de :) +- de lire un fichier markdown. Ce fichier markdown décrit un ensemble de variables. +- je demande ensuite à l'agent de me récupérer des variables ou groupes de variables. + +ce que je voudrais privilégier aussi, c'est la rapidité + +--- + +Pour votre cas d'usage précis — lire un fichier Markdown décrivant des variables, puis extraire des variables ou groupes de variables à la demande — la rapidité est effectivement un critère clé, et le raisonnement complexe de modèles comme DeepSeek-R1 est largement superflu. + +Voici mes recommandations, du plus léger au plus équilibré. + +### 🎯 Recommandation principale : MiniCPM5-2B + +MiniCPM5-2B est un modèle de 2,52 milliards de paramètres, récemment open-sourcé (septembre 2026) par OpenBMB . Il présente plusieurs avantages décisifs pour votre use case : + +- **Extrêmement léger et rapide** : conçu pour le déploiement local sur appareils aux ressources limitées . +- **Excellent en agentique et appels d'outils** : il obtient un score de 20 sur l'Agentic Index, surpassant des modèles 4 à 6 fois plus gros comme Qwen3.5 9B ou Gemma 4 12B . +- **Efficacité en tokens** : il consomme environ 21k tokens de sortie pour les tâches de l'Intelligence Index, contre 34k pour Qwen3.5 9B, ce qui se traduit directement par une latence plus faible . +- **Bonne fenêtre de contexte** : 131 072 tokens, suffisant pour votre fichier Markdown . + +Disponible via Ollama, LM Studio, llama.cpp et Apple Silicon, son intégration est simple . + +### ⚡ Alternative ultra-légère : Qwen3-0.6B-JSON-SFT-GRPO + +Si vous voulez pousser la rapidité à l'extrême, ce modèle de 0,8 milliard de paramètres est **spécifiquement fine-tuné pour le suivi d'instructions JSON** . Il est particulièrement adapté aux tâches d'extraction de données structurées, ce qui correspond exactement à votre besoin de récupérer des variables à partir d'un fichier Markdown. Avec seulement 0,8B de paramètres, sa vitesse d'inférence sera difficile à battre. La contrepartie est une capacité de raisonnement plus limitée, mais pour de l'extraction directe de variables, c'est rarement un problème. + +### 🔧 Alternative polyvalente : Ring-lite-distill-preview + +Si vous souhaitez conserver un peu plus de robustesse pour des cas limites (par exemple, des demandes d'extraction ambiguës ou des groupes de variables complexes), Ring-lite-distill-preview reste une option intéressante. Avec 16,8B de paramètres totaux mais seulement **2,75B activés** grâce à son architecture MoE, il offre un excellent équilibre vitesse/qualité, et surtout d'excellentes performances en suivi d'instructions et appels de fonctions . Il est plus lourd que MiniCPM5-2B, mais plus léger à l'usage que DeepSeek-R1-Distill-Qwen-7B. + +### ⚙️ Conseils d'implémentation + +1. **Désactivez le mode raisonnement** : comme le souligne la documentation de Knwler, « le mode réflexion est désactivé par défaut ; il ajoute de la latence sans améliorer la qualité » pour les tâches d'extraction . C'est un point crucial pour votre use case. +2. **Soignez le prompt d'extraction** : pour les tâches d'extraction structurée, la pratique recommandée est de fournir le texte d'entrée, de spécifier le schéma JSON exact attendu, d'inclure un exemple few-shot, et de demander au modèle de ne produire que du JSON, sans préambule . +3. **Prévoyez un post-traitement robuste** : les petits modèles produisent parfois des sorties avec des tokens parasites ou des accolades non fermées. Un nettoyage léger côté code est recommandé . +4. **Utilisez spaCy pour l'extraction simple** : si vos variables sont clairement identifiables (par exemple, des définitions `variable: valeur`), vous pourriez même envisager une approche hybride où spaCy extrait les entités de manière déterministe, et le LLM n'intervient que pour les cas ambigus . + +### 💡 En résumé + +Pour votre besoin de lire un Markdown et d'en extraire des variables rapidement, **MiniCPM5-2B** est le meilleur compromis actuel : il est très léger, rapide, et ses capacités agentiques sont remarquables pour sa taille. Si la vitesse pure est votre priorité absolue et que vos extractions sont simples, **Qwen3-0.6B-JSON-SFT-GRPO** sera encore plus rapide. Dans les deux cas, pensez à désactiver le mode raisonnement et à structurer vos prompts pour une sortie JSON directe. + +Souhaitez-vous que je vous aide à formuler le prompt système optimal pour votre agent, ou à comparer ces modèles sur un exemple concret de votre fichier Markdown ? diff --git a/doc/ChoixLllmQuery.md b/doc/ChoixLllmQuery.md deleted file mode 100644 index c6e8f70..0000000 --- a/doc/ChoixLllmQuery.md +++ /dev/null @@ -1,24 +0,0 @@ ---- - -question: quel distilled 7b prendre sachant que je vais faire demander au llm de faire des query sur un storage (db graph ou nsql) - ---- - -Pour votre cas d'usage précis (génération de requêtes pour bases de données graph ou NoSQL), un modèle standard comme `deepseek-r1:7b` risque d'être insuffisant. La version `deepseek-r1:7b-qwen`, qui supporte le **function calling**, est un bien meilleur point de départ . - -Voici un comparatif pour vous aider à choisir : - -| Modèle | Atout principal pour votre cas | Inconvénient / Point d'attention | -| :--- | :--- | :--- | -| **`deepseek-r1:7b`** (standard) | Raisonnement général puissant, utile pour décomposer une requête complexe. | **Ne supporte pas nativement le function calling**, ce qui complexifie l'intégration avec votre storage. Vous devrez "bricoler" une solution pour extraire la requête . | -| **`deepseek-r1:7b-qwen`** (avec function calling) | **Support natif du function calling**. Conçu pour appeler des outils externes (comme votre base de données), la sortie est structurée et facile à interpréter . | Moins de recul sur ses performances spécifiques pour le Text-to-SQL/NoSQL, mais c'est l'architecture la plus adaptée. | -| **`prav719/deepseek-7B-text-to-sql-flash-attention-2`** (fine-tuné) | **Spécialisé Text-to-SQL**. Fine-tuné sur cette tâche précise, il devrait être plus performant et fiable pour générer des requêtes . | Nécessite plus de configuration (fichier Modelfile) pour fonctionner avec Ollama. L'usage est moins "plug-and-play". | - -### 💡 Mon conseil - -1. **Pour une approche rapide et intégrée** : Testez en premier le modèle `deepseek-r1:7b-qwen` sur Ollama. La commande est `ollama run deepseek-r1:7b-qwen` . Sa capacité à comprendre et à formater un appel d'outil est un atout majeur pour votre projet. -2. **Pour un projet ambitieux ou professionnel** : Si le modèle généraliste n'est pas assez fiable, envisagez d'utiliser le modèle fine-tuné `prav719/deepseek-7B-text-to-sql-flash-attention-2`. Il a été entraîné spécifiquement pour la génération de requêtes SQL, ce qui devrait vous donner de meilleurs résultats, quitte à passer un peu plus de temps sur la configuration initiale . - -### ⚠️ Important : le "prix" du raisonnement - -Les modèles DeepSeek R1 sont des "modèles de raisonnement". Cela signifie qu'ils génèrent une chaîne de pensée (entre balises `think`) avant de répondre . C'est excellent pour la précision, mais cela ralentit le temps de réponse et allonge les réponses. C'est un compromis à garder en tête par rapport à un modèle plus direct comme Llama . diff --git a/doc/Experiments.md b/doc/Experiments.md index bbb58d8..b8d5a9e 100644 --- a/doc/Experiments.md +++ b/doc/Experiments.md @@ -3,12 +3,35 @@ ## Quel LLM pour les expériences ? - L'outil utilisé pour les expériences est ollama -- Le LLM utilisé pour les expériences est deepseek-r1:7b. +- Le LLM utilisé pour les expériences est `deepseek-r1:7b` et aussi le distilled deepseek-r1 qwen. Pourquoi un reasoning model ? Pour voir les "inner thoughts" du model. Pour voir s'il "comprend" correctement la question. On passera à un truc plus léger ultérieurement. +Tests des LLM plus légers: + +- phi3-medium : trop lent +- mistral 7b : peu pertinent malheureusement: + +``` + >>> what is the HTTPS Proxy variables' group name ? + The HTTPS Proxy variables are part of the "Manual proxy configuration" group. +``` + +- maternion/minicpm5:2b plutôt pas mal, même si ses "inner thouths" sont un peu bizarre + +``` + The HTTPS Proxy variables belong to the group named **HTTPS Proxy**. +``` +- phi3: c'est dur de l'admettre (c'est le modèle open source de microsoft) + mais il a l'air de donner de bon résultats: + +``` +>>> what is the HTTPS Proxy variables' group name ? +The group name for the HTTPS Proxy variables is "manual.https_proxy". +``` + ## installation de ollama `curl https://ollama.ai/install.sh | sh`