제품 콘텐츠 품질 확인
Updated 2026-09-05
구조적 유효성과 제품 의미를 분리하세요. 로컬 일본어 및 독일어 40행 사례에서는 필드 확인이 통과했지만 AI 검토에서 여전히 수정할 일본어 표현이 발견되었습니다.
생성 전에 품질 계약을 정의하세요
각 필드의 승인 규칙을 작성하세요. 식별자와 리비전 필드는 소스와 일치해야 합니다. 편집 가능한 텍스트는 요청된 로케일을 사용하고 필수 정보를 포함하며 대상 형식을 따라야 합니다. 주장에는 뒷받침하는 근거가 필요합니다. 한 번의 통과 또는 실패 라벨만으로는 어떤 조건이 제품을 막았는지 설명하기 어렵습니다.
기계가 확인할 수 있는 결함과 편집 판단을 분리하세요. 누락된 텍스트와 식별자 변동은 결정론적으로 좁힐 수 있습니다. 번역이 혜택을 과장하는지는 컨텍스트와 자격 있는 검토가 필요합니다. 각 이슈를 해결할 수 있는 사람이나 시스템으로 보내고 결과를 후보 리비전에 연결해 유지하세요.
| 확인 | 유용한 근거 | 후속 검토 |
|---|---|---|
| 식별자와 소스 리비전 | 정확한 필드 비교 | 자연스러운 번역 |
| 보호된 값 | 타입이 있는 스칼라 동등성 | 올바른 소스 사양 |
| 마크업과 플레이스홀더 | 파서와 토큰 수 | 정확한 제품 주장 |
| 주장 검토 | 주장과 소스 매핑 | 스토어 가져오기 성공 |
| 대상 다시 읽기 | 승인 값과 저장 값 비교 | 상업적 성과 |
조립 후 보호된 값을 비교하세요
허용된 텍스트 필드만 생성한 뒤 소스에서 복사한 보호된 값으로 후보 레코드를 조립하세요. 조립된 레코드에 대해 두 번째 비교를 실행합니다. 이는 매퍼의 실수와 검토 중 발생한 우발적인 수정까지 잡아냅니다.
예시 JavaScript는 스키마가 검증된 스칼라 보호 값을 가진 객체를 기대합니다. 누락, 추가, 변경된 보호 키와 오래된 소스 리비전을 감지하고 안정적인 이슈 코드를 반환합니다. 이 도우미보다 먼저 스키마와 값 검증을 실행하고 이후 구조적으로 유효한 후보를 편집 검토로 보내세요.
function checkProtected(source, candidate) {
const issues = [];
if (candidate.sourceRevision !== source.sourceRevision) {
issues.push({ code: "STALE_SOURCE", field: "sourceRevision" });
}
const keys = new Set([
...Object.keys(source.protected),
...Object.keys(candidate.protected),
]);
for (const field of keys) {
const hasSource = Object.prototype.hasOwnProperty.call(source.protected, field);
const hasCandidate = Object.prototype.hasOwnProperty.call(candidate.protected, field);
if (!hasSource || !hasCandidate ||
!Object.is(source.protected[field], candidate.protected[field])) {
issues.push({ code: "PROTECTED_FIELD_CHANGED", field });
}
}
return issues;
}숫자 형식과 값을 분리하세요
현지화된 숫자는 다르게 보이면서 같은 저장 수량을 나타낼 수 있습니다. MDN은 로케일에 맞는 표현을 위해 Intl.NumberFormat을 문서화합니다. 권위 있는 값을 선택한 후 형식을 적용하고 언어 모델에 렌더링된 통화 문자열에서 가격을 다시 만들도록 요청하지 마세요.
숫자 값과 함께 단위를 정의하고 각 치수에 어떤 단위가 속하는지 포함하세요. 변환이 승인된 경우 결정론적 변환 규칙을 사용하고 원래 표현을 보존합니다. 문장 속 숫자만 비교하지 마세요. 단위가 다른 동일한 숫자는 서로 다른 제품을 설명할 수 있습니다. 소스가 해결될 때까지 단위 누락은 승인을 막아야 합니다.
플레이스홀더 개수와 마크업을 검증하세요
애플리케이션의 템플릿 파서를 사용해 소스와 후보의 플레이스홀더 토큰을 수집하세요. 이름 집합만이 아니라 개수도 비교합니다. 모든 원래 토큰이 여전히 나타나더라도 토큰이 중복되면 문장이나 애플리케이션이 깨질 수 있습니다. 형식별 이스케이프 규칙은 대상 경계에서 유지하세요.
다음의 작은 확인은 이미 추출된 토큰을 받습니다. 보편적인 플레이스홀더 정규 표현식을 시도하지 않습니다. HTML은 문서 조각으로 파싱하고 허용된 구조와 링크를 별도로 비교하세요. 사용자 지정 렌더링에는 WordPress의 이스케이프 안내가 관련되지만 이스케이프만으로 콘텐츠가 의도한 의미를 보존했다는 사실을 입증할 수는 없습니다.
function samePlaceholderCounts(sourceTokens, candidateTokens) {
const counts = new Map();
for (const token of sourceTokens) {
counts.set(token, (counts.get(token) ?? 0) + 1);
}
for (const token of candidateTokens) {
if (!counts.has(token)) return false;
counts.set(token, counts.get(token) - 1);
}
return [...counts.values()].every((count) => count === 0);
}사례: 필드는 유효하지만 표현은 여전히 수정 필요
gpt-5.6-luna와 xhigh 추론을 사용하도록 명시적으로 구성한 번역 에이전트가 가상 제품 20개에서 일본어 패치 20개와 독일어 패치 20개를 만들었습니다. 결정론적 스키마, 식별자, 보호 필드 확인은 조립된 40개 행 전체에서 통과했습니다. 가격, 통화, 소재, 치수는 소스에서 복사되었고 생성 패치는 식별된 SKU와 로케일의 title과 description만 바꿀 수 있었습니다.
손대지 않은 일본어 패치도 구조 검증을 통과했습니다. 그럼에도 AI 검토는 아래 두 표현 문제를 발견하고 설명을 수정했습니다. 보호된 소재 필드를 확인하는 것만으로는 문장이 소재를 정확히 설명한다는 사실을 입증할 수 없는 이유입니다. 모든 스키마 확인이 통과한 뒤에도 중요한 각 주장을 소스와 비교하세요.

| 가상 제품 | 소스 의미 | 일본어 AI 검토 수정 |
|---|---|---|
| DEMO-003: 스케치 패드 | 판지 받침 | 골판지를 암시하는 근거 없는 표현 제거 |
| DEMO-010: 수납 바구니 | 총 두 개의 측면 손잡이 | 모호함을 없애도록 전체 손잡이 수를 명확히 함 |
가져오기와 함께 검토 내보내기도 테스트하세요
OWASP는 스프레드시트 수식 인젝션을 설명하며 안전 변환이 소비자마다 다르다고 기록합니다. 공급업체 및 생성 셀을 신뢰할 수 없는 입력으로 취급하세요. 실제 스프레드시트 도구에 대해 검토된 직렬화 정책을 사용하고 메모리 안의 표만이 아니라 저장된 산출물을 검사하세요.
기계 가져오기는 검토 파일과 분리하세요. 사람이 안전하게 보기 위해 추가한 접두사가 가져오기 중 식별자나 공개 설명을 조용히 바꿔서는 안 됩니다. 파서로 인코딩, 따옴표 처리, 예상 행 식별자를 검증하세요. 스프레드시트 편집기가 도입한 변경을 식별하고 수정할 수 있도록 손대지 않은 소스를 보존합니다.
승인을 정확한 후보에 연결하세요
사실 승인 및 언어 승인과 함께 후보 리비전 또는 해시를 저장하세요. 이후 편집은 검토될 때까지 관련 승인을 무효화해야 합니다. 제품 사양이 바뀐 뒤에는 번역이 그대로여도 오래될 수 있으므로 최종 게시자는 현재 소스 리비전도 비교해야 합니다.
사례 산출물에서 수정된 일본어 패치와 독일어 패치는 review_status: unreviewed로 표시된 행으로 조립됩니다. 두 보고서 모두 translation_semantic_review: pending을 유지합니다. AI 지원 수정은 리비전 단계이지 원어민 또는 판매자의 최종 승인이 아닙니다. 원본과 수정 후보를 보존한 뒤 가져오기 패키지에 들어갈 정확한 텍스트를 적절한 검토자가 승인하게 하세요.
확인을 재현하고 범위를 명확히 유지하세요
로컬 사례의 테스트는 소스 필드 보존, 중복 SKU, 누락 SKU, 금지된 가격 덮어쓰기를 실행합니다. 저장된 일본어 및 독일어 패치를 읽기 전용으로 재조립하면 두 validated 출력을 재현합니다. 더 큰 카탈로그에는 자체 플레이스홀더 문법, 마크업, 리비전 정책 확인을 추가하세요. 위의 예시 도우미는 이 40개 행에 사용한 검증기가 아니라 별도의 예시입니다.
이는 Astra 또는 게이트웨이 호출과 실제 스토어 가져오기가 없는 Luna 구성 로컬 번역 사례였습니다. 도구에는 API 사용량, 요청 ID, 결제가 노출되지 않았고 두 출력 모두 사용량과 비용을 null로 유지합니다. 구조 결과를 사용해 의미 검토로 진행한 다음 승인된 스토어 어댑터를 별도로 테스트하세요.
node --test examples/commerce-localization-case/case.test.mjs자주 묻는 질문
JSON이 유효한 응답도 가져오기에 안전하지 않을 수 있나요?
예. 유효한 문법만으로 올바른 식별자, 최신 소스, 지원 필드, 정확한 주장, 승인이 확립되지는 않습니다. 이러한 계약을 독립적으로 검증하세요.
모델이 편집할 수 없는 보호 필드를 왜 비교하나요?
조립, 매핑, 검토 단계에서도 실수가 생길 수 있습니다. 조립 후 비교는 전달을 위해 준비하는 실제 레코드를 확인합니다.
허용된 단어 목록으로 주장을 검증할 수 있나요?
일부 문제를 표시할 수는 있지만 단어 목록만으로는 주장의 의미나 강도를 확립할 수 없습니다. 제품 근거와 문장을 대조해 검토하세요.
플레이스홀더 이름이 일치하면 충분한가요?
실제 템플릿 파서를 사용해 개수도 비교하세요. 이름 집합이 익숙해 보여도 토큰이 반복되거나 누락되면 결함일 수 있습니다.
40행 사례에서 무엇이 확인되었나요?
저장된 패치는 기록된 구조 실패 없이 조립되었고 소스로 제어되는 제품 필드를 보존했습니다. 일본어 표현에는 여전히 두 번의 AI 검토 수정이 필요했으며 두 언어 모두 의미 승인이 대기 중입니다.