software

확률적 AI 분석의 결정론적 문제

발행: (2025년 12월 7일 오후 02:32 GMT+9)
11 min read
원문: Dev.to

Source: Dev.to

TL;DR

AI 기반 분석 도구는 비즈니스 질문에 대해 결정론적 정확성을 요구하는데, 확률적 시스템(LLM, 의미 검색, RAG)에 의존합니다. 약간의 문구 변화만으로도 서로 다른 SQL 쿼리와 서로 다른 답변이 생성됩니다. 이는 사소한 버그가 아니라 아키텍처 불일치입니다. 해결책은 “더 나은 AI”가 아니라 핵심 개념에 대해 퍼지 의미 검색이 아닌 정확한 매칭을 사용해 비즈니스 질문을 데이터와 연결하는 방식을 재고하는 것입니다.

확률적 AI 분석의 문제점

CFO에게 “3분기( Q3 )에 몇 건의 청구를 거부했나요?” 라고 물어보세요.
그는 대시보드를 열고 “대략 1,247건 정도요.” 라고 답합니다.
감사에서 정확한 수치를 요구하면 “대략”이라는 답은 받아들여지지 않습니다—정확히 1,247이어야 합니다.

다음 날 같은 CFO에게 약간 다른 표현으로 “지난 분기에 거부된 청구 건수는 얼마인가요?” 라고 물으면 답이 1,189로 바뀐다면 시스템에 대한 신뢰는 떨어집니다.

이것이 오늘날 대부분의 AI 기반 분석 도구가 작동하는 방식입니다.

최신 AI 분석 스택

  1. 사용자가 자연어로 질문을 합니다.
  2. 의미 검색이 메타데이터에서 관련 테이블과 컬럼을 찾습니다.
  3. RAG(검색‑증강 생성)가 해당 데이터 요소에 대한 추가 컨텍스트를 가져옵니다.
  4. LLM이 검색된 정보를 바탕으로 SQL 쿼리를 생성합니다.
  5. 쿼리를 실행하고 결과를 반환합니다.

이 파이프라인의 모든 단계는 확률적입니다:

  • 의미 검색은 임베딩을 사용합니다; 표현이 달라지면 다른 벡터가 생성되어 다른 메타데이터 조각을 검색합니다.
  • RAG는 관련도 점수로 결과를 순위 매깁니다; 작은 쿼리 변화가 순위를 뒤바꾸어 LLM에 전달되는 컨텍스트가 바뀝니다.
  • LLM 생성은 본질적으로 비결정적입니다. temperature = 0이라도 같은 프롬프트가 SQL 구조, 조인, 필터 등에 변형을 일으킬 수 있습니다.

확률적 파이프라인은 마케팅 카피, 아이디어 브레인스토밍, 이메일 초안 작성 등 여러 정답이 허용되는 창의적 작업에 적합합니다. 그러나 비즈니스 분석은 정밀함을 요구합니다.

실제 예시

질문: “지난 분기에 프리미엄 고객의 평균 주문 가치는 얼마인가요?”

첫 번째 시도

의미 검색 결과:

항목관련도
fact_orders 테이블0.89
customer_tier 컬럼0.87
order_total 컬럼0.85

LLM이 생성한 쿼리:

SELECT AVG(order_total) 
FROM fact_orders 
WHERE customer_tier = 'premium' 
  AND order_date >= '2024-07-01';

결과: $247.83

두 번째 시도 (문구 변경)

사용자 질문: “Q3에 우리 최상위 등급 고객의 평균 주문 금액은 얼마인가요?”

의미 검색 결과:

항목관련도
fact_orders 테이블0.88
customer_segment 컬럼0.86
order_value 컬럼0.84

LLM이 생성한 쿼리:

SELECT AVG(order_value)
FROM fact_orders
WHERE customer_segment = 'gold'
  AND order_date >= '2024-07-01';

결과: $231.56

질문은 동일했지만 시스템이 다른 컬럼을 선택하고 다른 답을 도출했습니다. 근본 원인은 “잘못된” AI가 아니라 정답을 강제하는 메커니즘이 없기 때문입니다. 시스템은 어느 의미 매핑이 올바른지 추측하고, 사소한 문구 변화가 균형을 뒤흔듭니다.

인간 분석가가 동일한 문제에 접근하는 방식

다음과 같은 복합 요청을 고려해 보세요:

“프리미엄 고객 중 지난 분기에 고거래량 매장에서 피크 시간대에 최소 3번 구매한 고객의 평균 주문 가치와 고객 만족도 점수를 제품 및 지역별로 나누어 알려주세요.”

분석가는 이 요청을 구조화된 구성 요소로 분해합니다:

  • 측정항목: 평균 주문 가치, 고객 만족도 점수
  • 필터: 프리미엄 고객, 최소 3회 구매, 고거래량 매장, 피크 시간대, 지난 분기
  • 차원: 제품, 지역

그 후 정확한 조회를 수행합니다:

  1. “average order value”에 대한 메트릭 카탈로그를 검색 → 정확히 일치하거나 없음.
  2. “premium customers”에 대한 비즈니스 용어집을 확인 → 정확한 정의.
  3. “high‑volume stores”를 찾아봄 → 정확한 기준.

어떤 개념에 정의가 없으면 분석가는 멈추고 명확화를 요청합니다. 이 결정론적 워크플로우는 동일한 질문에 대해 항상 동일한 메타데이터와 결과적으로 동일한 SQL 쿼리를 생성하도록 보장합니다.

제안하는 결정론적 아키텍처

  1. 비즈니스 개념 추출 (확률적 단계)
    LLM을 사용해 자연어 질문을 구조화된 JSON 페이로드로 파싱합니다:

    {
  "metrics": ["average order value", "customer satisfaction rating"],
  "filters": [
    "premium customers",
    "at least 3 purchases",
    "high volume stores",
    "peak hours",
    "last quarter"
  ],
  "dimensions": ["product", "region"]
}

    이 추출은 비결정적일 수 있지만, 목표는 사용자가 의도한 개념을 식별하는 것입니다.

  2. 카탈로그와의 정확한 매칭 (결정론적 단계)

    • 메트릭 카탈로그 → “average order value” 매핑 → metrics.avg_order_value (발견).
    • 비즈니스 용어집 → 각 필터를 정확한 정의에 매핑 (예: customer_tier = 'premium').
    • 차원 매핑 → “product” → dim_product.product_name 등.

    누락된 개념이 있으면 중단하고 명확화를 요청합니다.

  3. 구체적인 메타데이터 조합
    각 구성 요소에 대한 전체 정의(테이블, 컬럼, 계산 로직, 필요한 조인)를 가져옵니다.

  4. 사전 정의된 빌딩 블록으로 SQL 생성 (결정론적)
    LLM은 알려진 조각들을 이어붙이는 역할만 수행합니다:

    SELECT 
  p.product_name,
  g.region_name,
  AVG(o.order_total) AS avg_order_value,
  AVG(o.satisfaction_score) AS avg_csat
FROM fact_orders o
JOIN dim_customer c ON o.customer_id = c.customer_id
JOIN dim_product p ON o.product_id = p.product_id
JOIN dim_geography g ON o.store_id = g.store_id
WHERE c.customer_tier = 'premium'
  AND o.order_date >= DATE_TRUNC('quarter', CURRENT_DATE - INTERVAL '3 months')
  AND o.store_id IN (
    SELECT store_id 
    FROM dim_stores 
    WHERE annual_revenue > 5000000
  )
  AND EXTRACT(HOUR FROM o.order_time) IN (10,11,12,13,17,18,19,20)
GROUP BY p.product_name, g.region_name;

    동일한 메타데이터가 매번 동일하게 조회되므로, 동일한 질문에 대해 생성되는 쿼리 역시 결정론적입니다.

결정론적 접근을 위한 전제 조건

  • 메트릭 카탈로그 – 모든 KPI, 메트릭, 측정값이 정확한 계산 로직과 데이터 라인지를 포함해 정의되어 있어야 합니다.
  • 비즈니스 용어집 – 모든 비즈니스 용어, 세그먼트, 필터 조건에 대한 정확한 정의와 해당 SQL 스니펫이 포함돼야 합니다.
  • 차원 매핑 – 비즈니스 개념과 데이터 모델 엔터티(테이블, 컬럼) 간의 명확한 관계가 정의돼야 합니다.

이 자산들은 “80 % 해결된” 기반(이전 기사 참고)을 구성합니다. 한 번 구축되면, 결정론적 파이프라인은 자연어 질문을 정확하고 반복 가능한 SQL로 신뢰성 있게 변환할 수 있습니다.

동의어와 모호성 처리

정확한 매칭은 경직될 수 있어 사용자가 동의어(예: “VIP 고객” vs. “프리미엄 고객”)를 사용할 수 있습니다. 이를 다루는 전략은 다음과 같습니다:

  • 동의어 테이블을 비즈니스 용어집에 두어 대체 용어를 정규화된 정의에 매핑합니다.
  • 사용자 프롬프트를 통해 직접 매칭이 안 되는 용어가 등장하면 명확화를 요청합니다.

동의어를 명시적으로 관리함으로써 시스템은 결정론성을 유지하면서도 사용자 친화적인 경험을 제공할 수 있습니다.

Back to Blog

관련 글

더 보기 »