Azure에서 AI 워크로드를 위한 데이터 디자인 접지

AI 애플리케이션의 경우 데이터 디자인에 대한 잘 설계된 프레임워크 접근 방식은 조작성, 비용 및 보안과 같은 비기능적 요구 사항을 해결하고 Azure Well-Architected Framework 핵심 원칙을 준수해야 합니다. 또한 데이터 수집, 준비 및 유효성 검사와 같은 기능 요구 사항도 고려해야 합니다.

선택하는 AI 모델은 후속 데이터 디자인 결정에 영향을 줍니다. 이 문서에서는 결과 관련성을 향상시키기 위해 보강이 필요한 기본 모델의 주요 아키텍처 고려 사항에 대해 설명합니다. 이러한 모델은 일반적으로 생성됩니다.

생성 AI 모델은 미리 빌드되거나 미리 학습되므로 수정하지 않고 즉시 사용할 수 있습니다. 그러나 기본 제공 모델은 특정 워크로드 요구 사항을 충족하지 않는 경우가 많습니다. 이 문제를 해결하기 위해 모델은 성능 향상을 위해 컨텍스트별 데이터로 보강됩니다. 예를 들어 다양한 사용 사례에서 GPT 모델을 사용할 수 있습니다. 이러한 애플리케이션에는 문서에서 정보 검색, IT 기술 지원팀 지원 제공, 복잡한 정보 요약 등이 포함됩니다. 기초 모델을 사용하여 특정 요구 사항을 충족하려면 이러한 고려 사항을 이해하는 것이 중요합니다.

솔루션에서 생성 AI와 차별적인 AI 모델의 조합을 사용하여 워크로드 요구 사항을 충족할 수 있습니다. 학습 데이터에 대한 자세한 내용은 학습 데이터 디자인을 참조 하세요.

권장 사항

다음은 이 문서에 제공된 권장 사항의 요약입니다.

데이터 유형

유추 중에 컨텍스트 데이터를 사용하여 생성 AI 모델을 보강하거나 미세 조정 프로세스를 통해 추가로 최적화할 수 있습니다. 두 방법 모두 모델에 더 많은 컨텍스트를 제공하는 추가 데이터가 필요합니다. 모델은 해당 컨텍스트를 사용하여 사용자 쿼리에 응답하고 기대에 따라 답변을 형성합니다. 일반적으로 다음 데이터 형식을 사용합니다.

• 원본 데이터는 프로덕션의 기존 데이터입니다. 이 데이터는 데이터베이스의 데이터와 같이 구조화되거나 JSON 파일과 같은 반구조화될 수 있습니다. 문서, 이미지 및 오디오 파일과 같이 구조화되지 않을 수도 있습니다.

• 접지 데이터는 모델의 초기 학습 데이터에서 다루지 않는 항목에 대한 정보가 포함된 원본 데이터에서 가져옵니다. 접지 데이터는 사용자 쿼리와 결합되어 특정 유추 호출의 컨텍스트에서 큰 언어 모델로 전송되는 프롬프트를 형성합니다. 유추 호출에 포함할 수 있는 다른 데이터는 시스템 프롬프트, 단발 또는 몇 번의 예제, 이전 상호 작용과 같은 컨텍스트 데이터입니다.

  이 데이터는 쉽게 검색할 수 있고 빠르게 검색할 수 있어야 합니다. 이 요구 사항으로 인해 검색에 최적화된 인덱스로 데이터를 저장해야 합니다. 이 인덱스는 사용자가 답변을 기다리는 동안 실시간으로 액세스됩니다. 이 데이터가 없으면 모델이 잘못된 결과를 생성하거나 사용자가 구체적으로 검색하는 내용에 적용되지 않을 수 있습니다.

• 미세 조정 데이터는 향후 추론 요청에 대한 특정 작업, 도메인 또는 응답 스타일에 적응할 수 있도록 모델에 영향을 주는 데 사용되는 정보입니다. 예를 들어 모델이 특정 문법 스타일로 답변을 제공해야 하는 경우 해당 스타일 가이드는 미세 조정 데이터 역할을 합니다.

• 사용자 데이터에 는 애플리케이션과 상호 작용하는 동안 사용자가 제공한 정보가 포함됩니다. 생성 모델과 상호 작용할 때 상태 저장 상호 작용이 발생합니다. 이러한 모델은 내재된 메모리가 부족하고 각 상호 작용을 원자성으로 처리합니다.

  채팅 애플리케이션에서 TURN 데이터라고도 하는 상태 저장 상호 작용을 관리하는 경우 필요한 가장 짧은 시간 동안 데이터를 저장하는 것이 중요합니다. 이상적으로는 세션이 종료된 후 이 데이터를 제거해야 합니다. 그러나 세션 기간을 초과하여 원래 질문 또는 모델의 응답과 같은 특정 데이터를 보존해야 하는 운영 또는 규정 준수 이유가 있을 수 있습니다. 가능하면 세션을 지나서 이 데이터를 저장하지 마세요.

인덱싱

데이터 디자인의 핵심에는 기본 데이터를 효율적으로 저장하고 관리하는 것이 포함됩니다. 이 방법을 사용하면 가장 높은 수준의 관련성을 달성하기 위해 데이터를 보강할 수 있습니다.

간단한 AI 전략에는 각 사용자 상호 작용에 대한 원본 데이터를 쿼리하는 작업이 포함될 수 있습니다. 그러나 이 방법은 직접 데이터 원본 상호 작용의 높은 비용과 복잡성 때문에 실용적이지 않습니다. 대신 검색 및 검색에 최적화된 인덱스의 복사본으로 원본 데이터를 용도를 변경해야 합니다. 이 방법의 목표는 모델의 이해력과 관련 응답을 생성하는 기능을 개선하는 것입니다.

데이터 저장소에 사용자 은행 계좌 및 기본 설정 및 금융 거래와 관련된 세부 정보를 저장하는 은행 워크로드를 고려합니다. RAG 패턴을 사용하는 생성 AI 시나리오에서는 모델이 관련 응답을 제공할 수 있도록 컨텍스트를 사용하여 접지 데이터를 만들고 인덱싱합니다. 예를 들어 유추 중에 컨텍스트에 대한 사용자 트랜잭션에 대한 관련 데이터를 제공하여 모델은 지난 분기에 사용자의 지출 패턴과 관련된 질문에 답변할 수 있습니다.

특수 인덱스 기술

접지 데이터를 검색 인덱스로 외부화하는 것이 좋습니다. 원본 시스템에서 직접 쿼리하는 대신 이 방법을 사용합니다.

검색 인덱스 사용의 이점이 있습니다. 예상된 쿼리에 따라 데이터 복사본을 모델링하고 변환할 수 있습니다. 원본 데이터에 액세스할 수 없을 가능성이 있으므로 기본 원본에 대한 직접 쿼리는 문제가 됩니다. 인덱스는 애플리케이션과 관련이 있다고 판단되는 한 데이터를 계속 사용할 수 있도록 합니다. 또한 원본 데이터 시스템에 대한 스트레스가 발생하지 않습니다. 이 전략은 AI 관련 쿼리가 기본 사용 사례에 영향을 주지 않도록 합니다.

일부 기술 옵션에는 자체 인덱싱 기능이 있습니다. 인덱스는 데이터 원본에 도달하고 해당 데이터를 통합할 수 있습니다. 이 옵션의 경우 네트워크 고려 사항이 핵심입니다. 인덱스가 데이터베이스에 연결해야 하는 경우 네트워크 대기 시간 및 안정성과 같은 잠재적인 문제가 있습니다.

데이터를 가져오는 초기 비용이 있습니다. 데이터가 인덱스에 있으면 변경 내용이나 업데이트가 없으면 데이터를 다시 이동할 필요가 없습니다. 시간에 따른 데이터 관리는 인덱스 디자인의 중요한 측면입니다. 자세한 내용은 인덱스 유지 관리를 참조 하세요.

기본 또는 사용자 지정 인덱스

특정 기술은 데이터에 대한 기본 인덱스 작성을 자동으로 지원합니다. 이 인덱스는 최소한의 입력으로 데이터 수집에서 생성됩니다. 인덱스는 기본 제공 기능을 제공합니다. 기본 인덱스는 개념 증명 및 일부 프로덕션 시나리오에 적합할 수 있습니다.

일부 시나리오에서는 특정 워크로드 요구 사항에 따라 관련성을 개선하기 위해 사용자 지정 인덱스 스키마가 필요할 수 있습니다. 이러한 요구 사항은 스키마를 디자인하고, 인덱스 기능을 사용하도록 설정하고, 관련 메타데이터를 포함하는 방법을 결정합니다.

스키마 디자인

인덱스는 검색을 위해 데이터를 구성하고 최적화하는 구조체로 생각할 수 있습니다. 보다 구체적으로는 테이블의 문서 및 필드에서 데이터를 구성합니다. 다음 사항을 고려합니다.

• 인덱스 토폴로지. 단일 인덱스의 모든 데이터를 공동 배치할지 아니면 여러 인덱스에 분산할지 평가합니다. 이 결정은 쿼리 성능, 인덱스 유지 관리, 쿼리 단순성 및 문서 간의 서로 다른 필드 구성(또는 스키마)에 크게 영향을 줍니다.

  예를 들어 특정 언어로 콘텐츠를 요청하는 사용자 쿼리를 고려합니다. 가장 간단한 데이터 디자인 선택은 모든 언어를 하나의 언어로 번역하고 단일 인덱스에 저장하는 것입니다. 또는 단일 인덱스의 모든 언어로 데이터를 저장할 수 있습니다. 이 옵션을 선택하면 각 언어에 대해 여러 문서가 생성됩니다. 인덱스의 필터링 기능을 사용하여 결과를 원하는 언어로 제한할 수 있습니다. 또는 각 인덱스가 쿼리에서 예상대로 지정된 언어에 대해 번역된 버전을 포함할 수 있습니다.

  경우에 따라 여러 검색 인덱스가 필요할 수 있습니다. 이 방법을 사용하면 검색 쿼리에서 최대 관련성을 위해 각 인덱스를 독립적으로 최적화할 수 있습니다. 예를 들어 HR 직원 핸드북과 제품 유지 관리 수동은 다양한 목적과 대상 그룹을 제공합니다. 개별적으로 인덱싱하여 각각에 대한 스키마 및 검색 쿼리를 조정하여 사용자 환경을 향상시킬 수 있습니다. 이 방법은 구현하기 복잡할 수 있으며 각 인덱스에 대한 호출을 용이하게 하기 위해 오케스트레이터가 필요합니다. 오케스트레이션 구성 요소는 Azure의 AI 워크로드에 대한 애플리케이션 디자인에 설명되어 있습니다.

• 문서 디자인. 데이터 디자인을 예상 사용자 쿼리에 맞게 조정하여 관련성을 최적화합니다. 각 문서에서 쿼리를 어떻게 처리해야 하는지 고려합니다. 검색 인덱스의 경우 관련 문서의 우선 순위를 지정하고 관련 정보로 조밀하게 압축된 간결한 집합으로 결과를 구체화합니다.

• 필드 디자인. 검색 성능 및 관련성을 지원하도록 인덱스 필드를 구성합니다. 인덱스 필드는 검색 가능하고, 검색 가능하고, 필터링 가능하고, 정렬 가능하게 만들려는 문서 특성에 매핑되어야 합니다. 여기에는 포함, ID 또는 검색을 강화할 수 있는 기타 데이터가 포함됩니다.

인덱스 기능

가장 관련성이 큰 문서 집합을 반환하도록 검색 인덱스 필드를 구성합니다. 결정은 검색 인덱스 기술 및 워크로드 요구 사항이 지원하는 기능에 따라 달라집니다.

• 필터, 검색 및 정렬 옵션입니다. 이러한 옵션은 확대를 위한 사용 사례와 직접 관련이 있기 때문에 고려해 보세요. 예를 들어 filterable 은 쿼리에 제공된 값에 대해 true 또는 false를 결정하고 관련 문서를 반환합니다. 검색 가능성을 위해 특성은 검색 쿼리가 필드를 참조할 수 있는지 여부를 나타냅니다. 예를 들어 텍스트 필드에 특정 텍스트가 포함되어 있는지 또는 다른 벡터와 수학적으로 관련되어 있는지 확인할 수 있습니다. 필요에 따라 검색 쿼리의 일부로 해당 필드에 상대적 가중치를 할당할 수 있습니다. 관련성별로 결과를 나열하는 결과 집합 을 정렬 가능하게 만들 수도 있습니다.

  거래. 필드를 인덱싱하는 기능을 사용하도록 설정하면 공간 요구 사항이 증가하여 비용에 영향을 줍니다. 사용하려는 기능만 추가합니다.

• Metadata. 인덱스에는 일반적으로 인덱스 필드와 연결된 메타데이터가 있습니다. 메타데이터는 관련 세부 정보를 제공하여 데이터를 이해하고 관리하는 데 도움이 됩니다. 인덱스를 디자인할 때 메타데이터를 검색할 수 있는지 아니면 관련성 결정에만 사용되는지 고려합니다. 이 결정은 기본 인덱싱 프로세스가 다르기 때문에 컴퓨팅 비용에 영향을 줍니다. 과도한 메타데이터는 인덱스의 크기를 불필요하게 늘릴 수 있습니다.

인덱싱을 위한 많은 기술 선택이 있습니다. 많은 사람들이 이전에 나열된 것과 같은 유사한 특성을 공유합니다. 일부 인덱스에는 인덱싱 중에 텍스트 및 언어 분석 처리와 같은 추가 기능이 있을 수 있습니다. 텍스트를 인덱싱 및 검색에 더 적합하게 만들려면 텍스트를 토큰으로 나누거나 소문자로 변환하거나 중지 단어를 제거합니다.

효율적인 쿼리

접지 데이터는 사용자 쿼리에 대한 응답의 정확도와 관련성을 높이기 위해 생성 AI 애플리케이션에서 사용됩니다. 사용자 쿼리를 미리 고려합니다. 질문할 수 있는 질문, 질문하는 사람 및 질문 빈도를 이해합니다. 이 정보는 애플리케이션 양식 컨텍스트를 돕고 관련될 수 있는 결과를 이해하는 데 도움이 됩니다.

일반적인 검색 유형은 다음과 같습니다.

• 벡터 쿼리는 상위 차원 공간의 벡터 표현 또는 데이터 요소를 기반으로 유사한 항목을 검색합니다.

• 키워드 검색은 텍스트 문서의 전체 콘텐츠 내에서 검색 됩니다. 대량의 텍스트 데이터를 인덱싱하고 쿼리하며 검색 엔진, 데이터베이스 및 문서 관리 시스템에서 일반적으로 사용됩니다.

• 의미 체계 순위 는 쿼리에 대한 의미 체계 관련성에 따라 순서를 변경하여 검색 결과의 관련성을 향상시키고, 가장 의미상 관련성이 높은 일치 항목을 목록 맨 위로 승격합니다.

• 하이브리드 검색 은 벡터 검색, 전체 텍스트 검색 및 의미 체계 순위와 같은 다양한 검색 유형을 결합하여 검색 결과의 관련성을 더욱 향상시킵니다.

모델 성능을 더욱 향상시키려면 검색 유형을 결합합니다.

데이터가 저장되고 처리되는 방식은 쿼리 효율성에 영향을 줍니다. 데이터가 인덱스에 추가될 때마다 인덱싱에 컴퓨팅 주기가 필요합니다. 동일한 컴퓨팅 리소스에서 쿼리에 대한 인덱싱 및 응답이 수행되면 경합이 발생할 수 있습니다. 이상적으로 인덱스는 쿼리에 효율적으로 응답하고 과도한 인덱싱이 아닌 관련 문서를 찾는 기본 목표에 집중해야 합니다.

비용과 성능은 인덱스 디자인의 핵심 동인입니다. 섀도 복사본을 만드는 것과 같은 기술은 쿼리 속도를 높일 수 있습니다. 그러나 데이터 중복은 인덱스를 통해 발생하므로 비용이 발생합니다.

거래. 인덱스 디자인은 비용과 성능을 모두 고려해야 합니다. 스토리지를 최적화하고 과도한 인덱싱보다 효율적인 쿼리 응답 및 관련 문서 검색의 우선 순위를 지정하여 균형을 조정합니다.

데이터 저장소에 대한 기술 선택 항목의 경우 Elasticsearch 또는 AI Search와 같은 검색 인덱스는 벡터화된 검색 및 관련성 기반 검색을 비롯한 강력한 검색 기능을 제공합니다. 또는 쿼리에 최적화되어 있으므로 가지고 있는 데이터 형식과 필요한 쿼리 유형을 지원하는 데이터베이스 옵션을 고려해 보세요. 궁극적으로, 옵션에서 제공하는 기능과 팀에 새로운 기술 세트를 구축하는 투자에 관한 것입니다.

데이터 준비

접지 데이터는 의미 체계 쿼리에 적합해야 하는 기존 데이터를 기반으로 합니다. 인덱스의 관련 문서를 찾기 위한 일부 쿼리는 리터럴 일치일 수 있습니다. 다른 쿼리에는 유사 항목 일치가 필요합니다.

컨텍스트 데이터가 모델에 대한 추론 요청을 지원할 준비가 되기 전에 데이터 정리, 변환 및 구조화를 목표로 하는 선행 전처리 단계가 있습니다. 목표는 노이즈 및 바이어스 감소, 효율적으로 검색 및 인덱스 검색의 관련성을 최대화하는 것입니다. 전처리를 위한 선택 도구 또는 논리는 워크로드 팀에 따라 달라지지만 몇 가지 광범위한 고려 사항이 있습니다.

데이터 볼륨 범위 지정

데이터 볼륨 범위 조정에는 관련성이 증가하도록 긴밀한 인덱스를 만들기 위해 데이터 범위를 확장 또는 축소하여 조정하는 작업이 포함됩니다. 쿼리 효율성은 또 다른 중요한 관심사입니다. 불필요한 데이터를 저장하는 것은 이러한 두 가지 목표에 부정적인 영향을 줍니다. 예를 들어 사용자의 위치 데이터를 고려합니다. 도시 부분만 관련된 경우 주소를 나타내는 전체 텍스트 대신 도시 텍스트만 저장하여 최적화합니다.

다음은 몇 가지 광범위한 고려 사항입니다.

• 데이터 제거. 제품 기능에 필수적인 것만 유지하여 불필요한 세부 정보를 삭제합니다. 다음은 몇 가지 일반적인 예제입니다.

  • 질적 제거. 광범위한 범위에서 더 좁은 상대 데이터로 전환하는 한 가지 방법은 관련 원본 데이터를 인덱싱하도록 선택적으로 선택하여 저품질 데이터를 제거하는 것입니다. 문제는 AI 시나리오와 관련이 없는 콘텐츠를 프로그래밍 방식으로 식별하는 것입니다. 콘텐츠는 감사 또는 완전성과 같은 다른 의도에 유용할 수 있지만 AI 워크로드 위험에 포함하면 관련성이 줄어듭니다. 이러한 콘텐츠에 플래그를 지정하는 한 가지 방법은 인덱스 채우기 시간에 콘텐츠를 인덱스로 추가해야 하는 경우 사용할 수 있는 메타데이터를 사용하는 것입니다.

  • 중요한 데이터. 원본 데이터에서 인덱스로 데이터를 복사하면 중요한 정보를 가져올 수도 있습니다. 원본에 적용되는 데이터 분류 레이블을 준수하고 이 데이터 집합에 대해 동일한 수준의 민감도를 유지합니다. 개인 정보가 있는 데이터를 처리하는 경우 쿼리에 응답할 필요가 없는 한 개인 데이터를 저장하지 마세요. 예를 들어 전자 메일을 인덱싱할 때 데이터 분류를 적용합니다. 전자 메일에 중요한 플래그가 지정되면 일반 민감도 데이터 저장소에 저장하지 마십시오.

  • 텍스트 정규화 및 표준화 오타 주소 지정 및 텍스트 표준화는 키워드 기반 인덱스에 매우 중요합니다. 잠재적인 사용 사례는 번역이며, 특히 다국어 콘텐츠를 처리할 때 그렇습니다.

    이러한 유형의 전처리도 포함에 필요하며, 이를 통해 해당 컨텍스트와 중요도에 따라 단어를 비교할 수 있습니다. 그러나 단어의 대/소문자 구분에서 한 가지 문제가 발생합니다. 맥락이 중요하며 형용사 "시민"과 적절한 명사 "(혼다) 시빅"의 의미론적 차이와 같은 뉘앙스가 있을 수 있습니다.

• 데이터 추가. 보강 컨텍스트는 일반적으로 원본 데이터에 없는 메타데이터를 사용하는 경우가 많습니다. 예를 들어 텍스트 조각을 고려합니다. 루프 또는 AI의 사용자는 코드 조각의 컨텍스트를 사용하여 답변할 수 있는 관련 질문을 만듭니다. 이러한 질문을 접지 데이터와 함께 저장하는 경우 사용자 쿼리를 생성된 쿼리와 비교하여 문서 관련성을 평가할 수 있습니다. 접지 데이터로 이 새로운 데이터를 공동 배치하는 것은 청크 분할된 데이터를 보강하는 강력한 방법입니다.

  또 다른 사용 사례는 구조화되지 않은 데이터를 분석하는 동안 발견된 추가 엔터티입니다. 이러한 엔터티를 인덱스에 추가하고 외부 시스템을 검색 및 필터링하는 데 사용하거나 복잡한 계산을 수행하는 데 사용할 수 있습니다. 예를 들어 회사 이름을 식별하는 경우 외부 데이터베이스에서 해당 업계 또는 기타 관련 정보를 조회하여 인덱싱에 추가할 수 있습니다.

  데이터 계보를 유지 관리하는 것이 좋습니다. 시스템이 다양한 구성 요소를 하나의 인덱스로 집계할 때 정보가 손실 될 수 있으므로 AI 워크로드에서 데이터 원본을 추적하는 것이 중요합니다. 이 정보는 사용자에게 노출되지 않을 수도 있지만 데이터 원본에 대한 정보는 내부 데이터 거버넌스 팀에 매우 중요합니다. 이 메타데이터가 반드시 모델에 대한 것은 아닙니다. 투명성과 책임을 유지하는 데 도움이 됩니다.

  거래. 한편, 새 데이터를 추가하면 데이터 집합 내에서 관련성을 찾을 가능성이 높아질 수 있습니다. 그러나 이 혜택은 비용이 듭니다. 특히 해당 필드를 처리하고 관리하는 데 필요한 계산 리소스입니다. 데이터를 수집하고 저장하는 데 소요되는 시간은 상당할 수 있습니다. 불필요한 필드로 오버로드하면 리소스에 부담을 줄 수 있습니다.

• 텍스트 데이터 처리. 동의어, 형태소 분석 및 의미 체계 근접성과 같은 기술을 고려하여 관련성을 높입니다. 가능한 경우 이러한 기술을 도구에 위임합니다. Elasticsearch 또는 AI 검색과 같은 일부 기술은 인덱스를 만드는 동안 데이터를 전처리하기 위한 기능을 제공합니다.

데이터 형식 모핑

데이터 저장소의 인덱스 필드는 특정 목적을 위해 데이터 형식입니다. 숫자 필드는 효율적인 쿼리를 용이하게 하고, 텍스트 필드는 텍스트 기반 검색을 허용하며, 부울 필드는 이진 정보를 처리합니다.

원본 데이터는 일반적으로 텍스트, 이미지 및 테이블과 같은 다양한 유형의 데이터에 존재하며 해당 데이터는 복잡할 수 있습니다. 키-값 쌍을 추출하고, 의미 체계 청크에 대한 섹션 제목을 식별하고, 특정 식별자를 인식하는 등의 작업을 수행해야 할 수 있습니다.

예를 들어 원본 데이터에 이미지가 포함된 경우 본질적으로 검색할 수 없습니다. 효율적인 의미 체계 검색 및 비교를 사용하려면 벡터 표현으로 변환해야 합니다. 관련성이 이러한 형식 뒤에 있는 데이터에 연결된 경우 데이터 추출에 투자합니다. 원본 데이터 형식을 쿼리 및 분석에 도움이 되는 기능 데이터 형식으로 변환합니다.

청크 및 포함

접지 데이터에는 대용량 정보가 포함되어 있는 경우가 많지만 모델은 특정 금액만 토큰화할 수 있습니다. 청크는 문서를 개별적으로 처리 및 인덱싱할 수 있는 더 작은 조각으로 나누는 것을 포함하므로 중요한 데이터 디자인 전략입니다. 이 전략을 사용하면 토큰 제한에도 불구하고 효율적인 검색 및 검색을 수행할 수 있습니다. 선택한 큰 언어 모델에서 처리할 수 있는 최대 토큰 수를 확인합니다. 청크는 해당 제한을 초과해서는 안 됩니다.

청크 분할을 구현하는 많은 기술이 있습니다. 자세한 내용은 청크 분할 방법을 참조 하세요.

포함은 벡터 검색 기능을 사용하도록 설정하는 또 다른 디자인 전략이기도 합니다. 포함은 접지 데이터를 기반으로 AI 모델에서 생성되는 개체의 수학적 표현입니다. 인덱스에 저장되고 복잡한 쿼리가 더 나은 관련성으로 결과를 생성하는 데 도움이 되는 더 많은 컨텍스트를 추가합니다. 자세한 내용은 포함 생성을 참조하세요.

인덱스 유지 관리

시간 경과에 따른 유지 관리는 인덱스 디자인의 중요한 측면입니다. 문서가 변경되지 않은 상태로 유지되는 정적 데이터의 경우 인덱스 유지 관리는 간단합니다. 그러나 대부분의 인덱스는 동적입니다. 시간이 지남에 따라 새 데이터가 추가되고 인덱스 스키마에 새 필드가 필요할 수 있습니다. 반대로 일부 데이터 및 필드는 더 이상 관련이 없는 경우 삭제해야 할 수 있습니다. 인덱서에 일반적으로 사용되는 기술 옵션에는 업데이트를 자동으로 처리하는 기능이 있습니다. 권장 인덱스 특성에 대한 자세한 내용은 검색 인덱스에 대한 고려 사항을 참조하세요.

유지 관리 조건

• 기능 업데이트. 애플리케이션 기능이 변경된 경우 인덱스 업데이트가 필요할 수 있습니다. 이 상황은 새로운 질문을 할 때 발생합니다. 이러한 변경 내용을 수용하려면 인덱싱에 새 필드를 추가하거나 기존 필드에서 필터링, 검색 또는 텍스트 처리 옵션을 수정해야 할 수 있습니다.

• 데이터 삭제. 데이터 삭제는 사용 가능한 데이터와 누락된 데이터를 분석하여 관련이 없는 항목을 확인해야 하기 때문에 어려운 일입니다. 오래된 콘텐츠를 인덱스에서 제외하려면 검색 엔진이 특정 페이지 또는 콘텐츠를 인덱싱하지 못하도록 하는 메타데이터를 사용하는 것이 좋습니다. 또한 스토리지 옵션을 선택할 때 삭제를 효율적으로 지원하는 기술을 선택합니다. 예를 들어 Blob Storage는 일시 삭제를 지원합니다. 스토리지에서 AI 검색 및 로드 문서를 사용하는 경우 Blob Storage는 제거된 문서를 검색하고 해당 항목을 삭제할 수 있습니다. 이 방법은 이상적이지는 않지만 인덱스 크기가 크기 때문에 다시 인덱싱 비용이 많이 드는 경우 필요합니다.

  잊혀질 권리의 개념은 온라인 플랫폼 또는 데이터베이스에서 개인 데이터를 제거할 수 있는 개인의 권리를 의미합니다. 학습에 사용된 경우 개인 데이터를 제거하는 정책이 있는지 확인합니다. 데이터 집합을 다시 인덱싱하여 이 요구 사항을 해결할 수 있습니다. 트랜잭션 데이터베이스에서 데이터가 삭제되면 후속 인덱스 업데이트에 해당 변경 내용이 반영됩니다.

• 호환성 유지 관리 애플리케이션에는 특정 데이터 구조가 필요한 경우가 많으며, 편차가 있으면 해당 기능이 중단됩니다. 예를 들어 필드가 제거되고 애플리케이션이 해당 필드를 요청하는 경우 오류 조건이 발생할 수 있습니다. 기존 데이터베이스의 경우와 마찬가지로 인덱스에 대해 정방향 호환성 사고 방식을 채택하고 엄격한 수준을 유지합니다. 필드 추가 또는 제거와 같이 인덱스를 변경하는 경우 코드 업데이트를 사용하여 스키마 변경 내용을 조정합니다.

  거래. 인덱스 추가, 업데이트 및 삭제 작업은 비용이 많이 듭니다. 데이터 저장소 크기 및 효율성에 따라 업데이트 빈도 및 성능 비용을 고려합니다. 사용되지 않는 문서를 인덱스에 유지하면 스토리지, 유지 관리 및 쿼리 비용이 발생합니다.

배포 전략

배포 전략. 인덱스 업데이트를 위한 두 가지 주요 전략이 있습니다.

• 병렬 배포. 이 방법에서 업데이트가 있는 새 인덱스는 기존 인덱스와 함께 적용됩니다. 새 인덱스를 테스트하고 완전히 작동하면 업데이트된 인덱스를 사용하도록 쿼리가 전환됩니다. 애플리케이션은 새 인덱스와만 상호 작용하기 때문에 이 스위치를 인식하지 못합니다. 새 인덱스가 프로덕션 용도로 배포된 후 다른 문제를 발견하면 이전 인덱스로 되돌릴 수 있습니다. 이 방법은 가동 중지 시간을 최소화하고 지속적인 가용성을 보장합니다.

  인덱스 다시 작성 비용이 합리적이고 적절한 시간 프레임에서 완료할 수 있는 경우 병렬 업데이트가 제대로 작동합니다. 일반적으로 큰 인덱스는 더 많은 리소스를 사용하므로 인덱스를 최대한 효율적으로 유지하려고 노력합니다. 불필요한 증가를 방지하기 위해 인덱스를 정기적으로 모니터링하고 유지 관리합니다.

• 현재 위치 업데이트 배포. 이 방법은 기존 인덱스 직접 수정합니다. 중복 비용을 절감하는 것이 유용할 수 있지만 잠재적인 가동 중지 시간 및 리소스 집약적 작업으로 인해 위험이 발생합니다. 인덱스가 크고 처음부터 다시 빌드하는 것이 원하는 업데이트 빈도를 초과하는 경우 현재 위치 업데이트를 사용하는 것이 좋습니다. 그러나 이 방법은 쉽지 않으며 SLO(서비스 수준 목표)를 위반할 위험이 있습니다.

  거래. 추가, 업데이트 및 삭제를 배포하는 현재 위치 업데이트를 수행하지 않도록 인덱스의 병렬 배포를 수행하는 비용을 평가합니다. 대부분의 경우 현재 위치 업데이트 대신 병렬 업데이트를 사용해야 합니다. 인덱스를 다시 작성하면 완전히 새로운 데이터 집합을 만들기 때문에 프로세스에서 삭제 및 업데이트를 효과적으로 처리합니다. 이 전략은 데이터를 테스트할 수 있는 기회를 제공합니다. 병렬 배포가 일시적으로 데이터를 복제하고 추가 비용이 발생하더라도 테스트 및 성능 평가의 이점은 종종 이 스토리지 요구 사항을 정당화합니다. 인덱스를 라이브로 만들기 전에 데이터를 검사하여 예상과 일치하는지 확인합니다.

• 예약된 업데이트입니다. 데이터 원본과의 지속적인 실시간 통신을 유지하는 대신 정기적으로 접지 데이터를 새로 고칠 수 있습니다. 이 방법을 사용하면 예약된 업데이트를 통해 데이터가 관련성을 유지하므로 일정한 상호 작용이 필요하지 않습니다.

• 긴급 업데이트. 원치 않는 데이터가 실수로 검색 인덱스로 유출되는 등 예기치 않은 상황이 발생할 수 있습니다. 이 문제가 발생하는 경우 특정 문서를 제거하거나 인덱스 내에서 데이터를 조정하는 등의 즉각적인 조치를 취해야 할 수 있습니다. 병렬 업데이트 또는 현재 위치 업데이트와 같이 선택한 배포 전략에 관계없이 항상 긴급 작업의 가능성을 계획합니다.

• 자체 업데이트 인덱스입니다. 인덱싱 기술이 인덱스를 외부 데이터 원본과 동기화되도록 자동으로 업데이트하도록 지원하는 경우 데이터의 변경 내용을 자동으로 처리할 수 있습니다. 데이터 변경에는 수동 개입 없이 추가 또는 삭제가 포함됩니다. 모든 변경은 리소스를 사용하는 인덱스의 작업을 트리거합니다. 인덱스는 쿼리에 계속 응답할 수 있지만 업데이트 프로세스 중에 처리 용량을 줄일 수 있습니다.

새로 고침 작업

원본 데이터 생성 또는 수정과 인덱스에 대한 추가 사이의 기간을 지표로 측정하고 SLO에 대해 추적합니다. 이 지표는 필요할 때 인덱스에 데이터를 사용할 수 있도록 데이터 파이프라인 디자인을 업데이트하는 것과 관련한 데이터 결정을 내립니다. 인덱스는 필요한 만큼 새로워야 합니다.

새로 고침을 유지하려면 인덱스를 완전히 다시 빌드하거나 증분 방식으로 업데이트하여 원래 데이터 원본과 동기화 상태를 유지할 수 있습니다. 두 방법 모두 인덱스가 최신 상태로 정확하게 유지되도록 합니다.

모델 미세 조정에 대한 선불 투자는 RAG 패턴, 프롬프트 엔지니어링 및 데이터 보강 방법을 구현하는 것보다 저렴할 수 있습니다.

다음 단계