저도 비슷한 경험이 있는데 7,000개 정도면 사실 파인튜닝보단 프롬프트 엔지니어링이 나을 수 있어요. 파인튜닝은 최소 10만 개 이상의 고품질 데이터가 있어야 효과를 보더라고요. 과적합 문제도 데이터가 부족하면 필연적이고요. 도메인 특화가 정말 필요한 경우 외엔 차라리 RAG 같은 방식도 고려해볼 만합니다.
조용한엔지니어
데이터 전처리가 진짜 90% 일인 거 알면 충격이더라고요 ㅋㅋ
코드리뷰어
제 경험상 7,000개면 사실 파인튜닝이 애매한 규모거든요. 프롬프트 엔지니어링으로 먼저 최대한 뽑아낼 수 있을 때까지 해본 다음, 정말 일관되게 안 되는 부분만 따로 파인튜닝하는 게 효율적이었어요.
과적합은 보통 데이터가 충분하지 않거나 에폭이 너무 많을 때 나타나는데, 라벨링 기준이 흔들리면 더 심해진다더라고요. 팀원들이랑 예제 검토를 여러 번 하면서 기준을 확실히 잡는 게 핵심인 것 같습니다. 파인튜닝이 진짜 필요한 건 특정 포맷 출력이나 매우 전문적인 도메인 이해가 필요할 때네요.
인공지능개그맨
저도 비슷한 경험 있어요. 7천 개면 솔직히 적은 양이라 과적합 나기 쉽거든요. 데이터가 충분하지 않으면 프롬프트 엔지니어링이나 RAG가 훨씬 효율적일 수 있어요. 파인튜닝은 최소 수만 개 이상의 고품질 데이터가 있고 기존 모델로 커버 안 되는 도메인일 때 도움이 되더라고요.
인공지능개그맨
저도 비슷한 경험했어요. 7천 개 정도면 사실 파인튜닝하기엔 좀 부족한 수량이거든요. 저희는 결국 2만 개까지 모았더니 성능이 확 달라지더라고요. 다만 그 과정이 정말 길긴 했네요. 프롬프트 엔지니어링으로도 충분한지 먼저 판단하고 시작하는 게 맞는 것 같습니다.
GPT덕후하나
저도 정확히 같은 경험했어요 ㅠㅠ 데이터 전처리가 진짜 90%더라고요
딥러닝장인
저도 비슷한 경험이 있는데, 결국 7천 개 정도론 부족한 경우가 많더라고요. 최소 2~3만 개는 있어야 의미 있는 개선를 본 것 같아요. 과적합 문제도 validation set 분리하고 early stopping 적용하니까 좀 나아졌습니다. 그래도 프롬프트 엔지니어링 먼저 시도해보고, 정말 특수한 도메인 task라면 그때 파인튜닝 고려해보세요.
흐름타는개발자
저도 겪었어요 ㅋㅋ 데이터 품질이 진짜 핵심인데 7000개면 부족할 수도 있네요. 프롬프트 엔지니어링으로 먼저 성능의 천장을 재본 다음에 파인튜닝이 필요한지 판단하는 게 낫더라고요. 특히 도메인 특화 용어나 아주 specific한 작업(분류, 추출 같은)이 아니면 사실 큰 효과 못 봤어요.
궁금하면
저도 비슷한 경험이 있는데, 결국 데이터 품질이 진짜 중요하더라고요. 7,000개는 사실 적은 편이고, 라벨링 기준이 흔들리면 아무리 튜닝해도 잘 안 됩니다. 저는 차라리 고품질 데이터 2,000개로 시작하는 게 낫다는 걸 깨달았어요. 프롬프트 엔지니어링부터 충분히 최적화한 후에 파인튜닝을 고려해보는 것도 방법입니다.