Nicolas
18abae7b6a
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>
34 lines
1.9 KiB
Docker
34 lines
1.9 KiB
Docker
# Standalone image for services/tech-step-intent-service — hors du build
|
|
# apps/api (voir services/tech-step-llm-worker/Dockerfile pour le précédent
|
|
# direct : un service Python/spaCy n'a rien à faire dans l'image Node de
|
|
# l'API, et inversement). Rien n'est persisté sur disque (pas de VOLUME,
|
|
# contrairement au worker LLM) : tout l'état (textcat/matcher entraînés)
|
|
# vit en mémoire, reconstruit à chaque `/v1/train` depuis un corpus que ce
|
|
# service ne possède pas lui-même (voir intent_service/README.md).
|
|
FROM python:3.12-slim AS base
|
|
RUN apt-get update && apt-get install -y --no-install-recommends ca-certificates && rm -rf /var/lib/apt/lists/*
|
|
COPY --from=ghcr.io/astral-sh/uv:latest /uv /usr/local/bin/uv
|
|
WORKDIR /service
|
|
|
|
FROM base AS build
|
|
# `uv.lock` est commité pour ce service (même rigueur que
|
|
# `pnpm-lock.yaml`/`--frozen-lockfile` pour apps/api et
|
|
# services/tech-step-llm-worker) — `--frozen` échoue bruyamment si
|
|
# `pyproject.toml` a dérivé du lock plutôt que de re-résoudre en silence.
|
|
# `--no-install-project` sépare l'installation des dépendances (dont les
|
|
# wheels de modèles spaCy, pinnés par URL dans pyproject.toml) de la copie
|
|
# du code applicatif, pour que le cache de layer Docker survive à un
|
|
# changement dans intent_service/ sans retélécharger ~80 Mo de modèles.
|
|
# Chemins préfixés par `services/tech-step-intent-service/` : le contexte
|
|
# de build est la racine du repo (`docker-compose.yml`'s `build.context: .`),
|
|
# même convention que `services/tech-step-llm-worker/Dockerfile`.
|
|
COPY services/tech-step-intent-service/pyproject.toml services/tech-step-intent-service/uv.lock ./
|
|
RUN uv sync --frozen --no-install-project --no-dev
|
|
COPY services/tech-step-intent-service/intent_service ./intent_service
|
|
RUN uv sync --frozen --no-dev
|
|
|
|
FROM base AS runtime
|
|
ENV PYTHONUNBUFFERED=1
|
|
COPY --from=build /service /service
|
|
EXPOSE 8000
|
|
CMD ["uv", "run", "uvicorn", "intent_service.main:app", "--host", "0.0.0.0", "--port", "8000"]
|