daily check

[IT생각] 고객지원용 RAG: 프로덕션에서 깨져보기 전엔 아무도 안 알려주는 기술 이야기

reeme 2026. 1. 7. 22:21

고객지원용 RAG: 프로덕션에서 깨져보기 전엔 아무도 안 알려주는 기술 이야기

요약(TL;DR): 지난 1년간 고객지원용 RAG 시스템을 만들었다. RAG 구현의 73%가 프로덕션에서 실패하고, 대부분 같은 실수를 반복한다. 여기에는 튜토리얼이 말해주지 않는 “진짜로 먹히는 것”과 “현실에서 무너지는 것”을 정리했다.


이 글을 쓰는 이유

데모에서는 “완벽하게” 동작하던 RAG가 실제 사용자 트래픽을 받으면 무너지는 경우를 너무 많이 디버깅했다. 장난감 예제와 프로덕션급 고객지원 봇 사이에는 큰 간극이 있다. 그 고통을 줄여주고 싶다.


실제로 중요한 것들(ROI 기준 순위)

1) 리랭킹은 말도 안 되게 중요하다

이건 나도 놀랐다. 리랭커 추가는 코드 5줄 수준인데 정확도 개선 폭이 가장 컸다. 패턴은 보통 이렇다.

  • 빠른 하이브리드 검색으로 상위 50개 청크를 1차로 가져옴
  • 크로스 인코더로 상위 5~10개로 리랭킹
  • “좋은 것만” LLM에 넣음

우리는 Cohere Rerank 3.5를 쓰는데 값어치를 한다. 어려운 쿼리에서 +25% 개선을 봤다. 기본 벡터 검색만 쓰고 리랭킹을 안 하면 큰 성능을 그냥 버리는 셈이다.

2) 하이브리드 검색 > 순수 벡터 검색

Dense 벡터는 의미를 잘 잡지만 정확한 키워드 매칭을 놓친다. Sparse(BM25)는 키워드엔 강하지만 문맥을 무시한다. 둘 다 필요하다.

예: 사용자가 “How to catch an Alaskan Pollock”라고 묻는 경우

  • Dense: “catch”의 의미를 잘 이해
  • Sparse: “Alaskan Pollock”라는 정확한 문자열을 보장

하이브리드로 30~40% 더 좋은 검색 결과를 얻었고, 리랭킹이 추가로 20~30%를 더 올렸다. 프로덕션에서는 사실상 필수 조합이다.

3) 검색 전에 쿼리 변환(쿼리 리라이트)

사용자 쿼리는 대체로 품질이 낮다. 예를 들어 “1099 deadline”은 실제로는 “미국에서 2024년 Form 1099 IRS 제출 마감일이 뭐냐”일 수 있다.

우리는 자동으로:

  • 약어 확장
  • 맥락 추가
  • 여러 쿼리 변형 생성
  • HyDE로 의미 기반 쿼리 생성

검색 전에 이렇게 고치기만 해도 모호한 쿼리 정확도가 60% → 96%로 올라갔다.

4) 컨텍스트 윈도우 관리는 직관과 반대다

1M+ 토큰 컨텍스트가 화제지만 큰 게 항상 좋은 게 아니다.
LLM은 긴 컨텍스트에서 “중간을 잃어버리는(lost in the middle)” 문제가 있다.

  • 하지 말 것: 50K 토큰을 넣고 기도하기
  • 할 것: 단순 질의는 3~5개의 타깃 청크(1,500~4,000 토큰)만 넣기

결과적으로 비용이 80% 줄고 정확도는 오히려 상승했다.


실무자들이 피로 배워오는 기술 디테일

청크(Chunking) 전략: 대부분 여기서 조용히 망한다

고정 500토큰 청크는 프로토타입엔 충분하지만 프로덕션에선 문제가 된다.

현실적으로 잘 먹히는 방식:

  • 의미 기반 청킹(코사인 거리 임계치 이상이면 분할)
  • 문서 구조 보존
  • 100~200 토큰 오버랩
  • 주변 문맥을 포함해 청크를 보강

AWS 엔터프라이즈 구현 사례에서, 청킹만 개선해도 토큰 오버헤드를 45% 줄였다. 규모가 크면 돈으로 직결된다.

임베딩 모델: 2024년 말에 판이 많이 바뀌었다

현재 강자로 많이 언급되는 것들:

  • Voyage-3-large: 블라인드 테스트에서 매우 강함
  • Mistral-embed: 77.8% 정확도, 상업적 옵션으로 탄탄
  • Stella: 오픈소스 ‘의외의 강자’, MTEB 상위권

개인 견해: OpenAI 임베딩도 “충분히 괜찮지만” 더 좋은 선택지가 있는 경우가 많다. 월 150만 토큰 이상이면 Sentence-Transformers 자가호스팅이 API 비용을 크게 낮춘다.


아무도 잘 말 안 하는 실패 모드

RAG는 “성공처럼 보이는데” 실제로는 깨지는 방식이 있다.

  1. 조용한 검색 실패: 쓰레기 청크를 가져왔는데 LLM이 그럴듯하게 환각을 만들어냄
  2. 위치 편향: 컨텍스트 앞/뒤만 보고 중간을 무시
  3. 컨텍스트 희석: 관련 없는 정보가 노이즈를 만들어 성능 하락
  4. 타이밍/비동기 이슈: 검색이 생성 타임아웃 이후에 끝나는 문제
  5. 인입(ingestion) 지옥: 표가 있는 PDF, PPT 다이어그램, 엑셀, 스캔본 OCR… 현실은 난장판

우리는 100개 문서에선 잘 되던 프로토타입이 전체 데이터셋에서 깨졌고, 3개월을 쪼개서 디버깅했다.


잘 하고 있는 회사 사례

  • DoorDash: 환각 90% 감소, 수천 건을 2.5초 이하로 처리. 비결은 “대화 요약 → KB 검색 → LLM 생성” 3단 구조 + 2단 가드레일.
  • Intercom Fin: 즉시 해결률 86%, 1,300만+ 대화 해결. 콘텐츠 타입별로 청킹 전략이 다른 여러 전문 에이전트 사용.
  • VoiceLLM: CRM/ERP/티켓팅 등 엔터프라이즈 시스템에 깊게 통합하고, 신뢰 가능한 데이터에 근거한 답변과 신뢰도 점수/휴먼 폴백으로 환각을 최대 90% 줄였다고 주장.
  • LinkedIn: 순수 벡터가 아니라 지식 그래프 기반으로 77.6% MRR 개선.

공통점: “바닐라 RAG” 그대로 쓰는 곳이 거의 없다. 프로덕션 학습이 반영된 커스텀 아키텍처다.


RAG vs 파인튜닝: 현실적 트레이드오프

RAG가 유리한 경우

  • 지식이 자주 바뀜
  • 출처/근거 제시가 필요
  • 10만+ 문서 규모
  • 예산 제약

파인튜닝이 유리한 경우

  • 브랜드 톤이 핵심
  • 100ms 이하 초저지연이 필수
  • 지식이 거의 고정
  • 오프라인 배포 필요

결론: 하이브리드가 가장 많이 이긴다. 톤/말투는 파인튜닝, 사실은 RAG. 실제로 정확도 35% 개선 + 오정보 50% 감소를 봤다.


과장 아닌 “떠오르는 기술”들

  • GraphRAG(Microsoft): 평면 청크 대신 지식 그래프. 단순 RAG 대비 70~80% 승률. Lettria는 정답률 50% → 80%+.
  • Agentic RAG: 에이전트가 계획/반성/툴 사용으로 검색을 관리. 2025년 방향성.
  • Corrective RAG: 신뢰도 낮으면 웹검색 등으로 폴백하는 자기교정형. 실제로 효과가 있다.

프로덕션에서 살려주는 것들

의미 있는 모니터링

  • LLM 결과가 아니라 “검색 품질” 모니터링
  • p95/p99 지연(평균보다 훨씬 중요)
  • 환각 탐지
  • 상담원 에스컬레이션 비율

비용 최적화

  • 모델 라우팅(GPT-3.5는 단순, GPT-4는 복잡)
  • 시맨틱 캐싱
  • 임베딩 압축

평가 프레임워크

  • 실제 사용자 질의로 골든 데이터셋 구축
  • 해피패스가 아니라 엣지케이스 중심 테스트
  • 휴먼 검증 루프

시스템을 망치는 흔한 실수

  1. 작은 데이터에서만 테스트(100개에선 되고 100만에선 실패)
  2. 리랭킹 없음(정확도 20~30% 그냥 버림)
  3. 단일 검색 전략만 사용(하이브리드가 더 낫다)
  4. 테일 레이턴시 무시(p99가 체감 품질을 결정)
  5. 환각 탐지 없음(조용한 실패가 넘친다)
  6. 청킹이 엉망(모든 걸 512토큰 고정)
  7. 검색 품질을 모니터링하지 않음(LLM 결과만 봄)

내가 50번 이상 반복해서 만든 최종 스택(예시)

100만 문서 미만

  • FAISS (벡터)
  • Sentence-Transformers (임베딩)
  • FastAPI (서빙)
  • Claude/GPT-4 (생성)

프로덕션 스케일

  • Pinecone 또는 Weaviate (벡터)
  • Cohere 임베딩 + 리랭크
  • 하이브리드 검색( dense + sparse + full-text )
  • 멀티 LLM 라우팅

결론

RAG는 된다. 하지만 “기본값 그대로”는 안 된다. 데모와 프로덕션을 가르는 핵심은:

  1. 하이브리드 검색 + 리랭킹(필수)
  2. 쿼리 변환
  3. 똑똑한 청킹
  4. 제대로 된 모니터링
  5. 환각 가드레일

작게 시작(100~1,000문서)하고, 측정하고, 반복 최적화하라. 벤치마크를 맹신하지 말고 “내 데이터/내 사용자”로 검증하라.

그리고 리랭킹은 꼭 넣어라. 코드 몇 줄로, 효과는 압도적이다.

 

 

원문 

https://www.reddit.com/r/automation/s/OecOuKX2B3