Suite a une suggestion de revue de code : le textcat n'apprenait jusqu'ici que sur entry.utterances, jamais sur entry.synonyms (deja utilises pour le PhraseMatcher). Ajouter le mot-cle isole comme exemple positif de sa propre technique ameliore radicalement la confiance sur les cas ancres sans paraphrase entrainee. Mesures sur le vrai corpus (74 techniques) : - 40 iterations + synonymes (749 exemples vs 286 avant) : gain de confiance massif (simmer 0.25->0.60, cook 0.33->0.60, bake 0.34->0.86) mais temps d'entrainement multiplie par 2.6 (~535s/locale, ~17min combine pour fr+en — inacceptable). - 15 iterations + synonymes : retour a un temps raisonnable (~205s) mais qualite pire qu'avant (simmer/cook repassent sous le seuil de confiance) — les exemples supplementaires ne compensent pas la perte d'epoques a ce point. - 25 iterations + synonymes (retenu) : ~336s/locale (~670s combine), meilleur compromis — tous les cas mesures s'ameliorent par rapport a la config precedente (simmer 0.25->0.31, cook 0.33->0.38, bake 0.34->0.62, zest 0.64->0.66, julienne 0.56->0.76, compote 0.76->0.78), bruit hors-vocabulaire toujours negligeable (~0.02). CONFIDENCE_THRESHOLD releve de 0.2 a 0.25 (le cas le plus faible mesure est maintenant 0.31, avec plus de marge qu'avant). docker-compose.yml (start_period 900s) et la CI (timeout 900s) ajustes pour le nouveau temps de demarrage (~11 min pour fr+en combines, contre ~7 min avant). Deux autres pistes de la meme revue examinees et non retenues avec justification : classe __OTHER__/negatifs hors-domaine (le bruit mesure est deja bas, ~0.02, sans le symptome que cette classe corrige) et boost de score post-traitement si le NER confirme l'intention predite (casserait la garantie "score brut, jamais corrige par l'ancre" que services/tech-step-llm-worker's audit de faible confiance depend explicitement d'avoir, voir le commentaire de TechStepClauseClassification dans tech-step-matcher.ts). Verifie : 28/28 pytest (dont le vrai corpus complet, ~10.5 min pour la suite complete), lint + build du monorepo. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
75 lines
3.6 KiB
Python
75 lines
3.6 KiB
Python
"""Détient un `LocalePipeline` par locale supportée — le seul état mutable
|
|
partagé du process (une instance vit pour toute la durée de vie d'`uvicorn`,
|
|
montée sur `app.state`, voir `main.py`).
|
|
|
|
Volontairement une classe "registre" séparée de `LocalePipeline` lui-même :
|
|
`LocalePipeline` ne connaît qu'une seule locale, ce module route `process`
|
|
vers la bonne instance selon le `locale` reçu dans la requête — même
|
|
séparation de responsabilité que `TechStepClassifierService` (une seule
|
|
instance, un seul `NlpManager` multi-langues) avait implicitement via
|
|
node-nlp, explicitée ici puisque spaCy charge un modèle par langue.
|
|
"""
|
|
|
|
import logging
|
|
|
|
from .locale_pipeline import SUPPORTED_LOCALES, LocalePipeline, ProcessResult, TrainEntry
|
|
from .training_data import entries_for_locale
|
|
|
|
logger = logging.getLogger(__name__)
|
|
|
|
|
|
class PipelineRegistry:
|
|
def __init__(self) -> None:
|
|
self._pipelines: dict[str, LocalePipeline] = {
|
|
locale: LocalePipeline(locale) for locale in SUPPORTED_LOCALES
|
|
}
|
|
|
|
def initialize(self) -> None:
|
|
"""Charge le modèle spaCy de base *et* entraîne chaque locale connue
|
|
depuis `training_data.TECH_STEP_TRAINING_DATA` — appelé une fois au
|
|
démarrage du process (`main.py`'s `lifespan`), avant que `uvicorn`
|
|
n'accepte de requêtes.
|
|
|
|
Contrairement à la version précédente de ce service (où `apps/api`
|
|
poussait le corpus via `POST /v1/train` à son propre warm-up), ce
|
|
service est maintenant entièrement autonome : `apps/api` ne connaît
|
|
plus aucune technique, seulement le résultat de
|
|
`POST /v1/process`. `GET /health` ne répond `200` qu'une fois cette
|
|
méthode terminée (chargement *et* entraînement) — pas seulement le
|
|
chargement — pour que `docker-compose.yml`'s `depends_on: ...
|
|
condition: service_healthy` (et la boucle d'attente équivalente en
|
|
CI) ne laisse jamais `apps/api` démarrer face à un service qui
|
|
répondrait mais ne saurait encore rien détecter.
|
|
"""
|
|
logger.info("tech-step NLP initializing pipelines", extra={"locales": list(self._pipelines)})
|
|
for locale, pipeline in self._pipelines.items():
|
|
pipeline.preload()
|
|
entries = [TrainEntry(**entry) for entry in entries_for_locale(locale)]
|
|
label_count, example_count, synonym_count = pipeline.train(entries)
|
|
logger.info(
|
|
"tech-step NLP pipeline trained",
|
|
extra={
|
|
"locale": locale,
|
|
"labelCount": label_count,
|
|
# Nombre réel d'exemples donnés au textcat (utterances
|
|
# *et* synonyms combinés — voir `LocalePipeline.train`),
|
|
# pas seulement le compte d'`utterances` du corpus.
|
|
"exampleCount": example_count,
|
|
"synonymCount": synonym_count,
|
|
},
|
|
)
|
|
logger.info("tech-step NLP pipelines ready", extra={"locales": list(self._pipelines)})
|
|
|
|
def process(self, locale: str, text: str) -> ProcessResult:
|
|
pipeline = self._pipelines.get(locale)
|
|
if pipeline is None:
|
|
# Une locale que ce service ne sait structurellement pas
|
|
# charger (pas de modèle spaCy connu) se comporte comme une
|
|
# locale "jamais entraînée" côté `process` — reproduit le test
|
|
# `apps/api` existant ("returns an empty sequence for a locale
|
|
# nothing was trained on"), qui ne distingue pas les deux cas.
|
|
return ProcessResult(entities=[], intent=None, score=0.0)
|
|
return pipeline.process(text)
|
|
|
|
|
|
registry = PipelineRegistry()
|