Human-in-the-loop는 안전장치가 아니다. 규제 준수 라벨이 붙은 UX 문제다.
요약
Human-in-the-loop(HITL) 시스템이 아키텍처 다이어그램상으로는 완벽해 보이지만, 실제 운영 환경에서는 인간의 주의력 부족으로 인해 안전장치 역할을 제대로 수행하지 못할 수 있습니다. 따라서 모든 것을 검토에 맡기기보다, 모델이 불확실하거나 비용이 높을 때만 에스컬레이션하는 라우팅 전략이 필요합니다.
핵심 포인트
- HITL은 설계상의 문제일 뿐, 실제 운영에서는 주의력 부족으로 실패하기 쉽습니다.
- 모든 출력을 검토하게 하는 것은 오히려 인간의 경계심을 떨어뜨립니다.
- 모델의 의존 근거(Input)를 보여주는 UX가 중요하며, '승인'만큼 쉽게 '거부'할 수 있어야 합니다.
다이어그램과 화요일 오후의 차이점
아키텍처 다이어그램 상에서는 human-in-the-loop가 훌륭해 보인다. 모델이 결정을 내리고, 'human review'라고 표시된 박스가 모델과 프로덕션 사이에 위치하며, 모두들 디자인 문서에 서명하면서 더 안전하다고 느낀다.
그러고 시스템이 출시된다. 검토자는 실제 대기열을 가진 사람이고, 평범한 화요일 오후 그 대기열에는 340개의 항목이 들어있다. 대부분은 명백히 괜찮다. 40번째 항목에 이르러서야 첫 줄을 읽는다. 120번째 항목에 이르러서는 리듬을 타며 '승인' 버튼을 클릭한다.
다이어그램 속의 박스는 여전히 존재하지만, 검토 과정은 없다.
이것이 간극이다: 우리는 인간을 무한한 주의력을 가진 구성 요소로 취급하지만, 주의력이야말로 전체 파이프라인에서 가장 희소한 자원이다. 아래에는 내가 가장 자주 보는 실패 모드들과 예시(특정 회사가 아닌 종합적인 예시)가 있다.
실패 모드 1: 모든 것을 인간에게 맡기기
가장 단순한 설계는 모든 모델 출력을 검토에 거치도록 한다. 이는 보수적으로 느껴진다. 하지만 실제로는 가장 안전하지 않은 선택이다. 왜냐하면 검토자에게 승인이 예상되는 답변이라는 인식을 심어주기 때문이다.
예시: 청구서 분류 모델이 97%의 정확도를 가진다고 하자. 검토자는 하루에 300개의 청구서를 보게 되므로, 대략 9개가 틀리다. 이 9개는 한눈에 동일해 보이는 291개의 올바른 항목 사이에 파묻혀 있다. 2주 후, 검토자의 재정의(override) 비율은 거의 0으로 떨어진다. 모델이 개선되어서가 아니라, 인간이 보기를 그만뒀기 때문이다.
해결책은 라우팅이다. 모델이 불확실할 때, 또는 틀렸을 경우 비용이 높을 때만 에스컬레이션(escalate)해야 한다:
def route(decision, confidence, impact):
# High-impact actions always get a human, whatever the confidence
if impact ==
여기서 중요한 두 가지 세부 사항이 있습니다. 첫째, 자신감만으로는 충분하지 않습니다. 모델은 확신을 가지고 틀릴 수 있으며, 여러 모델의 원시 점수는 보정(calibrated)이 잘 되어 있지 않습니다. 임계값(threshold)을 신뢰하기 전에 별도로 분리된 데이터(held-out data)에서 보정을 확인하고, 자신감에 영향 규칙(impact rule)을 결합해야 합니다. 둘째, 자동 승인 항목에 대한 감사 샘플(audit sample)이 여러분의 임계값이 여전히 올바른지 알아내는 방법입니다.
## 실패 모드 2: 검토자가 추론 과정을 재구성해야 하는 경우
두 번째 실패는 모델의 답변만 보여주고 다른 것은 아무것도 보여주지 않는 검토 화면입니다. 검토자는 이제 두 가지 임무를 갖게 됩니다. 작업을 처음부터 다시 하거나, 아니면 그 답변을 신뢰하는 것입니다. 시간적 압박 속에서 그들은 답변을 신뢰합니다.
예시: 대출 서류 추출 도구가 '연간 수입: 84,000'이라고 표시합니다. 이를 확인하기 위해 검토자는 22페이지 분량의 PDF를 열고 수동으로 검색합니다. 그들은 그것을 조심스럽게 두 번 수행한 후 중단합니다.
좋은 검토 화면은 모델이 의존했던 정확한 입력(input)을 보여줍니다: 원본 문서에서 강조 표시된 범위(highlighted span), 점수를 유도한 필드, 에스컬레이션(escalation)을 촉발한 규칙입니다. 검증은 조사가 아니라 한눈에 파악하는 것이 됩니다. 모델이 무엇을 사용했는지 노출할 수 없다면, 더 많은 검토자를 추가하기 전에 고쳐야 할 부분입니다.
## 실패 모드 3: 재정의(Overriding)가 승인보다 어려운 경우
'승인'은 한 번의 클릭으로 되지만 '거부'는 필수 필드 여섯 개가 있는 양식을 여는 경우, 여러분은 무언가를 승인하도록 설계된 시스템을 만든 것입니다.
재정의 경로는 승인 경로만큼 저렴해야 합니다: 수정하기 위한 하나의 동작, 선택적이고 짧은 이유, 그리고 자동으로 캡처되는 수정된 값입니다. 모든 재정의는 원래 출력물, 수정 내용, 누가 했는지, 언제 했는지와 함께 기록되어야 합니다.
그 로그는 서류 작업이 아닙니다. 그것은 여러분이 가진 가장 유용한 데이터셋이며, 모델이 정확히 어디에서 실패하는지 그리고 여러분의 임계값이 올바른 위치에 설정되었는지 알려주기 때문입니다.
## 실패 모드 4: 검토자를 아무도 측정하지 않는 경우
검토 행동을 추적하지 않으면, 루프가 조용해질 때 알아차리지 못할 것입니다. 주목할 만한 몇 가지 신호들이 있습니다:
- 검토당 소요 시간 (갑작스러운 감소는 경고 신호)
- 시간에 따른 재정의율(Override rate) (거의 0에 가까운 것은 안심하기보다 의심스럽다)
- 검토자가 승인했던 감사 샘플에서 발견된 오류
이 지표들은 'Human-in-the-loop'가 여전히 무언가를 하고 있는지 알려줍니다.
## 재정의 관점 (The reframe)
'Human-in-the-loop'는 사실 그 앞에 있는 모델과 관련된 주의 집중 할당(attention-allocation) 문제입니다. 이 모델의 임무는 무엇을 건너뛰어도 안전한지 결정하는 것입니다. 인터페이스의 임무는 남아있는 결정을 빠르고 정확하게 내리도록 하는 것입니다. 그리고 로그의 임무는 이 둘 중 어느 하나가 작동을 멈췄는지 보여주는 것입니다.
저희는 Cyclopt에서 이것에 대해 많이 생각합니다. 왜냐하면 코드베이스를 건드리는 모든 AI 액션은 같은 질문을 제기하기 때문입니다. 즉, 어떤 부분에 사람이 필요한지, 그리고 그 사람의 검토가 얼마나 의미 있는지를 어떻게 만들 것인가 하는 문제입니다.
그래서 여러분께 드리고 싶은 질문이 있습니다. 여러분의 Human-in-the-loop 검토 대기열에서 재정의율은 얼마이며, 그것을 실제로 알고 계십니까?
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기