프롬프트나 모델 변경 후 예전 에이전트 오류가 재발하지 않게 하려면 어떻게 하나요?

저희가 딱 그걸 만들고 있습니다. TAQ라고 부르는데, 실패한 실행 기록을 다시 돌려볼 수 있는 회귀 테스트로 만들어서 프롬프트나 모델을 바꿀 때마다 배포 전에 그 테스트 뱅크를 돌리는 방식이죠. 아직 초기 단계지만 핵심 워크플로우는 말씀하신 그대로입니다. 저희가 만든 걸 보여드리고 어디가 잘못됐는지 의견을 듣고 싶네요.

따로 테스트해야 한다는 점은 저희도 고민하던 부분입니다. 프롬프트 변경과 모델 변경을 한꺼번에 테스트하면 개별적으로는 나타날 실패가 서로 상쇄되면서 가려질 수 있거든요. 에러가 서로 퉁쳐져서 잘못된 통과가 나오는 거죠. 픽스처 방식이 정답인데, 어려운 점은 누군가 일일이 기억해서 추가하게 하는 게 아니라 자동으로 캡처되게 만드는 겁니다. 저희가 그 워크플로우를 구축 중입니다.

저희 팀 외부에서 본 것 중 가장 명확한 데이터 모델 분석이네요. 특히 '금지 동작' 필드가 핵심입니다. 대부분의 팀은 에이전트가 뭘 해야 하는지만 정의하지, 절대 하면 안 되는 건 정의하지 않거든요. 그 빈틈에서 정책 회귀가 눈치채지 못하게 발생하는 겁니다. 저희가 딱 이 워크플로우를 만들고 있어요. 트레이스, 도구 호출, 중간 상태를 포함한 전체 실행 기록을 캡처해서 구조화된 테스트 케이스로 저장하고, 프롬프트나 모델, 도구 변경 시마다 버전별로 다시 돌려보는 거죠.

필터링된 로그 문제는 이게 왜 잡기 힘든지를 정확히 보여줌. 실패 사례들이 노이즈에 묻히면 팀은 더 이상 확인을 안 하고 그냥 괜찮겠거니 생각하게 됨. 그걸 제대로 된 기록으로 바꾸는 게 맞는 방향이긴 한데, 여전히 빠진 부분은 배포 전에 새 버전에 대고 그 기록들을 다시 돌려보는(replay) 과정임. 우리가 만들고 있는 게 바로 그 루프를 완성하는 거임.

자동화된 테스트나 로그 재실행을 사용해서 회귀를 잡고, 프롬프트와 모델을 버전 관리해서 변경 사항이 예전 실패를 다시 불러오지 않게 하세요.

프롬프트랑 모델을 리플레이 로그랑 같이 버전 관리하는 게 핵심임. 우리가 계속 보는 문제점은 팀들이 버전 관리는 하는데 루프를 닫질 않는다는 거임. 배포 전에 실제 실패 사례들을 새 버전에 돌려보는 리플레이 단계가 빠져있음. 우리가 만들고 있는 게 바로 그거임. 실제 실패 사례 자동 캡처랑 배포 전 버전별 리플레이. 지금 SDK 작업 중이고 테스트 기다리는 사람들도 있음.

에이전트 회귀 테스트는 소프트웨어 테스트랑 본질적으로 똑같은데, 그냥 좀 더 지저분할 뿐임. 실패 사례들을 데이터베이스에 저장해두고 프롬프트나 모델 바꿀 때마다 돌려봐야 함. 기준점(baseline)이랑 비교하는 간단한 스크립트만 있어도 조용히 발생하는 회귀 오류들 많이 잡을 수 있음. 나도 예전 실패 사례들을 레드팀 테스트에 돌려봤는데, 미처 생각지도 못한 회귀 오류들을 찾아냈음.