다음을 통해 공유

부모-자식 인덱싱에 대한 인덱스 프로젝션 정의

  • 아티클

청크 분할된 문서가 포함된 인덱스의 경우 인덱스 프로젝션은 일대다 인덱싱을 위해 검색 인덱스의 필드에 부모-자식 콘텐츠를 매핑하는 방법을 지정합니다. 인덱스 프로젝션을 통해 콘텐츠를 다음으로 보낼 수 있습니다.

  • 각 청크에 대해 부모 필드가 반복되지만 인덱스의 그레인이 청크 수준에 있는 단일 인덱스입니다. RAG 자습서는 이 방법의 예입니다.

  • 부모 인덱스에 부모 문서와 관련된 필드가 있고 자식 인덱스가 청크를 중심으로 구성되는 둘 이상의 인덱스입니다. 자식 인덱스는 기본 검색 모음이지만 특정 청크의 부모 필드를 검색하거나 독립적인 쿼리를 검색하려는 경우 조회 쿼리에 부모 인덱스를 사용할 수 있습니다.

대부분의 구현은 각 청크에 대해 반복되는 문서 파일 이름과 같은 부모 필드가 있는 청크를 중심으로 구성된 단일 인덱스입니다. 그러나 이 시스템은 요구 사항인 경우 별도의 여러 자식 인덱스를 지원하도록 설계되었습니다. Azure AI Search는 인덱스 조인을 지원하지 않으므로 애플리케이션 코드에서 사용할 인덱스를 처리해야 합니다.

인덱스 프로젝션은 기술 세트에 정의됩니다. 각 청크에 연결된 부모 콘텐츠와 함께 콘텐츠 청크를 검색 인덱스로 보내는 인덱싱 프로세스를 조정해야 합니다. 부모-자식 콘텐츠를 인덱싱하는 방법을 제어하기 위한 추가 옵션을 제공하여 네이티브 데이터 청크의 작동 방식을 개선합니다.

이 문서에서는 일대다 인덱싱을 위한 인덱스 스키마 및 인덱서 프로젝션 패턴을 만드는 방법을 설명합니다.

필수 조건

기술 세트에는 일대다 인덱싱을 위해 데이터를 셰이핑하는 인덱서 프로젝션이 포함되어 있습니다. 시나리오에 통합 벡터화가 포함된 경우 기술 세트에는 AzureOpenAIEmbedding과 같은 포함 기술과 같은 다른 기술이 있을 수도 있습니다.

인덱서 처리에 대한 종속성

일대다 인덱싱은 다음 네 가지 구성 요소를 포함하는 기술 세트 및 인덱서 기반 인덱싱에 대한 종속성을 사용합니다.

  • 데이터 원본
  • 검색 가능한 콘텐츠에 대한 하나 이상의 인덱스
  • 인덱스 프로젝션을 포함하는 기술 세트*
  • 인덱서

데이터는 지원되는 모든 데이터 원본에서 발생할 수 있지만 콘텐츠가 청크할 만큼 충분히 크다고 가정하고 청크 분할하는 이유는 채팅 모델에 접지 데이터를 제공하는 RAG 패턴을 구현하기 때문입니다. 또는 벡터 검색을 구현하고 있으며 모델 포함의 더 작은 입력 크기 요구 사항을 충족해야 합니다.

인덱서는 인덱싱된 데이터를 미리 정의된 인덱스로 로드합니다. 스키마를 정의하는 방법 및 하나 이상의 인덱스를 사용할지 여부는 일대다 인덱싱 시나리오에서 첫 번째 결정입니다. 다음 섹션에서는 인덱스 디자인을 다룹니다.

일대다 인덱싱을 위한 인덱스 만들기

부모 값을 반복하는 청크에 대해 하나의 인덱스를 만들거나 부모-자식 필드 배치를 위한 별도의 인덱스를 만들든 검색에 사용되는 기본 인덱스는 데이터 청크를 중심으로 설계되었습니다. 다음 필드가 있어야 합니다.

  • 각 문서를 고유하게 식별하는 문서 키 필드입니다. 분석기를 사용하여 형식 Edm.String keyword 으로 정의해야 합니다.

  • 각 청크를 상위 청크와 연결한 필드입니다. 형식 Edm.String이어야 합니다. 문서 키 필드일 수 없으며 true로 설정해야 filterable 합니다. 예제의 parent_id 이 문서의 프로젝션된 키 값이라고 합니다.

  • 텍스트 또는 벡터화된 청크 필드와 같은 콘텐츠에 대한 기타 필드입니다.

기술 세트를 만들거나 인덱서 실행하기 전에 검색 서비스에 인덱스가 있어야 합니다.

부모 및 자식 필드를 포함하는 단일 인덱스 스키마

각 청크에 대해 부모 콘텐츠가 반복되는 청크를 중심으로 설계된 단일 인덱스는 RAG 및 벡터 검색 시나리오의 주요 패턴입니다. 인덱스 프로젝션을 통해 올바른 부모 콘텐츠를 각 청크에 연결할 수 있습니다.

다음 스키마는 인덱스 프로젝션에 대한 요구 사항을 충족하는 예제입니다. 이 예제에서 부모 필드는 parent_id 제목입니다. 자식 필드는 벡터 및 비벡터 벡터 청크입니다. chunk_id 이 인덱스의 문서 ID입니다. parent_id 및 제목은 인덱스 내의 모든 청크에 대해 반복합니다.

Azure Portal, REST API 또는 Azure SDK를 사용하여 인덱스를 만들 수 있습니다.

{
    "name": "my_consolidated_index",
    "fields": [
        {"name": "chunk_id", "type": "Edm.String", "key": true, "filterable": true, "analyzer": "keyword"},
        {"name": "parent_id", "type": "Edm.String", "filterable": true},
        {"name": "title", "type": "Edm.String", "searchable": true, "filterable": true, "sortable": true, "retrievable": true},
        {"name": "chunk", "type": "Edm.String","searchable": true,"retrievable": true},
        {"name": "chunk_vector", "type": "Collection(Edm.Single)", "searchable": true, "retrievable": false, "stored": false, "dimensions": 1536, "vectorSearchProfile": "hnsw"}
    ],
    "vectorSearch": {
        "algorithms": [{"name": "hsnw", "kind": "hnsw", "hnswParameters": {}}],
        "profiles": [{"name": "hsnw", "algorithm": "hnsw"}]
    }
}

기술 세트에 인덱스 프로젝션 추가

인덱스 프로젝션은 기술 세트 정의 내에서 정의되며 주로 각 선택기가 검색 서비스의 다른 대상 인덱스에 해당하는 배열 selectors로 정의됩니다. 이 섹션은 컨텍스트에 대한 구문 및 예제와 매개 변수 참조로 시작합니다.

다양한 API 구문에 대한 탭을 선택합니다. 현재 기술 세트 JSON 정의를 편집하는 것 외에는 프로젝션 설정에 대한 포털 지원이 없습니다. JSON에 대한 REST 예제를 참조하세요.

인덱스 프로젝션은 일반 공급됩니다. 가장 최근의 안정적인 API를 사용하는 것이 좋습니다.

다음은 텍스트 분할 기술의 개별 페이지 출력을 검색 인덱스의 자체 문서로 프로젝션하는 데 사용할 수 있는 인덱스 프로젝션 정의에 대한 예제 페이로드입니다.

"indexProjections": {
    "selectors": [
        {
            "targetIndexName": "my_consolidated_index",
            "parentKeyFieldName": "parent_id",
            "sourceContext": "/document/pages/*",
            "mappings": [
                {
                    "name": "chunk",
                    "source": "/document/pages/*",
                    "sourceContext": null,
                    "inputs": []
                },
                {
                    "name": "chunk_vector",
                    "source": "/document/pages/*/chunk_vector",
                    "sourceContext": null,
                    "inputs": []
                },
                {
                    "name": "title",
                    "source": "/document/title",
                    "sourceContext": null,
                    "inputs": []
                }
            ]
        }
    ],
    "parameters": {
        "projectionMode": "skipIndexingParentDocuments"
    }
}

매개 변수 참조

인덱스 프로젝션 매개 변수 정의
selectors 주 검색 모음에 대한 매개 변수로, 일반적으로 청크를 중심으로 디자인된 매개 변수입니다.
projectionMode 인덱서에 지침을 제공하는 선택적 매개 변수입니다. 이 매개 변수에 유효한 값은 skipIndexingParentDocuments청크 인덱스가 기본 검색 모음이고 부모 필드가 청크 인덱스 내의 추가 검색 문서로 인덱싱되는지 여부를 지정해야 하는 경우에 사용됩니다. 설정 skipIndexingParentDocuments하지 않으면 청크에 대해 null이지만 부모 필드로만 채워진 추가 검색 문서가 인덱스에 표시됩니다. 예를 들어 5개의 문서가 인덱스에 100개의 청크를 기여하는 경우 인덱스의 문서 수는 105개입니다. 만든 문서 5개 또는 부모 필드에는 청크(자식) 필드의 null이 있으므로 인덱스의 문서 대부분과 크게 다릅니다. 로 설정하는 skipIndexingParentDocument것이 좋습니다projectionMode.

선택기에는 정의의 일부로 다음 매개 변수가 있습니다.

선택기 매개 변수 정의
targetIndexName 인덱스 데이터가 프로젝터되는 인덱스의 이름입니다. 부모 필드가 반복되는 단일 청크 인덱스이거나 부모-자식 콘텐츠에 별도의 인덱스를 사용하는 경우 자식 인덱스 입니다.
parentKeyFieldName 부모 문서의 키를 제공하는 필드의 이름입니다.
sourceContext 데이터를 개별 검색 문서에 매핑할 세분성을 정의하는 보강 주석입니다. 자세한 내용은 기술 컨텍스트 및 입력 주석 언어를 참조하세요.
mappings 보강된 데이터를 검색 인덱스의 필드에 매핑하는 배열입니다. 각 매핑은 다음으로 구성됩니다.
name: 데이터를 인덱싱해야 하는 검색 인덱스의 필드 이름입니다.
source: 데이터를 끌어올 보강 주석 경로입니다.

또한 각 mapping은 지식 저장소 또는 쉐이퍼 기술과 유사하게 선택적 sourceContext 및 inputs 필드를 사용하여 데이터를 재귀적으로 정의할 수 있습니다. 애플리케이션에 따라 이러한 매개 변수를 사용하면 검색 인덱스의 형식 Edm.ComplexType 필드에 데이터를 셰이핑할 수 있습니다. 일부 LLM은 검색 결과에서 복합 형식을 허용하지 않으므로 사용하는 LLM은 복합 형식 매핑이 유용한지 여부를 결정합니다.

mappings 매개 변수가 중요합니다. 문서 키 및 부모 ID와 같은 ID 필드를 제외하고 자식 인덱스 내의 모든 필드를 명시적으로 매핑해야 합니다.

이 요구 사항은 Azure AI Search의 다른 필드 매핑 규칙과는 대조적입니다. 일부 데이터 원본 형식의 경우 인덱서는 유사한 이름 또는 알려진 특성에 따라 필드를 암시적으로 매핑할 수 있습니다(예: Blob 인덱서는 고유한 메타데이터 스토리지 경로를 기본 문서 키로 사용). 그러나 인덱서 프로젝션의 경우 관계의 "다" 쪽에서 모든 필드 매핑을 명시적으로 지정해야 합니다.

부모 키 필드에 대한 필드 매핑을 만들지 마세요. 이렇게 하면 변경 내용 추적 및 동기화된 데이터 새로 고침이 중단됩니다.

부모 문서 처리

이제 일대다 인덱싱에 대한 몇 가지 패턴을 살펴보았으므로 각 옵션에 대한 주요 차이점을 비교할 수 있습니다. 인덱스 프로젝션은 기술 세트를 통해 실행되는 각 "부모" 문서에 대해 "자식" 문서를 효과적으로 생성합니다. "부모" 문서를 처리하기 위한 몇 가지 옵션이 있습니다.

  • 인덱스를 구분하기 위해 부모 및 자식 문서를 보내려면 인덱서 정의의 인덱스를 부모 인덱스로 설정하고 targetIndexName 인덱스 프로젝션 선택기에서 자식 인덱스로 설정합니다 targetIndexName .

  • 부모 및 자식 문서를 동일한 인덱스로 유지하려면 인덱서와 인덱스 targetIndexName 프로젝션 targetIndexName 을 동일한 인덱스로 설정합니다.

  • 부모 검색 문서를 만들고 인덱스에 균일한 곡물의 자식 문서만 포함되도록 하려면 인덱서 정의와 선택기 모두를 동일한 인덱스로 설정 targetIndexName 하지만 다음과 같이 키가 설정된 후 selectorsprojectionMode 추가 parameters 개체를 skipIndexingParentDocuments추가합니다.

    "indexProjections": {
    "selectors": [
        ...
    ],
    "parameters": {
        "projectionMode": "skipIndexingParentDocuments"
    }
}

필드 매핑 검토

인덱서는 세 가지 유형의 필드 매핑과 관련이 있습니다. 인덱서 실행 전에 필드 매핑을 확인하고 각 형식을 사용해야 하는 시기를 파악합니다.

필드 매핑은 인덱서에 정의되며 원본 필드를 인덱스 필드에 매핑하는 데 사용됩니다. 필드 매핑은 중간 기술 처리 단계 없이 원본에서 데이터를 들어 올려 인덱싱을 위해 전달하는 데이터 경로에 사용됩니다. 일반적으로 인덱서는 이름과 형식이 같은 필드를 자동으로 매핑할 수 있습니다. 명시적 필드 매핑은 불일치가 있는 경우에만 필요합니다. 일대다 인덱싱 및 지금까지 설명한 패턴에서는 필드 매핑이 필요하지 않을 수 있습니다.

출력 필드 매핑 은 인덱서에 정의되며 기술 세트에 의해 생성된 보강된 콘텐츠를 기본 인덱스에 필드에 매핑하는 데 사용됩니다. 이 문서에서 다루는 일대다 패턴에서 이는 2인덱스 솔루션의 부모 인덱스입니다. 이 문서에 표시된 예제에서 부모 인덱스는 제목 필드만 있는 스파스이며 해당 필드는 기술 세트 처리의 콘텐츠로 채워지지 않으므로 출력 필드 매핑이 아닙니다.

인덱서 프로젝션 필드 매핑은 기술 세트 생성 콘텐츠를 자식 인덱스의 필드에 매핑하는 데 사용됩니다. 자식 인덱스에 부모 필드도 포함된 경우(통합 인덱스 솔루션에서와 같이) 각 청크 문서에 제목을 표시하도록 가정하고 부모 수준 제목 필드를 포함하여 콘텐츠가 있는 모든 필드에 대한 필드 매핑을 설정해야 합니다. 별도의 부모 및 자식 인덱스를 사용하는 경우 인덱서 프로젝션에는 자식 수준 필드에 대한 필드 매핑만 있어야 합니다.

참고 항목

출력 필드 매핑과 인덱서 프로젝션 필드 매핑은 모두 보강된 문서 트리 노드를 원본 입력으로 허용합니다. 각 노드에 대한 경로를 지정하는 방법을 아는 것은 데이터 경로를 설정하는 데 필수적입니다. 경로 구문 에 대한 자세한 내용은 보강된 노드 에 대한 경로 참조 및 예제에 대한 기술 세트 정의를 참조하세요.

인덱서 실행

데이터 원본, 인덱스 및 기술 세트를 만든 후에는 인덱서 만들기 및 실행할 준비가 된 것입니다. 이 단계에서는 파이프라인을 실행합니다.

처리가 끝난 후 검색 인덱스를 쿼리하여 솔루션을 테스트할 수 있습니다.

콘텐츠 수명 주기

기본 데이터 원본에 따라 인덱서는 일반적으로 지속적인 변경 내용 추적 및 삭제 검색을 제공할 수 있습니다. 이 섹션에서는 데이터 새로 고침과 관련된 일대다 인덱싱의 콘텐츠 수명 주기를 설명합니다.

변경 내용 추적 및 삭제 검색을 제공하는 데이터 원본의 경우 인덱서 프로세스에서 원본 데이터의 변경 내용을 선택할 수 있습니다. 인덱서와 기술 세트를 실행할 때마다 기술 세트 또는 기본 원본 데이터가 변경된 경우 인덱스 프로젝션이 업데이트됩니다. 인덱서에서 선택한 모든 변경 내용이 보강 프로세스를 통해 인덱스의 프로젝션에 전파되어 프로젝션된 데이터가 원래 데이터 원본 콘텐츠의 현재 표현이 되도록 합니다. 데이터 새로 고침 작업은 각 청크에 대해 프로젝션된 키 값으로 캡처됩니다. 이 값은 기본 데이터가 변경되면 업데이트됩니다.

참고 항목

인덱스 푸시 API를 사용하여 프로젝트된 문서의 데이터를 수동으로 편집할 수 있지만 이렇게 하지 않아야 합니다. 인덱스에 대한 수동 업데이트는 원본 데이터의 문서가 업데이트되고 데이터 원본이 변경 내용 추적 또는 삭제 검색을 사용하도록 설정된 경우 다음 파이프라인 호출에서 덮어씁니다.

업데이트된 내용

데이터 원본에 새 콘텐츠를 추가하면 다음 인덱서 실행 시 새 청크 또는 자식 문서가 인덱스에 추가됩니다.

데이터 원본의 기존 콘텐츠를 수정하는 경우 사용 중인 데이터 원본이 변경 내용 추적 및 삭제 검색을 지원하는 경우 검색 인덱스에서 청크가 증분 방식으로 업데이트됩니다. exammple의 경우 문서에서 단어 또는 문장이 변경되면 해당 단어 또는 문장이 포함된 대상 인덱스의 청크가 다음 인덱서 실행 시 업데이트됩니다. 필드 형식 변경 및 일부 특성과 같은 다른 유형의 업데이트는 기존 필드에 대해 지원되지 않습니다. 허용되는 업데이트에 대한 자세한 내용은 인덱스 스키마 변경을 참조 하세요.

Azure Storage와 같은 일부 데이터 원본은 타임스탬프에 따라 기본적으로 변경 및 삭제 추적을 지원합니다. 변경 내용 추적을 위해 OneLake, Azure SQL 또는 Azure Cosmos DB와 같은 다른 데이터 원본을 구성해야 합니다.

삭제된 콘텐츠

원본 콘텐츠가 더 이상 존재하지 않는 경우(예: 텍스트의 청크가 줄어드는 경우) 검색 인덱스의 해당 자식 문서가 삭제됩니다. 나머지 자식 문서는 콘텐츠가 변경되지 않더라도 새 해시 값을 포함하도록 키를 업데이트합니다.

부모 문서가 데이터 원본에서 완전히 삭제된 경우, 해당 자식 문서는 데이터 원본 정의에 정의된 dataDeletionDetectionPolicy에 의해 삭제가 감지된 경우에만 삭제됩니다. dataDeletionDetectionPolicy가 구성되지 않았고 데이터 원본에서 부모 문서를 삭제해야 하는 경우, 자식 문서가 더 이상 필요하지 않으면 수동으로 삭제해야 합니다.

프로젝션된 키 값

업데이트 및 삭제된 콘텐츠에 대한 데이터 무결성을 보장하기 위해 일대다 인덱싱의 데이터 새로 고침은 "다" 쪽에서 프로젝션된 키 값을 사용합니다. 통합 벡터화 또는 데이터 가져오기 및 벡터화 마법사를 사용하는 경우 프로젝션된 키 값은 인덱스의 parent_id 청크 또는 "다" 쪽 필드입니다.

프로젝션된 키 값은 인덱서가 각 문서에 대해 생성하는 고유 식별자입니다. 고유성을 보장하고 변경 및 삭제 추적이 올바르게 작동할 수 있도록 합니다. 이 키에는 다음 세그먼트가 포함됩니다.

  • 고유성을 보장하는 임의의 해시. 이 해시는 후속 인덱서 실행에서 부모 문서가 업데이트되는 경우 변경됩니다.
  • 부모 문서의 키
  • 해당 문서가 생성된 컨텍스트를 식별하는 보강 주석 경로

예를 들어 키 값이 "aa1b22c33"인 부모 문서를 4페이지로 분할하면 각 페이지가 인덱스 프로젝션을 통해 자체 문서로 프로젝션됩니다.

  • aa1b22c33
  • aa1b22c33_pages_0
  • aa1b22c33_pages_1
  • aa1b22c33_pages_2

상위 문서가 원본 데이터에서 업데이트되면 더 많은 청크 페이지가 생성되고, 임의 해시가 변경되고, 더 많은 페이지가 추가되고, 각 청크의 콘텐츠가 원본 문서에 있는 내용과 일치하도록 업데이트됩니다.

별도의 부모-자식 인덱스 예제

이 섹션에서는 별도의 부모 및 자식 인덱스에 대한 예제를 보여 줍니다. 일반적인 패턴이지만 이 방법을 사용하여 가장 적합한 애플리케이션 요구 사항이 있을 수 있습니다. 이 시나리오에서는 부모-자식 콘텐츠를 두 개의 개별 인덱스에 프로젝팅합니다.

각 스키마에는 조회 쿼리에서 사용하기 위해 두 인덱스에 공통적인 부모 ID 필드가 있는 특정 조직 필드가 있습니다. 기본 검색 모음은 자식 인덱스이지만 조회 쿼리를 실행하여 결과의 각 일치 항목에 대한 부모 필드를 검색합니다. Azure AI Search는 쿼리 시 조인을 지원하지 않으므로 애플리케이션 코드 또는 오케스트레이션 계층은 앱 또는 프로세스에 전달할 수 있는 결과를 병합하거나 정렬해야 합니다.

부모 인덱스는 parent_id 필드와 제목이 있습니다. parent_id 문서 키입니다. 부모 문서 수준에서 필드를 벡터화하지 않으려면 벡터 검색 구성이 필요하지 않습니다.

{
    "name": "my-parent-index",
    "fields": [

        {"name": "parent_id", "type": "Edm.String", "filterable": true},
        {"name": "title", "type": "Edm.String", "searchable": true, "filterable": true, "sortable": true, "retrievable": true},
    ]
}

자식 인덱스는 청크 필드와 parent_id 필드를 포함합니다. 통합 벡터화, 점수 매기기 프로필, 의미 체계 순위 또는 분석기를 사용하는 경우 자식 인덱스에 설정합니다.

{
    "name": "my-child-index",
    "fields": [
        {"name": "chunk_id", "type": "Edm.String", "key": true, "filterable": true, "analyzer": "keyword"},
        {"name": "parent_id", "type": "Edm.String", "filterable": true},
         {"name": "chunk", "type": "Edm.String","searchable": true,"retrievable": true},
        {"name": "chunk_vector", "type": "Collection(Edm.Single)", "searchable": true, "retrievable": false, "stored": false, "dimensions": 1536, "vectorSearchProfile": "hnsw"}
    ],
    "vectorSearch": {
        "algorithms": [{"name": "hsnw", "kind": "hnsw", "hnswParameters": {}}],
        "profiles": [{"name": "hsnw", "algorithm": "hnsw"}]
    },
    "scoringProfiles": [],
    "semanticConfiguration": [],
    "analyzers": []
}

다음은 인덱서가 콘텐츠를 인덱싱하는 데 사용해야 하는 데이터 경로를 지정하는 인덱스 프로젝션 정의의 예입니다. 인덱스 프로젝션 정의에서 자식 인덱스 이름을 지정하고 모든 자식 또는 청크 수준 필드의 매핑을 지정합니다. 자식 인덱스 이름이 지정된 유일한 위치입니다.

"indexProjections": {
    "selectors": [
        {
            "targetIndexName": "my-child-index",
            "parentKeyFieldName": "parent_id",
            "sourceContext": "/document/pages/*",
            "mappings": [
                {
                    "name": "chunk",
                    "source": "/document/pages/*",
                    "sourceContext": null,
                    "inputs": []
                },
                {
                    "name": "chunk_vector",
                    "source": "/document/pages/*/chunk_vector",
                    "sourceContext": null,
                    "inputs": []
                }
            ]
        }
    ]
}

인덱서 정의는 파이프라인의 구성 요소를 지정합니다. 인덱서 정의에서 제공할 인덱스 이름은 부모 인덱스입니다. 부모 수준 필드에 대한 필드 매핑이 필요한 경우 outputFieldMappings에서 정의합니다. 별도의 인덱스를 사용하는 일대다 인덱싱의 경우 인덱서 정의는 다음 예제와 같을 수 있습니다.

{
  "name": "my-indexer",
  "dataSourceName": "my-ds",
  "targetIndexName": "my-parent-index",
  "skillsetName" : "my-skillset"
  "parameters": { },
  "fieldMappings": (optional) Maps fields in the underlying data source to fields in an index,
  "outputFieldMappings" : (required) Maps skill outputs to fields in an index,
}

다음 단계

데이터 청크 및 일대다 인덱싱은 Azure AI Search의 RAG 패턴의 일부입니다. 다음 자습서 및 코드 샘플을 계속 진행하여 자세히 알아보세요.

Azure AI Search를 사용하여 RAG 솔루션을 빌드하는 방법