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

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

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

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

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

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

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

LookML 품질 문제 더 명확한 대화형 분석을 위한 솔루션
명확성 부족 및 이름 충돌: 명확한 라벨이 없거나 정의가 모호하거나 여러 뷰에서 유사한 이름을 공유하는 필드는 잘못된 필드 선택으로 이어질 수 있습니다. 명확한 라벨과 자세한 설명 적용:
  • label 매개변수를 사용하여 필드에 직관적이고 비즈니스 친화적인 이름을 지정합니다.
  • 설명 파라미터를 사용하여 중요한 맥락, 자연어 정의, 업계별 용어를 제공합니다. 대화형 분석은 설명을 사용하여 필드 의미를 더 잘 식별하고 사용자 용어를 매핑합니다.
필드 과부하: 내부 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의 기본 LookML에서 최종 사용자의 분석에 유용한 필드만 정의합니다.
    • 각 필드에 명확하고 간결한 이름과 설명을 지정합니다.
    • 관련된 경우 샘플 값을 포함합니다. 샘플 값은 특히 문자열 유형 필드에 유용합니다.
  • 콘텐츠를 재사용하는 데이터 에이전트별 Explore를 선별하는 것이 좋습니다.
    • extends를 사용하여 기존 LookML을 기반으로 빌드하고 에이전트에 필요한 필드를 선별합니다. 시스템 활동에서 사용자는 에이전트가 생성한 쿼리에 사용된 필드를 확인하고 제외할 필드를 결정할 수 있습니다.
    • 필드 수준 LookML 개선사항을 사용하여 상담사를 위해 특별히 제작된 설명을 만드세요. 예를 들어 '사용자가 매출을 언급할 때는 주문 필드를 사용하세요'와 같은 설명이 있습니다.

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

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

에이전트를 빌드하고 요청 사항을 작성할 때 권장사항을 따르면 에이전트의 응답을 특정 사용자 요구사항에 맞게 조정하고 전반적인 정확도를 개선하는 데 도움이 됩니다. 이러한 권장사항에는 특정 도메인을 위한 전문 에이전트 설계 및 명확하고 효과적인 지침 작성이 포함됩니다.

전문 에이전트 빌드

모든 비즈니스 질문을 처리하는 하나의 글로벌 데이터 에이전트를 구축하고 싶을 수 있지만, 에이전트는 영업, 마케팅, 제품 분석과 같은 특정 도메인에 특화된 경우에 가장 효과적으로 작동합니다. 하나 또는 몇 개의 밀접하게 관련된 탐색에 집중하는 에이전트에게 더 정확한 요청 사항을 제공하여 모호성을 줄이고 대답의 정확도를 높일 수 있습니다.

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

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

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

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

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

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

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

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

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

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

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

상담사 요청 사항 예

Looker Explore에 연결된 데이터 에이전트의 샘플 안내는 다음과 같습니다(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에는 포함되지 않지만 에이전트 지침에 포함해야 하는 컨텍스트의 예는 다음과 같습니다.

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