[AIFactory 세미나] FineTune or Not FineTune

https://www.youtube.com/live/Zpevs-4hj68?si=asOQuIEyWD3JE-4e

 

 

 

 

LLM

• 앞으로는 오픈 모델을 좋건싫건 하나씩은 가지고 있지 않을까. fine tuning한 것들.
• 킬러 앱이 나온 건 없지만, 도구로서는 훌륭한 사례들이 나오고 있음.
• 학습된 데이터에 민감. 각각의 데이터별로 특성이 다르다.
  • pretrained dataset
  • supervised Fine-Tuning dataset
  • preference alignment dataset

그렇다보니

• '어떤 데이터로 학습했느냐'라는 정보가 LLM에서 원하는 결과를 얻기 위한 중요 방법인데
• 공개된 LLM 모델은 일반 사용자가 이걸 알 방법이 없으니 Prompt Engineering이라는 이름으로 사례들이 공유됨
  • 다만, 모델마다 Overfit 된 부분이 있다고 생각함. 같은 prompt가 chatGPT에서는 잘 되는데 Gemini에서는 안 된다, vise versa...
• 벤치마크 테스트도 있긴 한데, 신뢰도가 높다고 하긴 어렵다

파인튜닝 관점에서 보면

• 학습할 데이터가 엄청 많이 필요함
• 그렇게 학습한 모델의 serving (24/7 On)은 또 다른 문제
• 모델 자체가 업데이트되어 기존 모델이 사라졌다
  • 그런데 예컨대 prompt set 10000개 정도를 테스트해서 성능을 확인하고 있었다면?
  • 새로 나온 모델 대상으로 10000개 prompt를 다시 검증 시도해야 한다.
  • Randomness가 내장된 모델이라서, 테스트 또는 원하는 결과를 얻기 위한 Re-Generation Process가 많이 필요

 

(뇌피셜)

그래서 GPU 공급에 전반적으로 문제를 겪고 있지 않을까

• 예컨대 LLaMa 3 405B 모델의 pretrain하는 데에만 들어간 GPU가 16000장. SFT (supervised fine-tuning)은 별도.
• ML 모델을 잘 만드려면 Experiment 많이 해봐야 함... 수많은 GPU / hour가 홀딩된 상태
• 여기에 serving을 위한 Standby GPU 까지 생각하면?
  • 머스크 트위터: xAI의 Groq 서빙에만 10만 장의 GPU로 클러스터 구축했다고 함

LLM뿐만 아니라 vision / AGI까지 한다? 부족할 거 같다.

• 다시말해, 새로운 모델이 등장한다면 기존 모델은 빠르게 sunset될 수밖에 없다
• 리소스가 없으니까, 옛날 버전을 유지보수하기가 어려움

LLM과 App의 Integration 방법론

 

Chat UI + ping pong

• LLM의 다양한 파라미터를 조정하면서 테스트하기 좋은 형태
• 이걸로 찾아낸 최적값을 API로 호출했을 때도 동일한가
• System Integration했을 때도 의도한 대로 동작하는가

Open Weight model?

• 종류가 너무 많다. 벤치마크 결과를 100% 믿기도 어려운데, 그 많은 모델을 테스트한다? 돈도 많이 든다
• LLM이 사용자에게 훌륭한 경험을 제공하기 위해 설정할 것들이 많다.
  • 시스템 프롬프트 / 채팅 히스토리 관리 / 파라미터...
  • 오픈모델의 경우 chat UI가 진짜 'ui'만 제공함. 적절한 adjustment 찾아가기 쉽지 않음

Fine Tuning

 

Prompt Engineering은 시작은 쉽지만 최적 결과를 찾기까지는 매우 힘든 여정.

• token usage (system instruction token이라던가..)

FineTuning은 내가 원하는 특정 작업을 별도의 instruction 없이도 바로 실행할 수 있음.

• Gemini / OpenAI 모델도 fine tuning 서비스 제공됨.
  • PEFT 같은 기법으로 adapter 붙이는 형태
• 하지만, 서비스형 LLM보다는 오픈소스 모델 들고와서 fine tuning하는 경우가 더 많음
  • 학습데이터가 외부에 제공되어야만 한다는 점 (privacy)
  • API service Not Stable.
  • Target Environment 문제
  • Fast Rolling Out...
    • 예컨대 GPT-3.5는 적절한 intelligence + low cost 였어서 연동된 서비스가 많았는데, 지금은 모델 지원이 종료됐음. 유무형의 migration 비용이 필요했을 것.
  • internal change 파악이 어렵다. 어느 날부터 갑자기 '모델이 왜 이렇게 멍청해졌지?' 라는 의견이 계속 나올 경우.. 모델 버전은 똑같은데, prompt test 다시 해야 하나?

 

위와 같은 이유들 때문에 서비스형 LLM은 PoC / Development 환경에서 사용하는 게 좋음.

서비스형 LLM에서 효과적이었던 Prompt를 내 Production에서 쓰고 싶다면? Fine Tuning이 적합하다고 생각함.

 

LLMOps 파이프라인의 각 컴포넌트를 비유하자면

• Prompt: 하나의 function. 원하는 결과를 응답하는 prompt가 있다 == 좋은 function이 있다.
• 일반적인 Ops에서는 unit test가 있다. function 단위로 테스트한다 == prompt 테스트한다.
• all prompt works well -> 100% coverage

여기서 좋은 prompt를 얻기 위한 방법으로 외부 service LLM을 사용.

 

coverage 확보하고 데이터셋이 생기면, 원하는 합성 데이터를 만들어낸다. (fine-tuning에 사용할)

• SFT / PPO / DPO...
• 실제 데이터와 유사하지만, data privacy는 확보하는 data synthesis가 필요함 / 중요함.
• 라이센스 문제가 있긴 한데, 이걸로 태클 거는 사람이나 상황이 아직은 없음.
  • 메타의 경우 LLama3 405B로 static data 생성하는 것을 합법이라고 규정함.

우리 조직의 문제를 해결할 수 있는 데이터들을 LLama3와 같은 모델로 만들어낸다 -> LLM fine tuning해서 문제를 해결한다.

 

다들 Super Intelligence에 관심이 많고, 회사나 커뮤니티에서도 이걸 목표로 하는 경우가 많음.

• 하지만 사용자의 경우, LLM으로 하고 싶은 목적이 보통은 정해져 있음.
  • 번역 / 프로그래밍 / etc...
  • 특정 usecase 기반, Task-specific model 만드는 게 더 효율적이라고 생각함.

 

다만 'Fine tuning에 사용할 Synthetic Data'를 어떻게 만드는가? -> Prompt Engineering 영역임.

단순하게 생각하면

• instruction / response 제공하고
• "예시와 비슷하지만 약간의 diverse를 주는 prompt / response Pair를 만들어달라"는 형태.

Evaluation

 

• Benchmark score는 '내가 해결해야 할 문제에도 적합한 숫자인가'를 판단하기 쉽지 않음
• LLM as a Judge 형태로 Evaluation에도 LLM 쓰는 시도가 많음.
  • 개별 응답결과를 신뢰한다기보다는, 경향성이나 추세의 일관성을 보는 것
  • Another Prompt Engineering...

 

prompt 구조 예시

• instruction
• collection of human response
• collection of fine-tuned LLM response

얼마나 비슷한지 / LLM의 response는 instruction을 얼마나 반영하는지를 LLM에 물어본다.

 

예시. 각 모델별로 prompt / response Pair 만들어서 파인튜닝한 결과물. test set으로 평가한 것들.

• 하나의 LLM API가 down됐을 때 어떤 LLM API로 대체하면 서비스 품질 영향을 최소화할 수 있을지.. 용도로 활용 가능

 

요런 식으로 데이터 분포도 비교할 수 있다.

• GPT4o: 전반적으로 고른 분포
• Gemini: Preciseness에서는 약간 치우쳐있다

완전한 테스트라고 하기는 어렵지만, baseline으로 만들기에는 적절한 수준.

 

공개된 자료는 아니고, 대충 estimation한 것. 서비스 LLM과 자체 파인튜닝 모델의 비용 비교

• 요약: L4 기준으로 serving했을 때 가격 경쟁력이 있다.

Conclusion

 

• 파인튜닝 자체는, 서비스 LLM에서 발생하는 장애 대비를 위해서라도 필요함
• 꼭 최신모델을 추종할 필요 없다. 잘 만든 파인튜닝 모델 오래 쓰는 게 효율적일 수 있음.
• 벤치마크 데이터가 'my usecase'를 100% 반영하지는 못한다
• 파인튜닝에 사용할 데이터 Quality가 중요함.

---

Q. 작은 모델의 경우 Prompt Engineering 효과가 크지 않은 듯한데, 맞는지?

• 자료가 있는건 아닌데, prompt를 잘 쓰면 효과가 있을 거라 봄. 모델에 맞는 Prompt 자체는 있다.
• 원하는 답변을 얻어가는 것 자체는 그동안 가능했음.

Q. 파인튜닝이 필요한 프로젝트의 기준..?

• Mission Critical 이슈를 해결해야 함 + LLM이 효과가 있을 것 같음 = 파인튜닝.
• 쓰일 분야는 많을 거 같음. 예컨대 Data Privacy 중요한 경우, 외부 서비스 API 호출을 꺼려함.

Q. 파인튜닝에 필요한 데이터셋은 어느 정도가 적절할까?

• 데이터 품질이 좋다면, 1000개 데이터만으로도 괜찮은 성능이 나온다는 리포트도 있음.
• 단, '고품질'은 결국 사람이 검수해야만 함.
• 고품질 데이터 만드는 데 드는 비용 vs 합성 데이터셋을 대량으로 만드는 비용 -> trade-off.

Q. 학습데이터 부족하면? 합성데이터 만드는 방법은?

• 정형화된 건 없다. 목적에 따라서 prompt 구성해서 요청한다거나
• 최근까지 많이 쓰이던 게 Evo-instruct (wizardLM 사용한) https://x.com/WizardLM_AI/status/1812844503251947978
  • 단순한 seed 질문 -> 파생 질문을 복잡하게 만든다던가, 다른 형태의 질문을 만든다던가...
• 특정 환경에 맞는 데이터가 필요함... 그러면 그 환경을 시뮬레이션하는 게 좋을 듯
  • 채팅이라면 질문/답변 형태일거고
  • 네트워크 관련이라면 topology 관련 합성데이터 라던가.