Dolci-Think-SFT-7B의 샘플들을 번역하고 있었는데, 그냥 vllm에 Gemma를 배포하고 간단한 번역 프롬프트를 작성한 뒤 소스 언어와 타겟 언어를 지정하기만 하면 되는 쉬운 작업이라고 생각했습니다. 하지만 결국 거대한 토끼굴(rabbit hole)에 빠지게 되었고, 거기서 빠져나왔을 때쯤에는 꽤 불만족스러운 상태가 되어 이에 대해 불평을 좀 해야 했습니다. 미안합니다 ㅎㅎ 그래도 교육적인 내용이 되도록 노력할 테니 여러분도 무언가를 배울 수 있기를 바랍니다. 여기서 가장 중요한 교훈은, 아마 여러분 중 많은 분이 알고 계시겠지만, 만약 페이로드 (payload)에 지시 사항이 포함되어 있다면 모델이 여러분의 프롬프트 대신 페이로드의 지시 사항을 실행할 수도 있다는 점입니다. 꽤 당연한 이야기지만, 번역처럼 "지루한" 작업에서는 미처 생각하지 못했습니다. 문제는 모델이 추론 흔적 (reasoning traces)에서 언급된 문제들을 번역하는 대신 실제로 실행해 버렸다는 것입니다. 즉, 프로그래밍 문제에 대한 해결책이나 수학 문제의 증명 등을 실제로 만들어냈습니다. 사실 이 외에는 딱히 할 말이 없습니다. 번역을 하고 있다면 이 점을 경계하십시오. 당연히 항상 모델의 출력물을 경계해야 하며, 모델에 무엇을 입력하고 무엇을 신뢰할지 알 수 있도록 적절하고 엄격한 입력 태깅 (input tagging)을 갖추어야 합니다. 따라서 만약 여러분이 모델이 "일반적인" 텍스트를 번역하는 것을 신뢰한다면, 이전에 시도하거나 평가해 보지 않은 새로운 분포 (예: 추론 (reasoning))에 대해서는 아마 신뢰하지 못할 것입니다. 저와 함께 이 토끼굴로 들어가고 싶으시다면, 제가 여기서 말하는 내용은 제가 테스트해 본 다음 두 모델에 국한된 것입니다: RedHatAI/gemma-3-27b-it-FP8-dynamic, RedHatAI/gemma-4-31B-it-FP8-Dynamic. bf16 모델들도 이 문제를 겪는지 여부는 확실하지 않지만, 직접 해보지 않고서는 알 수 없으므로 그렇다고 말씀드리고 싶습니다. 저는 Gemma 모델들이 가장 강력한 다국어 (multilingual) 모델이라고 들었기 때문에 Gemma 모델들을 선택했습니다. 이 실패를 설명하는 유용한 방식은 지시 사항 (instruction)과 페이로드 (payload) 사이의 경계가 무너졌다는 것입니다.

그리고 저는 이것이 번역뿐만 아니라 재작성 (rewriting), 교정 (proofreading), 요약 (summarization) 등, 지시 사항 준수 모델 (instruction-following model)을 특이한 상황에 놓이게 하는 모든 작업에서 더 일반적인 현상일 것이라고 확신합니다. 예를 들어, 외부 프롬프트 (outer prompt)는 변환 (transformation)을 요청하는 반면, 데이터로 취급되는 텍스트 자체에 자체적인 지시 사항이 포함되어 있는 경우와 같은 상황 말입니다. 이는 일종의 간접적(indirect)이거나 비악의적(non-malicious)인 프롬프트 인젝션 (prompt injection)을 떠올리게 합니다. 어쨌든, 이 문제의 심연을 빠르게 파고들어 보자면, 가장 짜증 나는 첫 번째 점은 겉으로 보기에는 모든 것이 완전히 정상적으로 보였다는 것입니다. 요청이 stop으로 종료되었고, 출력 파일의 행 (row) 수가 맞으며 비어 있는 내용도 없었고, 처리량 (throughput) 수치도 좋아 보였습니다. 추론 서버 (inference server)는 올바른 출력과 잘못된 출력을 구분할 수 없기 때문에 이는 당연한 결과입니다. 하지만 샘플을 살펴보니 망가진 출력물들이 원문보다 훨씬 짧은 경우가 많다는 것을 발견했고, 그래서 출력물 대비 원문 길이 비율 (output-to-source length ratio)을 매우 저렴한 경보 장치로 사용하기 시작했습니다. 이것이 품질 지표 (quality metric)는 전혀 아니지만, 모델에게 거대한 추론 과정 (reasoning trace)을 주고 아주 작은 결과물만 반환한다면, 아마 파일을 열어볼 가치가 있을 것입니다. 그래서 저는 이를 이용해 최악의 실패 사례 30개를 모아 작은 테스트 세트를 만들었고, 여기에 여러 방법을 시도해 보았습니다. 처음에는 30개 사례를 모두 해결했을 때 매우 유혹적인 실수, 즉 기분이 좋아지는 실수를 저질렀습니다. 하지만 예상하셨겠지만, 알려진 실패 사례로만 구성된 데이터셋은 당신의 방법이 알려진 실패를 복구할 수 있는지만 알려줄 뿐, 해당 실패가 얼마나 자주 발생하는지 또는 그 방법이 "정상적인" 예시에서도 효과적인지는 알려주지 않습니다. 하지만 효과가 있었고 희망적이었던 주요 방법은 청킹 (chunking), 그리고 코드 펜스 (code fences), 수학 (mathematics) 및 기타 구조를 보호하는 것이었습니다. 직관적으로 (이것이 틀릴 수도 있지만), 산문 (prose)을 더 작은 요청으로 나누는 것이 효과가 있었던 이유는, 번역 지시 사항이 모델이 해결해야 할 문제처럼 보이는 수천 개의 토큰 (tokens) 옆에 파묻히는 대신, 국소적으로 더 관련성 있게 유지되었기 때문일 것입니다.

하지만 청킹 (chunking)은 깨진 코드 펜스 (code fences), <think> 태그, 재구성 (reconstruction), 일관되지 않은 용어 (inconsistent terminology), 청크 간의 문맥 (context between chunks) 등 완전히 새로운 문제 목록을 만들어냈습니다. 결국 저는 문서를 유형별 블록으로 정확히 분리하는 파서 (parser)를 작성해야 하는 짜증스러운 작업에 직면하게 되었습니다. 이를 통해 Python이 변경되지 않아야 할 부분(코드, 수학식 등)을 보존할 수 있게 하여 산문 (prose) 부분만 번역 대상으로 보내고, 이후 모든 것을 제자리에 다시 배치하여 재구성할 수 있도록 했습니다. 그 후, 6개 언어, 6개의 청크 길이, 그리고 두 모델을 대상으로 별도의 340행 샘플에 대해 더 큰 실험을 수행했습니다. 실험 결과, 두 모델 모두 작은 청크에서는 상당히 깔끔하게 동작했지만, 청크 길이가 커짐에 따라 작업 수행 능력과 폭주 생성 (runaway generation) 비율이 갑자기 훨씬 악화되었습니다. 이는 예상했던 바였지만, 제대로 연구될 필요가 있었습니다. Gemma 4는 그 임계점 (cliff)을 더 멀리 밀어냈지만, 실패 자체를 없애지는 못했습니다. 저는 정말로 이 문제가 해결되기를 바랐습니다. 그리고 당연하게도, 평가는 그 자체로 또 다른 미궁 (rabbit hole)이 되었습니다. 저는 COMET-QE를 사용했지만, 체크포인트 (checkpoint)의 입력 길이가 제한되어 있어 점수를 매기기 위해 긴 원문과 번역 쌍을 다시 나누어야만 했습니다. 하지만 원문과 번역이 정확히 같은 지점에서 나누어지지 않는다면 일종의 정렬 (alignment) 방법이 필요하며, 결국 저는 양쪽을 독립적으로 나눈 뒤 위치에 따라 조각들을 짝지어주는 방식에 의존해야 했습니다. 이 방식은 점수를 산출해주었지만, 그 점수 이면의 대응 관계는 특히 청크의 길이가 길어질수록 약해졌습니다. 그리고 여기서 멈추면 더 고통받을 수 없으니, 그 점수들을 평균 내는 것조차 간단하지 않았습니다. 예를 들어, 모든 평가 조각이 한 표씩 갖게 된다면, 패커 (packer)가 우연히 어떤 구절을 네 조각으로 나누었다는 이유만으로 그 구절이 더 중요해질 수 있습니다. 그래서 저는 원문과 후보(candidate) 길이의 합계에 따라 단위에 가중치를 부여했습니다. 이 방식은 임의적인 투표 문제는 해결해주지만, 정렬의 불확실성 (alignment uncertainty) 문제는 해결해주지 못합니다.

만약 긴 위치 쌍 (long positional pair)이 제대로 정렬되지 않았다면, 길이 가중치 (length weighting) 방식 또한 해당 정렬 오류에 더 많은 영향력을 부여하게 됩니다. 따라서 큰 청크 (large chunks)에서의 품질 곡선 또한 점점 더 약해지는 대응 증거 (correspondence evidence)로부터 만들어진 곡선이었으며, 이는 제가 원했던 깔끔한 결론은 아니었습니다 (하하). 저는 후보군을 비교하고 더 상세한 오류 루브릭 (error rubric)을 적용하기 위해 블라인드 모델 판정관 (blinded model judge, 중간 난이도의 GPT 5.5)을 사용하는 데까지 나아갔지만, 이것이 6개 언어에 걸친 원어민 검토 (native speaker review)를 대체할 수 있는 것처럼 가장하고 싶지는 않습니다. 저는 여기서 더 나아가 이를 제대로 보정 (calibrate)하고 판정관에 대한 신뢰도 (confidence)를 추정하고 싶었습니다. 예를 들어, 원어민들이 판단할 수 있도록 가장 흥미로운 "작은" 샘플 하위 집합 (subset)을 찾아내려고 시도하기도 했지만, 그러다 보니 이것이 지옥 같고 그럴 가치가 없다는 생각이 들어 어느 시점에서는 멈춰야 한다고 생각했습니다. 그래서 네, 저는 번역이 해결되었고 이것이 쉬운 작업일 것이라고 생각하며 이 일에 뛰어들었지만, 글쎄요. 우리가 가장 무시하는 것들로부터 가장 많은 것을 배우게 되는 것 같습니다. 이 모든 내용을 그림 등과 함께 깔끔하고 더 상세하게 읽고 싶으시다면 여기에서 읽으실 수 있습니다: https://reinforcedknowledge.com/posts/when-translation-starts-solving/ 솔직히 왜 이 모든 것에 대해 썼는지 모르겠지만, 만약 한 번 살펴보신다면 제가 진정으로 가치 있다고 생각하는 부분은 마지막 섹션입니다. 왜냐하면 그 부분은 (데이터셋을 번역하는 이 매우 구체적인 작업 외에) 머신러닝 (ML) 작업을 할 때 일반적으로 무엇에 주의를 기울여야 하는지에 관한 것이기 때문입니다. 이는 여러분의 개선 능력에 직접적인 영향을 미칩니다. 정직한 증거 없이는 여러분이 어느 방향으로 가고 있는지, 그리고 실제로 개선되고 있는지 여부를 알 수 없습니다. 또한 이는 제가 사람들이 저지르는 실수라고 관찰한 것들로부터 영감을 받았습니다.

또한 제가 여기서 사용한 것 이상으로 이를 개선하는 방법에 대해서도 이야기합니다. 제 생각에 LLM (Large Language Model) 개발과 마찬가지로, 가장 큰 장애물은 제대로 된 평가, 그리고 신뢰할 수 있는 평가입니다. 이것이 제 시간의 대부분을 차지했던 부분이었으며, 당연히 저는 이 문제를 해결하지 못했고 누군가가 해결해 주기를 바라고 있습니다 (하하). 저는 단지 번역 분야에서 조금이라도 진전을 이룰 수 있도록 우리가 무엇을 필요로 하는지에 대한 제 아이디어를 마지막에 제시하는 것뿐입니다. submitted by /u/ReinforcedKnowledge [link] [comments]