반복되는 문단은 번역을 재사용할 수 있지만 캐시 키는 원본 텍스트만 가질 수는 없습니다.

번역 캐싱의 핵심은 재사용을 허용하기 위해 동일한 조건을 정의하는 것입니다. 동일한 문장 "저장"은 프로젝트마다 번역, 대문자 사용 및 맥락이 다를 수 있습니다. 소스 텍스트 해시만 캐시 키로 사용되는 경우 한 프로젝트의 번역이 다른 프로젝트에서 잘못 사용되거나 테넌트 간에 혼합될 수도 있습니다.

이 글은 번역 캐시를 디자인해야 하는 개발자와 문서화 팀을 위해 작성되었습니다. 이 글을 읽고 나면 캐시 키에 포함되어야 하는 조건, 구조화된 직렬화를 사용하여 모호함을 피하는 방법, 캐시 적중 후 확인해야 할 사항을 알게 될 것입니다.

번역 캐시 키는 어떻게 디자인하나요? 한 문장 결론

캐시 키는 번역 결정을 나타내야 하며, 기존 결과의 재사용은 출발어, 도착어, 용어 버전, 정책 버전, 사용 범위가 동일한 경우에만 허용됩니다.

캐시 키는 번역 결정을 나타내야 합니다.

최소한 다음 조건을 고려해야 합니다.

• 원본 언어 및 대상 언어
• 기간 버전
• 모델 또는 번역 전략 버전
• 사용 범위

컨텍스트가 번역에 영향을 미치는 경우 컨텍스트 식별자도 캐시 키에 포함되어야 합니다.

모델명이 동일하다고 해서 서버가 절대 변경되지 않는다는 보장은 없습니다. 재현 가능하게 재현 가능한 결과가 필요한 경우 하나의 모델 이름이 모든 동작에 고정된다고 가정하기보다는 실제 작업 정보와 함께 자신만의 전략 버전을 저장해야 합니다.

다음은 로컬 캐시 키의 합성 예입니다. 변환 인터페이스를 호출하지 않으며 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. 용어 수정 후 기존 캐시는 즉시 삭제해야 하나요?

불확실한. 이전 캐시는 소급 목적으로 보관할 수 있지만 새 정책에 따라 현재 결과로 계속 사용되어서는 안 됩니다.

📝 요약

번역 캐시의 적중률도 중요하지만 재사용을 허용하기 전에 먼저 어떤 조건이 동일한지 정의해야 합니다. 권한 확인 및 상태 확인과 함께 언어, 용어, 정책, 사용 범위 및 컨텍스트를 캐시 키에 통합하면 효율적이고 안정적으로 재사용할 수 있습니다.

지금 사용해 보세요: 원본 레이아웃을 유지하면서 번역을 시작하려면 문서를 업로드하세요.