RAG 프로젝트를 점검하다 보면 처음에는 꽤 잘 동작하는 것처럼 보이는데 질문을 조금만 바꾸면 엉뚱한 문서를 가져오거나, 문서 안에 정답이 있는데도 답변하지 못하는 경우가 있습니다. PDF를 벡터 DB에 넣고 임베딩까지 생성했으며 LLM도 정상적으로 연결되어 있습니다. 사용자가 예상한 질문을 입력하면 답변도 자연스럽게 나옵니다. 그런데 제품 코드나 날짜처럼 정확한 표현이 포함된 질문에서는 관련 문서가 검색되지 않고, 긴 규정 문서에서는 질문에 필요한 문장이 서로 다른 청크로 잘려 일부 내용만 답하는 식입니다. 이 상황에서 가장 먼저 LLM 모델이나 프롬프트를 바꾸는 경우가 많습니다. 하지만 검색된 context를 직접 확인해 보면 모델에 전달된 문서 자체가 잘못된 경우도 적지 않습니다. 필요한 문서가 아예 검색되지 않았다면 아무리 생성 모델의 성능이 좋아도 정확한 근거를 이용한 답변을 만들기 어렵습니다. 현재 Microsoft의 RAG 가이드도 대용량 문서를 작은 청크로 나누어 각각 독립적으로 검색할 수 있게 만들고, 임베딩을 이용한 벡터 검색과 키워드 검색을 결합하는 방식 등을 검색 품질 개선의 주요 요소로 다루고 있습니다. 특히 하나의 긴 문서에 서로 다른 주제가 섞여 있다면 모델 입력 한도를 넘지 않더라도 더 세밀한 청킹이 검색에 유리할 수 있다고 설명합니다. 중요한 것은 청킹과 임베딩, 검색을 따로 설정값처럼 보는 것이 아닙니다. 청킹을 바꾸면 임베딩되는 문맥 단위가 바뀌고, 임베딩 방식이 달라지면 벡터 공간에서 가까워지는 문서도 달라지며, 검색 방식과 top-k를 변경하면 최종적으로 LLM에 전달되는 근거가 달라집니다. 결국 세 요소는 하나의 retrieval pipeline 안에서 연결되어 있습니다. 그래서 RAG 성능을 개선할 때는 최종 답변만 보고 판단하기보다 먼저 필요한 문서가 검색되었는가를 확인하고, 그렇지 않다면 문서 단위와 임베딩, 검색 전략을 단계적으로 분리해서 보는 편이 좋습니다. Microsoft Foundry의 현재 RAG 평가 체계도 최종 답변의 Groundedness와 Relevance뿐 아니라 retrieval 단계 자체를 별도로 평가하도록 구성되어 있습니다. 검색 품질이 RAG의 병목이라면 청크 크기와 검색 알고리즘, top-k 같은 조건을 바꾸며 검색 품질을 직접 비교할 수 있습니다. RAG 성능 개선의 핵심은 더 좋은 LLM을 찾는 것보다 필요한 근거가 올바른 단위로 만들어지고, 적절한 의미 표현으로 변환되며, 실제 질문에서 상위 검색되는지 확인하는 데 있습니다.
이번 글에서는 RAG 성능을 개선할 때 확인해야 할 부분을 청킹, 임베딩, 검색 세 가지 기준으로 나누어 정리하겠습니다.
청킹은 문서를 잘게 나누는 작업보다 질문에 필요한 문맥 단위를 만드는 과정입니다
- 청크 크기는 작을수록 좋은 것이 아니라 하나의 의미가 유지되는 범위를 기준으로 봐야 합니다
RAG를 처음 구성하면 chunk size를 몇 자나 몇 토큰으로 할지부터 고민하게 됩니다. 너무 큰 청크는 여러 주제가 한 벡터 안에 섞이면서 질문과 직접 관련 없는 내용까지 함께 포함될 수 있고, 너무 작은 청크는 답변에 필요한 앞뒤 문맥이 분리될 수 있습니다.
청킹을 점검할 때는 다음 내용을 함께 볼 수 있습니다.
- 한 청크 안에 서로 다른 주제가 과도하게 섞여 있는지 확인합니다.
- 질문에 필요한 문장과 조건이 서로 다른 청크로 끊어지는지 살펴봅니다.
- 제목이나 섹션 정보가 본문과 함께 유지되는지 확인합니다.
- 표나 목록이 중간에서 잘려 의미가 달라지지 않는지 살펴봅니다.
- 동일 질문에서 여러 chunk size를 적용해 검색 결과를 비교합니다.
- 최종 답변보다 먼저 검색된 청크 자체의 관련성을 확인합니다.
예를 들어 취업규칙 문서에서 연차 발생 기준과 연차 사용 절차가 한 페이지에 함께 존재한다고 가정할 수 있습니다. 청크가 지나치게 크면 두 내용이 하나의 벡터로 표현되면서 구체적인 질문의 의미가 흐려질 수 있고, 반대로 너무 작으면 1년 미만 근로자라는 조건과 실제 발생 일수가 서로 다른 청크로 나뉠 수 있습니다. Microsoft Azure AI Search도 긴 문서를 청킹 하면 각 부분을 독립적으로 검색할 수 있고, 하나의 문서 안에 다양한 하위 주제가 포함돼 있을 때 더 세밀한 청킹이 검색 결과를 개선할 수 있다고 설명합니다. 따라서 포트폴리오에서도 chunk size 500 적용이라는 설정값보다 왜 그 크기를 선택했고 어떤 질문에서 검색 결과가 좋아지거나 나빠졌는지를 보여주는 편이 좋습니다.
- 고정 길이 청킹과 의미 단위 청킹은 문맥을 나누는 기준에서 차이가 있습니다
청킹 방식은 모든 문서를 일정 길이로 자르는 방법만 있는 것이 아닙니다. 문서 구조가 분명하다면 제목과 문단, 조항, 페이지, 섹션 같은 의미 단위를 이용할 수도 있습니다.
- 고정 길이 청킹: 일정한 글자나 토큰 수를 기준으로 문서를 나누기 때문에 구현과 비교가 단순합니다.
- 문단 중심 청킹: 작성자가 이미 나눈 문단 구조를 활용해 하나의 설명 단위를 유지하기 쉽습니다.
- 제목·섹션 중심 청킹: 문서의 제목과 하위 항목 구조를 활용해 각 내용의 주제를 함께 보존할 수 있습니다.
- 조항 중심 청킹: 규정이나 법률처럼 번호와 조항 구조가 중요한 문서에서 하나의 규칙을 독립된 검색 단위로 만들 수 있습니다.
- 혼합형 청킹: 의미 단위를 먼저 유지한 뒤 지나치게 긴 부분만 추가로 나누는 방식으로 구성할 수 있습니다.
예를 들어 회사 규정처럼 제10조 휴가, 제11조 경조휴가처럼 구조가 명확한 문서라면 단순히 500자마다 나누는 것보다 조항 제목과 본문을 함께 묶는 방식이 질문과 더 잘 맞을 수 있습니다. 반대로 구조가 거의 없는 긴 텍스트에서는 일정 길이를 기준으로 나누는 방법이 관리하기 쉬울 수도 있습니다. 중요한 것은 특정 청킹 방식이 항상 우월하다고 생각하지 않는 것입니다. 문서 구조와 실제 질문 형태에 따라 어떤 단위가 검색에 적합한지를 비교하는 과정이 RAG 성능 개선의 핵심입니다.
- overlap은 문맥 단절을 줄일 수 있지만 너무 크면 비슷한 청크가 반복 검색될 수 있습니다
청크 사이에 일정 부분을 중복시키는 overlap은 경계에서 잘리는 정보를 보완하는 데 사용할 수 있습니다. 하지만 overlap을 크게 잡으면 같은 문장이 여러 청크에 반복되면서 검색 결과 상위에 비슷한 내용만 몰리는 문제도 생길 수 있습니다.
overlap을 조정할 때는 다음 내용을 확인할 수 있습니다.
- 청크 경계에서 핵심 조건이 분리되는 질문이 있는지 확인합니다.
- overlap을 늘렸을 때 필요한 문맥이 함께 검색되는지 비교합니다.
- 비슷한 청크가 상위 결과를 과도하게 차지하는지 살펴봅니다.
- 여러 검색 결과가 실제로 서로 다른 정보를 제공하는지 확인합니다.
- LLM에 전달되는 context가 중복으로 길어지지 않는지 살펴봅니다.
- overlap 변경 이후 같은 테스트 질문으로 다시 평가합니다.
예를 들어 한 문단의 마지막 문장에서 조건을 설명하고 다음 문단 첫 문장에서 예외 기준을 설명한다면 경계 부근의 overlap이 도움이 될 수 있습니다. 하지만 여러 청크가 거의 동일한 문장을 포함하면 top-5 검색 결과가 사실상 같은 내용을 반복하는 상황도 생길 수 있습니다. 이 경우 top-k를 늘려도 다양한 근거가 추가되지 않기 때문에 청킹 자체를 다시 조정하는 편이 적절할 수 있습니다.
- 청킹 변경은 최종 답변보다 검색 결과부터 비교해야 원인을 정확하게 볼 수 있습니다
청킹을 바꾼 뒤 LLM 답변만 확인하면 개선 이유를 구분하기 어렵습니다. 답변이 좋아진 것이 실제 검색 결과가 개선되었기 때문인지, 생성 모델이 우연히 더 잘 추론했기 때문인지 알기 어렵기 때문입니다.
- 기준 질문 구성: 실제 사용자 질문과 실패했던 질문을 일정하게 유지합니다.
- 기존 청킹 결과: 어떤 청크가 몇 번째 순위로 검색됐는지 기록합니다.
- 변경 청킹 결과: 동일 질문에서 검색 순위와 포함된 문맥을 다시 확인합니다.
- 관련성 비교: 정답 근거가 상위 결과에 들어왔는지 확인합니다.
- 최종 생성 비교: 검색 결과가 개선된 뒤 답변 품질까지 함께 살펴봅니다.
Microsoft Foundry의 Document Retrieval 평가도 검색 결과를 정답 문서와 비교해 NDCG와 Fidelity 같은 retrieval 지표를 측정할 수 있고, chunk size나 top-k 같은 검색 조건을 바꾸면서 파라미터를 비교할 수 있도록 설명하고 있습니다. 포트폴리오에서도 청킹을 수정해 성능을 개선했다보다 어떤 질문에서 어떤 청크가 검색되지 않았고, 청킹 변경 이후 관련 문서 순위가 어떻게 달라졌는지를 보여주면 개선 과정이 훨씬 구체적으로 보입니다.
임베딩은 텍스트를 벡터로 만드는 과정보다 질문과 문서가 어떤 의미 기준으로 가까워질지를 결정하는 요소입니다
- 임베딩 성능은 모델 이름보다 실제 질문과 문서의 의미 관계를 얼마나 잘 표현하는지 확인해야 합니다
RAG에서 임베딩 모델을 적용하면 문서와 질문이 벡터 형태로 변환되고 벡터 간 유사도를 이용해 관련 내용을 검색할 수 있습니다. 하지만 임베딩 모델을 사용했다는 사실만으로 검색 품질이 보장되는 것은 아닙니다.
임베딩을 점검할 때는 다음 내용을 확인할 수 있습니다.
- 실제 서비스 언어와 문서 언어에서 검색 품질이 유지되는지 확인합니다.
- 질문 표현과 문서 표현이 달라도 관련 내용을 찾는지 살펴봅니다.
- 전문 용어와 일반 표현 사이의 의미 관계를 확인합니다.
- 비슷하지만 다른 개념을 제대로 구분하는지 테스트합니다.
- 제품명이나 코드처럼 정확한 문자열 검색이 필요한 질문을 별도로 분리합니다.
- 모델 변경 전후 같은 테스트 질문으로 검색 결과를 비교합니다.
예를 들어 문서에는 퇴직급여라고 적혀 있고 사용자는 퇴직금이라고 질문할 수 있습니다. 의미 기반 검색이 잘 작동하면 표현이 달라도 관련 내용을 찾을 가능성이 높습니다. 반대로 A100과 A101처럼 한 글자 차이가 중요한 제품 코드에서는 의미 유사도보다 정확한 문자열 매칭이 더 중요할 수 있습니다. Microsoft Foundry는 임베딩을 콘텐츠의 숫자 표현으로 설명하며 벡터 유사도 검색에서 사용한다고 정리하고 있습니다. 따라서 임베딩 평가도 평균적인 검색 품질만 보는 것이 아니라 어떤 유형의 질문에서는 잘 작동하고 어떤 질문에서는 다른 검색 방식이 필요한지를 구분하는 편이 좋습니다.
- 문서 임베딩과 질문 임베딩은 같은 의미 공간에서 비교된다는 점을 이해해야 합니다
벡터 검색은 문서와 질문을 숫자로 변환한 뒤 서로 가까운 항목을 찾는 방식입니다. 이 과정에서 문서와 질문을 서로 다른 기준으로 전처리하거나 의미 구조가 크게 달라지면 검색 결과에 영향을 줄 수 있습니다.
- 전처리 일관성: 문서에 적용한 기본적인 텍스트 정리 방식과 질문 처리 방식을 일관되게 유지하는 편이 좋습니다.
- 언어 일관성: 다국어 문서와 질문이 섞이는 경우 사용한 임베딩 모델이 해당 언어 관계를 충분히 표현하는지 확인할 필요가 있습니다.
- 모델 일관성: 인덱스를 만든 임베딩 기준과 실제 검색에서 사용하는 질문 벡터가 호환되는 구조여야 합니다.
- 도메인 일관성: 일반 문장과 전문 약어가 함께 존재한다면 실제 업무 질문으로 검색 품질을 검증해야 합니다.
- 평가 일관성: 모델을 변경할 때는 기존과 같은 질문 세트로 retrieval 결과를 다시 측정해야 합니다.
Microsoft의 RAG 정보검색 가이드도 질문을 임베딩하기 전에 문서 청크에 적용했던 것과 같은 전처리를 적용하는 것이 중요하다고 안내하고 있습니다. 이런 내용을 프로젝트에 포함하면 임베딩을 단순 API 호출로 사용한 것이 아니라 문서와 질문을 비교 가능한 검색 표현으로 관리한 경험으로 설명할 수 있습니다.
- 전문 용어와 고유명사 질문을 따로 테스트하면 임베딩의 한계를 더 쉽게 발견할 수 있습니다
벡터 검색은 의미적으로 비슷한 표현을 찾는 데 강점을 가질 수 있지만 모든 검색이 의미 기반으로 해결되는 것은 아닙니다. 정확한 이름과 번호가 중요한 질문은 별도의 평가가 필요합니다.
임베딩 테스트 셋에서는 다음 질문을 분리할 수 있습니다.
- 같은 의미를 다른 표현으로 질문하는 사례를 포함합니다.
- 전문 용어와 일반 표현이 함께 사용되는 질문을 만듭니다.
- 서로 비슷하지만 다른 개념을 구별해야 하는 질문을 포함합니다.
- 제품 코드와 문서 번호처럼 정확한 값이 중요한 질문을 추가합니다.
- 숫자와 날짜가 핵심인 검색을 별도로 확인합니다.
- 짧은 한두 단어 질문과 긴 자연어 질문을 나누어 비교합니다.
Azure AI Search의 현재 하이브리드 검색 문서도 벡터 검색은 의미가 유사한 콘텐츠를 찾는 데 장점이 있지만 제품 코드와 전문 용어, 날짜, 이름처럼 정확한 일치가 중요한 경우에는 키워드 검색이 더 효과적일 수 있다고 설명합니다. 이 점 때문에 임베딩 성능이 낮다고 판단하기 전에 질문 자체가 의미 검색에 적합한 유형인지도 확인해야 합니다.
- 임베딩 모델 변경은 검색 평가와 인덱스 운영까지 함께 고려해야 합니다
더 새로운 임베딩 모델을 적용한다고 해서 실제 RAG 성능이 자동으로 좋아지는 것은 아닙니다. 기존 데이터셋에서는 현재 모델이 충분히 잘 작동할 수도 있고, 새로운 모델에서 특정 질문 유형의 검색 순위가 오히려 달라질 수도 있습니다.
- 기존 모델 기준: 현재 실패 질문과 정상 질문에서 관련 문서 순위를 기록합니다.
- 새 모델 비교: 동일한 문서를 새로운 임베딩으로 구성하고 같은 질문을 다시 검색합니다.
- 검색 품질 비교: 필요한 문서의 순위와 관련 없는 문서의 유입 정도를 살펴봅니다.
- 운영 영향 비교: 벡터 생성과 인덱싱 작업, 저장공간과 처리시간 변화를 확인합니다.
- 최종 선택: 실제 사용 질문에서 의미 있는 개선이 있는지에 따라 모델 변경 여부를 판단합니다.
이런 과정이 있어야 최신 임베딩 모델로 교체했다는 기술 변경을 넘어 왜 기존 모델을 바꿨고 어느 질문에서 개선 효과가 있었는지를 설명할 수 있습니다. RAG 포트폴리오에서는 모델 이름보다 이런 비교 근거가 더 중요한 차별점이 될 수 있습니다.
검색은 만들어진 청크와 임베딩 가운데 실제 답변에 필요한 근거를 상위에 배치하는 단계입니다
- 검색 품질은 문서가 검색됐는가 보다 필요한 문서가 상위 결과에 들어왔는지가 중요합니다
벡터 DB에서 관련 문서가 검색됐다고 해도 순위가 너무 낮으면 LLM에 전달되지 않을 수 있습니다. top-3만 사용하는 시스템에서 필요한 문서가 7번째에 있다면 인덱스 안에는 정답이 있어도 실제 생성 단계에서는 사용할 수 없습니다.
검색 단계에서는 다음 내용을 확인할 수 있습니다.
- 정답 근거 문서가 몇 번째 순위로 검색되는지 기록합니다.
- top-k를 변경했을 때 관련 문서 포함률이 어떻게 달라지는지 확인합니다.
- 상위 결과에 비슷한 문서만 반복되는지 살펴봅니다.
- 관련성이 낮은 문서가 높은 점수를 받는 질문을 분류합니다.
- 메타데이터 필터가 검색 범위를 지나치게 제한하지 않는지 확인합니다.
- 검색 결과와 최종 답변 오류를 따로 기록합니다.
예를 들어 10개 문서를 검색하면 필요한 문서가 포함되지만 top-3에서는 빠진다면 단순히 top-k를 크게 만드는 방법을 생각할 수 있습니다. 하지만 너무 많은 context를 LLM에 전달하면 관련 없는 내용도 늘어나고 응답시간이나 비용이 증가할 수 있기 때문에 검색 순위 자체를 개선하는 방법도 함께 검토해야 합니다. Microsoft의 현재 RAG 가이드도 검색 단계에서 벡터 가중치와 임계값, semantic ranking 등의 검색 조건을 조정해 관련성을 높일 수 있다고 안내합니다.
- 벡터 검색과 키워드 검색은 찾는 정보의 특성이 다르기 때문에 함께 비교할 필요가 있습니다
RAG를 만들면 벡터 검색을 기본 방식으로 사용하는 경우가 많습니다. 하지만 질문에 정확한 용어나 코드가 포함되는 환경에서는 키워드 검색과 벡터 검색을 함께 사용하는 하이브리드 방식이 더 적합할 수 있습니다.
- 벡터 검색 중심: 질문과 표현이 다르더라도 의미가 유사한 문서를 찾는 데 활용할 수 있습니다.
- 키워드 검색 중심: 제품명과 코드, 정확한 용어처럼 문자열 일치가 중요한 검색에 강점을 가질 수 있습니다.
- 하이브리드 검색 중심: 키워드와 벡터 검색을 함께 실행해 두 검색 방식의 후보를 결합할 수 있습니다.
- 필터 중심: 부서와 날짜, 문서 종류처럼 명확한 조건으로 검색 대상을 먼저 제한할 수 있습니다.
- 재정렬 중심: 넓게 검색한 후보를 다시 질문과 비교해 더 관련성 높은 순서로 배치할 수 있습니다.
Azure AI Search의 하이브리드 검색은 full-text와 vector query를 병렬로 실행하고 RRF를 이용해 결과를 하나의 순위로 결합합니다. 공식 문서에서도 벡터 검색과 키워드 검색이 서로 다른 실패 상황을 보완할 수 있다고 설명합니다. 따라서 검색 개선에서는 벡터 DB를 사용했다는 사실보다 실제 질문 유형에 어떤 검색 조합이 적합했는지 비교한 과정이 중요합니다.
- top-k와 reranking은 많이 검색하는 것과 좋은 근거를 전달하는 것의 균형을 조절하는 요소입니다
검색 결과를 많이 가져오면 필요한 정보가 포함될 가능성은 높아질 수 있습니다. 하지만 관련성이 낮은 청크까지 함께 들어가면 최종 context가 불필요하게 길어질 수 있기 때문에 검색량과 정확도의 균형이 필요합니다.
검색 튜닝에서는 다음 내용을 확인할 수 있습니다.
- top-k를 작게 설정했을 때 정답 문서가 빠지는 질문을 확인합니다.
- top-k를 늘렸을 때 관련 없는 문서가 얼마나 추가되는지 살펴봅니다.
- 검색 후보를 넓힌 뒤 reranking을 적용한 결과를 비교합니다.
- 정답 문서가 상위 몇 번째까지 올라오는지 기록합니다.
- 응답시간과 검색 처리량 변화도 함께 확인합니다.
- 동일한 질문 세트를 이용해 설정 전후 결과를 비교합니다.
Microsoft의 RAG 검색 가이드는 reranking이 벡터 유사도나 키워드 점수만으로는 충분히 구분하기 어려운 후보들을 질문 관점에서 다시 평가하는 데 도움이 될 수 있지만 추가 처리로 인해 지연시간도 늘어날 수 있다고 설명합니다. 이런 비교가 포트폴리오에 포함되면 top-k 5 사용, reranker 적용이라는 설정값보다 왜 해당 조건을 선택했고 검색 품질과 지연시간이 어떻게 달라졌는지를 설명할 수 있습니다.
- 검색 개선은 최종 답변 점수와 retrieval 점수를 따로 봐야 병목을 찾기 쉽습니다
RAG 결과가 틀리면 생성 모델의 문제인지 검색 문제인지 먼저 구분해야 합니다. 검색된 문서가 정확한데 답변이 잘못됐다면 생성 단계의 프롬프트나 모델 사용을 살펴볼 수 있고, 필요한 문서 자체가 검색되지 않았다면 retrieval부터 수정해야 합니다.
- 검색 실패 상태: 정답 문서가 상위 검색 결과에 없습니다.
- 검색 성공·생성 실패 상태: 필요한 context는 제공됐지만 LLM이 잘못 해석하거나 내용을 추가했습니다.
- 부분 검색 상태: 필요한 정보 가운데 일부만 검색되어 불완전한 답변이 생성됩니다.
- 과잉 검색 상태: 너무 많은 관련 없는 context가 들어와 모델의 판단을 방해합니다.
- 정상 상태: 필요한 근거가 검색되고 생성 답변도 해당 context에 충실합니다.
Microsoft Foundry의 RAG evaluator는 retrieval을 process evaluation으로, Groundedness와 Relevance 등을 system evaluation으로 구분합니다. 즉 검색 품질과 생성 결과를 별도로 측정해 어느 단계가 병목인지 확인하는 구조입니다. RAG 성능 개선에서도 이 구분이 중요합니다. 최종 답변 하나만 평가하기보다 검색 단계와 생성 단계를 분리하면 청킹과 임베딩, 검색 설정 가운데 실제로 손대야 할 부분을 더 정확하게 찾을 수 있습니다.
- conclusion
RAG 성능이 기대보다 낮을 때 가장 먼저 LLM 모델이나 프롬프트를 바꾸는 방식은 문제의 원인을 놓칠 수 있습니다. RAG는 외부 문서에서 필요한 근거를 찾아 모델에게 전달하는 구조이기 때문에 검색 이전 단계에서 이미 필요한 정보가 빠져 있다면 생성 모델이 정확한 답변을 만들기 어렵습니다. 청킹에서는 문서를 얼마나 작게 자르는 지보다 하나의 질문에 필요한 문맥이 검색 가능한 단위로 유지되는지를 확인해야 합니다. 청크가 지나치게 크면 여러 주제가 하나의 벡터에 섞일 수 있고, 너무 작으면 조건과 설명이 분리될 수 있습니다. overlap 역시 무조건 크게 설정하기보다 문맥 단절과 중복 검색 사이의 균형을 확인해야 합니다. 임베딩에서는 특정 모델을 사용했다는 사실보다 실제 질문과 문서의 의미 관계를 잘 표현하는지를 확인해야 합니다. 표현이 달라도 같은 의미를 찾아야 하는 질문과 코드나 날짜처럼 정확한 일치가 중요한 질문은 특성이 다릅니다. 따라서 벡터 검색만으로 모든 질문을 해결하려 하기보다 실제 데이터와 질문 형태를 기준으로 임베딩의 강점과 한계를 구분해야 합니다. 검색에서는 관련 문서가 어딘가에 존재한다는 사실이 아니라 LLM에 전달되는 상위 결과에 필요한 근거가 포함되는지가 중요합니다. 벡터와 키워드 검색을 비교하고, 필요하면 하이브리드 검색이나 reranking을 적용하며, top-k를 조정한 뒤 같은 질문으로 결과를 다시 측정해야 합니다. Azure AI Search의 현재 가이드 역시 RAG 검색 품질을 높이기 위해 chunking과 embedding뿐 아니라 hybrid query, semantic ranking, vector parameter tuning 등을 함께 다루고 있습니다.
최종적으로 확인할 항목은 다음과 같습니다.
- 질문에 필요한 정보가 하나의 적절한 청크 안에 유지되는지 확인합니다.
- chunk size와 overlap을 변경한 뒤 같은 질문에서 검색 결과를 비교합니다.
- 질문과 문서의 표현이 달라도 관련 문서가 검색되는지 살펴봅니다.
- 고유명사와 제품 코드처럼 정확한 매칭이 필요한 질문을 따로 점검합니다.
- 필요한 문서가 실제 top-k 안에 들어오는지 확인합니다.
- retrieval 품질과 최종 생성 품질을 분리해서 평가했는지 살펴봅니다.
RAG 성능 개선 흐름은 다음과 같이 연결할 수 있습니다.
- 대표 질문 수집 → 실패 질문 분류 → 검색된 context 확인 → 정답 문서 존재 여부 확인 → 청크 구조 점검 → chunk size·overlap 비교 → 임베딩 검색 결과 비교 → 전문 용어·고유명사 질문 분리 → 벡터·키워드·하이브리드 검색 비교 → top-k 조정 → 필요시 reranking 적용 → retrieval 지표 측정 → 최종 Groundedness·Relevance 평가 → 변경 전후 동일 질문 재검증 → 지연시간·비용 확인 → 최종 설정 기록 → 포트폴리오와 면접 연결
결국 RAG 성능 개선은 설정값을 하나씩 무작정 바꾸는 과정이 아닙니다. 청킹에서는 검색에 필요한 문맥 단위를 만들고, 임베딩에서는 질문과 문서를 비교할 의미 표현을 구성하며, 검색에서는 실제 답변에 필요한 근거를 상위 결과로 올릴 수 있어야 합니다. 이 세 영역을 같은 테스트 질문과 검색 평가 기준으로 반복해서 비교한다면 RAG 성능을 개선했다는 추상적인 설명을 넘어 어느 단계에서 문제가 발생했고 어떤 변경으로 검색 품질이 달라졌는지를 포트폴리오와 면접에서도 더 구체적으로 설명할 수 있습니다.