Bring Your Own Engine

Inhalte werden von Phrase Language AI maschinell aus dem Englischen übersetzt.

Die Funktion „Bring Your Own Engine“ (BYO Engine) ermöglicht die Integration externer maschineller Übersetzungssysteme (MT) in Phrase, um diese in Übersetzungsworkflows wie jeden anderen MT-Anbieter zu nutzen.

BYO Engine eignet sich für:

Unternehmen mit domänenspezifischen MT-Modellen.
Sprachdienstleister (LSPs) mit kundenspezifischen Engines oder bevorzugten KI-Stacks.
Organisationen mit internen Richtlinien, die die Verwendung spezifischer Engines erfordern (z. B. Gemini, interne LLMs usw.).

Kundenspezifisch trainierte Engines können verwendet oder Übersetzungen an interne LLMs oder MT-Anbieter weitergeleitet werden, um die volle Kontrolle über Qualität, Datenschutz und Kosten zu behalten und gleichzeitig weiterhin von Phrases Translation Memories (TM), Glossaren, QPS und dem CAT-Editor zu profitieren.

Wo eine BYO Engine verwendet werden kann

Nach der Integration steht eine BYO Engine für die Vorübersetzung zur Verfügung. Im Phrase Language AI-Profil wird die Engine konfiguriert, sodass dieses Profil für die Vorübersetzung aus Phrase TMS-Projekten, Phrase Portal, Phrase Strings-Projekten, Phrase Studio und Phrase Language AI über die API genutzt werden kann.

Konfiguration einer Bring Your Own Engine

Erstellung des Adapters

Die Organisation muss einen leichtgewichtigen API-Adapter erstellen und testen. Dieser Adapter ermöglicht die Kommunikation zwischen Phrase und der Engine.

Der Adapter muss Folgendes unterstützen:
- Übersetzungsanfragen
- Unterstützung von Sprachpaaren
- Statusabfrage der Engine (Phrase sendet eine Statusanfrage)
Die zugrunde liegende Infrastruktur (MT-Engine oder LLM) muss von der Organisation gehostet und gewartet werden.
Phrase benötigt Berechtigungen, um eine Verbindung zu dieser Infrastruktur herzustellen.
Der Adapter muss Übersetzungen mit der gleichen Segmentanzahl und Reihenfolge zurückgeben.

Integration der Engine in ein MT-Profil

Sobald der API-Adapter implementiert und bereitgestellt ist, steht die BYO-Engine in Phrase Language AI zur Auswahl in MT-Profilen zur Verfügung und kann Projekten zugewiesen werden.

Zur Verbindung einer BYO-Engine mit einem MT-Profil:

Auf der Seite des Phrase Language AI MT-Profils ist auf MT-Engines verbinden zu klicken.

Die Seite MT-Engine verbinden wird angezeigt.
Es ist Bring Your Own (BYO) Engine auszuwählen.

Die Konfigurationsseite der BYO Engine öffnet sich.
Die Basis-Engine-URL ist einzugeben.
Je nach Authentifizierungsmethode sind die Anmeldedaten (HTTP-Header oder Client-Anmeldedaten (OAuth 2.0)) anzugeben.
Es ist auszuwählen, ob der Übersetzungscache verwendet werden soll. Standardmäßig aktiviert

Dies reduziert den Datenverkehr und beschleunigt die Übersetzungsantwort, indem Segmente, die innerhalb der letzten 30 Tage übersetzt wurden, wiederverwendet werden. Dies ist lediglich eine Optimierung der Aufrufleistung und reduziert nicht die Übersetzungskosten. Es sollte standardmäßig aktiviert bleiben und nur während der aktiven Entwicklung des zugrunde liegenden Engine-Adapters deaktiviert werden.
Unter Benutzerdefinierte Labels sind bei Bedarf zusätzliche Informationen für die Engine anzugeben.
Durch Klicken auf Verbindung validieren kann überprüft werden, ob die Engine-Integration funktioniert.
Auf Hinzufügen klicken.

Die Engine ist nun verfügbar und kann im Profil aktiviert werden.

Tipp

Bei Verwendung einer BYO Engine darf im MT-Profil keine andere Engine aktiviert werden. Dies stellt sicher, dass die BYO Engine für die Vorübersetzung ausgewählt wird.

Bearbeitung einer BYO Engine

Zum Bearbeiten einer BYO Engine ist auf das Bearbeiten-Symbol auf der Engine-Kachel zu klicken.

Löschen einer BYO Engine

Zum Löschen einer BYO Engine:

Auf das Bearbeiten-Symbol auf der Engine-Kachel ist zu klicken.
Auf Remove Bring Your Own Engine ist zu klicken.

HÄUFIGE FRAGEN (FAQ)

Q:	Warum ist die Statusanfrage erforderlich? Wird sie von Phrase an die Engine gesendet oder wird erwartet, dass sie vom Kunden verarbeitet wird?
A	Phrase sendet die Anfrage, um zu prüfen, ob die Engine funktioniert oder nicht.
Q:	Eine Anfrage kann 500 `maxItems` in `segments` enthalten. Bedeutet dies, dass 500 Quellsätze in Echtzeit übersetzt werden müssen?
A	Sowohl synchrone als auch asynchrone Aufrufe akzeptieren 1–500 Segmente. In der Praxis enthalten synchrone Aufrufe aus dem Editor ein einzelnes Segment, während API- und Batch-Workflows (Vorübersetzung, Analyse) viele, bis zu 500, senden können. Der asynchrone Ablauf verwendet dasselbe Limit und trennt lediglich das Übermitteln des Auftrags vom Abrufen des Ergebnisses. Das asynchrone Timeout beträgt etwa 30 Minuten. Ein automatischer Fallback von synchron zu asynchron erfolgt nicht, falls der Adapter eine Anfrage ablehnt. Weitere Details zu den Erwartungen an Phrase (Segmentanzahl, Engine-Validierungstest, Wiederholungsversuche und Zeitlimits) finden sich im BYO Engine Guide.
Q:	Werden alle Begriffe eines Glossars in einer Anfrage gesendet oder nur eine Teilmenge?
A	Alle Begriffe des Glossars werden gesendet.
Q:	Ist es möglich, ein LLM einzubinden?
A	Das sollte mit einem Wrapper möglich sein. Solange die Engine Segmente wie im Schema definiert zurückgibt, erfordert Phrase keine spezifische Engine oder LLM.
Q:	Ist eine benutzerdefinierte Qualitätsbewertung (QE) möglich?
A	QE von Drittanbietern wird nicht unterstützt.
Q:	Wie werden Tags gehandhabt?
A	Der Inhalt, den Phrase erhält, wird vorverarbeitet. HTML-Tags werden in Markierungen umgewandelt und diese Markierungen werden unverändert weitergegeben.
Q:	Eine Implementierung ausschließlich des asynchronen Ansatzes ist möglich? Wird es in allen Phrase-Bereichen (Vorübersetzung, Editor usw.) korrekt funktionieren?
A	Nein, beide Ansätze (idealerweise alle Endpunkte) müssen implementiert werden. Der synchrone Endpunkt wird zum Beispiel vom Editor verwendet, während der asynchrone in Bereichen wie der Vorübersetzung zum Einsatz kommt.
Q:	Was passiert, wenn die Engine mehrere Anfragen gleichzeitig erhält?
A	Die Engine muss dazu in der Lage sein, dies zu verarbeiten. Eine ordnungsgemäße Handhabung von Nebenläufigkeit und Threadsicherheit über alle Endpunkte hinweg, insbesondere bei asynchronen, muss sichergestellt werden.
Q:	Wie funktioniert Request Metadata?
A	Sie muss statisch bleiben, wie bei der Einrichtung der Engine definiert.
Q:	Wie funktioniert Segment Metadata?
A	Derzeit muss sie Teil des Schemas sein.
Q:	Verwendet BYO Engine während der MT-Verarbeitung RAG, um Kontext abzurufen?
A	Nein, BYO Engine verwendet kein RAG. TMs können genutzt werden, um zu ermitteln, welche Segmente übersetzt wurden, sie fließen jedoch nicht in den eigentlichen MT-Prozess ein. Dies liegt daran, dass MT-Engines speziell dafür ausgelegt sein müssen, TM-Daten über RAG einzubinden, und bei BYO Engine-Szenarien gibt es keine Kontrolle darüber, wie Engines erstellt oder konfiguriert werden.

Adapter-Schema-Referenz

Der Adapter muss Antworten zurückgeben, die exakt mit den folgenden Feldnamen und Enum-Werten übereinstimmen. Eine Nichtübereinstimmung führt zu einem generischen INTERNAL_ERROR von Phrase, selbst wenn der Adapter selbst eine 200 OK-Antwort zurückgibt.

POST /status muss ein status-Feld mit einem strikten kleingeschriebenen Enum-Wert von entweder ok oder not_ok zurückgeben. Beispiel: { "status": "ok" }
POST /languages muss ein languagePairs-Array (camelCase) zurückgeben, wobei jeder Eintrag ein sourceLanguage-Feld und ein targetLanguage-Feld enthält. Beispiel: { "languagePairs": [ { "sourceLanguage": "en", "targetLanguage": "es" } ] }
POST /translate und GET /translateAsyncResult/{id} müssen die übergeordneten Felder sourceLanguage und targetLanguage sowie ein segments-Array zurückgeben, wobei jedes Segment sowohl ein text-Feld (den zurückgegebenen Quelltext) als auch ein translatedText-Feld enthält. Die Rückgabe von nur translatedText oder die Verwendung eines anderen Schlüsselnamens führt zu einem Deserialisierungsfehler.
POST /translateAsync erfordert in seiner Antwort nur ein id-Feld. Ein status-Feld ist nicht Teil dieses Antwortschemas und wird ignoriert, falls es vorhanden ist.
GET /translateAsyncStatus/{id} muss ein status-Feld mit einem von drei Enum-Werten zurückgeben: running für einen Auftrag, der noch verarbeitet wird, done für einen erfolgreich abgeschlossenen Auftrag oder failed für einen fehlgeschlagenen Auftrag. Bei einem fehlgeschlagenen Auftrag kann ein optionales detail-Feld den Fehler beschreiben. Beispielwerte: { "status": "running" }, { "status": "done" }, { "status": "failed", "detail": "Beschreibung des Übersetzungsfehlers"}