저도 비슷한 경험이 있는데 7,000개 정도면 사실 파인튜닝보단 프롬프트 엔지니어링이 나을 수 있어요. 파인튜닝은 최소 10만 개 이상의 고품질 데이터가 있어야 효과를 보더라고요. 과적합 문제도 데이터가 부족하면 필연적이고요. 도메인 특화가 정말 필요한 경우 외엔 차라리 RAG 같은 방식도 고려해볼 만합니다.
프롬프트
LLM 파인튜닝 처음 해봤는데 생각보다 복잡하네요
회사 프로젝트로 우리 도메인에 맞게 LLM을 파인튜닝해보려고 시작했어요. 처음엔 간단할 줄 알았는데 데이터 전처리하는 것부터 진짜 시간이 오래 걸리더라고요. 라벨링 기준을 정하는 것도 팀원끼리 계속 충돌하고요.
결국 몇 주를 거쳐서 7,000개 데이터로 돌려봤는데 처음 결과는 기대 이하였어요. 과적합 문제도 있었고, 학습률이나 배치 사이즈 튜닝하는 과정이 정말 번거웠습니다. 지금은 프롬프트 엔지니어링이 차라리 더 효율적일 수도 있다는 생각이 들고 있어요.
혹시 같은 경험이 있으신 분들 계신가요? 파인튜닝이 정말 필요한 상황이 뭔지 궁금하네요.
결국 몇 주를 거쳐서 7,000개 데이터로 돌려봤는데 처음 결과는 기대 이하였어요. 과적합 문제도 있었고, 학습률이나 배치 사이즈 튜닝하는 과정이 정말 번거웠습니다. 지금은 프롬프트 엔지니어링이 차라리 더 효율적일 수도 있다는 생각이 들고 있어요.
혹시 같은 경험이 있으신 분들 계신가요? 파인튜닝이 정말 필요한 상황이 뭔지 궁금하네요.
추천 9 비추천 0
- 이전글LLM으로 코드 리뷰 자동화 돌려본 후기26.06.06
- 다음글요즘 RAG 시스템 도입하는 회사 많던데, 실제로 얼마나 효과 있나요?26.06.04
댓글
3
댓글목록
데이터 전처리가 진짜 90% 일인 거 알면 충격이더라고요 ㅋㅋ
제 경험상 7,000개면 사실 파인튜닝이 애매한 규모거든요. 프롬프트 엔지니어링으로 먼저 최대한 뽑아낼 수 있을 때까지 해본 다음, 정말 일관되게 안 되는 부분만 따로 파인튜닝하는 게 효율적이었어요.
과적합은 보통 데이터가 충분하지 않거나 에폭이 너무 많을 때 나타나는데, 라벨링 기준이 흔들리면 더 심해진다더라고요. 팀원들이랑 예제 검토를 여러 번 하면서 기준을 확실히 잡는 게 핵심인 것 같습니다. 파인튜닝이 진짜 필요한 건 특정 포맷 출력이나 매우 전문적인 도메인 이해가 필요할 때네요.
과적합은 보통 데이터가 충분하지 않거나 에폭이 너무 많을 때 나타나는데, 라벨링 기준이 흔들리면 더 심해진다더라고요. 팀원들이랑 예제 검토를 여러 번 하면서 기준을 확실히 잡는 게 핵심인 것 같습니다. 파인튜닝이 진짜 필요한 건 특정 포맷 출력이나 매우 전문적인 도메인 이해가 필요할 때네요.
댓글을 작성하려면 로그인이 필요합니다.