사내 규정/매뉴얼 문서로 QA 챗봇을 만들려고 합니다. 근데 파인튜닝을 해야 하는지 RAG로 가야 하는지 판단이 안 서요. 주변에선 "요즘은 파인튜닝이 정석"이라는 사람도 있고 "그냥 RAG면 된다"는 사람도 있어서 더 헷갈립니다.
상황은 이래요. 문서가 꽤 많고, 내용이 대략 한 달에 한 번씩 개정됩니다. 답변은 반드시 실제 문서 내용에 근거해야 하고, 지어내면 안 되는 성격이에요. 그리고 가능하면 회사 톤에 맞는 정중한 말투로 답했으면 합니다.
파인튜닝을 하면 문서 내용을 모델이 "외워서" 더 잘 답할 것 같은 기대가 있는데, 개정될 때마다 다시 학습시켜야 하는 것도 부담이고요. 두 방식의 판단 기준을 알고 싶습니다.
댓글 3
핵심 오해가 하나 있는데, 파인튜닝은 지식을 주입하는 도구가 아니에요. 파인튜닝은 모델의 말투, 출력 형식, 행동 패턴을 잡는 데 쓰는 거지, 사실을 외우게 하는 용도가 아닙니다. 문서 내용을 파인튜닝으로 구워 넣으면 개정될 때마다 낡아버리고, 재학습 비용이 매번 들고, 게다가 그렇게 해도 환각이 사라지지 않아요. 모델이 외운 걸 자신있게 틀리게 뱉는 건 그대로입니다.
반대로 지금 요구사항을 보면 RAG에 딱 맞아요. 답변이 실제 문서에 근거해야 하고(→ 검색해서 근거를 컨텍스트로 넣으면 됨), 한 달에 한 번 개정되고(→ 벡터DB만 다시 인덱싱하면 끝, 재학습 불필요), 지어내면 안 되고(→ 검색된 근거만 쓰라고 프롬프트로 강제). 개정 대응이 인덱스 갱신 한 번으로 끝나는 게 결정적입니다.
말투는 RAG 안에서 system 프롬프트랑 few-shot으로 충분히 잡혀요. 그걸로 정중한 톤 나옵니다. 일단 RAG로 붙이고, 나중에 말투 일관성이나 프롬프트 길이가 진짜 병목이 되면 그때 파인튜닝을 얹는 순서로 가세요. 시작을 파인튜닝으로 하는 건 거의 항상 과합니다.
파인튜닝이 정당화되는 건 조건이 붙었을 때예요. few-shot 예시가 너무 많아져서 프롬프트 비용/지연이 실제로 병목이 되고, 그 예시를 매 요청 실어 나르는 게 아까워지는 시점. 그리고 원하는 말투/형식 샘플을 수백 개 단위로 확보할 수 있을 때. 이 두 개가 만족되면 그때 파인튜닝으로 그 패턴을 모델에 구워서 프롬프트를 짧게 줄이는 게 이득입니다.
비용이 걱정이면 순서를 이렇게 잡으세요. 먼저 few-shot으로 톤을 맞춰보고, 프롬프트 캐싱으로 그 고정 예시 부분을 캐시로 돌려서 비용을 눌러요. 그래도 예시가 계속 불어나서 감당이 안 되면 그때 파인튜닝을 검토. 대부분은 앞 두 단계에서 끝납니다.