182 lines
11 KiB
Markdown
182 lines
11 KiB
Markdown
# RIA (Reglement Interieur Achats) — 179 articles verbatim dans le RAG, fiabilite citation
|
||
|
||
**Instance auteur** : hermes-tt
|
||
**Date** : 2026-08-06
|
||
**Tags** : [ria, rag, nyora-notes-tt, fts, achats]
|
||
**Statut** : valide
|
||
|
||
---
|
||
|
||
## Probleme
|
||
|
||
Ingestion du RIA (reglement interieur achats TT, 179 articles) dans NyoraNotes REST (:8787) avec exigence stricte de Nabil : toute question RIA doit retourner l'article ou les articles correspondants, cites VERBATIM sans aucune modification. Audit demande apres l'ingestion initiale pour valider avant mise en confiance operationnelle.
|
||
|
||
Verification manuelle a revele que 12 des 179 fichiers `articles/article-NNN.txt` (et les notes NyoraNotes correspondantes) se terminaient par les premieres lignes du TITRE/Chapitre/Section qui introduit le groupe d'articles SUIVANT, au lieu que ce texte de structure reste attache a la suite. Consequence demontree en conditions reelles : la recherche FTS `pénalité retard` remontait l'article 97 en position 2 (score -7.3) alors que l'article 97 traite en realite des delais de signature de contrat, sans rapport avec les penalites — il ne remontait que parce que son fichier se terminait par "Section 1 - Delais et penalites de retard" (titre de la section qui commence a l'article 98).
|
||
|
||
---
|
||
|
||
## Contexte et contraintes
|
||
|
||
- Source : `reglement-interieur-achats-TT.docx`, hash MD5 `a6b534bb06473ce2ab6ac0f13ca4b0ea` (verifie).
|
||
- Extraction mecanique DOCX->XML vers 179 fichiers `article-NNN.txt` (parse_ria_articles.py) + fichier canonique `RIA_INTEGRAL_179_articles.txt`.
|
||
- Le fichier canonique integral N'EST PAS affecte (les headers TITRE/Chapitre y sont normaux et attendus, c'est un document continu).
|
||
- Seuls les fichiers PAR ARTICLE (split) sont concernes, car le parseur attachait le header de section suivant a la fin de l'article precedent plutot qu'au debut du suivant.
|
||
- Ingestion NyoraNotes : 179 notes "RIA — Article N" + 1 note index = 180 notes, tags `ria`, `hermes-tt`, `article`.
|
||
|
||
---
|
||
|
||
## Ce qui NE fonctionne PAS
|
||
|
||
| Tentative | Erreur obtenue | Raison de l'echec |
|
||
|-----------|----------------|-------------------|
|
||
| Faire confiance au rapport d'ingestion sans re-verifier le contenu reel des fichiers | Aucune erreur visible dans le rapport — le defaut n'apparait qu'en testant des requetes FTS reelles | Le rapport verifiait "la question renvoie le bon article en position 1" mais pas "aucun autre article n'est pollue par du texte hors-sujet" |
|
||
| Se fier au seul comptage (179 fichiers, 180 notes, sequence 1-179 complete) | Comptage correct, mais insuffisant | Un comptage exact ne garantit pas la purete du contenu de chaque fichier |
|
||
|
||
---
|
||
|
||
## Solution validee
|
||
|
||
1. Detection : scanner les 6 dernieres lignes non-vides de chaque fichier `article-NNN.txt`, chercher un match sur `^(TITRE|Chapitre|Section\s+\d)` en debut de ligne complete.
|
||
2. 12 fichiers concernes : 2, 5, 41, 97, 109, 127, 132, 142, 148, 152, 164, 172.
|
||
3. Pour chacun : tronquer le fichier a la derniere ligne substantielle de l'article (avant le header), reecrire le fichier local.
|
||
4. Recuperer l'ID de la note NyoraNotes correspondante (`GET /notes?tag=ria&limit=100&page=N`, filtrer par titre "RIA — Article N").
|
||
5. `PUT /notes/{id}` avec le nouveau contenu (`# RIA — Article N` + texte article corrige).
|
||
6. Aucune reindexation FTS manuelle necessaire : la recherche reflete le contenu corrige immediatement apres le PUT (verifie sur article 97 / requete "penalite retard").
|
||
|
||
---
|
||
|
||
## Verification
|
||
|
||
```
|
||
curl -s -H "Authorization: Bearer $TOKEN" --get http://localhost:8787/search --data-urlencode "q=penalite retard"
|
||
# Attendu : article 99 en position 1, article 97 absent du top (ou present uniquement si legitimement pertinent)
|
||
```
|
||
|
||
Confirme le 06/08/2026 : article 97 n'apparait plus dans les 5 premiers resultats pour "penalite retard", le classement restant (99, 129, 30, 40, 105) est desormais coherent avec le contenu reel de chaque article.
|
||
|
||
---
|
||
|
||
## Pieges specifiques DSM / NAS
|
||
|
||
- mcp-nas : la commande `docker` n'est PAS disponible directement dans le shell du container mcp-nas (pas de docker.sock monte, pas de binaire docker). Il faut passer par `ssh nas-host` (alias configure vers Best0f@172.17.0.1:22222) puis utiliser le binaire complet `/usr/local/bin/docker`.
|
||
- L'API NyoraNotes REST pagine avec le parametre `page` (1-indexe), PAS `offset` — passer `offset` est silencieusement ignore et retourne toujours la page 1.
|
||
- `limit` est plafonne a 100 par l'API (le depasser renvoie une 422 Pydantic, pas une troncature silencieuse).
|
||
- Le hash affiche dans les noms de fichiers du pipeline OneDrive (ex. `...a6b534bb.md`) est un MD5, pas un SHA256.
|
||
|
||
---
|
||
|
||
## References
|
||
|
||
- Skill : `gsd-ao-evaluation/references/ria-articles-cles.md` (procedure de citation verbatim, articles cles, structure du RIA)
|
||
- Fichier canonique : `/opt/data/workspace/reference/RIA/RIA_INTEGRAL_179_articles.txt`
|
||
- Memoire hermes-tt : `/opt/data/memories/MEMORY.md` (entree RIA ajoutee 06/08/2026)
|
||
|
||
|
||
---
|
||
|
||
## Addendum 06/08/2026 — purge du fichier memoire orphelin
|
||
|
||
Constat (demande Nabil) : hermes-tt possede DEUX fichiers "MEMORY.md" :
|
||
- `/opt/data/memories/MEMORY.md` — le vrai fichier natif, confirme dans le code source de l'agent (`tools/memory_tool.py`, fonction `get_memory_dir()` -> `{HERMES_HOME}/memories/MEMORY.md`). C'est celui injecte automatiquement dans le prompt systeme a chaque session (bloc "MEMORY (your personal notes)").
|
||
- `/opt/data/MEMORY.md` — fichier orphelin, JAMAIS lu par le moteur natif. En-tete affichait une limite de 2200 caracteres, deja depassee (3469 car.), contenu date du 01/06/2026 (services decommissionnes references comme actifs : Carbone, Gotenberg, Pandoc, pptx-tt-api, Paperless, Trilium ; port Baserow 3888 obsolete).
|
||
|
||
Verifie par comparaison : hermes-nyora et hermes-perso n'ont PAS ce fichier orphelin, uniquement `memories/MEMORY.md` (2181 et 2237 car. respectivement, sous budget). C'est un artefact propre a hermes-tt.
|
||
|
||
Cause racine probable : `boot.md` de hermes-tt (et de hermes-nyora, meme formulation) contient l'instruction generique "Lire MEMORY.md" sans chemin absolu. Chez nyora, un seul fichier porte ce nom -> pas d'ambiguite. Chez TT, deux fichiers portent ce nom -> l'agent, en suivant sa checklist boot au pied de la lettre, a pu lire (et tenter de mettre a jour) le mauvais fichier, expliquant le signalement de "saturation" (2902/2200 puis 3469/2200 car.) alors que le vrai fichier memoire actif n'etait pas concerne.
|
||
|
||
Correle avec observation Nabil : classement reactivite/justesse des instances Perso > Nyora > TT. Perso n'a meme pas de boot.md (aucune instruction de re-lecture manuelle). Nyora a boot.md mais pas de doublon. TT a boot.md ET un doublon -> ambiguite reelle, unique a cette instance. Hypothese plausible de contribution a la lenteur/defauts de raisonnement observes sur TT (contexte pollue par des faits perimes/contradictoires en plus du bloc memoire natif correct).
|
||
|
||
**Action** : fichier `/opt/data/MEMORY.md` supprime sur hermes-tt apres verification code source (non lu par le moteur). Contenu archive ci-dessous pour tracabilite. `boot.md` corrige pour lever l'ambiguite (chemin explicite, precision que le bloc memoire natif est deja auto-injecte, pas de relecture manuelle necessaire).
|
||
|
||
### Contenu archive avant suppression (`/opt/data/MEMORY.md`, 06/08/2026)
|
||
|
||
```markdown
|
||
# Mémoire Environnement
|
||
*limite : 2200 caractères — distiller à chaque mise à jour*
|
||
|
||
## Stack NAS
|
||
IP : 192.168.100.33 | DSM : Ahmed_-_Yesmine | user : Best0f
|
||
Réseau Docker : n8n | RAM : 20Go
|
||
|
||
## Services Docker actifs
|
||
n8n, Baserow (port 3888), Carbone, Gotenberg, Pandoc
|
||
pptx-tt-api, document-factory, Paperless, Trilium
|
||
Pingvin-Share, Portainer, Gitea (3232)
|
||
|
||
## Hermes Platform
|
||
hermes-tt : workspace 3010 · agent 8650
|
||
hermes-nyora : workspace 3020 · agent 8660
|
||
hermes-perso : workspace 3030 · agent 8670
|
||
|
||
## Baserow — Accès
|
||
Token RLA : XGCwbfgwg8ZiLVb4dxEfagWa7XptyUcM
|
||
URL interne : http://Baserow:3888
|
||
URL externe : https://baserow.bolbol.tn
|
||
Schéma complet : /opt/data/obsidian/config/baserow-schema.md (LIRE EN PREMIER)
|
||
|
||
## Baserow — Tables clés
|
||
T856 : Marchés RLA Zone Sud (55 marchés actifs au 30/04/2026)
|
||
T857 : Historique Avancement (snapshots mensuels)
|
||
T872 : Appels d'Offres en cours (pipeline 2026)
|
||
T998 : CI-CPT Zone Sud consolidé
|
||
T1006 : FB Zone Sud consolidé
|
||
|
||
## Situation marchés — 01/06/2026
|
||
- 4 non-renouvellements reçus : ECHABAKET (Lots 02+04 AO 58/2024) + SOTEL SUD (Lots 09+13 AO 66/2024)
|
||
- Avenants en cours : Lot 02 → YASMINE TELECOMS | Lot 04 → ATS
|
||
- Nouveaux marchés : Lot 09 → DR Gabes OK + quantitatifs reçus | Lot 13 → DR Kebili en attente
|
||
- 3 marchés AO 29/2025 + AO 31/2025 : fin contractuelle 13/05/2026 dépassée
|
||
- Pipeline AO 2026 : ~3.6 MDT en cours d'instruction
|
||
|
||
## Modèle par défaut
|
||
deepseek/deepseek-v4-flash (OpenRouter)
|
||
|
||
## Points actifs
|
||
- Schéma Baserow complet ajouté : 2026-06-01
|
||
- Modèle corrigé : GLM → DeepSeek V3.2 : 2026-06-01
|
||
- Workflow Marche RLA Sync validé : execution 25330 success 01/06/2026
|
||
|
||
Dernière mise à jour : 2026-06-01
|
||
|
||
## Historique Avancement — Table 857 (mis à jour 01/06/2026)
|
||
|
||
Total snapshots : 277 entrées
|
||
Couverture par mois :
|
||
2025-12 : 43 entrées ✅ (13 marchés)
|
||
2026-01 : 46 entrées ✅ (35 marchés)
|
||
2026-02 : 3 entrées ⚠️ (incomplet — workflow non déclenché)
|
||
2026-03 : 0 entrées ❌ (manquant — données non récupérables)
|
||
2026-04 : 110 entrées ✅ (55 marchés × Financier + Physique — créé le 01/06/2026)
|
||
2026-05 à 2027-01 : entrées issues des dates contractuelles (date_fin)
|
||
|
||
Snapshot 30/04/2026 : données arrêtées — référence officielle du portefeuille.
|
||
Mars 2026 : snapshot absent, données historiques perdues.
|
||
Février 2026 : incomplet (3 entrées seulement).
|
||
|
||
Format snapshot table 857 :
|
||
Marche : [row_id table 856]
|
||
Date_Releve : "AAAA-MM-JJ"
|
||
Valeur : montant TND (avt_fin pour Financier, avt_phy pour Physique)
|
||
Type_Avancement : "Financier" ou "Physique" (string direct, pas {"value":...})
|
||
Observation : "Snapshot auto JJ/MM/AAAA — id_marche"
|
||
|
||
Pour créer un nouveau snapshot mensuel :
|
||
python3 /tmp/snap_apr.py (adapter DATE et nom fichier)
|
||
Ou via workflow n8n Marche RLA Sync (ID: 8RSSgxRogaIMsxgm)
|
||
|
||
## Audit Table 857 — État final (01/06/2026)
|
||
|
||
Total : 387 entrées (379 + 8 complétées)
|
||
|
||
| Date | Entrées | Source | Qualité |
|
||
|---|---|---|---|
|
||
| 2025-12-31 | 39 | Workflow Marche RLA Sync | ✅ TND réels |
|
||
| 2026-01-31 | 43 | Workflow | ✅ TND réels |
|
||
| 2026-02-28 | 55 | Workflow + complété | ✅ 51 TND + 4 Pas de PO |
|
||
| 2026-03-31 | 55 | Workflow + complété | ✅ 51 TND + 4 Pas de PO |
|
||
| 2026-04-30 | 110 | Créé manuellement | ✅ 55 marchés × Fin+Phy |
|
||
|
||
Historique % physique par marché (Déc25→Avr26) injecté dans SOUL.md via PPTX officiels.
|
||
|
||
```
|