단일언어 데이터로 저자원 번역을 살리는 역번역

무엇인가

LLM은 제로샷·퓨샷 설정에서 여러 과제를 잘 처리하지만, 저자원 언어 기계번역은 사정이 다르다. 현실적인 선택지는 퓨샷 프롬프팅이나 소량 병렬셋에 대한 파인튜닝 정도다. 이 논문은 여기서 한 걸음 더 나아가, 저자원 언어의 단일언어 데이터가 어느 정도 확보된 상황을 가정한다. 그리고 묻는다. 그 데이터를 어떻게 쓸 것인가.

어떻게 동작하나

저자들의 답은 분명하다. 단일언어 데이터를 저자원 언어로의 계속 사전학습(continued pretraining)에 넣는 것보다, LLM 이전 시대의 기법인 역번역(back-translation)에 쓰는 편이 더 효과적이다.

무엇과 다른가

절차는 이렇다. 현재 파인튜닝된 LLM이 각 언어의 단일언어 문장을 번역하고, 그렇게 만들어진 쌍이 다시 반대 방향 학습 데이터가 된다. 안정적인 학습을 위해 병렬셋에 대한 업데이트를 번갈아 끼워 넣는다(interleave). 중간 번역을 beam decoding으로 생성하면 품질이 올라가고, 병렬 데이터에서 검색해 온 인컨텍스트 예시를 쓰면 역번역이 한 번 더 개선된다.

어떻게 쓰나

결과는 Odia와 Swahili에서 1K 병렬쌍만으로 측정됐다. 역번역은 저자원 언어로의 계속 사전학습을 도메인 내 XCOMET-XXL 기준 7.7~16.4점 앞선다. beam-decoded 중간 번역을 쓰면 병렬 데이터를 10배 가진 모델도 이긴다. 저자들은 5개 저자원 언어와 고자원 대조군인 Hindi, 3B 백본 2종으로 실험을 넓혀, 역번역이 병렬 데이터만으로 파인튜닝한 모델 대비 저자원 언어 방향 번역을 XCOMET-XXL 기준 16~173% 개선했다고 보고한다. Odia와 Sanskrit에 대한 블라인드 인간 평가도 자동 지표와 일치했다. 논문은 여기에 더해 단일언어 텍스트의 출처와 품질, 양을 분석한다.

전제와 한계

개발자 입장에서 이 논문이 주는 실무적 신호는 명확하다. 저자원 언어를 지원해야 하는데 번역 파이프라인이 이미 어느 정도 돌아가고 있고, 해당 언어의 단일언어 코퍼스가 중간 규모로 확보돼 있다면, 계속 사전학습에 자원을 쏟기 전에 역번역 루프를 먼저 실험해 볼 가치가 있다. 다만 도입 전에 확인할 것이 있다. 단일언어 텍스트의 출처와 품질, 양이 결과를 좌우하며, 중간 번역에 beam decoding을 쓰면 추론 비용이 늘어난다. 병렬셋 업데이트를 어떤 비율로 끼워 넣을지도 학습 안정성에 영향을 준다. 평가는 자체 도메인 데이터로 다시 해야 한다.

한계도 분명하다. 실험은 5개 저자원 언어와 Hindi 대조군, 3B 백본 2종이라는 범위 안에서 이뤄졌고, 보고된 향상 수치는 도메인 내 평가 기준이다. 블라인드 인간 평가는 Odia와 Sanskrit에 대해서만 수행됐다. 즉 단일언어 데이터가 어느 정도 있는 상황이라는 전제 자체가 이 방법의 적용 조건이다.