Netflix/머신러닝

5 개의 포스트

netflix4분 읽기큐레이션 요약

콘텐츠 출시의 위험 예측: 데이터 기반 인사이트가 출시 계획을 혁신하는 방법

넷플릭스는 콘텐츠 출시 준비 과정에서 수작업으로 입력된 미디어 전달 일정이 자주 부정확하거나 누락된다는 문제를 발견했습니다. 이에 제작 진행 데이터와 메타데이터를 활용한 머신러닝 모델로 Locked Cut과 최종 IMF 전달까지 남은 일수를 예측하고, 출시 지연 위험을 줄이려 합니다. 백테스트 결과 예측 일정은 수작업 일정에 비해 정확도와 제공 범위가 높았으며, 출시 직전 일정 오차와 출시 지연 사이의 상관관계도 완화했습니다. ## 콘텐츠 출시 준비와 일정 리스크 - 넷플릭스 콘텐츠는 개발, 프리프로덕션, 제작, 후반작업, 출시 준비 단계를 거쳐 공개됩니다. - 후반작업이 끝나면 최종 오디오·비디오 파일인 IMF가 전달되고, 이를 기반으로 다음 작업이 진행됩니다. - 아트워크와 예고편 제작 - 자막 생성 - 관람등급 지정 - 품질관리(QC) - 일부 작업은 최종본이 아닌 Locked Cut으로 미리 시작할 수 있습니다. - 다만 Locked Cut 이후 IMF가 크게 변경되면 추가 conformance 작업이 필요합니다. - IMF를 기다리면 일정이 압축될 수 있고, Locked Cut으로 일찍 시작하면 수정 비용이 발생하는 트레이드오프가 존재합니다. ## 수작업 일정의 한계 - 콘텐츠 파트너가 제작 일정에 Locked Cut과 IMF의 예상 전달일을 수동으로 입력합니다. - 실제 제작은 일정 변경, 인력·장비 충돌, 예기치 못한 문제 등으로 지속적으로 변동됩니다. - 그 결과 다음 문제가 발생합니다. - 일부 콘텐츠에는 예상 전달일 자체가 없음 - 기존 예상일이 실제 전달일과 크게 다름 - 출시 준비팀이 언제 작업을 시작해야 할지 판단하기 어려움 - 넷플릭스는 축적된 제작 데이터를 활용해 일정 누락을 보완하고 예상일의 정확도를 높이려 했습니다. ## 일정 오차와 출시 지연의 관계 - 일정 부정확성을 측정하기 위해 **Accumulated Error Days(AED)**라는 지표를 만들었습니다. - AED는 예상 전달일과 실제 전달일 사이의 편차를 시간에 따라 누적한 값으로, 두 일정 곡선 사이의 면적에 해당합니다. - 출시 지연이 발생한 콘텐츠는 지연이 없는 콘텐츠보다 평균 AED가 유의미하게 높았습니다. - 특히 전달일에 가까운 마지막 기간의 AED가 출시 지연과 더 강한 상관관계를 보였습니다. - 따라서 장기적인 평균 오차뿐 아니라 출시 직전 일정이 얼마나 정확한지가 출시 리스크 관리에 중요합니다. ## 머신러닝 기반 전달일 예측 - 예측 모델은 부스티드 트리 회귀 모델로, 진행 중인 제작물에 대해 IMF 또는 Locked Cut 전달까지 남은 일수를 예측합니다. - 다음과 같은 데이터를 입력값으로 활용합니다. - 제작 진행 상황과 관련된 운영 신호 - 콘텐츠 및 타이틀 메타데이터 - 계절성 신호 - 제작 과정의 매일 업데이트된 스냅샷 데이터를 사용해, 각 날짜 시점의 제작 상태를 모델링합니다. - 이 방식의 장점은 다음과 같습니다. - 새로운 정보가 들어올 때마다 최신 예측 생성 - 제작 단계가 달라도 적용 가능한 유연한 모델 구축 - 시간에 따라 변하는 동적 특성 반영 - 수작업 일정이 없는 콘텐츠에도 항상 예측일 제공 ## 종합적인 모델 평가 지표 - 실제 전달일과 비교해 예측일의 정확도를 평가하기 위해 여러 지표를 사용했습니다. - 평균·중앙값 절대 오차(MAE 등) - 평균·중앙값 오차를 통한 과대·과소 예측 편향 - 오차 표준편차를 통한 예측 분포의 변동성 - 전달일까지 일정 기간 이상 차이 나는 큰 오차의 비율 - 수작업 일정은 전달일까지 남은 기간별로 일정이 존재하는 콘텐츠의 비율인 coverage도 측정했습니다. - 예측 모델은 항상 날짜를 제공하도록 설계되어 수작업 일정의 공백을 보완할 수 있습니다. ## 수작업 일정 대비 개선 효과 - 백테스트에서 예측 일정은 대부분의 전달 시점과 평가 지표에서 수작업 일정보다 우수했습니다. - IMF와 Locked Cut 모두에서 평균 절대 오차가 크게 감소했습니다. - 큰 오차나 이상치도 수작업 일정에서 예측 일정으로 전환했을 때 줄어들었습니다. - 예측 모델은 단순히 최종 시점의 정확도를 높이는 것뿐 아니라 더 일찍 유용한 신호를 제공합니다. - Locked Cut 전달 6개월 전부터 예측일이 수작업 일정보다 정확했던 콘텐츠 비율은 76%였습니다. - 예측 일정의 MAE는 6.1주였으며, 수작업 일정이 같은 수준에 도달하려면 전달 11주 전까지 기다려야 했습니다. - AED를 6개월 또는 더 짧은 기간에 걸쳐 계산했을 때도 예측 IMF·Locked Cut 일정이 수작업 일정 대비 AED를 낮췄습니다. - 이러한 효과는 여러 구매 조직과 콘텐츠 유형, 즉 시리즈와 단편 콘텐츠 전반에서 대체로 나타났습니다. ## 기존 업무 흐름에 예측 일정 적용 - 전달 예상일은 이미 관련 팀의 업무 과정에 포함되어 있기 때문에, 예측 날짜를 도입해도 기존 프로세스를 전면 개편할 필요가 없습니다. - 다만 수작업 일정과 예측 일정이 동시에 존재하면 어느 쪽을 더 신뢰할지 판단해야 합니다. - 예측 일정이 평균적으로 더 정확하더라도 모든 상황에서 수작업 일정을 능가하는 것은 아니므로, 두 일정의 신뢰도를 비교하고 상황별로 선택하는 운영 체계가 필요합니다. - 제공된 글은 이 문제를 해결하기 위한 후속 방식 설명 중간에서 끝나 있어, 최종 의사결정 규칙이나 운영 정책은 확인할 수 없습니다. 실무적으로는 예측일을 기존 일정의 대체재라기보다, 누락된 일정을 보완하고 위험 신호를 조기에 제공하는 계층으로 도입하는 것이 적절합니다. 특히 출시 직전 AED와 일정 오차를 지속적으로 모니터링하면 출시 지연 가능성이 높은 콘텐츠에 우선 대응할 수 있습니다.

원문 읽기(새 탭에서 열림)
netflix4분 읽기큐레이션 요약

넷플릭스에서 머신러닝의 민주화: 모델 수명 주기 그래프 구축

Netflix는 ML 자산이 개인화, 스튜디오, 결제, 광고 등 여러 영역으로 확장되면서 모델과 데이터가 각기 다른 시스템에 고립되는 문제를 겪었다. 이를 해결하기 위해 다양한 ML 메타데이터를 통합하는 Metadata Service(MDS)와 Model Lifecycle Graph를 구축했다. MDS는 모델·피처·파이프라인·실험·데이터셋 등의 관계를 연결해 자산의 발견, 계보 추적, 영향 분석, 재사용을 가능하게 하는 기반이다. ## ML 생태계의 확장과 사일로 문제 - Netflix의 ML 활용 영역은 개인화 중심에서 다음과 같이 확대됐다. - 콘텐츠 추천과 사용자 참여 최적화 - 스튜디오의 제작 전후 작업 - 사기 탐지, 결제 라우팅, 정기 결제 최적화 - 광고 타기팅과 실시간 의사결정 - 각 도메인은 서로 다른 기술 스택, 비즈니스 지표, 조직 구조를 사용한다. - 그 결과 모델이 블랙박스처럼 고립되고, 다른 팀이 기존 모델과 데이터를 발견하거나 재사용하기 어려워졌다. - 예를 들어 스튜디오에서 만든 콘텐츠 임베딩은 장면 전환과 콘텐츠 구조를 분석하지만, 광고의 문맥 매칭이나 개인화 추천에도 활용될 수 있다. - 그러나 모델 레지스트리, 파이프라인 오케스트레이터, 실험 플랫폼이 분리되어 있어 다음 질문에 답하기 어렵다. - 어떤 피처와 데이터 소스가 존재하는가? - 특정 모델은 어떤 파이프라인과 데이터로 생성되는가? - 해당 모델을 사용하는 A/B 테스트는 무엇인가? - 피처를 변경하면 어떤 모델이 영향을 받는가? - 각 자산의 담당자는 누구인가? ## 통합 UI보다 어려운 메타데이터 연결 - 문제의 본질은 화면을 하나로 합치는 것이 아니라, ML 라이프사이클의 서로 다른 구성 요소를 연결하는 것이다. - Netflix에는 다음과 같은 시스템이 각각 메타데이터를 생성한다. - 파이프라인 오케스트레이션: 실행 정보, 단계 의존성, 데이터 변환 - 모델 레지스트리: 모델 버전, 아티팩트, 오래된 모델 여부, 배포 이력 - 실험 플랫폼: A/B 테스트와 설정 - 피처 스토어: 피처 정의와 사용처 - AI Dataset 플랫폼: 데이터셋 생성, 관리, 검색, 로딩 - Identity 플랫폼: 사용자, 팀, 조직 정보 - 시스템마다 데이터 형식, 식별자, 개념 모델이 다르기 때문에 이질적인 메타데이터를 하나의 엔터티 모델로 변환하고 관계 그래프로 만드는 작업이 핵심 기술 과제가 됐다. ## Metadata Service와 Model Lifecycle Graph - MDS는 Netflix 전반의 ML 관련 엔터티를 색인하고 서로 연결하는 서비스다. - 모델, 피처, 파이프라인, 실험, 데이터셋 등의 메타데이터를 실시간으로 수집한다. - 다음과 같은 교차 도메인 질의를 지원하는 것을 목표로 한다. - 특정 모델을 실행 중인 실험은 무엇인가? - 특정 피처를 공유하는 모델은 무엇인가? - 모델에 사용된 데이터와 생성 파이프라인은 무엇인가? - MDS의 역할은 다음과 같다. - 여러 시스템에서 이벤트 수집 - 메타데이터에 조직·소유자 등 추가 맥락 결합 - ML 자산 간 관계 추론 및 구체화 - 연결된 그래프 형태로 탐색 가능하게 제공 - 궁극적인 목표는 모든 ML 자산을 팀과 도메인에 관계없이 발견하고, 이해하고, 재사용할 수 있도록 만드는 것이다. ## URI 기반 핵심 추상화 MDS는 시스템 간 일관된 연결을 위해 AI Platform URI를 사용한다. - **Component** - 고유한 URI로 주소 지정할 수 있는 모든 객체다. - 형식은 다음과 같다. ```text aip://<componentType>/<platformId>/<resourceId> ``` - 예: ```text aip://model/registry/ranking-v5 aip://user/identity/alice aip://pipeline/orchestrator/weekly-training ``` - **Entity** - 이름, 설명, 생성일, 소유자 등 추가 속성을 가진 ML 생태계의 구성 요소다. - 모델, 피처, 파이프라인 등이 이에 해당한다. - **Entity Type** - 동일한 데이터 구조와 속성·관계 제약을 공유하는 엔터티 집합이다. - **Domain** - 관련 엔터티 타입을 묶고 해당 ML 자산 범주의 추상 인터페이스를 정의한다. - 예를 들어 Models 도메인은 Model과 Model Instance를, Pipelines 도메인은 Schedule·Request·Execution을 정의한다. - **Provider** - 도메인을 실제로 구현하는 특정 소스 시스템이다. - 하나의 도메인에 여러 Provider를 연결할 수 있어, 모델 레지스트리가 교체되더라도 도메인 인터페이스를 변경하지 않고 확장할 수 있다. - URI는 서비스 간 ML 자산 참조를 단일 문자열로 통일하고, MDS가 이를 풍부한 메타데이터와 연결된 관계로 해석할 수 있게 한다. ## 이벤트에서 엔터티와 그래프로 - MDS는 Kafka와 AWS SNS/SQS를 통해 소스 시스템의 이벤트를 실시간으로 수집한다. - 소스 시스템은 식별자와 이벤트 유형 중심의 얇은 이벤트를 발행한다. - 예시는 다음과 같다. ```json { "event_type": "model_instance_created", "instance_id": "ranking-model-v5-20XX0101" } ``` - 생산 시스템은 복잡한 그래프 로직을 알 필요 없이 간단한 이벤트만 발행하고, MDS가 이를 엔터티로 변환하고 다른 시스템의 정보와 결합한다. - 이후 모델, 파이프라인, 피처, A/B 테스트 등의 관계를 추론해 질의 가능한 Model Lifecycle Graph로 materialize한다. - 이를 통해 모델 생성 이벤트와 실험 설정을 연결하는 것처럼, 서로 다른 시스템에 존재하는 관계도 하나의 그래프에서 탐색할 수 있다. MDS와 Model Lifecycle Graph는 단순한 모델 카탈로그가 아니라, ML 자산의 생성부터 배포·실험·재사용까지를 연결하는 메타데이터 인프라다. 여러 팀이 공통 URI와 엔터티 모델을 사용하도록 만들면 모델의 검색성, 의존성 파악, 변경 영향 분석, 조직 간 재사용이 크게 향상된다.

원문 읽기(새 탭에서 열림)
netflix원문

모델 서빙의 라우팅 현황 (새 탭에서 열림)

넷플릭스는 대규모 개인화 경험을 제공하기 위해 수백 개의 모델과 초당 100만 건의 요청을 처리하는 중앙 집중식 머신러닝(ML) 모델 서빙 플랫폼을 운영하고 있습니다. 이 플랫폼은 'Switchboard'라는 라우팅 계층을 통해 클라이언트 마이크로서비스와 복잡한 ML 모델 인프라를 분리하여, 클라이언트의 수정 없이도 새로운 모델을 신속하게 실험하고 배포할 수 있는 환경을 구축했습니다. 이를 통해 넷플릭스는 모델 추론뿐만 아니라 데이터 전처리 및 특징 추출을 포함한 전체 워크플로우를 표준화된 API로 추상화하여 혁신의 속도를 높이고 있습니다. ### 넷플릭스의 워크플로우 중심 모델 정의 * 넷플릭스에서 모델은 단순한 추론 함수(`score(features)`)를 넘어, 입력 데이터 변환, 특징(feature) 계산, 추론, 후처리를 모두 포함하는 독립적인 '워크플로우'로 정의됩니다. * 클라이언트는 사용자 ID나 국가와 같은 최소한의 컨텍스트만 제공하며, 모델 서빙 플랫폼이 필요한 데이터를 다른 마이크로서비스에서 가져와 직접 특징을 계산합니다. * 이러한 구조 덕분에 클라이언트는 모델의 내부 로직이나 데이터 의존성을 알 필요가 없으며, 모델의 아키텍처가 변하더라도 클라이언트 코드를 수정할 필요가 없습니다. ### 중앙 집중형 라우팅 엔진, Switchboard * 넷플릭스는 표준 API 게이트웨이나 서비스 메시가 제공하지 못하는 실험 플랫폼과의 통합, gRPC 지원, 도메인 특화 라우팅을 구현하기 위해 자체 프록시 서비스인 'Switchboard'를 개발했습니다. * Switchboard는 클라이언트 요청을 적절한 모델 인스턴스와 클러스터 샤드로 전달하는 역할을 수행하며, 초당 100만 건 이상의 요청을 처리하면서도 높은 가용성을 유지합니다. * 모델 배포 시 섀도 모드(Shadow mode), 카나리 배포(Canary), 롤백 등을 클라이언트 모르게 수행할 수 있어 안전한 운영이 가능합니다. ### 인프라 복잡성을 감추는 모델 샤딩 분리 * 모델은 트래픽 패턴, SLA, CPU/메모리 요구사항에 따라 여러 연산 클러스터 샤드(VIP 주소)에 분산 배치됩니다. * 서빙 플랫폼은 이러한 물리적 배치 상태를 클라이언트로부터 은폐하여, 인프라의 변경이나 모델의 샤드 이동이 클라이언트 서비스에 영향을 주지 않도록 설계되었습니다. * 이를 통해 ML 연구자는 인프라 제약 없이 자유롭게 실험을 설계하고 모델을 배포할 수 있습니다. ### 'Objective' 기반의 추상화 계층 * 플랫폼은 'Objective'라는 열거형(Enum) 단위를 통해 모든 요청을 관리하며, 이는 비즈니스 목적(예: 콘텐츠 추천, 결제 사기 탐지)을 나타냅니다. * Objective는 요청이 전달될 특정 서빙 클러스터와 모델 유형/버전을 결정하는 기준이 됩니다. * 또한, 각 Objective는 고유한 API 규격을 정의하여 서로 다른 도메인의 클라이언트가 동일한 방식으로 플랫폼과 통신할 수 있도록 표준화합니다. 성공적인 대규모 ML 시스템을 구축하려면 모델의 생명주기를 클라이언트 애플리케이션으로부터 완전히 격리해야 합니다. 넷플릭스의 사례처럼 워크플로우 단위의 모델 정의와 'Objective' 중심의 라우팅 추상화를 도입함으로써, 인프라의 복잡성을 관리하면서도 머신러닝 혁신의 속도를 극대화할 수 있습니다.

netflix원문

넷플릭스의 Meta (새 탭에서 열림)

넷플릭스는 머신러닝(ML) 및 AI 워크플로우의 프로토타이핑부터 프로덕션 운영까지의 전 과정을 효율화하기 위해 오픈소스 프레임워크인 메타플로우(Metaflow)를 지속적으로 발전시켜 왔습니다. 특히 최신 업데이트인 Metaflow 2.19 버전에서는 'Spin'이라는 기능을 도입하여, 대규모 데이터와 모델을 다루는 ML 개발 과정에서 필수적인 빠른 반복 시도(Iterative development)와 상태 유지(Stateful iteration)를 획기적으로 가속화했습니다. 이를 통해 개발자는 코드 변경 사항을 즉각적으로 확인하면서도 운영 환경의 안정성을 동시에 확보할 수 있습니다. **ML 및 AI 워크플로우에서의 반복 개발 특성** * **데이터와 모델 중심의 반복:** 전통적인 소프트웨어 공학의 코드 중심 개발과 달리, ML/AI 개발은 크기가 크고 가변적인 데이터 및 모델을 중심으로 이루어집니다. * **비결정적 과정:** 데이터 변환이나 모델 학습은 실행 시마다 결과가 조금씩 달라지는 확률적 특성을 가지며, 연산 비용이 매우 높습니다. * **노트북의 장점과 한계:** 주피터(Jupyter)와 같은 노트북 도구는 메모리에 상태를 유지하여 빠른 피드백을 주지만, 실행 순서의 불명확성, 숨겨진 상태 문제, 재현성 부족 등의 고질적인 문제를 안고 있습니다. **메타플로우의 체크포인트 기반 상태 관리** * **@step을 통한 체크포인트 설정:** 메타플로우의 각 단계(`@step`)는 체크포인트 경계 역할을 수행하며, 단계가 종료될 때 모든 인스턴스 변수를 아티팩트(Artifact)로 자동 저장합니다. * **Resume 기능의 활용:** 기존의 `resume` 명령어를 사용하면 특정 단계부터 실행을 재개할 수 있어, 실패한 지점이나 수정이 필요한 지점부터 다시 시작할 수 있습니다. * **노트북 방식과의 차별점:** 실행 순서가 명시적이고 결정적이며, 모든 상태가 버전화되어 저장되므로 결과의 추적과 재현이 매우 용이합니다. **Spin: 반복 개발 속도의 극대화** * **지연 시간 단축:** 기존의 `resume` 방식은 특정 단계부터 전체를 다시 실행해야 하므로 반복 주기 사이에 일정 수준의 지연(Latency)이 발생했습니다. * **점진적 실험의 가속화:** 새로운 'Spin' 기능은 이러한 지연을 최소화하여 노트북 수준의 즉각적인 피드백을 제공하면서도 메타플로우의 견고한 상태 관리 기능을 그대로 활용합니다. * **워크플로우 엔진과의 통합:** 메타플로우는 넷플릭스의 워크플로우 오케스트레이터인 마에스트로(Maestro)와 긴밀하게 연동되어, 개발 환경에서 테스트한 로직을 프로덕션 규모로 확장하는 데 소요되는 오버헤드를 최소화합니다. 데이터 과학자와 엔지니어는 Metaflow 2.19 버전을 통해 Spin 기능을 직접 체험해 볼 수 있습니다. 실험적인 탐색 단계에서는 노트북처럼 빠른 속도를 누리고, 배포 단계에서는 엔지니어링 표준을 준수하는 견고한 파이프라인을 구축하고자 한다면 메타플로우의 새로운 반복 개발 워크플로우를 도입해 보길 권장합니다.

netflix원문

훈련 후 생성 추천 시스템: 장점 가중치 감독 세부 조정 | 넷플릭스 기술 블로그 | 넷플릭스 테크블로그 (새 탭에서 열림)

넷플릭스는 사용자 행동을 순차적으로 예측하는 생성형 추천 시스템(Generative Recommenders)의 성능을 한 단계 높이기 위해 사후 학습(Post-training) 기술인 '가중치 적용 지도 미세 조정(Advantage-Weighted Supervised Finetuning, 이하 A-SFT)'을 도입했습니다. 기존의 생성형 추천 모델은 단순히 과거의 시퀀스를 모방하는 데 그쳐 실제 사용자 만족도를 충분히 반영하지 못했으나, A-SFT는 노이즈가 많은 추천 환경의 보상 신호를 효과적으로 학습에 활용합니다. 이 방법론은 반사실적 데이터(Counterfactual feedback) 확보가 어려운 추천 시스템의 한계를 극복하고, 보상 모델의 불확실성 속에서도 모델을 사용자 선호도에 더 정교하게 정렬시키는 결론을 도출했습니다. **생성형 추천 시스템의 한계와 사후 학습의 필요성** * 생성형 추천 모델(GR)은 트랜스포머 아키텍처를 활용해 사용자의 다음 활동을 예측하는 순차적 변환 태스크로 추천 문제를 정의합니다. * 단순히 관찰된 과거 행동을 모방하는 방식은 트렌드나 외부 요인에 의한 상호작용을 구분하지 못하며, 사용자가 실제로 만족하지 않은 콘텐츠를 반복 추천할 위험이 있습니다. * 따라서 시청 시간, 클릭률, 평점 등 명시적·암묵적 피드백을 활용해 모델을 사용자 선호에 맞게 조정하는 사후 학습 과정이 필수적입니다. **추천 시스템 사후 학습의 주요 난제** * **반사실적 피드백의 부재:** LLM과 달리 추천 시스템은 사용자가 실제로 경험한 온-폴리시(On-policy) 데이터만 존재하며, 수주에서 수년에 걸친 사용자 시퀀스에 대해 가상의 시나리오에 대한 피드백을 얻는 것은 불가능에 가깝습니다. * **보상 신호의 높은 노이즈:** 시청 시간이 길다고 해서 반드시 만족도가 높은 것은 아니며(시간 제약 등으로 중단 가능), 보상 모델 자체가 높은 불확실성과 분산을 가집니다. * **기존 기법의 적용 한계:** 반사실적 데이터를 요구하는 PPO(근사 정책 최적화)나 DPO(직접 선호도 최적화) 같은 최신 LLM 최적화 기법을 추천 도메인에 그대로 적용하기 어렵습니다. **A-SFT: 불확실한 보상을 활용하는 최적화 전략** * A-SFT는 지도 미세 조정(SFT)의 안정성과 강화 학습의 이점 함수(Advantage function)를 결합하여 보상 모델의 방향성 신호를 학습에 반영합니다. * 보상 모델이 높은 분산을 가질 때에도 보상 자체에 매몰되지 않고, 이점 함수를 통해 상대적으로 더 나은 행동에 가중치를 두어 학습함으로써 성능 저하를 방지합니다. * 이 방식은 보상 모델이 없을 때 사용하는 '행동 복제(Behavior Cloning)'와 완벽한 보상 모델을 전제로 하는 '온라인 강화 학습' 사이의 적정 지점을 찾아내어 모델 성능을 최적화합니다. **실무적 권장 사항** 추천 시스템의 사후 학습 전략을 선택할 때는 보상 모델의 품질과 일반화 능력을 먼저 고려해야 합니다. 보상 모델의 노이즈가 심할 경우 이를 과도하게 최적화하면 오히려 성능이 하락할 수 있으므로, A-SFT와 같이 보상의 방향성을 활용하면서도 학습의 안정성을 유지할 수 있는 가중치 기반의 접근법을 사용하는 것이 권장됩니다. 이는 특히 실제 서비스 데이터와 같이 피드백이 불완전한 환경에서 생성형 모델을 사용자 가치에 정렬시키는 데 매우 효과적인 도구가 될 수 있습니다.