Human-in-the-loop AI 에이전트: 승인 게이트가 위치해야 할 곳

대부분의 에이전트 데모는 끝에 확인 버튼을 추가하여 사람을 개입시킵니다. 이 시점에는 이미 에이전트가 이메일을 보내거나 행(row)을 작성한 후입니다. 유용한 승인 게이트는 루프 안에, 외부 세계를 변화시키는 바로 그 단계 직전에 위치해야 합니다.

답변이 아닌 게이트의 부작용

에이전트는 두 가지 종류의 작업을 수행합니다. 읽기(read): 검색, 문서 검색, 데이터를 반환하는 API 호출 등입니다. 그리고 행동하기(act): 메시지 전송, 기록 업데이트, 자금 이동, 삭제 등이 있습니다. 읽기는 틀려도 비용이 적게 들기 때문에 결과를 버릴 수 있습니다. 하지만 행동은 그렇지 않습니다.

따라서 게이트는 대화가 아닌 도구(tools)에 위치해야 합니다. 에이전트가 자유롭게 계획하고 읽도록 두십시오. 쓰기(writes) 기능을 가진 도구를 호출하기로 결정했을 때, 멈추고, 수행하려는 정확한 호출을 저장한 다음 기다려야 합니다.

def call_tool(run, tool, args):
    if tool.writes and needs_approval(tool, args):
        request = save_pending(run.id, tool.name, args)
...

모든 쓰기 작업이 사람의 승인을 필요로 하는 것은 아닙니다. 초안을 작성하는 것과 전송하는 것은 다릅니다. 유용한 구분은 되돌릴 수 있는지(reversible)와 돌이킬 수 없는지(irreversible), 그리고 내부적인지(internal)와 고객에게 보이는지(visible to a customer)입니다. 돌이킬 수 없고, 고객에게 노출되는 행동은 항상 기다려야 합니다. 반면, 되돌릴 수 있고 내부적인 행동은 보통 그렇지 않습니다.

검토자가 봐야 할 것들

'에이전트가 기록을 업데이트하려고 합니다. 승인하시겠습니까?'라는 메시지는 매번 승인되어 무의미합니다. 검토자는 '아니오'라고 말할 수 있을 만큼 충분한 정보를 필요로 합니다.

• 정확한 행동과 그 인자(arguments)를, 가능하다면 현재 상태 대비 차이점(diff)으로 보여주는 방식입니다. '마감일을 12월 11일에서 3월 1일로 변경'이라는 설명은 JSON 블롭보다 훨씬 좋습니다.
• 에이전트가 왜 그렇게 하려 하는지, 사용한 출처와 함께 문장으로 설명해야 합니다. 검색된 문서가 결정의 원인이었다면 링크를 제공해야 합니다.
• 아무도 응답하지 않을 경우 어떻게 되는지에 대한 정보입니다. 만료 기한이 없는 승인 요청은 몇 주 후에 실행되는 오래된(stale) 행동으로 변질될 수 있습니다.

검토자가 단순히 승인하거나 거부하는 것뿐만 아니라 인자 자체를 편집할 수 있도록 해야 합니다. 대부분의 수정 사항은 작습니다: 잘못된 날짜, 잘못된 수신자 한 명 등입니다. 전체 행동을 거부하고 에이전트를 다시 실행하여 하나의 필드를 고치는 것은 모두의 시간을 낭비합니다.

모델의 신뢰도에만 의존하지 마세요

모델이 확신한다고 말할 때마다 승인 절차를 건너뛰고 싶은 유혹을 느낄 수 있습니다. 자신의 신뢰도를 평가하도록 요청받은 모델이라 할지라도, 틀린 답변에 대해 높은 숫자를 줄 때가 많습니다. 대신 모델 외부에서 확인할 수 있는 신호를 사용하세요.

• 검색(retrieval)이 관련성 있는 것을 찾았는지, 아니면 답변이 모델의 메모리에서 온 것인지?
• 인자들(arguments)이 유효성을 통과하는지 확인하세요: 기록이 존재하는가, 금액이 정상 범위를 벗어나지 않았는가?
• 이 정확한 종류의 행동이 전에 변경 없이 여러 번 승인된 적이 있는가?
• 이 단계를 두 번 실행하는 것이 해를 끼칠까?

원한다면 이들을 조합하여 점수를 매길 수 있습니다. 핵심은 모든 부분이 모델에게 다시 물어보지 않고도 검증될 수 있다는 것입니다.

'예' 이후 재개하기

승인은 몇 분 또는 며칠 후에 도착할 수 있습니다. 그때쯤이면 요청했던 프로세스는 사라졌을 수 있고, 기록은 변경되었을 수 있으며, 검토자는 버튼을 두 번 클릭했을 수도 있습니다.

• 에이전트의 메모리가 아닌 보류 중인 호출(pending call)을 영속화하세요. 모델에게 추론을 다시 수행하도록 요청하고 같은 답변을 기대하는 대신, 저장된 호출을 실행하여 재개하세요.
• 실행하기 전에 월드(world)를 다시 확인하세요. 요청이 이루어진 이후 기록이 변경되었다면, 다시 물어보세요.
• 모든 승인된 행동에 비멱등성 키(idempotency key)를 부여하여, 두 번 클릭하거나 재시도해도 한 번만 실행되도록 하세요.
• 누가 무엇을, 언제 승인했고 실제로 무엇이 실행되었는지 기록하는 감사 행(audit row)을 작성하세요. 나중에 무언가 잘못될 때, 그 행이 누구나 가장 먼저 요청하는 것이 됩니다.

'승인 피로도'를 주의하세요

하루에 50번씩 발생하는 게이트는 읽어보지 않고 통과 버튼만 눌리게 만듭니다. 이것은 게이트가 없는 것보다 더 나쁩니다. 왜냐하면 감독이 부족해 보이기 때문입니다. 각 종류의 요청이 변경 없이 얼마나 자주 승인되는지 추적하세요. 그 비율이 낮은 위험도의 행동에 대해 매우 높게 유지된다면, 자동화하고 인간의 주의력은 실제로 수정되거나 거부된 요청에 집중적으로 사용하세요.

목표는 모든 루프마다 사람이 있는 것이 아닙니다. 잘못된 행동이 비용이 많이 드는 몇몇 단계에 사람이 존재하며, 그들이 포착할 수 있을 만큼 충분한 정보를 가지고 있는 것입니다.

원문은 anukumar.site에 게시되었습니다.