다음 실험56c: 작은 속성 주장과 학습 전 효용 확인

English · 56b 결과 · 기존 확보 계획

56b의 전체17·라벨16그룹은 준비 하한을 넘었다. 하지만 동일 합성 영어 작성 흐름이고 역할·분할·새 기준선 효용을 아직 고정하지 않았다. 다음 단계에서도 하한을 통과했다는 이유만으로 학습하거나 기존 가중치를 교체하지 않는다.

가상 사용자는 코드를 확인하는 에이전트다. “어느 후보가 오류 때 출력을 비우는가”라는 작은 요구에 대해 싼 도구가 검사 순서만 제안한다. 외부의 독립 검사가 실제 코드를 확인하며, 모든 후보와 fallback을 유지한다. 여러 힌트를 반복 사용하더라도 점수는 정답 확률·실행 승인·전체 함수의 정답이 아니다.

다음 두 경로를 별도로 준비한다.

경로	먼저 만들어야 할 것	통과로 의미하지 않는 것
한 속성의 주장	quote 안 delimiter 보존, escape된 delimiter 보존, 오류 때 zero output 등 하나의 범위·관측값·literal 정답. 새 schema/계획/문장 검토	부분 속성을 통과한 코드가 함수 전체 계약도 충족한다는 주장
학습 전 순위 효용	알려진 답 있음/no-answer/unknown을 분리한 고정순서·BM25·어휘·좁은 규칙·oracle 비교, 같은 비용 분모·후보 보존	oracle 상한이 실제 모델 이득이나 LLM 사용량 감소라는 주장

속성별로 같은 원천 함수가 다른 정답 집합을 가질 수 있다. 예를 들어 초기 비ASCII 오류에 출력을 비우는 후보가 나중의 문법 오류에서는 부분 출력을 남길 수 있다. 원천의 full-contract correct/wrong 표시를 부분 속성의 라벨로 재사용하지 않는다. 속성별 literal 관측을 따로 준비하고, 지원 밖·설명 불완전·검사 문제는 unknown으로 둔다. 56b의 보류된 구분자4요청은 바꾸지 않는다.

한 함수의 속성을 여러 개 만들더라도 같은 부모·코드·오답·helper 연결로 묶는다. 속성 수·바꿔 쓴 문장·seed·형제·INT8/PTQ 자식은 독립 그룹을 늘리지 않는다. 더 좁은 의미 모델이 실제로 유리한지 확인하려면 공개 원천에서 서로 다른 개발 요청120→240과 언어·조건·작성 분포의 다양성을 함께 확보해야 한다. 권리·고정 revision·닫힌 compile 범위·독립 정답을 먼저 확인하며 기존 원천120개 조사 snapshot은 보존한다.

개선 여지가 충분한 자료가 확보된 뒤 학습/validation/calibration 역할과 전체 그룹 관계를 결과 전에 고정한다. 기존 최소15 기준과 최소5% 효용 필요조건을 낮추지 않는다. FP32 부모, 동일 부모의 INT8/PTQ 자식, 같은 예산의 삼진 STE 형제는 별도 관계로 기록한다. 기존 최대8 fits·16파생 산출물 제안은 실제 학습 실행 계획이 준비될 때만 집행한다. 아카이브의 bit 수와 추론 때 펼친 배열의 메모리를 따로 측정한다.

자원 경로도 별도 계획으로 진행한다. 먼저 캐시 없는 상주 JSONL에서 동일 요청과 서로 다른 공개 요청을 분리하고 startup·warmup·실제 처리·pipe·controller 비용과 전체 자식 RSS/CPU를 측정한다. 그 뒤 queue 한도가 있는 open-loop를 검토한다. 실제 재사용 이득이 관측되기 전에는 캐시·lock·SIMD·GPU를 성능 개선으로 주장하지 않는다. 이 문서는 해당 실험이나 새로운 숫자를 이미 만들었다는 기록이 아니다.

현재 실제 코딩 요청7개·기록20개와 소진된 호출 원장을 유지한다. 새 유료 시도를 하려면 별도 실행 계획과 예산 기록을 준비한다. 기존 protected final·CoSQA reserve는 읽지 않으며, 영역별 최소2,400개의 서로 다른 보호된 최종 요청은 별도 목표다. 유용성·권리·CI 검증을 통과한 새 모델만 Hugging Face에 불변 버전으로 올리고, Git에는 코드·계획·공개 수치·모델 참조만 둔다.