RAG를 붙였는데도 AI는 틀린다: 청킹·하이브리드 검색·재랭킹의 함정

 

AI 에이전트에 사내 문서를 연결하고 RAG를 붙였는데도 답변이 틀린다. 문서에 분명히 있는 제품 번호를 놓치고, 폐기된 정책을 최신 규정처럼 설명하며, 그럴듯한 출처 링크까지 달아 준다. 이때 프롬프트에 “정확하게 답하라”를 한 줄 더 넣는 것으로 해결되는 문제는 생각보다 적다. 모델이 답하기 전에 어떤 문서를 찾아 어떤 순서로 보여 주었는지부터 확인해야 한다.

 

RAG(Retrieval-Augmented Generation·검색 증강 생성)는 외부 자료를 검색해 언어 모델의 답변에 활용하는 구성이다. 외부 지식을 연결할 수 있다는 장점과, 연결한 지식을 정확하게 사용한다는 보장은 서로 다른 이야기다. 검색 대상이 잘못 잘렸거나 후보가 누락되었다면, 유창한 모델은 부족한 근거를 유창하게 설명할 수 있다. 답변 문장만 읽어서는 이 차이를 알아채기 어렵다.

 

이 글은 AI 에이전트와 업무용 챗봇을 만드는 개발자, 사내 지식 검색을 도입하는 실무자를 위해 RAG 검색 품질을 정리한다. 청킹, 하이브리드 검색, BM25, RRF, 재랭킹을 하나의 흐름으로 연결하고 한국어 업무 문서에서 확인할 항목을 설명한다. Anthropic·Elastic 공식 자료와 AWS 한국어 기술 블로그, 국내 개발 블로그를 비교해 작성했다. 자료 확인 기준일은 2026년 10월 22일이며, 본문의 회사·정책 사례는 설명을 위한 가상 사례다.

 

먼저 핵심을 짚으면, 청킹은 근거의 모양을 결정하고 하이브리드 검색은 후보의 범위를 넓히며 재랭킹은 후보의 우선순위를 조정한다. 어느 한 단계도 문서의 진실성이나 최종 답변의 정확성을 혼자 보장하지 않는다. RAG 최적화는 유행하는 구성 요소를 모두 붙이는 작업보다, 실패가 발생한 단계를 찾아 줄이는 작업에 가깝다.

RAG가 답을 찾는 과정부터 다시 보자

RAG에는 크게 준비 과정과 요청 처리 과정이 있다. 준비 과정에서는 원본 문서를 수집하고, PDF나 HTML에서 내용을 추출하고, 검색할 단위로 나눈 뒤 인덱스를 만든다. 요청이 들어오면 질문을 해석하고 검색 후보를 가져와 결합하거나 다시 정렬한다. 이후 모델에 전달할 근거를 구성하고 답변과 출처를 생성한다. 에이전트가 검색 도구를 호출하는 경우에도 이 기본 흐름은 사라지지 않는다.

 

문제는 각 단계의 오류가 다음 단계로 이어진다는 점이다. PDF 표에서 열 제목이 사라지면 청크에는 숫자만 남는다. 임베딩 모델이 그 숫자를 벡터로 잘 표현하더라도 원래 의미가 복구되지는 않는다. 검색 순위가 높아도 해당 문서가 다른 제품 버전에 관한 것일 수 있다. 답변 모델을 더 강한 모델로 바꾸기 전에, 모델이 실제로 받은 근거가 무엇인지 기록해야 하는 이유다.

 

실패를 진단할 때는 네 질문을 순서대로 던져 보자. 원본 저장소에 정답이 있는가. 검색 인덱스에 그 내용이 정상적으로 들어갔는가. 검색 후보에 필요한 근거가 포함되었는가. 포함된 근거를 답변이 제대로 사용했는가. 서로 다른 질문을 하나의 “정답률”로 뭉치면 개선 방향도 뭉개진다. 원본에 없는 답은 청킹이나 재랭킹으로 해결할 수 없다.

유용한 비교 실험은 담당자가 확인한 정답 근거를 직접 모델에 주는 것이다. 일반 검색 결과로는 실패하지만 검증된 근거를 주면 성공한다면 검색이나 문맥 구성에 개선 여지가 크다. 반대로 검증된 근거를 주어도 조건과 예외를 틀린다면 생성 지시, 모델의 해석, 답변 형식을 살펴봐야 한다. 이 비교가 모든 원인을 완벽하게 분리하는 것은 아니지만, 막연한 프롬프트 수정의 범위를 줄여 준다.

청킹을 잘못하면 정답 문서도 오답의 재료가 된다

청킹(chunking)은 문서를 일정한 검색 단위로 나누는 과정이다. 자주 나오는 질문은 “몇 토큰으로 자르면 좋은가”이지만, 그보다 먼저 물어야 할 것은 “함께 있어야 의미가 유지되는 정보가 무엇인가”다. 정책의 본문과 단서, 표의 값과 열 제목, 오류 코드와 해결 절차가 서로 다른 조각으로 흩어지면 검색은 성공처럼 보여도 답변은 실패할 수 있다.

 

예를 들어 “30일 이내 환불 가능”이라는 문장만 검색되었다고 가정하자. 바로 다음 문장에 “단, 기업용 연간 계약은 별도 약관 적용”이 있었다면 앞 문장만으로는 안전하게 답할 수 없다. 문장 길이가 짧고 임베딩 유사도가 높다는 사실은 예외 조항의 누락을 알려 주지 않는다. 한국어 약관과 운영 문서는 조사와 부정 표현 하나로 적용 범위가 달라지므로 문장의 경계보다 규칙의 경계를 보는 편이 낫다.

 

문서 구조를 이용하는 청킹은 제목, 절, 목록, 표 같은 경계를 활용한다. 다만 제목 기준으로 나누었다는 이유만으로 충분하지는 않다. 소제목 없는 긴 문단도 있고, 동일한 표가 여러 페이지에 걸쳐 이어지기도 한다. 파서가 표를 읽는 순서를 틀리면 구조적 청킹 이전에 추출 단계부터 수정해야 한다. 눈으로 본 PDF와 검색에 들어간 텍스트가 같은 정보를 담고 있는지 샘플을 비교하는 과정이 필요하다.

 

실무에서는 청크에 문서 제목, 상위 절 제목, 제품명, 버전, 시행일 같은 식별 정보를 함께 보존하는 방법을 검토할 수 있다. 표라면 행에 대응하는 항목 이름과 열의 단위가 따라오게 해야 한다. “12”라는 값만 저장하는 것과 “기업용 플랜·보관 기간·12개월”을 함께 저장하는 것은 전혀 다르다. 이 정보는 검색용 텍스트와 메타데이터에 각각 어떤 형태로 둘지도 구분해 설계해야 한다.

 

오버랩은 청크 경계에서 내용이 끊기는 문제를 줄이지만, 무조건 크게 주면 중복 후보가 상위 결과를 채울 수 있다. 같은 문서의 비슷한 조각만 여러 개 들어오면 다른 예외나 반대 근거를 볼 자리가 줄어든다. 작은 청크로 후보를 찾고 상위 절이나 부모 문서의 일부를 확장해서 읽는 방식도 가능하다. 이때도 확장된 문맥이 너무 커져 중요한 문장을 묻어 버리지 않는지 확인해야 한다.

 

토큰 수와 글자 수를 혼동하지 않는 것도 기본이다. 한국어 문장이 같은 글자 수라고 해서 임베딩 모델과 생성 모델에서 같은 토큰 수가 되는 것은 아니다. 모델과 토크나이저가 달라지면 경계와 비용도 달라질 수 있다. 청크 길이는 문서 유형별로 비교하고, 정답 근거의 보존율과 중복률을 함께 보면서 정해야 한다. 인터넷에서 본 하나의 숫자를 모든 문서에 적용할 이유는 없다.

컨텍스추얼 검색은 청크에 문맥을 돌려주는 방법이다

Anthropic이 2024년에 공개한 Contextual Retrieval은 문서를 나누면서 잃은 문맥을 보완하는 접근이다. 원문 전체를 참고해 각 청크를 설명하는 짧은 문맥을 생성하고, 이를 청크 앞에 붙여 임베딩과 BM25 인덱싱에 사용한다. 단순히 사용자 질문을 길게 쓰는 기법과는 위치가 다르다. 검색 요청이 오기 전에 검색 대상 자체가 문서 안에서 무엇을 의미하는지 더 잘 표현하도록 만드는 것이다.

 

가령 청크에 “매출이 3% 증가했다”만 있으면 어느 회사의 어느 기간인지 알기 어렵다. 문맥 설명에 회사와 분기, 해당 절의 주제가 들어가면 의미 검색과 키워드 검색에 필요한 단서가 늘어난다. Anthropic은 보통 50~100토큰 정도의 청크별 문맥을 생성하는 예시를 제시한다. 이 길이는 해당 구현의 안내이지 모든 한국어 문서에 통하는 정답 규격은 아니다.

 

여기서 생성한 문맥을 원문 사실과 같은 등급으로 취급해서는 안 된다. 문맥 작성 모델이 제품 버전이나 시행일을 잘못 해석하면 검색 인덱스에 오류를 더할 수도 있다. 원문과 생성한 주석을 구분해서 보관하고, 중요한 식별 정보가 원문에 근거하는지 검사하는 편이 좋다. 문서가 변경되면 기존 청크뿐 아니라 설명 문맥도 갱신해야 한다.

 

적용 대상을 고르는 것도 중요하다. 이미 제목과 메타데이터가 충분한 짧은 FAQ와, 동일 표현이 반복되는 긴 재무 보고서는 기대 효과가 다를 수 있다. 문맥 생성에는 처리 비용과 파이프라인 복잡도가 추가된다. 기존 제목 경로를 붙이는 단순한 기준선과 비교한 뒤 더 복잡한 방법의 가치가 있는지 판단해야 한다. 검색 전처리 비용을 지불한다고 검색 품질이 자동으로 올라가지는 않는다.

벡터 검색과 BM25는 서로 다른 질문에 강하다

벡터 검색은 질문과 문서의 의미적 관계를 표현한 임베딩을 이용한다. 사용자가 “계정을 잠깐 쉬고 싶다”고 묻고 문서에는 “서비스 일시 중지”라고 적혀 있을 때처럼 표현이 달라도 관련 내용을 찾는 데 도움이 된다. BM25는 질의어의 출현 빈도와 문서 길이 등을 반영하는 대표적인 어휘 기반 검색 방식이다. 특정 문자열과 단어가 중요한 요청에서 유용하다.

 

제품 코드, 오류 메시지, 계약 번호, API 이름은 의미가 비슷한 문장을 찾는 것만으로 충분하지 않은 경우가 많다. “TS-999 오류 해결”을 물었는데 다른 오류 설명이 문맥상 더 비슷하게 검색될 수도 있다. 반대로 사용자가 문서에 없는 동의어나 구어체를 썼다면 키워드만으로 필요한 문서를 놓칠 수 있다. 하이브리드 검색은 이런 차이를 이용해 서로 다른 검색기가 찾은 후보를 함께 다룬다.

 

다만 “벡터는 숫자를 못 찾고 BM25는 동의어를 전혀 처리하지 못한다”처럼 단정하면 시스템을 잘못 이해하게 된다. 결과는 임베딩 모델, 분석기, 동의어 설정, 필드 구성, 질의 방식에 영향을 받는다. BM25 점수도 일반적으로 양의 정수로만 나오는 값이 아니다. 검색기의 성질을 설명하는 쉬운 구분과 실제 구현의 제약을 혼동하지 말아야 한다.

 

한국어 문서에서는 띄어쓰기, 영문 약어, 한글 제품명과 영문 제품명의 혼용을 따로 점검할 만하다. “S-24”, “S24”, “에스24”가 정말 같은 제품인지부터 도메인 담당자가 정해야 한다. 같은 대상으로 쓰는 표현은 정규화나 별칭 사전으로 연결할 수 있지만, 서로 다른 버전을 편의상 합치면 오히려 위험하다. 하이픈과 소수점이 제거된 제품 번호가 다른 제품으로 검색되는지도 확인해야 한다.

검색 로그를 질문 유형별로 나누면 보완 관계가 보인다. 식별자 중심 질문, 개념 설명 질문, 문서 여러 개를 결합해야 하는 질문, 시간 조건이 있는 질문을 분리해 보자. 전체 평균이 올라도 중요한 오류 코드 질의가 악화될 수 있다. 하이브리드를 도입했다는 사실보다 어떤 질의군에서 누락이 줄고 어디서 불필요한 후보가 늘었는지가 더 중요하다.

하이브리드 검색의 핵심은 점수를 섞는 방식이다

두 검색기의 결과를 합칠 때 원점수를 그대로 더하는 방식은 주의가 필요하다. BM25 점수와 벡터 유사도는 같은 단위를 갖지 않으며, 분포도 질문과 인덱스에 따라 달라진다. 한쪽 점수가 수치상 더 크다는 이유만으로 의미 있는 비중이 자동으로 정해지지 않는다. 점수 정규화와 가중치를 설계하거나, 점수의 크기 대신 순위를 이용해 합치는 방법을 선택할 수 있다.

 

RRF(Reciprocal Rank Fusion)는 순위를 이용하는 대표적인 결합 방법이다. 어떤 문서 d의 점수를 각 결과 목록에서의 순위에 따라 1/(k + rank(d)) 형태로 계산한 뒤 더한다. 여기서 rank는 1부터 시작하며 k는 상위 순위와 하위 순위의 차이를 완화하는 상수다. 여러 목록에서 높은 순위로 반복 등장하는 문서가 유리해지는 구조다.

 

Elastic 공식 문서의 rank_constant 기본값은 60이다. 그러나 기본값이 있다는 사실은 조정할 것이 없다는 뜻이 아니다. 각 검색기에서 몇 개의 후보를 가져오는지, 결합 대상으로 삼는 창의 크기가 얼마인지에 따라 결과가 달라진다. 한 검색기에서 후보를 너무 적게 가져오면 결합 단계에서 살릴 문서 자체가 없다. 상수만 바꾸면서 성능을 논하기보다 후보 생성 조건을 함께 기록해야 한다.

 

RRF 점수를 “정답일 확률”로 읽어서도 안 된다. RRF는 검색 결과 목록의 순위를 결합할 뿐 문장 내용의 사실성을 직접 검증하지 않는다. 여러 검색기가 같은 잘못된 문서를 높게 평가하면 그 문서는 결합 후에도 유리할 수 있다. 모든 검색기가 놓친 문서는 RRF가 되살리지 못한다. 순위 결합은 근거 검증을 대신하는 장치가 아니다.

 

실험할 때는 벡터 단독, BM25 단독, 단순 결합, RRF 결합을 같은 평가 질문으로 비교하는 편이 좋다. 동시에 청크 크기와 임베딩 모델까지 바꾸면 무엇 때문에 결과가 달라졌는지 설명하기 어렵다. 점수 기반 결합이 항상 나쁘거나 RRF가 항상 우월한 것도 아니다. 운영 데이터에서 안정적인 방법과 관리 가능한 복잡도 사이의 선택이다.

재랭킹은 후보를 정리하지만 없는 정답을 만들지 못한다

재랭킹(reranking)은 먼저 가져온 후보를 질문과의 관련성에 따라 다시 정렬하는 단계다. 흔히 사용하는 크로스 인코더 방식은 질문과 문서를 함께 입력받아 둘 사이의 관계를 평가한다. 질문과 문서를 각각 임베딩하는 방식보다 쌍의 관계를 직접 살펴볼 수 있지만, 모든 문서에 이 계산을 적용하면 비용과 지연이 커진다. 그래서 넓게 후보를 가져온 뒤 좁혀서 다시 평가하는 두 단계 구성을 많이 사용한다.

AWS의 한국어 Reranker 기술 글도 이런 구조를 설명한다. 임베딩과 어휘 검색으로 후보를 구성하고 한국어 재랭커로 순서를 조정한 뒤 생성 단계로 전달하는 흐름이다. 여기서 핵심은 “검색 모델을 하나 더 붙였다”가 아니라 빠른 후보 생성과 상대적으로 비싼 정밀 평가의 역할 분담이다. 모든 재랭커가 동일한 구조나 비용 특성을 갖는 것은 아니므로 실제 사용하는 모델의 입력 제한과 처리 방식을 확인해야 한다.

 

가장 흔한 오해는 재랭커가 나쁜 검색을 모두 고쳐 줄 것이라는 기대다. 정답 청크가 처음 후보 100개 안에 없는데 그 100개를 아무리 잘 정렬해도 정답은 생기지 않는다. 반대로 정답이 후보에는 있는데 최종 문맥에 들어가지 못한다면 재랭킹의 효과를 기대할 수 있다. 후보 재현율과 최종 순위 품질을 나눠 보아야 하는 이유다.

 

처음 가져올 후보 수 N과 최종 전달할 근거 수 K를 구분해서 설계하자. N을 늘리면 필요한 근거를 포함할 가능성이 커질 수 있지만 재랭킹 계산량도 늘어난다. K를 늘리면 모델이 볼 정보는 많아지지만 중복, 충돌, 오래된 정책도 함께 들어올 수 있다. “최대한 많이 넣으면 정확해진다”는 직관은 문맥을 읽는 비용과 불필요한 정보의 영향을 빠뜨린다.

 

재랭킹을 넣은 뒤 생성 입력이 줄어도 전체 비용이 반드시 줄지는 않는다. 검색 비용, 재랭커 비용, 생성 입력과 출력 비용, 재시도 비용을 합산해야 한다. 지연도 평균뿐 아니라 느린 요청의 분포를 함께 보아야 한다. 짧은 질문에서 몇백 밀리초의 추가가 중요한 서비스와, 근거를 정밀 검토하는 내부 조사 도구는 허용 기준이 다르다.

검색어를 고치는 순간 사용자의 조건이 사라질 수 있다

질의 재작성은 구어체 질문을 검색하기 좋은 표현으로 바꾸거나, 여러 하위 질문으로 나누는 방법이다. 대화형 에이전트에서는 “그 플랜도 해당돼?” 같은 표현의 대상을 앞선 대화에서 복원하는 데 도움이 된다. 다만 질문을 더 자연스럽게 만드는 과정이 중요한 조건을 지우는 과정이 될 수도 있다.

 

“2026년 9월 이전에 구매한 기업용 연간 플랜은 환불되나?”라는 질문을 “기업용 플랜 환불 정책”으로 줄이면 구매 시점과 연간 계약이라는 조건이 사라진다. 검색 결과가 더 많이 나와도 사용자 질문에는 더 멀어질 수 있다. 재작성 결과와 원문을 함께 기록하고 제품 식별자, 날짜, 부정 표현, 수량 조건이 유지되는지 확인해야 한다.

 

여러 검색어를 생성하는 확장 방식도 마찬가지다. 표현의 폭을 넓히는 대신 사용자가 묻지 않은 개념을 추가하면 후보에 잡음이 늘어난다. 하위 질문으로 나누는 경우에는 각 질문의 답이 원래 요청의 조건 아래에서 결합 가능한지 봐야 한다. 서로 다른 제품의 규정을 각각 찾아 놓고 하나의 정책인 것처럼 합치면 검색 단계는 성공했어도 최종 답은 틀린다.

 

모르는 조건을 검색으로 추측하는 대신 사용자에게 되묻는 것도 시스템의 기능이다. 어떤 제품인지, 개인용인지 기업용인지에 따라 답이 달라지는데 대화에 단서가 없다면 확인 질문을 해야 한다. 재작성은 사용자의 의도를 명확하게 표현하는 도구이지 누락된 사실을 창작하는 허가가 아니다.

최신 문서보다 먼저 확인할 것은 적용 조건과 접근 권한이다

사내 RAG의 정답은 가장 최근에 게시된 문서와 항상 같지 않다. 2026년 9월에 새 환불 정책이 나왔더라도 그 이전 계약에는 이전 약관이 적용될 수 있다. 게시일, 수정일, 시행일, 계약 체결일은 서로 다른 시간 정보다. 최신성 정렬만으로 이 관계를 해결하려 하면 과거 거래에 현재 규정을 소급 적용하는 답이 나올 수 있다.

 

메타데이터에는 문서 버전, 제품군, 적용 지역, 유효 기간, 원본의 권위와 상태를 가능한 범위에서 명시하는 것이 좋다. 초안과 확정 공지, 폐기된 매뉴얼과 현재 매뉴얼을 구분해야 한다. 검색 결과를 받고 나서 모델에게 “최신 정보만 써라”라고 지시하는 것보다, 검색 조건과 문맥 구성에서 적용 대상을 좁히는 설계가 더 직접적이다.

 

여기에는 접근 권한도 포함된다. 사용자가 볼 수 없는 문서를 검색 후보에 넣은 뒤 답변 모델이 언급하지 않기를 기대하는 방식은 적절한 권한 통제가 아니다. 인증된 사용자의 권한을 검색과 문서 조회 단계에 적용하고, 캐시와 로그에서도 권한 경계가 유지되는지 확인해야 한다. 텍스트에 적힌 “외부 공유 금지” 문구를 모델이 읽었다는 사실과 접근 통제는 별개다.

 

필터도 무조건 강하게 걸면 좋은 것은 아니다. 잘못 입력된 제품 메타데이터가 정답을 검색 전에 제거할 수 있다. 따라서 검색 누락을 조사할 때는 필터 적용 전후와 문서 상태를 확인할 수 있어야 한다. 권한을 완화해서 해결할 문제가 아니라, 올바른 권한 안에서 인덱스와 메타데이터의 정확성을 관리할 문제다.

 

사용자에게는 적용 기준을 짧게 드러내는 편이 낫다. “기업용 연간 계약이며 2026년 9월 이전 체결이라는 조건에서 이전 약관을 기준으로 설명합니다”처럼 전제를 명시하면 오해를 줄일 수 있다. 조건이 확인되지 않았다면 단정 대신 확인이 필요한 항목을 제시해야 한다. 검색 관련성 점수가 높은 문서도 이 전제를 대신 결정해 주지는 못한다.

출처 링크가 있다는 것과 근거가 있다는 것은 다르다

RAG 답변에 문서 링크가 달리면 신뢰도가 높아 보인다. 하지만 링크가 존재한다는 사실과 그 문서가 바로 앞 주장을 뒷받침한다는 사실은 다르다. 제품 소개 페이지를 인용하면서 환불 가능 기간을 말하거나, 한 문서에서 수량을 가져오고 다른 문서에서 단위를 가져오면 출처가 있어도 근거 연결은 깨져 있다.

 

답변을 검토할 때는 중요한 주장마다 대응하는 근거 구간을 확인해야 한다. 숫자, 날짜, 적용 대상, 예외, 의무 사항은 특히 엄격하게 보자. 검색 청크의 ID를 문서 URL과 연결하고, 가능하다면 사용자가 확인할 절 제목이나 페이지 정보도 제공하면 검증 부담을 줄일 수 있다. 출처를 문서 맨 아래 한꺼번에 나열하는 것만으로는 어느 주장의 근거인지 알기 어렵다.

 

서로 충돌하는 근거가 나오면 모델이 자연스럽게 하나로 봉합하지 않도록 해야 한다. 문서의 적용 범위와 시행일을 비교해 구분할 수 있으면 구분해서 설명하고, 판단할 정보가 부족하면 충돌을 드러내야 한다. 오래된 문서를 무조건 버리는 방식도 과거 계약 질문에는 맞지 않는다. 근거의 관계를 설명하는 능력이 단순 요약보다 중요해지는 지점이다.

검색된 문서는 사실 자료이면서 동시에 외부 입력이다. 문서 안에 시스템 지시를 바꾸라는 문장이 섞여 있어도 그것을 도구 실행 권한으로 취급하면 안 된다. 특히 문서를 읽고 메일을 보내거나 주문을 바꾸는 에이전트에서는 답변 생성과 실제 행동의 권한을 분리해야 한다. 검색 품질을 높이는 일이 실행 권한 검증을 대신하지는 않는다.

RAG 평가는 검색과 답변을 나눠야 원인이 보인다

검색 평가에서는 필요한 근거가 후보에 포함되었는지와 얼마나 앞에 배치되었는지를 나눠 본다. Recall@N은 상위 N개 안에 필요한 근거를 얼마나 포함하는지 살피는 데 사용한다. MRR은 첫 관련 결과의 순위에 민감하고, NDCG는 관련성 등급과 순위의 가치를 반영할 수 있다. 지표 이름보다 어떤 문서나 청크를 관련 있다고 판단했는지의 기준이 먼저다.

 

정답에 문서 두 개가 필요한 질문이라면 하나를 찾은 것으로 충분하지 않다. 본문 규칙과 예외 조항을 함께 찾아야 하는 질문도 있다. 이런 경우 단일 정답 문서 기준의 적중률은 실제 답변 가능성을 과대평가할 수 있다. 필요한 근거 묶음을 표시하거나 조건별 근거의 포함 여부를 기록해 평가의 단위를 업무에 맞춰야 한다.

 

생성 평가에서는 질문에 답했는지, 근거에 충실한지, 사실이 맞는지, 모르는 내용을 적절히 보류했는지를 구분한다. 근거에 충실하게 오래된 규정을 답했더라도 사용자 상황에는 틀릴 수 있다. 반대로 우연히 맞는 답을 했어도 제공된 근거에서 확인할 수 없다면 근거 활용 품질은 좋다고 할 수 없다. 정답 여부와 근거 충실성을 같은 점수로 취급하지 않는 편이 좋다.

 

답이 없는 질문도 반드시 포함해야 한다. 데이터베이스에 없는 제품, 범위 밖 업무, 확인되지 않은 미래 일정에 대해 무리하게 답하는지 보자. 검색 점수 임계값 하나만으로 이 문제를 해결하기는 어렵다. 유사도와 재랭커 점수는 보통 교정된 정답 확률이 아니며 질문 유형별 분포도 다르다. 근거의 충족 여부와 필수 조건의 확인 상태를 함께 이용해야 한다.

 

평가 질문을 모델로 대량 생성하면 빠르게 시작할 수 있지만 쉬운 문제에 치우칠 수 있다. 원문 표현을 그대로 닮은 질문은 실제 사용자의 오타, 약어, 전제 생략을 충분히 반영하지 못한다. AWS 글은 135개의 질문·문서·답변 묶음을 이용한 평가를 설명하고, 답변과의 재랭커 유사도가 간접 평가라는 한계도 밝힌다. 이런 점수는 사람 검토를 대체하는 확정 판정으로 읽어서는 안 된다.

 

실제 문의에서 개인정보를 제거해 만든 질문과 전문가가 만든 어려운 질문을 함께 관리하는 편이 좋다. 튜닝에 사용한 문제와 최종 확인 문제를 나누고 문서 버전도 남기자. 시스템을 수정할 때마다 같은 고정 평가군으로 퇴행을 확인해야 평균 개선 뒤에 숨은 중요한 실패를 찾을 수 있다. 단, 운영 로그의 민감한 내용을 그대로 외부 평가 서비스로 보내서는 안 된다.

검색 실패 67% 감소라는 수치를 읽는 정확한 방법

Anthropic의 Contextual Retrieval 자료에서 자주 인용되는 숫자는 재랭킹을 함께 적용했을 때 검색 실패율이 67% 줄었다는 결과다. 이 표현을 “RAG 답변 정확도가 67%포인트 올라갔다”로 바꾸면 의미가 완전히 달라진다. 이 수치는 해당 평가 조건에서 상위 20개 청크를 기준으로 한 검색 실패 지표인 1-recall@20에 관한 것이다.

자료에 제시된 기준선 실패율은 5.7%, 문맥을 추가한 임베딩은 3.7%, 문맥 기반 BM25까지 결합한 구성은 2.9%, 재랭킹까지 적용한 구성은 1.9%다. 5.7%에서 1.9%로 줄어든 차이는 3.8%포인트이며, 기준선 실패율 대비 약 66.7%의 상대 감소다. 실패가 줄었다는 유의미한 결과지만 최종 생성 답변의 정확도나 모든 업무의 성능을 직접 나타내지는 않는다.

 

평가에는 코드, 소설, 논문 등 여러 영역과 당시 선택한 임베딩·재랭킹 구성이 사용됐다. 후보 수와 최종 청크 수 등 실험 조건도 함께 읽어야 한다. 해당 문서에서 좋은 결과를 보였던 설정을 현재 한국어 정책 문서의 보장된 최적값으로 가져올 수는 없다. 2024년 자료의 모델명과 요금도 현재 시점의 추천 사양으로 옮기지 않는 편이 정확하다.

 

이 사례가 주는 실용적인 교훈은 특정 숫자를 복제하는 것이 아니다. 문맥 보존, 어휘 검색 보완, 순위 재평가가 각자 어떤 실패를 줄였는지 분리해 측정했다는 데 있다. 우리 시스템에서도 같은 방법이 효과를 내는지는 같은 질문과 같은 문서 조건에서 확인해야 한다. 벤치마크는 실험 방향을 제안하는 자료이지 도입 후 성과 보증서가 아니다.

한국어 업무 문서로 시작하는 현실적인 개선 순서

먼저 대표 질문을 모으고 실패를 유형별로 분류하자. 문서가 없는 질문, 문서는 있지만 파싱이 깨진 질문, 후보에 정답이 없는 질문, 후보는 맞는데 순위가 낮은 질문, 근거를 잘못 읽은 질문을 구분한다. 고객지원이라면 문의량뿐 아니라 잘못 답했을 때의 영향도 함께 고려해야 한다. 자주 나오는 쉬운 질문만으로 전체 품질을 판단하지 않는 것이 출발점이다.

 

다음으로 검색 입력을 눈으로 확인한다. PDF 표의 제목과 단위, 절의 계층, 예외 조항, 제품 코드가 청크에서 살아 있는지 본다. 이 단계에서 문제가 발견되면 재랭커보다 파서와 청킹을 먼저 고치는 편이 합리적이다. 수정 전후 원본 문서 버전과 청크 생성 규칙을 남겨야 개선이 재현 가능하다. 문서가 갱신될 때 삭제된 내용이 인덱스에 남는지도 점검한다.

 

그다음 벡터 검색과 BM25를 각각 평가하고 결합한다. 모든 질문에서 한쪽을 우세하게 만들기보다 식별자 질의와 자연어 질의의 차이를 보자. RRF를 사용한다면 각 검색기의 후보 수와 결합 범위를 기록한다. 중복 청크가 상위 결과를 차지하는지, 특정 긴 문서가 과도하게 노출되는지도 함께 확인한다. 평균 지표만으로는 이런 편향이 잘 드러나지 않는다.

 

후보에 정답이 충분히 들어오는데 순위가 문제일 때 재랭킹을 검토한다. 초기 후보 수와 최종 전달 수를 바꾸면서 검색 품질, 답변 품질, 지연, 총비용을 같은 화면에서 비교하자. 재랭커를 붙였다는 이유만으로 성공으로 판단하지 말고, 중요한 질문군의 개선이 실제로 있는지 확인해야 한다. 입력 길이를 넘은 문서가 어디서 잘리는지도 실험 조건에 포함한다.

 

마지막으로 근거와 답변의 연결을 점검한다. 적용 기준을 먼저 밝히고, 주장의 출처를 연결하며, 근거가 부족하면 확인 질문이나 보류 응답을 하도록 설계한다. 변경을 운영에 반영한 뒤에는 검색 후보와 사용 근거를 추적할 수 있어야 한다. 모든 로그를 영구 저장하자는 뜻은 아니다. 개인정보와 권한을 고려하면서 실패 원인을 재현할 최소한의 관측 정보를 정하자는 뜻이다.

이 순서는 무조건 모든 팀에 적용되는 고정 절차가 아니다. 문서가 자주 바뀌는 조직은 인덱스 갱신과 버전 관리가 우선일 수 있고, 정확한 부품 번호를 찾는 서비스는 어휘 검색과 식별자 처리가 먼저일 수 있다. 문제에 맞는 단순한 기준선을 만들고 하나씩 비교하는 편이, 많은 구성 요소를 동시에 붙인 뒤 결과를 설명하지 못하는 상황을 줄여 준다.

자주 묻는 질문

Q. RAG를 쓰면 환각이 없어지나요?

아니다. RAG는 모델이 참고할 외부 근거를 제공하지만 근거 누락, 오래된 문서, 잘못된 적용 조건, 생성 과정의 오류가 남는다. 검색 평가와 답변 평가를 나누고 근거가 없는 상황에서 보류할 수 있어야 한다. 출처 표시도 실제 주장과 연결되는지 확인해야 한다.

Q. 청크 크기는 작을수록 검색이 잘되나요?

작은 청크는 주제를 좁힐 수 있지만 예외와 전제가 잘릴 수 있다. 큰 청크는 문맥을 보존하지만 여러 주제가 섞이거나 불필요한 정보가 늘 수 있다. 문서 구조와 정답 근거의 범위를 기준으로 비교하고, 필요하면 검색 단위와 생성에 전달하는 문맥 단위를 다르게 설계한다.

Q. 하이브리드 검색과 재랭킹은 같은 기술인가요?

하이브리드 검색은 서로 다른 검색 방식의 후보를 결합하는 구성이고 재랭킹은 가져온 후보의 우선순위를 다시 평가하는 단계다. 함께 쓸 수 있지만 해결하는 실패가 다르다. 후보 자체의 누락과 후보 안에서의 잘못된 순위를 구분해야 한다.

Q. RRF를 사용하면 튜닝이 필요 없나요?

점수의 척도를 직접 맞추는 부담을 줄일 수 있지만 후보 수, 결합 창의 크기, 순위 상수 같은 조건은 여전히 결과에 영향을 준다. RRF 점수는 정답 확률이 아니며 원문 내용의 사실성도 검증하지 않는다. 기본값에서 시작하더라도 자체 평가군으로 확인해야 한다.

Q. 한국어 RAG에는 한국어 재랭커가 반드시 필요한가요?

언어 지원과 도메인 적합성을 확인할 필요는 있지만 특정 이름이나 언어 표기만으로 도입 여부를 정할 수는 없다. 실제 한국어 질문, 영문 약어, 제품 코드, 긴 규정 문장으로 평가하고 처리 지연과 입력 제한을 함께 비교해야 한다. 후보가 부실하다면 재랭커를 바꾸는 것보다 앞단 수정이 우선이다.

Q. 더 긴 컨텍스트를 지원하는 모델이면 검색을 생략해도 되나요?

문서량과 비용, 변경 주기, 접근 권한에 따라 전체 문서를 넣는 접근을 검토할 수는 있다. 다만 긴 입력을 받을 수 있다는 사실이 모든 조건을 정확히 활용한다는 뜻은 아니다. 불필요한 정보와 충돌 문서가 늘어날 수 있으므로 같은 평가 질문으로 검색 방식과 비교해야 한다.

RAG의 경쟁력은 검색 결과를 의심하는 구조에서 나온다

RAG 시스템의 품질은 “어떤 모델을 연결했는가”만으로 설명되지 않는다. 원본의 의미를 보존한 청크, 서로 다른 검색기의 보완 관계, 후보를 좁히는 순위 평가, 적용 조건과 접근 권한, 주장과 근거의 연결이 함께 작동해야 한다. 이 가운데 하나가 무너지면 나머지 단계가 잘 돌아가도 사용자에게 틀린 답이 전달될 수 있다.

 

좋은 AI 에이전트는 검색 결과를 받았다는 이유로 바로 행동하지 않는다. 필요한 근거가 있는지, 현재 질문에 적용되는지, 출처가 주장을 실제로 지지하는지 확인한다. 부족한 정보가 있으면 더 찾거나 묻고, 확인할 수 없는 부분은 남겨 둔다. 그 과정을 측정하고 개선할 수 있는 구조가 프롬프트 한 문장보다 오래가는 품질 차이를 만든다.

참고 자료와 읽는 순서

• Anthropic, Introducing Contextual Retrieval, 2024년 9월 19일. 청크별 문맥을 임베딩과 BM25에 적용하는 방식, 재랭킹을 포함한 검색 실패율 평가의 원자료다. 본문의 67% 수치는 이 자료의 실험 범위를 설명한 것이다.

https://www.anthropic.com/news/contextual-retrieval

Contextual retrieval in AI systems

• Elastic 공식 문서, Reciprocal rank fusion. RRF 공식, rank_constant, rank_window_size와 결합 동작을 확인할 수 있다. 구현 시에는 사용하는 Elasticsearch 버전에 맞는 문서를 확인해야 한다.

https://www.elastic.co/docs/reference/elasticsearch/rest-apis/reciprocal-rank-fusion

Reciprocal rank fusion | Elasticsearch Reference

• AWS 기술 블로그, 한국어 Reranker를 활용한 검색 증강 생성(RAG) 성능 올리기, 2024년 2월 20일. 한국어 재랭킹 구성과 평가 흐름을 이해하는 데 참고했다. 당시 모델과 구현 예시는 게시 시점의 맥락으로 읽어야 한다.

https://aws.amazon.com/ko/blogs/tech/korean-reranker-rag/

한국어 Reranker를 활용한 검색 증강 생성(RAG) 성능 올리기 | Amazon Web Services

• Junyeol Blog, RAG 개념 정리 (2) — 검색 정확도 올리기: 하이브리드 서치, 리랭킹, 쿼리 재작성, 2026년 8월 11일. 국내 설명 글의 주제 전개를 비교하는 데 참고했으며, 성능 수치는 공식 원자료와 별개로 일반화하지 않았다.

https://www.junyeol.blog/blog/tech/rag-hybrid-search-reranking

RAG 개념 정리 (2) — 검색 정확도 올리기: 하이브리드 서치, 리랭킹, 쿼리 재작성

• hjjummy의 Dev Blog, RAG 구축하기 - 3.2 성능 최적화 : Hybrid Search(CC& RRF) 와 Rerank, 2025년 8월 19일. 준비·검색·재랭킹·생성의 흐름과 국내 개발 블로그의 설명 형식을 비교했다. 본문은 이들 자료를 바탕으로 재구성한 해설이며 자체 성능 실험 보고서는 아니다.

https://hjjummy.tistory.com/28