가장 어려운 비즈니스 질문은 지표에 관한 것이 아닙니다. 그것은 관계에 관한 것입니다.

만약 당신의 BI (Business Intelligence) 도구가 무언가가 왜 발생했는지 설명할 수 없다면, 그것은 지능이 아니라 단순한 보고(reporting)일 뿐입니다.

멀티홉 (multi-hop)의 실제 의미

"3월 가격 변경 이후 왜 EMEA 지역의 이탈(churn)이 급증했나요?"

이것은 단 한 번의 조회(lookup)가 아닙니다. 이것은 트래버설 (traversal, 순회)입니다: 가격 변경 → 영향을 받은 계정 → 고객 지원 티켓 볼륨 → 응답 지연 시간 → 이탈 이벤트. 각 홉 (hop)은 서로 다른 키로 조인되며, 여러 단계는 시스템 경계를 넘나듭니다.

싱글홉 (Single-hop) 도구는 _무엇(what)_을 답변합니다. _왜(why)_를 답변하기 위해서는 멀티홉이 필요하며, 거의 모든 분석 스택은 내부적으로 싱글홉 방식으로 작동합니다.

LLM만으로는 부족한 이유

오류는 복리로 쌓입니다. 하나의 홉이 정확할 확률이 90%라면, 세 번의 홉을 거친 답변이 정확할 확률은 73%이며, 결과물은 어느 쪽이든 동일해 보입니다. 자신감 넘치는 문단에는 오차 범위가 표시되지 않습니다.

컴파일러 접근 방식 (The compiler approach)

질문을 생성(generated)해야 할 대상이 아니라 **컴파일(compiled)**해야 할 대상으로 취급하십시오:

1. 의도(intent)를 타입화된 표현(typed representation)으로 파싱(Parse)
2. 버전 관리되는 **시맨틱 그래프 (semantic graph)**를 기준으로 각 개념을 해결(Resolve)
3. 후보 경로를 열거한 다음, 하나를 증명(prove) — 카디널리티(cardinality)를 인지하거나, 실패 처리
4. 호출자를 위한 정책 서술어(policy predicates) 주입
5. 해당 방언(dialect)에 완벽한 SQL 생성

3단계가 멀티홉의 성패가 갈리는 지점입니다. 생성기(generator)는 그럴듯한 경로를 선택합니다. 컴파일러는 경로가 존재함을 증명하고 요청된 입도(grain)에 대해 유일함을 증명하며, 그렇지 않을 경우 거부합니다.

그 거부야말로 핵심 기능입니다. "이 질문은 모호합니다 — 인식된 매출(recognised revenue)을 의미하나요, 아니면 예약된 매출(booked revenue)을 의미하나요?"라는 정직한 답변은 자신감 있게 틀린 인과 관계 이야기를 늘어놓는 것보다 훨씬 가치 있습니다.

전체 분석 내용 — 트래버설 아키텍처, 카디널리티 처리, 그리고 실제 멀티홉 예시 — 은 여기서 확인할 수 있습니다:

👉 Multi-Hop Query Understanding: The Deterministic Compiler Approach

원문은 colrows.com/blogs/multi-hop-query-understanding-the-new-frontier-of-bi에 게시되었습니다.