Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 1 addition & 20 deletions MyIA.AI.Notebooks/GenAI/SemanticKernel/fort-boyard-csharp.ipynb
Original file line number Diff line number Diff line change
Expand Up @@ -440,25 +440,6 @@
"\n"
]
},
{
"cell_type": "markdown",
"id": "ef9f8d8c",
"metadata": {},
"source": [
"### Lecture — l'orchestrateur alterne les agents tout seul\n",
"\n",
"La sortie committée montre **3 tours** :\n",
"1. **Père Fouras** : une charade en 4 parties (« Mon premier est le contraire de pro… Mon quatrième se termine par ment »). Le modèle a *inventé* sa propre charade — elle ne décompose pas `Anticonstitutionnellement` de façon canonique, mais reste cohérente.\n",
"2. **Laurent Jalabert** : propose « amendement » — **faux** mais proche (le mot commence par une longue suite de lettres).\n",
"3. **Père Fouras** : encourage (« Tu t'approches ») sans révéler — la stratégie de sélection lui redonne la parole automatiquement.\n",
"\n",
"Ce que le code fait et que l'output démontre :\n",
"- **`chat.ResetAsync()` + `chat.IsComplete = false`** : on repart d'un historique vide — rejouer la cellule relance une partie fraîche.\n",
"- **`await foreach (var content in chat.InvokeAsync())`** : la boucle consomme un flux asynchrone. L'orchestrateur décide *à chaque tour* quel agent parle (sélection) et s'il faut s'arrêter (terminaison). Le code ne dicte pas l'ordre.\n",
"- **`content.AuthorName`** : rend la trace lisible (`Pere_Fouras` / `Laurent_Jalabert`). C'est le `Name` posé en cell 9 — sans lui, la trace serait indistinguible.\n",
"- **La terminaison n'a pas déclenché** : Laurent n'a pas dit `Anticonstitutionnellement` — la sortie s'arrête à 3 tours (output tronqué, l'itération continue au-delà). Le `MaximumIterations = 10` protège contre une partie infinie."
]
},
{
"cell_type": "markdown",
"metadata": {},
Expand Down Expand Up @@ -568,4 +549,4 @@
},
"nbformat": 4,
"nbformat_minor": 2
}
}
27 changes: 0 additions & 27 deletions MyIA.AI.Notebooks/GenAI/Texte/13_Agentic_Orchestration.ipynb
Original file line number Diff line number Diff line change
Expand Up @@ -490,15 +490,6 @@
"print(f\"(4) import os : ({p}/{t}) {e}\")"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"**LECTURE ANCRÉE — Validation expérimentale des garde-fous d'exécution**\n",
"\n",
"La démonstration ci-dessus valide expérimentalement trois scénarios distincts et critiques avec la fonction `executer_tests_detaille`, chacun produisant une sortie commité qui sert de preuve objective et reproductible. Le premier cas, avec le code honnête `def carre(n): return n * n`, passe les 2 tests définis dans le dictionnaire `PB_DEMO` (carre(4)==16 et carre(0)==0), confirmant que l'implémentation simple et directe est correcte, avec un score parfait de 2/2. Le deuxième scénario injecte intentionnellement une boucle infinie (`while True: pass`), qui est interceptée et interrompue de force après exactement 3 secondes par le mécanisme de timeout intégré, retournant un score de 0/2 tests passés avec la mention verbatim et commitée : `interrompue de force apres 3.0s`. Cette interruption prouve que le garde-fou anti-boucle fonctionne correctement et empêche une exécution indéfinie qui aurait pu bloquer le noyau. Le troisième cas tente un accès disque non autorisé via `open()`, qui déclenche une exception de type `NameError` interceptée par le système d'exécution robuste, résultant en un échec contrôlé avec 0/2 tests. Ces trois résultats, commités tels quels dans le notebook, démontrent de manière tangible que l'infrastructure d'exécution est robuste face à différents types d'erreurs : code correct, boucle infinie, et opération interdite. Cette robustesse offre un environnement sûr pour l'exécution de code non fiable."
]
},
{
"cell_type": "markdown",
"id": "8185f3e1",
Expand Down Expand Up @@ -1001,15 +992,6 @@
" print(etape)"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"**LECTURE ANCRÉE — Mécanisme de routage pour les tâches combinatoires**\n",
"\n",
"La trace d'exécution complète ci-dessus montre comment l'agent `agent_routeur` résout automatiquement et efficacement un problème de type 24-game avec les nombres [4, 7, 8, 8]. Dès le premier tour de la boucle d'exécution, l'agent sélectionne de manière déterministe l'outil `resoudre_tot_24` avec les arguments précis `{'nombres': [4, 7, 8, 8]}`, démontrant une détection correcte et immédiate du type de problème. Le résultat retourné par l'outil, visible dans la sortie commité, indique `solution_trouvee: True`, confirmant que l'outil spécialisé a réussi à trouver une combinaison valide pour atteindre exactement 24. Au deuxième tour, l'agent émet la réponse finale textuelle verbatim : `Solution trouvée: 4 × (7 - 8/8) = 24.` — accompagnée de `(Utilise les nombres 4, 7, 8 et 8 une fois chacun.)`. Cette solution, générée par le moteur ToT (Tree of Thoughts), est mathématiquement correcte et vérifiable. Ce comportement illustre parfaitement le mécanisme de sélection d'outil basé sur des règles explicites : la présence dans la requête des mots-clés '24-game' combinée à une liste de nombres déclenche systématiquement et sans ambiguïté le choix de `resoudre_tot_24`. Ce dernier est spécialement conçu pour ce type de problème combinatoire nécessitant une exploration exhaustive des combinaisons possibles. L'efficacité exceptionnelle du routage se mesure par le fait que la solution complète est obtenue en seulement 2 tours (1 appel d'outil pour la résolution + 1 tour pour la réponse finale), sans itération."
]
},
{
"cell_type": "code",
"execution_count": 10,
Expand Down Expand Up @@ -1108,15 +1090,6 @@
" print(etape)"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"**LECTURE ANCRÉE — Adaptation intelligente du choix d'outil par diagnostic**\n",
"\n",
"La démonstration fizzbuzz illustrée par les sorties commitées ci-dessus présente un cas différent et instructif de routage où l'agent sélectionne l'outil `resoudre_reflexion` plutôt que `resoudre_best_of_n` ou `resoudre_tot_24`. Dès le premier tour d'exécution, l'agent identifie avec précision que le problème 'fizzbuzz' (générer une séquence de nombres avec des règles de remplacement spécifiques : multiples de 3 → 'Fizz', multiples de 5 → 'Buzz', multiples des deux → 'FizzBuzz') relève de la catégorie des problèmes de génération de code nécessitant une approche par réflexion itérative. Les arguments passés à l'outil, tels qu'affichés dans la sortie, sont `{'id_probleme': 'fizzbuzz', 'iterations': 3}`. Ces paramètres déclenchent le moteur de réflexion avec exactement 3 itérations d'auto-amélioration successives. Le résultat commité montre que le code généré passe les 2 tests définis pour ce problème, avec un coût total de 84 tokens consommés lors du processus. Ce choix d'outil, différent de celui du 24-game, démontre la capacité remarquable de l'agent à distinguer automatiquement entre plusieurs catégories : les problèmes combinatoires (ToT), les problèmes de code nécessitant une recherche approfondie (Réflexion), et les problèmes plus simples (Best-of-N). La règle de choix de `SYSTEME_AGENT` distingue verbatim : « Probleme de code ou l'erreur est systematique / conceptuelle -> resoudre_reflexion » contre « Probleme de code ou le single-shot echoue par variance -> resoudre_best_of_n » — l'agent a orienté le fizzbuzz vers la première branche, et le résultat (2/2 passes, 84 tokens) valide pragmatiquement ce choix. Cette capacité d'adaptation dynamique et contextuelle entre différents moteurs est précisément au cœur de l'orchestration agentique moderne et représente un progrès significatif par rapport aux systèmes statiques."
]
},
{
"cell_type": "markdown",
"id": "nb13-demo-synthesis-c831",
Expand Down
49 changes: 0 additions & 49 deletions MyIA.AI.Notebooks/GenAI/Texte/17_Native_Reasoning_vs_Scaling.ipynb
Original file line number Diff line number Diff line change
Expand Up @@ -154,13 +154,6 @@
"**Lecture** : La configuration a chargé les variables depuis `.env`. Le baseline non-reasoning est `meta-llama/llama-3.3-70b-instruct` et le modèle de raisonnement est `deepseek/deepseek-r1`. Le mode BATCH est activé pour une comparaison équitable entre les deux approches."
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"**Lecture supplémentaire** : La configuration des variables d'environnement permet une flexibilité maximale pour les tests. Le fichier `.env` contient les paramètres spécifiques à l'environnement d'exécution, tandis que le mode BATCH permet une évaluation systématique et reproductible des modèles."
]
},
{
"cell_type": "code",
"execution_count": 2,
Expand Down Expand Up @@ -242,13 +235,6 @@
"**Lecture** : Pour un même énoncé, les deux modèles répondent `391` — mais `llama-3.3-70b-instruct` y consomme 31 tokens (dont 0 de raisonnement), tandis que `deepseek-r1` utilise 853 tokens dont 531 pour le raisonnement interne. Cela illustre le surcoût en tokens du raisonnement natif par rapport à l'inférence directe."
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"**Lecture supplémentaire** : La comparaison des token counts entre les deux modèles est révélatrice. Le modèle `deepseek-r1` utilise 27,5 fois plus de tokens (853/31 ≈ 27,5) que `llama-3.3-70b-instruct` pour le même prompt, et 531 de ces 853 tokens sont dédiés au raisonnement interne. Cela démontre que le raisonnement natif implémente une approche de résolution de problème plus intensive en calcul, mais potentiellement plus robuste pour les tâches complexes."
]
},
{
"cell_type": "markdown",
"id": "c37df8f0",
Expand Down Expand Up @@ -344,13 +330,6 @@
"**Lecture** : La configuration des problèmes utilise 6 échantillons par problème, répartis dans 3 buckets de difficulté : facile, moyen, difficile. L'héritage de NB-16 garantit une comparaison équitable avec des benchmarks précédents."
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"**Lecture** : La collecte des échantillons pour le baseline non-reasoning a réussi pour tous les buckets : facile, moyen, difficile. Chaque problème reçoit 6 échantillons (2 problèmes par bucket), et la collecte a été validée. Le tableau suivant montre les métriques pass@k pour chaque bucket, avec des tokens cumulés moyens. On observe que le bucket difficile a des performances limitées (25% à pass@1, 50% à pass@4/6)."
]
},
{
"cell_type": "markdown",
"id": "1691bde3",
Expand Down Expand Up @@ -562,27 +541,13 @@
" f\"avg total_tokens={avg_tok:.0f} (dont reasoning={avg_rt:.0f})\")"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"**Lecture supplémentaire** : Le fait que `deepseek-r1` obtienne 100% de réussite sur tous les buckets en single-shot, malgré des ratios de raisonnement différents (74%, 80%, 90%), suggère une capacité exceptionnelle à résoudre des problèmes de difficulté variable. Le nombre absolu de tokens de raisonnement augmente considérablement avec la difficulté : 172 pour facile, 442 pour moyen, 1094 pour difficile."
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"**Lecture** : Le raisonnement natif avec `deepseek-r1` atteint 100% de réussite en single-shot pour tous les buckets (facile, moyen, difficile), avec respectivement 232, 553 et 1213 tokens totaux. Le ratio raisonnement/tokens totaux est élevé : 172/232 (74%) pour facile, 442/553 (80%) pour moyen, et 1094/1213 (90%) pour difficile, démontrant que le modèle utilise intensément le raisonnement pour les problèmes complexes."
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"**Lecture complémentaire** : La structure du coût par bucket est révélatrice — la part hors raisonnement (total moins reasoning) reste quasi stable : 60 tokens en facile (232-172), 111 en moyen (553-442), 119 en difficile (1213-1094) — alors que le budget de raisonnement passe de 172 à 1094 (x6,4) : l'escalier de coût 232 -> 553 -> 1213 est porté par le raisonnement, pas par l'énoncé ni la réponse."
]
},
{
"cell_type": "markdown",
"id": "088b0847",
Expand Down Expand Up @@ -689,13 +654,6 @@
"**Lecture** : La visualisation compare les deux approches. La courbe représente le BoN (scaling externe manuel), tandis que la croix représente le raisonnement natif (r1). Pour chaque bucket, si la croix est au-dessus de la courbe au même coût, le raisonnement natif est plus efficace."
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"**Lecture supplémentaire** : Le mode BATCH permet une évaluation systématique et reproductible des modèles sur un ensemble de problèmes. Contrairement à une évaluation interactive, le mode BATCH utilise des prompts prédéfinis et collecte les résultats de manière automatique, ce qui élimine le biais de l'interaction humaine et permet une comparaison objective entre différents modèles et approches."
]
},
{
"cell_type": "code",
"execution_count": 7,
Expand Down Expand Up @@ -759,13 +717,6 @@
"**Lecture** : Le verdict cost-normalisé montre que pour le bucket `difficile`, le raisonnement natif (`r1`) avec 1213 tokens obtient 100% de réussite, tandis que le BoN avec 438 tokens n'obtient que 50%. Les buckets `facile` et `moyen` montrent une égalité entre les deux approches, mais la méthode de comparaison cost-normalisée (tokens incluant le raisonnement) reste valide malgré le bruit dû au petit échantillon."
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"**Lecture supplémentaire** : L'utilisation de `deepseek-r1` en mode single-shot pour le raisonnement natif démontre une approche efficace où le modèle génère sa réponse en une seule passe, mais avec un raisonnement interne substantiel. Cette approche contraste avec les méthodes de scaling manuel où l'on essaie plusieurs prompts ou configurations pour obtenir un résultat satisfaisant."
]
},
{
"cell_type": "markdown",
"id": "ff222a9f",
Expand Down
Loading