나의 편향 탐지기가 "정보 없음"이라는 답변에서 "체리 피킹 (Cherry-Picking)"을 발견했다

몇 달 전, 나는 Biassemble이라는 작은 개인 프로젝트를 시작했습니다. 개인적인 이야기를 입력하고 몇 가지 후속 질문을 던지면, 그 사람이 일어난 일에 대해 추론하는 방식에서 나타날 수 있는 인지 편향 (cognitive biases)을 찾아내는 프로젝트였습니다.

획기적인 것은 아니었습니다. 나는 한동안 프론트엔드 엔지니어 (frontend engineer)로 일해 왔고, LLM 시스템 — 구조화된 출력 (structured outputs), 평가 (evaluation) 등 이제 모두가 "LLM 엔지니어링 (LLM engineering)"이라고 부르는 분야 — 을 직접 다뤄보고 싶었습니다. Biassemble은 스타트업 아이디어가 아니라, 만드는 과정을 통해 배우기 위한 구실이었습니다. 나는 AI 관련 업무로 전업하고 싶은지 확신이 서지 않았습니다. 그저 나 자신을 시험해 볼 수 있는 프로젝트가 필요했을 뿐입니다.

그리고 이 프로젝트는 나를 시험했습니다. 다만 내가 예상했던 방식은 아니었습니다.

모든 것을 망가뜨린 이야기

초기 테스트 스토리 중 하나는 다음과 같았습니다:

Anna는 오전 8:00에 문을 열었습니다. 그녀는 파란색 머그컵에 커피를 따랐습니다. 머그컵의 용량은 350밀리리터였습니다. 그녀는 블랙커피로 마셨습니다. 오전 8:15에 그녀는 버스 정류장으로 걸어갔습니다. 버스는 오전 8:22에 도착했습니다. 그녀는 창가 쪽 세 번째 줄에 앉았습니다. 버스는 17분 동안 이동했습니다. Anna는 Main Street에서 내렸고 사무실까지 240미터를 걸었습니다. 그녀는 오전 8:42에 도착했습니다. 그녀의 책상에는 컴퓨터, 노트, 그리고 펜 하나가 있었습니다. 펜은 검은색이었습니다. 그녀는 오전 8:43에 타이핑을 시작했습니다.

의견도, 결정도, 감정적 내용도 없는 — 그저 사실의 나열이었습니다.
이 이야기에 대해, 시스템은 Anna의 아침에 대한 나의 해석을 묻는 네 가지 후속 질문을 생성했습니다. 내가 준 모든 답변은 동일했습니다: 정보 없음 (no info). 해석할 내용이 아무것도 없었습니다. 나는 Anna나 그녀의 커피, 혹은 그녀의 출근길에 대해 어떠한 결론도 내리지 않았습니다.

원래 프롬프트 (prompt)의 지침은 거의 그대로였습니다: "카탈로그에서 최소 하나 이상의 편향을 탐지하라." Anna의 이야기와 같은 경우, 이 지침은 실제로 찾을 것이 있든 없든 시스템이 항상 무언가를 반환해야 함을 의미했습니다.

첫 번째 해결책: 도움을 요청하고 근거를 추가하기

저는 LLM에게 무엇이 잘못되었는지 물었습니다. 제안된 해결책은 합리적이었습니다. 구조화된 추론 흔적 (reasoning trace)을 추가하고, 모든 편향 (bias)에 대해 이야기나 답변에서 근거가 되는 증거 (grounded evidence)를 인용하도록 요구하는 것이었습니다. 그것이 프롬프트 버전 1.0.0이 되었습니다. 즉, 이야기 분석 단계, 순위가 매겨진 해석들, 편향 가설, 증거 매핑 (evidence-mapping) 단계, 그리고 아무것도 해당하지 않을 때를 위한 noBiasDetected 플래그를 포함했습니다.

이 모든 것은 프롬프트에서 reasoningTrace라고 부르는 단일 구조화된 객체 안에 존재합니다. 사용자에게 보여지는 평가와 함께 이야기 분석, 해석, 편향 가설, 그리고 증거 매핑이 생성됩니다.

이론적으로는 이 방식이 Anna 문제를 해결했어야 했습니다. 근거가 되는 증거가 없다면, 편향도 없는 것이니까요.
하지만 네 개의 후속 답변을 모두 "정보 없음 (no info)"으로 설정하여 Anna 이야기에 실행했을 때, 실제로 반환된 결과는 다음과 같습니다:

체리 피킹 (Cherry-Picking) — 사용자는 해석이나 주관적 분석을 요구하는 질문에 일관되게 "정보 없음"이라고 답변했습니다. 이는 명시된 사실에만 집중하고 더 깊은 추론을 피하는, 정보의 선택적 제시를 시사합니다. 여러 질문에 걸쳐 나타나는 이러한 패턴은 해석적 데이터의 의도적인 누락을 나타냅니다.

저는 그 문장을 두 번 읽었습니다. 증거 요구 사항은 기술적으로 충족되었습니다. 저는 실제로 인용된 그대로, 토씨 하나 틀리지 않고 네 번 모두 "정보 없음"이라고 답변했기 때문입니다. 시스템은 인용구를 지어내지 않았습니다. 대신 실제 답변을 가져와 그것을 바탕으로 진단을 내린 것입니다. 즉, 추측하기를 거부한 행위 자체가 추론 오류의 증거가 된 것입니다.
근거 제시 (Grounding)는 인용을 정직하게 만들었지만, 결론을 정당화해주지는 못했습니다.

무엇이 해당하지 않는지 시스템에 알려주기

여기서의 해결책은 더 많은 제시 (Grounding)가 아니라, 제시 (Grounding)가 무엇을 의미하는지를 정의하는 것이었습니다.
버전 1.1.0에서는 그 자체로는 편향 (Bias)의 증거가 되지 않는 항목들의 명시적인 목록을 추가했습니다: 사실적 기술 (Factual descriptions), 중립적 관찰 (Neutral observations), 불확실성 (Uncertainty), 그리고 특히 — "모릅니다"라고 말하기, "정보 없음"이라고 말하기, 추측을 거부하기 등이 포함됩니다.
또한 '단계 0 (Step 0)'을 추가했습니다: 어떠한 해석 (Interpretations)을 생성하기 전에, 해당 이야기가 믿음 (Beliefs), 판단 (Judgments), 예측 (Predictions), 결정 (Decisions)과 같은 심리학적 요소 (Psychological material)를 포함하고 있는지 여부를 먼저 결정합니다. 만약 포함되어 있지 않다면, 거기서 멈춥니다.
신뢰도 게이팅 (Confidence gating)도 추가되었습니다: 신뢰도(Confidence)가 0.60 미만인 가설들은 내부 추론 흔적 (Internal reasoning trace)에만 머물며 사용자에게는 절대 전달되지 않습니다.
그리고 그 무엇보다도 더 큰 역할을 하게 된 한 줄의 문장을 추가했습니다: 거짓 양성 (False positives)은 거짓 음성 (False negatives)보다 나쁩니다. 만약 증거가 약하거나, 모호하거나, 불충분하다면, noBiasDetected = true를 선호하십시오.

v1.1.0은 v1.0.0과 동일한 3단계 구조를 유지하지만 세 가지 게이트(Gates)를 추가합니다: 시작 단계의 충분성 검사 (Sufficiency check), 중간 단계의 증거 제외 규칙 (Evidence-exclusion rule), 그리고 출력 전의 신뢰도 임계값 (Confidence threshold).

동일한 이야기와 동일한 "정보 없음" 답변에 대해 실행했을 때, 버전 1.1.0은 빈 편향 평가 (Bias assessment)를 반환했습니다. 성찰 프롬프트 (Reflection prompt)는 해당 상호작용이 해석적이기보다는 기술적 (Descriptive)이었다는 점을 인정하고 거기서 멈췄습니다.

동일한 네 가지 "정보 없음" 답변, 두 가지 프롬프트 버전, 정반대의 결론 — v1.0.0은 이를 체리 피킹 (Cherry-Picking)이라 부르고, v1.1.0은 편향 없음 (No bias)이라 부릅니다.

두 출력물은 정확히 동일한 입력값에 대해 추론(reasoning)을 수행하고 있습니다. 차이점은 증거가 존재하는지 여부가 아닙니다. 차이점은 "모르겠습니다"라는 답변이 무언가의 증거로 간주되느냐 하는 점입니다. 그리고 누군가는 이를 명시적으로 결정해야 합니다. 모델 스스로는 이를 결정하지 않을 것이기 때문입니다.

두 프롬프트 버전 간의 실제 차이점(diff)

아직 구축하지 못한 것들

이 시점에서 저는 몇 가지 지표(metrics) 세트를 계획하기 시작했습니다. evidence_grounded_rate (증거 기반율), false_positive_rate (오탐률), 그리고 파이프라인에 체계적으로 실행해 볼 의도적으로 지루한 "편향 없음 (no bias)" 이야기 코퍼스(corpus) 같은 것들 말입니다.

저는 아직 그중 어느 것도 구축하지 않았습니다. 그리고 제가 체리 피킹 (Cherry-Picking) 문제를 포착한 방식이 바로 그것이 왜 중요한지를 보여줍니다. 저는 이야기 하나를 수동으로 실행하고 출력물을 주의 깊게 읽었습니다. 그런 방식은 확장성(scale)이 없으며, v1.1.0이 제가 테스트할 생각을 하지 못한 다른 곳에 동일한 결함을 가지고 있는지 알려주지 못합니다. 아마도 "모르겠습니다"라는 표현이 다르게 바뀌면 빠져나갈 수도 있습니다. 아마도 하나의 모호한 세부 사항과 세 개의 "정보 없음 (no info)" 답변이 포함된 이야기는 네 개의 답변이 있는 경우와 다르게 동작할 수도 있습니다.

현재 "작동한다"는 말은 "이번에는 이 이야기에서 작동했다"는 뜻입니다. 이것이 프로젝트의 현 상태에 대한 정직한 설명입니다. 또한, 다음 단계가 새로운 기능(feature)이 아니라, 수정 사항이 과연 일반화(generalize)될 수 있는지 확인하는 방법이어야 하는 이유이기도 합니다.

더 불편한 가능성도 존재합니다. 어쩌면 v1.1.0은 일반적인 문제를 해결하지 못했을 수도 있습니다. 어쩌면 그저 이 특정 이야기 — Anna의 커피에 관한 네 개의 "정보 없음" 답변 — 만 학습했을 수도 있으며, 약간 다른 형태의 "모르겠습니다"가 나오면 다시 체리 피킹 (Cherry-Picking) 상태로 빠져버릴 수도 있습니다. 저는 아직 그것을 배제할 수 있는 평가 코퍼스(evaluation corpus)를 가지고 있지 않습니다. 이것은 변명이 아니라, 프로젝트의 실제 상태입니다.

프롬프트 규칙만이 이를 포착할 수 있는 유일한 방법은 아닙니다. 추론(reasoning) 단계 이전에 "정보 없음" 스타일의 무응답을 감지하는 저렴한 분류기(classifier)나 단순한 규칙 기반 사전 점검(rule-based precheck)도 제 역할을 할 수 있었을 것입니다. 제가 규칙 기반 사전 점검을 추가하지 않은 이유는 사용자에게 후속 질문에 답변하도록 강요하고 싶지 않았기 때문입니다. "모르겠습니다"라고 말할 수 있는 옵션을 보존하는 것은 의도적인 설계 선택(design choice)이었습니다.

내가 예상하지 못했던 것

나는 이것이 편향 탐지기 (bias detector)를 구축하는 것이라고 생각하며 시작했습니다. 하지만 실제로 내가 만든 것은, 한 번의 실패를 거듭하며, 왜 "모르겠습니다"라는 답변을 추론 시스템 (reasoning system)이 처리하기 어려운지에 대한 작은 교훈이었습니다. 그리고 그 이유는 내가 가정했던 것과는 달랐습니다.

나는 어려운 부분이 편향이 존재하지 않을 때 모델에게 편향을 찾지 말라고 말하는 것이라고 예상했습니다. 그 부분은 거의 쉬운 것으로 드러났습니다. 플래그 (flag)를 추가하고, "이것은 증거가 아님" 목록을 추가하면 끝이었습니다.

진정으로 어려운 부분은, 모델이 내가 작성한 모든 근거 제시 (grounding) 요구 사항을 충족하면서도 여전히 확신에 차 있고, 인용이 잘 되어 있으며, 완전히 근거 없는 결론을 도출할 수 있다는 사실을 깨닫는 것이었습니다. 모델은 추측하기를 거부하는 나의 태도 자체를 진단할 가치가 있는 나에 대한 사실로 취급함으로써 이를 수행했습니다.

이 프로젝트에서 가장 유용했던 변화는 추론 과정 (reasoning trace)도 아니었고, 증거 요구 사항 (evidence requirement)도 아니었습니다. 그것은 "모르겠습니다", "정보 없음", "확실하지 않음"과 같은 일부 답변은 아무런 의미도 갖지 않는다는 점을 명시적으로 문서화한 규칙이었습니다. 시스템에 이 점을 반드시 알려주어야 합니다. 왜냐하면 기본적으로 시스템은 당신이 제공하는 그 어떤 것에서도 어떻게든 의미를 찾아내려 할 것이기 때문입니다.

live
main repo
core repo