AI 에이전트의 결과물을 검수하지 않아도 되는 시점은 언제인가요?

진짜 좋은 지적이다. 내 얘기가 딱 그 부분이었거든. 내 에이전트는 틀린 내용을 말할 때도 엄청 자신만만했으니까, 자신감은 절대 신호가 될 수 없지. 영향 범위를 제한하는 게 훨씬 합리적인 것 같아. 잘못된 결과물이 실제로 아무것도 바꿀 수 없다면, 그렇게 빡세게 검증할 필요도 없으니까. 내 에이전트는 읽기 전용 환경에서만 답을 하니까 피해가 제한적이지. 하지만 에이전트의 결과물이 무언가에 직접 영향을 미칠 수 있게 되는 순간, 검증 방식은 완전히 달라져야 할 거야.

좋아, 내 생각을 바꾼 건 '트랜스크립트는 상태를 렌더링한 것일 뿐, 상태 그 자체가 아니다'라는 말이었어. 나는 내가 예상한 것과 답변을 대조하고 있었는데, 사실은 시스템의 상태를 실제 데이터와 대조했어야 했던 거지. 그래서 답변은 그렇게 정상적으로 보였던 거고, 나는 raw log에서야 버그를 발견할 수 있었던 거야. 되돌릴 수 있는 작업과 없는 작업으로 나누는 것도 이해가 돼. 내 에이전트는 지금 읽고 답하는 것만 하니까 거의 모든 게 되돌릴 수 있는 작업이지. 하지만 나는 절대...

좋은 지적임. 사람이 코드를 짤 때는 모든 걸 테스트하면서, 에이전트가 짜면 그 습관을 까먹는단 말이지. 아직 에이전트를 위한 정식 테스트 하네스는 없지만, 변경할 때마다 똑같은 질문을 던져보는데, 결과물을 뚫어지게 쳐다보는 것보다 리그레션 잡는 데 훨씬 빠름. 완벽하게 결정론적인 검증은 아니지만, 지금 내가 할 수 있는 최선임.

evals를 하나의 독립적인 기술로 다룬다는 건 처음 들어봤는데, 진짜 일리 있네. 이미 코드 변경 사항은 테스트로 다 검증하고 있으니까, 에이전트 결과물도 똑같이 하는 게 당연한 수순이지. 그 영상들 찾아봐야겠음, 어차피 다들 그 방향으로 가고 있는 것 같으니까. 알려줘서 고마움!

실수했을 때의 비용과 실수가 얼마나 빨리 드러나는지를 기준으로 삼으셈. 가역적이고, 비공개로 관찰 가능하며, 재실행 비용이 저렴한 작업부터 시작해서 실패율을 알 때까지 에이전트 결과와 사람의 결과를 비교해 보셈. 그다음엔 에러뿐만 아니라 성공해 보이는 결과물도 샘플링하셈. 조용히 넘어가는 거짓 양성(false positive)이 진짜 위험하니까. Mio를 만들 때도 전송, 결제, 권한 변경, 파괴적인 쓰기 작업 전에는 같은 워크플로우가 성공했더라도 여전히 권한을 다시 확인함...

절대 안 함. 난 내 (인간) 동료들이 한 일도 검토 안 멈췄음.

특정 상황에 따라 다르겠지만, 가끔은 에이전트가 처음부터 끝까지 다 하게 두면 안 됨. 에이전트한테 작업의 80% 정도인 특정 지점이나 상태까지만 하라고 시키는 거임. 그럼 결과물을 검증하기 쉬워지고, 나머지는 직접 하거나 다른 에이전트를 돌리면 됨. 이게 일종의 HITL 방식이지. 간단한 예로 데이터베이스에서 데이터를 가져올 때, 에이전트한테 데이터를 직접 가져오라고 하지 말고 쿼리를 짜라고 하는 거임. 쿼리는 직접 검증할 수 있으니까...

성공했다는 보고만 계속되는 게 아니라, 검사기가 실제로 실패를 잡아낸다는 증거가 필요함. 샌드박스에서 메모리 계층에 일부러 오래된 기록을 주거나 쓰기 작업을 누락시켜 보고, 결과가 사용되기 전에 실행이 중단되거나 플래그가 뜨는지 확인하셈. 기대 결과값은 메모리 계층 외부에서 관리하고. 검사기가 고장 난 걸 통과시키면 2주 동안 조용히 잘 돌아갔대도 별 의미가 없음. 일단 테스트가 제대로 작동하면 특정 작업에 대한 수동 검토를 줄이고, 모델이나 내가...