bolbol/nas-runbooks
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

roadmap: architecture 2 phases telechargement/resume (31/07/2026)

Browse Source
This commit is contained in:
bolbol
2026-08-01 06:52:59 +00:00
parent 4dcf749153
commit 2e17b515c9
1 changed files with 21 additions and 17 deletions
Download Patch File Download Diff File Expand all files Collapse all files
hermes-tt/nyora-notes-tt-roadmap-pieces-jointes.md
+21 -17
View File
@@ -1,30 +1,34 @@
# nyora-notes-tt -- Pieces jointes : chantier dedie futur, EXHAUSTIF (decision finale 31/07/2026)
# nyora-notes-tt -- Pieces jointes : chantier dedie futur, EXHAUSTIF, architecture 2 phases (31/07/2026)
**Date** : 31/07/2026 (mise a jour -- decision initiale "cible" remplacee par "exhaustif")
**Date** : 31/07/2026 (v3 -- ajoute l'architecture 2 phases proposee par Nabil)
## Decision finale
## Decision finale (rappel v2)
Nabil tranche pour l'exhaustif : toutes les PJ, tous les dossiers. Motivation explicite : "je ne veux rien perdre comme info", accepte le cout en temps/ressources en echange ("un vrai RAG merite quelques sacrifices").
Exhaustif : toutes les PJ, tous les dossiers. Dedoublonnage par CONTENU (similarite vectorielle sur texte extrait), jamais par nom de fichier -- une meme PJ peut etre diffusee plusieurs fois ou renommee. Chantier separe, lance APRES le backfill texte (205 dossiers, 2024-2026, deadline dimanche matin), jamais en parallele.
Reste separe du backfill texte en cours (205 dossiers, 2024-2026, deadline dimanche matin) -- chantier lance APRES, pas en parallele, pour ne pas compromettre les deux delais a la fois.
## Architecture 2 phases (idee de Nabil, 31/07/2026)
## Deduplication par CONTENU, pas par nom de fichier
Decouple explicitement la partie LENTE-MECANIQUE (telechargement, contrainte OWA) de la partie LENTE-LLM (resume/embedding) -- les deux etaient bundlees dans le concept initial, ce qui les faisait payer le meme prix (45s d'attente OWA) meme pour la relecture. Separer permet a la phase 2 de tourner vite, sur fichiers locaux deja presents, sans plus jamais toucher OWA.
Point souleve par Nabil, essentiel : la meme PJ peut apparaitre plusieurs fois (diffusion a plusieurs destinataires) ET le meme fichier peut porter des noms differents (renommage, versions). Un dedoublonnage par nom de fichier ne suffit pas.
### Phase 1 -- Telechargement seul, aucun appel LLM
**Solution retenue** : meme mecanisme que le dedoublonnage des diffusions groupe de mails deja en place (similarite vectorielle sur le texte extrait, pas sur le nom). Le nom du fichier ne rentre jamais dans la decision de dedoublonnage -- seul le contenu compte.
- Reproduit la structure des dossiers mail sur disque (miroir de l'arborescence O365).
- Chaque PJ telechargee et rangee dans le dossier correspondant, nommee `{N}_{note_id}_{nom_original_assaini}` -- le numero ET le note_id assurent la correspondance directe RAG<->Mail des cette etape (pas besoin d'attendre la phase 2 pour tracer quelle PJ vient de quel mail).
- **Piege a eviter (deja paye une fois avec folder_path)** : certains noms de dossiers mail contiennent un vrai `/` (ex "AO 66/2024 E Curatif"). Assainir ce caractere (remplacer par `-` ou equivalent) UNIQUEMENT pour le chemin disque -- la donnee en base garde le nom exact, seul le chemin fichier est assaini.
- Resultat : une archive locale complete et exploitable meme independamment du RAG.
## Cout reel -- deux volets distincts, ne pas les confondre
### Phase 2 -- Resume + alimentation RAG, sur fichiers locaux
**1. Cout API (LLM)** : Nabil suppose que le forfait Go OpenCode absorbe tout sans surcout. Correction : ca couvre Mimo v2.5 et DeepSeek V4 Flash (provider opencode), mais PAS les embeddings Gemini (cle Google separee dans Bifrost) -- necessaires pour le dedoublonnage par contenu decrit ci-dessus. Volet non chiffre a ce stade.
- Opere uniquement sur les fichiers deja telecharges en phase 1 -- plus aucune navigation OWA, donc rapide.
- Nouvelle table dediee `attachments` (PJ = entite de premiere classe, pas un champ JSON annexe sur `notes`) :
- id, note_id (FK vers notes), original_filename, local_path, content_hash (dedup par contenu), extracted_text, summary, embedding_rowid (table vec dediee ou reutilisation de notes_vec avec discriminant de type).
- Objectif final explicite de Nabil : **hermes-tt consulte les PJ sans jamais avoir besoin de rouvrir O365** -- une fois phase 2 terminee, la dependance a la session OWA disparait completement pour la consultation (elle reste necessaire uniquement pour l'ingestion initiale).
**2. Cout temps** : le vrai facteur limitant, independant de tout forfait. Chaque telechargement de PJ attend jusqu'a 45s (contrainte technique : navigateur pilote a distance via CDP, pas de gestion de telechargement native). Sur l'ensemble de l'arborescence (branche RLA 2024 notamment, potentiellement plusieurs PJ par lot), estimation grossiere : plusieurs heures a plus d'une journee, rien qu'en telechargement.
## Cout (rappel v2, toujours valable)
## Contexte quota OpenCode donne par Nabil (31/07/2026)
Volet API : Mimo/DeepSeek couverts par le forfait Go OpenCode, embeddings Gemini sur cle Google separee (non chiffre). Volet temps : jusqu'a 45s par telechargement en phase 1, potentiellement plusieurs heures a plus d'une journee sur l'ensemble de l'arborescence -- mais ce cout ne concerne QUE la phase 1 desormais ; la phase 2 devrait etre nettement plus rapide une fois les fichiers locaux disponibles.
Forfait Go : 80% restant, 12 jours avant fin de mois. Fenetre hebdomadaire : 85% restant, moins de 2 jours avant fin de semaine. A reverifier au moment de lancer le chantier PJ (le contexte peut avoir change).
## Infrastructure deja disponible
## Infrastructure deja disponible (rappel, cf version precedente de cette note)
- `GET /message/{index}/attachments` -- listing leger, deja integre au backfill texte en cours (colonne `notes.attachments`, JSON, best-effort).
- `GET /message/{index}/attachments/{filename}/text` -- telechargement + extraction, PAS encore integre au pipeline -- objet du present chantier.
- `GET /message/{index}/attachments` -- listing leger, deja integre au backfill texte en cours (colonne `notes.attachments`, JSON, best-effort) -- deviendra probablement redondant une fois la table `attachments` dediee en place, a evaluer.
- `GET /message/{index}/attachments/{filename}/text` -- combine actuellement telechargement+extraction en un seul appel ; pour l'architecture 2 phases, il faudra soit isoler la partie telechargement seule (nouvel endpoint ou parametre), soit telecharger via ce endpoint en phase 1 et ignorer le texte extrait a ce stade (extraction refaite en phase 2 depuis le fichier local si le format le justifie).