AI 에이전트가 QA를 통과하지만 프로덕션에서 실패하는 이유

연속 학습은 에이전트를 배포 후에도 개선할 수 있는 엔지니어링 기술이 되고 있습니다.

AI 에이전트는 전개 전 평가를 모두 통과했지만 프로덕션에서 일주일 후에 실패할 수 있습니다. 이것은 모순이 아닙니다. 평가 세트는 팀이 전개 전 테스트에 대한 지식을 반영합니다. 프로덕션은 누락된 경우가 나타나는 곳입니다: 이상한 문구, 누락된 컨텍스트, 툴 에지 케이스, 불만족한 사용자, 상반되는 정책 및 워크플로우.

에이전트는 사용자에 의해 지속적으로 수정됩니다. 사용자에게 실망을 줄 수 있습니다. 그런 다음 세션이 종료되고 로그가 저장되며 다음 사용자가 본질적으로 동일한 시스템을 만납니다.

이것이 연속 학습이 에이전트 엔지니어링의 핵심이 되는 이유입니다. 이것은 하나의 제품의 기능이 아닙니다. 에이전트가 경험에서 개선되는 방법의 범주입니다. 클래식적인 연속 학습 연구는 시간이 지남에 따라 학습하는 문제를 정의했습니다. 에이전트가 만들어낸 문제는 더 넓습니다. 변경되는 것은 모델일 수 있지만 툴, 스킬, 워크플로우 또는 메모리일 수도 있습니다.

그 차이가 중요합니다. 대부분의 에이전트 실패는 모델 훈련으로 해결할 수 없습니다.

세부 조정 반사신은 너무 狭い

팀이 AI 시스템을 개선하는 방법에 대해 이야기할 때 기본 계획은 다음과 같습니다: 실패를 수집하고 더 좋은 답변을 레이블링하고 모델을 세부 조정합니다. 그 본능은 이해할 수 있습니다. 지도된 세부 조정, 직접 선호도 최적화, 그룹 상대 정책 최적화 및 파라미터 효율적인 방법들 such as LoRA는 모델 자체가 변경되어야 할 때 유용한 도구입니다.

그러나 많은 프로덕션 실패는 모델 가중치 실패가 아닙니다. 시스템 실패입니다.

에이전트는 구식 메모리에 의존하거나 필수 확인을 건너뛰거나 잘못된 인수를 사용하여 툴을 호출하거나 잘못된 워크플로우를 통해 케이스를 라우팅할 수 있습니다. 문제는 대부분 기본 모델의 능력이 아닙니다. 컨텍스트, 메모리, 툴 인터페이스 또는 워크플로우입니다.

최신 에이전트에는 여러 계층이 있습니다. 모델은 추론하고 생성합니다. 모델을 둘러싼 하네스는 프롬프트, 툴, 스킬, 코드, 라우팅 및 워크플로우를 정의합니다. 메모리는 事実과 학습된 절차를 세션 간에 전달합니다. 연속 학습은 어떤 계층이 변경되어야 하는지, 변경이 얼마나 작을 수 있는지 및 변경이 실제로 도움이 되었는지 결정하는 것입니다.

때때로 올바른 수정은 메모리 작성입니다. 때때로 프롬프트 편집입니다. 때때로 툴 래퍼, 라우팅 규칙 또는 워크플로우 패치입니다. 세부 조정은 여전히 사용할 수 있어야 하지만 모든 실패에 대한 첫 번째答案으로서는 적합하지 않습니다.

벤치마크는 유용하지만 프로덕션에서는 거의 제공되지 않는다

에이전트 하네스를 최적화하는 작업에 대한 흥미로운 연구가 있습니다. GEPA와 Meta-Harness와 같은 방법은 에이전트를 시스템으로 취급하여 변형하고 테스트할 수 있습니다. 프롬프트 또는 워크플로우 최적화 접근 방식과 관련하여 에이전트를 시스템으로 취급하여 변형하고 테스트할 수 있습니다.

그것은 올바른 방향입니다. 그것은 “가중치를 업데이트한다”라는 좁은 프레임에서 벗어나 “에이전트를 개선한다”는 더 넓은 프레임으로 이동합니다.

그러나 한 가지 문제가 있습니다. 이러한 방법은 일반적으로 벤치마크를 가정합니다. 반복적으로 실행할 수 있는 작업과 후보 A가 후보 B보다 낫는지 여부를 말해주는 평가자가 필요합니다. 그 없이 최적화는 더 나은 툴링을 가진 추측이 됩니다.

그것은 대부분의 팀이 프로덕션에서 가지고 있는 것이 아닙니다.

그들이 가지고 있는 것은 로그입니다. 그들은 추적, 사용자 수정, 지원 티켓, 엄지 아래 이벤트, 에스컬레이션 노트 및 때때로 전문가 피드백을 가지고 있습니다. 이러한 신호는 가치があり지만 아직 벤치마크는 아닙니다. 어떤 일이 발생했는지 알려줍니다. 어떻게 재생해야 하는지, 성공이 무엇인지 또는 제안된 수정을 어떻게 점수화해야 하는지 자동으로 알려주지는 않습니다.

그 간격은 जह에서 많은 연속 학습 노력이 중단됩니다. 팀은 경험을 가지고 있지만 아직 학습 환경이 없습니다.

로그는 교훈이 아니다

프로덕션 로그는 상호작용을 통해 하나의 경로를 기록합니다. 사용자가 비행기를 물었습니다. 에이전트가 검색했습니다. 사용자가 날짜가 잘못되었다고 했습니다. 그것은 실패의 증거이지만 학습하기에는 충분하지 않습니다.

로그는 대안을 정의하지 않습니다. 에이전트가 확인을 요청해야 했는지, 이전 컨텍스트에서 날짜를 추론해야 했는지, 다른 툴을 호출해야 했는지, 모호성이 해결될 때까지 진행하지 않아야 했는지 알 수 없습니다. 인간은 추적을 읽은 후에 답을 알 수 있지만 시스템은 그 구조를 무료로 얻지 못합니다.

연속 학습이 작동하려면 원시 실패를 재생할 수 있는 환경으로 전환되어야 합니다. 즉, 에이전트가 다시 직면할 수 있는 작업, 관련 패턴을 재현하는 사용자 또는 시뮬레이터, 에이전트가 호출할 수 있는 툴 및 성공을 정의하는 평가자가 필요합니다. 평가자는 최종 답변, 툴 호출, 정책 경계, 지연, 비용 또는 모든 것을 확인할 수 있습니다.

이것은 실제 개선이 되는 작업의 덜 보이는 부분입니다. 한 번 실패가 재생할 수 있는 환경이 되면 구체적인 질문을 할 수 있습니다. 제안된 변경이 실제로 행동을 수정했는지 여부를.

그 단계 없이 팀은 대부분 메모리에서 패치합니다.

David Silver와 Richard Sutton은 경험의 시대를 묘사했습니다. 여기서 에이전트는 정적인 인간 데이터보다 세계와의 상호작용에서 주로 학습합니다. 기업 에이전트의 경우 그 비전은 메시한 프로덕션 경험을 재생할 수 있는 환경, 점수할 수 있는 환경 및 재사용할 수 있는 환경으로 만드는 것입니다.

경험만으로는 충분하지 않습니다. 테스트할 수 있어야 합니다.

회귀는 숨겨진 비용이다

실패가 테스트할 수 있는 환경이 되더라도 가장 어려운 부분은 여전히 남아 있습니다. 그것을 고치지 않고 다른 것을 고장시키지 않는 것입니다.

복잡한 에이전트를 유지보수한 사람은이 패턴을 보았을 것입니다. 공격적인 환불 요청을 에스컬레이션하기 위해 지침을 추가합니다. 이제 빠르게 처리되어야 하는 정상 환불도 에스컬레이션합니다. 한 워크플로우에서 툴 호출을 줄입니다. 이제 다른 워크플로우에서 필수 확인을 건너뛰게 됩니다. 구식 메모리를 수정합니다. 이제 에이전트는 다른 제품 라인에 대한 수정을过度 일반화합니다.

각 패치는 지역적으로 의미가 있습니다. 시스템은 여전히 전역적으로漂います.

이것은 에이전트 버전의 災難적인忘却입니다. 신경망에서 이 용어는 일반적으로 새로운 훈련이 이전 능력을 덮어쓰는 것을 의미합니다. 에이전트에서는 실패가 더 넓고 종종 더 어려워서 보입니다.忘却은 프롬프트, 툴, 메모리, 라우팅 및 워크플로우에서 발생할 수 있습니다. 그것은 깨끗한 지표가 트레이닝 곡선에 나타나지 않고 사용자가 “이것은 이전에 작동했습니다”라고 말할 때 나타납니다.

회귀 제어는 최종 검토 단계가 될 수 없습니다. 그것은 학습 루프 자체 안에 있어야 합니다.

목표는最新의 실패에서 성능을 최대화하는 것이 아닙니다. 목표는새로운 경우를 개선하면서 이전 경우도 보존하는 것입니다. 작동하는 모든 수정은 에이전트의 증가하는 메모리의 일부가 되어야 합니다. 구체적으로, 이전 실패는 회귀 테스트가 됩니다. 에이전트의 기록은 제약이 아닌 아카이브가 됩니다.

이것은 연속 학습이 진지한 소프트웨어 엔지니어링보다 프롬프트 조작에 더 가까워지는 곳입니다. 변경은 더 나아 보이기 때문에 좋지 않습니다. 측정된 행동을 개선하고 시스템이 이미 얻은 행동을 회귀시키지 않기 때문에 좋습니다.

실제 연속 학습이 요구하는 것

프로덕션 준비 연속 학습 루프에는 네 가지 속성이 필요합니다.

첫째, 실패는 재생할 수 있어야 합니다. 일회적인 실패는 일화입니다. 재생할 수 있는 환경은 테스트입니다. 에이전트가 동일한 패턴을 다시 마주칠 때까지 누구도 수정이 작동했는지 증명할 수 없습니다.

둘째, 진단은 전체적으로 이루어져야 합니다. 수정은 모델에 속할 수 있지만 메모리, 프롬프트, 툴 계층 또는 워크플로우에 속할 수도 있습니다. 최고의 수정은 일반적으로 실패를 설명하는 가장 작은 지속 가능한 변경입니다.

셋째, 학습은 일생 동안 지속되어야 합니다. 에이전트는 이번 주에 개선되어야 하며 지난 주에 얻은 행동을 조용히 취소해서는 안 됩니다. 이전의 성공은 최적화 중에 제약이 되어야 하며 배포 후에는驚き가 되어서는 안 됩니다.

넷째, 루프는 효율적이어야 합니다. 모든 개선이 분기별 재훈련 프로젝트를 필요로 한다면 시스템은 프로덕션을 따라가지 못할 것입니다. 루프는 저렴한 수정을 먼저 시도하고 필요할 때만 에스컬레이션해야 하며 확인을 변경에 가깝게 유지해야 합니다.

이것은 에이전트가 스스로를盲目적으로 업데이트하지 않도록 의미합니다. 반대로 의미합니다. 개선은 측정할 수 있어야 합니다. 모든 변경에는 테스트, 전후 점수 및 회귀 확인이 있어야 합니다.

그것이 연속 학습을 모호한願望에서 엔지니어링 기술로 전환하는 것입니다.

에이전트의 미래는 더 큰 컨텍스트 창, 더 강력한 기본 모델 또는 더 많은 툴로만 정의되지 않을 것입니다. 그것은 중요할 것입니다. 그러나 기업에게 더 중요한 질문은 배포 후에 무엇이 발생하는지입니다.

에이전트가 내일 실패할 때, 시스템이 그 실패를 테스트로 전환할 수 있습니까? 수정을 올바른 계층으로 라우팅할 수 있습니까? 수정이 도움이 되었음을 증명할 수 있습니까? 다른 것이 깨지지 않았음을 증명할 수 있습니까?

그答案이 否라면 에이전트는 실제로 프로덕션에서 학습하지 못합니다. 그것은 위험을 축적합니다.

중요한 에이전트는 다음에 더 나은 것을 할 것입니다. 그것은 복합할 것입니다.