LoRA를 붙이고 하이퍼파라미터를 만지다가 데이터와 모델을 의심하게 됐다

데이터셋을 어느 정도 정리하고 나니 드디어 학습을 시작할 수 있을 것 같았다.

대상은 Gemma4-26B-A4B와 Qwen3.6-35B-A3B였다. 하나는 MoE 구조를 이해하는 좋은 실험 대상이었고, 다른 하나는 비교적 익숙한 생성 경로에서 결과를 확인하기 좋았다.

처음부터 두 모델의 결과를 같은 기준으로 비교하면 안 된다는 것도 이때 배웠다.

dense와 MoE는 이름만 다른 모델이 아니었다

Dense 모델은 각 토큰 처리에 전체 레이어의 파라미터가 참여한다. MoE는 expert가 여러 개 있고 router가 일부 expert를 선택한다.

Dense:
  token → 모든 주요 파라미터

MoE:
  token → router → 일부 expert

그래서 MoE의 전체 파라미터 수만 보고 dense보다 몇 배 무겁다고 말할 수 없고, 활성 파라미터 수만 보고 메모리 비용이 작다고 말할 수도 없다. 가중치 보관, routing, expert 통신, KV cache, batch 구성은 각각 다른 비용을 만든다.

LoRA를 붙일 때도 마찬가지였다. “adapter 하나를 추가한다”는 말은 간단하지만, 어느 모듈에 어떤 rank로 붙일지와 학습 대상 파라미터가 구조에 따라 달라진다.

처음 실패는 데이터 문제를 설정 문제로 착각한 것이었다

첫 결과가 기대보다 별로였다.

그러자 학습률, rank, alpha, warmup, batch size부터 바꾸기 시작했다. 숫자를 바꾸면 결과도 바뀌었지만, 좋아졌다는 확신은 없었다.

지금 생각하면 순서가 반대였다.

샘플 품질 확인
  → 포맷과 라벨 확인
  → base model baseline
  → 작은 실험
  → 그다음 하이퍼파라미터

base model에 같은 평가셋을 넣어보지 않았고, 학습 데이터와 평가 데이터의 문체가 얼마나 겹치는지도 충분히 보지 않았다. 답변이 좋아진 것처럼 보인 이유가 학습이 아니라 데이터 누수일 수도 있었다.

하이퍼파라미터는 결과를 바꾸는 손잡이지, 원인을 설명해주는 장치는 아니었다.

한 번에 여러 설정을 바꾸면 아무것도 배울 수 없다

실험이 망하자 설정을 한꺼번에 바꿨다.

rank도 바꾸고, learning rate도 바꾸고, sequence 길이도 바꾸고, target module도 바꿨다. 결과가 조금 나아졌지만 어떤 변경이 영향을 줬는지 알 수 없었다.

그래서 나중에는 실험 단위를 줄였다.

실험 ID
  - dataset version
  - base model
  - adapter target
  - rank / alpha
  - learning rate
  - context policy
  - seed
  - eval 결과

결과가 나빠진 실험도 버리지 않았다. 특정 문체는 좋아졌지만 사실성이나 형식 준수는 떨어지는 경우가 있었고, 짧은 입력에서는 괜찮지만 긴 문맥에서 무너지는 경우도 있었다.

평균 점수 하나로는 이런 trade-off가 보이지 않았다.

MoE에서 특히 조심한 것

MoE는 expert가 알아서 전문성을 학습한다는 기대를 만들기 쉽다. 하지만 내 데이터가 커밋, PR, Jira, Slack과 디자인·CTO·리뷰 기록으로 나뉘어 있다고 해서 특정 expert가 특정 페르소나를 깨끗하게 담당한다는 보장은 없다.

오히려 데이터가 편향되면 router가 특정 형식에 과하게 끌릴 수 있다. Slack 샘플이 많으면 문서 요청에도 짧은 메시지 같은 답을 내놓을 수 있고, PR 샘플이 많으면 간단한 질문에도 목차를 붙일 수 있다.

그래서 모델 구조보다 먼저 입력과 출력 계약을 평가했다.

페르소나 선택과 검토 순서가 맞았는가
출력 형식이 맞았는가
공개 범위를 넘지 않았는가
원문에 없는 사실을 추가하지 않았는가

이것들은 expert 수나 adapter rank로 해결되지 않는 문제였다.

LoRA는 개인화의 끝이 아니라 한 계층이었다

LoRA를 적용한 뒤 표현은 확실히 달라졌다. 자주 쓰는 문장 구조와 제목 스타일이 더 잘 나왔다.

하지만 최신 프로젝트 상태나 실제 결정의 근거를 모델이 자동으로 아는 것은 아니었다. 학습 데이터에 없는 변경사항은 생성할 수 없고, 오래된 기록을 학습했다면 낡은 답을 자신 있게 만들 수도 있다.

여기서 RAG가 필요해졌다.

LoRA → 어떻게 말하는가
RAG  → 무엇을 근거로 말하는가

그리고 RAG를 붙이자 이번에는 하네스가 필요해졌다. 어떤 자료를 검색하고, 몇 개를 넣고, 충돌하는 기록을 어떻게 다루고, 근거가 없으면 어떻게 실패할지 정해야 했다.

모델을 더 튜닝하면 해결될 것 같았던 문제가 시스템 설계 문제로 이동했다.