두 설정, 같은 GPU, 설명할 수 있는 하나의 결정.

1. 변형을 준비하기 전에 질문을 적으세요

유용한 비교는 구체적인 결정에 답합니다. 최대 길이를 늘리면 잘린 답변을 피할 수 있는가? 디테일 수준이 필요한 윤곽을 유지하는가? 더 큰 배치가 오류 없이 끝나는가? 질문 하나와 파라미터 하나를 고르세요. “최적의 설정 찾기”는 첫 세션으로는 너무 넓습니다.

A를 기준으로, B를 변형으로 부르세요. 변경한 정확한 값을 기록하세요. 모델, 크기, 패스 수를 동시에 바꾸면 다른 결과가 나올 수 있지만 어떤 변경 때문인지 알 수 없습니다. 이런 시도는 별도의 비교로 남겨 두세요.

2. 작은 코퍼스와 판단 규칙을 고정하세요

A와 B에 같은 입력을 모으세요. 프로젝트의 어려움이 포함되어 있다면 열두 개 정도의 사례로 제한된 첫 결정을 내리기에 충분할 수 있습니다. 이미지 속 작은 글씨, 긴 문서, 누락된 데이터, 특이한 형식 등입니다. 이 숫자는 실용적인 선택이며 통계적 보장이 아닙니다. 이미 성공하던 예시만 포함하지 마세요.

각 입력에 대해 테스트 전에 성공 조건을 적으세요. 표현상의 선호와 치명적인 결함을 구분하세요. 문서 어시스턴트에서는 더 친절한 답변이라도 규칙을 지어내면 거부될 수 있습니다. 제품 이미지에서는 매력적인 색감이 중요한 요소의 사라짐을 보상하지 못합니다.

최소 승인 사례 수, 금지된 결함, 최대 검토 시간도 정하세요. 이러한 프로젝트 고유의 기준은 결과를 검토할 때도 동일하게 유지되어야 합니다.

3. 같은 세션과 같은 의존성을 유지하세요

모델, 버전, 확장 기능, 연산 엔진 및 기타 설정을 그대로 유지하세요. 두 변형 사이에 다른 작업을 실행하지 말고 동일한 환경과 동일한 GPU를 사용하세요. 통제할 수 없는 요소도 기록하세요. 눈에 보이는 동시 작업, 강제된 버전 변경, 또는 다른 로딩 방식 등입니다. 이러한 변경의 영향을 받은 비교는 더 신중하게 해석해야 합니다.

도구가 무작위 시드를 사용하고 이를 고정할 수 있다면, 각 실행 쌍마다 그 값을 유지하세요. 이는 비교를 수월하게 하지만 모든 곳에서 동일한 출력을 보장하지는 않습니다. PyTorch는 동일한 시드를 사용하더라도 버전이나 플랫폼 간에 완전한 재현성이 보장되지 않는다고 명시합니다.

동일한 식별자 목록으로 A와 B 두 개의 폴더를 만드세요. 수동 수정 전의 원본 출력을 보관하세요. 사후 수정은 별도의 작업으로 기록하고 그 작업 시간을 명시해야 하며, 최초 파일을 생성한 설정의 결과로 간주해서는 안 됩니다.

4. 대조 실행을 한 번 하고, 쌍을 비교하세요

먼저 단순한 입력이 저장된 파일이나 응답까지 도달하는지 확인하세요. 이 실행은 방법을 검증합니다. 최초 로딩이나 특별한 준비 과정은 별도로 표시하세요. 모든 요소가 이미 로드된 B 실행과 A의 전체 시작 과정을 비교해서는 안 됩니다.

A와 B에 동일한 사례를 실행하세요. 도구가 허용한다면 순서를 번갈아 하고, 그런 다음 몇 가지 결정적인 쌍을 역순으로 다시 실행하세요. 단일 결과나 순서상의 이점이 전체 결론을 좌우하지 않는지 확인하세요.

오류와 거부된 출력도 기록하세요. B가 큰 입력에서 실패하더라도 평균을 높이기 위해 표에서 제거하지 마세요. 필요하다면 별도의 B2 시도에서 원인을 수정하세요. 이렇게 하면 난관이 생길 때마다 변형이 바뀌는 기록 대신 읽기 쉬운 비교를 유지할 수 있습니다.

5. 수용된 결과와 관측된 시간을 분리하세요

먼저 실제 크기나 사용 도구에서 품질을 평가하세요. 가능하다면 판단 시 A와 B의 이름을 일시적으로 가리세요. 한 사람이 단순히 뒤섞인 순서로 출력을 살펴본 뒤 대응 관계를 복원할 수 있습니다. 사전에 정한 기준과 각 거부에 대한 짧은 사유를 유지하세요.

시간에 대해서는 하나의 정의를 선택하세요. 예를 들어 시작부터 최종 출력 저장까지입니다. 그런 다음 사람의 검수와 수정을 분리하세요. GPU 호출 주변의 스톱워치가 항상 완료된 연산을 측정하는 것은 아닙니다. PyTorch/CUDA에서는 연산이 비동기적으로 처리될 수 있습니다. 연산만을 분리해 측정하려면 도구에서 문서화한 측정 방법을 사용하세요.

반복이 겹치거나 시간 측정이 여전히 부정확하다면 '시간 차이 결론 없음'이라고 기록하세요. 단 한 번의 실행에서 나온 작은 차이가 확실한 이득률로 제시될 근거는 되지 않습니다.

예시: 문서 지원 어시스턴트를 위한 128 또는 256개의 새 토큰

한 소규모 팀이 열두 개의 고정된 질문에 대해 완전한 답변을 원합니다. 이들은 동일한 모델, 동일한 문서, 동일한 지시문, 동일한 GPU를 유지합니다. 오직 응답 한도만 바뀝니다. A는 128개의 새 토큰을 허용하고, B는 256개를 허용합니다. Transformers에서 max_new_tokens는 입력 텍스트의 토큰을 계산하지 않고 생성만 제한합니다. 토큰은 단어가 아니므로, 이 한도가 정확한 문장 수를 정의하지는 않습니다.

실험 전에 팀은 예시적인 규칙을 정합니다. 열두 개 중 최소 열 개의 답변이 수용되고, 지어낸 규칙이 없어야 한다는 것입니다. 아래 표는 결과를 읽는 가상의 시나리오입니다. 이는 측정된 어시스턴트를 설명하는 것도 아니고, 이 값들이 여러분의 모델에 미칠 영향을 예측하는 것도 아닙니다.

A는 최소 기준을 달성했고, B는 더 많은 답변이 수용되었지만 중대한 결함이 남아 있습니다. 결정은 이 범위에서는 A를 유지하고 답변을 재검토하며, 다른 비교 전에 B의 결함 원인을 찾는 것입니다. 더 긴 길이가 품질의 증거도 아니고 지어냄의 확실한 원인도 아닙니다.

팀은 A와 B를 구분 짓는 질문들과 이미 성공한 두 질문을 다시 실행합니다. A에서도 결함이 나타난다면 판단을 보류합니다. 최초 코퍼스만으로는 안정성을 입증하기에 충분하지 않았던 것입니다. 가장 유리한 결과만 남기는 대신 두 실행의 기록을 모두 보관합니다.

테스트로 뒷받침되지 않는 결론은 피하세요

한쪽 출력만 화려하고 나머지는 품질이 떨어진다고 해서 B를 선택해서는 안 됩니다. 도중에 코퍼스를 바꾸거나, 두 번 이어서 실행한 것을 서로 다른 두 항목으로 세거나, 실패한 항목을 분모에서 빼지 마세요. 제출한 열두 개 항목은 결과 파일이 하나도 나오지 않은 경우가 있더라도 여전히 설명해야 할 열두 개의 사례입니다.

선택한 설정은 검토한 입력, 버전 및 기준에 유효합니다. 열 배 더 긴 문서나 다른 이미지에는 더 이상 적합하지 않을 수 있습니다. 대표적인 사례를 점진적으로 추가하세요. 이 과정은 통제 범위를 넓힐 뿐, 작은 테스트를 시스템 인증으로 바꾸지는 않습니다.

짧은 결정과 다음 확인 사항을 남기세요

최종 결과물에는 코퍼스, 두 가지 구성, 출력, 식별자별 판정, 그리고 몇 줄의 결론이 들어갑니다. 선택한 설정과 그 이유, 한계를 밝히세요. 예를 들어 "이 열두 개 질문에서는 A가 우세했다. 두 답변은 다시 검토해야 한다. 추가된 긴 문서는 다루지 못했다"와 같이 적습니다. 다른 사람이 그 자리에 없어도 이 선택을 이해할 수 있어야 합니다.

다음 진단을 위해 A를 대조군으로 유지하세요. 어떤 변형도 기준을 충족하지 못한다면 배포용으로 아무것도 선택하지 말고 새로운 가설을 세우세요. 이 후속 작업을 시작하기 전에 복사와 확인에 필요한 시간을 확보하세요. 명확한 한계와 함께 끝난 실험은 그 자체로 하나의 결정을 제공하며, 승자를 찾을 때까지 계속할 의무는 없습니다.