RAG 검색의 top-k와 재순위화, 후보 수와 최종 순서 구분하기
페이지 정보
본문
RAG 예제에서 top-k를 늘리면 답변이 좋아진다는 설명을 접하기 쉽습니다. 그러나 검색 후보를 더 가져오는 일과 그중 답변에 쓸 근거를 잘 고르는 일은 서로 다른 단계입니다.
재순위화까지 추가하면 같은 숫자가 여러 위치에 등장해 설정의 의미가 더 헷갈릴 수 있습니다. 이 글은 후보 검색, 재순위화, 최종 문맥 구성을 나누어 이해하는 데 초점을 둡니다.
숫자와 문서 이름은 설명을 위한 가상 사례이며 특정 모델이나 서비스의 권장값은 아닙니다.
AI 생성 삽화 · 개념 이해를 위한 AI 연출 이미지이며 실제 시스템 구성도나 측정 결과가 아닙니다.
핵심 정리
검색의 top-k는 가져올 후보 수와 관련되고, 재순위화는 그 후보의 순서를 다시 평가합니다. 후보에 없는 문서를 재순위화만으로 되찾을 수 없으며 최종 답변의 사실성은 별도로 검증해야 합니다.
1. 검색 결과와 생성에 넣는 근거를 구분합니다
가상의 사내 안내 검색에서 휴가 신청 절차를 물었다고 가정합니다. 첫 단계는 관련 있어 보이는 문서를 찾는 작업입니다.
다음 단계는 그 후보를 다시 평가하거나 필요한 부분을 선택하는 작업이며, 마지막으로 선택한 내용을 모델 입력에 넣어 답변을 생성합니다. 이 흐름을 하나의 검색 함수라고만 부르면 어디에서 문제가 생겼는지 찾기 어렵습니다.
Sentence Transformers의 공식 예제는 먼저 검색으로 후보를 얻고, 질문과 후보를 함께 평가하는 재순위화 단계를 설명합니다. 자체 설계 노트에는 각 단계의 입력과 출력을 적어 보십시오. 질문 문자열, 후보 문서 식별자 목록, 다시 정렬된 목록, 최종 입력 문맥을 구분하면 같은 데이터가 어디까지 전달되었는지 따라갈 수 있습니다.
문서 전체를 저장하기 어렵다면 검증에 필요한 식별자와 버전을 남겨 추적할 수 있게 구성합니다.
2. 후보 수와 최종 반환 수에 별도 이름을 붙입니다
자체 예시로 첫 검색에서 열 개의 후보를 찾고 재순위화 후 세 개를 선택한다고 가정합니다. 여기서 열과 셋은 서로 다른 단계의 수량입니다.
설정 파일에 두 값 모두 k라고 적으면 호출 위치를 알아야 의미를 해석할 수 있습니다. 후보 수와 최종 선택 수처럼 역할이 드러나는 이름을 쓰는 편이 좋습니다.
Pinecone의 재순위화 문서도 먼저 후보를 가져온 뒤 별도의 반환 개수를 정하는 흐름을 보여 줍니다. 다만 제품과 라이브러리마다 매개변수 이름은 달라질 수 있으므로 자신이 사용하는 API 문서를 기준으로 확인합니다.
후보가 요청 개수보다 적게 반환되는 경우도 처리해야 합니다. 가상의 후보 열 개라는 설명이 언제나 정확히 열 문서를 보장한다는 의미는 아닙니다.
필터와 데이터 상태를 포함해 실제 반환 목록의 길이를 기록하면 이후 단계의 결과를 더 정확히 해석할 수 있습니다.
3. 재순위화가 할 수 없는 일도 이해합니다
재순위화기는 전달받은 후보를 평가하므로, 첫 검색에서 빠진 문서를 그 목록 안에서 새로 발견할 수는 없습니다. 가상의 정답 근거가 문서 A인데 후보 목록에 A가 없다면 순서만 바꾸는 것으로 문제가 해결되지 않습니다.
이때는 후보를 만드는 검색 단계부터 살펴야 합니다. 반대로 A가 후보에는 있지만 최종 선택에서 빠졌다면 재순위화와 선택 기준을 점검할 수 있습니다.
Sentence Transformers 문서는 질문과 문서를 함께 입력하는 Cross-Encoder와 개별 임베딩을 활용하는 검색 방식의 역할 차이를 설명합니다. 입문 실습에서는 구현을 한꺼번에 바꾸기보다 실패한 질문 하나의 후보 목록을 직접 읽어 보십시오. 문서가 없는 문제인지, 순서가 낮은 문제인지, 문서는 맞지만 필요한 문장이 잘린 문제인지 구분하면 다음 실험이 구체적이 됩니다.
답변 문장만 보고 모든 오류를 생성 모델의 문제라고 단정하지 않는 것이 중요합니다.
4. 관련성 점수를 정답 확률로 읽지 않습니다
재순위화 결과에 숫자가 붙어 있어도 그 값이 문서 내용의 사실성을 보장하는 확률이라고 생각하면 안 됩니다. Sentence Transformers의 사전 학습 모델 문서는 모델에 따라 원시 점수를 출력하거나 활성화 함수를 적용할 수 있음을 설명합니다.
따라서 서로 다른 모델의 점수를 같은 기준으로 직접 비교하기 전에 정의부터 확인해야 합니다. 가상의 검색 실험에서 오래된 안내 문서가 질문과 표현이 비슷해 높은 순위에 오를 수 있습니다.
관련성이 높다는 판단과 현재 유효한 규정이라는 판단은 별도의 문제입니다. 자체 시스템에서는 문서의 갱신일과 적용 대상, 접근 권한 같은 정보를 함께 다룰 필요가 있습니다.
점수 임계값을 정할 때도 보기 좋은 숫자를 임의로 정하기보다 실제 질문과 근거를 이용한 평가에서 어떤 결과가 나오는지 확인합니다. 원시 점수인지 변환한 값인지 로그에 명시하면 분석 중 의미가 바뀌는 일을 줄일 수 있습니다.
5. 최종 문맥은 문서 개수만으로 결정하지 않습니다
세 개의 문서를 선택했다 해도 각 문서의 길이가 다르면 모델에 전달되는 분량은 크게 달라질 수 있습니다. 자체 실습에서는 선택 문서 수와 최종 문맥의 토큰 수를 따로 기록해 보십시오. 같은 내용이 여러 후보에 반복되면 문서 수가 늘어도 새로운 근거가 늘지 않을 수 있습니다.
예를 들어 동일한 안내문을 복사한 파일 세 개와 서로 다른 절차를 설명한 파일 세 개는 답변에 제공하는 정보가 다릅니다. 필요한 부분을 선택하는 과정에서는 출처 식별자를 유지해, 답변의 근거를 나중에 원문과 대조할 수 있게 합니다.
잘라낸 문맥이 조건이나 예외 문장을 제외하지 않았는지도 살펴봅니다. 문서 앞부분만 일률적으로 붙이는 방식이 질문에 필요한 대목을 남기는지 직접 검토하는 것이 좋습니다.
문맥 구성의 목표는 숫자를 채우는 것이 아니라 답변에 필요한 정보를 추적 가능한 형태로 전달하는 데 있습니다.
6. 단계별 평가로 바꿀 설정을 정합니다
가상의 평가 질문 묶음에는 정답 근거 문서와 확인해야 할 핵심 내용을 함께 준비합니다. 먼저 근거가 첫 후보에 포함되는지 살펴보고, 그다음 최종 선택에 남는지, 마지막으로 답변이 근거를 올바르게 사용했는지 나누어 기록합니다.
후보 수만 늘린 실험과 재순위화를 추가한 실험은 변경 사항을 구분해 비교합니다. 소요 시간과 처리한 후보 수도 남기면 품질 변화와 운영 부담을 함께 검토할 수 있습니다.
평가 질문을 몇 개 읽어 본 결과와 충분한 범위에서 검증한 결과도 구별해야 합니다. 자주 묻는 질문만 잘 동작하고 긴 질문이나 모호한 표현에서 실패하는지 확인할 수 있도록 사례를 나눕니다.
포트폴리오에는 최종 답변 화면과 함께 실패 원인을 어느 단계에서 발견했는지 설명해 보십시오. 검색과 재순위화의 역할이 분명해지면 top-k를 단순히 크게 만드는 대신 필요한 지점을 선택해 개선할 수 있습니다.
7. 자주 묻는 질문
Q1. 검색 top-k와 생성 모델의 top-k는 같은가요?
서로 다른 맥락에서 사용하는 용어입니다. 이 글의 top-k는 검색 후보 수를 다루며, 생성 중 토큰 후보를 선택하는 설정과 구분해야 합니다.
Q2. 재순위화를 넣으면 검색 누락이 해결되나요?
전달되지 않은 문서는 후보 목록의 순서만 바꾸어 복구할 수 없습니다. 정답 근거가 첫 검색 결과에 있었는지부터 확인합니다.
Q3. 후보 수는 얼마로 정해야 하나요?
모든 서비스에 맞는 고정값은 없습니다. 질문 유형과 근거 포함 여부, 최종 답변 품질, 처리 시간을 함께 비교해 결정합니다.
Q4. 높은 점수의 문서를 그대로 답변에 쓰면 되나요?
관련성 점수만으로 최신성이나 사실성을 보장할 수 없습니다. 적용 대상과 출처를 확인하고 답변이 근거를 정확히 사용했는지도 별도로 평가해야 합니다.
참고 자료
- 이전글GPU 메모리와 시스템 RAM, 모델 실행에서 쓰이는 위치 구분하기 26.09.28
- 다음글쿠버네티스 ConfigMap과 Secret, 설정 구분과 접근 통제 이해하기 26.09.27
댓글목록
등록된 댓글이 없습니다.