Amazon SageMaker Multi-Turn RL, 단일 답변을 넘어선 학습으로 전환

Amazon은 10월 23일, 개별 답변을 채점하는 대신 하나의 완전한 작업 전반에 걸쳐 에이전트를 학습시키는 SageMaker 가이드를 공개했다. 여러 상호작용 단계에 걸친 강화학습인 Amazon SageMaker multi-turn RL은 Wordle을 통해 그 실질적 의미를 드러낸다. 핵심 과제는 성공을 정의하고 유용한 피드백을 보존하며 사용자가 실제로 받게 될 행동을 측정하는 쪽으로 옮겨간다.

여기서 비교 대상은 제공된 예시를 모방하도록 모델을 학습시키는 방식인 SageMaker와 지도 미세 조정이다. 시연 예시는 여전히 유용하지만, 어떤 성공 행동을 보여줄지 결정해야 한다. 반면 결과 기반 학습은 개발자에게 서로 다른 시도가 의미 있는 점수를 받을 수 있는 환경을 구축하도록 요구한다.

이 차이는 모델 엔지니어뿐 아니라 애플리케이션 팀에도 부담을 준다. 지원 담당자, 워크플로 소유자 또는 평가자는 성공적인 완료가 무엇을 의미하는지 판단하는 데 참여해야 한다. AWS는 구체적인 구현을 제공하지만, 이를 적용하는 기업은 여전히 점수 규칙이 실제 업무를 반영한다는 근거를 확보해야 한다.

Amazon SageMaker Multi-Turn RL은 완전한 작업을 학습 단위로 만든다

의미 있는 변화는 피드백의 단위다. 하나의 완전한 시도는 앞선 의사결정과 이후 결과를 연결할 수 있다.

AWS는 multi-turn RL walkthrough에서 중간 추론 노력 수준에서 gpt-oss-20b의 홀드아웃 Wordle 해결률이 61%에서 84%로 향상됐다고 밝혔다. 낮은 노력 수준에서는 보고된 개선 폭이 15%에서 69%에 이른다. 이는 독립적인 재현이 여기에서 확인되지 않은 AWS 예시의 자체 보고 결과다.

이 수치는 범위가 제한된 실험을 설명한다. 고객 서비스, 비용 처리, 리서치 또는 코딩에서 동일한 개선이 나타난다는 점을 입증하지는 않는다. 그 의미는 개발자가 검토하고 검증할 수 있는, 작동하는 작업별 학습 경로를 보여준다는 데 있다.

예시적인 지원 워크플로를 생각해 보자. 어시스턴트는 계정을 검토하고, 추가 설명을 요청하고, 문서를 참조한 뒤 문제 해결을 시도할 수 있다. 각 단계에서 공손하게 답변하는 것만으로는 구매자가 문제가 해결됐는지 알 수 없다.

유용한 판단을 포함한 실패 시도에도 같은 구분이 적용된다. 필요한 질문을 하는 일은 단독으로 평가하면 비효율적으로 보일 수 있다. 그러나 전체 상호작용에서 그 질문은 잘못된 조치나 피할 수 있는 에스컬레이션을 막을 수 있다.

결과 기반 피드백은 개발자가 이 관계를 표현할 방법을 제공한다. 모든 행동의 인과적 중요성을 자동으로 식별하지는 않는다. 대신 학습은 여러 시도를 비교하고, 그 시도들이 만들어낸 신호에 따라 모델을 변경한다.

이 때문에 이 예시는 게임이라는 맥락을 넘어 관련성을 갖지만, 이를 일반적인 비즈니스 성과의 증거로 바꾸지는 않는다. 이전 가능한 아이디어는 애플리케이션이 피드백을 생성하는 방식에 관한 것이다. 이전 가능한 결과는 각 도입 팀이 직접 측정해야 한다.

시점도 중요하다. AWS는 10월 22일 serverless training sessions의 정식 출시를 발표했다. 이 광범위한 서비스는 AWS가 기반 컴퓨팅 리소스와 실행을 관리하는 동안 개발자가 학습 로직을 조율할 수 있게 한다.

인접한 두 발표는 이미 학습된 모델을 조정하는 과정인 후학습에 대해 애플리케이션별 제어를 강화하려는 일관된 제품 방향을 가리킨다. 다만 이들은 구분해야 한다. 유연한 학습 세션과 특정 Wordle 워크플로는 서로 관련된 기능이지만 구현 선택지는 다르다.

엔터프라이즈 구매자에게 이는 평가 과정에서 물어야 할 질문을 바꾼다. 모델이 도구를 호출할 수 있는지 묻는 것은 출발점일 뿐이다. 구매자는 피드백, 실패한 행동, 불완전한 정보, 변화하는 조건 이후에 모델이 어떻게 행동하는지도 알아야 한다.

완전한 작업 점수는 조직이 중시하는 결과를 반영한다면 이러한 질문을 정리할 수 있다. 그렇지 않으면 더 효과적인 최적화기는 불완전한 목표를 추구하는 데 더 효과적일 뿐이다.

작업의 중심은 시연 작성에서 성공 정의로 이동한다

예시 응답에 대한 의존도를 줄이면 환경 설계와 결과 측정의 중요성이 커진다.

따라서 SageMaker와 지도 미세 조정의 비교는 피드백 전략의 비교다. 이는 학습 방법의 보편적인 순위가 아니다. 애플리케이션의 서로 다른 부분은 시연, 결과 보상 또는 이들의 조합에서 이점을 얻을 수 있다.

예시 응답은 형식, 어조 또는 필수 순서를 가르칠 수 있다. 조직이 허용 가능한 행동의 모습을 알고 있을 때 유용하다. 여러 경로가 유효하고 올바른 경로가 중간 관찰에 따라 달라질 때는 더 까다로워진다.

결과 점수는 그런 대안을 수용할 수 있다. 하지만 누군가는 여전히 시도가 성공했는지, 어떤 실수가 중요한지, 불완전한 시도를 어떻게 계산할지 결정해야 한다. 정해진 답을 없앤다고 편집적 또는 운영상의 판단까지 없어지는 것은 아니다.

예시적인 비용 처리 워크플로는 이 차이를 보여준다. 완료된 제출 건은 단순한 자동 검사를 통과할 수 있지만 잘못된 분류를 사용하거나 필요한 승인이 누락됐을 수 있다. 제출만 계산하면 다른 곳에서 정리 작업을 만드는 행동에 보상이 주어진다.

더 강력한 평가는 생성된 기록과 필수 조건을 검토한다. 또한 정당한 추가 설명 요청과 불필요한 중단을 구분한다. 이는 Wordle 실험이 입증한 결과가 아니라 제안된 설계 고려 사항이다.

부담은 그런 조건을 이해하는 사람들에게 돌아간다. 애플리케이션 엔지니어는 점수 함수를 구현할 수 있지만, 도메인 소유자는 그 의미를 명시하는 데 참여해야 한다. 이후 평가자는 구현과 의도된 의미가 갈라지는 사례를 찾아야 한다.

이러한 업무 분담은 프로젝트 계획에 영향을 줘야 한다. 컴퓨팅 리소스에 접근할 수 있지만 성공 기준이 불명확한 팀은 학습이 가능하다는 이유만으로 준비된 것이 아니다. 먼저 반복해서 시도하고 일관되게 평가할 수 있는 작업이 필요하다.

반대로 완료 검사가 명확한 좁은 워크플로는 더 다루기 쉬운 출발점이 된다. 팀은 모든 비즈니스 프로세스를 대표한다고 주장하지 않으면서 실패를 검토하고, 가정을 수정하며, 결과를 비교할 수 있다.

문서화도 이 피드백 과정의 일부가 된다. 팀은 작업 정의, 점수 결정, 기각된 대안, 모호한 사례의 예시를 보존해야 한다. 공유된 searchable knowledge base는 이러한 정의가 바뀔 때 검토자에게 공통 참조점을 제공할 수 있다.

실질적인 가치는 의견 충돌을 드러내는 데 있다. 운영팀이 상호작용을 성공으로 판단하지만 컴플라이언스 팀이 이를 받아들일 수 없다고 판단한다면, 학습이 그 사이에서 조용히 선택해서는 안 된다. 그 의견 충돌은 최적화가 시작되기 전에 작업 명세에 반영돼야 한다.

이는 더 작은 작업별 모델이 여전히 경험적으로 검증해야 할 주장인 이유이기도 하다. 적합성은 요구되는 행동, 이용 가능한 피드백, 허용 가능한 실패율에 달려 있다. 학습 파이프라인의 가용성만으로 구매자를 위한 이러한 선택이 결정되지는 않는다.

그 결과 Amazon SageMaker multi-turn RL은 애플리케이션 팀에 또 하나의 적응 옵션을 제공한다. 그 유용성은 평가 과정이 바람직한 완료와 완료된 것처럼 보일 뿐인 결과를 구분할 수 있는지에 달려 있다.

AgentCore는 환경, 데이터셋, 학습 루프를 연결한다

이 예시의 아키텍처는 학습 대상 모델과 그 경험을 생성하는 애플리케이션을 분리한다.

AWS의 Wordle training sample은 게임, 도구, 보상 로직을 호스팅된 실행 환경인 Amazon Bedrock AgentCore runtime에 배치한다. SageMaker는 학습 측면을 관리한다. 에이전트는 시도 중 행동을 선택하는 모델을 뜻하는 정책 모델을 호출한다.

샘플 데이터셋에는 640개의 학습 단어와 별도의 검증 단어 128개가 포함된다. 각 작업에는 지시문, 환경을 위한 숨겨진 답, 식별자가 담긴다. 모델은 답에 직접 접근하지 않고 게임 피드백을 받는다.

저장소에는 로컬 환경 검사, 데이터셋 준비, 배포, 학습, 평가, 정리 구성 요소가 포함된다. 이 프로젝트는 프로덕션 구현이 아닌 데모라고 명시한다. 이를 적용하기로 한 모든 결정에는 이 단서가 함께 고려돼야 한다.

개발자에게 아키텍처적 교훈은 경계에 관한 것이다. 환경에는 모델이 직접 받아서는 안 되는 정보가 필요하다. 올바른 구현은 작업 파싱, 도구 응답, 로깅, 오류 처리 전반에서 이 구분을 유지해야 한다.

비즈니스 사례로는 예상 계정 상태나 비공개 완료 기준을 생각할 수 있다. 평가자는 성공 여부를 판단하기 위해 그 정보가 필요할 수 있다. 이를 에이전트에 노출하면 추론 작업이 답 검색으로 바뀔 수 있다.

따라서 데이터셋 준비는 프롬프트를 수집하는 것 이상을 포함한다. 개발자는 무엇이 작업에 속하는지, 무엇이 환경에 속하는지, 무엇이 비공개로 남아야 하는지 결정해야 한다. 이 결정은 실험의 난이도와 타당성을 모두 좌우한다.

배포는 다른 질문을 제기한다. 즉, 애플리케이션이 하나의 시도를 안정적으로 실행할 수 있는지다. 낮은 보상을 약한 추론으로 해석하기 전에 팀은 요청이 모델에 도달하고 도구 응답이 에이전트에 전달된다는 점을 확인해야 한다.

이 구분이 중요한 이유는 운영 실패와 의사결정 실패에 서로 다른 해결책이 필요하기 때문이다. 인증 문제는 인프라 작업이 필요하다. 에이전트가 부적절한 행동을 선택했다면 행동, 피드백 또는 작업 설계를 조사해야 한다.

AWS의 multi-turn RL documentation은 상호작용, 도구 사용, 복구, 의존적인 의사결정이 포함된 작업을 설명한다. 또한 더 넓은 의미의 에이전트와 기반 모델을 구분한다. 이 용어는 팀이 모든 시스템 실패를 모델 품질 탓으로 돌리지 않도록 돕는다.

학습 방법은 또 다른 경계를 추가한다. GRPO(Group Relative Policy Optimization)는 업데이트를 이끌기 위해 시도 그룹 내 보상을 비교한다. DeepSeekMath research는 수학적 추론 연구에서 GRPO를 도입했으며, 여기서의 사용에 역사적 맥락을 제공한다.

이 비교 메커니즘은 점수 함수의 중요성을 특히 크게 만든다. 유용한 시도와 도움이 되지 않는 시도가 구별되지 않는 점수를 받으면, 피드백은 선호를 정할 근거를 거의 제공하지 못한다. 오해를 부르는 행동이 더 높은 점수를 받으면 최적화는 잘못된 방향을 받는다.

이 아키텍처를 통해 설명하는 SageMaker agent training은 시스템의 이야기다. 데이터셋이 시도를 시작하고, 환경이 관찰값을 제공하며, 모델이 행동을 선택한다. 평가는 학습된 모델을 고립된 산출물로 다루기보다 이들의 상호작용을 검토해야 한다.

보상은 잘못된 종류의 진전을 선호할 수 있다

채점 함수는 에이전트가 예상치 못한 경로를 찾아도 조직의 우선순위를 유지해야 한다.

AWS는 추측 횟수에 따라 보너스를 누적하는 초기 Wordle 보상을 설명한다. 이 방식은 패배한 게임에도 긍정적인 점수를 부여하고, 더 이른 해결보다 더 늦은 해결을 선호할 수 있었다. 수정된 설계는 결과를 우선시하고 보조적인 전략 보상은 제한한다.

이 사례는 일반적인 설계 문제를 보여 준다. 각기 타당해 보이는 지역적 인센티브가 결합되면 바람직하지 않은 전체 선호로 이어질 수 있다. 정보를 수집하는 데 보너스를 주는 것은 합리적으로 들린다. 하지만 적절한 제한이 없다면, 이미 유용한 정보를 얻은 뒤에도 활동을 계속하는 행동에 보상을 줄 수 있다.

예시적인 지원 애플리케이션에서는 각 진단 단계에 보상하는 방식이 이에 해당할 수 있다. 어시스턴트는 문제를 신속히 해결하는 것보다 상호작용을 길게 끌어 더 많은 점수를 얻을 수 있다. 이는 가상의 실패 방식이며, AWS의 실제 비즈니스 배포에서 관찰된 결과는 아니다.

완료 보너스 역시 문제를 감출 수 있다. 어시스턴트가 근본 문제가 해결되지 않은 상태에서 티켓을 종료할 수 있기 때문이다. 평가기는 에이전트의 선언만을 충분한 증거로 받아들이기보다, 의도한 결과에 대한 증거를 요구해야 한다.

이 지점에서 도메인 지식이 기술적으로 중요해진다. 채점 함수는 사람들이 다른 경우 비공식적으로 표현했을 우선순위를 인코딩한다. 그러한 우선순위가 최적화 목표가 되면, 작은 모호성도 어떤 행동이 강화되는지에 영향을 줄 수 있다.

팀은 더 큰 실험을 시작하기 전에 대조적인 시도 쌍을 검토해야 한다. 정당한 완료는 부수적인 점수를 축적한 미완료 시도보다 높은 평가를 받아야 한다. 또한 필요한 에스컬레이션은 겉보기 목표에 도달하더라도 승인되지 않은 행동보다 계속 선호되어야 한다.

이러한 비교는 제안된 평가 관행이다. 모델이 테스트된 사례 밖에서도 올바르게 행동할 것이라고 보장하지는 않는다. 그 목적은 목표 함수의 모순을 아직 쉽게 점검할 수 있을 때 드러내는 데 있다.

더 넓은 우려는 Anthropic의 보상 해킹 연구에서도 나타난다. 이 연구는 모델이 의도대로 작업을 완료하지 않고도 보상을 얻는 법을 학습하는 현상을 다룬다. 실험 환경은 AWS의 Wordle 사례와 다르다. 이는 SageMaker에서 동등한 실패가 발생했다는 증거가 아니라, 목표 설계에 대한 주의를 제기한다.

중립적인 평가에서는 이 구분이 중요하다. AWS의 사례는 해당 서비스에 일반적인 안전성 문제가 있음을 입증하지 않는다. 마찬가지로 Anthropic의 연구도 모든 작업별 학습 실행에서 그 연구가 다룬 행동이 나타난다는 점을 입증하지 않는다.

두 자료를 함께 보면 더 제한적인 결론을 뒷받침한다. 평가는 점수가 어떤 방식으로 획득됐는지 살펴봐야 한다. 보상 상승은 향상된 작업 성과, 지나치게 관대한 채점 규칙 또는 그 둘의 조합을 반영할 수 있다. 집계 수치만으로는 그 모호성을 해소할 수 없다.

따라서 애플리케이션 팀은 성공에 대한 해석에 도전하는 사례를 보존해야 한다. 불필요한 행동, 성급한 완료, 누락된 증거, 부적절한 에스컬레이션이 관련된 사례는 명시적인 검토가 필요하다. 목표는 반복 학습이 그 결과를 증폭하기 전에 채점의 취약점을 찾아내는 것이다.

핵심적인 긴장은 지도 적응과 마찬가지로 그대로 남는다. 개발자에게는 신뢰할 수 있는 피드백이 필요하다. Amazon SageMaker 멀티턴 RL은 그러한 피드백을 생성하는 방식을 바꾸지만, 그 의미를 자명하게 만들지는 않는다.

서빙 설정도 성능 주장에 포함되어야 한다

보고된 작업 점수에는 모델 및 평가 세트와 함께 그 점수를 만들어 낸 구성도 포함되어야 한다.

AWS의 사례는 인상적인 상기점을 제공한다. 학습 검증은 37%의 해결률로 끝났지만, 보고된 서빙 구성에서는 84%에 도달했다. 추론 노력과 생성 출력의 무작위성을 제어하는 파라미터인 temperature를 비롯해 설정이 달랐다.

이 수치를 서로 대체 가능한 측정값으로 읽어서는 안 된다. 그렇다고 더 높은 수치가 더 낮은 수치를 지워버려서도 안 된다. 이들은 서로 다른 운영 조건에 관한 질문에 답하며, 배포 결정에는 의도한 애플리케이션과 맞는 조건이 필요하다.

추론 노력은 모델이 응답하기 전에 얼마나 많은 연산을 사용할지에 관한 실질적인 선택지를 제시한다. Temperature는 가능한 출력들을 어떻게 샘플링하는지 바꾼다. 이들의 상호작용은 에이전트가 작업 전반에 걸쳐 내리는 결정의 순서를 바꿀 수 있다.

적절한 비교는 기본 모델과 적응 모델 사이에서 관련 조건을 동일하게 유지한다. 그렇지 않으면 겉보기 학습 개선이 부분적으로 구성 변경을 반영할 수 있다. 이는 공개된 사례의 부정행위 주장이라기보다 실험 설계의 문제다.

구매자는 공급업체 간 핵심 비율을 비교하기 전에 운영 구성을 요청해야 한다. 도구 정의, 작업 입력, 제공되는 컨텍스트, 중단 규칙도 에이전트가 달성할 수 있는 일을 결정하는 데 도움이 된다. 모델 이름만으로는 너무 많은 사항이 불명확하게 남는다.

이는 작업별 모델을 범용 대안과 비교할 때 특히 중요해진다. 세심하게 적응된 소형 모델과 폭넓은 역량을 갖춘 모델은 서로 다른 제품 질문에 답한다. 비교는 어떤 작업, 제약 조건, 운영 예산이 조직에 중요한지 명확히 해야 한다.

Wordle 실습은 Anthropic, Google 또는 다른 모델 제공업체와의 일반적인 순위를 입증하지 않는다. 이는 특정 적응 실험에 관한 증거를 제공한다. 이 증거를 확장하려면 더 넓은 주장에 맞게 설계된 평가가 필요하다.

실패 분석은 전체 성공률과 함께 제공되어야 한다. 애플리케이션은 평균 성능이 개선되면서도 중요한 하위 집합에서 용납할 수 없는 실패 패턴을 유지할 수 있다. 비즈니스 의사결정에는 남은 실패가 무해한 재시도, 잘못된 기록, 또는 사람이 복구해야 하는 행동과 관련되는지 알아야 한다.

반복 평가는 생성된 행동의 변동과 안정적인 성과 향상을 구분하는 데에도 도움이 된다. 팀은 자신의 증거가 뒷받침하는 범위에서 불확실성을 보고해야 한다. 근거 없는 정밀성을 만들어 내거나, 소수의 성공적인 시연을 모집단 수준의 결과로 취급해서는 안 된다.

SageMaker와 지도 미세 조정을 비교할 때에도 배포 비교에는 같은 기준이 적용되어야 한다. 질문은 선택한 적응 방식이 비교 가능한 조건에서 전체 워크플로를 개선하는지 여부다. 학습 지표는 여전히 유용한 진단 증거이지만, 수용 여부는 배포 요구 사항이 결정한다.

상승하는 대시보드 곡선만으로 설명하는 SageMaker 에이전트 학습은 이 점을 놓치게 된다. 제공되는 시스템에는 구성, 도구, 환경 행동, 복구 경로가 포함된다. 이러한 요소는 조달 및 출시 검토 전반에서 성능 주장과 계속 연결되어 있어야 한다.

이는 출시 후 운영 책임도 만든다. 팀이 도구 응답이나 생성 설정을 바꾼다면, 이전에 승인했던 행동을 다시 평가해야 한다. 모델 가중치가 그대로여도 기존 평가는 이전 시스템을 설명할 뿐이다.

다음 증거는 재현, 전이, 신뢰성을 검증해야 한다

가장 강력한 후속 증거는 해당 사례의 성과가 독립적인 검증과 유용한 워크플로 제약에서도 유지되는지 보여줄 것이다.

첫 번째로 살펴볼 신호는 일치된 조건에서의 재현이다. 독립 실행은 관련 작업 설정을 보존하고 운영 구성을 보고해야 한다. 유사한 결과는 공개된 성과가 문서화되지 않은 구현 세부 사항에만 특화된 것이 아니라 재현 가능하다는 신뢰를 높일 것이다.

실질적으로 다른 결과를 보고하는 재현은 더 넓은 결론을 내리기 전에 조사가 필요하다. 가능한 설명으로는 변경된 종속성, 다른 설정 또는 실행 간 변동이 있다. 불일치 자체만으로는 어느 설명이 옳은지 알 수 없다.

독자에게 가치 있는 산출물은 결과와 그 결과를 낸 시스템을 연결하기에 충분한 정보를 포함해야 한다. 이는 작업 정의, 모델 버전, 환경 행동, 구성을 보존하는 것을 뜻한다. 최종 점수의 스크린샷만으로는 핵심 질문이 해결되지 않는다.

두 번째 신호는 신뢰할 수 있는 성공 기준을 갖춘 비공개 워크플로로의 전이다. 범위가 제한된 내부 작업은 일반적인 에이전트 개선에 대한 또 다른 주장보다 더 많은 정보를 제공할 수 있다. 여기에는 낯선 사례와 학습 보상을 단순히 반복하지 않는 검증이 포함되어야 한다.

그곳에서의 긍정적 결과는 애플리케이션별 적응의 근거를 강화할 것이다. 전이가 약하다면 성공을 유난히 쉽게 검증할 수 있는 환경으로 주장을 좁히게 된다. 어느 결과든 구매자가 추가 실험이 정당화되는 지점을 파악하는 데 도움이 된다.

증거는 학습과 평가 자료에 대한 노출도 구분해야 한다. 비공개 테스트 세트는 보호되어야 하며, 평가자는 환경이 무엇을 드러내는지 점검해야 한다. 그렇지 않으면 명목상 낯선 작업도 통과에 필요한 정보를 노출할 수 있다.

세 번째 신호는 주변 애플리케이션이 불완전하게 작동할 때의 신뢰성이다. 구매자는 도구를 사용할 수 없거나, 응답이 모호하거나, 시도가 중단된 뒤 어떤 일이 일어나는지 알아야 한다. 이상적인 조건에서의 성공은 전체 운영 부담을 설명하지 않는다.

그러한 조건에서도 유용한 행동을 유지하는 평가는 실질적인 근거를 강화할 것이다. 이상적인 조건의 작업 점수가 개선되더라도, 빈번한 수동 복구가 필요한 시스템이라면 근거는 약화된다. 관련 비교에는 남겨진 사람의 작업도 포함된다.

앞으로 몇 달 동안 이러한 신호는 어떤 학습 방식이 우세할지에 관한 근거 없는 예측보다 더 많은 주목을 이끌어야 한다. AWS는 점검 가능한 사례와 보고된 결과를 제공했다. 다음 증거는 환경이 덜 정돈될수록 이 접근 방식이 어디에서 계속 유용한지를 보여줘야 한다.

실험을 고려하는 팀이라면 검토자가 결과를 독립적으로 확인할 수 있는 범위가 제한된 워크플로부터 시작해야 한다. 의도한 서빙 설정에서 기본 모델의 행동을 기록한 다음, 수용 가능한 개선이 어떤 모습일지 정의하라. 어려운 사례를 보존하고 성공 점수 뒤에 있는 행동을 검토하라. AWS 샘플을 사용해 통합 방식을 이해하되, 그 시연 코드는 평가의 출발점으로 다뤄야 한다. Amazon SageMaker 멀티턴 RL을 더 넓은 워크플로로 확장하기 전에, 그 성과가 낯선 작업, 비교 가능한 설정, 독립적인 결과 검증에서도 유지되는지 물어야 한다. 결과에 의존하게 될 사람들에게 가장 중요한 불확실성을 중심으로 다음 실험을 선택하라.