코드 동작에서 학습 정답을 만드는 방법

작은 모델이 확인할 후보의 순서를 제안하려면, 먼저 후보가 실제로 어떤 동작을 하는지 알아야 합니다. 공개 Go 코드에서 검증한 요청3개를 추가하고 같은 조건으로 실제 학습했습니다. 새 모델은 확인31회로 기존 단순 정렬27회보다 나빠 개선 기준을 실패했습니다. 전체 학습 결과에서 측정과 한계를 확인할 수 있습니다.

실제로 확인한 내용

검사	결과	해석
시간 변환과 명령행 슬라이스 처리	고정 입력 32건 모두 사전 기대값과 일치	오류 원인, 시간 값, nil·빈 슬라이스와 변경 상태를 구분했습니다. 아직 학습 요청으로 전환하지 않았습니다.
UUID 파싱·상태 변경과 영어 서수 후보	후보 9개 × 입력 8개, 총 72건 모두 사전 기대값과 일치	맞는 후보와 일부러 다른 동작을 하는 후보를 모두 실제로 실행했습니다.
학습 정답 검토	요청 3개, 정답 후보 3개·오답 후보 6개	코드의 요청 만족 여부와 설명의 충실성, 관찰 항목의 완결성을 따로 확인했습니다.

“기대값과 일치”는 코드가 좋은 후보라는 뜻이 아닙니다. 예를 들어 잘못된 후보가 오류를 버릴 것이라고 미리 예상했고 실제로 오류를 버렸다면, 관찰 검사는 통과하지만 사용자 요청에는 틀린 후보입니다.

어떤 차이를 학습시키나

요청	정답 후보	오답 후보에서 확인한 차이
UUID 오류를 반환하고 파서의 부분 결과도 유지	원 파서의 결과와 오류를 그대로 전달	오류 때 결과를 0으로 바꾸거나, 오류 반환 대신 패닉을 냅니다.
nil·빈 값·오류 때 기존 UUID 상태를 유지하고 오류를 반환	기존 상태에서 스캔하고 오류를 전달	스캔 전에 상태를 지우거나, 오류를 버립니다.
영어 서수에서 11·12·13으로 끝나면 th 사용	원 서수 함수의 규칙을 유지	끝자리만 보고 11st를 만들거나, 항상 th를 붙여 1th를 만듭니다.

오답 후보의 설명도 그 코드에 충실해야 합니다. “오류를 버린다”는 설명이 실제로 오류를 버리는 코드를 가리킬 때 학습에 사용할 수 있습니다. 설명이 코드와 맞지 않는 사례는 정답 판단과 별도로 다룹니다. 정답은 설명의 유사도에서 만들지 않고 고정한 요청, 소스와 실제 동작에서 만들었습니다.

이번 정답은 요청마다 고정한 8개 입력과 해당 소스 버전에 연결됩니다. 모든 가능한 입력에 대한 실험 증명은 아닙니다. 코드·설명을 함께 읽은 AI 보조 검토이며, 독립적인 사람의 맹검 검토도 아닙니다.

데이터 추가 학습에서 바꾼 것

기존 76개 요청의 문장, 후보 순서, 정답, 학습 제외 표시와 역할을 유지합니다. 새 3개는 학습 쪽에만 추가합니다. 같은 UUID 소스의 파싱·스캔과 그 변형은 한 그룹에 묶고, 서수 함수와 그 변형은 다른 그룹에 묶습니다. 전체 자료의 역할을 다시 추첨하지 않습니다.

새 구성은 요청79개·후보235개입니다. Go 학습 입력으로 변환1회와 학습1회를 완료했습니다. 기존76개, 기존 학습 행의 수치 접두부, 전체 검증·보정 구간이 유지됐습니다. 새 모델은 기존 첫 FP32 모델과 같은 설정으로 처음부터 학습한 형제 실험입니다. 시드, 특징 추출, 손실 함수와 양자화 방식을 유지했습니다. 첫 후보 정답은2/10, 확인31회로 기존 모델과 같았고 단순 정렬의5/10·27회를 넘지 못했습니다.

이 경량 실험은 직접 만든 Go 특징과 작은 모델을 사용합니다. 기존 Laya 본체의 파인튜닝이나 GPU 추론을 수행한 결과로 읽으면 안 됩니다. Laya 라우터와 연결하는 일, 3진 압축의 추가 실험, 모델 활성화는 각각 근거를 확인한 뒤 진행합니다.

시간과 메모리

32건 관찰의 전체 프로세스는 약 2.56초·최대 RSS 18.70MiB였습니다. 72건 후보 관찰은 약 2.84초·최대 RSS 18.63MiB였습니다. 각각 한 번 실행했고 자동 재시도는 없었습니다. 이 값에는 시작, 원문 확인, JSON 기록과 디스크 동기화가 포함됩니다. 모델 추론 속도나 함수 한 번의 메모리 사용량은 측정하지 않았습니다.

학습 준비의 기존 한도는 Go 힙의 완만한 256MiB 제한, 전체 프로세스 RSS 관찰 예산 256MiB, 외부 실행 제한 300초, 신규 데이터·모델·수치 기록 합계 64MiB입니다. 힙 설정이 OS 메모리를 강제로 제한하는 것은 아닙니다.

추가 저장 감사에서는 중복 저장본을 포함한 일부 자료만으로67,943,460바이트를 확인해 초기64MiB 초과를 기록했습니다. 고정된 범위2776개 경로의 재검증 합계는206,707,066바이트이며 전체 Mac·원격·삭제 이력을 포함한 총량은 아닙니다. 실제 실행 전에 별도 버전으로 보관512MiB·새 단계64MiB 한도를 고정했고, 과거 초과를 통과로 바꾸지 않았습니다. 같은 해시의 다른 경로도 각각 계산합니다.

새 변환 작업자는2.090초·OS 최고 메모리33.45MiB, 입력 검사·학습·비교·저장 작업자는1.244초·35.08MiB였습니다. CPU1개에서 실제 수행한 전체 작업자 측정이며 Go 힙이나 원래 Laya GPU 측정과 다릅니다.

결과를 판단하는 기준

기존 검증 자료와 네 단순 기준선을 그대로 비교합니다. 예상 확인 횟수가 가장 좋은 단일 기준선보다 5% 이상 줄고, 첫 후보와 상위 세 후보의 정답 포함률이 떨어지지 않아야 기존 개발 효용 기준을 통과합니다. 새 3개 자료의 결과는 학습한 자료에 대한 진단으로 따로 기록합니다.

기존 검증 결과는 이미 열람했으므로 새 학습도 개발 중 회귀 비교입니다. 별도의 새 의미 요청2,400개 이상으로 만드는 도메인별 최종 검증은 아직 갖춰지지 않았습니다. 후보 실행72건을 사용자 요청72개로 세거나 기존79개를 최종 검증으로 사용하지 않습니다. 새 모델과 기존 두 모델은 효용 검사를 실패해 모두 비활성입니다. 같은 작은 검증 구간의 재튜닝보다 독립적인 의미 요청과 소스 그룹을 확대하는 다음 PDCA를 준비합니다.

원본과 당시 계획, 실패 기록을 보존했습니다. 준비 자료, 기존 함수 관찰, 자료 준비 과정에서 출처와 한계를 확인할 수 있습니다. UUID의 BSD-3-Clause와 선택한 서수 소스의 MIT 원문 고지를 유지하며, 모델 파일과 호스트 경로·원시 실행 로그는 Git에 올리지 않습니다.