Three Design Decisions That Shaped the Enterprise RAG Retrieval Pipeline

개요

Enterprise RAG의 검색 파이프라인은 기술 선택뿐만 아니라 구조적 결정이 프로덕션 환경에서의 시스템 작동 여부를 결정하며, 본 글은 이러한 세 가지 주요 구조적 설계 결정과 그 배경, 수용된 비용을 문서화합니다.

주요 내용

* 의사 결정 1: 의미론적 검색 이전의 어휘 검색 (Lexical retrieval before semantic)
* 순서상의 결정: 초기 구현은 로컬 SQLite 청크 저장소를 사용한 토큰 코사인 유사도(어휘 검색)를 기본으로 하며, 이는 의미론적 유사성을 포착하지 못하지만 접근 제어 유효성 검사를 위해 결정론적 검색 기준선을 확보하는 데 필수적입니다.
* 제약: 임베딩 모델 업데이트, 벡터 인덱스 재구축, 근사 최근접 이웃 알고리즘의 비결정성으로 인한 검색 결과 변동은 평가 세트를 신뢰할 수 없게 만들 수 있습니다. 어휘 검색은 동일한 문서 코퍼스와 쿼리에 대해 항상 동일한 순위의 청크 목록을 반환하여 평가 세트가 안정적인 회귀 테스트 역할을 하도록 합니다.
* 수용된 비용: 어휘 검색은 "headcount reduction"과 같은 쿼리에 대해 "workforce restructuring"이라는 문구를 사용하는 청크를 토큰 중복이 없으면 검색하지 못합니다. Azure AI Search 어댑터는 프로덕션에서 의미론적 및 하이브리드 쿼리 모드를 제공합니다.
* 의사 결정 2: API 기반 대시보드 (API-backed dashboard)
* 아키텍처 경계: Streamlit 대시보드는 데이터베이스에 직접 접근하는 대신 FastAPI API 계층과 연결되며, 모든 대시보드 작업은 인증된 API 호출을 통해 이루어집니다.
* 제약: 컨테이너화되거나 클라우드 환경에서 직접 데이터베이스 접근이 가능한 대시보드는 자격 증명 배포 문제를 야기합니다. API 기반 대시보드는 API URL과 관리 토큰만 필요하며, API가 권한을 부여하고 데이터베이스 자격 증명은 API 컨테이너에만 유지됩니다.
* 수용된 비용: 직접 데이터베이스 접근 대비 네트워크 홉이 한 번 더 추가되지만, 동일 가상 네트워크 내에서 API를 쿼리하는 경우 무시할 수 있으며, API가 올바른 데이터를 반환함을 보장하는 연속 통합의 이점을 제공합니다.
* 의사 결정 3: 라이브 API 엔드포인트로서의 평가 실행기 (Evaluation runner as a live API endpoint)
* 통합된 파이프라인 테스트: 평가 실행기는 POST /eval/run API 엔드포인트로 노출되어 실시간 쿼리 파이프라인을 통해 평가 세트를 실행하고 직접 메트릭을 반환합니다.
* 제약: 평가 스크립트가 접근 제어 계층을 우회하면 접근 제어 실패를 감지할 수 없습니다. POST /eval/run은 내부적으로 POST /query를 호출하여 인증 처리, 역할 필터, 검색, 생성, 인용 조립 등 전체 파이프라인을 테스트합니다.
* 수용된 비용: 프로덕션 데이터베이스에서 실시간 평가가 실행되므로 고트래픽 환경에서는 부하를 야기할 수 있습니다. 낮은 트래픽 시간이나 스테이징 환경에서 평가를 실행하는 것으로 완화할 수 있으며, 현재 평가는 반복 가능한 접근 제어 확인에 맞춰져 있습니다.
* 아직 결정하지 않은 사항: 역할 메타데이터가 문서 프런트 매터에 임베딩되어 있지만, 프로덕션에서는 ID 공급자(Entra ID 클레임 또는 OIDC 베어러 토큰 속성)에서 역할 컨텍스트가 나와야 하며, Entra ID 역할 클레임 통합은 실제 Azure 테넌트가 필요하여 아직 완료되지 않았습니다.

시사점

Enterprise RAG 시스템의 성공적인 프로덕션 배포는 단순한 기술 선택을 넘어, 결정론적 평가를 위한 어휘 검색 우선 적용, 보안 및 확장성을 위한 API 기반 아키텍처, 그리고 실제 사용자 경로를 검증하는 통합 평가 실행기 등의 구조적 설계 결정에 달려있습니다.