* feat(tech-steps): fiabilise la detection des tech steps (corpus + LLM + corrections utilisateur)
Une seule feature livree en une seule PR, en 5 phases :
- Phase 1 : enrichit le corpus NLP (tech-step-training-data.ts) et ajoute
un harness d'evaluation (precision/rappel/F1) avec un jeu de test etiquete
- la premiere metrique objective de qualite pour ce classifieur.
- Phase 2 : schema Prisma (StepTechStepCorrection, TechStepTrainingSuggestion)
+ endpoints utilisateur (POST/GET corrections, ouverts a tout viewer, pas
seulement l'auteur) + endpoints internes /internal/tech-steps/* proteges
par secret partage (requireInternalWorker).
- Phase 3 : UI de highlight/correction cote web (selection de texte ->
association a une technique, ou clic sur un highlight existant pour le
corriger/supprimer) - verifiee via Cypress (component + e2e, en Chrome
reel).
- Phase 4 : worker LLM autonome (services/tech-step-llm-worker, hors du
monorepo pnpm comme experiments/llm-tech-step-poc) qui audite les clauses
a faible confiance et transforme les corrections utilisateur en
suggestions d'entrainement, sans jamais toucher le chemin interactif.
- Phase 5 : script retrain-tech-steps.ts (gate de regression F1 + backfill)
et list-pending-training-suggestions.ts pour la revue humaine avant
application au corpus.
Verification effectuee cette session : tsc/biome sur l'ensemble du repo,
build complet (pnpm build), suite Cypress complete (component 39/39, e2e
75/76 - le seul echec est preexistant et sans rapport, cote
recipe-form.feature/ingredient-picker), tests unitaires du worker (6/6) et
son install/typecheck reels contre node-llama-cpp. Les tests Mocha
d'apps/api (Phases 1 et 2) n'ont pas pu etre executes dans cette session
(pas de Postgres local disponible) - a lancer avant merge.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* fix(tech-steps): calibre le seuil F1 sur une vraie execution et corrige un bug de comptage
Docker etant redevenu disponible dans cette session, j'ai pu lancer pour de
vrai la suite Mocha d'apps/api (334/334, y compris les tests Phase 1/2
qui n'avaient pu etre executes precedemment) ainsi que les scripts de la
Phase 5 contre une vraie base de test.
- tech-step-eval-dataset.ts : corrige un vrai bug d'auteur - "Take the
plates..." collisionnait avec le synonyme anglais enregistre "plates"
(technique plate), invalidant ce cas negatif. Remplace par "dishes".
- tech-step-eval-runner.ts : F1 reel mesure = 0.815 (33 TP / 9 FP / 6 FN).
Documente ce chiffre et les vraies erreurs de classification decouvertes
(ex: "Blanchissez les haricots verts..." classifie a tort comme "peel")
- des faiblesses reelles du classifieur que ce harness est cense
detecter, pas a masquer en ajustant le jeu de test.
- retrain-tech-steps.ts : le script loggait `appliedIds.length`/
`rejectedIds.length` (ce qui a ete demande) au lieu du `count` reel
retourne par `updateMany` (ce qui a vraiment ete modifie) - un id
inexistant faisait afficher un faux succes. Decouvert en executant le
script pour de vrai avec des ids partiellement invalides.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* fix(tech-steps): corrige un span de correction incorrect sur un highlight existant
Bug reel trouve en lancant l'application pour de vrai et en cliquant sur
un highlight existant : la correction soumise couvrait presque toute la
description au lieu du seul mot-cle cliqué (ex: [6, 56) au lieu de [6, 13)
pour "mijoter").
Cause : StepDescription.tsx capturait `start` dans un `const` par
iteration de `.map()` (correct), mais utilisait `offset` directement (la
variable mutable partagee, pas une valeur capturee) pour `end` dans le
gestionnaire onClick - une fermeture classique sur variable de boucle
encore mutee. Par le temps ou l'utilisateur clique reellement (bien apres
la fin du rendu), `offset` contient sa valeur finale (fin de la
description entiere), pas celle du segment concerne.
Corrige en capturant `end` dans un `const` au meme endroit que `start`.
Renforce aussi l'assertion e2e correspondante (recipes.ts) qui ne
verifiait auparavant que la requete avait ete faite, jamais son contenu -
elle serait passee malgre ce bug.
Verifie en conditions reelles : recette creee via l'UI, correction
soumise, span persiste verifie directement en base (start=6, end=13,
previous=simmer, corrected=grill).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* chore: ignore les telechargements Cypress (artefact de run local)
* feat(tech-steps): distingue les corrections manuelles des détections auto
Les corrections utilisateur (via TechStepCorrectionPopover) sont
désormais écrites directement dans StepTechStep, avec une colonne
`source` ("auto" | "manual") qui les distingue des matches du
classifieur NLP :
- Migration `step_tech_step_source` ajoutant `source` (défaut "auto")
- `applyManualCorrection`/`renumberStepTechSteps` dans
recipe-tech-step-correction.service.ts : une correction met à jour
ou crée l'entrée StepTechStep concernée (source "manual"), la
réponse de l'endpoint inclut désormais le techSteps à jour du step
(SubmitTechStepCorrectionResult), pas seulement l'audit de
correction
- backfill-tech-steps.ts préserve les entrées "manual" existantes :
seules les entrées "auto" sont recalculées, et un nouveau match
auto chevauchant une correction manuelle est ignoré plutôt
qu'inséré en doublon — vérifié en base réelle (une correction
manuelle survit intacte à un backfill complet)
- Le front distingue visuellement les deux (StepDescription.tsx,
recipes.scss : `.step-tech-step--manual`, couleur Turmeric au lieu
de Basil), avec un tooltip "(correction manuelle)" et un indicateur
de découvrabilité de la fonctionnalité dans RecipeDetailPanel
Corrige aussi deux bugs trouvés en testant en conditions réelles :
- StepDescription.tsx : le clic sur un highlight existant lisait la
variable `offset` (mutable, partagée par la boucle) au lieu d'une
valeur capturée, envoyant un `end` erroné (fin de la description
entière au lieu du span du mot cliqué)
- backfill-tech-steps.ts : le garde `import.meta.url ===
file://${process.argv[1]}` ne matche jamais sur Windows (chemins à
antislash), le script ne faisait donc rien en exécution directe ;
remplacé par `pathToFileURL(process.argv[1]).href`
335 tests apps/api passants, 40/40 composants Cypress, 75/76 e2e
Cypress (1 flake pré-existant sans rapport, non touché ici).
* fix(worker): corrige le build Docker de tech-step-llm-worker
docker compose build tech-step-llm-worker échouait sur deux problèmes
en cascade, tous deux liés à l'isolation volontaire de ce service hors
du monorepo pnpm (seul son propre package.json/tsconfig.json est copié
dans son contexte de build) :
- pnpm install --ignore-workspace --frozen-lockfile échouait
(ERR_PNPM_IGNORED_BUILDS) : sans "packageManager" dans son
package.json, corepack télécharge le pnpm le plus récent
(11.22.0), qui a durci en erreur bloquante ce qui n'était qu'un
avertissement sur les builds de dépendances ignorés
(esbuild/node-llama-cpp). Le reste du repo est épargné parce que
apps/api/Dockerfile copie le package.json racine, qui pinne déjà
pnpm@10.12.4 — ce pin ne pouvait pas atteindre ce service isolé.
Fixé en pinnant la même version ici.
- tsc échouait ensuite (TS5083 puis erreurs en cascade dans les .d.ts
de node-llama-cpp) : tsconfig.json de ce service extends le
tsconfig.base.json racine (skipLibCheck notamment), jamais copié
dans le contexte de build. Fixé en le copiant avant tsconfig.json.
Vérifié : `docker compose build tech-step-llm-worker` complet en local.
* fix(tech-steps): empêche le contexte d'un match d'avaler une correction manuelle voisine
La correction manuelle ne s'affichait pas quand elle portait sur du texte
qui n'était pas une technique à l'origine — reproduit en live : une
description avec un seul match auto-détecté ("mijoter") voit son
contexte de clause s'étendre sur toute la description dès que
splitIntoClauses (tech-step-matcher.ts) n'a trouvé qu'un seul candidat
NER (le cas courant), même quand ce candidat n'a aucun rapport avec le
reste du texte. splitDescriptionByTechSteps avançait alors son curseur
jusqu'à la fin de ce contexte large, ce qui faisait purement et
simplement disparaître (silencieusement, sans erreur) toute correction
manuelle ajoutée plus loin dans la même description — un mot pourtant
sans aucun rapport avec la technique auto-détectée.
Le contexte d'un match est purement cosmétique (StepDescription.tsx le
rend identique à du texte brut depuis que sa mise en valeur dédiée a
été désactivée) et ne doit donc jamais coûter son propre highlight à
un *autre* match. splitDescriptionByTechSteps distingue maintenant
deux notions : le chevauchement entre les spans *keyword* stricts de
deux entrées (toujours un vrai conflit, l'entrée la plus tardive est
toujours ignorée, comportement inchangé) et le chevauchement du
contexte *cosmétique* d'une entrée sur le keyword d'une autre (jamais
un vrai conflit désormais : le contexte est simplement rogné pour
laisser la place, plutôt que l'entrée voisine entière étant abandonnée).
Vérifié en conditions réelles (Docker) : une correction manuelle sur
"materiel" dans "Faire mijoter la sauce, puis ranger le materiel."
s'affiche maintenant correctement à côté du highlight auto "mijoter",
et survit à un rechargement complet de la page.
Nouveau test de régression dans highlight-tech-steps.cy.tsx
reproduisant exactement ce cas ; les 18 tests du fichier (dont tous
les cas de contexte/malformation déjà couverts) passent toujours.
---------
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
190 lines
9.4 KiB
TypeScript
190 lines
9.4 KiB
TypeScript
import path from "node:path";
|
|
import { fileURLToPath } from "node:url";
|
|
import {
|
|
getLlama,
|
|
type Llama,
|
|
LlamaChatSession,
|
|
type LlamaContext,
|
|
type LlamaJsonSchemaGrammar,
|
|
type LlamaModel,
|
|
resolveModelFile,
|
|
} from "node-llama-cpp";
|
|
import { env } from "./config.js";
|
|
|
|
/**
|
|
* Local LLM inference for this worker's two jobs — model loading/grammar
|
|
* compilation ported from `experiments/llm-tech-step-poc/src/llm-tech-step-poc.ts`'s
|
|
* `LocalLlmStepAnalyzer` (same `node-llama-cpp` API: `getLlama()` ->
|
|
* `loadModel()` -> `createContext()` -> `createGrammarForJsonSchema()`, a
|
|
* fresh `LlamaContextSequence` allocated and disposed per call rather than
|
|
* a shared `LlamaChatSession` growing its own history across calls), *not*
|
|
* copied wholesale — this worker judges against the real ~26-key `TechStep`
|
|
* taxonomy (fetched at runtime, see `tech-step-taxonomy.ts`), not that
|
|
* PoC's own fixed 7-category `KitchenActionType`, and needs two distinct
|
|
* tasks (clause verdict, training-data suggestion) rather than that PoC's
|
|
* one full-step structuring task — so the schemas/prompts here are new,
|
|
* only the surrounding model-lifecycle mechanics are reused.
|
|
*/
|
|
|
|
/** Directory GGUF weights are downloaded/cached in — gitignored, same convention as the PoC's own `models/` directory next to it. */
|
|
const MODELS_DIRECTORY = path.join(path.dirname(fileURLToPath(import.meta.url)), "..", "models");
|
|
|
|
async function resolveModelPath(): Promise<string> {
|
|
if (env.TECH_STEP_LLM_MODEL_PATH !== undefined && env.TECH_STEP_LLM_MODEL_PATH.length > 0) {
|
|
return env.TECH_STEP_LLM_MODEL_PATH;
|
|
}
|
|
return await resolveModelFile(env.TECH_STEP_LLM_MODEL_URI, MODELS_DIRECTORY);
|
|
}
|
|
|
|
/** JSON shape `judgeClause` asks the model for — `techStepKey` constrained (via {@link buildClauseVerdictSchema}) to exactly the taxonomy's own keys, plus `null` for "none of them". */
|
|
interface ClauseVerdictResult {
|
|
techStepKey: string | null;
|
|
}
|
|
|
|
/** Builds the JSON schema constraining `judgeClause`'s output to one of `techStepKeys`, or `null` — compiled fresh per {@link TechStepLlmService.initialize} call since the taxonomy (and so the valid `enum` values) is only known once fetched from the API, not at module-load time. */
|
|
function buildClauseVerdictSchema(techStepKeys: string[]) {
|
|
return {
|
|
type: "object",
|
|
properties: {
|
|
techStepKey: { oneOf: [{ type: "null" }, { enum: techStepKeys }] },
|
|
},
|
|
required: ["techStepKey"],
|
|
} as const;
|
|
}
|
|
|
|
/** JSON shape `suggestTrainingData` asks the model for. Array sizes are steered by the prompt (`buildSuggestionSystemPrompt`'s "at most 3"/"at most 2"), not the grammar itself — `experiments/llm-tech-step-poc`'s own schemas never constrained array length either, and adding an unfamiliar JSON-schema keyword here risked breaking grammar compilation for no proven benefit. */
|
|
const TRAINING_SUGGESTION_JSON_SCHEMA = {
|
|
type: "object",
|
|
properties: {
|
|
suggestedSynonyms: { type: "array", items: { type: "string" } },
|
|
suggestedUtterances: { type: "array", items: { type: "string" } },
|
|
},
|
|
required: ["suggestedSynonyms", "suggestedUtterances"],
|
|
} as const;
|
|
|
|
/** Result shape for {@link TechStepLlmService.suggestTrainingData}. */
|
|
export interface TrainingSuggestionResult {
|
|
suggestedSynonyms: string[];
|
|
suggestedUtterances: string[];
|
|
}
|
|
|
|
function buildClauseVerdictSystemPrompt(techStepKeys: string[]): string {
|
|
return `You are a culinary technique classifier. You receive one short clause from a recipe step, written in French or English, and a fixed list of known technique keys. Decide which single technique from the list the clause most likely describes — including when it describes the technique without ever naming it (e.g. "until the butter has disappeared into the pan" means "melt"). If the clause doesn't clearly describe any technique in the list, answer null. Respond with ONLY the JSON object required by the schema — no prose, no markdown.
|
|
|
|
Known technique keys: ${techStepKeys.join(", ")}`;
|
|
}
|
|
|
|
/** French clitic-pronoun lesson from `experiments/llm-tech-step-poc/src/nlp-tech-step-poc.ts` (e.g. "faites-les revenir" breaking a "faire revenir" match) encoded directly into the prompt — a suggestion generated without this steer would reproduce the exact multi-word-synonym trap that PoC found and this feature's plan calls out. */
|
|
function buildSuggestionSystemPrompt(techStepKey: string, locale: string): string {
|
|
return `You are helping expand a training corpus (locale "${locale}") for a cooking-technique detector. You receive a real recipe clause a human has confirmed means the technique "${techStepKey}". Suggest at most 3 short new synonym words/phrases for this technique, and at most 2 example training sentences that use it in context (paraphrases are welcome, not just the literal clause). Prefer single-word verb forms over multi-word phrases when both would work — a multi-word phrase like "faire revenir" can silently fail to match a real sentence like "faites-les revenir" (French object pronoun inserted between the two words), while the bare verb "revenir" still would. Respond with ONLY the JSON object required by the schema — no prose, no markdown.`;
|
|
}
|
|
|
|
/**
|
|
* Owns the loaded model/context/compiled grammars for this worker's whole
|
|
* run — a real class (not a plain object), same "holds real, expensive-to-
|
|
* rebuild state" reasoning as `TechStepClassifierService`
|
|
* (`apps/api/src/lib/recipe-matching/tech-step-matcher.ts`) and the PoC's
|
|
* own `LocalLlmStepAnalyzer`.
|
|
*/
|
|
export class TechStepLlmService {
|
|
private _llama: Llama | undefined;
|
|
private _model: LlamaModel | undefined;
|
|
private _context: LlamaContext | undefined;
|
|
private _verdictGrammar:
|
|
| LlamaJsonSchemaGrammar<ReturnType<typeof buildClauseVerdictSchema>>
|
|
| undefined;
|
|
private _suggestionGrammar:
|
|
| LlamaJsonSchemaGrammar<typeof TRAINING_SUGGESTION_JSON_SCHEMA>
|
|
| undefined;
|
|
private _techStepKeys: string[] = [];
|
|
|
|
/**
|
|
* Loads the model, creates its inference context, and compiles both
|
|
* grammars — `techStepKeys` (from `loadTechStepTaxonomy`) is what the
|
|
* verdict grammar's `enum` is built from, so it must be known before this
|
|
* can complete (see {@link buildClauseVerdictSchema}).
|
|
*/
|
|
public async initialize(techStepKeys: string[]): Promise<void> {
|
|
this._techStepKeys = techStepKeys;
|
|
const modelPath = await resolveModelPath();
|
|
this._llama = await getLlama();
|
|
this._model = await this._llama.loadModel({ modelPath });
|
|
this._context = await this._model.createContext({ contextSize: 4096 });
|
|
this._verdictGrammar = await this._llama.createGrammarForJsonSchema(
|
|
buildClauseVerdictSchema(techStepKeys),
|
|
);
|
|
this._suggestionGrammar = await this._llama.createGrammarForJsonSchema(
|
|
TRAINING_SUGGESTION_JSON_SCHEMA,
|
|
);
|
|
}
|
|
|
|
/**
|
|
* Judges one clause against the taxonomy `initialize` was given, and
|
|
* returns its verdict's technique `key`, or `null` for "none of them
|
|
* clearly". A grammar-invalid or empty response degrades to `null`
|
|
* (treated as "no opinion") rather than throwing — one bad generation
|
|
* shouldn't abort the whole scheduled run over a single clause.
|
|
*/
|
|
public async judgeClause(clauseText: string): Promise<string | null> {
|
|
if (this._context === undefined || this._verdictGrammar === undefined) {
|
|
throw new Error("TechStepLlmService.initialize() must be awaited before judgeClause().");
|
|
}
|
|
const context = this._context;
|
|
const grammar = this._verdictGrammar;
|
|
const sequence = context.getSequence();
|
|
try {
|
|
const session = new LlamaChatSession({
|
|
contextSequence: sequence,
|
|
systemPrompt: buildClauseVerdictSystemPrompt(this._techStepKeys),
|
|
});
|
|
const response = await session.prompt(clauseText, { grammar });
|
|
const parsed = grammar.parse(response) as ClauseVerdictResult;
|
|
return parsed.techStepKey;
|
|
} catch {
|
|
return null;
|
|
} finally {
|
|
await sequence.dispose();
|
|
}
|
|
}
|
|
|
|
/**
|
|
* Proposes candidate synonyms/utterances for `techStepKey` from one
|
|
* confirmed clause. An invalid/empty response degrades to an empty
|
|
* suggestion (`{ suggestedSynonyms: [], suggestedUtterances: [] }`) —
|
|
* `transform-corrections` skips posting a suggestion that came back
|
|
* empty on both arrays, rather than treating a bad generation as a
|
|
* job-ending failure.
|
|
*/
|
|
public async suggestTrainingData(
|
|
clauseText: string,
|
|
techStepKey: string,
|
|
locale: string,
|
|
): Promise<TrainingSuggestionResult> {
|
|
if (this._context === undefined || this._suggestionGrammar === undefined) {
|
|
throw new Error(
|
|
"TechStepLlmService.initialize() must be awaited before suggestTrainingData().",
|
|
);
|
|
}
|
|
const context = this._context;
|
|
const grammar = this._suggestionGrammar;
|
|
const sequence = context.getSequence();
|
|
try {
|
|
const session = new LlamaChatSession({
|
|
contextSequence: sequence,
|
|
systemPrompt: buildSuggestionSystemPrompt(techStepKey, locale),
|
|
});
|
|
const response = await session.prompt(clauseText, { grammar });
|
|
return grammar.parse(response) as TrainingSuggestionResult;
|
|
} catch {
|
|
return { suggestedSynonyms: [], suggestedUtterances: [] };
|
|
} finally {
|
|
await sequence.dispose();
|
|
}
|
|
}
|
|
|
|
/** Releases the model/context — native memory, not managed by V8's GC. Called once per scheduled run (see `scheduler.ts`) rather than kept loaded between runs, so the process's RAM footprint returns to idle between them. */
|
|
public async dispose(): Promise<void> {
|
|
await this._context?.dispose();
|
|
await this._model?.dispose();
|
|
}
|
|
}
|