Enterprise 환경에서 RAG 파이프라인 구축하기
범용 LLM 챗봇이 아닌 회사 내부 지식을 안전하게 활용하는 RAG 시스템을 어떻게 운영 환경까지 가져갔는지, 그 과정에서 부딪힌 5가지 문제와 우리의 답을 정리했습니다.
· NexMind ML Team
왜 RAG인가
범용 LLM 챗봇은 모르는 회사 내부 지식이 너무 많습니다. 정관·내부 매뉴얼·과거 프로젝트 산출물·고객별 컨피그까지 — 이것들을 학습시키는 fine-tuning은 비용·통제 양쪽에서 부담입니다. NexMind가 자체 SaaS와 고객 SI 양쪽에서 채택한 답은 RAG(Retrieval-Augmented Generation)입니다.
운영에서 발견한 5가지 문제
1. 청크 크기 = 하이퍼파라미터
청크가 너무 크면 노이즈가 답변에 섞이고, 너무 작으면 컨텍스트가 깨집니다. 우리는 문서 종류별로 청크 크기를 다르게 가져갑니다 — 매뉴얼 800 토큰, 회의록 300 토큰, 코드 600 토큰.
2. Embedding 모델은 한국어 + 도메인이 함께 잡혀야 한다
범용 multilingual 모델은 일반 한국어는 잡지만 "MES 작업지시서", "ERP 회계전표" 같은 업무 용어 유사도가 무너집니다. 도메인 키워드 사전을 retrieval 직전에 합성하는 방식으로 우회했습니다.
3. Citation은 답변보다 중요하다
사용자는 LLM 답변을 100% 믿지 않습니다. 어디서 온 답인지(원문 문장 + 페이지) 표시되지 않으면 채택률이 30%로 떨어집니다.
4. Hallucination guard는 prompt가 아니라 retrieval에서
"근거 없으면 모른다고 답해" 프롬프트는 절반만 작동합니다. 점수가 낮은 chunk만 회수되면 retrieval 단계에서 차단해야 합니다.
5. 비용 곡선은 query×chunk×model로 폭발한다
주력 모델은 GPT-4 / Claude로, 1차 retrieval과 reranking은 작은 모델로 분리하는 cascading 구조가 필수입니다.
다음 글
- Vector DB 선택: pgvector vs. 전용 DB의 운영 트레이드오프
- Eval 자동화: 답변 품질을 PR마다 측정하기