Повторяющиеся абзацы могут повторно использовать перевод, но ключ кэша не может содержать только исходный текст.

— Хеширование не равно шифрованию, для кэшированного содержимого по-прежнему требуются разрешения на доступ и политики хранения, а идентификатор клиента не может заменить проверку разрешений во время запроса.

• Правила нормализации должны быть четко определены и проверены на контрпримерах, чтобы избежать объединения неидентичных текстов и повысить вероятность попадания.

Ключом к кэшированию перевода является определение условий, которые позволяют повторное использование. Одно и то же предложение «сохранить» может иметь разные переводы, заглавные буквы и контекст в разных проектах. Если в качестве ключей кэша используются только хэши исходного текста, переводы из одного проекта могут быть неправильно использованы для другого проекта или даже смешаны между арендаторами.

Эта статья написана для разработчиков и групп документации, которым необходимо проектировать кэши переводов. Прочитав это, вы узнаете, какие условия должен содержать ключ кэша, как использовать структурированную сериализацию, чтобы избежать двусмысленности сращивания, и что еще нужно проверить после попадания в кэш.

Как создать ключ кэша переводов? Вывод в одно предложение

Ключ кэша должен представлять собой решение о переводе, а повторное использование существующих результатов допускается только в том случае, если исходный язык, целевой язык, версия терминологии, версия политики и область использования совпадают.

Ключ кэша должен представлять собой решение о переводе

По крайней мере, следует учитывать следующие условия:

– Исходный язык и Целевой язык

• Сроковая версия
• Модель или версия стратегии перевода
• Область использования

Если контекст влияет на перевод, идентификатор контекста также должен быть включен в ключ кэша.

Наличие того же названия модели не гарантирует, что сервер никогда не изменится. Если вам необходимо получить воспроизводимые результаты, вам следует сохранить свою собственную версию стратегии с фактической информацией о задаче, а не предполагать, что одно имя модели будет фиксировать все поведение.

Ниже приведен синтетический пример ключа локального кэша. Он не вызывает какой-либо интерфейс трансляции и не определяет реализацию внутреннего кэша OmniDoc (портал продуктов).

В примерах используются синтетические образцы для демонстрации методов обработки, а код проверен в изолированной среде, но это не является гарантией всех реальных файлов или эффектов продукта. Перед обработкой важных документов сохраните оригиналы и проверьте их в соответствии с границами и пунктами приема, указанными ниже.

Используйте структурированную сериализацию, чтобы избежать неоднозначностей при склейке

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) == 64

При простом использовании text + language + version для сращивания границы поля неясны и легко возникает двусмысленность. Структурированная сериализация уточняет имена полей и границы значений; после исправления порядка ключей и разделителя та же запись получит стабильные байты.

Этот набор протоколов фиксирован. Если правила сериализации будут изменены в будущем, пространство имен кэша должно быть обновлено одновременно.

По-прежнему проверяем доступный статус после нажатия

Записи в кэше могут поступать из невыполненных, отмененных или непросмотренных задач, и нажатие клавиши не означает, что результаты могут быть доставлены напрямую.

Каждая запись кэша также должна записывать следующую информацию:

• Статус
• Время создания
• Исходные задачи
• Знак качества при необходимости

После пересмотра терминологии старый кэш можно сохранить для ретроактивных целей, но он не должен продолжать использоваться в качестве текущего результата в соответствии с новой политикой.

Хеширование не равнозначно шифрованию или контролю доступа

Тот факт, что ключом кэша является SHA-256, не означает, что текст был десенсибилизирован. Общие фразы могут быть перечислены, а для кэшированного содержимого по-прежнему требуются права доступа и политики хранения.

Ключ записи идентификатора клиента можно использовать только для изоляции именования и не может заменить проверку разрешений во время запроса.

Равномерное удаление пробелов, знаков препинания или цифр с целью повышения вероятности попадания может привести к объединению неидентичных текстов. Правила нормализации должны быть четко определены и проверены на контрпримерах, которые изменяют семантику, а не только количество сохраненных вызовов.

Соответствующую реализацию см. в Python hashlib.

Разрешить повторное использование доставки

Если OmniDoc используется в качестве портала перевода документов, внешняя оркестровка задач также может сохранять входные версии и записи о приемке.

Возможность повторного использования существующих результатов должна определяться вашим соглашением о задаче. В этой статье не делается вывод о том, использует ли платформа одну и ту же стратегию кэширования, а также не гарантируется, что повторные отправки не повлекут за собой новые задачи или сборы.

📊 Сравнение ядра

🎯 Какой метод подходит вам?

если ты……

• Необходимо повторно использовать переводы в нескольких проектах: включите область использования в ключ кэша.
• Для нескольких арендаторов: поместите идентификатор арендатора в ключ и выполните проверку разрешений во время запроса.
• Хотите иметь возможность отслеживать или воспроизводить результаты позже: сохраните версию политики и фактическую информацию о задаче.
• Если вы хотите повысить вероятность попадания: сначала определите правила нормализации и протестируйте их на контрпримерах, которые изменят семантику.
• Хит существующий кеш: сначала проверьте статус, время создания и исходную задачу.

❓ Часто задаваемые вопросы (FAQ)

1. Можно ли использовать только хеширование исходного текста для ключей кэша?

недостаточно. Одно и то же предложение может иметь разные переводы, использование заглавных букв или контекст в разных проектах. Использование только хеширования может привести к ошибочному повторному использованию перевода в других проектах или даже к смешиванию его между арендаторами.

2. Если ключ кэша использует SHA-256, можно ли сделать содержимое кэша общедоступным?

Не мочь. Хеширование не равно шифрованию или десенсибилизации, общие фразы могут быть перечислены, а кэшированный контент по-прежнему требует разрешений на доступ и политик хранения.

3. Если названия моделей одинаковые, будут ли результаты такими же?

Не гарантировано. Тот факт, что названия моделей одинаковы, не означает, что сервер никогда не изменится. Если требуется стабильное воспроизведение, следует сохранить версию политики и фактическую информацию о задаче.

4. После пересмотра терминологии следует ли сразу удалять старый кэш?

неопределенный. Старый кэш можно сохранить для ретроактивных целей, но он не должен использоваться в качестве текущих результатов новыми политиками.

📝 Резюме

Частота попаданий в кэш трансляции важна, но сначала необходимо определить, какие условия являются одинаковыми, прежде чем будет разрешено повторное использование. Включение языка, терминологии, политики, области использования и контекста в ключи кэша в сочетании с проверкой разрешений и проверкой статуса может сделать повторное использование эффективным и надежным.

Попробуйте сейчас: загрузите документ, чтобы начать перевод, сохранив исходный макет.