금융 에이전트가 모든 평가를 통과했습니다. 그 결정을 방어할 수 있나요?

AI 요약

감사 의견은 결론뿐 아니라 그 판단에 이른 근거까지 제시해야 합니다. 글은 회사 장부의 현금 잔액과 은행 기록을 대조하는 은행 계정 조정을 사례로 듭니다. 장부와 조정 내역, 은행 증거를 에이전트에 넣고 감사 방법론과 전년도 사례를 프롬프트에 제공한 뒤, 과거 감사 결과로 평가하고 사람이 승인하게 만들 수 있습니다. 하지만 평가 점수와 사용자 만족도가 높아도 특정 감사 건에서 왜 그 판단을 내렸는지 설명하지 못하면 검토에 답하기 어렵습니다. 글은 새로 업무를 맡은 경험 많은 감사인이 판단 과정을 따라갈 수 있어야 한다는 기준을 에이전트에도 적용합니다.

판단을 방어하기 위한 네 가지 통제

권한은 도구를 호출할 수 있는 정체성인지 확인하는 데 그치지 않습니다. 예를 들어 감사인이 특정 수취인의 62,500달러 수표를 예외로 표시하고 검토자가 승인했는데, 새 은행 명세서가 들어온 뒤 에이전트가 해당 행을 예외 없음으로 바꾸면 서명은 검토하지 않은 답변을 보증하게 됩니다. 서명된 행인지, 현재 상태에서 그 작업이 허용되는지를 함께 확인해야 합니다.

실행 통제는 작업을 가져오기(fetch), 추출(extract), 대조(match), 결론 내리기(conclude) 같은 단계로 나누고, 안정적인 ID 아래 각 단계의 입력과 출력, 모델 버전을 기록하는 방식입니다. 글의 사례에서는 에이전트가 96,400달러 수표가 결제됐다고 판단했지만 재실행 결과는 69,400달러였습니다. 전체 로그만 남기지 말고 이견이 생긴 단계를 당시 입력으로 다시 실행해야 판단이 달라진 위치를 확인할 수 있습니다.

증거 출처는 모델이 적은 문서 이름이 아니라 문서 ID와 버전, 해시 같은 안정적인 식별자에 연결해야 합니다. 같은 이름의 문서가 여럿이거나 문서가 수정됐을 수 있기 때문입니다. 인용한 자료가 판단에 필요한 관련 속성을 실제로 뒷받침하는지도 확인해야 합니다. 평가 무결성을 위해서는 정답 라벨에 적용 방법론과 유효 기간을 표시하고, 오답뿐 아니라 정답 판정도 점검해야 합니다. 결과는 방법론과 기간 등 조건별로 나눠 보고합니다.

사람에게 넘기는 조건

사람이 서명한 업무를 에이전트가 바꾸려 할 때, 재실행 결과가 기록과 다를 때, 증거가 대상 항목과 맞지 않을 때, 필수 규칙을 충족하지 못할 때 에이전트는 작업을 멈춰야 합니다. 이관할 때는 충돌하는 증거를 나란히 보여 주고 구체적인 질문을 제시하며 사람의 답변도 기록합니다. 검토를 쉽게 승인하게 하기보다 사실을 확인하기 쉽게 만드는 방식입니다. 글은 이 원칙을 대출 거절, 자금세탁방지(AML) 경보 종결, 가격 결정에도 적용합니다.

dev.to 반응

• @max_quimby — 서명된 행에 대한 권한 문제는 사람들을 불안하게 해야 하는 사례입니다. '이 정체성이 이 도구를 호출할 수 있는가'는 통과하지만 '지금 이 상태의 이 객체에 이 작업을 허용해야 하는가'는 실패할 수 있다는 점을 정확히 짚었습니다. 저희도 같은 문제를 겪었습니다. 정체성에 따른 권한 설정은 빈틈없어 보여도 에이전트가 정당하게 다시 실행되면서 사람이 이미 보증한 내용을 조용히 덮어쓰면 그렇지 않습니다. 서명은 약해지는 데 그치지 않고 거짓말이 됩니다. 도움이 된 방법 하나는 서명된 객체를 불변 경계로 취급하는 것이었습니다. 에이전트가 이를 수정하려면 명시적으로 다시 열어야 하고, 그 작업도 별도의 감사 이벤트로 남깁니다. 그러면 덮어쓰기가 조용히 일어나지 않습니다. 증거가 실제로 바뀌는 실행 통제 문제에 대한 의견도 듣고 싶습니다. 새 명세서가 들어오면 재실행에서 다른 숫자가 나오는 게 맞습니다. 고쳐야 할 비결정성과 세상의 변화를 구분하는 일은 저희 재생 비교에서 잡음을 만들었습니다. 단계 기록에 이를 어떻게 표시하나요?
• @alexshev — 감사 에이전트에 유용한 산출물은 결론뿐 아니라 재생 가능한 근거입니다. 출처 식별자와 변환 과정, 당시 적용한 정책이나 기준표가 필요합니다. 은행 증거에서 에이전트 판단까지 예외 항목 하나를 추적하는 검토 화면이 있으면 검토자가 전체 실행을 다시 구성하지 않아도 의견을 방어할 수 있습니다.
• @arhancanli — 실행 통제 사례의 96,400달러와 69,400달러는 자릿수가 뒤바뀐 경우입니다. 두 수의 차이인 27,000은 9로 나누어떨어지며, 숫자가 같은 채 순서만 바뀐 경우에는 자리 바뀜을 나타내는 전형적인 징후입니다. 재실행 결과가 9로 나누어떨어지는 차이를 보이고 숫자도 맞물리면 결론 단계보다 추출 단계가 원인일 가능성이 큽니다. 따라서 저장된 입력으로 해당 단계만 다시 실행하는 접근이 맞고, 사람이 확인하기 전에 저렴한 자동 경고를 띄울 수도 있습니다. 평가 무결성에도 같은 아이디어를 적용할 수 있습니다. 추출한 금액을 명세서 자체의 소계와 대조하면 정답 라벨 없이도 이런 오류를 잡을 수 있습니다. 소계나 총액 검증을 별도 단계로 기록하나요, 아니면 추출 단계에 포함하나요?
• @kartik-nvjk — 62,500달러 수표 사례가 와닿았습니다. 에이전트 정체성에는 모든 쓰기 권한이 있었지만 검토자가 이미 서명한 행을 덮어썼습니다. 저는 에이전트 권한을 도구별로만 설정하고 객체 상태별로는 설정하지 않았는데, 이 부분을 보완해야겠습니다. 서명된 행을 데이터 계층에서 잠그나요, 아니면 에이전트가 쓰기 전에 매번 행 상태를 확인하나요?

원문: dev.to / 번역·요약: Trawling