요약 (TL;DR) — LoRA 기반의 선호도 최적화(preference optimization)는 저렴하기 때문에 인기가 많지만, 낮은 랭크 제약 조건(low-rank constraint)은 모델을 선택된 출력과 거부된 출력을 분리하는 가장 단순한 방향으로 체계적으로 편향시킨다. 이는 보통 내용(substance)이 아니라 스타일(style)에 관한 것이다. 따라서 LoRA-DPO 모델에서 지식 증류(Distilling)를 하면 그 '지름길(shortcut)'을 학생 모델에게 영구적으로 각인시키게 된다. 해결책은 더 많은 데이터가 아니라, 스택의 어느 부분에서 랭크 예산(rank budget)을 사용할지 재고하는 것이다.

모두가 이제 LoRA를 통해 선호도 최적화를 수행한다. 대규모 모델에 대한 전체 랭크 (full-rank) RLHF나 DPO는 비용이 많이 들기 때문에, 업계의 기본 방식은 다음과 같다: 베이스 가중치(base weights)를 고정하고, 낮은 랭크 어댑터(low-rank adapter)를 부착한 다음, 그에 대해 DPO를 실행하고 배포하는 것이다. 저렴하고 빠르며, 대부분 작동한다—평가 점수(eval scores)는 올라가고, 선택된 응답이 거부된 응답보다 선호되며, 모두가 만족한다.

하지만 아무도 가격을 매기지 않는 문제가 있다: 랭크 제약 조건은 단순히 업데이트를 저렴하게 만드는 것이 아니다. 그것은 어떤 종류의 업데이트가 가능한지를 바꾼다. 그리고 빠듯한 랭크 예산 하에서 가능한 것은 거의 항상

Full-rank 업데이트는 여전히 그 신호를 수많은 독립적인 방향으로 확산시킬 여유가 있으며, 그중 일부는 실제 추론 능력의 변화, 즉 더 나은 사실 선택(fact selection), 더 긴밀한 논리 체인(logical chains), 더 정확한 도구 사용(tool use)과 일치합니다. 그 단계에 도달하는 것은 비용이 많이 들고 느리지만, 그 역량(capacity)은 존재합니다.

LoRA 어댑터는 그러한 역량을 가지고 있지 않습니다. 당신은 훈련이 시작되기도 전에 업데이트가 랭크(rank) 8, 16 또는 64의 부분 공간(subspace) 내에 존재하도록 이미 결정했습니다. 이제 옵티마이저(optimizer)는 데이터 내의 선호 신호(preference signal)를 설명할 수 있는 단 하나의 가장 저렴한 부분 공간을 찾아야 합니다. 최적화(Optimization)는 당신의 의도에는 관심이 없습니다. 제한된 예산이 주어지면, 옵티마이저는 가장 적은 자유도(degrees of freedom)를 사용하여 선택된 답변(chosen)과 거부된 답변(rejected)을 최대한 분리하는 방향을 항상 선호할 것입니다. 그리고 그 방향은 거의 항상 피상적인 스타일적 특징(stylistic tell)입니다. 왜냐하면 스타일적 특징이야말로 랭크-16 행렬이 표현하기에 매우 적합한, 저복잡도(low-complexity)이면서 광범위하게 적용 가능한 신호이기 때문입니다. 심층적인 추론 변화(Deep reasoning shifts)는 고복잡도(high-complexity)이며 예시 특이적(example-specific)입니다. 그것들은 공유된 저랭크 부분 공간(low-rank subspace)으로 그만큼 깔끔하게 압축되지 않습니다.

실제 사례에서의 모습

당신은 아마 원인을 명명하지 않은 채 그 증상을 목격했을 것입니다. LoRA-DPO 과정을 거치면 모델이 눈에 띄게 더 공손해지고, 더 신중해지며, 긍정적인 문구로 시작하거나 주의 사항을 덧붙일 가능성이 높아집니다. 그리고 당신의 선호 승률(preference win-rate) 지표는 상당히 상승합니다. 하지만 실제 추론 품질, 사실적 정확도, 또는 홀드아웃 문제(held-out problems)에서의 작업 성공률을 파헤쳐 보면, 개선 효과는 미미하거나 거의 없습니다. 모델은 선호되는 답변처럼 들리도록(sounding) 하는 능력은 좋아졌지만, 선호되는 답변 그 자체가(being) 되는 능력은 좋아지지 않은 것입니다.

이것은 더 많은 쌍(pairs)을 수집한다고 해서 해결할 수 있는 데이터 품질의 문제가 아닙니다. 더 많은 쌍은 동일한 '저렴한 방향(cheap direction)'을 더 빠르게 강화하는데, 그 이유는 이 저렴한 방향이 거의 구조적으로, 크고 이질적인 선호도 비교 세트 전체에 걸쳐 가장 잘 일반화되는 방향이기 때문입니다. 스타일 전이(Style transfers)는 도메인을 넘나들며 일어나지만, 추론 품질(Reasoning quality)은 그렇지 않습니다. 만약 당신의 랭크 예산(rank budget)이 코딩, 요약, 그리고 개방형 채팅 전반의 선호도를 동시에 설명하기 위해 단일한 공유 부분 공간(shared subspace)을 강제한다면, 스타일만이 압축 과정에서 살아남을 수 있는 충분한 도메인 간 일관성을 가진 유일한 요소가 됩니다.

증류 증폭기 (The distillation amplifier)

이 문제는 증류(distillation)를 수행하는 순간 더 악화됩니다. 증류는 학생 모델(student)이 교사 모델(teacher)의 근본적인 계산 과정을 맞추는 것이 아니라, 교사 모델의 출력 분포(output distribution)를 맞추도록 학습시키기 때문입니다. 만약 교사 모델의 "선호도에 정렬된(preference-aligned)" 행동이 변경되지 않은 기본 모델 위에 얹혀진 주로 스타일적인 오버레이(stylistic overlay)라면, 학생 모델은 정확히 그것을 재현하도록 학습됩니다. 충실하고 효율적으로 말이죠. 하지만 교사가 처음에 가졌던 원래의 추론 능력은 전혀 갖추지 못한 채로 말입니다. 왜냐하면 학생의 역할은 추론을 복구하는 것이 아니라 로짓(logits)을 맞추는 것이었기 때문입니다.

결국 당신은 실체(substance)는 전혀 없이 지름길(shortcut)만을 깔끔하게 물려받은 작은 모델을 얻게 됩니다. 그리고 증류는 보통 처음에 그 지름길에 보상을 주었던 것과 동일한 선호도-스타일 지표(preference-style metrics)로 평가되기 때문에, 전체 과정이 마치 잘 작동하고 있는 것처럼 보이게 됩니다. 선호도 승률(Preference win-rate)은 기본 모델, LoRA-DPO 교사, 증류된 학생 모델에 이르기까지 모든 단계에서 상승합니다. 하지만 실제 작업 역량(Actual task competence)은 전체 과정 동안 정체되거나 퇴보할 수 있으며, 당신이 관찰하고 있는 지표는 결코 그 사실을 알려주지 않을 것입니다.

랭크 예산이 실제로 투입되어야 할 곳

이 모든 내용이 LoRA나 DPO에 반대하는 논거는 아닙니다. 이는 랭크(rank)를 순수한 비용 레버(cost lever)로 취급하고 선호도 최적화(preference optimization)를 순수한 품질 레버(quality lever)로 취급하는 것에 대한 반대입니다. 실제로는 이 둘이 특정한 예측 가능한 방식으로 서로 상충(trade-off)하기 때문입니다.

증상이 아닌 메커니즘 자체를 해결하는 몇 가지 구체적인 조정 방법은 다음과 같습니다:

• 기능별로 랭크 예산(rank budget)을 분리하십시오. 스타일(style)에 민감한 레이어에는 작은 어댑터(adapter)를 할당하고, 작업 관련 연산(task-relevant computation)에 더 가까운 레이어 — 즉, 추론 집약적 작업과 연결된 후반부 트랜스포머 블록(transformer blocks)이나 출력 투영(output projections) — 에는 의미 있게 더 큰 랭크를 할당하십시오. 모든 레이어에 균일한 랭크를 적용하면, 옵티마이저(optimizer)가 가장 저렴하고 전역적인 신호(global signal)를 기본값으로 선택하게 됩니다.

• 감당할 수 있는 가장 작은 모델에 대해 선호도 최적화(preference optimization)를 풀 랭크(full-rank) 또는 그에 가깝게 수행한 뒤, 이를 증류(distillation)를 위한 교사 모델(teacher)로 사용하십시오. 지름길(shortcut)을 증류하는 것은 효율적입니다. 하지만 실제 능력(capability)을 증류하는 것은 파이프라인에서 최소한 한 번은 풀 랭크 비용을 지불할 가치가 있습니다.
  객관적으로 확인 가능한 결과가 있는 작업들을 대상으로 선호도 튜닝(preference-tuned)된 체크포인트를 평가하십시오 — 실행 가능한 코드, 결과가 확인 가능한 수학 문제 등