Looker에서 대화형 분석을 구성하기 위한 권장사항

대화형 분석은 Gemini를 사용하여 Google Cloud Looker 시맨틱 모델 (LookML), 데이터 값, 데이터 에이전트 구성을 정보 소스로 사용하여 자연어 질문을 해석합니다. 응답의 품질은 이러한 입력을 얼마나 효과적으로 준비하는지에 따라 달라집니다.

이 가이드에서는 LookML 개발자와 관리자가 대화형 분석을 구성하고 최적화하기 위한 전략과 권장사항을 제공합니다. LookML 모델, Explore, 데이터 에이전트에 대한 이러한 권장사항을 따르면 사용자 채택을 늘리고 사용자가 질문에 대한 정확하고 관련성 높고 유용한 답변을 얻을 수 있습니다. 이 가이드에서는 모델의 LookML에서 강력한 기반을 개발하고, 이 모델을 기반으로 Explore를 구성하고, 이러한 Explore를 데이터 소스로 사용하는 데이터 에이전트를 빌드하는 것으로 시작하는 논리적 흐름에 따라 대화형 분석과 관련된 권장사항을 다룹니다.

대화형 분석을 위한 LookML 권장사항

대화형 분석은 다음과 같은 기본 입력을 활용하여 자연어 질문을 해석합니다.

  • LookML 모델: 에이전트는 연결된 Explore의 스키마를 가져옵니다. 스키마에는 필드 (측정기준, 측정값), 필터 전용 필드 (필터, 매개변수), Looker Explore의 기본 LookML 모델에 정의된 해당 라벨, 설명, 동의어가 포함됩니다. 대화형 분석에서 분석하는 LookML 매개변수의 전체 목록은 대화형 분석 개요를 참고하세요.
  • 고유한 필드 값: 에이전트는 데이터 값을 샘플링하고 퍼지 검색을 실행하여 기본 데이터베이스에서 특정 필드 값을 확인할 수 있습니다. 이러한 방법을 사용하면 에이전트가 올바른 필드를 선택하고, 올바른 필터 값을 적용하고, 사용자가 질문할 수 있는 사용 가능한 카테고리와 항목을 식별할 수 있습니다.

대화형 분석의 효과는 이러한 입력의 품질과 명확성과 직접적인 관련이 있습니다. 다음 표에는 명확하지 않거나 모호한 LookML이 대화형 분석에 부정적인 영향을 미칠 수 있는 일반적인 방법과 지연 시간을 줄이고 출력 및 사용자 환경을 개선하기 위한 해결 방법이 나와 있습니다.

LookML 품질 문제 더 명확한 대화형 분석을 위한 해결 방법
명확성 부족 및 이름 지정 충돌: 명확한 라벨이 없거나, 정의가 모호하거나, 여러 뷰에서 유사한 이름을 공유하는 필드는 잘못된 필드 선택으로 이어질 수 있습니다. 명확한 라벨과 자세한 설명 적용:
  • label 매개변수를 사용하여 필드에 직관적이고 비즈니스 친화적인 이름을 지정합니다.
  • description 매개변수를 사용하여 중요한 컨텍스트, 자연어 정의, 업계별 용어를 제공합니다. 대화형 분석은 설명을 사용하여 필드 의미를 더 잘 식별하고 사용자 용어를 매핑합니다.
필드 부풀림: 내부 ID, 조인의 중복 필드 또는 중간 계산과 같이 너무 많은 필드를 노출하면 대화형 분석에 사용할 수 있는 옵션이 복잡해집니다. 관련 없는 필드 숨기기: 모든 기본 키, 외래 키, 기술 필드가 숨겨져 있는지 확인합니다.

(선택사항) Explore 확장: 필드가 많은 Explore의 경우 기존 Explore를 확장하여 대화형 분석 전용 버전을 만드는 것이 좋습니다.
샘플링 및 검색을 위한 데이터베이스 부하: 데이터베이스에서 샘플 값과 추천을 가져오는 데 시간이 오래 걸리거나 불필요한 부하가 발생할 수 있습니다. 특히 사용자가 쿼리에서 특정 데이터 값을 참조하는 경우에 그렇습니다. LookML에서 추천 정의: 값을 하드 코딩하거나 더 효율적인 측정기준을 가리켜 필드 추천을 위한 실시간 데이터베이스 쿼리를 방지합니다.
  • suggestions 매개변수를 사용하여 가능한 값 목록을 하드 코딩합니다.
  • suggest_explore 및 suggest_dimension 매개변수를 사용하여 필터 추천을 위한 더 효율적인 대체 측정기준을 쿼리합니다.
데이터 쿼리를 위한 데이터베이스 부하: 크거나 비효율적인 쿼리는 지연 시간과 데이터베이스 부하를 늘릴 수 있습니다. 데이터 쿼리 최적화: 집계 인식 및 효율적인 조인 로직 사용과 같이 쿼리 성능 최적화를 위한 일반적인 권장사항을 준수합니다.
불완전한 LookML 정의: 대시보드 수준의 커스텀 필드 또는 테이블 계산에 의존하면 대화형 분석에서 중요한 비즈니스 로직에 액세스할 수 없습니다. 커스텀 로직 통합: 중요하고 흔히 사용되는 커스텀 필드 또는 테이블 계산을 LookML 측정기준 및 측정값으로 변환합니다.
정리되지 않은 데이터: 다음과 같은 유형의 일관성 없거나 구조화되지 않은 데이터로 인해 대화형 분석에서 쿼리를 정확하게 해석하기가 어렵습니다.
  • 값 변형: 대소문자 또는 이름 지정 규칙이 일관되지 않으면 (예: complete, Complete, COMPLETE 값의 혼합) 대화형 분석에서 데이터가 중복되거나 데이터 관계가 잘못될 수 있습니다.
  • 일관성 없는 데이터 유형: 숫자여야 하지만 가끔 문자열 값을 포함하는 열은 필드 유형을 string으로 강제하여 숫자 연산을 방지합니다.
  • 시간대 모호성: 타임스탬프 필드에 표준화된 시간대가 없으면 필터링 또는 집계가 잘못될 수 있습니다.
 데이터 품질 문제 해결: 가능한 경우 데이터 큐레이션 중에 식별한 데이터 품질 문제 (일관성 없는 값, 유형, 시간대)에 플래그를 지정합니다. 데이터 엔지니어링팀과 협력하여 소스 데이터를 정리하거나 ETL/데이터 모델링 레이어에서 변환을 적용합니다.

주요 LookML 고려사항

대화형 분석의 데이터 소스로 사용될 Explore의 LookML을 정의할 때는 다음 고려사항에 유의하세요.

  • 명확하고 정확한 라벨 사용: 비즈니스 사용자가 실제로 말하는 방식을 반영하는 데이터 라벨을 선택합니다. "amt_usd_curr"와 같은 기술 약어를 사용하지 말고 "Amount (USD)"를 사용합니다.
  • 원활한 매핑 사용 설정: 동의어와 설명을 사용하여 에이전트가 사용자 질문을 올바른 필드에 매핑하도록 돕습니다.
  • 계산 중앙 집중화: 자주 사용되는 계산을 LookML 측정기준 또는 측정값으로 직접 정의하여 단일 정보 소스를 보장하고 지연 시간을 줄입니다.
  • 컨텍스트 간소화: LookML에서 기술 필드 또는 내부 전용 필드 (예: 외래 키 또는 원시 ID)를 숨겨 비즈니스 질문에 답하는 데 필요한 필드만 대화형 분석에 표시되도록 합니다. 관련 필드에만 집중하면 노이즈가 줄어들고 필드 선택의 정확성이 향상됩니다.
  • 샘플 데이터 및 퍼지 검색 쿼리 최적화: suggestions 매개변수에서 하드 코딩된 값을 정의하거나 더 효율적인 데이터베이스 쿼리를 위해 suggest_dimension 및 suggest_explore를 사용합니다.
  • 데이터 쿼리 최적화: 집계 인식 및 효율적인 조인 로직 사용과 같이 쿼리 성능 최적화를 위한 일반적인 Looker 권장사항을 준수합니다.

정리되고 효율적인 LookML 작성에 관한 권장사항은 다음 문서를 참고하세요.

대화형 분석에 사용할 Explore 설정에 대한 권장사항

대화형 분석에서 가장 유용한 답변을 제공할 수 있도록 대화형 분석의 데이터 소스로 사용할 Explore를 정의할 때는 다음 권장사항을 따르는 것이 좋습니다.

  • Explore의 기본 LookML에서 최종 사용자의 분석에 유용한 필드만 정의합니다.
    • 각 필드에 명확하고 간결한 이름과 설명을 지정합니다.
    • 관련된 경우 샘플 값을 포함합니다. 샘플 값은 문자열 유형 필드에 특히 유용합니다.
  • 콘텐츠를 재사용하는 데이터 에이전트별 Explore를 큐레이션하는 것이 좋습니다.
    • extends를 사용하여 기존 LookML을 기반으로 빌드하고 에이전트에 필요한 필드를 큐레이션합니다. 시스템 활동에서 사용자는 에이전트가 생성한 쿼리에 사용되는 필드를 확인하고 제외할 필드를 결정할 수 있습니다.
    • 필드 수준 LookML 상세검색을 사용하여 에이전트 전용 설명을 만듭니다. 예를 들어 "사용자가 판매를 언급할 때 주문 필드를 사용하세요"와 같은 설명입니다.

데이터 에이전트 빌드에 대한 권장사항

LookML 권장사항과 잘 구성된 Explore를 사용하여 강력한 기반을 구축한 후에는 특정 사용 사례 또는 사용자 그룹에 맞춤 대화형 환경을 제공하는 데이터 에이전트를 빌드할 수 있습니다. 데이터 에이전트는 최대 5개의 Explore에 연결하고 자연어 요청 사항을 사용하여 컨텍스트를 제공하고, 용어를 정의하고, 행동 가이드라인을 설정합니다.

에이전트를 빌드하고 요청 사항을 작성할 때 권장사항을 따르는 것은 특정 사용자 요구사항을 충족하고 전반적인 정확성을 개선하도록 에이전트의 응답을 맞춤설정하는 데 매우 중요합니다. 이러한 권장사항에는 특정 도메인용 전문 에이전트 설계와 명확하고 효과적인 요청 사항 작성이 포함됩니다.

전문 에이전트 빌드

모든 비즈니스 질문을 처리하는 전역 데이터 에이전트를 빌드하는 것이 좋지만 에이전트는 판매, 마케팅 또는 제품 분석과 같은 특정 도메인에 전문화되어 있을 때 가장 효과적으로 작동합니다. 하나 또는 몇 개의 밀접하게 관련된 Explore에 집중하는 에이전트에는 더 정확한 요청 사항을 제공할 수 있으므로 모호성이 줄어들고 응답 정확성이 향상됩니다.

에이전트를 설계할 때는 관련 없는 모든 데이터 모델을 처리하는 단일 에이전트를 빌드하지 마세요. 대신 밀접하게 관련된 Explore에만 연결하여 고유한 비즈니스 영역에 집중된 에이전트를 만듭니다. 예를 들어 모든 회사 데이터에 대한 에이전트 하나 대신 Orders 및 Transactions Explore에만 집중하는 '수익 에이전트'를 만듭니다.

효과적인 에이전트 요청 사항 작성

에이전트 요청 사항은 데이터 에이전트의 동작을 맞춤설정하고 조직의 고유한 비즈니스 로직과 용어를 주입하는 기본 도구입니다. 요청 사항은 에이전트가 사용자 질문을 해석하고, 모호성을 처리하고, 사용자에게 가장 도움이 되는 방식으로 응답하는 방법을 코칭하는 방법이라고 생각하세요. 잘 작성된 요청 사항은 정확하고 관련성 높고 신뢰할 수 있는 답변을 생성하는 데 중요합니다.

데이터 에이전트를 만들 때 요청 사항 필드에 에이전트 요청 사항을 입력합니다. 에이전트 만들기에 관한 자세한 내용은 Explore 데이터 에이전트 만들기 및 관리 문서 페이지를 참고하세요.

효과적인 요청 사항을 작성하려면 다음 권장사항을 따르세요.

  • 비즈니스 컨텍스트 및 기본 동작 정의: 조직의 고유한 로직과 용어에 대해 에이전트를 코칭합니다. 요청 사항을 사용하여 약어 (예: 'LY는 작년을 의미함')를 정의하거나, 일반적인 필터링 로직을 설명하거나, 모호성에 대한 기본 동작 (예: 'date_created가 제공되지 않으면 지난 6개월로 필터링')을 설정합니다.
  • LookML 및 필터 구문 사용: 요청 사항에서 필드를 참조하거나 필터를 적용할 때는 LookML 구문 (예: events.date_created) 및 필터 구문 (예: "last 6 months")을 사용합니다. 이렇게 하면 에이전트가 적용할 필드 또는 필터를 이해할 수 있습니다. 예: '사용자가 '리전'에 관해 질문할 때는 account_holder.geo_region 필드를 사용하세요.'
  • 복잡한 예에 표준 쿼리 사용: 복잡한 비즈니스 로직과 관련된 일반적인 질문 또는 쿼리의 경우 자연어 질문과 해당 검증된 Looker 쿼리의 쌍인 golden queries를 제공합니다. 표준 쿼리는 에이전트가 특정 패턴을 학습하는 데 도움이 될 수 있습니다. 까다로운 용어 또는 일반적인 필터 조합을 명확히 하는 쿼리에 집중합니다. 표준 쿼리는 원시 SQL 또는 표준 Explore URL이 아닌 특정 LookML 쿼리 표현으로 제공되어야 합니다.
  • 간결하게 작성: 명확하게 작성하고 요청 사항 내에서 불필요한 단어나 반복을 피합니다.
  • 중복 방지: 필드 설명 또는 동의어와 같이 LookML에 속하는 정보를 중복하지 마세요. LookML에서 컨텍스트를 정의해야 하는 경우와 에이전트 요청 사항에서 컨텍스트를 정의해야 하는 경우에 관한 자세한 내용은 LookML에 컨텍스트를 추가해야 하는 경우와 대화형 분석에 컨텍스트를 추가해야 하는 경우를 참고하세요. 또한 측정기준과 측정값의 차이 또는 기본 날짜 필터링을 실행하는 방법과 같이 에이전트가 이미 이해하고 있는 기본 개념을 설명하지 마세요.

에이전트 요청 사항의 제한사항

에이전트 요청 사항을 작성할 때는 대화형 분석의 다음 제한사항에 유의하세요.

  • 대화형 분석은 pivots 매개변수가 포함된 쿼리 생성을 지원하지 않습니다. 대화형 분석은 한 번에 여러 측정기준의 데이터를 반환할 수 있지만 Looker Explore UI에서 할 수 있는 것처럼 별도의 열로 피벗할 수는 없습니다. 대신 데이터를 '긴' 또는 '평면화된' 형식으로 반환하므로 데이터가 세로가 아닌 가로로 그룹화됩니다.

  • 대화형 분석은 기존 Looker 콘텐츠에 정의된 커스텀 필드를 재사용할 수 없습니다 (예: 커스텀 필드가 포함된 Explore에서 생성된 LookML을 사용하여 표준 쿼리를 만드는 경우). 또한 새 쿼리 내에서 완전히 새로운 커스텀 필드를 생성할 수 없습니다. 대신 기존 LookML 필드를 사용하거나 Python을 사용하여 데이터 결과에 커스텀 계산을 만듭니다.

  • 관리되는 LookML과 달리 요청 사항은 자유 형식 텍스트인 경우가 많으며 시간이 지남에 따라 기본 데이터 모델이 발전함에 따라 '비활성' 상태가 될 수 있습니다.

예시 에이전트 요청 사항

다음은 주문 항목 및 제품 이라는 Looker Explore에 연결된 데이터 에이전트의 샘플 요청 사항입니다.

# Define a persona and provide instructions on how to propose suggestions
You are a helpful data assistant. After answering the user's question, please provide 2-3 relevant follow-up questions they might be interested in exploring based on the data.
Anticipate the user's needs. Suggest potential next questions or related analyses after each response.
Always offer suggestions for deeper dives into the data.
Your tone should be professional and concise.

# Business Terms
# Define how business terms map to LookML fields or data values that can't be captured in LookML synonyms or descriptions.
Terms:
  EOP: End of Period. This is the last day of the period.
  LY: Last Year.
  Month-over-month: This is a measure of `type: period_over_period` with `period: month`.

# Default Behaviors
# Define how to handle ambiguous or underspecified queries.
When users mention Orders, you must apply a filter of `Status` like `COMPLETED`. Consider this a **hard-coded requirement**. Do not attempt to verify this filter by querying sample values; proceed directly to the calculation using this exact string.
Defaults:
  Date Filter: If no `created_date` is specified by the user, filter order_items.created_date to "last 12 months".
  Product Grouping: If "group by product" is requested without specifying name or category, use `products.category`.

# Golden Queries
# Provide examples of question/query pairs for common or complex questions.
Golden Queries:
  - Question: "How much revenue did we generate from successful orders in 2024?"
    Looker query:
      model: thelook_ecommerce
      explore: order_items
      fields: [order_items.total_sales]
      filters: [{field: order_items.status, value: "Complete"}, {field: order_items.created_year, value: "2024"}]

# Related Fields
# Provide instructions for what other related fields the agent should fetch information from
Include parent dimensions like Category when asking for "item level" data.

LookML에 컨텍스트를 추가해야 하는 경우와 대화형 분석에 컨텍스트를 추가해야 하는 경우

대화형 분석에서는 LookML 또는 에이전트 요청 사항 내부에 컨텍스트를 추가할 수 있습니다. 컨텍스트를 추가할 위치를 결정할 때는 다음 안내를 적용하세요.

  • Explore의 모든 사용자에게 적용되어야 하는 컨텍스트는 대시보드와 대화형 분석 모두에서 Looker Explore가 여러 위치에서 사용될 수 있으므로 LookML 모델에 직접 추가해야 합니다. 컨텍스트가 특정 사용자에게만 적용되어야 하는 경우 사용자 속성과 같은 LookML 기능을 사용하여 맞춤 환경을 만드는 것이 좋습니다.
  • 필드별 메타데이터 및 하드 요구사항에는 LookML을 우선시합니다. 동의어와 설명을 포함한 필드별 메타데이터를 에이전트 요청 사항이 아닌 LookML에 직접 배치합니다. 기본 필터 값 또는 숨겨진 필드와 같은 요구사항은 준수되도록 LookML에서 처리하는 것이 좋습니다.
  • Looker 쿼리를 만드는 방법, 측정기준 또는 측정값에 관한 설명, 액세스 가능한 Explore, 기본 날짜 필터링을 실행하는 방법과 같이 에이전트가 이미 알고 있는 정보를 중복하지 마세요. 마찬가지로 LookML과 에이전트 요청 사항 모두에서 동일한 용어를 정의하지 마세요.

에이전트 컨텍스트는 질적이고 사용자에게 집중해야 하며 하나의 Explore에서 여러 사용자에게 서비스를 제공하는 에이전트가 있을 수 있습니다. LookML은 필드가 무엇 인지 정의하는 데 유용하지만 일반적으로 비즈니스 전략 또는 예측 계산을 정의할 수는 없습니다. 에이전트 요청 사항에는 포함되어야 하지만 LookML에는 포함되지 않아야 하는 컨텍스트의 예는 다음과 같습니다.

  • 에이전트와 상호작용하는 사용자는 누구인가요? 이들의 역할은 무엇인가요? 회사 내부 사용자인가요, 아니면 외부 사용자인가요? 이전 분석 경험은 무엇인가요?
  • 사용자의 목표는 무엇인가요? 대화가 끝날 때 어떤 유형의 결정을 내리려고 하나요?
  • 이 사용자가 질문할 수 있는 질문 유형은 무엇인가요?
  • 이 사용자에게 가장 관련성이 높은 필드는 무엇인가요? 예를 들어 이 사용자가 액세스할 수 있는 필드는 무엇인가요? 특정 필터가 항상 적용되어야 하나요? 아니면 이 사용자를 위해 일부 필드의 우선순위를 지정해야 하나요?