주요 컨텐츠로 이동
제품

어디서든 모든 에이전트에 대한 관찰 가능성: Databricks의 OpenTelemetry 및 Unity Catalog를 사용한 프로덕션 준비 추적

Unity Catalog의 OpenTelemetry 추적은 분석, 평가 및 모니터링을 통해 AI 에이전트의 지속적인 개선 플라이휠을 만듭니다.

작성자: 피라스 파라, Bruno Faria , Anoop Sunke

  • 문제점: AI 에이전트는 방대한 양의 추적 데이터를 생성하지만, 기존의 관찰 가능성 도구는 해당 데이터를 보존하는 데 비용이 많이 들고, 거버넌스가 어려우며, 평가 및 분석 워크플로우에서 사용하기 어렵습니다.
  • 해결책: Databricks는 이제 완전히 관리되고 서버리스인 수집 경로를 통해 OpenTelemetry(OTel) 추적을 Unity Catalog 테이블에 직접 쓸 수 있도록 지원합니다.
  • 이점: 추적 데이터를 Lakehouse에 직접 안착시킴으로써 팀은 장기 보존, 통합된 평가 및 모니터링 워크플로우, 운영할 OTel 인프라 없이도 거버넌스가 적용되고 분석 준비가 된 관찰 가능성 데이터를 확보할 수 있습니다.
  • 결과: 프로덕션 추적 데이터는 즉시 분석 및 평가에 사용할 수 있게 되어 실제 사용량, 모델 평가, 지속적인 개선 간의 빠른 반복 루프를 가능하게 합니다.

AI 추적이 기존 관찰 가능성을 방해하는 이유

AI 애플리케이션이 프로덕션 환경으로 이동함에 따라, 프롬프트, 도구 호출, 응답, 지연 시간 및 실행 경로를 캡처하여 에이전트가 실제로 어떻게 작동하는지 이해하는 가장 명확한 방법 중 하나가 추적입니다. 강력한 추적 없이는 에이전트가 작동하는 이유를 이해하기 어려워 디버깅, 평가 및 거버넌스가 훨씬 더 어려워집니다.

AI 추적은 기존 디버깅 및 관찰 가능성 사용 사례를 넘어 분석, 평가 및 모니터링 워크플로우에 빠르게 유용해집니다. 팀은 이를 더 오래 보관하고, SQL로 분석하고, 비즈니스 및 모델 데이터와 조인하고, 평가 및 모니터링에 재사용하기를 원합니다. 추적이 관찰 가능성 시스템 내에만 있으면 유연성이 제한되고, 거버넌스가 파편화되며, 데이터를 분석 워크플로우로 이동하려면 특히 민감한 프롬프트 데이터가 관련된 경우 추가 파이프라인과 중복이 필요합니다.

OTel 추적 수집

Databricks는 이제 OpenTelemetry(OTel) 형식을 사용하여 OTel 추적을 Unity Catalog에 직접 작성하는 것을 지원합니다. 실제로는 추적을 실시간으로 수집하여 Delta 테이블에 저장할 수 있으며, 여기서 데이터의 나머지 부분과 동일한 확장성, 거버넌스 및 도구를 활용할 수 있습니다.

이는 팀이 추적 데이터를 사용하는 방식을 바꿉니다:

  • 실용적인 보존을 통한 실시간 수집: 추적은 높은 처리량으로 생성될 때 작성될 수 있으며, 관찰 가능성 플랫폼과 일반적으로 관련된 비용 압박 없이 장기간 보존될 수 있습니다.
  • Lakehouse를 사용한 분석 및 거버넌스: 추적이 테이블에 있으면 다른 데이터 세트와 마찬가지로 취급할 수 있습니다. SQL로 쿼리하고, 대시보드를 구축하고, ETL 파이프라인을 실행하고, Genie와 같은 도구를 사용하고, PII 마스킹과 같은 거버넌스 컨트롤을 적용할 수 있습니다.
  • 전체 MLflow 평가 스택 사용: MLflow를 사용하면 디버깅을 위해 추적을 쉽게 검색, 필터링 및 드릴다운할 수 있습니다. Unity Catalog에 추적을 영구 저장하면 일반적인 실험 제약 조건(예: 추적 제한)이 제거되어 대규모 오프라인 평가를 실행하고, 프로덕션 시스템을 모니터링하고, 워크로드가 증가함에 따라 품질을 지속적으로 개선하기가 더 쉬워집니다.

SaaS 대 Lakehouse

그렇다면 SaaS 관찰 가능성 도구에 전적으로 의존하는 것은 어떨까요?

  1. 보존 경제성: 에이전트는 방대한 텍스트 페이로드를 생성합니다. 객체 스토리지의 Delta Lake에 이 데이터를 저장하는 것은 SaaS 기반 보존 모델보다 훨씬 비용 효율적입니다.
  2. PII 교착 상태: 타사 플랫폼으로 원시 프롬프트를 보내면 InfoSec 마찰이 발생할 수 있습니다. Unity Catalog 내에 추적을 유지하면 데이터 주권을 유지하고 거버넌스를 단순화하는 데 도움이 됩니다.
  3. 분석, 단순한 원격 측정 이상: SaaS 도구는 지연 시간과 같은 운영 메트릭에 강력하지만, Lakehouse는 분석 엔진을 제공합니다. 추적을 수익 및 전환과 같은 비즈니스 데이터와 조인하여 실제 영향을 이해하고 시스템 상태를 넘어설 수 있습니다. 또한 Lakehouse를 사용하면 추적에 직접 AI를 적용하고 평가 프레임워크를 구축하여 시스템 품질을 지속적으로 개선할 수 있습니다.

아키텍처: 서버리스 OpenTelemetry 수집

Databricks는 계측과 스토리지를 분리하기 위해 OTel 표준을 사용하여 OpenTelemetry(OTel) 추적, 로그 및 메트릭을 Unity Catalog 테이블에 직접 수집하는 것을 지원합니다.

Databricks는 Zerobus Ingest를 통해 투명하게 제공되는 관리형 수집 계층을 제공하여 기존의 멀티홉 원격 측정 파이프라인의 운영 복잡성을 제거합니다. Zerobus Ingest는 오픈 소스 수집기를 통해 gRPC를 통한 표준 OpenTelemetry 프로토콜(OTLP)을 기본적으로 지원하는 완전 관리형 서버리스 수집 엔진 역할을 하며, REST API 기능은 MLflow와 같은 애플리케이션 프레임워크와의 원활한 통합을 가능하게 합니다. 애플리케이션은 스팬, 로그 및 메트릭을 Unity Catalog 테이블로 직접 내보낼 수 있으며, 여기서 데이터는 Delta 형식으로 저장됩니다. "단일 싱크" 아키텍처를 통해 Zerobus Ingest는 데이터를 Lakehouse로 직접 스트리밍하여 관찰 가능성을 단순화합니다. 기존 OLTP 호환 수집기는 Kafka와 같은 중간 메시지 버스를 완전히 우회하여 gRPC를 통해 이 엔드포인트에 직접 연결할 수 있습니다. Zerobus Ingest는 인프라 오버헤드 없이 수집 및 내구성을 처리하는 고처리량 원격 측정 파이프라인 역할을 합니다. OTel 호환 클라이언트는 인기 있는 AI 에이전트 프레임워크를 포함하여 이 엔드포인트로 추적을 내보낼 수 있습니다.

여기서부터 추적, 로그 및 메트릭은 Lakehouse의 최우선 데이터가 되어 임시 SQL 분석, 대시보드, 다운스트림 분석 및 MLflow 평가 및 모니터링 워크플로우를 지원합니다. 원격 측정 통합은 프로덕션 동작이 평가 및 분석을 지원하고, 이는 다시 더 빠른 반복과 더 나은 에이전트 성능을 주도하는 지속적인 개선 플라이휠을 만듭니다.

Databricks Lakehouse Platform

튜토리얼: 추적을 Lakehouse에 연결하기

샘플 에이전트: 지원 관리자 도우미

이 블로그에서는 추적을 엔드투엔드로 시연하는 데 사용할 간단한 지원 관리자 도우미를 만들 것입니다. 에이전트는 여기서 수행한 것처럼 Databricks 외부에서 배포할 수 있으며, 이는 추적 수집이 에이전트가 실행되는 위치와 분리되어 있음을 강조합니다.

추론 및 응답 생성을 위해 Databricks 호스팅 Claude Sonnet 4.6 모델을 기반으로 하는 LangGraph 에이전트를 구축했습니다. 에이전트는 도구로 Genie Space를 호출하며, 이는 여기에서 배포할 수 있습니다.

사용자가 데이터 기반 질문을 하면 에이전트는 MCP 도구 API를 통해 Genie를 호출합니다. Genie는 요청을 SQL로 변환하고, 지원 데이터 세트에 대해 실행하고, 결과를 반환합니다. 그런 다음 에이전트는 결과를 요약하고 지원 관리자에게 실행 가능한 통찰력을 제공합니다.

Support manager assistant

UC를 사용한 OTel 추적 설정

에이전트를 계측하기 전에 먼저 OpenTelemetry 추적을 저장할 UC의 테이블을 구성합니다. 이 예에서는 MLflow를 사용하여 Unity Catalog에 기본 OpenTelemetry 테이블을 생성하고 MLflow 실험에 연결하여 추적을 UI에서 검색, 분석 및 주석 처리할 수 있도록 합니다. 먼저 SQL 웨어하우스와 MLflow 실험을 식별(또는 생성)한 다음 MLflow Python 라이브러리를 사용하여 Unity Catalog 테이블을 프로비저닝하고 스키마를 실험과 연결합니다. 전체 단계는 여기의 문서를 따르세요.

이 설정은 OpenTelemetry 스팬, 로그 및 메트릭에 대한 Unity Catalog 테이블을 생성합니다. 기본 데이터는 OpenTelemetry 호환 테이블 형식으로 저장되며, MLflow 서비스는 쿼리 및 분석을 용이하게 하기 위해 OpenTelemetry 데이터를 MLflow 친화적인 형식으로 변환하는 Databricks SQL 보기를 자동으로 함께 생성합니다. 여기에는 다음이 포함됩니다:

  • <table_prefix>_otel_spans: 각 요청에 대한 자세한 스팬 수준 실행 데이터
  • <table_prefix>_otel_logs: 실행 중에 캡처된 구조화된 로그/이벤트 데이터
  • <table_prefix>_otel_metrics: 실행 중에 캡처된 숫자 원격 측정
  • <table_prefix>_otel_annotations: 메타데이터, 태그, 평가/피드백, 예상치, 실행 링크를 포함하여 표준 OTel 신호가 아닌 MLflow별 추적 데이터
  • <table_prefix>_trace_unified: 원시 스팬 데이터 및 추적 메타데이터를 포함하여 추적 데이터를 단일 추적당 레코드로 조립하는 통합 보기
  • <table_prefix>_trace_metadata: MLflow 태그, 메타데이터 및 평가가 추적 ID별로 그룹화됩니다. MLflow 추적 메타데이터만 필요한 경우 통합 뷰보다 더 효율적입니다.
  • Unity Catalog 테이블 OpenTelemetry용

    실험 설정 후 에이전트 계측은 동일하게 유지됩니다. OTel 호환 계측 라이브러리는 구성된 엔드포인트로 추적을 내보낼 수 있습니다. 자동 및/또는 수동 추적은 여기에 설명된 대로 수행할 수 있습니다. 저희 예시에서는 상세한 LangGraph 실행(모델 호출 및 도구 호출)을 캡처하기 위해 mlflow.langchain.autolog()에 의존합니다. 또한 각 호출을 단일 엔드투엔드 실행으로 관찰할 수 있도록 요청 수준 루트 스팬을 설정하기 위해 @MLflow.trace로 진입점을 래핑합니다.

    샘플 추적 검사

    이제 에이전트가 계측되고 추적이 Unity Catalog로 흐르고 있으므로 실제 실행을 살펴보겠습니다.

    이 예시에서는 지원 관리자 어시스턴트에게 다음과 같이 요청했습니다.

    "어떤 지원 엔지니어를 승진시켜야 할까요?"

    에이전트는 요청을 평가하고, 지원 데이터를 수집하기 위해 여러 번 Genie 스페이스를 호출했으며, 성능 지표를 기반으로 추천을 반환했습니다.

    성능 분석

    응답은 간단해 보이지만, 추적은 이를 생성한 기본 실행 경로를 보여줍니다. MLflow 실험에서 각 도구 호출과 claude sonnet 모델의 추론 로직을 볼 수 있습니다. 최종 답변을 종합하기 전에 세 번의 genie 스페이스 도구 호출이 있었음을 알 수 있습니다.

    Genie 스페이스 도구

    각 개별 단계를 클릭하여 입력과 출력을 연구할 수 있습니다.

    Genie 스페이스 도구

    추적이 Delta 테이블로 저장되므로 다른 데이터셋과 마찬가지로 쿼리할 수 있습니다. mlflow_experiment_trace_unified 뷰에서 시작하면 요청, 응답, 추적 메타데이터 및 스팬 배열을 포함하는 레코드를 찾을 수 있습니다.

    Genie 스페이스 도구

    디버깅을 넘어: 추적 데이터 분석

    이제 추적이 Unity Catalog에 저장되었으므로 배치 및 스트리밍 분석 모두에 즉시 사용할 수 있습니다.

    Unity Catalog의 거버넌스

    그러나 프롬프트와 응답에는 민감한 정보가 포함되는 경우가 많으므로 추적 데이터를 거버넌스된 데이터로 취급하는 것이 중요합니다. Unity Catalog에 저장함으로써 추적은 카탈로그 및 스키마 권한부터 열 마스킹 및 행 수준 필터링에 이르기까지 세분화된 액세스 제어를 상속하여 유연성을 제한하지 않고 안전하고 프로덕션 준비가 된 분석을 가능하게 합니다.

    액세스가 설정되면 팀은 위에서 수행한 것처럼 SQL을 사용하여 기본 테이블과 뷰를 쿼리하여 안전하게 임시 분석을 실행할 수 있습니다. 또한 대시보드 및 Genie 스페이스 외에도 실행 가능한 비즈니스 통찰력을 얻기 위해 ETL 파이프라인을 구축할 수 있습니다.

    대시보드

    MLflow 실험 UI는 이제 추적 볼륨, 오류, 지연 시간, 토큰 사용량 및 비용에 대한 뷰를 포함하여 Unity Catalog의 추적에 대한 기본 관찰 가능성 대시보드를 제공합니다. 대부분의 팀에게는 일상적인 에이전트 상태를 모니터링하기에 충분합니다.

    대시보드

    기본 시각화를 넘어서는 보기가 필요할 때 추적 테이블은 여전히 Unity Catalog의 Delta 테이블일 뿐입니다. 사용자 지정 AI/BI 대시보드를 구축하고 AI의 도움을 받아 표준 SQL을 작성하여 팀이 중요하게 생각하는 모든 것을 모델링할 수 있습니다.

    사용자 지정 대시보드가 기본 뷰 위에 추가할 수 있는 기능을 보여주기 위해 추적 테이블 위에 AI 운영 센터를 구축했습니다. 언급할 만한 몇 가지 기능은 다음과 같습니다.

    계약 가격을 이용한 맞춤형 비용 분석

    기본 비용 지표는 표준 목록 가격을 사용하는데, 이는 협상된 요율이 있거나 다른 가격으로 미세 조정된 모델을 실행하는 팀에게는 부정확할 수 있습니다. SQL을 제어하므로 가격 책정 로직을 쿼리에 직접 포함했습니다. 대시보드는 모델 유형별(예: GPT 5.5 대 Claude 4.6 Sonnet) 토큰 사용량을 추적하고 계약 요율을 적용하여 실제 지불하는 비용을 반영하는 추적당 예상 비용을 생성합니다. 이를 통해 검색 루프로 인해 $0.50의 비용이 발생하는 단일 복잡한 쿼리와 같은 비싼 이상치를 쉽게 감지할 수 있습니다.

    맞춤형 비용 분석

    구성 요소 수준 성능

    기본 지연 시간 뷰는 추적 수준에서 P50/P99를 보여줍니다. 한 단계 더 나아가 어떤 도구가 느린지 확인하기 위해 에이전트의 개별 도구(예: retrieve_docsgenerate_response)별 지연 시간(P50, P99) 및 오류율을 분해하는 도구 성능 위젯을 구축했습니다. 이를 통해 LLM, Genie 도구 호출 또는 다른 단계가 병목 현상인지 여부를 알 수 있으므로 사용자 경험이 저하되는 부분을 정확히 파악할 수 있습니다.

    구성 요소 수준 성능

    Genie 스페이스

    비즈니스 및 기술 이해 관계자 모두 SQL을 작성하지 않고도 에이전트 동작을 탐색하고 싶어하는 경우가 많습니다. 추적 테이블을 Genie를 통해 노출함으로써 팀은 자연어 분석을 원격 측정 데이터에 대해 사용할 수 있게 하여 사용자가 성능, 도구 사용량, 지연 시간 및 모델 동작에 대해 직접 질문할 수 있습니다. 저희 예시에서는 다음과 같은 질문을 포함할 수 있습니다.

    • 어떤 유형의 요청에 에스컬레이션이 필요합니까?
    • 도구 재시도가 증가하고 있습니까?
    • 어떤 쿼리가 가장 복잡한 실행 경로를 트리거합니까?

    추적 테이블

    ETL 파이프라인

    추적이 Delta 테이블로 저장되므로 다른 데이터셋과 마찬가지로 다운스트림 ETL 파이프라인에 공급할 수 있습니다. 변경 데이터 피드(CDF)를 사용하면 팀이 전체 테이블을 반복적으로 스캔하지 않고도 배치 또는 스트리밍으로 추적 데이터를 점진적으로 처리할 수 있습니다.

    이를 통해 관찰 가능성을 운영할 수 있습니다. 예를 들어, 파이프라인은 추적 패턴을 모니터링하고 지연 시간이 정의된 임계값을 초과하거나, 도구 오류가 급증하거나, 토큰 사용량이 예상 기준선에서 벗어나는 경우 경고를 트리거할 수 있습니다. 이러한 신호는 대시보드, 알림 시스템 또는 자동화된 수정 워크플로에 공급될 수 있습니다.

    중요하게도 이는 실시간 보호 기능(예: AI Guardrails)을 보완합니다. Guardrails는 요청 시 정책을 시행하는 반면, ETL 파이프라인은 피드백 루프를 생성하여 팀이 추세를 분석하고, 정책을 개선하고, 에이전트 성능을 지속적으로 개선하는 데 도움을 줍니다.

    프로덕션 추적에서 평가까지 루프 닫기

    추적을 사용할 수 있게 되면 전체 MLflow 평가 스택을 지원하여 팀이 전체 수명 주기에 걸쳐 GenAI 애플리케이션의 품질을 측정, 개선 및 유지 관리할 수 있습니다. 평가는 모니터링과 직접적으로 구축되며, 개발, 테스트 및 프로덕션 중에 캡처된 동일한 원격 측정을 LLM 심사관 및 사용자 지정 메트릭을 사용하여 채점할 수 있습니다.

    개발 중 평가

    MLflow를 사용하면 평가 데이터셋에 대해 평가를 실행하고, 내장 또는 사용자 지정 심사관을 적용하여 응답 품질을 채점할 수 있습니다. 한 가지 효과적인 접근 방식은 실제 추적에서 이 데이터셋을 부트스트랩하는 것입니다. 이러한 프롬프트는 실제 사용자 상호 작용에서 비롯되므로 순전히 합성 테스트 사례에 비해 에이전트가 처리해야 하는 시나리오를 더 잘 나타냅니다.

    아래에서는 최근 캡처된 추적에서 평가 데이터셋을 만듭니다. MLflow는 SQL 웨어하우스를 사용하여 데이터셋 레코드를 검색하고 구체화하므로 환경에서 웨어하우스 ID를 구성해야 합니다.

    데이터셋이 준비되었으므로 애플리케이션을 평가할 심사위원을 정의할 수 있습니다. MLflow는 내장된 심사위원 세트를 제공하며, 에이전트의 예상 동작에 맞춰진 맞춤형 가이드라인을 정의할 수도 있습니다.

    이제 MLflow 실험에서 결과를 확인할 수 있습니다.

    M Flow Experiment

    운영 모니터링

    개발 평가는 출시 전에 동작을 검증하는 데 도움이 되지만, 운영 모니터링은 실제 사용자와의 애플리케이션 성능을 보여줍니다. MLflow는 동일한 심사위원을 사용하여 실시간 추적을 자동으로 평가할 수 있으므로 회귀, 드리프트 및 새로운 실패 패턴을 신속하게 감지하는 데 도움이 됩니다. 이를 통해 평가는 일회성 작업에서 애플리케이션이 발전함에 따라 지속적인 관행으로 전환됩니다.

    Databricks에서 AI 관찰 가능성을 실행하는 고객

    Experian

    Eva 가상 비서 및 Latte 자동 이메일 시스템에 대한 MLflow 추적으로의 전환은 원활했습니다. Unity Catalog의 추적을 통해 데이터 과학 팀은 거버넌스된 Delta 테이블을 통해 수십만 건의 추적을 실행하고 Databricks를 떠나지 않고도 에이전트 품질을 확장하여 평가합니다. 더 많은 중요 평가 워크플로를 온보딩함에 따라, 추적 및 평가가 하나의 거버넌스된 플랫폼에 있다는 것은 에이전트 수명 주기의 각 단계에 대해 별도의 도구를 유지 관리할 필요가 없다는 것을 의미합니다.— James Lin, Head of AI/ML Innovation, Experian

    Superhuman (Grammarly)

    Superhuman의 모든 AI 에이전트에 대한 관찰 가능성 계층으로 MLflow 추적을 표준화하고 있습니다. 맞춤형 또는 포인트 솔루션을 구축하고 유지 관리하는 것보다 광범위한 플랫폼 통합을 선호합니다. 해당 유지 관리 부담은 저희 팀에게 실질적인 문제였습니다. Unity Catalog의 MLflow 추적을 통해 하루에 수십만 건의 추적으로 확장할 수 있으며, 연구원들은 엔지니어링 지원 없이 MLflow UI에서 직접 에이전트 동작을 셀프 서비스하고 탐색할 수 있습니다. 추적, 평가 및 모니터링이 모두 하나의 거버넌스된 플랫폼에 있다는 것은 에이전트를 자신 있게 운영 환경으로 전환하는 데 필요한 것입니다.— Martin Jewell, Lead MLE AI Infrastructure, Superhuman

    SmartSheet

    GenAI 플랫폼으로 Databricks를 선택했으며, MLflow는 저희 팀이 AI 에이전트를 구축하고 평가하는 방법입니다. Databricks와의 3일간의 공동 구축 기간 동안 MLflow 추적, 평가, 맞춤형 심사위원 및 레이블 지정을 사용하여 두 개의 운영 에이전트를 구축했습니다. 추적은 Unity Catalog에 저장되므로 수만 건의 평가를 실행하고 확장함에 따라 품질을 자신 있게 반복할 수 있습니다.— Kapil Ashar, VP of Engineering, Smartsheet

    The Standard

    The Standard는 고객이 재정적 웰빙과 마음의 평화를 달성하도록 돕습니다. 데이터와 AI는 해당 경험을 확장하여 제공하는 데 중요합니다. 중요한 비즈니스 기능에 AI 에이전트 기능(예: 수신 인수 문서 및 청구 제출에서 주요 정보 추출)을 내장함으로써 고객과 파트너에게 탁월한 서비스를 제공할 수 있습니다. 운영 추적 및 모니터링을 통해 저희 팀은 시스템이 어떻게 작동하는지 신속하게 이해하고 안정적인 업데이트를 만들 수 있습니다. Databricks Data Intelligence Platform의 나머지 데이터와 함께 Unity Catalog에서 추적을 거버넌스함으로써, 불필요한 복잡성을 추가하지 않고도 안전하게 쿼리, 모니터링 및 반복할 수 있습니다.— Porter Orr, AVP of AI and Automation, The Standard

    자주 묻는 질문 (FAQ)

    Q: Databricks 외부에서 실행되는 에이전트에 사용할 수 있나요?
    A: 예, 에이전트는 어디에서든 실행될 수 있습니다. 실제로 이 블로그에 사용된 지원 도우미 에이전트 예제는 로컬에 배포되었습니다.

    Q: 이 솔루션의 처리량 및 스토리지 제한은 어떻게 되나요?
    A: 수집 처리량 제한은 200 QPS부터 시작합니다. 스토리지에는 제한이 없습니다. 실험당 추적에 대한 이전 제한은 더 이상 적용되지 않습니다. 더 높은 처리량 제한이 필요한 경우 Databricks 계정 팀에 문의하십시오.

    Q: 검색 쿼리, MLflow 실험 경험 및 다운스트림 분석을 성능이 유지되도록 어떻게 할 수 있나요?
    A: 최신 제품 업데이트를 통해 테이블은 데이터를 최적으로 구성하기 위해 자동으로 액체 클러스터링됩니다. 그러나 더 큰 추적 볼륨의 경우 파생 뷰 위에 구체화된 뷰를 만들고 점진적으로 새로 고쳐 쿼리 성능을 유지해야 합니다.

    Q: 사용자 프롬프트에 포함된 PII는 어떻게 처리되나요?
    A: 이 기능은 PII에 대해 특별한 처리를 적용하지 않습니다. 그러나 데이터는 Unity Catalog에 저장되며, 여기서 세분화된 액세스 제어, 열 마스킹 및 행 필터링과 같은 거버넌스 기능을 활용하여 다운스트림 액세스를 관리하고 제한할 수 있습니다.

    시작하기

    설명서를 따라 시작하세요.

    (이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)

최신 게시물을 이메일로 받아보세요

블로그를 구독하고 최신 게시물을 이메일로 받아보세요.