OmniDocАбзаци, що повторюються, можуть повторно використовувати переклад, але ключ кешу не може мати лише оригінальний текст.
«Зберегти» виглядає однаково в обох проектах, але переклад, регістр і контекст можуть відрізнятися. Використовуючи хеш оригінального тексту як унікальний ключ кешу, можна легко повторно використовувати переклади з одного проекту в інший або навіть змішувати їх між клієнтами. Кешування — це не лише частота відвідувань. Ви повинні спочатку визначити, які умови є однаковими, перш ніж дозволити повторне використання.
Ключ до кешування перекладу полягає у визначенні однакових умов для повторного використання. Одне й те саме речення «зберегти» може мати різний переклад, використання великих літер і контекст у різних проектах. Якщо як ключі кешу використовуються лише хеші вихідного тексту, переклади з одного проекту можуть бути неправильно використані для іншого проекту або навіть змішані між клієнтами.
Ця стаття написана для розробників і груп документації, яким потрібно розробити кеші перекладу. Прочитавши це, ви дізнаєтесь, які умови має містити ключ кешу, як використовувати структуровану серіалізацію, щоб уникнути неоднозначності з’єднання, і що ще перевіряти після попадання в кеш.
Як створити ключ кешу перекладу? Висновок одним реченням
Ключ кешу має представляти рішення щодо перекладу, а повторне використання наявних результатів дозволено, лише якщо мова оригіналу, цільова мова, версія термінології, версія політики та область використання однакові.
| ваша ситуація | Рекомендовані практики | причина |
|---|---|---|
| У різних проектах одне й те саме речення може перекладатися по-різному | Включіть область використання в ключ кешу | Уникайте повторного використання перекладів з одного проекту в інший |
| Кілька клієнтів спільно використовують один кеш | Ідентифікатор клієнта вводить ключ і виконує перевірку дозволів під час запиту | Ідентифікатор клієнта може лише ізолювати іменування та не може замінити перевірку дозволів |
| Глосарій переглянуто | Нові ключі генеруються, коли версії термінів відрізняються | Термінологічне рішення змінено, старий кеш використовується лише заднім числом |
| Потрібно стабільно відтворювати результати | Збережіть свою власну версію стратегії та актуальну інформацію про завдання | Та сама назва моделі не означає, що поведінка сервера ніколи не зміниться. |
| Натисніть на існуючий кеш | Перевірте статус, вихідні завдання та оцінки якості | Натискання клавіші не означає, що результат можна отримати безпосередньо |
Ключ кешу повинен представляти рішення про переклад
Слід враховувати принаймні такі умови:
- Вихідна мова та Цільова мова
- Версія термінів
- Модель або версія стратегії перекладу
- Сфера використання
Якщо контекст впливає на переклад, ідентифікатор контексту також слід включити в ключ кешу.
Наявність тієї самої назви моделі не гарантує, що сервер ніколи не зміниться. Якщо вам потрібні відтворювані відтворювані результати, вам слід зберегти власну версію стратегії з фактичною інформацією про завдання, а не припускати, що одна назва моделі зафіксує всю поведінку.
Нижче наведено синтетичний приклад ключа локального кешу. Він не викликає жодного інтерфейсу перекладу, а також не визначає реалізацію внутрішнього кешу 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 використовується як точка входу для перекладу документів, зовнішня оркестрація завдань також може зберігати вхідні версії та записи прийняття.
Чи використовувати існуючі результати повторно, слід вирішувати у вашій угоді про завдання. Ця стаття не стверджує, чи використовує платформа ту ж стратегію кешування, і не гарантує, що повторні подання не призведуть до нових завдань чи зборів.
📊 Порівняння ядра
| Метод | Ключові ризики або винагороди | Пропозиція |
|---|---|---|
Просте шиття text + language + version | Нечіткі межі полів легко призводять до неоднозначності | Перехід на структуровану серіалізацію |
| Структурована серіалізація | Назви полів і межі значень чіткі, а фіксований порядок ключів і вихід роздільника стабільні | При зміні правил одночасно оновлюється кеш-простір назв |
| Лише хеш вихідного тексту використовується як ключ | Зловживання може виникати між проєктами або орендарями | Включайте мову, термінологію, стратегію та сферу використання |
| Рівномірно видаляйте пробіли, пунктуацію або цифри для покращення показників перегляду | Тексти з різним значенням можуть об'єднуватися | Визначте правила явно і перевірте їх на контрприкладах |
🎯 Який метод тобі підходить?
Якщо ти ......
- Необхідність повторного використання перекладів у кількох проєктах: включити обсяг використання у кеш-ключі.
- Для кількох орендарів: введіть ідентифікатор орендаря у ключ і виконуйте перевірку дозволу під час запитів.
- Сподіватися відстежити або відтворити результати пізніше: зберегти версію політики та фактичну інформацію про завдання.
- Щоб покращити швидкість досягнення: спочатку визначайте правила нормалізації та використовуйте контрприклади, що змінюють семантику.
- Перевірте існуючий кеш: спочатку перевірте статус, час створення та джерело завдання.
❓ Поширені запитання (FAQ)
1. Чи нормально використовувати лише хеш вихідного тексту для кеш-ключів?
Недостатньо. Одне й те саме речення може перекладатися по-різному — у відмінку та відмінку, або в контексті між різними проєктами; використання лише хешу може призвести до неправильного застосування перекладу в інших проєктах або навіть до змішування між орендарями.
2. Якщо кеш-ключ використовує SHA-256, чи може кешований вміст бути публічним?
Ні, не можна. Хешування не означає шифрування чи десенсибілізацію; можуть бути перелічені поширені короткі фрази, а кешований контент все одно потребує дозволів доступу та політик утримання.
3. Чи означає наявність однакової назви моделі, що результат завжди однаковий?
Гарантій немає. Однакова назва моделі не означає, що сервер залишається незмінним. Коли потрібне стабільне відтворення, слід зберігати версію політики та фактичну інформацію про завдання.
4. Після оновлення термінології, чи слід негайно видалити старий кеш?
Не обов'язково. Старі кеші можна зберігати для ретроспективних цілей, але не повинні розглядатися як поточні результати за новими стратегіями.
📝 Резюме
Коефіцієнт досягнення кешу перекладу важливий, але спочатку потрібно визначити, які умови однакові, перш ніж дозволити повторне використання. Інтегруючи мову, термінологію, політики, обсяг і контекст у кеш-ключі, а також перевірки дозволів і стану, повторне використання може бути як ефективнім, так і надійним.
Досвід зараз: завантажте документ, щоб почати переклад, зберігаючи оригінальне форматування
