OmniDocLes paragraphes répétés peuvent réutiliser la traduction, mais la clé de cache ne peut pas contenir uniquement le texte original.
« Enregistrer » a la même apparence dans les deux projets, mais la traduction, la casse et le contexte peuvent différer. En utilisant le hachage du texte original comme clé de cache unique, il est facile de réutiliser les traductions d'un projet à un autre, ou même de les mélanger entre locataires. La mise en cache ne concerne pas seulement le taux de réussite. Vous devez d'abord définir quelles conditions sont identiques avant que la réutilisation ne soit autorisée.
La clé de la mise en cache des traductions est de définir quelles conditions sont les mêmes pour permettre la réutilisation. La même phrase « enregistrer » peut avoir des traductions, des majuscules et un contexte différents selon les projets. Si seuls les hachages du texte source sont utilisés comme clés de cache, les traductions d'un projet peuvent être utilisées à mauvais escient pour un autre projet ou même mélangées entre les locataires.
Cet article est destiné aux développeurs et aux équipes de documentation qui doivent concevoir des caches de traduction. Après avoir lu ceci, vous saurez quelles conditions une clé de cache doit contenir, comment utiliser la sérialisation structurée pour éviter les ambiguïtés de raccordement et quoi d'autre vérifier après un accès au cache.
Comment concevoir la clé de cache de traduction ? Conclusion en une phrase
La clé de cache doit représenter une décision de traduction, et la réutilisation des résultats existants n'est autorisée que lorsque la langue source, la langue cible, la version terminologique, la version de politique et la portée d'utilisation sont identiques.
| votre situation | Pratiques recommandées | raison |
|---|---|---|
| La même phrase peut être traduite différemment dans différents projets | Inclure la portée d'utilisation dans la clé de cache | Évitez de réutiliser les traductions d’un projet à un autre |
| Plusieurs locataires partagent le même cache | L'ID du locataire saisit la clé et effectue une vérification des autorisations pendant la requête | L'ID du locataire peut uniquement isoler la dénomination et ne peut pas remplacer la vérification des autorisations |
| Le glossaire a été révisé | De nouvelles clés sont générées lorsque les versions de termes sont différentes | La décision terminologique a changé, l'ancien cache n'est utilisé qu'à des fins rétroactives |
| Nécessité de reproduire les résultats de manière stable | Enregistrez votre propre version de stratégie et les informations sur les tâches réelles | Le même nom de modèle ne signifie pas que le comportement du serveur ne changera jamais. |
| Accédez au cache existant | Vérifier le statut, les tâches sources et les labels de qualité | Appuyer sur la touche ne signifie pas que le résultat peut être livré directement |
La clé de cache doit représenter une décision de traduction
Au moins les conditions suivantes doivent être prises en compte :
- Langue source et Langue cible
- Version à terme
- Version du modèle ou de la stratégie de traduction
- Champ d'utilisation
Lorsque le contexte affecte la traduction, l'identifiant du contexte doit également être inclus dans la clé de cache.
Avoir le même nom de modèle ne garantit pas que le serveur ne changera jamais. Si vous avez besoin d'obtenir des résultats reproductibles, vous devez enregistrer votre propre version de la stratégie avec les informations réelles sur la tâche, plutôt que de supposer qu'un seul nom de modèle verrouillera tous les comportements.
Vous trouverez ci-dessous un exemple synthétique de clé de cache locale. Il n'appelle aucune interface de traduction et ne spécifie pas non plus l'implémentation du cache interne de OmniDoc (portail produit).
Les exemples utilisent des échantillons synthétiques pour démontrer les méthodes de traitement, et le code a été vérifié dans un environnement isolé, mais cela ne représente pas une garantie de tous les fichiers réels ou effets du produit. Avant de traiter des documents importants, veuillez conserver les originaux et les examiner en fonction des limites et des éléments d'acceptation ci-dessous.
Utilisez la sérialisation structurée pour éviter les ambiguïtés de raccordement
import hashlib
import json
def cache_key(tenant, text, source_lang, target_lang, glossary, policy):
record = {"tenant": tenant, "text": text, "source": source_lang,
"target": target_lang, "glossary": glossary, "policy": policy}
raw = json.dumps(record, ensure_ascii=False, sort_keys=True,
separators=(",", ":")).encode("utf-8")
return hashlib.sha256(raw).hexdigest()
args = ("demo-a", "保存", "zh", "en", "terms-v1", "ui-v1")
first = cache_key(*args)
assert first == cache_key(*args)
assert first != cache_key("demo-b", *args[1:])
assert first != cache_key("demo-a", "保存", "zh", "ja", "terms-v1", "ui-v1")
assert first != cache_key("demo-a", "保存", "zh", "en", "terms-v2", "ui-v1")
assert len(first) == 64Lorsque vous utilisez simplement text + language + version pour effectuer un épissage, les limites du champ ne sont pas claires et l'ambiguïté est facile à survenir. La sérialisation structurée clarifie les noms de champs et les limites des valeurs ; après avoir corrigé l'ordre des clés et le délimiteur, le même enregistrement obtiendra des octets stables.
Cet ensemble de protocoles est fixe. Lorsque les règles de sérialisation sont modifiées ultérieurement, l'espace de noms du cache doit être mis à niveau simultanément.
Vérifiez toujours l'état disponible après avoir cliqué
Les entrées du cache peuvent provenir de tâches ayant échoué, annulées ou non révisées, et appuyer sur la touche ne signifie pas que les résultats peuvent être fournis directement.
Chaque entrée du cache doit également enregistrer les informations suivantes :
- Statut
- Temps de création
- Tâches sources
- Label de qualité en cas de besoin
Une fois la terminologie révisée, l'ancien cache peut être conservé à des fins rétroactives, mais ne doit pas continuer à être utilisé comme résultat actuel par la nouvelle politique.
| changement | Cet exemple génère-t-il des clés différentes ? | raison |
|---|---|---|
| Différents locataires | Oui | Évitez la confusion dans la portée de la réutilisation |
| Différentes langues cibles | Oui | La cible de traduction a changé |
| Les versions terminologiques sont différentes | Oui | Les décisions terminologiques ont changé |
| Les entrées et les stratégies sont les mêmes | Non | Autoriser l'interrogation des résultats existants |
Le hachage n'équivaut pas au cryptage ou au contrôle d'accès
Ce n’est pas parce que la clé de cache est SHA-256 que le texte a été désensibilisé. Les expressions courantes peuvent être énumérées et le contenu mis en cache nécessite toujours des autorisations d'accès et des politiques de conservation.
La clé d’entrée de l’ID de locataire peut uniquement être utilisée pour isoler la dénomination et ne peut pas remplacer la vérification des autorisations lors de la requête.
La suppression uniforme des espaces, de la ponctuation ou des chiffres afin d'améliorer le taux de réussite peut fusionner des textes qui ne sont pas identiques. Les règles de normalisation doivent être clairement définies et testées avec des contre-exemples qui modifient la sémantique, et pas seulement le nombre d'appels enregistrés.
Pour une implémentation associée, veuillez vous référer à Python hashlib.
Laisser la réutilisation servir la livraison
Si OmniDoc est utilisé comme portail de traduction de documents, l'orchestration des tâches externe peut également conserver les versions d'entrée et les enregistrements d'acceptation.
La réutilisation ou non des résultats existants doit être déterminée par votre accord de tâche. Cet article ne déduit pas si la plateforme utilise la même stratégie de mise en cache, ni ne garantit que les soumissions répétées n'entraîneront pas de nouvelles tâches ou de nouveaux frais.
📊 Comparaison de base
| pratique | Principaux risques ou avantages | suggestion |
|---|---|---|
Épissage simple text + language + version | Les limites des champs sont floues et sujettes à l'ambiguïté | Utilisez plutôt la sérialisation structurée |
| Sérialisation structurée | Les limites entre les noms de champs et les valeurs sont claires et la sortie est stable après avoir corrigé l'ordre des clés et le délimiteur. | Mettre à niveau de manière synchrone l'espace de noms du cache lors de la modification des règles |
| Utiliser uniquement les hachages du texte source comme clés | Peut être réutilisé par erreur entre les projets et les locataires | Intégrer le langage, la terminologie, les stratégies et l'utilisation |
| Supprimez uniformément les espaces, la ponctuation ou les chiffres pour améliorer le taux de réussite | Possibilité de fusionner des textes sémantiquement différents | Définir explicitement les règles et les tester avec des contre-exemples |
🎯 Quelle méthode vous convient ?
si tu……
- Nécessité de réutiliser les traductions sur plusieurs projets : inclure la portée d'utilisation dans la clé de cache.
- Pour plusieurs locataires : insérez l'ID du locataire dans la clé et effectuez une vérification des autorisations lors de la requête.
- Vous souhaitez pouvoir retracer ou reproduire les résultats ultérieurement : enregistrez la version de la stratégie et les informations réelles sur la tâche.
- Si vous souhaitez améliorer le taux de réussite : définissez d'abord les règles de normalisation et testez-les avec des contre-exemples qui changeront la sémantique.
- Accédez au cache existant : vérifiez d'abord l'état, l'heure de création et la tâche source.
❓ Questions fréquemment posées (FAQ)
1. Est-il acceptable d'utiliser uniquement le hachage du texte source pour les clés de cache ?
pas assez. La même phrase peut avoir des traductions, des majuscules ou un contexte différents dans différents projets. Utiliser uniquement le hachage peut réutiliser par erreur la traduction dans d'autres projets, ou même la mélanger entre les locataires.
2. Si la clé de cache utilise SHA-256, le contenu du cache peut-il être rendu public ?
Ne peut pas. Le hachage n'équivaut pas au cryptage ou à la désensibilisation, des expressions courantes peuvent être énumérées et le contenu mis en cache nécessite toujours des autorisations d'accès et des politiques de conservation.
3. Si les noms de modèles sont les mêmes, les résultats seront-ils les mêmes ?
Non garanti. Ce n’est pas parce que les noms de modèles sont les mêmes que le serveur ne changera jamais. Lorsqu'une reproduction stable est requise, la version de la politique et les informations sur la tâche réelle doivent être enregistrées.
4. Une fois la terminologie révisée, l'ancien cache doit-il être supprimé immédiatement ?
incertain. L'ancien cache peut être conservé à des fins rétroactives, mais ne doit pas continuer à être utilisé comme résultats actuels par les nouvelles politiques.
📝Résumé
Le taux de réussite du cache de traduction est important, mais il est d'abord nécessaire de définir quelles conditions sont identiques avant d'autoriser la réutilisation. L'intégration du langage, de la terminologie, de la politique, de la portée d'utilisation et du contexte dans les clés de cache, associée aux contrôles d'autorisation et de statut, peut rendre la réutilisation efficace et fiable.
