Repository navigation
Helper Value Flow
2026-10-08. PR #1373의 개발 관측입니다.
아래 원본 관측의 소스는 246fdf5b입니다. 이후 CI에서 요구한 문자열 조립 방식으로
수정한 2a47da0e의 후속 검사가
모두 통과해 dev c278bb58에 병합했습니다. 같은 파일 트리의
main PR #1374도 별도 CI와 검증을
통과해 main dd0f339e에 병합했습니다. 아래 관측 파일은 당시 소스로 보존합니다.
병합 검증 기록.
파일 이름을 다루는 Gooo 함수들을 만들고 보니, 실행과 모델용 분석 사이에 빈틈이 있었습니다.
StripSuffix를 실행하면 확장자를 뺀 이름이 나오지만, 값의 출처를 분석하는 쪽은
그 함수 안으로 들어가지 못했습니다. 함수가 계산한 내용을 모델 입력에 옮길 길이 끊겨 있었습니다.
이번에는 호출할 때 넘긴 값을 함수의 입력에 연결하고, 함수 내부 계산과 조건별 반환값을 다시 호출한 쪽에 연결했습니다. 작업을 다른 사람에게 넘겼다가 받는다면, 무엇을 넘겼고 어떤 계산을 거쳐 돌아왔는지 작업 기록을 이어 붙이는 셈입니다.
- 인자에서 함수 입력으로 이어지는 관계
- 조건에 따라 달라지는 반환값과 일찍 반환하는 경로
- 레코드를 복사한 뒤 일부 값을 바꾸는 경우의 원래 값
- 호출한 함수의 안정 ID, 본문 해시, 원본 위치
- 후보의 두 번째 선택지에서만 호출하는 함수
파일 이름 예제에서는 네 함수가 115개 노드로 연결됐습니다. StripSuffix 안에서 다시
HasSuffix를 호출하는 경우도 포함합니다. 이 분석 단계의 모델 호출과 사례 실행은 0회입니다.
전체 노드 512개와 동시에 살아 있는 변수 64개라는 한도는 함수 안에서도 함께 적용합니다.
한도를 넘으면 미해결 이유를 남깁니다.
같은 프로그램에서 세 후보의 앞뒤를 뒤집은 여덟 배치를 다시 비교했습니다.
| 모델 입력 방식 | 실제 서로 다른 배열 | 제공된 정답 기준으로 가능한 최대치 |
|---|---|---|
| 기존 식 표현 | 2개 | 2/8 |
| 함수 출처까지 연결한 기존 v2 표현 | 4개 | 4/8 |
원래 파일 이름과 확장자를 뺀 이름은 출처가 달라 구분됐습니다. &&와 ||는 현재
특징 추출에서 여전히 같은 표현이 됩니다. 다음 입력 형식에서 연산자의 차이를 보존해야 합니다.
위 최대치는 같은 배열에 붙은 정답들이 얼마나 함께 만족될 수 있는지 센 값입니다. 한 프로그램의 후보 배치에 관한 결과이고, 모델 정답률을 측정한 수치는 아닙니다. v2 모델을 새로 학습하지 않았습니다. 후속 v3 입력 실험은 연산자와 값의 순서를 보존해 같은 여덟 배치를 여덟 배열로 구분합니다.
작업장의 PR #22에
출처 입력을 받는 feature-audit 명령을 추가했습니다. Go가 실제 특징 배열을 묶고,
Gooo로 작성한 평가 함수가 그 결과를 읽어 다음 작업을 정합니다.
두 입력 형식 모두 preserve-distinguishing-source-facts를 반환했습니다.
다음 학습에 앞서, 사라지는 소스의 구분부터 보존하라는 뜻입니다.
로컬 전체 동시 실행 검사와 정적 검사를 통과했고, PR CI와
브랜치 CI도 통과했습니다.
원본 결과의 해시와 로컬 관측의 일치를 확인한 뒤 main d7a628fa에 병합했습니다.
병합과 Linux 실행 기록을 보관했습니다.
기존 v1 모델은 여덟 번 판단해 제공된 선택을 1/8 만족했습니다.
v2 검사는 모델 호출 없이 진행했습니다. 입력에서 구별되는 경우가 늘어난 것과
실제 모델의 판단이 좋아진 것은 각각 측정합니다.
그래프만 읽는 별도 평가 코드로 파일 이름 열두 개의 두 후보, 세 필드를 비교해 72개 값이 기준 Go 구현과 일치하는지 확인했습니다. 세 가지 반환 경로, 중첩 레코드 전달, 변수 이름 변경, 동시 분석과 한도 초과도 검사했습니다.
기존 소형 모델을 사용한 코드 조립은 조립 사례 5/5, 별도 실제 실행 12/12였고 저장 재실행에서도 12/12였습니다. 이 실행은 기존 v1 모델 경로이며 새 출처 그래프를 소비하지 않습니다. 기존 모델의 후보 배치 의존성은 이전 실험에 남아 있습니다.