RAG 챗봇을 평가해 보았는데 가장 비싼 모델이 최악의 성능을 보였습니다. 실제로 유의미한 변화를 이끌어낸 요소들에 대한 노트.
요약
고객 지원용 RAG 챗봇의 성능 평가를 진행한 결과, 단순히 비싼 모델이 최고의 성능을 보장하지 않으며, 실제 유의미한 개선은 검색(Retrieval) 단계와 데이터 전처리 과정에서 발생했습니다. 핵심 교훈으로는 LLM의 응답 품질보다 먼저 검색된 컨텍스트 자체를 면밀히 분석해야 하며, 휴리스틱 평가기 대신 LLM judge를 활용하는 것이 효과적입니다. 또한, 청크 중복 제거 로직을 추가하여 노이즈를 줄이고, 모델 스윕(model sweep)을 통해 비용 대비 성능이 우수한 최적의 모델 조합을 찾는 것이 중요합니다. 궁극적으로는 엔드투엔드 품질과 비용 모두에서 큰 개선을 달성할 수 있었습니다.
핵심 포인트
- LLM 응답 문제로 오인하기 전에, 검색된 컨텍스트(context)가 충분한지 반드시 로그를 확인해야 합니다.
- 단순 키워드 매칭 같은 휴리스틱 평가기보다 LLM judge를 사용하여 관련성, 정확성 등을 다각도로 평가하는 것이 더 신뢰성이 높습니다.
- 컨텍스트 윈도우 내의 청크 중복을 제거하는 전처리 과정이 모델 환각(hallucination) 방지 및 성능 향상에 매우 효과적입니다.
- 모델 스윕(model sweep)을 통해 다양한 모델들을 비교하고, 비용 효율성과 성능 간의 최적 지점(Pareto frontier)을 찾아야 합니다.
- 정확성(Accuracy)과 유용성(Helpfulness) 사이에는 상충 관계가 존재하므로, 봇의 목적에 맞게 설정을 의식적으로 조정해야 합니다.
저희는 고객 지원용 RAG (Retrieval-Augmented Generation) 봇을 운영하고 있었습니다. 표준적인 설정은 ChromaDB, 시스템 프롬프트(system prompt), 그리고 생성을 수행하는 LLM (Large Language Model)이었습니다. 하지만 아무도 응답 품질을 실제로 측정해 본 적이 없었습니다.
평가라는 명목하에, 저는 그저 키워드 매칭 스크립트를 사용하여 점수처럼 보이지만 아무런 의미도 없는 숫자들을 만들어내고 있었을 뿐입니다.
저는 이를 제대로 해결하기 위해 나섰습니다. 제가 발견한 것들을 공유하고자 하는데, 대부분 제가 예상했던 곳과는 다른 곳에 있었습니다.
1. 검색(Retrieval) 문제가 LLM 문제로 위장합니다.
사용자가 "저희가 무엇을 하는 곳인가요?"라고 물으면, 봇은 "저희 회사의 서비스에 대한 구체적인 정보에 접근할 수 없습니다."라고 답합니다. 모든 사람의 첫 번째 본능은 프롬프트를 수정하거나 모델을 교체하는 것입니다. 틀렸습니다. ChromaDB의 유사도 임계값(similarity threshold)이 0.7로 설정되어 있었습니다 (코사인 거리(cosine distance), 값이 낮을수록 더 유사함, 따라서 이는 실제로 엄격한 설정임). 가벼운 인사말은 해당 필터를 통과할 만큼 어떤 청크(chunk)와도 가까운 임베딩(embedding)을 생성하지 못합니다. 검색된 문서가 0개였습니다. 모델은 솔직하게 아무것도 없다고 보고하고 있었던 것입니다.
교훈: 생성을 탓하기 전에 LLM이 실제로 어떤 컨텍스트(context)를 받았는지 항상 로그를 남기십시오. 검색 결과가 아무것도 없다면, 그 어떤 프롬프트 엔지니어링(prompt engineering)으로도 해결할 수 없습니다.
2. 휴리스틱 평가기(Heuristic evaluators)는 평가기가 없는 것보다 못합니다.
키워드와 출처 참조를 세는 것은 숫자 하나를 제공합니다. 그 숫자는 사용자가 도움을 받고 있는지 여부와 아무런 상관관계가 없습니다. 더 나쁜 것은, 무언가를 측정하고 있다는 가짜 확신을 준다는 점입니다. 저는 결단을 내리고 LLM judge (OpenRouter를 통한 Claude Haiku 4.5)를 사용하여 관련성(relevance), 정확성(accuracy), 유용성(helpfulness), 그리고 종합 점수를 0-10점으로 매기도록 했습니다. 전체 실행당 몇 센트의 비용이 들지만, 저렴한 보험과 같습니다.
3. 모델로 보내기 전에 청크(chunks)의 중복을 제거하십시오.
저희의 대화 중 두 차례에서 컨텍스트 윈도우(context window) 내에 거의 동일한 FAQ 청크 3개가 포함되어 있었습니다. 동일한 소스 파일에서 토큰 중복(token overlap)이 80% 이상인 경우를 확인하는 체크 로직을 추가했습니다. 컨텍스트가 깔끔해지고 토큰 사용량이 줄어들었으며, 에이전트가 한 차례에서 제품 이름을 환각(hallucination)하는 현상이 멈췄습니다 (아마도 노이즈가 사라졌기 때문일 것입니다).
4. 더 엄격한 그라운딩(grounding)은 정확성을 위해 유용성을 희생합니다.
에이전트가 검색된 문서(retrieved docs)에 존재하는 사실만을 말하도록 하는 규칙을 추가했습니다. 정확도(Accuracy)는 올라갔습니다. 하지만 지식 공백(knowledge-gap)이 발생하는 질문에 대해 봇이 추측하는 대신 "문서에 명시되어 있지 않습니다. 고객 지원팀에 문의하세요"라고 말하기 시작하면서 유용성(Helpfulness)은 떨어졌습니다. 사실에 기반한 지원 봇(factual support bot)에게는 이것이 올바른 결정이지만, 의식적으로 설정해야 합니다. 그렇지 않으면 점수는 개선되었다고 나오더라도 사용자는 봇이 더 나빠졌다고 불평할 것입니다.
5. 모델 스윕(model sweep)을 실행하세요. 기본 설정은 대개 틀렸습니다.
저는 Gemini 3.1 Flash Lite Preview를 실행하고 있었습니다. 동일한 평가 하네스(eval harness)를 사용하여 5개의 모델을 스윕했습니다. Gemma 4 26B가 더 높은 점수(7.88 대 7.33)를 기록했으며 세션당 비용은 75% 더 저렴했습니다. Mistral Small 3.2가 근소한 차이로 2위를 차지했습니다. Nova Micro는 가장 저렴했지만, 답변이 너무 간결하여 실행 가능성(actionable)이 부족하다는 이유로 감점을 받았습니다.
핵심은 Gemma가 최고의 모델이라는 것이 아닙니다. 핵심은 여러분의 프로덕션 모델이 아마도 파레토 프런티어(Pareto frontier)에 있지 않을 것이며, 이를 알 수 있는 방법은 오직 측정뿐이라는 점입니다.
엔드 투 엔드(End to end): 품질 6.62에서 7.88로 (+19%), 비용 세션당 $0.002420에서 $0.000509로 (−79%). 두 방향 모두 동일한 실행 결과입니다.
이 모든 평가는 Neo AI Engineer를 사용하여 수행되었습니다. 이 도구는 평가 하네스를 구축하고, 체크포인트가 설정된 실행을 처리하며, 타임아웃 및 컨텍스트 제한(context limit) 문제를 해결하고, 결과를 통합했습니다. 저는 모든 것을 수동으로 검토하고 무엇을 배포할지 결정했습니다.
자신의 시스템에서 이를 재현하고 싶은 분들을 위해 댓글에 전체 과정에 대한 글을 남겨두었습니다. 👇
AI 자동 생성 콘텐츠
본 콘텐츠는 Reddit AI Engineering의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기