Safety Guard Architecture와 Human In The Loop

Architecture로 보기

실무 사이클은 Planner, 비판 반복, 검증, 정책 엔진, 실행, 관측과 PostCondition Verifier로 이어집니다. 마지막 Verifier는 단지 성공 여부를 찍는 장치가 아니라, 피드백용 메모리를 관리하는 장치입니다. 실패가 나오면 Belief, Rule, Procedure 쪽으로 다시 들어가야 합니다.

Safety guard는 한 줄짜리 금칙어 필터가 아닙니다. Input guard, memory guard, retrieval guard, action guard, output guard, audit guard가 따로 있어야 합니다. 입력에서 위험을 줄이고, 기억에서 민감정보를 관리하고, 검색에서 신뢰도를 보고, action에서 권한을 확인하고, 출력에서 재배포 위험을 줄입니다.

이 구조는 앞선 문서의 7, 8, 9번 주제를 한 사이클로 묶습니다. conflict가 생기면 guardrail이 작동하고, operation은 action ontology를 통과하고, capability는 permission과 policy reasoning을 거쳐야 합니다.

Policy 구조화

Policy를 구조화할 때는 Permission, 제한, Obligation을 분리해야 합니다. Permission은 해도 되는 일이고, 제한은 특정 조건에서 막아야 하는 일이며, Obligation은 반드시 해야 하는 일입니다. 예를 들어 공개 배포 전 개인정보 점검은 obligation이고, 외부 전송 전 승인 요구는 approval requirement입니다.

Approval Requirement는 action 전에 필요한 작업을 정리합니다. 어떤 정보가 더 필요한지, human 동의가 필요한지, 대안이 있는지, 실패하면 무엇을 되돌려야 하는지 출력해야 합니다. agent가 스스로 개선하려면 승인 요청 자체가 좋은 데이터가 되어야 합니다.

사이클 예시

예를 들어 agent가 사이트에 광고를 추가한다고 합시다. Observe 단계에서 현재 HTML과 CSS, 광고 설정을 읽습니다. Classify 단계에서 광고 단위, 화면 위치, 국가 분기, 정책 위험을 분류합니다. Plan 단계에서 top, side, inArticle 같은 슬롯을 정합니다.

Gate 단계에서는 Kakao와 Google이 동시에 뜨지 않는지, 허용 크기를 지키는지, 클릭 유도 문구가 없는지 봅니다. Execute 단계에서 파일을 고치고, Verify 단계에서 실제 HTML과 JS 분기를 확인합니다. Learn 단계에서 실패가 있으면 rule로 남깁니다.

Human In The Loop의 자리

Human In The Loop는 사람을 귀찮게 하자는 장치가 아닙니다. agent가 책임지기 어려운 지점에서 사람에게 판단권을 돌려주는 장치입니다. 개인정보 외부 전송, 대규모 삭제, 공개 배포, 법적 판단, 비용 발생은 사람이 개입하는 편이 자연스럽습니다.

좋은 HITL 화면은 짧아도 정보가 빡빡합니다. 대상, 실행 이유, 근거, 위험, 대안, 복구 가능성, 로그 위치가 있어야 합니다. 사람은 모델의 기분을 승인하는 것이 아니라 operation을 승인합니다. 그래서 승인 UI도 action ontology를 보여줘야 합니다.

정리

이 글에서는 guard location, risk escalation, human role, evidence display, incident type을 챙깁니다. agent가 멈췄을 때 왜 멈췄는지 설명할 수 있어야 하고, 실행했을 때 왜 실행했는지 증명할 수 있어야 합니다.

법적 규제 준수는 safety architecture의 중심입니다. 자동화가 빠를수록 법적 위반도 빠르게 퍼질 수 있습니다. 그래서 기본값은 보수적이어야 하고, 위험한 자동 실행은 인간 루프로 올려야 합니다.