당신의 RAG 에이전트가 잘못된 청크를 검색하고 있습니다: 우리가 프로덕션에서 해결하는 5가지 실패 모드

지난달 한 고객이 간단한 불만 사항을 가지고 저희에게 연락했습니다: "저희 지원 에이전트가 잘못된 환불 정책을 아주 자신 있게 인용합니다." 모델은 괜찮았습니다. 프롬프트(Prompt)도 괜찮았습니다. 문제는 세 단계 아래, 아무도 데모하지 않는 부분인 검색(Retrieval)에 있었습니다. 에이전트가 잘못된 텍스트 청크(Chunk)를 가져왔고, 그 잘못된 사실을 바탕으로 아주 훌륭하게 추론을 수행한 것이었습니다.

이것이 검색 증강 생성 (RAG, Retrieval-Augmented Generation)에 관한 조용한 진실입니다. 에이전트가 틀린 답을 내놓을 때, 본능적으로 모델을 탓하거나 "프롬프트를 더 강하게 작성"하려고 합니다. 하지만 프로덕션 환경에서 우리가 디버깅하는 잘못된 답변의 대다수는 생성(Generation) 실패가 아니라 검색(Retrieval) 실패입니다. 모델은 지시받은 대로 정확히 수행했습니다. 단지 잘못된 컨텍스트(Context)를 전달받았을 뿐입니다. 여기 우리가 가장 자주 목격하는 다섯 가지 실패 모드와 이를 해결하는 방법이 있습니다.

1. 사실을 반으로 쪼개버리는 청킹 (Chunking)

기본적인 방식은 문서를 고정된 500-토큰(Token) 창으로 자르는 것입니다. 이는 사실이 경계선에 걸쳐 있기 전까지는 작동합니다. 예를 들어, 자격 요건 규칙은 14번 청크에 있고, 이를 무효화하는 예외 사항은 15번 청크에 있는데, 검색기(Retriever)가 14번 청크만 반환하는 경우입니다. 이제 에이전트는 예외 사항에 대한 인지 없이 완벽한 확신을 가지고 규칙을 진술합니다.

해결책: 글자 수가 아니라 구조에 따라 청킹하세요. 제목, 표 행, 조항, 리스트 항목을 기준으로 나누십시오. 사실과 그 주의 사항이 깔끔하게 절단되지 않도록 작은 중첩(Overlap, 10-15%)을 추가하세요. 정책 및 계약 데이터의 경우, 내용이 길더라도 섹션 전체를 하나의 청크로 저장하는 경우가 많습니다. 약간 부풀려진 컨텍스트가 절단된 사실보다 낫기 때문입니다.

2. "유사한 단어"를 "같은 의미"로 혼동하는 임베딩 (Embeddings)

벡터 검색(Vector search)은 질문과 의미론적으로 가까운 것을 검색합니다. 하지만 "구독을 취소할 수 있나요?"와 "예약을 취소할 수 있나요?"는 임베딩 공간(Embedding space)에서 서로 가깝게 위치하지만, 귀하의 시스템에서는 완전히 다른 의미를 갖습니다. 순수 의미론적 검색(Pure semantic search)은 기꺼이 예약 정책을 반환할 것입니다.

해결책: 하이브리드 검색 (Hybrid retrieval). 밀집 벡터 검색 (Dense vector search)을 전통적인 키워드 (BM25) 검색과 결합하고 그 결과를 병합합니다. 키워드는 임베딩 (Embeddings)이 뭉뚱그려 버리는 제품명, 에러 코드, SKU와 같은 정확한 용어들을 잡아냅니다. 저희의 경험상, 이 단 한 번의 변화만으로도 "유사하지만 틀린" 검색 결과의 상당 부분을 제거할 수 있었습니다.

3. 리랭킹 (Re-ranking) 부재로 인해 가장 좋은 청크가 7순위에 머무는 경우

리트리버 (Retriever)가 상위 20개의 후보를 반환합니다. 실제로 정답인 청크가 그 안에 포함되어 있지만, 순위는 7위입니다. 하지만 당신은 상위 3개만 모델에 전달하므로, 모델은 그 청크를 결코 보지 못합니다. 재현율 (Recall)은 괜찮았지만, 랭킹 (Ranking)이 실패한 것입니다.

해결책: 리랭커 (Re-ranker)를 추가하세요. 넉넉한 후보군(예: 20~30개)을 뽑은 다음, 각 청크를 실제 질문과 대조하여 점수를 매기고 순서를 재조정하는 크로스 인코더 (Cross-encoder) 리랭커를 실행합니다. 리랭킹을 거친 후 상위 몇 개만을 전달하세요. 이는 추가적인 단계이지만, 더 큰 LLM으로 교체하는 것보다 일관되게 답변 품질을 높여줍니다.

4. 오래되었거나 중복된 문서

2023년 가격 책정 PDF와 2026년 가격 책정 PDF가 모두 인덱스 (Index)에 존재합니다. 리트리벌 (Retrieval)은 우연히 의미론적으로 더 밀접하게 일치하는 2023년 문서를 찾아냅니다. 이제 당신의 에이전트는 3년 전의 가격을 인용하게 됩니다. 문서 자체에 대한 내용은 틀리지 않았지만, 어떤 문서를 가져왔느냐가 틀린 것입니다.

해결책: 인덱스를 일회성 덤프가 아닌, 살아있는 데이터셋으로 취급하세요. 메타데이터 (Metadata, 예: 효력 발생일, 버전, 출처)를 부착하고 쿼리 시점에 이를 기준으로 필터링하세요. 중복 제거 (De-duplication) 과정을 실행하고, 정기적으로 재색인 (Re-index)을 수행하세요. 저희가 해결했던 가장 비용이 많이 들었던 RAG 버그들은 알고리즘 문제가 아니라, 아무도 삭제하지 않아 잊혀진 오래된 파일 때문이었습니다.

5. "모르겠습니다" 경로의 부재

리트리벌 (Retrieval)이 관련 있는 내용을 아무것도 반환하지 않더라도, 단순한 파이프라인 (Pipeline)은 찾아낸 무엇이든 프롬프트 (Prompt)에 집어넣고, 모델은 충실하게 답변을 지어냅니다. 그것이 바로 모두가 두려워하는 환각 (Hallucination)입니다. 피할 수 있었던 일임에도 말이죠.

해결책: 검색 결과에 점수를 매기십시오 (score the retrieval). 만약 최상위 결과의 관련성 (relevance)이 임계값 (threshold) 미만이라면, 그 결과를 바탕으로 답변하지 마십시오. 해당 정보를 가지고 있지 않다고 말하거나, 사람에게 업무를 넘기십시오 (hand off). 자신의 지식의 한계를 아는 에이전트가 허세를 부리는 에이전트보다 훨씬 더 가치 있습니다.

제품 출시 전 이를 테스트하는 방법

눈대중만으로는 신뢰할 수 있는 RAG 시스템을 만들 수 없습니다. 우리는 정답이 확인된 소스 문서와 함께 50~100개의 실제 질문으로 구성된 작은 평가 세트 (evaluation set)를 구축하고, 두 가지를 별도로 측정합니다: 검색 (retrieval) 정확도 (올바른 청크를 가져왔는가?)와 답변 (answer) 정확도 (최종 응답이 정확했는가?)입니다. 이 둘을 분리하면 실패가 실제로 어디에서 발생하는지 알 수 있습니다. 열 번 중 아홉 번은 검색을 수정하면 답변이 해결되며, 더 비싼 모델이 전혀 필요하지 않았음을 깨닫게 됩니다.

RAG는 마법이 아니며 무시해도 되는 배관 작업도 아닙니다. 그것은 당신의 에이전트가 비즈니스에 기반을 두고 있는지(grounded), 아니면 즉흥적으로 행동하고 있는지를 결정하는 계층입니다. RAG를 제대로 구축하면 중간 규모의 모델이 잘못된 컨텍스트 (context)를 사용하는 프런티어 모델 (frontier model)보다 더 뛰어난 성능을 발휘합니다. 반대로 잘못 구축한다면 세상 그 어떤 모델도 당신을 구할 수 없을 것입니다.

Shanti Infosoft 소개: Shanti Infosoft는 16개 이상의 산업 분야에서 700개 이상의 프로젝트를 수행한 CMMI Level 5 AI 개발 기업입니다. 우리는 팀이 AI 아이디어에서 신뢰할 수 있는 프로덕션급 소프트웨어로 나아갈 수 있도록 돕습니다 - shantiinfosoft.com | machine learning development services.

만약 당신의 에이전트가 잘못된 컨텍스트를 자신 있게 검색하고 있다면, 저희가 귀하의 검색 파이프라인 (retrieval pipeline)을 감사하고 귀하의 문서에 맞춰 튜닝해 드릴 수 있습니다. 저희 팀과 상담하세요.

Rishabh Jain은 Shanti Infosoft의 디렉터로, 이곳의 팀은 실제 비즈니스 운영을 위한 AI 에이전트와 자동화를 구축합니다.