본문 바로가기
it

Azure AI Search RAG 오답 줄이기: 하이브리드 검색과 preFilter 점검

by 메르세데쓰 2026. 7. 30.
반응형

RAG 답변에 출처가 붙어 있어도 엉뚱한 문서를 근거로 삼는 경우가 있습니다. Azure AI Search에서 키워드와 벡터를 함께 검색하고, 메타데이터를 생성 전에 거르는 순서로 검색 품질과 문서 접근 범위를 점검하는 방법을 정리합니다.

 

문서와 데이터베이스에서 키워드·벡터 검색을 병렬 실행하고 메타데이터 필터를 거쳐 결과 순위를 만드는 RAG 검색 흐름

 

핵심 질문: 벡터 검색의 top-k만 늘리면 RAG 오답이 줄어들까?

아닙니다. top-k를 늘리면 후보는 많아지지만 오래된 문서, 다른 조직의 문서, 상태가 다른 문서까지 생성 모델에 전달될 수 있습니다. 먼저 키워드 검색과 벡터 검색을 병렬로 실행하는 하이브리드 검색으로 재현율을 확보하고, tenant_id·status 같은 메타데이터를 preFilter로 제한해야 합니다. 권한 조건은 관련성 조정이 아니라 문서 접근 제어이므로 모든 검색 경로에 빠짐없이 적용해야 합니다.

출처가 있는데도 답이 틀리는 이유

벡터 검색은 질문과 의미가 비슷한 문서를 찾는 데 강하지만 제품 코드, 오류 번호, 날짜, 고유 명칭의 정확한 일치에는 약할 수 있습니다. 반대로 키워드 검색은 정확한 문자열에 강하지만 사용자가 문서와 다른 표현을 쓰면 관련 문서를 놓칠 수 있습니다.

Azure AI Search의 하이브리드 검색은 BM25 기반 전체 텍스트 검색과 벡터 검색을 병렬 실행한 뒤 Reciprocal Rank Fusion(RRF)으로 순위를 합칩니다. 따라서 한쪽 점수만 높이는 것보다 두 검색 결과가 실제 질문에 어떤 후보를 보태는지 분리해 보는 편이 원인 파악에 유리합니다.

적용 환경과 먼저 확인할 인덱스 필드

아래 예시는 Azure AI Search REST API 2026-04-01 안정 버전을 기준으로 합니다. 검색 서비스와 인덱스가 이미 있고, 질문을 인덱스와 같은 임베딩 공간의 벡터로 변환할 수 있어야 합니다. 벡터 값은 사용 중인 임베딩 구성에 맞게 애플리케이션에서 생성합니다.

  • content: 원문 청크. 검색과 응답 표시를 위해 searchable·retrievable로 구성
  • contentVector: content와 대응하는 벡터 필드
  • tenant_id, status, source_type: 정확히 일치시킬 비벡터 메타데이터. filterable로 구성
  • document_id, chunk_id, updated_at: 출처 추적과 최신성 검증에 필요한 필드
  • group_ids 또는 ACL 필드: 요청자의 문서 접근 범위를 제한할 필드

벡터 필드 자체에는 필터를 적용하지 않습니다. Microsoft 문서에 따르면 필터는 같은 검색 문서에 있는 문자열·숫자 같은 filterable 비벡터 필드를 대상으로 합니다. 필터가 필요해진 뒤 인덱스에 필드를 덧붙이기보다, 수집 단계에서 문서 상태와 권한 메타데이터를 청크마다 함께 저장하는 편이 안전합니다.

하이브리드 검색과 preFilter 요청 예시

다음 요청은 게시 상태인 특정 테넌트의 문서만 대상으로 키워드와 벡터 검색을 함께 실행합니다. Microsoft Entra ID를 사용한다면 Search Index Data Reader 등 필요한 데이터 평면 역할과 토큰 발급 구성을 먼저 완료해야 합니다. 관리자 키를 클라이언트 코드나 로그에 넣지 마십시오.

POST https://[service-name].search.windows.net/indexes/[index-name]/docs/search?api-version=2026-04-01
Content-Type: application/json
Authorization: Bearer [access-token]

{
  "search": "ORA-01555 원인과 확인 순서",
  "filter": "tenant_id eq 'tenant-a' and status eq 'published'",
  "vectorFilterMode": "preFilter",
  "vectorQueries": [
    {
      "kind": "vector",
      "vector": [QUERY_VECTOR],
      "fields": "contentVector",
      "k": 50
    }
  ],
  "queryType": "semantic",
  "semanticConfiguration": "rag-semantic-config",
  "select": "document_id,chunk_id,title,content,updated_at",
  "top": 8,
  "debug": "all"
}

semanticConfiguration은 인덱스에 실제로 만든 이름으로 바꿔야 합니다. 의미 순위화를 사용하지 않는 환경이라면 queryType과 semanticConfiguration을 제거한 상태부터 비교하십시오. Microsoft는 하이브리드 검색에 의미 순위화를 결합할 때 순위화 입력을 충분히 주기 위해 벡터 k를 50으로 설정하도록 안내합니다. 최종 생성 모델에는 top 8처럼 더 작은 수의 검증된 청크만 전달할 수 있습니다.

검색 품질을 검증하는 순서

  1. 질문 20~50개와 정답 문서 ID를 준비합니다. 정상 질문뿐 아니라 오류 코드, 날짜, 동의어, 문서에 없는 질문을 섞습니다.
  2. 키워드만, 벡터만, 하이브리드 순서로 같은 질문을 실행해 정답 문서가 상위 후보에 들어오는지 비교합니다.
  3. 필터 없이 결과를 기록한 뒤 tenant_id와 status를 preFilter로 추가합니다. 결과가 0건이면 생성 모델이 추측하게 두지 말고 “근거 문서 없음”으로 처리합니다.
  4. debug 결과와 document_id·chunk_id를 로그에 남기되 원문, 토큰, 개인정보는 최소화합니다.
  5. 검색 결과와 최종 답변을 분리 평가합니다. 검색 단계에서 정답 문서가 없으면 프롬프트 수정만으로 해결할 수 없습니다.

하이브리드 결과의 @search.score는 RRF 점수이며, 벡터 단독 검색 점수나 BM25 점수와 범위가 다릅니다. 서로 다른 검색 방식의 임계값을 그대로 복사하지 말고 평가 질문으로 별도 기준을 잡아야 합니다. 의미 순위화를 사용하면 @search.rerankerScore도 따로 확인합니다.

자주 하는 실수와 롤백 기준

  • postFilter는 벡터 후보를 찾은 뒤 거르므로 선택적인 필터와 작은 k에서 필요한 문서를 놓칠 수 있습니다. preFilter는 재현율에 유리하지만 매우 선택적인 조건에서는 CPU와 지연 시간이 늘 수 있어 부하 시험이 필요합니다.
  • strictPostFilter와 벡터별 filterOverride는 2026년 7월 확인 기준 미리 보기 기능이 포함됩니다. SLA가 필요한 운영 환경에는 안정 버전 기능을 우선하고, 벡터별 필터가 전역 보안 필터를 덮어쓰지 않는지 확인해야 합니다.
  • 프롬프트에 “권한 없는 문서는 무시하라”고 쓰는 것은 접근 제어가 아닙니다. 권한 필터 또는 문서 수준 ACL/RBAC를 검색 단계에서 집행해야 합니다.
  • 장애가 생기면 기존 검색 요청으로 되돌릴 수 있도록 변경 전 쿼리, 인덱스 스키마, 평가 결과를 보관합니다. 롤백 중에도 tenant_id와 권한 필터는 제거하지 않습니다.

정리와 다음 확인

RAG의 오답을 줄이는 첫 단계는 생성 모델 교체가 아니라 검색 후보를 관찰하는 것입니다. 키워드와 벡터 검색을 하이브리드로 결합하고, 문서 상태·조직·권한을 preFilter로 제한한 뒤, 정답 문서가 상위 후보에 들어오는지 평가하십시오. 그 다음에 청킹, 의미 순위화, k와 top, 프롬프트를 순서대로 조정해야 원인과 효과를 구분할 수 있습니다.

검증 기준일: 2026-07-30
적용 환경: Azure AI Search REST API 2026-04-01 안정 버전, classic RAG 하이브리드 검색

공식 문서와 최신 자료를 교차 확인해 정리했으며 자료 조사와 초안 구성에 자동화 도구의 도움을 받았습니다.

출처

반응형

댓글