⚡ 3줄 요약
- 한 사례에서 fine-tuning은 말투를 90%까지 맞췄지만, 사실 정확도를 50%로 떨어뜨렸다.
- RAG는 근거를, fine-tuning은 말투를 맡긴다 — 역할을 섞자 사실 정확도가 73%로 돌아왔다.
- 정확도를 가르는 건 모델 크기가 아니라 질문에 필요한 자료를 정확히 고르는 검색 품질이다.
고객지원 챗봇이 틀린 답을 내면, 대부분 “모델이 작아서” 또는 “학습을 더 시켜야 해서”라고 생각한다. 그런데 한 실무 사례가 정반대의 그림을 보여준다. 회사 말투에 맞춰 모델을 fine-tuning했더니 말투는 약 90%까지 자연스러워졌는데, 정작 사실 정확도는 약 50%로 떨어졌다. 문제는 모델의 지능이 아니었다. 답변의 근거를 어디서 가져오느냐, 그 자료를 얼마나 정확히 골라 넣느냐였다.
고객지원 AI에 fine-tuning으로 지식을 넣으려 하면 실패한다
기업용 고객지원은 제품 정보만 맞으면 끝이 아니다. 민감 자료를 흘리지 않아야 하고, 응답이 늦으면 안 되고, 회사가 정한 말투와 절차까지 지켜야 한다. 요구가 이렇게 여러 갈래인데 이 전부를 모델 하나에 밀어넣으려는 순간 균형이 무너진다.
특히 “회사 지식을 모델에 학습시키자”는 접근이 함정이다. LLM은 한 번에 읽는 정보량에 한계가 있고, 긴 입력의 중간에 있는 내용을 덜 활용하는 경향(primacy-recency bias)이 있다. 자료의 앞뒤는 잘 보지만 가운데는 흘린다. 게다가 근거가 없을 때 모델은 답을 멈추는 대신 그럴듯한 거짓을 자신 있게 지어낸다(hallucination). 고객지원에서 이런 답변은 신뢰와 비용에 직접 꽂힌다.
검색은 ‘무엇을 아는가’, fine-tuning은 ‘어떻게 말하는가’
해법은 역할을 쪼개는 것이다. 두 도구는 애초에 서로 다른 문제를 푼다. 근거를 검색으로 대는 RAG는 노트북 한 대로도 구현할 만큼 문턱이 낮아졌다.
| 도구 | 맡는 일 | 못 하는 일 |
|---|---|---|
| RAG(검색) | 질문에 필요한 최신 근거·정책을 찾아 넣는다 | 회사 말투·형식은 못 맞춘다 |
| fine-tuning | 말투·답변 형식·절차 설명 방식을 조정한다 | 최신 사실 지식을 안정적으로 못 담는다 |
실제 구성은 단순하다. 사내 Q&A, 제품 설명서, 기술 문서, 정책 자료를 검색 가능한 자료실로 만든다. 질문이 들어오면 검색이 관련성 높은 자료 일부를 골라 오고, 모델은 그 자료만 근거로 답을 만든다. 자료 전체가 아니라 질문에 필요한 조각만 넣는 게 핵심이다. 말투는 fine-tuning으로 따로 맞춘다.
⚠️ 가장 흔한 착각 — fine-tuning은 지식 주입이 아니다
이 사례에서 fine-tuning에 쓴 약 1,000개의 전문가 Q&A는 사실 지식을 가르치려는 게 아니라 말투·형식·절차 감각을 익히게 하려는 것이었다. 그런데도 fine-tuning만으로 밀어붙이자 사실 정확도가 50%까지 무너졌다. 모델을 학습시켜 지식을 넣겠다는 발상 자체가 정확도를 갉아먹는다.
자료를 많이 넣을수록 정확해진다 — 는 거짓이다
“근거를 넉넉히 넣으면 안전하겠지”라는 생각도 틀렸다. 검색 자료를 과하게 넣으면 입력이 길어지고, 응답이 느려지고, 관련 없는 자료에 정작 중요한 근거가 묻힌다. 반대로 너무 적게 넣으면 근거가 부족해 거짓 답변 위험이 커진다.
그래서 검색 품질은 자료의 개수로 판단하면 안 된다. 질문에 필요한 자료를 얼마나 정확히 골랐는지가 전부다. 입력창을 키우는 것만으로 답이 좋아지지 않는다.
더 뼈아픈 사실은 따로 있다. 이 사례에서 거의 100% 정확한 검색 자료를 받은 작은 언어 모델의 최종 출력 정확도가 약 70%에 그쳤다. 근거가 완벽해도 답변 생성 단계에서 오류가 남는다는 뜻이다. 그래서 검색 품질과 최종 답변 품질은 반드시 따로 측정해야 한다. 하나로 뭉뚱그리면 어디서 새는지 영영 못 찾는다.
수치로 보는 하이브리드 — 약점을 나누자 정확도가 돌아왔다
이 사례의 핵심은 마지막 숫자에 있다. fine-tuning만 썼을 때 50%였던 사실 정확도가, RAG로 근거를 맡기고 fine-tuning은 말투만 담당하게 하자 약 73%로 회복됐다. 말투 정확도도 무리한 90%가 아니라 약 75%로 현실적인 균형을 찾았다.
| 구성 | 말투 | 사실 정확도 |
|---|---|---|
| fine-tuning만 | 약 90% | 약 50% |
| RAG만 (작은 모델·근거 거의 100%) | 불안정 | 약 70% |
| 하이브리드 (RAG + fine-tuning) | 약 75% | 약 73% |
참고로 이 조정에는 LoRA가 쓰였다. 모델 전체가 아니라 일부 조정 행렬만 학습해, 기존 지식을 대부분 유지하면서 fine-tuning 비용(GPU 메모리)을 줄이는 방법이다. 다만 LoRA를 쓴다고 품질 문제가 자동으로 풀리지는 않는다. 어떤 Q&A를 조정 자료로 넣었는지, 사실 근거를 어디서 가져오는지가 여전히 결과를 가른다. 좁은 업무라면 작은 전용 모델에 RAG를 붙여 정확도를 끌어올린 접근도 같은 원리다.
⚠️ 이 수치를 그대로 믿지 마라
90%·50%·70%·73%·75%는 모두 특정 챗봇 한 사례의 값이다. 모든 모델·자료·업무에 그대로 적용되는 성능 기준이 아니다. 여기서 가져갈 건 정확한 숫자가 아니라 패턴이다 — fine-tuning으로 지식을 넣으면 사실이 무너지고, 역할을 나누면 회복된다는 것.
🎯 FEEDON의 선택 — 우리라면 이렇게 한다
고객지원 AI를 검토한다면 모델 크기 비교부터 시작하지 않는다. 더 큰 모델, 더 많은 fine-tuning은 대개 오답이다. 먼저 검색 자료실의 최신성과 권한을 점검하고, 검색이 질문에 맞는 자료를 정확히 골라 오는지부터 본다.
그다음 검색 품질과 최종 답변 품질을 따로 측정하고, 말투 점수와 사실 점수를 절대 합치지 않는다. 말투가 자연스러워도 사실이 틀릴 수 있고, 그 반대도 가능하다. 정확한 고객지원 AI는 좋은 모델 하나가 아니라, 근거를 고르는 검색 설계에서 출발한다.
도입 전 체크리스트
- 검색 자료의 최신성·권한 확인 — 사용자가 볼 수 없는 자료가 검색 결과에 섞이지 않는가
- 검색 결과 개수를 고정하지 말고, 많이/적게 각각의 답변 품질·응답 속도를 비교
- 검색 품질과 최종 답변 품질을 별도 지표로 측정
- 말투와 사실성을 하나의 점수로 합치지 않기
- 형식이 중요한 업무면 실제 질문 + 전문가 답변을 평가 자료로 준비 (절차 누락·구조 붕괴 확인)
점검 순서
🛠️ 검색 설계부터 손보기
- 검색 자료실의 최신성과 권한부터 확인한다 — 사용자가 볼 수 없는 자료가 검색 결과에 섞이지 않는지 본다.
- 검색 결과 개수를 고정하지 말고 많이 넣을 때와 적게 넣을 때의 답변 품질·응답 속도를 각각 비교한다.
- 검색 품질과 최종 답변 품질을 별도 지표로 나눠 측정한다 — 하나로 뭉치지 않는다.
- 말투 점수와 사실 점수를 절대 하나로 합치지 않는다.
- 실제 질문과 전문가 답변을 평가 자료로 준비해 절차 누락·구조 붕괴를 점검한다.
출처: KDnuggets 「Beyond Bots: Rethinking AI Support with a Hybrid AI Architecture」 · 본문 수치는 특정 챗봇 사례의 값으로 일반 성능 기준이 아님
이 글은 FEEDON이 공개 1차 자료를 바탕으로 작성·검증했습니다.
