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

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

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

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

지나치게 단호했던 판단들

그동안 LLM이나 에이전트로 해 온 작업은 굉장히 heuristic하고 deterministic했던 것 같아요. 문서의 종류가 무엇인지, 이 문서에서 어떤 특징을 뽑아야 하는지에 대한 판단을 대부분 경험에 기대어 내렸고, 그 결정이 수식으로 정리되어 있지 않으니 얼마나 모호한지를 가려낼 방법이 없었습니다.

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

모른다고 말할 근거

그럼 파이프라인이 “모른다”고 말하게 하려면 어떻게 해야 할까요? 오늘 들은 이야기의 상당 부분은 결국 “모른다”는 답을 어떻게 정식 출력으로 다룰 것인가에 관한 것이었습니다. 가장 단순한 형태는 판단을 유보하는 규칙이에요.

\[\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에는 방향을 정할 수 없는 간선이 “정할 수 없음”으로 표시된 채 남습니다. 알고리즘이 결론을 못 내린 것이 아니라, 데이터로 결정할 수 있는 것과 없는 것을 구분해서 그린 거죠. 관계에 불확실성을 붙이자는 이야기가 이미 그래프 표기법 수준까지 내려와 있는 셈이라, 지식베이스의 관계 표현을 다시 볼 때 참고할 만한 지점으로 보입니다.

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

정리

그럼 오늘의 소득은 무엇이었을까요? 결국 새로운 기법 하나가 아니라 질문 하나인 것 같습니다. 내 파이프라인의 모든 판단 지점에서 “이 판단을 버릴 근거가 있는가?”를 물을 수 있는가 하는 것입니다. 지금은 대부분 ‘아니오’일 것 같네요.

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