UAI 2026에서, 내 파이프라인이 너무 단호했다는 걸 깨닫다

English version: At UAI 2026: My Pipeline Was Far Too Sure of Itself

UAI(Conference on Uncertainty in Artificial Intelligence) 2026을 참관하고 있습니다. 학회에 올 때마다 느끼는 거지만, 공대 출신이고 이걸로 밥 먹고 살면서도 수학에의 베이스가 여전히 부족하다는 걸 오늘도 절감하고 있습니다. (^^;;;) 확률과 관련된 수식들과 낯선 단어들이 어우러지는 가운데 많은 것들을 배우고 있습니다. 사실 배운다기보다는, 모르는 게 아직도 많다는 걸 깨닫고 있다는 게 더 정확하겠네요.

그런데 오늘 세션들을 따라가다 보니, 못 알아들은 수식보다 더 마음에 걸리는 게 하나 있었습니다. 내가 지금까지 만들어 온 것들이 지나치게 단호했다는 것입니다.

내가 만든 판단들은 전부 단호했다

기존에 LLM이나 에이전트를 통해서 하던 작업들은 굉장히 heuristic하고 deterministic 했습니다. 문서의 종류가 무엇인지, 이 문서에서 어떤 특징을 뽑아야 하는지에 대한 판단을 대부분 경험에 의거해서 진행했고, 그 결정이 수식으로 정리되어 있지 않으니 모호성에 대한 분류가 불가능했습니다.

문제는 결과가 틀린다는 게 아닙니다. 이 문서가 협약서인지 변경협약서인지 확신이 서지 않는 순간에도 파이프라인은 반드시 둘 중 하나를 골라야 했다는 것입니다. 프롬프트는 항상 답을 돌려주고, 그 답에는 “이건 좀 애매한데요”라고 적을 자리가 없었습니다. 확신이 0.9일 때와 0.4일 때의 출력이 형태상 완전히 동일하니, 뒷단에서는 그 둘을 구분할 방법이 없습니다. 수학적으로 어떤 불확실성이나 모호성이 높다고 판단되면 그 판단을 버릴 수 있어야 하는데, 그 부분이 전혀 반영되지 않고 있었습니다.

모른다고 말할 근거

오늘 들은 이야기들의 상당 부분은 결국 “모른다”를 어떻게 1급 시민으로 만들 것이냐에 대한 것이었습니다. 가장 단순한 형태는 판단을 유보하는 규칙입니다.

\[\hat{y}(x) = \begin{cases} \arg\max_k \, p(y = k \mid x), & \max_k \, p(y = k \mid x) \ge \tau \\ \text{기권}, & \text{그 외} \end{cases}\]

이런 selective prediction은 임계값 하나만 있으면 되니 지금 파이프라인에도 당장 붙일 수 있습니다. 하지만 더 중요한 건, 그 확률이 어디서 온 불확실성인지를 나누는 쪽이었습니다.

\[\underbrace{H\big[\mathbb{E}_{\theta}\,p(y \mid x, \theta)\big]}_{\text{전체}} = \underbrace{\mathbb{E}_{\theta}\,H\big[p(y \mid x, \theta)\big]}_{\text{aleatoric}} \;+\; \underbrace{I(y; \theta \mid x)}_{\text{epistemic}}\]

문서가 원래 애매해서 못 정하는 것(aleatoric)과, 이런 문서를 본 적이 없어서 못 정하는 것(epistemic)은 완전히 다른 처방을 요구합니다. 앞쪽은 사람이 봐도 애매하니 규칙을 바꾸거나 그냥 두 클래스를 병기해야 하고, 뒤쪽은 라벨을 몇 개 더 주거나 아예 새로운 클래스를 만들어야 한다는 신호입니다. 지금 내 파이프라인은 이 둘을 똑같이 “일단 하나 골라서 넘김”으로 처리하고 있었습니다. 예전에 불확실성 정량화를 정리하면서 로봇 제어 맥락에서만 생각했던 구분인데, 문서 분류에도 그대로 필요한 이야기였습니다.

여기에 conformal prediction처럼 분포 가정 없이 커버리지를 보장해 주는 방법을 얹으면, 출력이 하나의 라벨이 아니라 집합 \(C(x)\) 가 되고 그 집합의 크기 자체가 모호성의 척도가 됩니다. 라벨 하나가 나오면 확정, 세 개가 나오면 사람에게 넘김. 이건 지금 구조에서도 그리 어렵지 않게 붙일 수 있는 형태로 보입니다.

지식베이스에 그대로 적용된다

이 이야기가 남 얘기 같지 않았던 이유는, 최근에 지식베이스를 세 번 엎으면서 겪은 문제들이 정확히 여기에 걸려 있었기 때문입니다. 적어도 세 군데에 바로 적용될 것 같습니다.

첫째, 문서 판단. 지금은 확신 없이 내린 분류와 확신을 갖고 내린 분류가 데이터베이스에 똑같은 모양으로 들어갑니다. 여기에 불확실성 값이 함께 저장되면, 검토 큐를 만들 근거가 생깁니다. 사람이 전수 검사를 할 게 아니라 애매한 것부터 보면 됩니다.

둘째, 관계 판단. 추출된 엔터티 사이에 관계를 놓는 일도 마찬가지입니다. 이 출장이 이 과제에 속하는지, 이 기관이 이 협약의 당사자인지 — 지금은 그렇다/아니다뿐입니다. 관계에도 근거의 세기가 붙어야 하고, 특히 “지금 가진 문서만으로는 방향을 정할 수 없다”를 표현할 수 있어야 합니다.

셋째, 그리고 가장 흥미로운 것은 새 클래스를 만들 근거입니다. 기존 온톨로지에 없는 문서가 들어왔을 때, 지금은 가장 비슷한 기존 클래스로 억지로 밀어 넣습니다. 그런데 Dirichlet process 계열의 관점에서 보면 새 클래스는 예외 처리가 아니라 모델의 일부입니다.

\[p(z_{n+1} = k \mid z_{1:n}) = \frac{n_k}{n + \alpha}, \qquad p(z_{n+1} = \text{new} \mid z_{1:n}) = \frac{\alpha}{n + \alpha}\]

“기존 클래스 중 어디에도 잘 안 맞는다”가 곧 “새 클래스를 열 만하다”의 정량적 근거가 되는 구조입니다. 온톨로지를 사람이 미리 다 짜 놓고 시작해야 한다는 부담을 덜어 줄 수 있는 방향이라고 생각합니다.

SEM과 FCI는 좀 더 공부해 봐야겠다

오늘 여러 번 나온 단어 중에 SEM과 FCI가 있었습니다.

SEM(Structural Equation Modeling) 은 직접 관측되지 않는 잠재 변수와, 그것을 간접적으로 드러내는 관측 지표들을 함께 모형화합니다. “문서의 성격” 같은 건 원래 직접 재는 값이 아니라 여러 신호를 통해 추정하는 것이니, 지금 내가 heuristic으로 뭉개고 있는 부분과 형태가 꽤 비슷합니다.

FCI(Fast Causal Inference) 는 관측되지 않은 교란 변수가 있을 수 있다는 전제에서 인과 구조를 찾는 알고리즘입니다. 개인적으로 인상적이었던 건 결과물의 형태였습니다. FCI가 내놓는 PAG에는 방향을 정할 수 없는 간선이 “정할 수 없음”으로 표시된 채 남습니다. 알고리즘이 결론을 못 내린 게 아니라, 데이터로 결정 가능한 것과 아닌 것을 구분해서 그린 겁니다. 관계에 불확실성을 붙이겠다는 이야기가 이미 그래프 표기법 수준까지 내려와 있는 셈이라, 지식베이스의 관계 표현을 다시 볼 때 참고할 만한 지점이라고 봅니다.

둘 다 아직 개념 수준에서만 알고 있어서, 돌아가면 제대로 읽어 볼 생각입니다.

그래서

정리하면 오늘의 소득은 새로운 기법 하나가 아니라 질문 하나입니다. 내 파이프라인의 모든 판단 지점에서 “이 판단을 버릴 근거가 있는가?”를 물을 수 있는가. 지금은 대부분 아니오입니다.

역시, 논문만 볼 게 아니라 학회에 나와 봐야 하는 것 같습니다. 이제 이것저것 물어보러 포스터 세션으로 이동합니다.