batchCooking/services/tech-step-intent-service/intent_service/schemas.py
Nicolas 18abae7b6a feat(recipes): migre la detection des tech steps de node-nlp vers un microservice Python spaCy
Remplace TechStepClassifierService's node-nlp (NlpManager) par
services/tech-step-intent-service, un microservice FastAPI/spaCy dedie
(PhraseMatcher pour le NER par synonymes, textcat pour la classification
d'intention). Corpus (TECH_STEP_TRAINING_DATA) toujours possede par
apps/api, pousse au service via POST /v1/train a chaque warm-up ; le
service ne touche jamais Postgres (meme posture que
services/tech-step-llm-worker).

Cote apps/api :
- intent-service-client.ts : client HTTP vers le nouveau service
- tech-step-matcher.ts : delegue NER + intent classification au client,
  logique pure (splitIntoClauses, seuil/fallback) inchangee
- env.ts : INTENT_SERVICE_BASE_URL/INTENT_SERVICE_SECRET (secret requis,
  service coeur non optionnel)
- server.ts : warm-up avec retry/backoff (service Python demarre a part)
- scripts/calibrate-tech-step-threshold.ts : recalibration empirique de
  CONFIDENCE_THRESHOLD contre le jeu d'eval existant
- node-nlp retire (package.json, node-nlp.d.ts, model.nlp du .gitignore)

docker-compose.yml : nouveau service tech-step-intent-service (pas de
port expose, healthcheck, app en depend). CI : job intent-service-test
(pytest) + le job test demarre le service en arriere-plan avant la suite
Mocha (jamais de mock d'un service interne, cf specs/dev-conventions.md).

Verifie : 26/26 tests pytest du service (dont les offsets caracteres
exacts de tech-step-matcher.test.ts), lint + build complets du monorepo,
smoke test HTTP reel bout en bout. La suite Mocha et docker compose
build/up n'ont pas pu etre executes dans cet environnement (pas de
Postgres/Docker disponibles ici) — a confirmer via la CI et en local.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-25 20:11:30 +02:00

75 lines
2.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`).
"""
from pydantic import BaseModel, ConfigDict, Field
from pydantic.alias_generators import to_camel
# ---------------------------------------------------------------------------
# POST /v1/train
# ---------------------------------------------------------------------------
class TrainEntryPayload(BaseModel):
"""Une technique — mêmes champs qu'une entrée de `TECH_STEP_TRAINING_DATA`
(`apps/api/src/lib/recipe-matching/tech-step-training-data.ts`) pour une
locale donnée."""
uid: str
synonyms: list[str] = Field(default_factory=list)
utterances: list[str] = Field(default_factory=list)
class TrainRequest(BaseModel):
locale: str
entries: list[TrainEntryPayload]
class TrainResponse(BaseModel):
# camelCase en sortie (`labelCount`, pas `label_count`) — cohérent avec
# la convention JSON déjà en place côté `apps/api`/`packages/shared`
# (voir `TechStepAuditClauseView` etc.), même si le code Python interne
# reste en snake_case (convention PEP 8).
model_config = ConfigDict(alias_generator=to_camel, populate_by_name=True)
locale: str
label_count: int
utterance_count: int
synonym_count: int
# ---------------------------------------------------------------------------
# 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