Tradurre sembra il compito più semplice del dominio, e invece è quello dove AI-103 mette la scelta architetturale più interessante: dallo stesso endpoint puoi far tradurre una rete neurale specializzata oppure un modello linguistico, e le due cose hanno costi, garanzie e comportamenti diversi. Sopra ci sta il tema più generale di questa unità: come si piega l’output di un modello al linguaggio di un settore specifico senza addestrare niente da capo.

Le due famiglie di traduzione in Azure Translator

Azure Translator in Foundry Tools è un servizio di neural machine translation che si divide in due famiglie, e la prima domanda da farsi è che cosa stai traducendo.

La text translation prende stringhe e restituisce stringhe. Esistono due versioni GA in parallelo: la v3, con i parametri di query from e to, il dizionario dinamico e la funzione di prevenzione della traduzione per i termini da lasciare intatti; e la 2026-06-06, che riorganizza tutto in un corpo JSON e introduce la selezione del modello. Le operazioni disponibili oltre a translate sono transliterate, detect e dictionary.

La document translation prende file e li restituisce tradotti preservando struttura e formattazione, cosa che una traduzione stringa per stringa distrugge. Qui la scelta è fra due modalità: quella asincrona in batch, che richiede un account Azure Blob Storage con container di origine e destinazione e accetta glossari, e quella sincrona su singolo file, che non richiede storage perché restituisce il documento tradotto direttamente al chiamante. Batch quando i file sono molti o grandi, sincrona quando l’utente sta aspettando davanti allo schermo.

Esiste infine il container Translator, che porta il servizio dentro il perimetro quando i dati non possono uscire.

Translator o LLM? La versione 2026-06-06 non ti obbliga a scegliere

Il punto più esaminabile della nuova API è che il motore si seleziona per singolo target, con la proprietà deploymentName dentro l’array targets. Il valore riservato general usa il sistema NMT; il nome di un deployment di modello linguistico fa passare quella traduzione da un LLM; l’identificativo di categoria di un modello Custom Translator usa il tuo modello NMT addestrato.

{
  "inputs": [
    {
      "text": "The policy takes effect immediately.",
      "language": "en",
      "textType": "plain",
      "targets": [
        {
          "language": "it",
          "deploymentName": "il-tuo-deployment-llm",
          "tone": "formal",
          "gender": "female",
          "allowFallback": "true"
        }
      ]
    }
  ]
}

La via LLM sblocca controlli che l’NMT non ha: tone con i valori formal, informal e neutral, e gender con female, male e neutral per le lingue che marcano il genere. In cambio cambia la fatturazione, perché la risposta riporta i token di istruzione, sorgente e target oltre ai caratteri, mentre la traduzione NMT si conta a caratteri sorgente. E c’è un vincolo di rete da ricordare: la traduzione basata su LLM non è disponibile quando la risorsa Translator è configurata con un private endpoint.

La scelta pratica: NMT quando conta la prevedibilità del costo, la latenza bassa e il volume alto; LLM quando conta il registro, il contesto lungo o la resa di un testo che l’NMT rende letteralmente ma male. Il parametro allowFallback, che vale true per default, decide se una coppia linguistica non supportata dal modello scelto ricade sul sistema generale o restituisce un errore: mettilo a false quando la coerenza terminologica conta più della copertura.

Personalizzare senza addestrare da zero

Qui l’esame vuole una scala, non un’unica risposta. Dal più leggero al più impegnativo:

  1. Istruzioni e few-shot nel prompt, per un flusso di traduzione affidato interamente a un LLM. Costo zero, nessun asset da mantenere, ma la coerenza dipende dal prompt.
  2. referenceTextPairs nella richiesta di translate: coppie sorgente-target passate al volo che orientano la resa. Quando sono presenti, prevalgono su un eventuale dataset adattivo.
  3. Adaptive custom translation: si caricano da 5 a 10.000 coppie di segmenti preallineati, ciascuna entro 500 caratteri, e il servizio costruisce in pochi minuti un indice bilingue che si richiama con adaptiveDatasetId. Adatta i modelli linguistici supportati alla terminologia, al contesto e allo stile del tuo dominio senza alcun training.
  4. Custom Translator: qui si addestra davvero un modello NMT di dominio, con la possibilità di definire dizionari di frase o di sentenza. È l’opzione giusta quando il vocabolario è stabile, ampio e la coerenza è contrattuale.

La regola implicita è quella che l’esame ripete in tutti i domini: si sale di gradino solo quando il gradino precedente è stato misurato e non basta.

Compiti di dominio: compliance summarization e domain extraction

Lo stesso schema si applica quando il compito non è tradurre ma produrre un riassunto conforme a una policy o estrarre i campi di un dominio. Non serve un modello nuovo: serve un contratto d’uscita e una verifica.

Il contratto d’uscita è uno schema strutturato che descrive esattamente i campi attesi, più istruzioni che vietano di riempire ciò che non è nel testo. Per la compliance summarization aggiungi una rubrica esplicita — quali clausole vanno sempre citate, quale livello di dettaglio, quale formulazione è vietata — perché una rubrica scritta è ciò che rende la valutazione ripetibile. Ancora il modello alle fonti recuperate, così che ogni affermazione sia riconducibile a un passaggio del documento originale, e non alla memoria del modello.

La verifica passa dagli evaluator di Microsoft Foundry: groundedness per accertare che l’output resti ancorato alla sorgente, relevance e response completeness per la qualità della risposta. È il ciclo che trasforma «il riassunto sembra buono» in un numero che puoi confrontare fra due versioni del prompt.

Da ricordare per l’esame

  • Document translation quando serve preservare struttura e formattazione: asincrona con container Blob di origine e destinazione, sincrona su singolo file senza storage.
  • Nella text translation 2026-06-06 il motore si sceglie con deploymentName: general per l’NMT, il nome di un deployment per un LLM, l’ID di categoria per un modello Custom Translator.
  • Solo la via LLM offre tone e gender; in cambio si paga a token oltre che a caratteri, e non funziona con un private endpoint.
  • Adaptive custom translation adatta un LLM al tuo dominio con da 5 a 10.000 coppie preallineate entro 500 caratteri l’una, senza training; Custom Translator addestra invece un modello NMT.
  • Personalizzare per un compito di dominio significa schema di output, rubrica esplicita, grounding sulla fonte e misurazione con gli evaluator — non fine-tuning come primo passo.