유효한 SQL이라도 여전히 잘못된 비즈니스 답변을 생성할 수 있습니다.

AI SQL 어시스턴트는 실제 테이블, 합법적인 조인 (Join), 실행 가능한 필터 (Filter)를 선택할 수는 있지만, “활성 고객 (active customer)”, “매출 (revenue)”, “이탈 (churn)”, 또는 “진행 중인 파이프라인 (open pipeline)”이 무엇을 의미하는지는 오해할 수 있습니다.

따라서 운영 환경의 테스트는 다음 단계에서 멈춰서는 안 됩니다:

• SQL이 파싱 (Parse) 되었는가?
• 쿼리 (Query)가 실행되었는가?
• 읽기 전용 (Read-only) 상태를 유지했는가?

대신 버전 관리된 메트릭 계약 (Metric Contract)을 테스트해야 합니다.

모든 중요한 메트릭에 대해 다음을 정의하십시오:

• 엔티티 (Entity) 및 입도 (Grain)
• 대상 인구 (Eligible population) 및 제외 대상 (Exclusions)
• 테넌트 (Tenant) 및 환경 (Environment) 범위
• 분자 (Numerator), 분모 (Denominator), 및 상태 전이 (State transitions)
• 시간 필드 (Time field), 시간대 (Timezone), 및 데이터 지연 도착 정책 (Late-arrival policy)
• 통화 (Currency) 및 정밀도 (Precision)
• 승인된 소스 (Sources) 및 조인 (Joins)
• 신선도 예산 (Freshness budget)
• 질문이 모호할 때의 예상 동작

그 다음, 다음과 같은 까다로운 사례들을 포함하는 제어된 픽스처 (Fixture)를 구축하십시오:

• 내부 및 체험 계정 (Trial accounts)
• 취소 및 재활성화 (Reactivations)
• Null 값, 환불, 및 중복 데이터
• 일대다 조인 (One-to-many joins)
• 월말 및 일광 절약 시간제 (Daylight-saving) 경계
• 오래된 상류 데이터 (Stale upstream data)
• 누락된 전환율 (Conversion rates)

정확한 총합 그 이상을 단언(Assert)하십시오.

유용한 불변량 (Invariants)은 다음과 같습니다:

• 부분 집합은 대상 인구 (Eligible population)를 초과할 수 없다
• 전체 세그먼트의 합은 총계와 일치해야 한다
• 제외된 테넌트를 추가해도 메트릭이 변경되지 않아야 한다
• 행의 순서를 변경해도 답변이 바뀌지 않아야 한다
• 잘린 입력값 (Truncated input)이 자격 조건이 없는 완전한 결과를 생성할 수 없다

그리고 의도적으로 모호함을 테스트하십시오.

만약 “활성 고객”에 두 가지 승인된 의미가 있다면, 올바른 출력은 확신에 찬 쿼리가 아니라 명확화를 요청하는 것이어야 합니다.

핵심은 실패 유형을 분리하는 것입니다:

1. 잘못된 의도 (Wrong intent)
2. 추측된 계약 (Guessed contract)
3. 유효하지 않거나 안전하지 않은 SQL (Invalid or unsafe SQL)
4. 비즈니스 의미가 잘못된 유효한 SQL (Valid SQL with wrong business meaning)
5. 소스 증거 누락 (Missing source evidence)
6. 잘못된 최종 요약 (Incorrect final summary)

단 하나의 정확도 점수(Accuracy score)는 어떤 경계에서 실패했는지를 숨깁니다.

전체 가이드: Natural language SQL metric contracts: test business meaning before deployment