繰り返される段落では翻訳を再利用できますが、キャッシュ キーには元のテキストのみを含めることはできません。

変換キャッシュの鍵は、再利用を許可するためにどの条件が同じかを定義することです。同じ文「保存」でも、プロジェクトごとに翻訳、大文字小文字の区別、文脈が異なる場合があります。ソース テキスト ハッシュのみをキャッシュ キーとして使用すると、あるプロジェクトの翻訳が別のプロジェクトで悪用されたり、テナント間で混合されたりする可能性があります。

この記事は、翻訳キャッシュを設計する必要がある開発者およびドキュメント チームを対象に書かれています。これを読むと、キャッシュ キーにどのような条件を含めるべきか、構造化シリアル化を使用してスプライシングの曖昧さを回避する方法、およびキャッシュ ヒット後に他に何を確認する必要があるかがわかります。

変換キャッシュキーを設計するにはどうすればよいですか?一文の結論

キャッシュ キーは翻訳の決定を表す必要があり、既存の結果の再利用は、ソース言語、ターゲット言語、用語のバージョン、ポリシーのバージョン、および使用範囲が同じである場合にのみ許可されます。

キャッシュ キーは変換の決定を表す必要があります

少なくとも次の条件を考慮する必要があります。

• ソース言語とターゲット言語
• 期間版
• モデルまたは翻訳戦略のバージョン
• 使用範囲

コンテキストが変換に影響を与える場合、コンテキスト識別子もキャッシュ キーに含める必要があります。

同じモデル名であっても、サーバーが変更されないという保証はありません。再現可能な結果が必要な場合は、1 つのモデル名ですべての動作がロックされると想定するのではなく、実際のタスク情報を含む独自のバージョンの戦略を保存する必要があります。

以下は、ローカル キャッシュ キーの合成例です。変換インターフェイスを呼び出すことも、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 であるからといって、テキストの機密性が解除されているわけではありません。一般的なフレーズが列挙される可能性があり、キャッシュされたコンテンツには引き続きアクセス許可と保持ポリシーが必要です。

テナント ID エントリ キーは、名前付けを分離するためにのみ使用でき、クエリ中の権限チェックを置き換えることはできません。

ヒット率を向上させるためにスペース、句読点、数字を一律に削除すると、同一ではないテキストがマージされる可能性があります。正規化ルールは明確に定義し、保存される呼び出しの数だけでなく、セマンティクスを変更する反例でテストする必要があります。

関連する実装については、Python hashlibを参照してください。

配信サービスを再利用しましょう

OmniDoc が文書翻訳ポータルとして使用されている場合、外部タスク オーケストレーションは入力バージョンと受諾記録も保持できます。

既存の結果を再利用するかどうかは、タスク契約によって決定する必要があります。この記事は、プラットフォームが同じキャッシュ戦略を使用しているかどうかを推測するものではなく、繰り返しの送信によって新しいタスクや料金が発生しないことを保証するものでもありません。

📊 コアの比較

🎯 どの方法があなたに適していますか?

もしあなたが……

• 複数のプロジェクト間で翻訳を再利用する必要がある: キャッシュ キーに使用範囲を含めます。
• 複数のテナントの場合: テナント ID をキーに入力し、クエリ中に権限チェックを実行します。
• 後で結果を追跡または再現できるようにしたい: ポリシーのバージョンと実際のタスクの情報を保存します。
• ヒット率を向上させたい場合: まず正規化ルールを定義し、セマンティクスを変更する反例でルールをテストします。
• 既存のキャッシュをヒットします。まずステータス、作成時間、ソース タスクを確認します。

❓ よくある質問 (FAQ)

1. キャッシュ キーにはソース テキストのハッシュのみを使用しても問題ありませんか?

足りない。同じ文でも、プロジェクトごとに翻訳、大文字の使用、文脈が異なる場合があります。ハッシュのみを使用すると、誤って他のプロジェクトで翻訳を再利用したり、テナント間で翻訳を混合したりする可能性があります。

2. キャッシュキーに SHA-256 を使用している場合、キャッシュの内容を公開できますか?

できません。ハッシュ化は暗号化や非感作化と同等ではなく、一般的なフレーズが列挙される可能性があり、キャッシュされたコンテンツには引き続きアクセス許可と保持ポリシーが必要です。

3. モデル名が同じであれば、結果は同じになりますか?

保証されていません。モデル名が同じだからといって、サーバーが変わらないというわけではありません。安定した再現が必要な場合は、ポリシーバージョンと実際のタスク情報を保存する必要があります。

4. 用語が改訂されたら、古いキャッシュをすぐに削除する必要がありますか?

不確かな。古いキャッシュは遡及目的で保持できますが、新しいポリシーで現在の結果として使用し続けるべきではありません。

📝 概要

変換キャッシュのヒット率は重要ですが、再利用を許可する前に、まずどの条件が同じであるかを定義する必要があります。言語、用語、ポリシー、使用範囲、およびコンテキストをキャッシュ キーに組み込み、権限チェックやステータス検証と組み合わせることで、再利用を効率的かつ信頼性の高いものにすることができます。

今すぐ試してみましょう: ドキュメントをアップロードして、元のレイアウトを保持したまま翻訳を開始します