Repository navigation
Source Relative Learning
x < 257이라는 조건에서 256과258은 기준값의 서로 다른 쪽에 있습니다.
이번에는 숫자와 참·거짓만 넘기던 입력에 작음·같음·큼과 요구한 참·거짓의 관계를
추가했습니다. Gooo 소스에서 이 관계를 읽어16개 숫자,64바이트로 전달합니다.
모델 크기와 학습 횟수는 그대로 두었습니다. 새로운 입력이 실제 선택을 바꾸는지, 같은 정보를 쓰는 간단한 규칙과 비교하면 어떤지를 함께 살폈습니다.
| 첫 후보가 적힌 요구를 모두 충족한 수 | 고정 순서 | 간단한 규칙 | 기존 입력 모델 | 새 입력 모델 |
|---|---|---|---|---|
| 학습64개 | 16 | 32 | 11 | 32 |
| 관련 평가128개 | 32 | 64 | 32 | 64 |
| 학습에서 제외한 계산 유형64개 | 16 | 32 | 14 | 32 |
관련 평가에서 새 모델은 기존 모델보다46개를 개선했고14개에서 나빠졌습니다. 비교 순서는128/128, 반환 분기는64/128을 맞혔습니다. 간단한 규칙도 같은 수를 맞혔습니다.
소스와 출력 사례를 그대로 두고 조건만 바꾼64쌍에서는 새 모델의 두 선택이 모두 바뀌었습니다. 그중32쌍은 두 문서의 첫 후보를 모두 맞혔습니다. 기존 모델은 비교 선택을 한 번도 바꾸지 않았고 분기 선택은2쌍에서만 바뀌었습니다. 이 수는 위128개 평가와 겹칩니다.
알려진 세 계산 양식과 한글·영어 문구를 재사용한 합성 사례입니다. 문서288개를 서로 독립적인 프로그래밍 문제288개로 볼 수는 없습니다. 이 수치를 일반적인 자연어 이해율로 옮기지도 않습니다.
정상적인256개에서는 네 방식 모두 네 후보 안에서 요구와 별도 확인 사례를 통과했습니다. 첫 후보를 잘 고르는 능력과 끝까지 찾아 완성하는 능력은 따로 기록합니다.
- 조건을 비운16개: 출력만으로 가능한 답이 두 개씩 남았습니다. 적힌 출력은 모두 충족했지만, 별도로 고정해 둔 조건까지 맞는지는 방식마다 달랐습니다.
-
모순된 조건16개: 같은 값끼리의 엄격 비교를 참으로 요구했습니다. 허용된 네 후보가
모두 실패했고, 각각11개 중10개를 충족한
PARTIAL결과로 남았습니다.
모순 사례의 별도 확인은 통과했어도, 원래 적힌 모순 조건은 실패한 채입니다. 성공한 검사 수를 한데 더해서 높은 정답률처럼 보여주는 대신, 빠진 조건과 실패한 조건을 남겼습니다.
두 모델 모두 가중치19,034개, FP32 배열76,136바이트입니다. 학습과 실행은 Go이며, 고정된 시드와2,000회 학습을 각각 한 번 수행했습니다.
| 같은288개 조립의 관측값 | 고정 순서 | 간단한 규칙 | 기존 모델 | 새 모델 |
|---|---|---|---|---|
| 후보 검사 수 | 728 | 472 | 726 | 542 |
| 모델 호출 수 | 0 | 0 | 288 | 288 |
| 전체 조립 시간 | 36.214ms | 25.589ms | 98.630ms | 84.688ms |
새 모델의 예측 중앙값은107.292µs, 입력 준비 중앙값은61.188µs였습니다. 전체 수집·학습2회·조립1,152회는32.57초, 최대 메모리63.594MiB를 썼습니다. 기기는 Apple M4, 논리 CPU10개, RAM16GiB입니다. CPU 시간은32.27초로 평균 약 한 코어를 사용했습니다. 순간적인 PC 전체 CPU 상승률은 따로 측정하지 않았습니다.
조립 시간에는 입력 준비·기록·후보 검사 비용이 포함됩니다. 학습·처음 소스를 읽고 전체 후보를 수집하는 작업·별도 확인 비용은 분리했습니다. 간단한 규칙도 실제 관계 계산과1,632번의 구간 검사를 수행했습니다. 너무 짧아0ns로 기록된55구간을 무료 계산으로 해석하지 않습니다. 처음 기록 검사기가 이를 오류로 처리했던 문제도 원본과 수정 내역에 남겼습니다.
한 번의 실행과 고정된 실행 순서에서 얻은 값입니다. 이번 작은 계산에서는 규칙이 같은 첫 선택 성과를 더 낮은 비용으로 냈습니다. 모델을 기본값으로 바꾸는 근거로 삼지는 않습니다.
SDK PR66에 계획·구현·가중치·원본을,
Hugging Face 연구 폴더에
자료를 공개했습니다. SDK는 원래 검사 통과 후 main의 3427169c에 병합했습니다.
계획과 소스는 원본 실행 전에 공개했습니다. 결과 검사는 저장된 기록만
읽으며, 학습·예측·후보 실행을 다시 하지 않습니다.
SDK0.2.41 실험판은
이번 가중치를 읽는 공개 Go API와 일반 조립 세션을 제공합니다. Gooo 소스에 연결된 준비된
계획을 주면, 후보를 실행하기 전에 한 번 판단합니다. 다음 후보로 넘어갈 때는 다시 호출하지
않습니다. 모델을 생략하면 고정 순서를 사용하고, 지원 밖 소스도 이유를 남기고 고정 순서로
진행합니다. PARTIAL에는 확인한 본문과 실패한 요구가 남습니다.
go get github.com/kimjooyoon/gooo-decision-runtime@v0.2.41-experimental사용 안내에
파일 읽기·입력 조회·조립 예제가 있습니다. inspect -source-relative-source는 실제 판단에 쓰는
528개 입력 값을 보여주며 예측이나 후보 실행을 하지 않습니다.
PR67의 연결 검사는 별도의 작은 예제로
호출 횟수·입력 일치·부분 결과·동시 실행을 확인했습니다. 공개 가중치는 원래 파일과 같습니다.
일반 SDK 세션은 필요할 때 다음 후보를 펼칩니다. 위 연구는 네 조합을 처음부터 정렬했으므로, 연구의 시간과 후보 수를 이 새 연결의 성능으로 옮길 수는 없습니다. 공개 컴파일러 0.6.29는 이전 평균·극값 모델과 이번 관계 모델을 지원합니다. 설치와 확인 범위.
컴파일러 연결 PR1455를 dev에 병합하고 배치 처리량 사용 예제를 공개했습니다. 연결 검사는 별도의 합성 가중치로 실제 Go 실행과 모델 없는 저장 재실행을 확인합니다. 공개 HF 가중치를 사용한 네이티브 관찰을 고정 소스에서 한 번 수행했습니다. 원본 결과와 비용을 공개했습니다. 모델과 고정 순서 모두 첫 후보가 출력4개 중1개를 맞혔고, 두 번째 후보에서4개를 모두 맞혔습니다. 중간 조건은 두 후보 모두3/3이었습니다. 올바른 조건을 고르는 것과 그 안의 계산을 고르는 것이 별개라는 점이 드러났습니다. 이 예제에서 모델은 후보 수를 줄이지 못했습니다.
모델은 후보 검사 전에 한 번 판단했고, 이후 후보 진행과 저장 재실행에서는 새로 판단하지 않았습니다.
나중에 준 네이티브 출력4개는 두 방식과 저장 재실행에서 모두 통과했습니다. 같은 사례를 반복한
결과이며, 실행기의 내부 입력 분리 지표는 UNKNOWN을 유지합니다.
판단 자체는0.106833ms, 가중치 준비는7.822ms였습니다. 전체 명령은 고정 순서0.81초·82.375MiB, 모델0.64초·81.578MiB 최대 RSS를 기록했습니다. 고정 실행 순서와 빌드 캐시가 있는 한 번의 관찰이므로 속도 향상으로 해석하지 않습니다. 공개 자료에는 첫 실패, 전체 입력 배열과 선택 기록, 실제 생성 Go 및 저장된 결과를 포함했습니다. 이 관찰은 당시 고정한 개발 소스에서 수행했습니다. 후속 공개판 0.6.29의 설치 확인은 별도로 기록했습니다.
0.6.29 공개 소스는
조립하면서 내부 함수가 실제로 받은 입력을 기록합니다. 호출자가 값을 제곱해 보조 함수에
넘긴다고 하면, 조립 때의 3과 평가 때의 -3은 모두 보조 함수의 9로 이어집니다.
이 경우 보조 함수는 이미 사용한 입력을 다시 받은 것입니다.
실패한 후보가 사용한 입력도 이력에 남습니다. 반복·중첩 호출을 기록하고, 이후 평가에서는 소스 사례와 중간 조건, 보류 사례, 기록한 확인 입력, 모든 호출 시도의 입력을 함께 비교합니다. 같은 시작 입력을 여러 번 적어도 새로운 입력 개수는 늘어나지 않습니다. 그 입력에 붙인 기대값은 모두 맞아야 통과한 사례 하나로 셉니다.
모델 판단과 실제 후보 실행은 기존 순서로 진행합니다. 입력 기록 때문에 모델을 더 부르거나 별도의 프로그램 실행을 추가하지 않습니다. 저장 재실행에서는 원래 소스로 후보와 입력 이력을 대조한 뒤 평가합니다. 표의 항목과 남은 관측 범위.
입력 이력 설명은 Hugging Face 모델 카드에도 반영했습니다.
위의 원본 네이티브 관찰은 당시 내부 입력 이력을 갖고 있지 않아 UNKNOWN을 유지합니다.
원본 실행과 학습을 반복하지 않았으며 가중치도 같습니다. 지역 후보를 점수화하는 동안의
내부 호출과 모델 학습 데이터 중복 여부는 아직 미측정입니다. 공개 실행 파일의 점검에서 확인한
입력과 분모는 0.6.29 배포 기록에 별도로 적었습니다.
이제 비교 조건의 관계는 선택에 전달됩니다. 다음 질문은 반환할 계산과 요구 출력의 관계를 어떻게 전달할지입니다. 여기에도 같은 정보를 쓰는 규칙을 함께 두고, 어떤 선택에 학습이 추가 비용만큼 도움이 되는지 확인할 계획입니다.
- 문서 홈
- 현재 상태와 지원 범위
- 문자열과 한 조건 조립의 0.6.32
- 문자열을 읽고 찾는 0.6.31
- 실패를 기록하며 조립을 이어가는 0.6.30
- 업무 규칙 예제와 실제 도입 기준
- 요구를 바꾼 뒤 결과 비교하기
- 결과 조회와 자체 모델의 0.6.28 배포
- 저장 결과를 비교하는 0.6.27 배포
- 작은 모델과 조립하는 0.6.26 배포
- 중간 조건을 확인하는 0.6.25 배포
- 분기 구성·재실행의 0.6.24 개발 후보
- 작은 도구로 발전시키는 Gooo
- 흐름도로 보는 Gooo
- 시작하기
- 언어 둘러보기
- 사용 흐름
- 작은 모델과 메타프로그래밍
- 우리 PC의 자체 경로 decision 모델
- 조건을 읽는 자체 모델과 실제 탐색
- SDK 0.2.39 자체 모델 받기
- 모델 선택 점수와 실제 실패
- 설명·변수 이름 변화의 27회 관측
- 작은 모델의 학습 범위를 넓힌 결과
- 같은 계산을 같은 모델 입력으로 읽기
- 사례를 통과해도 의도가 다를 때
- 사례를 모아 읽는 방식을 바꿔 보기
- 자체 결정 모델 받기 · Hugging Face
- 비교와 분기를 따로 배우면 나아질까
- 소스에 적는 중간 조건과 선택
- 지표와 증거
- 참고하고 감사하는 연구
- 최근 연구와 다음 작은 기능