다음을 통해 공유

보안 다중 테넌트 RAG 추론 솔루션 설계

  • 아티클

RAG(Retrieval-Augmented Generation)는 인터넷에서 공개적으로 사용할 수 없는 독점 정보 또는 기타 데이터를 추론하기 위해 기본 모델을 사용하는 애플리케이션을 빌드하는 패턴입니다. 일반적으로 클라이언트 애플리케이션은 벡터 데이터베이스와 같은 데이터 저장소에서 관련 정보를 가져오는 오케스트레이션 계층을 호출합니다. 오케스트레이션 계층은 해당 데이터를 컨텍스트의 일부로 기본 모델에 접지 데이터로 전달합니다.

다중 테넌트 솔루션은 여러 고객이 사용합니다. 각 고객 또는 테넌트는 동일한 조직, 회사 또는 그룹의 여러 사용자로 구성됩니다. 다중 테넌트 시나리오에서는 테넌트 또는 테넌트 내의 개인이 액세스 권한이 부여된 접지 데이터만 통합할 수 있는지 확인해야 합니다.

사용자가 액세스 권한이 부여된 정보에만 액세스하도록 하는 것 외에는 여러 테넌트 문제가 있습니다. 그러나 이 문서는 다중 테넌시의 그 측면에만 중점을 둡니다. 이 문서는 단일 테넌트 RAG 아키텍처의 개요로 시작합니다. 이 문서에서는 RAG를 사용하여 다중 테넌트에서 발생할 수 있는 과제와 몇 가지 일반적인 접근 방식에 대해 설명합니다. 또한 보안 향상을 위한 다중 테넌트 고려 사항 및 권장 사항을 간략하게 설명합니다.

메모

이 문서에서는 Azure OpenAI On Your Data 기능과 같은 Azure OpenAI 서비스와 관련된 몇 가지 기능에 대해 설명합니다. 그러나 이 문서에 설명된 대부분의 원칙을 모든 플랫폼의 기본 AI 모델에 적용할 수 있습니다.

오케스트레이터를 사용하는 단일 테넌트 RAG 아키텍처

단일 테넌트 데이터베이스 인스턴스를 사용하는 RAG 아키텍처를 보여 주는 다이어그램

워크플로

이 단일 테넌트 RAG 아키텍처에서 오케스트레이터는 데이터 저장소에서 관련 독점 테넌트 데이터를 가져와 기본 모델에 대한 접지 데이터로 제공합니다. 다음 단계에서는 고수준의 워크플로를 설명한 것입니다.

  1. 사용자가 지능형 웹 애플리케이션에 요청을 발급합니다.
  2. ID 공급자가 요청자를 인증합니다.
  3. 지능형 애플리케이션은 사용자의 쿼리 및 사용자에 대한 권한 부여 토큰을 사용하여 오케스트레이터 API를 호출합니다.
  4. 오케스트레이션 논리는 요청에서 사용자의 쿼리를 추출하고 적절한 데이터 저장소를 호출하여 쿼리에 대한 관련 접지 데이터를 가져옵니다. 접지 데이터는 다음 단계에서 Azure OpenAI에 노출되는 모델과 같이 기본 모델로 전송되는 프롬프트에 추가됩니다.
  5. 오케스트레이션 논리는 기본 모델의 추론 API에 연결하고 검색된 접지 데이터를 포함하는 프롬프트를 보냅니다. 결과는 지능형 애플리케이션에 반환됩니다.

자세한 내용은 RAG 솔루션디자인 및 개발을 참조하세요.

직접 데이터 액세스를 사용하는 단일 테넌트 RAG 아키텍처

단일 테넌트 RAG 아키텍처의 이 변형은 Azure OpenAI의 On Your Data 기능 사용하여 Azure AI Search와 같은 데이터 저장소와 직접 통합합니다. 이 아키텍처에서는 고유한 오케스트레이터가 없거나 오케스트레이터의 책임이 적습니다. Azure OpenAI API는 데이터 저장소를 호출하여 접지 데이터를 가져오고 해당 데이터를 언어 모델에 전달합니다. 이 방법을 사용하면 가져올 접지 데이터와 해당 데이터의 관련성을 덜 제어할 수 있습니다.

메모

Azure OpenAI는 Microsoft에서 관리합니다. 데이터 저장소와 통합되지만 모델 자체는 데이터 저장소와 통합되지 않습니다. 모델은 오케스트레이터가 데이터를 가져올 때와 동일한 방식으로 접지 데이터를 받습니다.

단일 테넌트 데이터베이스 인스턴스에 대한 Azure OpenAI 직접 액세스를 사용하는 RAG 아키텍처를 보여 주는 다이어그램

워크플로

이 RAG 아키텍처에서 기본 모델을 제공하는 서비스는 데이터 저장소에서 적절한 소유 테넌트 데이터를 가져오고 해당 데이터를 기초 모델에 대한 접지 데이터로 사용합니다. 다음 단계에서는 고수준의 워크플로를 설명한 것입니다. 기울임꼴화된 단계는 오케스트레이터 워크플로가 있는 이전의 단일 테넌트 RAG 아키텍처와 동일합니다.

  1. 사용자가 지능형 웹 애플리케이션에 요청을 발급합니다.
  2. ID 공급자가 요청자를 인증합니다.
  3. 지능형 애플리케이션은 사용자의 쿼리를 사용하여 Azure OpenAI를 호출합니다.
  4. Azure OpenAI는 AI Search 및 Azure Blob Storage와 같은 지원되는 데이터 저장소에 연결하여 접지 데이터를 가져옵니다. 접지 데이터는 Azure OpenAI가 OpenAI 언어 모델을 호출할 때 컨텍스트의 일부로 사용됩니다. 결과는 지능형 애플리케이션에 반환됩니다.

다중 테넌트 솔루션에서 이 아키텍처를 사용하려는 경우 Azure OpenAI와 같은 접지 데이터에 직접 액세스하는 서비스는 솔루션에 필요한 다중 테넌트 논리를 지원해야 합니다.

RAG 아키텍처의 멀티 테넌시

다중 테넌트 솔루션에서 테넌트 데이터는 테넌트별 저장소에 있거나 다중 테넌트 저장소의 다른 테넌트와 공존할 수 있습니다. 데이터는 테넌트 간에 공유되는 저장소에 있을 수도 있습니다. 사용자에게 액세스 권한이 부여된 데이터만 접지 데이터로 사용해야 합니다. 사용자는 액세스 권한이 부여된 데이터만 볼 수 있도록 필터링된 테넌트의 일반 또는 모든 테넌트 데이터만 표시되어야 합니다.

공유 데이터베이스, 다중 테넌트 데이터베이스 및 두 개의 단일 테넌트 데이터베이스를 사용하는 RAG 아키텍처를 보여 주는 다이어그램

워크플로

다음 단계에서는 고수준의 워크플로를 설명한 것입니다. 이탤릭체로 표시된 단계는 오케스트레이터 워크플로를 사용하는 싱글 테넌트 RAG 아키텍처와 동일합니다.

  1. 사용자가 지능형 웹 애플리케이션에 요청을 발급합니다.
  2. ID 공급자가 요청자를 인증합니다.
  3. 지능형 애플리케이션은 사용자의 쿼리 및 사용자에 대한 권한 부여 토큰을 사용하여 오케스트레이터 API를 호출합니다.
  4. 오케스트레이션 논리는 요청에서 사용자의 쿼리를 추출하고 적절한 데이터 저장소를 호출하여 쿼리에 대한 테넌트 권한이 부여된 관련 접지 데이터를 가져옵니다. 접지 데이터는 다음 단계에서 Azure OpenAI로 전송되는 프롬프트에 추가됩니다. 다음 단계 중 일부 또는 전부가 포함됩니다.
    1. 오케스트레이션 논리는 적절한 테넌트별 데이터 저장소 인스턴스에서 접지 데이터를 가져오고 잠재적으로 보안 필터링 규칙을 적용하여 사용자에게 액세스 권한이 부여된 데이터만 반환합니다.
    2. 오케스트레이션 논리는 다중 테넌트 데이터 저장소에서 적절한 테넌트의 접지 데이터를 가져오고 잠재적으로 보안 필터링 규칙을 적용하여 사용자에게 액세스 권한이 부여된 데이터만 반환합니다.
    3. 오케스트레이션 논리는 테넌트 간에 공유되는 데이터 저장소에서 데이터를 가져옵니다.
  5. 오케스트레이션 논리는 기본 모델의 추론 API에 연결하고 검색된 접지 데이터를 포함하는 프롬프트를 보냅니다. 결과는 지능형 애플리케이션에 반환됩니다.

RAG의 다중 테넌트 데이터에 대한 디자인 고려 사항

다중 테넌트 RAG 추론 솔루션을 디자인할 때 다음 옵션을 고려합니다.

저장소 격리 모델 선택

다중 테넌트 시나리오의 스토리지 및 데이터에 대한 두 가지 주요 아키텍처 접근 방식은 테넌트당 저장소 및 다중 테넌트 저장소입니다. 이러한 접근 방식은 테넌트 간에 공유되는 데이터를 포함하는 저장소에 추가됩니다. 다중 테넌트 솔루션은 이러한 방법의 조합을 사용할 수 있습니다.

테넌트별 저장소

테넌트별 매장에서는 각 테넌트에 자체 매장이 있습니다. 이 방법의 장점은 데이터와 성능 격리를 모두 포함합니다. 각 테넌트의 데이터는 자체 저장소에 캡슐화됩니다. 대부분의 데이터 서비스에서 격리된 저장소는 다른 테넌트의 시끄러운 인접 문제에 취약하지 않습니다. 또한 이 방법은 저장소 배포의 전체 비용이 단일 테넌트에 기인할 수 있으므로 비용 할당을 간소화합니다.

이 접근 방식은 관리 및 운영 오버헤드 증가 및 비용 증가와 같은 과제를 제시할 수 있습니다. 기업-소비자 시나리오와 같이 작은 테넌트가 많은 경우 이 방법을 사용하면 안 됩니다. 이 방법은 서비스 제한에 도달하거나 초과할 수도 있습니다.

이 AI 시나리오의 컨텍스트에서 테넌트당 저장소 저장소는 컨텍스트에 관련성을 가져오는 데 필요한 접지 데이터가 테넌트에 대한 접지 데이터만 포함하는 기존 또는 새 데이터 저장소에서 가져온다는 것을 의미합니다. 이 토폴로지에서 데이터베이스 인스턴스는 각 테넌트에 사용되는 판별자입니다.

멀티테넌트 저장소

다중 테넌트 저장소에서는 여러 테넌트의 데이터가 동일한 저장소에 공존합니다. 이 방법의 장점으로는 비용 최적화 가능성, 테넌트별 저장소 모델보다 더 많은 수의 테넌트를 처리할 수 있는 기능, 저장소 인스턴스 수가 적기 때문에 관리 오버헤드가 낮아지는 것이 있습니다.

공유 저장소를 사용하는 경우의 과제에는 데이터 격리 및 관리의 필요성, 시끄러운 이웃 안티패턴가능성 및 테넌트에 대한 더 복잡한 비용 할당이 포함됩니다. 데이터 격리는 이 방법을 사용할 때 가장 중요한 문제입니다. 테넌트가 데이터에만 액세스할 수 있도록 보안 접근 방식을 구현해야 합니다. 테넌트에 다른 일정에 따라 인덱스 빌드와 같은 작업이 필요한 데이터 수명 주기가 서로 다른 경우에도 데이터 관리가 어려울 수 있습니다.

일부 플랫폼에는 공유 저장소에서 테넌트 데이터 격리를 구현할 때 사용할 수 있는 기능이 있습니다. 예를 들어 Azure Cosmos DB는 데이터 분할 및 분할에 대한 기본 지원을 제공합니다. 테넌트 식별자를 파티션 키로 사용하여 테넌트 간에 격리를 제공하는 것이 일반적입니다. Azure SQL 및 Azure Database for PostgreSQL - 유연한 서버는 행 수준 보안을 지원합니다. 그러나 이러한 기능은 다중 테넌트 솔루션에서 사용하려는 경우 이러한 기능을 중심으로 솔루션을 디자인해야 하기 때문에 일반적으로 다중 테넌트 솔루션에서 사용되지 않습니다.

이 AI 시나리오의 맥락에서 모든 임차인의 데이터는 동일한 데이터 저장소에 저장됩니다. 따라서 해당 데이터 저장소에 대한 쿼리에는 테넌트 컨텍스트 내에서 관련 데이터만 다시 가져오도록 응답이 제한되도록 하는 테넌트 판별자가 포함되어야 합니다.

공유 저장소

다중 테넌트 솔루션은 테넌트 간에 데이터를 공유하는 경우가 많습니다. 의료 도메인에 대한 다중 테넌트 솔루션 예제에서 데이터베이스는 테넌트와 관련이 없는 일반 의료 정보 또는 정보를 저장할 수 있습니다.

이 AI 시나리오의 컨텍스트에서 접지 데이터 저장소는 일반적으로 액세스할 수 있으며, 데이터가 시스템의 모든 테넌트에 대해 관련되고 권한이 부여되므로 특정 테넌트에 따라 필터링할 필요가 없습니다.

신원

정체성은 다중 테넌트 솔루션의 주요 측면이며,다중 테넌트 RAG 솔루션도 포함됩니다. 지능형 애플리케이션은 ID 공급자와 통합하여 사용자의 ID를 인증해야 합니다. 다중 테넌트 RAG 솔루션에는 신뢰할 수 있는 ID 또는 ID에 대한 참조를 저장하는 ID 디렉터리 필요합니다. 이 ID는 요청 체인을 통해 흐르고 오케스트레이터 또는 데이터 저장소 자체와 같은 다운스트림 서비스가 사용자를 식별하도록 허용해야 합니다.

테넌트 데이터에 대한 액세스 권한을 부여할 수 있도록, 사용자를 테넌트에 매핑하는 방법이 필요합니다.

테넌트 및 권한 부여 요구 사항 정의

다중 테넌트 RAG 솔루션을 빌드할 때는 솔루션 테넌트가 무엇인지정의해야 합니다. 선택할 수 있는 두 가지 일반적인 모델은 비즈니스 간 모델과 기업 간 모델입니다. 선택한 모델은 솔루션을 빌드할 때 고려해야 할 다른 요소를 결정하는 데 도움이 됩니다. 테넌트 수를 이해하는 것은 데이터 저장소 모델을 선택하는 데 중요합니다. 많은 수의 세입자가 있을 경우, 각 상점에 여러 세입자가 있는 모델이 필요할 수 있습니다. 테넌트 수가 적어지면 테넌트별 매장 모델이 가능할 수 있습니다. 각 테넌트에 대한 데이터 양도 중요합니다. 많은 양의 데이터가 있는 테넌트는 데이터 저장소의 크기 제한으로 인해 다중 테넌트 저장소를 사용하지 못할 수 있습니다.

이 AI 시나리오를 지원하기 위해 기존 워크로드를 확장하려는 경우 이미 이 결정을 내렸을 수 있습니다. 일반적으로 해당 데이터 저장소가 충분한 관련성을 제공하고 다른 비기능적 요구 사항을 충족할 수 있는 경우 접지 데이터에 기존 데이터 스토리지 토폴로지를 사용할 수 있습니다. 그러나 전용 벡터 검색 저장소와 같은 새 구성 요소를 전용 접지 저장소로 도입하려는 경우에도 이 결정을 내려야 합니다. 현재 배포 스탬프 전략, 애플리케이션 제어 평면 영향 및 테넌트별 데이터 수명 주기 차이(예: 성능에 대한 지불 상황)와 같은 요소를 고려합니다.

솔루션에 대한 테넌트를 정의한 후에는 데이터에 대한 권한 부여 요구 사항을 정의해야 합니다. 각 테넌트는 자신의 테넌트에서만 데이터에 액세스하지만, 권한 요구 사항은 더 세부적일 수 있습니다. 예를 들어 의료 솔루션에는 다음과 같은 규칙이 있을 수 있습니다.

  • 환자는 자신의 환자 데이터에만 액세스할 수 있습니다.
  • 의료 전문가는 환자의 데이터에 액세스할 수 있습니다.
  • 재무 사용자는 재무 관련 데이터에만 액세스할 수 있습니다.
  • 임상 감사관은 모든 환자의 데이터를 볼 수 있습니다.
  • 모든 사용자는 공유 데이터 저장소의 기본 의료 지식에 액세스할 수 있습니다.

문서 기반 RAG 애플리케이션에서는 문서에 할당된 태그 지정 체계 또는 민감도 수준에 따라 문서에 대한 사용자의 액세스를 제한할 수 있습니다.

테넌트가 무엇인지 정의하고 권한 부여 규칙을 명확하게 이해한 후에는 해당 정보를 데이터 저장소 솔루션에 대한 요구 사항으로 사용합니다.

데이터 필터링

액세스 권한이 있는 데이터에 대한 액세스만 제한하는 것은 필터링 또는 보안 트리밍이라고 합니다. 다중 테넌트 RAG 시나리오에서 사용자는 테넌트별 저장소에 매핑될 수 있습니다. 그렇다고 해서 사용자가 해당 저장소의 모든 데이터에 액세스할 수 있어야 하는 것은 아닙니다. 테넌트 및 권한 부여 요구 사항 정의 데이터에 대한 권한 부여 요구 사항 정의의 중요성에 대해 설명합니다. 이러한 권한 부여 규칙을 필터링의 기초로 사용해야 합니다.

행 수준 보안과 같은 데이터 플랫폼 기능을 사용하여 필터링을 구현할 수 있습니다. 또는 사용자 지정 논리, 데이터 또는 메타데이터가 필요할 수 있습니다. 이러한 플랫폼 기능은 일반적으로 다중 테넌트 솔루션에서 사용되지 않습니다. 이러한 기능을 중심으로 시스템을 디자인해야 하기 때문입니다.

다중 테넌트 데이터 논리 캡슐화

사용하는 스토리지 메커니즘 앞에 API가 있는 것이 좋습니다. API는 사용자가 액세스 권한이 부여된 정보에만 액세스할 수 있도록 하는 게이트키퍼처럼 작동합니다.

공유 데이터베이스, 다중 테넌트 데이터베이스 및 두 개의 단일 테넌트 데이터베이스가 있는 RAG 아키텍처를 보여 주는 다이어그램 API 계층은 오케스트레이터와 데이터베이스 사이에 있습니다.

데이터에 대한 사용자의 액세스는 다음을 통해 제한될 수 있습니다.

  • 사용자의 임차인입니다.
  • 플랫폼 기능.
  • 사용자 지정 보안 필터링 또는 트리밍 규칙

API 계층은 다음을 수행해야 합니다.

  • 테넌트별 저장소 모델에서 특정 테넌트의 저장소로 쿼리를 라우팅합니다.
  • 다중 테넌트 저장소의 사용자 테넌트에서 데이터만 선택합니다.
  • 플랫폼에서 사용 권한 부여 논리를 지원하기 위해 적절한 사용자 ID를 사용하십시오.
  • 사용자 지정 보안 트리밍 논리를 적용합니다.
  • 감사 목적으로 접지 정보의 액세스 로그를 저장합니다.

테넌트 데이터에 액세스해야 하는 코드는 백 엔드 저장소를 직접 쿼리할 수 없습니다. 데이터에 대한 모든 요청은 API 계층을 통해 전달되어야 합니다. 이 API 계층은 테넌트 데이터 위에 단일 거버넌스 지점 또는 보안을 제공합니다. 이 방법을 사용하면 테넌트 및 사용자 데이터 액세스 권한 부여 논리가 애플리케이션의 다른 영역에 도달하지 못하게 됩니다. 이 논리는 API 계층에 캡슐화됩니다. 이 캡슐화를 사용하면 솔루션의 유효성을 더 쉽게 검사하고 테스트할 수 있습니다.

요약

다중 테넌트 RAG 유추 솔루션을 디자인할 때 테넌트에 대한 접지 데이터 솔루션을 설계하는 방법을 고려해야 합니다. 테넌트 수와 저장하는 테넌트별 데이터의 양을 이해합니다. 이 정보는 데이터 테넌시 솔루션을 설계하는 데 도움이 됩니다. 다중 테넌트 논리 및 필터링 논리를 포함하여 데이터 액세스 논리를 캡슐화하는 API 계층을 구현하는 것이 좋습니다.

참여자

Microsoft는 이 문서를 유지 관리합니다. 다음 기여자는 이 문서를 작성했습니다.

주요 작성자:

비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인합니다.

다음 단계

RAG 솔루션 디자인 및 개발