에이전트 데모는 잘 작동합니다. 그것이 함정입니다.
저는 기업들을 위해 AI 에이전트를 구축합니다. 자주 반복되는 패턴을 목격하곤 합니다. 데모에서는 모델이 잘 작동합니다. 제품을 출시합니다. 그런데 실제 운영 환경(production)에서는 세 번 중 한 번꼴로 실패합니다. 아무도 그 이유를 모릅니다.
데모와 운영 환경 사이의 간극은 수학의 문제입니다. 수학을 이해하고 나면, 구축 방식이 달라집니다.
에이전트의 각 단계가 95%의 신뢰도를 가진다면 괜찮게 들릴 것입니다. 하지만 에이전트는 단계들을 체인(chain)으로 연결하여 사용합니다. 10개의 단계를 연결하면 성공률은 60%로 떨어집니다. 20개의 단계를 사용하면 성공률은 36%로 급락합니다.
실제 업무에서 단계별 오류율은 종종 10%에서 20%에 달합니다. 만약 에이전트가 85%의 신뢰도를 가진 8개의 단계로 구성되어 있다면, 75%의 확률로 실패하게 됩니다.
문제는 모델이 아닙니다. 문제는 누적되는 확률(compounding probability)입니다.
데모는 단 하나의 '해피 패스(happy path)'만을 보여줍니다. 깨끗한 입력값과 짧은 체인을 사용하죠. 하지만 운영 환경은 수백 명의 사용자가 만드는 지저분한 데이터를 사용합니다. 또한 숨겨진 단계들이 포함된 긴 체인을 사용합니다.
에이전트의 실패는 시스템 충돌(crash)처럼 나타나지 않습니다. 조용한 오류처럼 나타납니다.
3단계에서 필드를 잘못 읽습니다. 출력값은 여전히 유효한 JSON처럼 보입니다. 4단계는 그 잘못된 데이터를 바탕으로 추론합니다. 5단계부터 8단계까지는 그 실수를 바탕으로 진행됩니다. 최종 답변은 틀렸지만 그럴듯해 보입니다. 어디서 잘못되었는지 알려주는 에러 로그도 남지 않습니다.
모델이 환각(hallucination)을 일으켰다고 말하는 것을 멈추십시오. 모델은 그저 전달받은 잘못된 데이터를 전달했을 뿐입니다. 당신의 시스템에 3단계의 오류를 잡아낼 체크포인트가 없었을 뿐입니다.
에이전트를 프롬프트로 취급하는 것을 멈추십시오. 시스템으로 취급하기 시작하십시오.
신뢰할 수 있는 에이전트를 구축하려면 다음 규칙을 따르십시오:
에이전트 외부에서 상태(state)를 저장하십시오. 상태를 대화 내용이 아닌 데이터베이스에 저장하십시오. 프로세스가 6단계에서 실패하면 6단계부터 재개할 수 있습니다. 전체 체인을 다시 시작할 필요가 없습니다.
경계(boundaries)에서 검증하십시오. 모든 입력과 출력을 스키마(schema)에 따라 확인하십시오. 오류가 발생하는 단계에서 즉시 잡아내십시오. 이렇게 하면 미스터리한 오류를 복구 가능한 오류로 바꿀 수 있습니다.
사이드 이펙트(side effects)를 멱등(idempotent)하게 만드십시오. 단계가 실패하면 반드시 재시도해야 합니다. 만약 특정 단계에서 이메일을 보내거나 카드로 결제한다면, 멱등성 키(idempotency key)를 사용하십시오. 이는 재시도 중에 중복 작업이 발생하는 것을 방지합니다.
CI에서 평가(evals)를 사용하십시오. 에이전트의 동작은 미세한 조정마다 변합니다. 프롬프트를 수정하면 한 가지 케이스는 해결될지 몰라도 다른 다섯 가지 케이스를 망가뜨릴 수 있습니다. 테스트 세트를 사용하여 이러한 회귀(regression)를 자동으로 잡아내십시오.
데모에서 실제 제품으로 넘어가는 것은 엔지니어링의 영역입니다. 이는 에러 핸들링, 상태 관리, 그리고 관측성(observability)에 관한 문제입니다. 더 나은 프롬프트를 만드는 문제가 아닙니다.
운영 환경에서 에이전트가 불안정하다면, 더 큰 모델을 찾지 마십시오. 체인이 어긋나는 단계를 찾으십시오. 왜 시스템이 그 단계에서 오류를 잡아내지 못했는지 질문하십시오.
Source: https://dev.to/sagar_jain4010/your-agent-demo-works-thats-the-trap-4joc
Optional learning community: https://t.me/GyaanSetuAi