알파코드 2가 코드를 생성하는건 Fine tuning 과정에 의존하는 부분이 커보이는데, 이 과정에서 설계 철학등을 적용하는지는 나와있지 않음, 하지만 좋은, 그러니까 성능적으로 좋고 보기 좋은 코드를 걸러내고 의미를 분석해서 코드를 생성하는거임. 설계 철학, 즉 코드의 의미를 그루핑하고 성능적으로 나은것을 필터링하는 방식으로 성능을 올렸는데, 난이도가 높은 문제에서는 제출된 답안이 없는 경우도 존재함. 하지만 통상적 문제에 대해서 2.4번의 제출로 문제를 해결했다는걸로 봤을 때, 코드를 의미적으로 분석하고 생성하여 일반 문제를 해결하는 속도는 비약적으로 향상시켰지만 설계 철학과 방법론등 코드를 설계하는 부분 자체를 취득한 것 같지는 않음.

) Solve rate(해결률)는 더 많은 샘플을 사용할 때 log-linear 하게 증가한다

: 10@k와 pass@k 지표는 둘 다 많은 샘플을 사용할 때 k가 커짐에 따라 대략적으로 log-linear하게 증가했다. <그림 7>의 (a) 그림을 보면 10@k 지표는 샘플링 예산이 많을 때 log-linear 증가 추세가 약간 감소하였다. 10개의 코드만을 최종 제출하더라도 충분한 양의 코드를 샘플링할 때 성능이 증가하는 것은 탐색 공간을 충분히 탐색하는 것이 중요하다는 것을 보여준다. 하지만 solve rate를 향상시키기 위해서 샘플링 사이즈를 지수적으로 증가해야 한다는 것은 샘플링 비용이 빠르게 소진될 수 있다.

2) 더 나은 모델은 scaling curve에서 더 가파른 기울기를 가진다

: <그림 6>에서 큰 스케일의 모델은 더 나은 성능을 보일 뿐만 아니라 더 많은 샘플링에 따른 성능 향상의 기울기가 더 컸다. scaling curve의 기울기가 크다는 것은 더 적은 표본으로 동일한 해결률에 도달할 수 있다는 것이다. 따라서 1)의 결과와 같이 더 높은 해결률을 달성하기 위한 샘플의 수가 지수적으로 폭증하는 상황에서, 더 나은 모델을 확보하는 것이 해결책이 될 수 있다.

3) 해결률은 더 많은 계산 양에 따라 log-linear 하게 증가한다

: <그림 7>의 (a) 그림에서 볼 수 있듯이 학습 시 사용한 자원에 log-linear 하게 해결률이 증가한다. 도표의 곡선에서 각 점은 하나의 모델에서의 성능을 보여준다. <그림 7>의 (b)는 추론 시 소요되는 계산량과 solve rate의 관계를 보여주는데, 큰 모델의 경우 하나의 코드 샘플을 생성하는 데에 더 많은 계산 자원이 필요하지만, 많이 샘플링할수록 같은 샘플링 비용을 사용할 때 작은 모델보다 성능이 좋은 것을 볼 수 있다.

블로그에서 긁어왔는데, 개발자면 이정도 영어는 읽을줄 알겠지. 코드를 많이 접할수록 얘가 코드를 정답으로 제출할 확률이 높아짐.

즉 코드를 설계하는 걸 모방하는 수준.

너무 혼란스러워서 일단 대충 요약정리만 했는데 이제 즉각적으로 방법론이랑 코드 설계를 짜내고 그래야 되는건가 하는 생각이 듬.

추가로 메타데이터나 지시문에 관련된 모든 알고리즘을 사용한다는 내용이 나와있어서 리소스가 많이 든다고 함