Changement d'architecture demande par l'utilisateur : le dataset d'entrainement (TECH_STEP_TRAINING_DATA) quitte apps/api pour vivre entierement dans services/tech-step-intent-service (intent_service/training_data.py). Ce service est desormais autonome : il s'entraine lui-meme une seule fois, a son propre demarrage (PipelineRegistry.initialize, dans le lifespan FastAPI), sans plus dependre d'un POST /v1/train pousse par apps/api (route supprimee). apps/api ne connait plus aucune technique/synonyme, uniquement le resultat de POST /v1/process. Corpus enrichi avec les 48 techniques du lexique fourni (Arroser, Appertiser, Braiser, Caraméliser, Confire, Julienne/Brunoise/Mirepoix/ Paysanne, Cuire à blanc/au bain-marie/à l'étouffée, Déglacer variantes, Emulsionner, Glacer, Pocher, Réduire, Suer, Zester, etc.), soit 74 techniques au total (26 + 48). Integration complete bout en bout : - reference-seed-data.ts : 48 nouvelles entrees TECH_STEPS - apps/web/locales/fr/translation.json : libelles francais correspondants - "Mitonner" fondu comme synonyme de simmer (pas une technique distincte, sa propre definition le dit) - "Blanchir un oeuf" (whiskPale) distingue de "Blanchir un legume" (blanch, existant) via des synonymes en phrase complete plutot qu'au mot nu — filter_spans (deja en place) resout la collision par specificite Impact performance mesure : le corpus elargi (74 classes vs 26) rend l'entrainement bien plus lent a nombre d'iterations egal (150 iterations depassait 17 minutes par run de test) — reduit a 40 iterations apres mesures repetees en local (~200s/locale, ~400s pour fr+en combines). docker-compose.yml (healthcheck start_period 600s), CI (timeout curl 600s) et le README du service documentent ce nouveau temps de demarrage. CONFIDENCE_THRESHOLD recalibre a 0.2 par verification manuelle (0.75 puis 0.45 ne tenaient plus compte tenu du nombre de classes) — marque explicitement comme placeholder en attendant une vraie repasse de calibrate-tech-step-threshold.ts (necessite Postgres, indisponible dans cet environnement). Verifie : 28/28 tests pytest du service (suite complete re-ecrite pour s'entrainer une seule fois par session sur le vrai corpus, fixture partagee dans conftest.py), lint + build complets du monorepo. La suite Mocha d'apps/api reste a confirmer via CI (le root hook mocha n'attend plus l'entrainement, seulement CI's propre attente sur /health). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
45 lines
1.3 KiB
Python
45 lines
1.3 KiB
Python
"""Modèles Pydantic du contrat HTTP — voir le plan de migration pour le
|
|
contrat exact attendu côté `apps/api` (`IntentServiceClient`,
|
|
`apps/api/src/lib/recipe-matching/intent-service-client.ts`).
|
|
|
|
Pas de `POST /v1/train` ici — ce service s'entraîne lui-même au démarrage
|
|
depuis `training_data.py` (voir `pipeline_registry.py`/`main.py`), plus
|
|
besoin d'un contrat HTTP pour ça.
|
|
"""
|
|
|
|
from pydantic import BaseModel
|
|
|
|
# ---------------------------------------------------------------------------
|
|
# POST /v1/process
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
|
class ProcessRequest(BaseModel):
|
|
locale: str
|
|
text: str
|
|
|
|
|
|
class EntityPayload(BaseModel):
|
|
"""Une mention candidate d'une technique — offsets caractère `[start, end)`
|
|
dans `text`, convention identique à `String.prototype.slice` côté
|
|
`apps/api` (pas de décalage `+1` à appliquer côté Node, contrairement à
|
|
l'ancien `NlpManager` de node-nlp)."""
|
|
|
|
uid: str
|
|
start: int
|
|
end: int
|
|
|
|
|
|
class ProcessResponse(BaseModel):
|
|
entities: list[EntityPayload]
|
|
intent: str | None
|
|
score: float
|
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
# GET /health
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
|
class HealthResponse(BaseModel):
|
|
status: str
|