프로덕션용 Genie Spaces 구축 및 신뢰 확보 방법

셀프서비스 분석의 신뢰성 문제

Genie는 비즈니스 팀이 자연어를 사용하여 데이터와 상호 작용할 수 있도록 하는 Databricks 기능입니다. 조직의 용어와 데이터에 맞춤화된 생성형 AI를 사용하며, 사용자 피드백을 통해 성능을 모니터링하고 개선할 수 있습니다.

모든 자연어 분석 도구의 공통적인 과제는 최종 사용자와의 신뢰를 구축하는 것입니다. 마케팅 도메인 전문가인 Sarah가 기존의 대시보드 대신 Genie를 처음 사용해 본다고 가정해 보겠습니다.

Sarah: "지난 분기 저희 클릭률이 어떻게 됐나요?"

Genie: 8.5%

Sarah의 생각: 잠깐, 지난 분기에 6%를 달성했을 때 축하했던 기억이 나는데...

이것은 Sarah가 답을 알고 있지만 올바른 결과를 보지 못하고 있는 질문입니다. 아마도 생성된 쿼리에 다른 캠페인이 포함되었거나, 회사의 회계 달력을 사용해야 하는데 '지난 분기'에 대한 표준 달력 정의를 사용했을 수 있습니다. 하지만 Sarah는 무엇이 잘못되었는지 모릅니다. 불확실성의 순간이 의심을 불러일으켰습니다. 답변에 대한 적절한 평가가 없으면 사용성에 대한 이러한 의심은 커질 수 있습니다. 사용자는 애널리스트 지원을 다시 요청하게 되는데, 이는 다른 프로젝트에 지장을 주고 단일 인사이트를 생성하는 데 드는 비용과 가치 창출 시간을 증가시킵니다. 셀프 서비스 투자는 충분히 활용되지 못하고 있습니다.

문제는 Genie 스페이스가 SQL을 생성할 수 있는지 여부만이 아닙니다. 사용자가 그 결과를 바탕으로 의사 결정을 내릴 만큼 신뢰하는지 여부입니다.

이러한 신뢰를 구축하려면 주관적인 평가('작동하는 것 같습니다')를 넘어 측정 가능한 검증('체계적으로 테스트했습니다')으로 나아가야 합니다. Genie의 기본 내장 벤치마크 기능이 기준 구현을 사용자가 중요한 결정을 내릴 때 의존하는 프로덕션용 시스템으로 전환하는 방법을 시연하겠습니다. 벤치마크는 Genie 스페이스의 품질을 평가하고 Genie 스페이스를 큐레이션할 때 격차를 해소하는 데 도움이 되는 데이터 기반 방식을 제공합니다.

이 블로그에서는 신뢰할 수 있는 시스템을 개발하기 위해 벤치마크를 사용하여 Genie 스페이스를 구축하는 전체 과정을 예시와 함께 살펴보겠습니다.

데이터: 마케팅 캠페인 분석

마케팅팀은 상호 연결된 4개의 데이터 세트에서 캠페인 성과를 분석해야 합니다.

• 잠재 고객 - 업계 및 위치를 포함한 회사 정보
• 연락처 - 부서 및 기기 유형을 포함한 수신자 정보
• 캠페인 - 예산, 템플릿, 날짜를 포함한 캠페인 세부 정보
• 이벤트 - 이메일 이벤트 추적 (발송, 열람, 클릭, 스팸 신고)

워크플로: 타겟 회사(잠재 고객) 식별 → 해당 회사의 연락처 찾기 → 마케팅 캠페인 전송 → 수신자가 해당 캠페인에 어떻게 반응하는지 추적(이벤트).

사용자가 답변해야 했던 몇 가지 예시 질문은 다음과 같습니다.

• "어떤 캠페인이 산업별로 최고의 ROI를 달성했나요?"
• "캠페인 유형별 규정 준수 위험은 무엇인가요?"
• "기기 및 부서별로 참여 패턴(CTR)은 어떻게 다른가요?"
• "특정 잠재고객 세그먼트에서 가장 실적이 좋은 템플릿은 무엇인가요?"

이러한 질문은 테이블 조인, 도메인별 측정항목 계산, 그리고 캠페인을 "성공적" 또는 "고위험"으로 만드는 요인에 대한 도메인 지식 적용을 필요로 합니다. 이러한 답변을 올바르게 얻는 것은 예산 할당, 캠페인 전략, 규정 준수 결정에 직접적인 영향을 미치기 때문에 중요합니다. 바로 시작해 보죠!

여정: 기준선에서 프로덕션까지 개발

일화적으로 테이블과 몇 가지 텍스트 프롬프트를 추가하는 것만으로 최종 사용자에게 충분히 정확한 Genie 공간을 만들 수 있다고 기대해서는 안 됩니다. 최종 사용자 요구사항에 대한 철저한 이해와 데이터 세트 및 Databricks 플랫폼 기능에 대한 지식이 결합되면 원하는 결과를 얻을 수 있습니다.

이 엔드투엔드 예시에서는 벤치마크를 통해 Genie 스페이스의 정확도를 평가하고, 부정확한 답변을 유발하는 컨텍스트 격차를 진단하며, 수정 사항을 구현합니다. Genie 개발 및 평가에 접근하는 방법으로 이 프레임워크를 고려해 보세요.

• 벤치마크 스위트 정의 (10~20개의 대표적인 질문을 목표로 하세요). 이러한 질문은 주제 전문가와 Genie를 분석에 활용할 것으로 예상되는 실제 최종 사용자가 결정해야 합니다. 이상적으로는 Genie 스페이스를 실제로 개발하기 전에 이러한 질문을 만드는 것이 좋습니다.
• 베이스라인 정확도를 설정하세요. Genie 스페이스에 기준 데이터 객체만 추가하여 스페이스에서 모든 벤치마크 질문을 실행하세요. 정확도, 통과한 질문, 실패한 질문 및 그 이유를 문서화하세요.
• 체계적으로 최적화하세요. 한 세트의 변경 사항(예: 열 설명 추가)을 구현합니다. 모든 벤치마크 질문을 다시 실행하세요. 영향과 개선 사항을 측정하고 게시된 모범 사례에 따라 반복적인 개발을 계속하세요.
• 측정하고 전달하세요. 벤치마크를 실행하면 Genie 스페이스가 기대치를 충분히 충족한다는 객관적인 평가 기준이 제공되므로 사용자와 이해관계자의 신뢰를 구축할 수 있습니다.

최종 사용자가 마케팅 데이터에서 찾고자 하는 답변을 나타내는 13개의 벤치마크 질문 모음을 만들었습니다. 각 벤치마크 질문은 평이한 영어로 된 현실적인 질문과, 그 질문에 답하는 검증된 SQL 쿼리로 구성됩니다.

Genie는 설계에 따라 이러한 벤치마크 SQL 쿼리를 기존 컨텍스트에 포함하지 않습니다. 이들은 순전히 평가용으로만 사용됩니다. 이러한 질문에 정확하게 답변할 수 있도록 올바른 컨텍스트를 제공하는 것이 우리의 작업입니다. 바로 시작해 보죠!

반복 0: 기준 설정

cmp 및 proc_delta와 같이 부적절한 테이블 이름과 uid_seq (campaign_id용), label_txt (campaign_name용), num_val (cost용), proc_ts (event_date용)와 같은 열 이름으로 의도적으로 시작했습니다. 이러한 시작점은 많은 조직이 실제로 직면하는 상황, 즉 비즈니스 의미보다는 기술적 관례에 따라 모델링된 데이터를 반영합니다.

또한 테이블만으로는 도메인별 KPI 및 메트릭을 계산하는 방법에 대한 컨텍스트를 제공하지 않습니다. Genie는 수백 개의 기본 내장 SQL 함수를 활용하는 방법을 알고 있지만, 입력으로 사용할 올바른 열과 로직이 여전히 필요합니다. 그렇다면 Genie에게 컨텍스트가 충분하지 않으면 어떻게 될까요?

벤치마크 분석: Genie는 13개의 벤치마크 질문 중 어느 것에도 올바르게 답변하지 못했습니다. AI의 성능이 충분하지 않아서가 아니라, 아래에서 볼 수 있듯이 관련 컨텍스트가 부족했기 때문입니다.

인사이트: 최종 사용자가 묻는 모든 질문은 귀하가 제공하는 데이터 객체를 기반으로 Genie가 생성하는 SQL 쿼리에 의존합니다. 따라서 잘못된 데이터 명명 규칙은 생성된 모든 쿼리에 영향을 미칩니다. 기본적인 데이터 품질을 건너뛰고 최종 사용자와의 신뢰를 구축할 수는 없습니다! Genie는 모든 질문에 대해 SQL 쿼리를 생성하지는 않습니다. 충분한 컨텍스트가 있을 때만 쿼리를 생성합니다. 이는 환각 현상과 오해의 소지가 있는 답변을 방지하기 위한 예상된 동작입니다.

다음 작업: 초기 벤치마크 점수가 낮은 것은 먼저 Unity Catalog 개체를 정리하는 데 집중해야 한다는 것을 의미하므로 거기서부터 시작하겠습니다.

반복 1: 모호한 열 의미

테이블 이름을 campaigns, events, contacts, prospects로 개선하고 Unity Catalog에 명확한 테이블 설명을 추가했습니다.

하지만 저희는 존재하지 않는 관계를 암시하는 오해의 소지가 있는 열 이름이나 주석이라는 또 다른 관련 문제에 직면했습니다.

예를 들어 workflow_id, resource_id, owner_id 와 같은 열은 여러 테이블에 걸쳐 존재합니다. 이 열들은 테이블을 서로 연결하는 것처럼 보이지만 실제로는 그렇지 않습니다. events 테이블은 캠페인에 대한 외래 키로 workflow_id 를 사용하고(별도의 워크플로 테이블이 아님) 연락처에 대한 외래 키로 resource_id 를 사용합니다(별도의 리소스 테이블이 아님). 한편, campaigns 테이블에는 완전히 관련 없는 자체 workflow_id 열이 있습니다. 이러한 열 이름과 설명이 적절하게 표기되지 않으면 해당 속성이 부정확하게 사용될 수 있습니다. 모호한 각 열의 목적을 명확히 설명하기 위해 Unity Catalog의 열 설명을 업데이트했습니다. 참고: UC에서 메타데이터를 편집할 수 없는 경우 Genie 스페이스 지식 저장소에 테이블 및 열 설명을 추가할 수 있습니다.

벤치마크 분석: 명확한 이름과 설명 덕분에 간단한 단일 테이블 쿼리가 작동하기 시작했습니다. "2023년 유형별 이벤트 수 계산" 및 "지난 3개월 동안 시작된 캠페인은 무엇인가요?"와 같은 질문 이제 정확한 답변을 받았습니다. 그러나 테이블 간 조인이 필요한 모든 쿼리는 실패했습니다. Genie는 여전히 어떤 열이 관계를 나타내는지 올바르게 파악할 수 없었습니다.

인사이트: 명확한 이름 지정 규칙이 도움이 되지만, 명시적인 관계 정의가 없으면 Genie는 어떤 열이 테이블을 서로 연결하는지 추측해야 합니다. 여러 열의 이름이 workflow_id 또는 resource_id와 같으면 이러한 추측으로 인해 부정확한 결과가 나올 수 있습니다. 적절한 메타데이터는 기초가 되지만 관계는 명시적으로 정의해야 합니다.

다음 작업: 데이터 객체 간의 조인 관계를 정의하세요. id 또는 resource_id 와 같은 열 이름은 항상 나타납니다. 해당 열 중 정확히 어떤 열이 다른 테이블 객체를 참조하는지 명확히 해보겠습니다.

반복 2: 모호한 데이터 모델

테이블을 조인할 때 Genie가 사용해야 하는 열을 명확히 하는 가장 좋은 방법은 기본 키와 외래 키를 사용하는 것입니다. Unity Catalog에 기본 키 및 외래 키 제약 조건을 추가하여 테이블 연결 방법을 Genie에게 명시적으로 알려주었습니다(예: campaigns.campaign_id). events.campaign_id와 관련되며, contacts.contact_id에 연결됩니다. 이는 prospects.prospect_id에 연결됩니다. 이를 통해 추측을 배제하고 다중 테이블 조인이 기본적으로 생성되는 방식을 지정합니다. 참고: UC에서 관계를 편집할 수 없거나 테이블 관계가 복잡한 경우(예: 여러 JOIN 조건) Genie 스페이스 지식 저장소에서 이를 정의할 수 있습니다.

또는 객체 정의에 조인 세부 정보를 명시적으로 포함할 수 있는 메트릭 뷰를 생성하는 것을 고려할 수 있습니다. 이에 대해서는 나중에 더 자세히 설명하겠습니다.

벤치마크 분석: 꾸준한 진전. 여러 테이블에 걸쳐 조인이 필요한 질문이 작동하기 시작하여, 이제 "2024년 1분기 산업별 캠페인 비용을 보여주세요" 및 "1월에 1,000개 이상의 이벤트가 있었던 캠페인은 무엇인가요?"와 같은 질문이 성공적으로 처리됩니다.

인사이트: 관계를 통해 실제 비즈니스 가치를 제공하는 복잡한 다중 테이블 쿼리를 구현할 수 있습니다. Genie는 올바르게 구조화된 SQL을 생성하고 비용 합산 및 이벤트 수 계산과 같은 간단한 작업을 정확하게 수행하고 있습니다.

조치: 남아있는 부정확한 벤치마크 중 다수는 사용자가 데이터 필터로 활용하려는 값에 대한 참조를 포함합니다. 최종 사용자가 질문하는 방식이 데이터 세트에 나타나는 값과 직접적으로 일치하지 않습니다.

반복 3: 데이터 값 이해

Genie space는 특정 도메인 관련 질문에 답변하도록 큐레이션되어야 합니다. 하지만 사람들은 항상 데이터에 있는 용어와 정확히 똑같은 용어를 사용해 말하지는 않습니다. 사용자는 "바이오엔지니어링 회사"라고 말할 수 있지만 실제 데이터 값은 "생명공학"입니다.

값 사전과 데이터 샘플링을 활성화하면 최종 사용자가 프롬프트한 정확한 값만 Genie가 사용하는 대신, 데이터에 있는 그대로의 값을 더 빠르고 정확하게 조회할 수 있습니다.

예시 값과 값 사전은 이제 기본적으로 활성화되어 있지만, 필터링에 일반적으로 사용되는 올바른 열이 활성화되어 있고 필요할 때 사용자 지정 값 사전을 사용하는지 다시 한번 확인하는 것이 좋습니다.

벤치마크 분석: 벤치마크 질문의 50% 이상에서 성공적인 답변을 얻고 있습니다. “biotechnology”와 같은 특정 카테고리 값을 포함하는 질문이 해당 필터를 올바르게 식별하기 시작했습니다. 이제 과제는 맞춤 측정항목과 집계를 구현하는 것입니다. 예를 들어, Genie는 데이터 값으로 "click"을 찾은 것과 비율 기반 메트릭에 대한 이해를 바탕으로 CTR을 계산하는 방법에 대해 최선의 추측 을 제공하고 있습니다. 하지만 쿼리를 바로 생성할 만큼 확신하지는 못합니다.

이는 항상 100% 정확하게 계산되어야 하는 메트릭이므로 Genie를 위해 해당 세부 정보를 명확히 해야 합니다.

인사이트: 값 샘플링은 실제 데이터 값에 대한 액세스를 제공하여 Genie의 SQL 생성을 개선합니다. 사용자가 오타나 다른 용어를 사용하여 대화형 질문을 할 때, 값 샘플링은 Genie가 프롬프트를 테이블의 실제 데이터 값과 일치시키는 데 도움이 됩니다.

다음 조치: 현재 가장 흔한 문제는 Genie가 아직 사용자 지정 측정항목에 대한 정확한 SQL을 생성하지 못한다는 점입니다. 더 정확한 결과를 얻기 위해 측정항목 정의를 명시적으로 다뤄 봅시다.

4차 반복: 맞춤 측정항목 정의

이 시점에서 Genie는 데이터에 있는 범주형 데이터 속성에 대한 컨텍스트를 가지고 데이터 값을 필터링하며 표준 SQL 함수(예: “유형별 이벤트 수”는 COUNT()를 사용)를 통해 간단한 집계를 수행할 수 있습니다. Genie가 측정항목을 계산하는 방법을 더 명확히 하기 위해 genie space에 예시 SQL 쿼리를 추가했습니다. 이 예시는 CTR에 대한 올바른 측정항목 정의를 보여줍니다:

참고: SQL 쿼리에 주석을 남기는 것이 좋습니다. 주석은 코드와 함께 관련 컨텍스트가 됩니다.

벤치마크 분석: 이를 통해 현재까지 단일 개선으로는 가장 큰 정확도 향상을 이루었습니다. Genie의 목표는 정의된 잠재고객을 대상으로 매우 상세한 수준의 질문에 답변할 수 있는 역량을 갖추는 것입니다. 대부분의 최종 사용자 질문은 CTR, 스팸 비율, 참여 측정항목 등과 같은 맞춤 측정항목을 활용할 것으로 예상됩니다. 더 중요한 것은 이러한 질문의 변형도 효과가 있었다는 것입니다. Genie는 지표의 정의를 학습했으며 앞으로 모든 쿼리에 이를 적용할 것입니다.

인사이트: 예시 쿼리는 메타데이터만으로는 전달할 수 없는 비즈니스 로직을 알려줍니다. 잘 만들어진 예시 쿼리 하나는 종종 전체 카테고리의 벤치마크 격차를 동시에 해결합니다. 이것은 지금까지 다른 어떤 단일 반복 단계보다 더 큰 가치를 제공했습니다.

다음 조치: 이제 몇 개의 벤치마크 질문만 부정확한 상태로 남아 있습니다. 자세히 살펴보니 남아있는 벤치마크가 두 가지 이유로 실패하는 것을 확인했습니다.

• 사용자는 데이터에 직접 존재하지 않는 데이터 속성에 대해 질문하고 있습니다. 예를 들어, '지난 분기에 높은 CTR을 생성한 캠페인은 몇 개인가요?' 해당 데이터 속성이 존재하지 않기 때문에 Genie는 사용자가 의미하는 '높은' CTR이 무엇인지 알지 못합니다.
• 이 데이터 테이블에는 제외해야 할 레코드가 포함되어 있습니다. 예를 들어, 고객에게 전달되지 않는 테스트 캠페인이 많이 있습니다. KPI에서 해당 항목들을 제외해야 합니다.

반복 5: 도메인별 규칙 문서화

이렇게 남아 있는 격차는 모든 쿼리의 생성 방식에 전역적으로 적용되는 컨텍스트이며, 데이터에 직접적으로 존재하지 않는 값과 관련이 있습니다.

높은 CTR에 대한 첫 번째 예시나, 높은 비용의 캠페인과 같이 유사한 것을 예로 들어보겠습니다. 몇 가지 이유 때문에 테이블에 도메인별 데이터를 추가하는 것이 항상 쉽거나 권장되는 것은 아닙니다.

• 테이블 스키마와 데이터 파이프라인을 모두 변경해야 하므로, 데이터 테이블에 campaign_cost_segmentation 필드(높음, 중간, 낮음)를 추가하는 등의 변경은 시간이 걸리고 다른 프로세스에도 영향을 미칩니다.
• CTR과 같은 집계 계산의 경우, 새로운 데이터가 유입되면 CTR 값이 변경됩니다. 어쨌든 이 계산을 미리 수행해서는 안 됩니다. 우리는 기간 및 캠페인과 같은 필터를 명확히 할 때 이 계산이 실시간으로 수행되기를 원합니다.

따라서 Genie에서 텍스트 기반 지침을 사용하여 이 도메인별 세분화를 수행하도록 할 수 있습니다.

마찬가지로 비즈니스 기대치에 부합하도록 Genie가 항상 쿼리를 작성하는 방법을 지정할 수 있습니다. 여기에는 사용자 지정 달력, 필수 전역 필터 등이 포함될 수 있습니다. 예를 들어, 이 캠페인 데이터에는 KPI 계산에서 제외해야 하는 테스트 캠페인이 포함되어 있습니다.

벤치마크 분석: 100% 벤치마크 정확도! 에지 케이스와 임계값 기반 질문이 일관되게 작동하기 시작했습니다. '고성과 캠페인' 또는 '규정 준수 위험 캠페인' 관련 질문에 이제 비즈니스 정의가 올바르게 적용되었습니다.

인사이트: 텍스트 기반 지침은 이전 단계에서 남은 격차를 메우고 최종 사용자에게 올바른 쿼리가 생성되도록 보장하는 간단하고 효과적인 방법입니다. 하지만 컨텍스트 주입을 위해 의존하는 첫 번째 또는 유일한 방법이 되어서는 안 됩니다.

참고로, 경우에 따라 100% 정확도를 달성하는 것이 불가능할 수도 있습니다. 예를 들어, 벤치마크 질문에 대한 정답을 생성하기 위해 매우 복잡한 쿼리나 여러 개의 프롬프트가 필요한 경우가 있습니다. 단일 예시 SQL 쿼리를 쉽게 만들 수 없다면, 벤치마크 평가 결과를 다른 사람들과 공유할 때 이 격차를 간단히 기록해두세요. 일반적으로 사용자 인수 테스트(UAT)로 넘어가기 전에 Genie 벤치마크가 80%를 넘어야 한다고 기대합니다.

다음 작업: 이제 Genie가 벤치마크 질문에 대해 기대했던 수준의 정확도를 달성했으므로 UAT로 이동하여 최종 사용자로부터 더 많은 피드백을 수집할 것입니다!

(선택 사항) 반복 6: 복잡한 측정 항목 사전 계산

최종 반복에서는 주요 마케팅 메트릭을 사전 정의하고 비즈니스 분류를 적용하는 사용자 지정 뷰를 만들었습니다. 데이터 세트가 모두 단일 데이터 모델에 적합하고 수십 개의 사용자 지정 메트릭이 있는 경우 뷰 또는 메트릭 뷰 를 만드는 것이 더 간단할 수 있습니다. 각각에 대해 Genie 공간에 특화된 예시 SQL 쿼리를 작성하는 것보다, 이 모든 것을 데이터 객체 정의 하나에 포함하는 것이 더 쉽습니다.

벤치마크 결과: 메타데이터 콘텐츠가 동일하게 유지되었기 때문에 기본 테이블 대신 뷰를 활용해서도 100% 벤치마킹 정확도를 달성했습니다.

인사이트: 예시나 지침을 통해 복잡한 계산을 설명하는 대신 뷰 또는 메트릭 뷰로 캡슐화하여 단일 정보 소스를 정의할 수 있습니다.

학습한 내용: 벤치마크 기반 개발의 영향

모든 것을 해결하는 지니 스페이스를 구성하는 데 '만능 해결책'은 없습니다. 프로덕션 수준의 정확도는 일반적으로 고품질 데이터, 적절하게 보강된 메타데이터, 정의된 메트릭 로직, 그리고 도메인별 컨텍스트가 스페이스에 주입되었을 때만 달성됩니다. 엔드투엔드 예시에서는 이러한 모든 영역에 걸쳐 있는 일반적인 문제에 직면했습니다.

벤치마크는 스페이스가 기대치를 충족하고 사용자 피드백을 받을 준비가 되었는지 평가하는 데 매우 중요합니다. 또한 Genie의 질문 해석 격차를 해소하기 위한 개발 노력을 이끌었습니다. 요약:

• 반복 1~3 - 54% 벤치마크 정확도. 이러한 반복은 Genie가 데이터와 메타데이터를 더 명확하게 인식하도록 만드는 데 중점을 두었습니다. 적절한 테이블 이름, 테이블 설명, 열 설명, 조인 키를 구현하고 예시 값을 활성화하는 것은 모든 Genie 스페이스에 있어 기본적인 단계입니다. 이러한 기능을 통해 Genie는 생성하는 모든 쿼리에 영향을 미치는 올바른 테이블, 열 및 조인 조건을 정확하게 식별해야 합니다. 또한 간단한 집계 및 필터링도 수행할 수 있습니다. Genie는 이러한 기본적인 지식만으로도 도메인별 벤치마크 질문의 절반 이상에 올바르게 답변할 수 있었습니다.
• 반복 4 - 77% 벤치마크 정확도. 이번 반복에서는 사용자 지정 메트릭 정의를 명확히 하는 데 중점을 두었습니다. 예를 들어, CTR은 모든 벤치마크 질문에 포함되는 것은 아니지만, 비표준(즉, sum(), avg() 등) 매번 정확하게 답변해야 하는 메트릭입니다.
• 반복 5 - 100% 벤치마크 정확도. 이번 반복에서는 텍스트 기반 지침을 사용하여 남아 있는 부정확성을 보완하는 방법을 보여주었습니다. 이 지침에는 분석용 데이터에 전역 필터를 포함하는 것, 도메인별 정의(예: 무엇이 참여도가 높은캠페인인지), 그리고 지정된 회계 달력 정보와 같은 일반적인 시나리오가 포함되어 있습니다.

Genie 스페이스를 평가하는 체계적인 접근 방식을 따름으로써 Sarah로부터 사후에 문제를 듣는 대신 사전에 의도하지 않은 쿼리 동작을 포착했습니다. 우리는 주관적인 평가("작동하는 것 같다")를 객관적인 측정("최종 사용자가 초기에 정의한 주요 사용 사례를 다루는 13개의 대표적인 시나리오에 대해 작동함을 검증했습니다")으로 전환했습니다.

향후 계획

셀프 서비스 분석에서 신뢰를 구축하는 것은 첫날부터 완벽을 기하는 것이 아닙니다. 이는 측정 가능한 검증을 통한 체계적인 개선에 관한 것입니다. 사용자가 문제를 발견하기 전에 먼저 찾아내는 것입니다.

벤치마크 기능은 이를 달성할 수 있게 해주는 측정 레이어를 제공합니다. 이는 Databricks 설명서에서 권장하는 반복적인 접근 방식을 정량화할 수 있고 신뢰를 구축하는 프로세스로 전환합니다. 이 벤치마크 기반의 체계적인 개발 프로세스를 요약해 보겠습니다.

• 사용자의 실제적인 질문을 대표하는 벤치마크 질문 을 10~15개 만드세요.
• 스페이스를 테스트하여 기준 정확도를 설정하세요
• Databricks가 모범 사례에서 권장하는 반복적인 접근 방식에 따라 구성을 개선하세요
• 변경이 있을 때마다 모든 벤치마크를 다시 테스트하여 영향을 측정하고, 부정확한 질문으로 인한 컨텍스트 격차를 파악하세요. 정확도 진행 상황을 문서화하여 이해관계자의 신뢰를 구축하세요.

강력한 Unity Catalog 기반으로 시작하세요. 비즈니스 컨텍스트를 추가하세요. 벤치마크를 통해 종합적으로 테스트하세요. 모든 변경 사항을 측정하세요. 검증된 정확성을 통해 신뢰를 구축하세요.

귀하와 귀하의 최종 사용자는 혜택을 누릴 수 있습니다!

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