주민건

일리야 수츠케버 - 데이터 고갈

제프리 힌튼 - 하드웨어의 한계

Cursor 한 달 유료 결제해서 웹 프로토타입 개발을 해보았다.

뭔가 어릴적 레고 조립하듯 혹은 게임하듯이 재밌게 앱을 제작할 수 있게 되었다.

만든 프로토타입은 모두의연구소 랩에서 함께 기획한 내용을 토대로 제작되는데, 이때 여러 직업군이 어떻게 사용하는지 관찰할 수 있었다.

평가, 피드백, 코칭

생성형 AI를 잘 사용하기 위해서는 사람이 평가를 잘할 수 있어야되고 방향 제시를 잘 할 수 있어야 한다.

Cursor의 경우 사용자가 끝없는 코드 리뷰와 UI 리뷰를 빠르게 진행하게 된다.

앞으로 갈수록 도메인 지식이 더 중요하다고 말한 의미가 좀 더 와닿는 느낌이다.

집중

프로토타입 개발에서 좀 더 내가 원하는 부분에 집중할 수 있게 해주었다.

• 서비스 UX
• 어떤 순서로 개발하면 좋을지에 대한 감각
• 책봇(책의 등장인물을 사고 과정을 구현한 LLM)의 출력물

좀 더 중요한 영역에 신경을 더 쓸 수 있도록 만들어주고, 덜 중요한 영역은 시간 투자 대비 높은 수준의 질을 갖도록 해준다.

도메인 지식 (업무 처리 순서)

만약 아래 두 가지 포인트에 대한 이해가 없다면 Cursor와의 협업이 어려울거라 예상한다.

• 서비스 개발의 단계적 순서와 기능 개발 크기에 대한 감각이 없다면,
• 생성형 AI에 input으로 들어가게되는 코드 및 자연어 명령의 양에 대한 이해가 없다면,

초보 보조

초심자가 빠르게 해당 도메인에 올라탈 수 있도록 도움을 준다.

하지만, 질문을 잘 할 수 없다면 한 가지 해결 방법 및 경로만 알려주기 때문에 문제를 잘 해결하기는 어려울 듯 하다.

운전을 예로 들면,

• 택시 운전사는 네비게이션을 보조 자료로 사용한다
• 초행자는 네비게이션에 의지해서 길을 찾는다

한국 사람인은 전국민이 평론가다

코스닥기업 지배구조 ‘취약’…이사회 독립성 강화해야

만성적 코리아 디스카운트(한국 증시 저평가)를 해소하기 위해 기업 밸류업 프로그램 방안을 모색 중인 가운데 코스닥 상장사들의 지배구조가 코스피 기업들보다 더 취약한 것으로 나타났다. 코스닥150 기업 중 사외이사가 이사회 의장인 기업은 단 2개사로 전체 1.3%에 그쳤으며, 이사회에서 최고경영자 후보군을 검토하는 기업은 없는 것으로 나타나는 등 이사회의 독립성과 적극적인 활동이 부족했다. 이에 따라 지배구조 평가결과 또한 A등급을 받은 곳은 4.7%에 불과했다. 전문가들은 코스닥 기업의 지배구조 개선을 위해 이사회의 독립성 강화가…

내일신문김영숙

CEO가 피드백을 받을 수 없는 한국 이사회

[평가 만능주의, 해결책은] ①평가에 매몰된 학교교육의 문제

[교육플러스] 대한민국 교육이 평가에 매몰돼 학교교육이 수동적으로 이뤄진다는 지적이 나온다. 즉 평가가 수업에 맞춰지는 게 아니라 평가에 맞춰 수업을 진행할 수밖에 없는 현실에 점수로 등급이 나눠져 미래가 결정되는 아이들로 인한 문제들이 발생한다. 는 박도순 고려대 명예교수(제1대 교육과정평가원장)를 통해 평가 만능주의를 해소하기 위한 평가의 방향을 살펴봤다. 대한민국 평가, 무엇이 문제인가최근 학교를 통해서 학생들이 병들어 가고 있다는 주장이 우리 주변에서 자주 들리고 있다. 특히, 1980년대에 들어서면서부터 현장

교육플러스

성적 평가 위주의 한국 교육

Let’s Verify Step by Step

In recent years, large language models have greatly improved in their ability to perform complex multi-step reasoning. However, even state-of-the-art models still regularly produce logical mistakes. To train more reliable models, we can turn either to outcome supervision, which provides feedback for…

arXiv.orgHunter Lightman

결과를 피드백 주는 강화학습 보단 (평가)
과정을 피드백 주는 강화학습이 더 효과적 (코칭)

우린 알고 있다, 연구실에서 재떨이 던지는 괴물을 [커버스토리]

[경향신문] ㆍ61개 대학 4500명 교수 정보 등록, 잔잔한 파문 던지는 ‘김박사넷’…교수 갑질 대학원 사회, 을의 반란 재떨이가 날아왔다. 재떨이에 맞은 사람의 반응은 무엇일까. 1번 화를 낸다. 2번 신고한다. 3번 맞받아 던진다. 하지만 이곳에 있는 이들은 돈을 모아 전자담배를 선물했다. ‘아니, 뭐 이렇게 이상한 일이?’라는 생각이 든다면 주어를

다음 - 경향신문

피드백 시스템이 없는 교수는 괴물이 될 수밖에 없는가

평가만 주고 받을 줄 아는 사람들
피드백과 토론은 주고 받을 줄 모르는 사람들

그 사람들이 만든 사회와 구조
리더가 대부분 쉽게 왕이 될 수 있음

아무도 의견을 내지 않는다
의견 낼 줄 모르게 자랐기 때문

대신 나온 의견에 대한 평가는 잘한다
평가 받고 자라왔기 때문

조직이 결코 바뀌지 않는 이유

조직을 바꾸고 싶다면 꼭 알아야 할 시스템 원리 | 시스템 사고와 시스템 원형 시스템 과학자 피터 센게는 그의 저서 <학습하는 조직>에서 조직이 겪고 있는 본질적인 문제를 해결하려면 ‘시스템 사고’를 갖추어야 된다고 말합니다. 사업체가 급속히 성장하는 시점에서 회사 내의 전문가들이 초과근무 등으로 극도의 피로에 시달리자, 이를 해결해보려고 백방으로 노력했지만 소용이 없어 좌절했던 친구가 떠오른다.친구의

Brunch Story박상권

누구든 어느 위치에서든 피드백을 받을 수 있는 시스템이 존재해야한다

피드백 시스템을 구축하기 위해서는 구성원이 토론을 할 수 있어야 한다

어릴 때부터 자신의 생각을 표현하고,
다른 사람들의 생각을 듣고 의견을 낼 수 있고,
합의를 도출 할 수 있어야한다

가정 -> 학교 -> 사회 순서로
피드백, 코칭, 토론을 할 수 있도록 환경 조성이 되어야 한다

Q4: 여러분 모두에게 그런 '아하' 순간이 있었나요? 예를 들어, GPT-2, GPT-3, GPT-4를 훈련시켰을 때, 모델이 막 완성되어 모델과 대화를 시작하고 사람들이 "와, 이 모델 정말 대단해"라고 말했던 첫 순간 같은 것 말입니다.

추론을 위한 모델을 훈련시킬 때, 가장 먼저 떠오르는 것은 인간이 자신의 사고 과정을 작성하고 그것을 훈련시키는 것입니다. 제게 한 가지 '아하' 순간은 강화학습을 사용하여 모델이 자체적으로 사고 사슬을 생성하고 다듬도록 훈련시키면, 인간이 사고 사슬을 작성하는 것보다 더 나은 결과를 얻을 수 있다는 것을 발견했을 때였습니다. 이는 정말 이 방식을 확장하고 모델의 추론을 이런 방식으로 탐구할 수 있다는 '아하' 순간이었습니다.

전문가 (사람)의 사고방식이 필요하지 않은 이유

전문가의 사고방식보다 전문가의 사고방식이 탄생하게 된 환경 (강화학습에서의 environment)을 이해하는게 필요한 이유

Q8: o1을 어떤 방식으로 사용하고 있는지 들려주실 수 있나요?

저는 o1을 코딩에 사용하고 있습니다. 제 업무의 많은 부분이 코딩과 관련되어 있죠. 이제 저는 문제 정의에 더 집중하고 TDD(테스트 주도 개발)라는 방식을 사용합니다. 기능을 구현하는 코드를 작성하는 대신, 올바른 동작을 명시하는 단위 테스트를 작성하는 데 집중합니다. 그리고 나서 o1에게 실제 구현을 맡깁니다. 이렇게 하면 제가 중요한 것, 즉 높은 수준의 문제 해결에 집중할 수 있습니다.

또 다른 영역은 디버깅입니다. 이제 오류 메시지가 나오면 그냥 o1에 전달하고, 그러면 바로 해결책을 제시해줍니다. 즉시 해결하지 못하더라도, 적어도 더 나은 질문을 하거나 문제를 더 잘 생각할 수 있는 방법을 제시해줍니다. 이는 제 작업 방식에 정말 중요한 변화를 가져왔고, 다른 사람들에게도 도움이 되길 바랍니다.

저는 o1을 점점 더 학습에 활용하고 있습니다. 다양한 복잡한 기술 주제에 대해 물어볼수록, 이전 모델들보다 환각을 덜 일으키고 개념을 더 잘 설명한다는 것을 알게 되었습니다.

저는 o1을 브레인스토밍 파트너로 사용하는 것을 좋아합니다. 이는 매우 구체적인 머신 러닝 문제를 해결하는 방법부터 블로그 포스트나 트윗을 작성하는 방법까지 다양한 범위를 포함합니다. 예를 들어, 최근에 언어 모델 평가에 대한 블로그 포스트를 작성했는데, o1에게 블로그 포스트의 구조에 대한 아이디어, 특정 벤치마크의 장단점, 심지어 글쓰기 스타일에 대해서도 물어보았습니다. 최종 답변을 제시하기 전에 생각할 수 있기 때문에, 아이디어를 더 잘 연결하고 후보 아이디어를 수정하고 비평할 수 있습니다.

짧은 텍스트가 있고 그것을 더 창의적으로 만들거나 매우 다르게 만들고 싶다면, 이는 "다섯 가지 다른 아이디어를 주세요"라고 요청하기에 좋은 용도입니다. 또한 구조화되지 않은 생각들이 있다면, o1은 정말 뛰어난 사고 파트너가 됩니다. 아이디어가 있을 때 "이것들을 어떻게 연결해야 할까? 내가 무엇을 놓치고 있지?"라고 물어볼 수 있습니다. 최종 답변과 사고 과정을 읽음으로써 여러분은 훨씬 더 나은 결과를 얻을 수 있습니다.

저는 o1을 사용하여 우리의 내부 비밀 아이디어들을 시도해보고, 그것이 실제로 개선하려고 노력합니다.

독립적인 프로젝트에 대해 o1은 정말 좋습니다. 저는 GitHub 플러그인을 추가해야 했는데, GitHub 플러그인 추가에 대해 아무것도 몰랐습니다. 그래서 그냥 "PR에 대한 이러저러한 정보를 표시하는 GitHub 플러그인이 필요해"라고 말했더니, 코드를 그냥 생성해주었습니다. 저는 그냥 "이 코드를 어디에 붙여넣어야 하지? 나는 모르겠어"라고 물었고, o1은 "여기에 붙여넣으세요"라고 알려주었습니다. 그렇게 진행했죠.

많은 사람들에게 AGI(인공일반지능)를 실감하기는 어렵습니다. 모델이 여러분이 정말 중요하게 여기는 분야에서 인간보다 더 잘하는 것을 볼 때까지는 말이죠. 바둑 선수들과 체스 선수들에게는 몇 년 전에 그 순간이 왔을 것이고, 수학과 코딩을 정말 중요하게 여기는 우리에게는 지금 그 순간을 느끼기 시작하고 있는 것 같습니다.

코딩과 브레인 스토밍에 사용

바둑 선수와 체스 선수가 느꼈던 상실감을 곧 소프트웨어 엔지니어가 경험할 차례

Q9: 이 프로젝트의 일부 중에서, 정말 필요했지만 사람들이 그 중요성을 깨닫지 못할 수 있는 부분이 있나요?

우리의 가장 큰 대표 모델 훈련 실행뿐만 아니라 연구 실험을 수행하기 위한 대규모의 신뢰할 수 있는 인프라를 구축하는 것은 연구 자체만큼 흥미롭지는 않지만, 반드시 수행되어야 하며 전체 프로젝트의 성공에 엄청난 영향을 미칩니다.

OpenAI에는 연구 구조화 방식에 특별한 점이 있다고 생각합니다. 우리는 알고리즘적 발전을 신뢰할 수 있는 대규모 시스템을 구축하는 것과 동일하게 중요하게 여기며, 이러한 모델들을 훈련시키는 데 필요한 데이터셋을 구축하는 것도 마찬가지입니다. 저는 이런 점에서 OpenAI가 자랑스럽습니다. 이는 우리의 많은 대형 프로젝트들에서 일관된 패턴이었습니다.

우리가 새로운 것을 또 한 단계 확장할 때마다, 알고리즘적으로나 인프라 측면에서 새로운 문제들의 집합을 보게 됩니다. 우리는 확실히 두 가지 모두를 많은 집중력을 가지고 발전시킬 수 있는 능력을 키웠습니다.

저는 최종 모델이 말 그대로 아름다운 예술 작품이라고 느낍니다. 그것이 작동하도록 만들기 위해, 우리는 모든 단계가 작동하는지 확인해야 합니다. 우리는 모든 도전을 찾아 해결합니다. 저는 이것이 정말로 OpenAI가 운영되는 방식이라고 생각하며, 여기서 일하는 것이 매우 자랑스럽습니다.

또한 반드시 말씀드려야 할 것은, 여기에는 정말 훌륭한 사람들뿐만 아니라 따뜻한 마음을 가진 사람들이 있다는 것입니다. 저에게는 여기서 일하는 것이 정말 즐겁습니다. 저는 동료들과 함께 코딩하고, 잡담하고, 점심을 먹고, 대화를 나누고, 모델과 함께 이야기를 나눌 수 있어서 감사합니다.

모델을 잘 만들면 끝나는게 아님
모델을 잘 쓸 수 있도록 만드는데도 모델을 잘 만드는데 들었던 노력을 똑같이 해야 됨

전문가의 사고 방식 모방은 어떻게?

• 그저 policy와 reward를 잘 설계 했을 뿐, 전문가의 사고방식을 모방하지 않음
• 전문가가 처해있는 상황을 잘 묘사했을 뿐

OpenAI 연구자의 o1 활용법

코딩

• 원하는 결과물이 나올 수 있는 테스트 코드만 작성하고 나머지는 o1에게 맡긴다
  (기능을 구현하는 코드를 작성하는 대신, 올바른 동작을 명시하는 단위 테스트를 작성하는 데 집중합니다. 그리고 나서 o1에게 실제 구현을 맡깁니다. )
• 독립적인 작은 프로젝트는 아예 맡긴다
  ("PR에 대한 이러저러한 정보를 표시하는 GitHub 플러그인이 필요해")

브레인스토밍

• 다양한 시각에서의 아이디어 제시
  ("다섯 가지 다른 아이디어를 주세요")
• 구조화 되지 않은 생각 정리
  ("이것들을 어떻게 연결해야 할까? 내가 무엇을 놓치고 있지?")

인공지능 서비스가 성공하려면?

• 모델 개발 노력과 인프라 구축 노력을 동일하게 중요시 여겨야한다
• Research Scientist/Engineer, MLOps 둘 다 중요하다

소프트웨어 엔지니어의 업무 중 "코딩"이 사라질 예정

• 바둑기사 이세돌이 온몸으로 겪은 상실감을 코더가 곧 느낄 차례
• 우선 TDD를 열심히 체화 시켜야 됨
  (원하는 결과를 잘 정의하는 능력)

제가 사용한 비유는 옛 속담을 확장한 것입니다: "한 사람에게 물고기를 주면, 하루를 먹을 수 있습니다. 그에게 어떻게 물고기를 잡는지 가르치면, 평생을 먹을 수 있습니다." 저는 한 걸음 더 나아가 이 작업을 인센티브 기반 방법으로 해결합니다: "그에게 물고기의 맛을 가르치고 배고프게 만드세요." 그러면 그는 물고기 잡는 법을 배우러 갈 것입니다. 그렇게 하면서, 그는 인내심을 갖는 것, 날씨를 읽는 법, 물고기에 대해 배우는 것 등 다른 기술들도 배울 것입니다. 이 기술들 중 일부는 일반적이며 다른 작업에도 적용될 수 있습니다.

내 교육 철학의 근간

이는 전문가 대 제너럴리스트의 트레이드오프에 대해 흥미로운 함의를 갖습니다. 인간의 경우 이런 트레이드오프가 존재하는데, 한 주제에 전문화하는 데 소비한 시간은 일반화에 쓰이지 않기 때문입니다. 기계의 경우에는 그렇지 않습니다. 일부 모델은 10000배 더 많은 연산을 누릴 수 있습니다.

또 다른 비유는 드래곤볼의 "정신과 시간의 방"입니다. 방 안에서 1년 동안 훈련하면 밖에서는 겨우 하루밖에 지나지 않습니다. 배수는 365배입니다. 기계의 경우 훨씬 더 높습니다. 따라서 더 많은 연산을 하는 강력한 제너럴리스트가 종종 전문가보다 특정 영역에서 더 뛰어난 경우가 많습니다.

소형 모델, 전문가 모델은 결국 미래에 효용이 없다

쓸모가 있을려면 어떤 형태여야 할까?

• 대형 모델보다 압도적으로 저렴해야한다?

하지만 여기서, 만약 이 파란색 선을 확장해서 탐색을 추가함으로써 얻는 성능과 일치하려면 얼마나 멀리 확장해야 할지 본다면, 그 답은 100,000배입니다. 그래서 단지 탐색을 추가하는 것만으로도 모델을 100,000배 확장하는 것과 동등한 효과를 얻을 수 있었습니다. 제가 3년 동안 100배 확장하는 데 성공했을 때와 비교하면 말이죠.

모델 크기를 키우기 보단 추론 (계획) 시간을 늘리는게 비용 측면에서 효율적이다

기본적으로 하나비에서는 당신이 어떤 상태에 있는지에 대한 불확실성이 있습니다. 그래서 당신이 어떤 상태에 있을 수 있는지에 대한 믿음 분포가 있고, 게임에서 취할 수 있는 20가지 다른 행동이 있습니다. 그래서 우리는 그저 이렇게 말했습니다. 좋아, 우리가 있을 수 있는 이 다른 상태들 각각에 대해, 카드 1장 내기, 카드 1장 버리기, 빨간색 힌트 주기 등의 다른 행동들이 있습니다.

그 행동을 취하고 나서 게임의 나머지 부분을 우리의 정책에 따라 플레이한다면 우리의 기대 가치가 어떨지 보기 위해 여러 번의 롤아웃을 수행해 봅시다. 우리는 약 1000번의 롤아웃을 수행하여 각 행동에 대한 기대 가치의 좋은 추정치를 얻고, 그 다음 가장 높은 기대 가치를 가진 행동을 선택합니다. 여기 성능이 어떤지 보여드리겠습니다.

휴리스틱한, 수작업으로 만들어진 봇으로, 약 25%, 아마도 28%의 게임에서 승리합니다. 이것은 DeepMind 논문에서 소개된 알고리즘으로, 딥 Q 네트워크 봇이며 약 45%의 승률을 얻었습니다. 그리고 이것은 하나비를 위한 딥 RL 알고리즘에 대한 일련의 논문들 중 하나로, 점점 더 높은 성능을 얻었습니다. 우리 논문 발표 당시 최신 것으로, 약 58%의 점수를 얻었습니다.

이것은 다른 봇들에 이 탐색 알고리즘을 추가했을 때 얻을 수 있는 결과입니다. 28%만 얻던 수작업으로 만든 휴리스틱 봇에 상상할 수 있는 가장 단순한 탐색을 추가하면, 즉 취할 수 있는 모든 다른 행동들에 대해 많은 롤아웃을 수행하고 가장 높은 기대 가치를 가진 것을 선택하면, 성능이 거의 60%로 향상되어 이전의 모든 딥 RL 봇들을 바로 이겼습니다. 이는 테스트 시 1초 동안 단일 CPU 코어를 사용한 것입니다.

그리고 아름다운 점은 이를 다른 모든 딥 RL 봇들 위에 추가할 수 있다는 것이었습니다. 최신의 뛰어난 딥 RL 봇에 이를 추가하면 성능이 더욱 향상되어 약 72%에 도달했습니다. 그리고 이는 한 플레이어에 대해서만 탐색을 수행했을 때의 결과입니다.두 플레이어 모두에 대해 이를 수행하면, 그것이 초록색 막대들인데, 성능이 더욱 향상된 것을 볼 수 있습니다. 또한 지적해야 할 점은 이 게임의 상한선이 100%가 아니라는 것입니다. 왜냐하면 절대 이길 수 없는 카드 분배가 있기 때문입니다. 실제로 가능한 최고 성능은 아마도 90% 정도일 것입니다.

추론 (몬테카를로 트리 서치) 할 수 있도록 했을 뿐인데 성능이 월등히 좋아짐

사실, 2021년에 발표된 정말 좋은 논문이 있습니다. 그냥 아카이브에 올라갔습니다. 앤디 존스는 현재 Anthropic에 있는데, 그는 알파제로와 같은 기술을 사용하여 헥스 게임에 대한 많은 스케일링 법칙을 연구했습니다.

그는 기본적으로 10배의 훈련 컴퓨팅이 15배의 테스트 시간 컴퓨팅과 동등하다는 트레이드오프가 있다는 것을 발견했습니다. 이것이 의미하는 바는 이 도메인에서 테스트 시간 컴퓨팅의 양을 15배 증가시킴으로써 훈련 컴퓨팅을 10배 증가시키는 것과 동등한 효과를 얻는다는 것입니다. 이것이 왜 중요할까요? 음, 만약 여러분이 예를 들어 10억 달러가 드는 시스템을 훈련시키고 있고 성능을 더 향상시키고 싶다면, 그것을 10배로 늘려 10억 달러에서 100억 달러로 갈 수 있거나, 아니면 추론 비용을 1센트에서 15센트로 증가시킬 수 있습니다.

15배의 test-time computing은 10배의 (pre) train computing 효과

좋습니다, Cicero의 작동 방식은 보드 상태와 대화 기록을 입력으로 받아 대화 조건부 행동 모델에 입력합니다. 이 모델은 다시 대화와 보드 상태를 입력으로 받아 현재 턴에서 모든 플레이어가 무엇을 할지 예측하려고 합니다. 이 행동들은 계획 엔진에 입력됩니다.

그리고 다시 말하지만, 이것이 Cicero의 새로운 점 중 하나라고 생각합니다. 오늘날의 많은 언어 모델에서는 볼 수 없는 것인데, 모든 플레이어들이 무엇을 할 것인지와 우리가 무엇을 할 것이라고 생각하는지에 대한 예측을 반복하고, 포커에서 했던 것과 비슷한 방식으로 여러 번의 루프를 돌며 이러한 예측을 정제한다는 것입니다. 그리고 이는 우리가 결국 플레이하게 되는 행동으로 이어지지만, 또한 우리의 대화 모델을 조건화하는 이러한 의도, 이러한 행동들로도 이어집니다. 즉, 이번 턴에 어떤 움직임을 해야 할지, 다른 플레이어들이 이번 턴에 무엇을 할 것이라고 생각하는지를 계획한 후, 우리는 그 계획들을 대화 모델에 입력하고, 그 계획들에 따라 우리의 대화를 조건화한 다음, 그에 따라 메시지를 출력합니다. 그리고 다시 말하지만, 이것이 Cicero에 대해 과소평가된 점 중 하나라고 생각합니다. 즉각적으로 행동하는 전형적인 언어 모델이 아니었다는 것입니다.

성능 면에서는, Cicero가 결국 상위 10%의 플레이어 중에서 두 번째로, 5게임 이상을 플레이한 19명의 플레이어 중 2위를 차지했고, 평균 인간 점수의 2배 이상을 기록했습니다.

외교 게임에서 상대방의 플레이를 예측하고 앞 수를 계획하고 말을 생성하는 모델

좋습니다, 여기에 일반적인 경향이 있습니다. 어떤 문제에 대해 왜 계획이 그렇게 많은 도메인에서 작동하는 걸까요? 그리고 제가 생각하기에 근본적인 이유 중 하나는 '생성자-검증자 격차'라고 부를 수 있는 것입니다. 기본적으로, 어떤 문제에서는 좋은 해결책을 검증하는 것이 그것을 생성하는 것보다 훨씬 쉽습니다. 예를 들어, 포커에서는 균형 상태에 있는지 검증하는 것이 그것을 계산하는 것보다 훨씬 쉽습니다.

계획이 잘 동작하는 이유는? 검증하는게 생성하는 것보다 쉬워서

체스에서는 정말 좋은 보드 상태에 있는지 검증하는 것이 그 매우 좋은 보드 상태로 가는 경로를 찾는 것보다 훨씬 쉽습니다. 그리고 스도쿠와 같은 것에서는 스도쿠 퍼즐의 해답을 검증하는 것이 그 해답을 찾는 것보다 훨씬 쉽습니다. 이는 퍼즐, 수학, 프로그래밍 증명과 같은 도메인에서도 마찬가지입니다.

증명을 검증하는 것이 증명을 생성하는 것보다 훨씬 쉽습니다. 이것이 사실이 아닌 일부 도메인도 있습니다. 예를 들어, 정보 검색에서는 그렇지 않습니다.

제가 여러분에게 부탄의 수도가 무엇인지 물어본다면, 10가지 다른 선택지를 줄 수 있습니다. 하지만 그것이 여러분 대부분에게 정답이 무엇인지 말하는 데 실제로 도움이 될 것 같지는 않습니다. 또한 이미지 인식과 같은 것들도 마찬가지입니다.

이러한 도메인들에서는 검증이 생성보다 그다지 쉽지 않습니다. 그리고 이러한 도메인에서는 계획이 큰 차이를 만들지 않을 것으로 예상됩니다. 하지만 생성자-검증자 격차가 있고 우리가 매우 좋은 검증자를 가지고 있다면, 우리는 생성 과정에 더 많은 계산을 투자할 수 있고 좋은 해결책을 찾았을 때 검증할 수 있습니다.

검증이 생성보다 쉬운 도메인 예시와 쉽지 않은 도메인

쉽지 않은 도메인에서 좋은 검증자를 가진다는 건 그 도메인을 장악할 수 있다는 말

언어 모델에서 테스트 시간 컴퓨팅의 스케일링은 어떤 모습일까요?

그것의 사례들이 있습니다.그리고 다시 말하지만, 저는 사람들이 그러한 기술들이 만드는 차이를 과소평가한다고 생각합니다. 가장 단순한 것은 합의(consensus)라고 불리는 알고리즘입니다. 기본 아이디어는 하나의 해결책만 생성하는 대신 여러 개의 해결책을 생성하고 가장 일반적인 것을 선택하는 것입니다.

Minerva라는 논문이 있습니다. 여러분 중 일부는 수학 벤치마크라고 불리는 것에 대해 알고 계실 것입니다. 이것은 벤치마크입니다. 말 그대로 수학이라고 불립니다. 그리고 기본적으로 고등학교, 대학 수준의 많은 어려운 수학 문제들을 포함하고 있습니다. 사람들은 이 벤치마크에서 50% 성능에 도달하는 데에도 매우 오랜 시간이 걸릴 것이라고 생각했습니다.

하지만 2022년에 구글은 Minerva라고 불리는 이 봇에 대한 논문을 발표했고, 수학 벤치마크에서 50% 이상을 얻었습니다. 이는 LLM 커뮤니티의 사람들에게 매우 놀라운 일이었습니다. 왜냐하면 수학은 LLM이 정말 못하는 매우 어려운 작업 중 하나로 여겨졌기 때문입니다. 그들은 성능을 50%로 올리기 위해 많은 일을 했습니다.

하지만 그들이 사용한 것 중 하나가 합의였습니다. 그들은 많은 해결책을 생성하고 단순히 가장 일반적인 것을 반환했습니다. 그리고 그것이 실제로 Minerva의 성능을 33.6%에서 50.3%로 끌어올렸습니다. 1000개의 샘플을 생성함으로써 말이죠. 하지만 합의에는 한계가 있습니다.예를 들어, 합의를 하는 것은 정말 쉽습니다. 답으로 반환해야 하는 단일 숫자가 있을 때 합의를 할 수 있습니다. 하지만 예를 들어 증명을 작성해야 할 때는 합의를 하는 것이 훨씬 더 어렵습니다. 왜냐하면 같은 증명을 여러 번 생성하지 않을 것이기 때문입니다.

하지만 할 수 있는 다른 것들이 있습니다. 또 다른 하나는 n개 중 최선(best of n)입니다. 여기서의 아이디어는 생성된 것이 얼마나 좋은지 점수를 매길 수 있는 보상 모델을 가지고 있다는 것입니다. 그리고 첫 번째 것을 반환하는 대신, n개의 해결책을 생성한 다음 보상 모델이 가장 좋다고 판단하는 것을 반환합니다. 충분히 좋은 보상 모델이 있다면, n개 중 최선이 합의를 이깁니다. 하지만 많은 경우에 보상 모델의 품질에 의해 병목 현상이 발생합니다. 실제로 보상 모델이 매우 좋지 않다면, 여기서 볼 수 있는 것과 같은 과적합 동적을 보게 될 것입니다. x축에는 생성하고 있는 해결책의 수가 있고 y축에는 테스트 시간 성능, 해결책, 점수가 있습니다. 그리고 처음에는 더 많은 해결책을 생성하고 보상 모델에 따라 최선의 것을 선택함에 따라 성능이 올라가지만, 결국에는 과적합되어 내려가는 것을 볼 수 있습니다. 따라서 매우 좋은 보상 모델이 없다면, 이것은 합의보다 더 나쁠 수 있습니다.

이것은 정답이 있는 도메인에서 매우 유용합니다. 체스가 좋은 예인데, 여러분은 이겼거나 졌다는 것을 알 수 있고, 스도쿠도 마찬가지로 여러분이 그것을 풀었는지 풀지 못했는지 알 수 있습니다. 우리가 이것들보다 더 잘할 수 있을까요?

실제로 OpenAI가 최근에 발표한 논문이 있습니다. 약 1년 전에 온라인에 공개되었지만, 공식적으로는 몇 주 전 ICLR에서 발표되었습니다.이것은 "단계별로 검증하자(Let's Verify Step by Step)"라고 불립니다. 그들은 프로세스 보상 모델이라는 아이디어를 소개했습니다. 그 아이디어는 최종 해결책만 검증하는 대신 모든 단계를 개별적으로 검증하는 것입니다. 그래서 그들은 각 단계를 거치면서 "이것이 맞는가? 틀린가?"를 확인합니다. 만약 틀렸다면, 그들은 그냥 전체 해결책에 대해 틀렸다고 표시합니다.

좋습니다, 이것은 어떻게 비교될까요? 이 그래프에서 우리는 생성된 해결책의 수가 1000 또는 2000까지 올라가는 것을 볼 수 있습니다. 그리고 이것은 수학 벤치마크에서의 성공률입니다.이 회색 선은 합의(consensus), 또는 다수결 투표라고도 불립니다. 처음에는 올라가지만 결국에는 평평해지는 것을 볼 수 있습니다. 하지만 실제로 꽤 큰 향상을 준다는 것을 볼 수 있습니다. 그래서 단순히 합의를 함으로써 약 60%에서 거의 70%로 올라갑니다. n개 중 최선(Best of n)을 사용하면 더 큰 향상을 얻고 72.4%까지 올라갑니다. 정말 좋은 보상 모델로 모든 단계를 검증하는 이 프로세스 보상 모델을 사용하면 더 큰 향상을 얻고 78.2%까지 올라갑니다. 그리고 여전히 더 많은 샘플을 생성하면 그 선이 더 올라갈 것 같아 보입니다.

이에 대한 몇 가지 예가 있습니다. 제 생각에 이것은 특히 정말 흥미로운 예인데, 이것이 수학 문제이기 때문입니다. 여러분에게 100도의 탄젠트 더하기 100도의 사인 4배를 단순화하라고 요구하고 있습니다.이것을 순수한 GPT-4 모델에 제시하면, 1000번 중 1번만 맞출 것입니다. 하지만 모든 단계를 검증하는 과정을 거침으로써, 1000개의 샘플을 생성한 다음 보상 모델이 맞다고 하는 것만 취하면, 이 문제에 대한 성공률이 크게 올라갈 것입니다.

합의 (consensus or voting) < 최선 (Best of n) < 과정 검증 (Verify step by step)

하지만 제가 지적하고 싶은 한 가지는 이 모델들의 추론 비용이 여전히 꽤 낮다는 것입니다. 여러분은 지금 당장 ChatGPT에 가서 질문을 할 수 있고, 매우, 매우 낮은 비용으로 기본적으로 즉시 응답을 받을 수 있습니다. 그리고 그것이 그렇게 될 필요는 없습니다.

우리가 살펴본 많은 이 게임들에서는 그렇지 않았습니다. 언어 모델의 경우에도 그럴 필요가 없을 수 있습니다. 그래서, 음, 다음 목표는, 음, 제가 지금 작업하고 있는 것은 일반성입니다.

우리가 정말로 일반적인 방식으로 추론 계산을 확장할 수 있을까요? 음, 이것은 매우 어려운 문제입니다. 알다시피, 우리는 이러한 기술들, 추론 계산을 확장하는 이러한 탐색 기술들을 많이 개발했지만, 그것들은 항상 우리가 살펴본 도메인에 매우 특화되어 있었습니다. 그리고, 그리고 제가, 제가 작업하고 있고 다른 사람들이 작업하고 있는 것은 매우 일반적인 방식으로 그것을 하는 것을 개발하는 것입니다.

이것은 테스트 시간에 훨씬 더 높은 계산을 사용하는 것을 포함하겠지만, 그것은 훨씬 더 능력 있는 모델을 의미할 것입니다. 그리고 제 생각에 많은 도메인에서 우리는 그 트레이드오프를 기꺼이 할 것입니다. 네, ChatGPT의 경우처럼 코딩 작업을 위한 코파일럿을 원할 때 응답을 기다리는 데 5분을 쓰고 싶지 않을 수 있지만, 우리가 답변을 위해 몇 시간, 며칠, 심지어 몇 주를 기다릴 수 있는 많은 질문들이 있습니다.

리만 가설의 증명이나 새로운 생명을 구하는 약물, 또는 다음 해리 포터 소설과 같은 것을 위해 그런 종류의 비용을 기꺼이 지불할 수 있다고 상상할 수 있습니다. 그리고 제 생각에 매우 중요하게, 이것은 우리가 이 모델들을 더 확장함에 따라 어디로 가고 있는지에 대한 감각을 줄 수 있습니다. 이것은 본질적으로 이 모델들이 더욱 능력 있게 됨에 따라 앞으로 AI의 상태가 어떨지에 대한 미래의 창을 우리에게 제공할 수 있습니다.

현재 기준으로 GPT 40의 추론 비용은 매우 저렴하고, 이제야 o1에서 비싸지기 시작했다.

도메인에 특화된 추론 절차가 존재할 것이다.

답변을 얻는데 기꺼이 시간을 내어 줄 아주 어려운 문제가 있는 도메인을 노리자.

음, 저는 또한 제안하고 싶습니다. 알다시피, 저는 n개 중 최선과 같은 것들에 대해 언급했는데, 병목 현상은 정말로 검증자, 보상 모델의 품질에 있습니다. 음, 여러분은 외부 검증자가 있는 영역에서 작업하는 것을 고려해 볼 수 있습니다. 왜냐하면 그렇게 하면 여러분은, 음, 보상 모델의 품질에 의해 병목 현상이 생기는 것을 피할 수 있기 때문입니다.

사람이 검증자라는 얘기를 하는 듯하다

• 답변을 얻는데 기꺼이 시간을 내어 줄 아주 어려운 문제가 있는 도메인을 노리자.
• 해당 도메인에 특화된 추론 절차를 정의하자.
• 생성보다 검증이 쉬운 문제를 찾자.
• 해당 도메인의 좋은 검증자를 확보하자.

고장 진단을 예로 들어보자

1. 고장 진단을 단계별로 풀어서 원인부터 결과까지 도출하는 LLM을 만든다
   (전문가의 고장 진단 생각 절차를 본따서 만든다)
2. 현장 진단 엔지니어가 각 단계에 대한 피드백을 준다
   (생각의 단계에서 특정 부분이 잘못되면 뒷 부분도 잘못됐다고 라벨링)
3. 사람의 수준 정도로 모델 정확도가 도달하면 사람의 도움 없이 인공지능 모델끼리 검증하고 생성하도록 만든다

알고리즘 문제해결능력 교육을 예로 들어보자

1. 6단계의 생각 절차를 똑같이 밟는 LLM을 만든다
2. 6단계 중 어떤 부분이 잘못되었는지 피드백을 준다
3. 사람의 수준 정도로 모델 정확도가 도달하면 지들끼리 검증하고 생성하게 한다

알고리즘 문제해결능력 교육의 예시는 내가 현장에서 코칭하는 방식이었다

1. 수강생이 모르겠다고 했을 때 6단계 중 어떤 단계에서 어려움이 있었는지 파악한다
2. 이후 해당 단계에서 다음 단계로 넘어갈 수 있는 힌트를 준다
3. 그리고 몇 단계에서 어려움이 있었다고 수강생에게 인지시켜 줬다

위 예제를 일반화 시켜보자

1. 도메인 전문가의 문제 해결 생각 절차를 추출한다
2. 추출한 절차를 lang-graph로 제작한다
3. 생성된 결과물을 도메인 전문가가 평가하도록 만든다
4. 학습에 사용될 충분한 데이터양을 확보한다
   (Let's verify step by step 논문의 경우 80만개)
5. 학습을 진행한 이후 사용한다

o1의 technical report가 나오면 위 일반화 과정을 업데이트한다

1. 도메인 전문가가 처한 상황을 잘 정의한다
2. 인센티브 모델을 잘 만든다
3. 문제를 잘 해결했는지 확인한다

OpenAI o1 팀 이야기 체리픽

Q4: 여러분 모두에게 그런 ‘아하’ 순간이 있었나요? 예를 들어, GPT-2, GPT-3, GPT-4를 훈련시켰을 때, 모델이 막 완성되어 모델과 대화를 시작하고 사람들이 ”와, 이 모델 정말 대단해”라고 말했던 첫 순간 같은 것 말입니다. 추론을 위한 모델을 훈련시킬 때, 가장 먼저 떠오르는 것은 인간이 자신의 사고 과정을 작성하고 그것을 훈련시키는 것입니다.

zoomgzoomg

이전 글

뭐하고 살지?

막연히 창업을 해야겠다는 생각을 가지고 10대와 20대 초반을 보내고, 아는 형님의 스타트업에 올라타 어깨너머로 구경하며 20대 중반을 보냈다. 회사 창업을 간접적으로 경험을 하고나니 내가 진짜 무얼하고 싶은지, 무엇을 하면서 살고 싶은지에 대한 방향성을 잃어버렸다! 삶의 목표가 희미해진채로 대학원 생활을 하고 전문연으로 취업한 지금 이 시점에서 이대로 계속 살다간 내 삶이

zoomgzoomg

이전 글에서 직무 관점에서 뭐하고 살지 고민했다면, 이번 글에서는 회사의 형태, 비지니스 모델의 관점에서 나한테 맞는 회사는 어디인지 생각해보려 한다.

회사의 크기 관점

나는 2개의 회사 경험이 있다

1. 10인~20인 규모의 에듀테크 회사, 입사 후 Seed 투자, 시리즈 A 투자를 받았다
2. 50인 규모의 원자력 발전소 밸브 진단 및 로봇 개발 회사, 투자 없이 매출 내면서 성장

신수정님의 글 내용과 같이 2번 회사는 풀고자 하는 문제가 정해져있고 이를 정확하고 효과적으로 해결하는데에 시간을 많이 투자한다. 1번 회사에 비해 상대적으로 긴 호흡으로 업무를 진행한다. 빠르게 해결해서 확인하는 과정이 필요하지 않았다. 오히려 빠르게 무언가 되는걸 보여주면 저평가를 받고 왜 이렇게 만들었냐는 말을 많이 들었다.

반면에 1번 회사는 빠른 호흡으로 산발적으로 업무가 진행되며, 제작과 동시에 배포로 이어져서 사용자의 반응을 확인할 수 있었다. 배포한 내용에 대해 회고하고 발전시킬 시간도 없이 다른 걸 만드는데에 시간을 써야했다. 시장에 맞는 제품을 찾아 헤매는 과정이라 생각된다. 그나마 궤도에 올랐다고 생각되는 서비스나 제품은 어느정도 회고의 시간이 있었으나 매우 짧았다. 다른거 하느라 바쁘게 만들어서.. 타겟과 문제가 명확하지 않았던거 같다. 대표가 문제 정의와 해결을 혼자서 논의없이 하려고 해서 원하던 회사 생활은 아니었다.

두 경험과 나의 성향을 토대로 나와 맞는 곳은 타겟의 해결하고자 하는 문제가 명확한 작은 회사이다. 인공지능 모델 정확도 개선 업무로 비유하면 94% 정확도를 가진 모델을 97%로 높이는 일에는 재미를 크게 느끼지 못한다. 웹 프론트엔드 개발을 예로 들면 로딩 시간이 2초인데 1초로 개선하는데에도 마찬가지로 흥미가 없다. 세부적인 문제보다는 큼지막한 단위로 문제를 풀고 개선하는게 재미있다. 사용자가 갖고 있는 문제를 결국 해결하게 되었는지, 사용자가 갖고 있는 진짜 문제를 찾았는지가 더 중요하다.

비지니스 모델 관점

1. B2C로 알고리즘 문제풀이 교육을 진행하다가, 퇴사 직전에 피봇팅하여 인공지능 솔루션을 공급하는 B2B 회사로 전환했다.
2. 발전소를 대상으로 사업을 하는 회사기에 B2G이다.

대상 고객 관점으로 보면, B2C, B2B, B2G는 다음과 같다

• B2C: 불특정 다수
• B2B: 회사 의사결정권자 (C레벨)
• B2G: 정부

B2C의 고객인 불특정 다수는 자신이 무엇을 원하는지 잘 모른다. 원한다고 해서 만들어도 진짜 사용할지는 모른다. B2B의 경우 고객사가 크다면 C레벨까지 제품이 만들어져 도달하기까지 중간 의사결정자가 다수 있고, 한 단계씩 만족시키며 올라가야한다. 중간 과정을 모두 만족시켜도 최종 의사결정자가 만족 할지는 모른다. 하지만 B2C와 달리 대화를 나눌 대상이 존재한다. 만들어야할 제품이 B2C보다는 명확하다. B2G의 경우 요구사항이 모두 정의되어 나온다. 하지만 제품을 제작할 권한을 따오는게 B2C, B2B보다 훨씬 어렵다.

• 요구사항 정의 난이도: B2C > B2B > B2G
• 사업 따오기 난이도: B2C < B2B < B2G
• 고객 만족 난이도: B2C > B2B > B2G

나는 정의된 요구사항을 잘 만들기보다는 요구사항을 정의해나가며 고객의 문제를 해결해나가는 과정을 즐긴다. 불확실한 내용을 확실하게 만들어가는게 재미있다.

결론

The Product-Minded Software Engineer

Product-minded engineers are developers with lots of interest in the productitself. They want to understand why decisions are made, how people use theproduct, and love to be involved in making product decisions. They’re someonewho would likely make a good product manager if they ever decide to gi…

The Pragmatic EngineerGergely Orosz

제품을 생각하는 소프트웨어 엔지니어로 실사용자에 미쳐있는 B2C (낮은 확률로 B2B) 회사에서 일하기를 희망한다.

The Product-Minded Software Engineer

Product-minded engineers are developers with lots of interest in the productitself. They want to understand why decisions are made, how people use theproduct, and love to be involved in making product decisions. They’re someonewho would likely make a good product manager if they ever decide to gi…

The Pragmatic EngineerGergely Orosz

Product-Minded Software Engineer (제품을 생각하는 엔지니어)
1. 제품에 대한 의견을 적극적으로 제시합니다.
2. 비즈니스, 사용자에 대해 이해하는데 시간을 투자합니다.
3. 왜 이 일을 하는지 생각하고, 스스로 답을 찾고자 합니다.
4. 훌륭한 의사소통 능력을 가지고 비엔지니어와 훌륭한 관계를 맺습니다.
5. 제품 <> 엔지니어링 사이의 절충안을 미리 제공합니다.
6. 엣지케이스는 실용적인 처리를 합니다.
7. 빠른 제품 검증 주기를 갖습니다.
8. 사용자 행동과 비즈니스 지표에 대한 결과를 얻은 후에만 작업이 완료되었다고 간주합니다.
9. 반복적인 제품 개선을 통해 배웁니다.

컴공, 디자인 취준생 분들에게 하고 싶은 말 | Disquiet*

IT 프로덕트를 만드는 메이커가 대다수는 창업자가 아닌 실무자 분들과 취준을 하는 분들입니다. 그러다 보니 이분들과 대화를 할 기회가 많습니다. 그리고 요즘 구직이 어렵다면서 아래 고민들을 많이들 얘기해 주시고요.“요즘 신입 채용 공고가 없어요”“서류 넣어도 계속 떨어...

Disquiet*

회사 입장에서 채용은 최소 N천만원, N개월이라는 시간을 사용하는 큰 비용이 드는 의사결정이고, 그런 결정을 하는 데엔 분명한 이유가 있습니다.

그 문제를 내가 해결해 줄 수 있다는 것을 증명하는 것입니다. 최소한 잠재력이 있다는 것을 알려주어야 합니다.

결국 문제를 적절히 해결해서 돈을 벌어다 줄 수 있는 사람이 채용될 수밖에 없다