저도 비슷한 상황 겪었는데 결국 RAG로 시작하는 게 맞더라고요. 파인튜닝은 정말 비싸고 유지보수도 힘들어요. 상담 길어도 RAG에서 관련 문서 잘 뽑아내면 충분합니다. 처음엔 간단하게 시작해서 필요하면 나중에 추가하는 게 정신 건강에 좋아요 ㅋㅋ
오류해결
LLM 파인튜닝 vs RAG, 실제로는 어느 쪽이 낫나요?
회사에서 고객 상담용 챗봇을 만들고 있는데 요구사항이 자꾸 바뀌면서 고민이 많네요. 처음엔 GPT-4 API를 그냥 쓰려다가, 우리 회사의 특정 도메인 지식을 더 잘 이해시키려면 파인튜닝을 해야 하는 거 아니냐는 의견이 나왔거든요.
근데 알아보니 파인튜닝도 결국 비용이 만만치 않고, 최근 트렌드는 RAG가 더 나은 방법이라고 하더라고요. 벡터 DB에 우리 문서들을 다 넣고 쿼리할 때마다 관련 정보를 가져와서 프롬프트에 포함시키는 방식 말이에요. 기술적으로는 이해가 되는데 실무에선 어떨까 싶어서요.
우리 경우엔 상담 내용이 꽤 길고, 고객마다 상황이 다르게 들어오는데 RAG로 충분할까요? 파인튜닝이 필요한 케이스가 따로 있는 건지도 궁금하고요. 둘을 조합해서 쓰는 경우도 있던데 그러면 관리 포인트가 너무 많아질 것 같기도 하네요.
지금 우리 팀은 기술 스택이 Python, FastAPI, OpenAI API 정도로 심플한데, 너무 복잡한 솔루션은 피하고 싶어요. 실제로 비슷한 프로젝트 진행하신 분들이 있으면 어떻게 접근하셨는지 들어보고 싶습니다. 특히 ROI 관점에서 어떤 선택이 맞을까요?
근데 알아보니 파인튜닝도 결국 비용이 만만치 않고, 최근 트렌드는 RAG가 더 나은 방법이라고 하더라고요. 벡터 DB에 우리 문서들을 다 넣고 쿼리할 때마다 관련 정보를 가져와서 프롬프트에 포함시키는 방식 말이에요. 기술적으로는 이해가 되는데 실무에선 어떨까 싶어서요.
우리 경우엔 상담 내용이 꽤 길고, 고객마다 상황이 다르게 들어오는데 RAG로 충분할까요? 파인튜닝이 필요한 케이스가 따로 있는 건지도 궁금하고요. 둘을 조합해서 쓰는 경우도 있던데 그러면 관리 포인트가 너무 많아질 것 같기도 하네요.
지금 우리 팀은 기술 스택이 Python, FastAPI, OpenAI API 정도로 심플한데, 너무 복잡한 솔루션은 피하고 싶어요. 실제로 비슷한 프로젝트 진행하신 분들이 있으면 어떻게 접근하셨는지 들어보고 싶습니다. 특히 ROI 관점에서 어떤 선택이 맞을까요?
추천 13 비추천 0
- 이전글Llama 2 로컬에서 돌려봤는데 생각보다 괜찮네요26.05.29
- 다음글LLM Fine-tuning할 때 LoRA vs Full parameter, 실제로 성능 차이 많이 나나요?26.05.23
댓글
3
댓글목록
RAG로 시작하는 게 맞을 것 같아요. 파인튜닝은 진짜 필요할 때만이라고 봐요.
저도 비슷한 상황 겪었는데 RAG로 시작하는 게 정답인 것 같아요. 파인튜닝은 진짜 비용도 많이 들고 요구사항이 자주 바뀌면 계속 재학습해야 하니까 오버헤드가 심하거든요.
상담 내용이 길다고 하셨는데 RAG면 충분합니다. 벡터 DB에 회사 문서 잘 정리해서 넣고, retrieval 부분만 신경 써도 괜찮아요. 요구사항 바뀔 때마다 문서 업데이트만 하면 되니까 훨씬 유연하죠.
파인튜닝이 필요한 건 정말 특수한 경우인데, 모델이 특정 답변 형식을 배워야 할 때 정도예요. 상담 챗봇이면 그런 케이스는 거의 없을 것
상담 내용이 길다고 하셨는데 RAG면 충분합니다. 벡터 DB에 회사 문서 잘 정리해서 넣고, retrieval 부분만 신경 써도 괜찮아요. 요구사항 바뀔 때마다 문서 업데이트만 하면 되니까 훨씬 유연하죠.
파인튜닝이 필요한 건 정말 특수한 경우인데, 모델이 특정 답변 형식을 배워야 할 때 정도예요. 상담 챗봇이면 그런 케이스는 거의 없을 것
댓글을 작성하려면 로그인이 필요합니다.