doc(choixllm)
This commit is contained in:
gwen
parent
4f1a15891d
commit
6f0ccbd535
4 changed files with 92 additions and 25 deletions
|
|
@ -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 .
|
||||
|
|
|
|||
45
doc/ChoixLllmAgentique.md
Normal file
45
doc/ChoixLllmAgentique.md
Normal file
|
|
@ -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 ?
|
||||
|
|
@ -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 .
|
||||
|
|
@ -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`
|
||||
|
|
|
|||
Loading…
Reference in a new issue