RAG(검색 증강 세대)는 인터넷에서 공개적으로 사용할 수 없는 독점 정보 또는 기타 정보를 추론하는 데 기본 모델을 사용하는 애플리케이션을 빌드하는 패턴입니다. 일반적으로 클라이언트 애플리케이션은 벡터 데이터베이스와 같은 데이터 저장소에서 관련 정보를 가져오는 오케스트레이션 계층을 호출합니다. 오케스트레이션 계층은 해당 데이터를 컨텍스트의 일부로 기본 모델에 접지 데이터로 전달합니다.
다중 테넌트 솔루션은 여러 고객이 사용하며, 각 고객(테넌트)은 동일한 조직, 회사 또는 그룹의 여러 사용자로 구성됩니다. 다중 테넌트 시나리오에서는 테넌트 또는 테넌트 내의 개인이 볼 수 있는 권한이 있는 접지 데이터만 통합할 수 있는지 확인해야 합니다.
사용자가 보려는 정보만 액세스하도록 하는 것 외에는 다중 테넌트 문제가 있지만, 이 문서에서는 다중 테넌트의 측면에 중점을 둡니다. 이 문서는 단일 테넌트 RAG 아키텍처의 개요로 시작하고, RAG를 사용한 다중 테넌트와 관련한 과제와 따라야 할 몇 가지 일반적인 접근 방식을 설명하고, 안전한 다중 테넌트 고려 사항 및 권장 사항으로 마무리합니다.
참고 항목
이 문서에서는 Azure OpenAI On Your Data와 같은 일부 Azure OpenAI 관련 기능에 대해 설명합니다. 즉, 이 문서에서 설명하는 대부분의 원칙은 호스트 플랫폼에 관계없이 대부분의 기본 AI 모델에 적용됩니다.
오케스트레이터를 사용하는 단일 테넌트 RAG 아키텍처
그림 1 단일 테넌트 RAG 아키텍처
워크플로
이 단일 테넌트 RAG 아키텍처에서 오케스트레이터는 데이터 저장소에서 관련 독점 테넌트 데이터를 가져와서 기본 모델에 대한 접지 데이터로 제공해야 합니다. 다음은 개략적인 워크플로입니다.
- 사용자가 지능형 웹 애플리케이션에 요청을 발급합니다.
- ID 공급자가 요청자를 인증합니다.
- 지능형 애플리케이션은 사용자 쿼리 및 사용자에 대한 권한 부여 토큰을 사용하여 오케스트레이터 API를 호출합니다.
- 오케스트레이션 논리는 요청에서 사용자의 쿼리를 추출하고 적절한 데이터 저장소를 호출하여 쿼리에 대한 관련 접지 데이터를 가져옵니다. 접지 데이터는 다음 단계에서 Azure OpenAI에 노출된 모델과 같이 기본 모델로 전송되는 프롬프트에 추가됩니다.
- 오케스트레이션 논리는 기본 모델의 추론 API에 연결하고 검색된 접지 데이터를 포함하는 프롬프트를 보냅니다. 결과는 지능형 애플리케이션에 반환됩니다.
RAG의 세부 정보에 대한 자세한 내용은 RAG 솔루션 디자인 및 개발을 참조 하세요.
직접 데이터 액세스를 사용하는 단일 테넌트 RAG 아키텍처
단일 테넌트 RAG 아키텍처의 변형은 Azure Search와 같은 데이터 저장소와 직접 통합하는 Azure OpenAI 서비스의 기능을 활용합니다. 이 아키텍처에서는 고유한 오케스트레이터가 없거나 오케스트레이터의 책임이 적습니다. Azure OpenAI API는 데이터 저장소를 호출하여 접지 데이터를 가져오고 해당 데이터를 언어 모델에 전달할 책임이 있습니다. 따라서 가져올 접지 데이터와 해당 데이터의 관련성을 덜 제어할 수 있습니다.
참고 항목
Microsoft에서 관리하는 Azure OpenAI 서비스는 데이터 저장소와 통합됩니다. 모델 자체는 데이터 저장소와 통합되지 않습니다. 모델은 오케스트레이터가 데이터를 가져오는 경우와 똑같은 방식으로 접지 데이터를 받습니다.
그림 2. Azure OpenAI 서비스에서 직접 데이터 액세스를 사용하는 단일 테넌트 RAG 아키텍처
워크플로
이 RAG 아키텍처에서 기본 모델을 제공하는 서비스는 데이터 저장소에서 적절한 소유 테넌트 데이터를 가져오고 해당 데이터를 기본 모델에 대한 접지 데이터로 사용해야 합니다. 다음은 대략적인 워크플로입니다(기울임꼴로 구성된 단계는 오케스트레이터 워크플로를 사용하는 단일 테넌트 RAG 아키텍처와 동일합니다.)
- 사용자가 지능형 웹 애플리케이션에 요청을 발급합니다.
- ID 공급자가 요청자를 인증합니다.
- 그런 다음 지능형 애플리케이션은 사용자 쿼리를 사용하여 Azure OpenAI 서비스를 호출합니다.
- Azure OpenAI 서비스는 Azure AI Search 및 Azure Blob Storage와 같은 지원되는 데이터 저장소에 연결하여 접지 데이터를 가져옵니다. 접지 데이터는 Azure OpenAI 서비스가 OpenAI 언어 모델을 호출할 때 컨텍스트의 일부로 사용됩니다. 결과는 지능형 애플리케이션에 반환됩니다.
다중 테넌트 솔루션에서 이 아키텍처를 고려하려면 접지 데이터에 직접 액세스하는 Azure OpenAI와 같은 서비스는 솔루션에 필요한 다중 테넌트 논리를 지원해야 합니다.
RAG 아키텍처의 다중 테넌트
다중 테넌트 솔루션에서 테넌트 데이터는 테넌트별 저장소에 있거나 다중 테넌트 저장소의 다른 테넌트와 공존할 수 있습니다. 테넌트 간에 공유되는 저장소에 데이터가 있을 수도 있습니다. 사용자에게 볼 권한이 있는 데이터만 접지 데이터로 사용해야 합니다. 사용자는 볼 수 있는 권한이 있는 데이터만 볼 수 있도록 필터링 규칙이 적용된 테넌트의 공통(모든 테넌트) 데이터 또는 데이터만 볼 수 있어야 합니다.
그림 3: RAG 아키텍처 - 여러 데이터 저장소 테넌트 사용
워크플로
이 워크플로는 4단계를 제외한 오케스트레이터 를 사용하는 단일 테넌트 RAG 아키텍처와 동일합니다.
- 사용자가 지능형 웹 애플리케이션에 요청을 발급합니다.
- ID 공급자가 요청자를 인증합니다.
- 지능형 애플리케이션은 사용자 쿼리 및 사용자에 대한 권한 부여 토큰을 사용하여 오케스트레이터 API를 호출합니다.
- 오케스트레이션 논리는 요청에서 사용자의 쿼리를 추출하고 적절한 데이터 저장소를 호출하여 쿼리에 대한 테넌트 권한이 부여된 관련 접지 데이터를 가져옵니다. 접지 데이터는 다음 단계에서 Azure OpenAI로 전송되는 프롬프트에 추가됩니다. 다음 단계 중 일부 또는 전부가 관련되어 있습니다.
- 오케스트레이션 논리는 적절한 테넌트별 데이터 저장소 인스턴스에서 접지 데이터를 가져오며, 잠재적으로 보안 필터링 규칙을 적용하여 사용자에게 액세스 권한이 부여된 데이터만 반환합니다.
- 오케스트레이션 논리는 다중 테넌트 데이터 저장소에서 적절한 테넌트의 접지 데이터를 가져오며, 잠재적으로 보안 필터링 규칙을 적용하여 사용자에게 액세스 권한이 부여된 데이터만 반환합니다.
- 오케스트레이션 논리는 테넌트 간에 공유되는 데이터 저장소에서 데이터를 가져옵니다.
- 오케스트레이션 논리는 기본 모델의 추론 API에 연결하고 검색된 접지 데이터를 포함하는 프롬프트를 보냅니다. 결과는 지능형 애플리케이션에 반환됩니다.
RAG의 다중 테넌트 데이터에 대한 디자인 고려 사항
저장소 격리 모델 선택
다중 테넌트 시나리오에서는 스토리지 및 데이터에 대한 두 가지 주요 아키텍처 접근 방식인 테넌트당 저장소 및 다중 테넌트 저장소가 있습니다. 이러한 접근 방식은 테넌트 간에 공유되는 데이터를 포함하는 저장소에 추가됩니다. 이 섹션에서는 각 방법을 다룹니다. 다중 테넌트 솔루션은 이러한 방법의 조합을 사용할 수 있습니다.
테넌트당 스토어
테넌트당 저장소에서 이름에서 알 수 있듯이 각 테넌트에는 고유한 저장소가 있습니다. 이 방법의 장점은 데이터와 성능 격리를 모두 포함합니다. 각 테넌트의 데이터는 자체 저장소에 캡슐화됩니다. 대부분의 데이터 서비스에서 격리된 저장소는 다른 테넌트의 시끄러운 인접 문제에 취약하지 않습니다. 또한 이 방법은 저장소 배포의 전체 비용이 단일 테넌트에 기인할 수 있으므로 비용 할당을 간소화합니다.
이 방법의 과제에는 더 높은 관리 및 운영 오버헤드와 더 높은 비용이 포함될 수 있습니다. 이 접근 방식은 기업-소비자 시나리오와 같은 소규모 테넌트가 많은 경우 고려해서는 안 됩니다. 이 방법은 서비스 제한에 대해서도 실행할 수 있습니다.
이 AI 시나리오의 컨텍스트에서 테넌트당 저장소는 컨텍스트에 관련성을 가져오는 데 필요한 접지 데이터가 테넌트에 대한 접지 데이터만 포함하는 기존 또는 새 데이터 저장소에서 가져온다는 것을 의미합니다. 이 토폴로지에서 데이터베이스 인스턴스는 테넌트당 사용되는 판별자입니다.
다중 테넌트 저장소
다중 테넌트 저장소에서는 여러 테넌트 데이터가 동일한 저장소에 공존합니다. 이 방법의 장점으로는 비용 최적화 가능성, 테넌트별 저장소 모델보다 더 많은 수의 테넌트를 처리할 수 있는 기능, 더 낮은 수의 저장소 인스턴스로 인한 관리 오버헤드 감소 등이 있습니다.
공유 저장소를 사용하는 경우의 과제에는 데이터 격리, 데이터 관리, 노이즈 이웃 안티패턴의 가능성 및 테넌트에 비용을 할당하는 데 어려움이 있는지 확인해야 하는 필요성이 포함됩니다. 이 접근 방식에서 데이터 격리를 보장하는 것이 가장 중요합니다. 테넌트가 데이터에만 액세스할 수 있도록 보안 접근 방식을 구현해야 합니다. 테넌트에 서로 다른 일정에 따라 인덱스 작성과 같은 작업이 필요할 수 있는 데이터 수명 주기가 서로 다른 경우에도 데이터 관리가 어려울 수 있습니다.
일부 플랫폼에는 공유 저장소에서 테넌트 데이터 격리를 구현할 때 활용할 수 있는 기능이 있습니다. 예를 들어 Azure Cosmos DB는 분할 및 분할에 대한 기본 지원을 제공하며 테넌트 식별자를 파티션 키로 사용하여 테넌트 간에 일정 수준의 격리를 제공하는 것이 일반적입니다. Azure SQL 및 Postgres Flex는 행 수준 보안을 지원하지만 이 기능은 다중 테넌트 솔루션에서 일반적으로 사용되지는 않지만 다중 테넌트 저장소에서 사용하려는 경우 이러한 기능을 중심으로 솔루션을 디자인해야 하기 때문입니다.
이 AI 시나리오의 맥락에서 모든 테넌트에 대한 접지 데이터가 동일한 데이터 저장소에 들어오는 것을 의미합니다. 즉, 해당 데이터 저장소에 대한 쿼리에 테넌트 판별자를 포함해야 응답이 테넌트 컨텍스트 내에서 관련 데이터만 다시 가져오도록 제한됩니다.
공유 매장
다중 테넌트 솔루션에는 테넌트 간에 공유되는 데이터가 있는 경우가 많습니다. 의료 도메인에 대한 다중 테넌트 솔루션 예제에는 테넌트별로 지정되지 않은 일반 의료 정보 또는 정보를 저장하는 데이터베이스가 있을 수 있습니다.
이 AI 시나리오의 컨텍스트에서는 데이터가 시스템의 모든 테넌트에 대해 관련되고 권한이 부여되므로 테넌트를 기반으로 필터링할 필요가 없는 일반적으로 액세스할 수 있는 접지 데이터 저장소입니다.
ID
ID는 보안 다중 테넌트 RAG를 비롯한 다중 테넌트 솔루션의 주요 측면입니다. 지능형 애플리케이션은 IdP(ID 공급자)와 통합하여 사용자의 ID를 인증해야 합니다. 다중 테넌트 RAG 솔루션에는 신뢰할 수 있는 ID 또는 ID에 대한 참조가 저장되는 ID 디렉터 리가 필요합니다. 이 ID는 요청 체인을 통과하여 오케스트레이터 또는 데이터 저장소 자체와 같은 다운스트림 서비스가 사용자를 식별할 수 있도록 해야 합니다.
또한 테넌트 데이터에 대한 액세스 권한을 부여할 수 있도록 사용자를 테넌트에 매핑하는 수단이 필요합니다.
테넌트 및 권한 부여 요구 사항 정의
다중 테넌트 RAG 솔루션을 빌드할 때는 솔루션에 대한 테넌트를 정의해야 합니다. 선택할 수 있는 두 가지 일반적인 모델은 B2B(기업 간) 및 B2C(기업 간)입니다. 이 결정은 솔루션을 설계할 때 고려해야 할 영역을 알려주는 데 도움이 됩니다. 테넌트 수를 이해하는 것은 데이터 저장소 모델을 결정하는 데 중요합니다. 많은 수의 테넌트는 저장소당 여러 테넌트가 있는 모델을 필요로 할 수 있지만, 더 적은 수의 테넌트 모델에서 저장소를 허용할 수 있습니다. 테넌트당 데이터의 양도 중요합니다. 테넌트에 데이터 저장소의 크기 제한으로 인해 다중 테넌트 저장소를 사용할 수 없는 많은 양의 데이터가 있는 경우
이 AI 시나리오를 지원하기 위해 확장 중인 기존 워크로드에서는 이미 이 옵션을 선택했을 수 있습니다. 일반적으로 데이터 저장소가 충분한 관련성을 제공하고 다른 비기능적 요구 사항을 충족할 수 있는 경우 접지 데이터에 기존 데이터 스토리지 토폴로지를 사용할 수 있습니다. 그러나 전용 벡터 검색 저장소와 같은 새 구성 요소를 전용 접지 저장소로 도입하는 경우 현재 배포 스탬프 전략, 애플리케이션 제어 평면 영향 및 테넌트별 데이터 수명 주기 차이(예: 성능에 대한 지불 상황)와 같은 요소를 고려하여 이 결정을 내려야 합니다.
솔루션에 대한 테넌트를 정의한 후에는 데이터에 대한 권한 부여 요구 사항을 정의해야 합니다. 테넌트는 테넌트에서만 데이터에 액세스하지만 권한 부여 요구 사항은 더 세분화될 수 있습니다. 예를 들어 의료 솔루션에는 다음과 같은 규칙이 있을 수 있습니다.
- 환자는 자신의 환자 데이터에만 액세스할 수 있습니다.
- 의료 전문가는 환자의 데이터에 액세스할 수 있습니다.
- 재무 사용자는 재무 관련 데이터에만 액세스할 수 있습니다.
- 임상 감사자가 모든 환자의 데이터를 볼 수 있습니다.
- 모든 사용자는 공유 데이터 저장소에서 기본 의료 지식에 액세스할 수 있습니다.
문서 기반 RAG 애플리케이션에서는 문서에 설정된 태그 지정 체계 또는 민감도 수준에 따라 문서에 대한 사용자 액세스를 제한할 수 있습니다.
테넌트가 무엇인지 정의하고 권한 부여 규칙을 명확하게 이해한 후에는 해당 정보를 데이터 저장소 솔루션에 대한 요구 사항으로 사용합니다.
필터링
보안 트리밍이라고도 하는 필터링은 사용자에게 볼 권한이 있는 데이터만 노출하는 것을 말합니다. 다중 테넌트 RAG 시나리오에서 사용자는 테넌트별 저장소에 매핑될 수 있습니다. 그렇다고 해서 사용자가 해당 저장소의 모든 데이터에 액세스할 수 있어야 하는 것은 아닙니다. 테넌트 및 권한 부여 요구 사항 정의에서 데이터에 대한 권한 부여 요구 사항을 정의하는 것의 중요성에 대해 설명했습니다. 이러한 권한 부여 규칙은 필터링의 기준으로 사용해야 합니다.
행 수준 보안과 같은 데이터 플랫폼 기능을 사용하여 필터링을 수행할 수 있거나 사용자 지정 논리, 데이터 또는 메타데이터가 필요할 수 있습니다. 다시 말하지만, 이러한 플랫폼 기능은 이러한 기능을 중심으로 시스템을 설계해야 하므로 다중 테넌트 솔루션에서 일반적으로 사용되지 않습니다.
다중 테넌트 데이터 논리 캡슐화
사용 중인 스토리지 메커니즘 앞에 API를 두는 것이 좋습니다. API는 게이트키퍼 역할을 하므로 사용자가 액세스해야 하는 정보에만 액세스할 수 있습니다.
그림 4. 다중 테넌트 테넌트 데이터 액세스 논리를 캡슐화하는 API를 사용하는 다중 테넌트 RAG 아키텍처
이 문서의 앞부분에서 설명한 것처럼 데이터에 대한 사용자 액세스는 다음으로 제한될 수 있습니다.
- 사용자의 테넌트
- 플랫폼 기능
- 사용자 지정 보안 필터링/트리밍 규칙
이 계층에는 다음과 같은 책임이 있어야 합니다.
- 테넌트별 저장소 모델의 테넌트별 저장소로 쿼리 라우팅
- 다중 테넌트 저장소의 사용자 테넌트에서 데이터만 선택
- 사용자가 플랫폼 사용 권한 부여 논리를 지원하기 위해 적절한 ID를 사용합니다.
- 사용자 지정 보안 트리밍 논리 적용
- 감사 목적으로 접지 정보의 액세스 로그 저장
테넌트 데이터에 액세스해야 하는 코드는 백 엔드 저장소를 직접 쿼리할 수 없습니다. 데이터에 대한 모든 요청은 이 API 계층을 통해 전달되어야 합니다. 이 API 계층은 테넌트 데이터 위에 단일 거버넌스 지점 또는 보안 계층을 제공합니다. 이 방법은 테넌트 및 사용자 데이터 액세스 권한 부여 논리가 애플리케이션의 다른 영역으로 번지게 합니다. 이 논리는 API 계층에 캡슐화됩니다. 이 캡슐화를 사용하면 솔루션의 유효성을 더 쉽게 검사하고 테스트할 수 있습니다.
요약
다중 테넌트 RAG 유추 솔루션을 설계할 때 테넌트에 대한 접지 데이터 솔루션을 설계하는 방법을 고려해야 합니다. 테넌트 수와 저장하는 테넌트당 데이터의 양을 이해합니다. 이 정보는 데이터 테넌시 솔루션을 설계하는 데 도움이 됩니다. 다중 테넌트 및 필터링 논리를 포함하여 데이터 액세스 논리를 캡슐화하는 API 계층을 구현하는 것이 좋습니다.
참가자
Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.
- John Downs | 소프트웨어 수석 엔지니어
- Daniel Scott-Raynsford | Sr. 파트너 솔루션 설계자, 데이터 및 AI