7d. Mémoire & Cognition

Cette famille d'outils est le cœur cognitif de l'Arsenal. Elle permet à ECHO de maintenir une mémoire persistante entre les sessions (RAG organique), de gérer les données de travail à l'intérieur d'une session (RAG éphémère), et de déléguer des tâches complexes à un niveau cognitif supérieur (routage dynamique).

RAG Organique — `echo_memory`

La mémoire organique est la mémoire à long terme d'ECHO. Les souvenirs y sont stockés avec un niveau d'importance (1–5) qui influence leur rappel et leur durée de vie. Ils persistent entre toutes les sessions, indépendamment du chat courant.

Outil	Description
`save_memory(fact, importance)`	Vectorise et stocke un souvenir dans `echo_memory`. Utilise un UUID déterministe (UUIDv5) basé sur le `memory_id` technique distillé — un appel avec le même `memory_id` remplace le souvenir existant (upsert). Paramètre `importance` de 1 (Trivial) à 5 (Axiome), défaut 1.
`search_memory(query, limit)`	Recherche sémantique dans `echo_memory`. Over-fetch ×3 puis reranking par `cos_score × MEMORY_IMPORTANCE_WEIGHTS[lvl]`. Paramètre `limit` (défaut 5).
`list_memory_topics(scope)`	Liste les thèmes mémorisés (`memory_id`, tags, niveau d'importance). Paramètre `scope` optionnel, défaut `"global"`. Utile avant un `forget_memory` pour retrouver l'identifiant exact.
`forget_memory(memory_id)`	Supprime définitivement un souvenir de la collection Qdrant par son `memory_id`. Irréversible. L'identifiant exact est requis — utiliser `list_memory_topics` pour le retrouver si inconnu.

RAG Éphémère — `echo_ephemeral`

La mémoire éphémère est la mémoire de travail d'une session. Elle stocke les distillats de fichiers volumineux, les résultats intermédiaires de navigation et toute donnée volumineuse qu'il serait coûteux de maintenir dans le contexte actif. Elle est automatiquement purgée en fin de session par l'Admin Manager.

Outil	Description
`save_session_context(text, source_id)`	Indexe du texte dans `echo_ephemeral`, partitioné par `user_id + chat_id + source_id`. Le texte est découpé automatiquement en chunks sémantiques. Paramètre `text` en premier, `source_id` en second (identifiant natif du fichier).
`search_session_context(source_id, query)`	Recherche sémantique dans la partition du `source_id` courant. Retourne les chunks les plus pertinents au-dessus du `SCORE_THRESHOLD` (défaut 0.45).

Usage canonique du RAG éphémère

Lorsque le Filtre effectue l'extraction transmodale et le Map-Reduce d'un fichier volumineux, il utilise le source_id natif (ex. U_abc123_C_xyz789_T_1748246400) et indexe les chunks bruts dans echo_ephemeral. Le modèle reçoit ce source_id dans l'AEC (registre_fichiers) et l'utilise pour interroger les détails précis de la source brute : search_session_context("U_abc123_C_xyz789...", "..."). Ce mécanisme remplace avantageusement l'injection du fichier complet dans le contexte, qui serait prohibitive en tokens.

Routage Cognitif — `new_cognitive_level`

L'outil new_cognitive_level(target_model, transfer_plan) permet à un modèle de déclarer qu'il est dépassé par la tâche courante et de demander une escalade vers un niveau cognitif supérieur. Le Pipe intercepte cet appel, injecte le transfer_plan (Markdown structuré rédigé par le modèle sortant) dans le contexte du modèle cible, et relance la génération sans redémarrer la boucle complète.

Modèle source	Modèles cibles possibles	Déclencheur typique
`MODEL_LITE`	`MODEL_FLASH`, `MODEL_PRO`	Tâche dépassant les capacités de raisonnement de Lite.
`MODEL_FLASH`	`MODEL_PRO`	Architecture multicouche complexe, raisonnement philosophique profond.

⚙️ Mémoire duale et Vallée de la Mort

La combinaison des deux RAG est la réponse architecturale à la Vallée de la Mort Contextuelle. save_session_context doit être utilisé proactivement dès qu'une information volumineuse risque de saturer le contexte (au-delà de ~30 % de remplissage). search_memory couvre les informations des sessions antérieures, totalement absentes du contexte actif.

Topologie Vectorielle (Qdrant) [Stockage]

flowchart TD O["Outils Cognitifs
(memory_and_rag_tool)"] --> |save_memory
search_memory| COL1 O --> |save_session_context
search_session_context| COL2 subgraph Q["Qdrant Engine (Port 6333)"] COL1[("🧠 echo_memory
Mémoire long terme
TTL, Consolidation, Importance")] COL2[("⏳ echo_ephemeral
RAG de session
Map-Reduce, source_id, Purge auto")] end classDef db fill:#0f172a,stroke:#3b82f6,color:#f8fafc class COL1,COL2 db

Agents Cognitifs — `cognitive_agents.py`

Le Conseil d'Experts est un système d'orchestration cognitive dédié permettant de déléguer des tâches à des instances Gemini spécialisées selon trois modes : stateless (délégation simple), boucle itérative 1:1 avec mémoire de thread (consultation d'expert), ou table ronde N:N multi-tours (conseil). Les thoughtSignature Gemini sont capturées et réinjectées à chaque tour pour maintenir la cohérence du raisonnement sans inclure les pensées en texte brut (includeThoughts: false).

Outil	Description
`delegate_to_subagent(task, system_prompt, sub_sid)`	Délégation cognitive stateful (depuis `delegate_tool.py` v1.0, remplace `delegate_reasoning` supprimée en v5.14). Boucle agentique complète avec accès aux outils, budget d'appels configurable, montée cognitive LITE→FLASH→PRO. Persistance de l'historique de thread dans SQLite (`cognitive_threads`). Protocole `QUESTION:` pour les clarifications.
`consult_expert_consultant(role_name, prompt, sub_sid, target_model)`	Consultation d'un expert Skill avec mémoire de thread persistante. Si `sub_sid` est fourni, reprend le fil de discussion existant. Le contexte est distillé depuis la branche active du chat principal avant chaque appel. Boucle itérative jusqu'à la balise `<FINAL_ANSWER>`.
`consult_council(question, participants, target_model, synthesis_model)`	Table Ronde Multi-Experts (protocole Delphi). Convoque N experts (2–5, CSV de skill_ids) pour une délibération en tours parallélisés. Prérequis : au minimum 2 participants distincts — si moins de 2 skills sont fournis, l'outil retourne une erreur actionnable incluant la liste des skills disponibles et une invite à utiliser `forge_skill`. Chaque participant reçoit un nom factice (« Participant 1 ») et voit le roster (rôles) mais pas les instructions des autres. Après les tours de parole, un modèle synthétiseur (défaut `MODEL_FLASH`) produit une distillation structurée. Paramètres optionnels : `rounds` (défaut 3, max 5), `history_depth`, `distillation_focus`.
`forge_skill(skill_id, name, description, instructions)`	Crée ou met à jour un profil d'expert (SKILL) au format `SKILL.md`. Les instructions définissent le ton, la méthodologie et les contraintes de sortie de l'expert. Persisté dans le Vault de l'utilisateur via `echo_skills.save_skill()`.
`list_skills()`	Liste les expertises (Skills) disponibles pour le Conseil courant, avec leurs identifiants et descriptions. Utile pour découvrir les rôles déjà forgés avant un `consult_expert_consultant` ou un `consult_council`.
`list_sub_chats()`	Liste les fils de discussion cognitifs actifs pour le chat courant, avec leur `sub_sid`, rôle et résumé du dernier échange. Permet à l'orchestrateur de choisir quel fil reprendre.

⚙️ Boucle itérative du Conseil (1:1)

consult_expert_consultant distille d'abord la branche active du chat via MODEL_DISTILLATION, puis entre dans une boucle (ITERATION_DEFAULT tours, max ITERATION_MAX). À chaque tour, la thoughtSignature de la réponse précédente est sauvegardée dans EchoStateManager et réinjectée au tour suivant, évitant de propager les pensées en clair dans le contexte. La boucle s'arrête dès que l'expert émet la balise <FINAL_ANSWER>.

⚙️ Table Ronde Multi-Experts — Protocole Delphi (N:N)

consult_council orchestre une délibération en quatre phases :

Phase 0 — Validation : parsing du CSV participants, chargement des Skills via echo_skills.get_skill_content() et parse_skill_metadata(), attribution de noms factices (« Participant 1 », « Participant 2 », etc.). Limites : 2 à COUNCIL_MAX_PARTICIPANTS (défaut 5) participants.
Phase 1 — Distillation : réutilise _distill_context() (identique à consult_expert_consultant) pour résumer la branche active du chat via MODEL_DISTILLATION.
Phase 2 — Tours de parole : COUNCIL_ROUNDS_DEFAULT tours (défaut 3, max COUNCIL_ROUNDS_MAX = 5). Au Tour 1, chaque expert reçoit la question et le contexte distillé. Aux tours suivants, chaque expert reçoit les contributions des autres participants du tour précédent (il ne se relit pas lui-même). Tous les appels d'un même tour sont exécutés en parallèle via asyncio.gather(). Les parts brutes de l'API (incluant les thoughtSignature) sont conservées dans un dictionnaire in-memory par participant, assurant la continuité cognitive entre les tours sans persistance DB.
Phase 3 — Synthèse : la transcription complète (question + tous les tours de tous les participants avec leur rôle) est envoyée à un modèle synthétiseur (défaut MODEL_FLASH, configurable via synthesis_model) avec un prompt générique de rapporteur neutre. La synthèse identifie consensus, divergences et recommandations.

Un participant qui échoue (429, timeout) ne bloque pas le conseil — son absence est notée dans le transcript et les participants restants poursuivent la délibération. Le dictionnaire des historiques est libéré à la fin de l'appel (pas de persistance inter-appels).

← Vault Explorer Exécution & Pilotage →

7d. Mémoire & Cognition

RAG Organique — echo_memory

RAG Éphémère — echo_ephemeral