Traduction automatique

Bring Your Own Engine

Le contenu est traduit de l’anglais par Phrase Language AI.

La fonctionnalité Bring Your Own Engine (BYO Engine) permet l'intégration de moteurs de traduction automatique (TA) externes dans Phrase pour être utilisés dans les flux de travail de traduction comme n'importe quel autre fournisseur de TA.

Le Bring Your Own Engine est adapté pour :

  • Les entreprises avec des modèles de TA spécifiques à un domaine.

  • Les LSP avec des moteurs clients personnalisés ou des piles d'IA privilégiées.

  • Les organisations avec des politiques internes qui exigent l'utilisation de moteurs spécifiques (par exemple Gemini, LLM internes, etc.).

Des moteurs entraînés de manière personnalisée peuvent être utilisés ou les traductions peuvent être acheminées vers des LLM internes ou des fournisseurs de TA pour conserver un contrôle total sur la qualité, la confidentialité et le coût tout en continuant à bénéficier des mémoires de traduction (MT), glossaires, QPS et du CAT Editor de Phrase.

Où un Bring Your Own Engine peut être utilisé

Une fois intégré, un moteur personnalisé est disponible pour la pré-traduction. Configurez-le dans un profil Language AI de Phrase et utilisez ce profil pour pré-traduire depuis des projets Phrase TMS, Phrase Portal, des projets Phrase Strings, Phrase Studio et Phrase Language AI via API.

Configurer un Bring Your Own Engine

Création de l'adaptateur

  • L'organisation doit créer et tester un adaptateur API léger. Cet adaptateur permet la communication entre Phrase et le moteur.

    L'adaptateur doit prendre en charge :

    • Les demandes de traduction

    • La prise en charge des paires de langues

    • La vérification du statut du moteur (Phrase envoie une demande de statut)

  • L'infrastructure sous-jacente (moteur de TA ou LLM) doit être hébergée et maintenue par l'organisation.

  • Phrase nécessite des autorisations pour se connecter à cette infrastructure.

  • L'adaptateur doit renvoyer des traductions avec le même nombre de segments et le même ordre.

Intégration du moteur dans un profil de TA

Une fois l'adaptateur API implémenté et déployé, le Bring Your Own Engine devient disponible dans Phrase Language AI pour être sélectionné dans les profils de TA et peut être assigné à des projets.

Pour connecter un Bring Your Own Engine à un profil TA :

  1. Depuis la page du profil TA de Phrase Language AI, cliquez sur Connecter des moteurs TA.

    La page Connecter un moteur TA s'affiche.

  2. Sélectionnez Bring Your Own (BYO) Engine.

    La page de configuration du moteur BYO s'ouvre.

  3. Entrez l'URL de base du moteur.

  4. Fournissez les informations d’identification en fonction de la méthode d'authentification (en-tête HTTP ou informations d’identification client (OAuth 2.0)).

  5. Sélectionnez si vous souhaitez utiliser le cache de traduction. Activé par défaut.

    Réduit le trafic et accélère la réponse de traduction en réutilisant les segments traduits au cours des 30 derniers jours. Il s'agit uniquement d'une optimisation des performances d'appel, cela ne réduit pas le coût de traduction. Gardez-le activé par défaut, désactivez-le uniquement pendant que l'adaptateur de moteur sous-jacent est en cours de développement actif.

  6. Si nécessaire, fournissez toute information supplémentaire pour le moteur sous Étiquettes personnalisées.

  7. Cliquez sur Valider la connexion pour vérifier si l'intégration du moteur fonctionne.

  8. Cliquez sur Ajouter.

    Le moteur est maintenant disponible pour être activé dans le profil.

Astuce

Lors de l'utilisation d'un moteur BYO, n'activez aucun autre moteur dans le profil TA. Cela garantit que le moteur BYO est sélectionné pour la pré-traduction.

Modifier un Bring Your Own Engine

Pour modifier un Bring Your Own Engine, cliquez sur l'icône de modification sur la tuile du moteur.

Supprimer un Bring Your Own Engine

Pour supprimer un Bring Your Own Engine :

  1. Cliquez sur l'icône de modification sur la tuile du moteur.

  2. Cliquez sur Retirer le Bring Your Own Engine.

FAQ

Q :

Pourquoi la demande de statut est-elle requise ? Est-elle envoyée par Phrase au moteur, ou est-il attendu qu'elle soit gérée par le client ?

R :

Phrase envoie la demande pour vérifier si le moteur fonctionne ou non.

Q :

Une demande peut contenir 500 maxItems dans segments. Cela implique-t-il que 500 phrases source doivent être traduites en temps réel ?

R :

Les appels synchrones incluent seulement jusqu'à 5 segments, tandis que les appels asynchrones peuvent en inclure davantage, jusqu'à 500. De plus, le délai d'expiration asynchrone est d'environ 30 minutes.

Q :

Tous les termes d'un glossaire sont-ils envoyés dans une demande, ou seulement un sous-ensemble ?

R :

Tous les termes du glossaire sont envoyés.

Q :

Est-il possible de connecter un LLM ?

R :

Cela devrait être possible avec un wrapper. Tant que le moteur renvoie des segments tels que définis dans le schéma, Phrase ne nécessite pas de moteur ou de LLM spécifique.

Q :

Une évaluation de la qualité (QE) personnalisée est-elle possible ?

R :

La QE tierce n'est pas prise en charge.

Q :

Comment les balises sont-elles gérées ?

R :

Le contenu que Phrase reçoit est pré-traité. Les balises HTML sont converties en marques, et ces marques sont transmises telles quelles.

Q :

Pouvons-nous implémenter uniquement l'approche asynchrone ? Cela fonctionnera-t-il correctement dans toutes les zones de Phrase (pré-traduction, éditeur, etc.) ?

R :

Non, les deux approches (idéalement tous les points de terminaison) doivent être implémentées. Le point de terminaison synchrone est utilisé, par exemple, par l'éditeur, tandis que l'asynchrone est utilisé dans des zones telles que la pré-traduction.

Q :

Que se passe-t-il lorsque le moteur reçoit plusieurs requêtes en même temps ?

R :

Le moteur doit être capable de gérer cela. Assurez-vous d'une gestion appropriée de la concurrence et de la sécurité des threads sur tous les points de terminaison, en particulier les asynchrones.

Q :

Comment fonctionnent les métadonnées de requête ?

R :

Elles doivent rester statiques, telles que définies lors de la configuration du moteur.

Q :

Comment fonctionnent les métadonnées de segment ?

R :

Actuellement, elles doivent faire partie du schéma.

Q :

Lors du traitement par MT, BYOE utilise-t-il RAG pour récupérer le contexte ?

R :

Non, BYOE n'utilise pas RAG. Les utilisateurs peuvent tirer parti des TM pour déterminer quels segments sont traduits, mais ils ne sont pas utilisés au sein du processus de MT lui-même. C'est parce que les moteurs de MT doivent être spécifiquement conçus pour intégrer les données de TM via RAG, et dans les scénarios BYOE, il n'y a aucun contrôle sur la façon dont les moteurs sont construits ou configurés.

Référence du schéma d'adaptateur

L'adaptateur doit renvoyer des réponses qui correspondent exactement aux noms de champ et aux valeurs enum suivants. Une non-correspondance entraîne une INTERNAL_ERROR générique de la part de Phrase, même lorsque l'adaptateur lui-même renvoie une réponse 200 OK.

  • POST /status doit renvoyer un champ status avec une valeur enum stricte en minuscules, soit ok, soit not_ok. Exemple : { \"status\": \"ok\" }

  • POST /languages doit renvoyer un tableau languagePairs (camelCase), chaque entrée contenant un champ sourceLanguage et un champ targetLanguage. Exemple : { \"languagePairs\": [ { \"sourceLanguage\": \"en\", \"targetLanguage\": \"es\" } ] }

  • POST /translate et GET /translateAsyncResult/{id} doivent renvoyer des champs sourceLanguage et targetLanguage de premier niveau, ainsi qu'un tableau segments où chaque segment inclut à la fois un champ text (le texte source renvoyé) et un champ translatedText. Le renvoi du seul champ translatedText, ou l'utilisation d'un nom de clé différent, provoque un échec de désérialisation.

  • POST /translateAsync ne nécessite qu'un champ id dans sa réponse. Un champ status ne fait pas partie de ce schéma de réponse et est ignoré s'il est présent.

  • GET /translateAsyncStatus/{id} doit renvoyer un champ status utilisant l'une des trois valeurs enum : running pour une tâche en cours de traitement, done pour une tâche terminée avec succès, ou failed pour une tâche ayant échoué. Pour une tâche ayant échoué, un champ optionnel detail peut décrire l'échec. Exemples de valeurs : { \"status\": \"running\" }, { \"status\": \"done\" }, { \"status\": \"failed\", \"detail\": \"Description of translation failure\" }

Cet article vous a-t-il été utile ?

Sorry about that! In what way was it not helpful?

The article didn’t address my problem.
I couldn’t understand the article.
The feature doesn’t do what I need.
Other reason.

Note that feedback is provided anonymously so we aren't able to reply to questions.
If you'd like to ask a question, submit a request to our Support team.
Thank you for your feedback.