[RAG] 단순 RAG를 넘어: 고도화된 하이브리드 검색(Keyword + Semantic) 설계하기

RAG가 유행이라길래 대충 벡터 DB에 때려 넣으셨나요? 솔직히 저도 처음엔 그랬습니다. “문서 넣고, 임베딩하고, 검색해서 LLM에 던지면 끝”인 줄 알았는데요. 실제 서비스에 붙이자마자 정확도는 들쭉날쭉, 운영은 난이도 급상승이더군요.특히 문서를 “기계적으로 잘라서” 넣는 순간부터 문제가 시작됩니다. 문장 하나가 반으로 잘리고, 표/코드/약관 조항이 끊기고, 그 조각을 근거로 모델이 답을 만들면… 결과는 뻔합니다. 검색 품질이 흔들리면 RAG는 곧바로 엉뚱한 말을 합니다. 단순 토큰 분할의 함정: “잘라 넣었더니 잘라 먹습니다”제가 겪었던 케이스 하나 말씀드리겠습니다. 고객센터 환불 정책 문서를 그냥 512 토큰으로 잘라서 벡터 DB에 넣었습니다. 질문은 단순했습니다. “부분 환불 가능한가요?”근데 ..