Shopify가 PyTorch와 vLLM으로 지속 학습 루프를 만든 방법

AI 제품은 출시하는 것보다 출시 이후 꾸준히 개선하는 일이 더 어렵다. Shopify는 GraphQL 에이전트를 사례로 PyTorch와 vLLM을 활용한 지속 학습 루프를 소개했다. 이 구조는 운영 환경에서 발생한 실패를 학습 신호로 바꾸고, 최종적으로 모델 가중치에 반영한다. Shopify에 따르면 이 방식은 프런티어 모델보다 높은 품질을 달성하면서 서빙 비용을 96% 절감했다.

먼저 품질을 점수로 정의한다

루프의 출발점은 무엇이 좋은 응답인지 정하는 일이다. Shopify는 제품 요구사항을 완전성, 실행 결과, 응답 품질, 안전성 등의 기준으로 나누고 각 점수에 구체적인 기준점을 부여한다. 이 루브릭은 제품 담당자, 주석자, 평가 모델, 학습 파이프라인이 공유하는 품질 계약이 된다.

평가 데이터는 엄선된 예제만으로 구성해서는 안 된다. 골든 세트는 이미 알고 있는 문제를 점검하는 데 유용하지만, 무작위 운영 트래픽은 팀이 예상하지 못한 실제 실패를 보여준다. Shopify는 두 명의 숙련된 전문가가 무작위 샘플을 블라인드 평가하고 Cohen’s kappa로 일치도를 확인하는 방식을 제안한다. 전문가끼리도 합의하지 못한다면, 모델을 학습시키기 전에 루브릭부터 고쳐야 한다.

평가기를 검증하고 교정한다

루브릭만으로 신뢰할 수 있는 자동 평가기가 만들어지는 것은 아니다. Shopify는 DSPy와 GEPA, Agentic Context Engineering 같은 반성 기반 최적화 기법을 사용해 실패 기록과 자연어 피드백으로 평가기를 개선한다.

평가기는 과거 A/B 테스트와도 비교해야 한다. 실제 제품 지표에서 확인된 성공과 실패의 방향을 평가기가 재현하는지 확인하는 것이다. 특정 행동을 의도적으로 나쁘게 만드는 성능 저하 테스트도 필요하다. 예를 들어 사용자의 목표를 제대로 수행하지 못하게 했을 때 관련 점수만 떨어져야 한다. Shopify는 모든 행동을 하나의 거대한 평가기에 넣기보다, 목적이 분명한 여러 평가기를 사용하는 방식을 선호한다.

가중치보다 먼저 애플리케이션을 개선한다

평가기가 준비되면 즉시 재학습하기보다, 기존 프런티어 모델을 활용한 애플리케이션을 먼저 개선한다. Shopify는 이를 오토리서치 문제로 다룬다. 에이전트가 프롬프트, 도구 정의, 오케스트레이션 코드의 변경을 제안하고, 평가기로 전체 시스템을 측정한 뒤 점수가 좋아진 변경만 남긴다.

실제 동작은 하나의 프롬프트가 아니라 동적 프롬프트 구성, 도구, 제어 루프, 애플리케이션 코드가 함께 만든다. 따라서 프롬프트만 조정하는 것보다 하네스 전체를 실험 대상으로 삼는 편이 효과적이다.

어려운 운영 사례를 모델에 되돌린다

하네스 개선이 정체되면 익명화된 운영 대화에서 평가기가 낮게 판단한 어려운 사례를 추출한다. 여러 추론 모델이 실패 원인을 분석하고, 중재 모델이 이를 하나의 수정 지시로 통합한다. 이 지시를 사용자 발화 앞에 삽입해 대화를 다시 실행한 뒤 결과를 재평가한다.

수정에 성공한 궤적은 지도 미세조정과 강화학습의 데이터가 된다. 여전히 해결되지 않는 사례는 전문가 주석자에게 보내 동일한 루브릭으로 교정한다. 이렇게 운영 지식은 프롬프트, 검색 예제, 라우팅 규칙에만 남지 않고 모델 자체의 가중치로 이동한다.

이 방식이 중요한 이유

이 사례의 핵심은 평가, 하네스 최적화, 어려운 사례 발굴, 사람의 검토, 가중치 업데이트를 하나의 순환 과정으로 연결한 데 있다. PyTorch는 학습 기반을 제공하고 vLLM은 효율적인 서빙을 뒷받침한다. 두 도구가 품질 관리와 데이터 흐름에 결합되면서, 제품 고유의 경험이 일회성 패치가 아니라 누적되는 모델 능력으로 바뀐다.

출처：PyTorch Blog