스크랩된 번역과 LLM 컨센서스, 블라인드 벤치마크

저희 도메인 용어집의 비원어 용어 출처는 두 가지였습니다. 도메인 소유자가 직접 게시하는 공식 다국어 페이지를 스크랩하거나, 두 모델 LLM 합의 파이프라인으로 번역을 생성하는 것이었습니다. 직관적으로는 공식 페이지가 정답일 것이라고 생각했습니다. 측정 결과, 그 직관은 틀렸습니다. 모든 불일치 사례에 대한 블라인드 평가에서 LLM 출력이 9대 1의 비율로 우세했습니다. 이 게시물에서는 실험 설계, 실제 수치, 스크랩된 '공식' 번역이 실패하는 이유, 그리고 라이브 서비스를 중단하지 않고 크롤러를 어떻게 중단했는지 살펴봅니다.

다국어 용어집을 소싱하는 두 가지 방법

도메인 용어집은 소스 언어 개념(절차명, 제품, 증상)을 각 타겟 언어의 표시 형식에 매핑합니다. 재현율이 중요합니다. 용어가 누락되면 다운스트림 번역가는 일반적인 표현으로 대체하게 되고 도메인 특유의 어조를 잃게 됩니다.

첫 번째 파이프라인은 쌍을 이룬 페이지를 크롤링했습니다. 각 사이트에 대해 소스 언어 URL과 각 번역된 URL을 등록하고, 동일한 예산으로 양쪽을 크롤링했으며, 임베딩 유사도를 사용하여 블록을 정렬하고, 신뢰도 높은 앵커 쌍을 용어집으로 바로 승격시켰습니다. 이 방법은 사이트 소유자가 자신의 번역을 검토했을 것이기 때문에 이론상으로는 매력적입니다.

두 번째 파이프라인은 번역된 페이지를 전혀 보지 않습니다. 소스 언어 용어를 가져와, 두 개의 다른 LLM 제공업체에 독립적으로 번역하도록 요청하고(어느 쪽도 다른 쪽의 결과물을 보지 않음), 정규화 후 두 답변이 일치하거나 작은 임베딩 거리 내에 있을 때만 결과를 수용합니다. 여기서 살아남은 것들은 역번역 게이트를 통과합니다. 즉, 일반 NMT 서비스를 사용하여 후보 번역을 소스 언어로 다시 번역하고, 정규화된 정확한 일치 또는 언어별 임계값 미만의 코사인 거리를 요구하며, 회색 지대는 제3의 판단으로 해결합니다.

실험: 블라인드 심사와 동일한 조건

파이프라인을 정직하게 비교한다는 것은 소스를 제외한 모든 변수를 제거하는 것을 의미합니다. 크롤링이 실제로 작동한 세 가지 언어에 걸쳐 크롤러가 기본 표시 형식으로 승격시킨 136개의 용어집 항목을 샘플링했습니다(각각 60개, 50개, 26개 항목). 각 항목에 대해 합의 파이프라인을 사용하여 동일한 조건, 즉 프로덕션에서 사용하는 것과 동일한 두 개의 생성기 모델, 정확한 프로덕션 프롬프트, 동일한 배치 크기 상한으로 번역을 다시 생성했습니다. 따라서 비교는 설정이 아닌 소스를 측정했습니다.

그런 다음 두 가지를 평가했습니다.

첫째, 일치율입니다. 즉, 정규화(대소문자 통일, 전각/반각 정규화, 공백 및 구두점 정리, 스크립트 수준 통합) 후 두 모델 합의가 자체적으로 스크랩된 형식을 얼마나 자주 정확하게 재현했는지입니다.

둘째, 합의가 스크랩된 형식과 다른 것을 생성한 모든 경우에 대해 블라인드 심사를 실행했습니다. 각 충돌은 소스는 숨겨지고 순서는 결정론적으로 섞인 A/B 쌍이 되었으므로, 심사자는 "A가 크롤러를 의미한다"는 것을 알 수 없었습니다. 생성에 참여하지 않은 두 개의 더 강력한 모델이 용어집 적합성을 목표로 하는 평가 기준, 즉 '이것이 전문가가 마케팅 노이즈 없이 실제로 사용할 용어인가?'라는 기준을 사용하여 독립적으로 심사했습니다. 두 심사자가 모두 동의한 경우에만 승자로 집계했습니다.

수치가 말해주는 것

가장 놀라웠던 순서대로 정리한 주요 결과는 다음과 같습니다.

4분의 3의 경우, 공식 페이지에 접근하지 않은 두 개의 독립적인 모델이 사이트 소유자가 게시한 문자열과 정확히 일치하는 결과로 수렴했습니다. 이 사실만으로도 합의 메커니즘이 "공식" 용어를 한 번도 보지 않고도 복원한다는 것을 알 수 있습니다.

불일치가 발생한 부분에서 이야기는 반전됩니다. 19개의 충돌 중, 블라인드 심사단이 만장일치로 크롤링된 형식을 선호한 경우는 단 한 번뿐이었습니다. 아홉 번은 LLM 형식을 선호했고, 나머지 아홉 번은 의견이 갈리거나 동등하게 수용 가능하다고 판단되었습니다. 스크랩된 쪽은 단순히 비긴 것이 아니라, 경쟁하던 영역에서 패배했습니다.

적용 범위가 결정을 확정지었습니다. 크롤 파이프라인은 사이트가 실제로 번역된 페이지를 게시한 경우에만 작동하는데, 저희 도메인에서는 이것이 실제 사용량이 있는 3개 언어와 거의 아무것도 없는 8개 언어를 의미했습니다. 합의 파이프라인은 목록에 있는 모든 언어에 대해 생성합니다. 측정 시점에서 이 파이프라인은 수년간의 크롤링이 축적한 것보다 16.6배 더 많은 승인된 기본 항목을 생성했습니다.

공식 페이지가 지는 이유: 구조적인 노이즈

19개의 충돌을 하나씩 읽어보니 패인을 알 수 있었습니다. 크롤링된 형식은 잘못된 번역이 아니었습니다. 많은 경우 아예 번역이 아니었습니다.

• 용어로 캡처된 언어 코드: "body shape"의 용어집 항목은 언어 전환기에서 스크랩된 리터럴 문자열 "en"을 표시 형식으로 가지고 있었습니다.
• 메뉴 연결: 인접한 두 개의 탐색 항목이 하나의 문자열로 융합되어, 존재하지는 않지만 그럴듯해 보이는 복합 용어를 생성했습니다.
• 프로모션 산술: 가격표가 제목 옆에 위치하기 때문에 "300샷" 스타일의 수량 접두사가 시술명에 붙었습니다.
• 용어가 아닌 마케팅 문구에 속하는 괄호 안의 여담 및 성분 접미사.

중요한 점은 이것이 정리 작업 후에도 살아남았다는 것입니다. 우리는 이미 몇 달 전에 크롤링된 데이터에 대해 전용 노이즈 제거 패스를 실행하여 수백 개의 오염된 행을 제거했습니다. 위의 예는 그 노력 후에 남은 것들입니다. 크롤링 노이즈는 구조적입니다. 페이지 레이아웃이 계속해서 노이즈를 생성하는 반면, 생성 파이프라인은 애초에 탐색 모음을 내보내지 않기 때문입니다.

솔직한 주의 사항이 하나 있습니다. 크롤링이 이긴 유일한 경우는 브랜드 기기의 현지 선호 음역이었는데, 이는 마케팅 팀이 결정하고 모델은 추론할 수 없는 종류의 것입니다. 용어집이 공식 현지 표기가 있는 브랜드 음역으로 가득하다면, 바로 그 항목들을 위해 수동 재정의 계층을 유지하십시오. 우리에게는 그런 계층이 있으며, 마이그레이션 시에도 이를 보존했습니다.

크롤러를 대체한 합의 게이트

대체 파이프라인은 설명하고 실행하는 데 비용이 적게 듭니다.

term -> generator A (model 1)   -> agree after normalization? -> accept
     -> generator B (model 2)   -> else: embedding distance <= 0.20? -> accept
accepted -> back-translate -> exact match OR cosine <= threshold(lang)
         -> gray zone (<= 0.50) -> single judge yes/no -> insert or drop

실제로 중요했던 설계상의 선택:

• 두 생성기는 독립적으로 실행되며 서로의 출력을 보지 않습니다. 복사를 통한 합의는 합의가 아닙니다.
• 비교 전 정규화는 의미 없는 차이를 흡수합니다: 전각/반각, 대/소문자, 공백, 스크립트 수준의 등가성. 이것이 없으면 일치율이 떨어지고 잘못된 불일치에 대한 비용을 치르게 됩니다.
• 역번역 게이트는 확신에 찬 헛소리를 잡아냅니다. 두 모델이 유창하지만 잘못된 렌더링에 동의할 수 있습니다. 일반 NMT 서비스를 통한 왕복(round trip)은 잘못된 렌더링이 소스 용어로 다시 돌아오지 않기 때문에 이를 노출시킵니다.
• 드롭(drop)은 시도 횟수 카운터와 함께 기록됩니다. 세 번 실패한 슬롯은 모집단에서 제외되므로, 야간 배치가 영원히 동일한 어려운 사례를 재논의하며 예산을 소모하지 않습니다. 나중에 생성기 모델을 업그레이드했을 때, 마지막 실패가 불일치 또는 역번역 실패였던 슬롯만 선택적으로 재설정하고, "두 모델 모두 노이즈로 판단" 및 "중복" 드롭은 닫힌 상태로 두었습니다. 업그레이드된 모델은 첫 번째 패스에서 해당 재설정을 통해 297개의 추가 항목을 복구했습니다.

라이브 서비스 하에서 스크레이퍼 폐기하기

측정 결과에 따라 결정을 내렸지만, 마이그레이션은 용어집을 실시간으로 읽는 서비스가 중단되지 않도록 해야 했습니다. 결과적으로 개별 단계보다 작업 순서가 더 중요했습니다.

1. 먼저 야간 스케줄에서 크롤러를 제거하는 코드를 배포하고 출시합니다. 기존 크롤러가 아직 스케줄된 상태에서 데이터를 삭제하면, 다음 실행 시 방금 제거한 모든 것을 다시 스크레이핑하고 다시 승격시킵니다.
2. 재생성하기 전에 배치 워커의 model-name 환경 변수가 새 생성기를 가리키도록 설정합니다. 그렇지 않으면 야간 작업이 누락된 슬롯을 기존 모델로 소리 없이 다시 채울 것입니다. 여기서 경계해야 할 실패 모드는 기본 모델로 소리 없이 대체되는 것이므로, 첫 번째 소규모 배치 후 감사 로그에 기록된 모델 태그를 확인했습니다.
3. 삭제하려는 모든 행에 대해 외래 키 연쇄(foreign-key cascade)에 의해 함께 삭제될 행을 포함하여 데이터베이스 수준의 백업을 수행합니다. 기본 테이블의 CSV 파일은 롤백 계획이 될 수 없습니다.
4. 잠금 시간 초과(lock timeout)를 설정하여 배치 단위로 삭제한 다음, 재생성하고 회귀 벤치마크를 다시 실행합니다. 우리의 경우 마이그레이션 이전 값(0.88의 페어 적중률)을 정확히 유지했으며, 이 수치를 보고 마이그레이션이 완료되었다고 판단할 수 있었습니다.

FAQ

두 모델 대신 강력한 모델 하나만 사용하지 않는 이유는 무엇인가요? 단일 모델에는 "추측 중"이라는 내부 신호가 없습니다. 두 개의 독립적인 모델은 추측이 발생하는 항목에서 정확히 불일치하며, 그 불일치가 필터 역할을 합니다. 저희 데이터에서는 불일치 항목을 제외하고 나머지를 통과시키는 방식으로 오염을 거의 0으로 줄였으며, 그 비용으로 패스당 약 40%의 후보를 건너뛰었습니다. 이들 대부분은 나중에 다시 시도하면 성공했습니다.

이 방법은 용어집 외에도 일반화될 수 있나요? 이 패턴(독립적인 이중 생성, 정규화된 일치, 왕복 검증, 제한된 재시도)은 엔티티 이름, 코드 식별자, 카테고리 라벨과 같이 출력이 짧고 확인 가능한 문자열인 모든 작업에 적합합니다. 정규화 후 일치 여부가 의미를 잃기 때문에 출력이 긴 자유 텍스트인 경우에는 잘 맞지 않습니다.

스크레이핑은 여전히 가치가 있나요? 네, 소스 언어 측면에서는 그렇습니다. 공식 페이지는 특정 도메인에 어떤 개념이 존재하는지에 대한 좋은 소스로 남아 있으며, 저희 대체 시스템도 새로운 용어를 발견하기 위해 소스 언어 페이지를 계속 크롤링합니다. 저희가 중단한 것은 해당 페이지의 번역된 쪽을 정답으로 신뢰하는 것입니다.

사이트에서 전혀 게시하지 않은 언어는 어떻게 되나요? 그것이 결정적인 논거였습니다. 스크레이퍼는 사이트가 게시하지 않은 것을 생성할 수 없습니다. 저희의 11개 대상 언어 중 8개는 크롤링 가능한 커버리지가 거의 0에 가까웠습니다. 따라서 선택은 "스크레이핑된 품질 대 생성된 품질"이 아니라 "생성된 커버리지 대 전무함"이었습니다.