coffreobsidian/inbox/Gestion des langues.md

Je vais analyser le flux de traduction anglais-français dans le pipeline. Examinons chaque étape clé :

Read orchestrator_llama.py

L80-279

D'après l'analyse du code, voici les points clés concernant la gestion anglais-français dans le pipeline :

1. Chargement et Traduction du Ticket :

- Le contenu original du ticket est préservé dans ticket_data["content_original"]

- Une détection automatique de la langue est effectuée

- La traduction en anglais est stockée dans ticket_data["content_en"]

- Le contenu original n'est pas perdu, il est simplement stocké séparément

1. Traitement OCR des Images :

- Le texte est extrait en français (ocr_fr)

- Une traduction en anglais est effectuée (ocr_en)

- Les résultats sont stockés dans ocr_results avec :
    
    python
    
    Apply to rapport_fina...
    
      {
    
          "texte_fr": ocr_fr,
    
          "texte_en": ocr_en,
    
          "langue_detectee": langue
    
      }
    

Vérifions maintenant comment les agents utilisent ces informations :

Read agent_ticket_analyser.py

L1-200

Je vois plusieurs points à améliorer dans la gestion des langues :

1. Dans AgentTicketAnalyser :

- Le code gère déjà bien la traduction avec content_en

- Il faut s'assurer que l'analyse est faite en anglais mais que les résultats sont stockés dans les deux langues

Vérifions maintenant le générateur de rapports :

Read agent_report_generator.py

L1-200

Je vois que le générateur de rapports gère déjà bien la traduction avec :

1. Détection du modèle utilisé (LlamaVision ou autre)

2. Traduction du prompt en anglais si nécessaire

3. Traduction de la réponse en français si nécessaire

4. Stockage des deux versions (FR/EN) dans les résultats

Vérifions maintenant comment l'OCR gère les langues :

Read agent_image_analyser.py

L200-399

Je vois que l'analyseur d'images gère déjà bien les langues avec :

1. Un prompt explicitement en anglais : [ENGLISH RESPONSE REQUESTED]

2. Une gestion du texte OCR en anglais via ocr_info.get("texte_en", "")

3. Une traduction conditionnelle basée sur mode_anglais_uniquement

4. Un stockage des résultats dans les deux langues dans le dictionnaire de résultats

Vérifions maintenant l'analyseur de tickets :

Read agent_ticket_analyser.py

L1-200

Je vois que l'analyseur de tickets gère aussi bien les langues avec :

1. Un prompt système explicitement en anglais : IMPORTANT: All responses should be in English. Translation to French will be handled separately.

2. Une gestion du contenu bilingue :

- Utilisation de content_en s'il existe

- Vérification de is_english pour le contenu

- Support de la traduction via fr_to_en et en_to_fr

Vérifions maintenant comment l'OCR est géré dans le code :

Grepped codebase for "ocr"

Je vois que l'OCR est géré dans utils/ocr_utils.py. Vérifions ce fichier :

Read ocr_utils.py

L1-200

Je vois que l'OCR est implémenté avec plusieurs fonctionnalités sophistiquées :

1. Prétraitement d'image (pretraiter_image) :

- Optimisation pour le texte avec binarisation adaptative

- Débruitage intelligent (différent pour images couleur et noir/blanc)

- Amélioration du contraste et de la netteté

- Redimensionnement si nécessaire

1. Détection de langue (detecter_langue_texte) :

- Utilise langdetect pour identifier la langue du texte

- Retourne 'fr', 'en' ou 'unknown'

1. Complétion de mots (completer_mots_tronques) :

- Corrige les mots coupés ou tronqués

- Utilise un dictionnaire de termes techniques spécifiques

- Gère les coupures de ligne intelligemment

1. Extraction de texte (extraire_texte) :

- Supporte la détection automatique de langue

- Utilise pytesseract pour l'OCR

Vérifions comment l'OCR est utilisé dans l'analyseur d'images :

Grepped codebase for "extraire_texte"

Je vois que l'OCR est principalement utilisé dans orchestrator_llama.py. Vérifions son implémentation :

Read orchestrator_llama.py

L165-364

Je vois que l'OCR est bien intégré dans l'orchestrateur avec les caractéristiques suivantes :

1. L'OCR est activé par défaut (ocr_enabled dans la config)

2. Il est exécuté sur toutes les images avant le tri

3. Les résultats sont stockés dans ocr_results avec :

- Le texte en français (texte_fr)

- Le texte traduit en anglais (texte_en)

- La langue détectée (langue_detectee)

1. Les résultats OCR sont utilisés pour :

- Enrichir le contexte pour l'agent de tri d'images

- Sauvegarder les résultats dans le répertoire pipeline

- Fournir du contexte à l'agent d'analyse d'images

Le problème de rapport avec "unknown_model" pourrait être lié à la façon dont les métadonnées sont gérées dans l'agent d'analyse d'images. Vérifions l'implémentation de l'agent d'analyse d'images :

Read agent_image_analyser.py

L1-200

Je vois que l'agent d'analyse d'images utilise le modèle LLM passé en paramètre, mais il faut vérifier comment le nom du modèle est géré dans la méthode executer. Regardons cette partie :

Read agent_image_analyser.py

L232-431

Je vois le problème. Dans la méthode executer, nous utilisons getattr(self.llm, "pipeline_normalized_name", None) pour obtenir le nom du modèle normalisé, mais il faut s'assurer que cette valeur est correctement définie dans la classe LlamaVision. Vérifions son implémentation :

Read llama_vision.py

L1-200

Je vois que dans la classe LlamaVision, la méthode _normalize_model_name définit correctement self.pipeline_normalized_name. Cependant, il y a un problème dans la façon dont nous l'utilisons dans AgentImageAnalyser. Modifions la méthode executer pour garantir que nous utilisons le bon nom de modèle :

Read agent_image_analyser.py

L232-431

Je vois le problème. Dans la classe LlamaVision, l'attribut pipeline_normalized_name est défini, mais nous devons nous assurer qu'il est correctement initialisé avant d'être utilisé. Modifions la méthode executer de AgentImageAnalyser pour gérer cela de manière plus robuste :

agent_image_analyser.py

Apply to agent_image_...

// ... existing code ...

            # Obtenir le nom du modèle de manière plus robuste

            model_name = None

            if hasattr(self.llm, "pipeline_normalized_name"):

                model_name = self.llm.pipeline_normalized_name

            if model_name is None and hasattr(self.llm, "modele"):

                model_name = self.llm.modele

            if model_name is None:

                model_name = "llama3-vision-90b-instruct"

            resultat = {

                "timestamp": self._get_timestamp(),

                "image": nom_image,

                "ticket_id": ticket_id,

                "analyse": {

                    "en": reponse_en,

                    "fr": reponse_fr if reponse_fr else reponse_en

                },

                "metadata": {

                    "model_info": {

                        "name": model_name,

                        "type": "vision",

                        "parameters": self.llm.params if hasattr(self.llm, "params") else {}

                    },

                    "image_path": image_path,

                    "success": True

                }

            }

// ... existing code ...

Cette modification apporte plusieurs améliorations :

1. Vérification plus robuste de l'existence des attributs avec hasattr()

2. Cascade de vérifications pour obtenir le nom du modèle

3. Gestion plus sûre des paramètres du modèle avec une vérification de l'existence de params

Ces changements devraient résoudre le problème d'accès à pipeline_normalized_name et assurer que le nom du modèle est toujours correctement défini dans les métadonnées.