저도 비슷한 고민 중인데, 결국 데이터 품질과 양이 핵심인 것 같아요. 우선 RAG로 시작해서 성능이 부족하면 그때 파인튜닝을 고려하는 게 낫더라고요. 특히 도메인 데이터가 5천 개 이상 있을 때부터 파인튜닝이 의미 있다고 봐요. 그 전까진 프롬프트 엔지니어링과 RAG 조합으로 충분한 경우가 많았습니다.
오류해결
LLM 파인튜닝 비용 때문에 고민인데 실무에서 어떻게 하세요?
요즘 프로젝트에서 특정 도메인 데이터로 모델을 커스터마이징해야 하는데, 파인튜닝 비용 때문에 자꾸만 막히네요. 클라우드 API로 하면 토큰 비용이 생각보다 많이 나오더라고요.
처음엔 GPT-4를 파인튜닝하려고 했는데, 최소 몇십만 원대 이상 들어갈 것 같아서 다른 방법을 생각 중입니다. 오픈소스 모델(라마,미스트럴 같은)을 직접 로컬에서 파인튜닝하는 게 낫지 않을까 하는데, 인프라 비용과 시간을 생각하면 애매하거든요. 특히 정말 고품질의 결과가 필요할 때는 더더욱요.
혹시 실무에서 이런 상황 어떻게 해결하세요? RAG로 충분한 경우도 있고, 그렇지 않은 경우도 있을 것 같은데 기준이 뭐라고 봐야 할까요. 아니면 처음부터 파인튜닝을 염두에 두고 프로젝트 예산을 설계하시는 건지 궁금합니다.
혼자 생각해보니 좋은 질의응답 데이터셋이 작으면 RAG로도 충분할 수 있겠다는 생각도 들고, 데이터가 충분히 많으면 파인튜닝 투자가 의미 있을 것 같기도 하네요. 근데 그 경계가 어디인지는 확실하지 않아서요. 혹시 비슷한 고민하셨던 분 있으면 경험담 좀 나눠주세요.
처음엔 GPT-4를 파인튜닝하려고 했는데, 최소 몇십만 원대 이상 들어갈 것 같아서 다른 방법을 생각 중입니다. 오픈소스 모델(라마,미스트럴 같은)을 직접 로컬에서 파인튜닝하는 게 낫지 않을까 하는데, 인프라 비용과 시간을 생각하면 애매하거든요. 특히 정말 고품질의 결과가 필요할 때는 더더욱요.
혹시 실무에서 이런 상황 어떻게 해결하세요? RAG로 충분한 경우도 있고, 그렇지 않은 경우도 있을 것 같은데 기준이 뭐라고 봐야 할까요. 아니면 처음부터 파인튜닝을 염두에 두고 프로젝트 예산을 설계하시는 건지 궁금합니다.
혼자 생각해보니 좋은 질의응답 데이터셋이 작으면 RAG로도 충분할 수 있겠다는 생각도 들고, 데이터가 충분히 많으면 파인튜닝 투자가 의미 있을 것 같기도 하네요. 근데 그 경계가 어디인지는 확실하지 않아서요. 혹시 비슷한 고민하셨던 분 있으면 경험담 좀 나눠주세요.
추천 14 비추천 0
- 이전글최근에 LLM fine-tuning 해보신 분 계신가요?26.03.21
- 다음글RAG 시스템에서 context window 크기 늘렸더니 성능이 떨어졌어요26.03.20
댓글
10
댓글목록
저는 일단 RAG로 시작해서 부족한 부분만 파인튜닝하는 방식으로 하고 있어요. 처음부터 파인튜닝하기엔 비용 대비 효과를 검증하기 어렵더라고요.
데이터 품질이 좋으면 RAG만으로도 꽤 잘 작동하는데, 특정 스타일이나 도메인 특화 응답이 필요할 때만 그때 라마나 미스트럴로 LoRA 파인튜닝을 했어요. 풀 파인튜닝보다 훨씬 저렴하거든요.
경계라면 보통 검증 데이터셋으로 RAG 성능을 평가해보고, 정확도가 70% 이하면 파인튜닝을 진지하게 고려하는 정도더라고요. 그리고 파인튜닝 데이터가 최소 500개는 있어
데이터 품질이 좋으면 RAG만으로도 꽤 잘 작동하는데, 특정 스타일이나 도메인 특화 응답이 필요할 때만 그때 라마나 미스트럴로 LoRA 파인튜닝을 했어요. 풀 파인튜닝보다 훨씬 저렴하거든요.
경계라면 보통 검증 데이터셋으로 RAG 성능을 평가해보고, 정확도가 70% 이하면 파인튜닝을 진지하게 고려하는 정도더라고요. 그리고 파인튜닝 데이터가 최소 500개는 있어
저도 요즘 같은 고민 중이네요. 제 경험상 데이터가 5천 개 미만이면 RAG가 훨씬 효율적이더라고요. 그 이상이면 파인튜닝 고려할 만한 수준이었어요. 그리고 요즘은 Llama 2 같은 오픈소스 모델을 LoRA로 가볍게 조정하는 방식이 괜찮더라고요. 인프라 비용이 생각보다 크지 않아요. 혹은 프롬프트 엔지니어링으로 먼저 얼마나 커버 가능한지 테스트해보고 부족한 부분만 파인튜닝으로 채우는 식으로 하는 게 좋은 것 같습니다.
저도 비슷한 고민 많이 했는데, 결국 데이터 규모가 핵심인 것 같아요. 저희는 고품질 QA 쌍이 500개 이상 있을 때부터 파인튜닝 투자를 생각하기로 결정했습니다. 그 이하면 RAG + 프롬프트 엔지니어링으로 대부분 커버 가능하더라고요.
특히 도메인 특화가 필요한 경우라도 먼저 RAG로 baseline을 만들어보고, 평가 메트릭(BLEU, ROUGE 같은)으로 성능 격차를 정량화한 후 파인튜닝 여부를 판단하는 게 좋습니다. 추측만으로 결정하면 비용을 낭비할 수 있거든요.
비용 문제라면 로컬 파인튜닝도 선택지긴 한데, QLoRA나 Lo
특히 도메인 특화가 필요한 경우라도 먼저 RAG로 baseline을 만들어보고, 평가 메트릭(BLEU, ROUGE 같은)으로 성능 격차를 정량화한 후 파인튜닝 여부를 판단하는 게 좋습니다. 추측만으로 결정하면 비용을 낭비할 수 있거든요.
비용 문제라면 로컬 파인튜닝도 선택지긴 한데, QLoRA나 Lo
저도 비슷한 고민을 했는데, 결국 RAG + 프롬프트 엔지니어링으로 충분한 경우가 대부분이더라고요. 파인튜닝은 정말 특수한 도메인 언어나 매우 구체적인 출력 형식이 필요할 때만 고려할 만한 것 같습니다. 비용 대비 효과를 생각하면 고품질 데이터셋 준비에 시간을 더 투자하는 게 현실적이라고 봐요.
저도 지금 같은 고민이네요 ㅠㅠ
저도 비슷한 고민을 했는데, 결국 RAG로 먼저 시작하는 걸 추천드려요. 데이터셋이 몇천 개 수준이면 RAG만으로도 꽤 커버되더라고요. 파인튜닝은 정말 특정 스타일이나 추론 방식을 바꿔야 할 때만 의미 있다고 봅니다.
저희 팀은 결국 LoRA 방식으로 로컬에서 라마2를 가볍게 파인튜닝했는데, 초기 세팅만 해놓으면 반복 실험할 때 비용이 훨씬 낮더라고요. 다만 GPU 서버 임차료가 월 50만원대 드니까 그것도 고려해야 합니다. 프로젝트 초기부터 RAG vs 파인튜닝 ROI를 계산해서 예산 설계하는 게 현
저희 팀은 결국 LoRA 방식으로 로컬에서 라마2를 가볍게 파인튜닝했는데, 초기 세팅만 해놓으면 반복 실험할 때 비용이 훨씬 낮더라고요. 다만 GPU 서버 임차료가 월 50만원대 드니까 그것도 고려해야 합니다. 프로젝트 초기부터 RAG vs 파인튜닝 ROI를 계산해서 예산 설계하는 게 현
저도 똑같은 고민 중이었어요 ㅠㅠ RAG로 먼저 시작해보는 게 답인 것 같아요
RAG와 파인튜닝의 경계는 결국 도메인 특이성이라고 봐요. 저는 보통 먼저 RAG로 프로토타입을 빨리 만들어보고, 평가 지표(정확도, 할루시네이션)를 측정해서 판단하더라고요.
RAG로 70~80% 이상이 나오면 그걸로 충분한 경우가 많고, 그 아래면 파인튜닝을 고려하는데, 그때도 바로 GPT-4 파인튜닝 할 생각은 하지 말고요. 저는 처음엔 라마 2 7B 같은 걸 로컬이나 온프레미스에서 LoRA로 돌려봐요. 인프라 비용도 저렴하고 실험도 빠르거든요.
고품질이 정말 필요한 경우만 API 파인튜닝으로 가는데, 그전에
RAG로 70~80% 이상이 나오면 그걸로 충분한 경우가 많고, 그 아래면 파인튜닝을 고려하는데, 그때도 바로 GPT-4 파인튜닝 할 생각은 하지 말고요. 저는 처음엔 라마 2 7B 같은 걸 로컬이나 온프레미스에서 LoRA로 돌려봐요. 인프라 비용도 저렴하고 실험도 빠르거든요.
고품질이 정말 필요한 경우만 API 파인튜닝으로 가는데, 그전에
저도 같은 고민을 했는데, 결국 RAG로 먼저 시작하고 부족할 때만 파인튜닝하는 걸로 정했어요. 고품질 데이터셋이 수천 개 이상 있을 때 파인튜닝 가치가 생긴다고 봐요. 그 이하면 프롬프트 엔지니어링과 RAG 조합이 비용 대비 효과가 훨씬 낫더라고요. 혹시 벡터DB는 고려하셨나요?
댓글을 작성하려면 로그인이 필요합니다.