피터와 보리스 — OpenAI의 GPT-3 파인튜닝

에피소드 소개

사람들이 GPT-3를 번역, 카피라이팅 등 다양한 상업적 업무에 적용하는 방법
GPT-3 파인튜닝의 성능 향상 효과
바로 사용할 수 있으면서도 유연하고 커스터마이즈 가능한 GPT-3 기반 API 개발

Peter & Boris와 연결하기:

Peter의 트위터
Boris의 트위터

듣기

타임스탬프

대본

인트로

우리는 두 가지 유형의 사용자 집단이 있습니다. 연구자와 개발자죠. 개발자들은 “그냥 버튼 하나만 있으면 좋겠어요. 가장 좋은 모델만 나오게 해 주세요.”라고 말하곤 합니다. 반면에 많은 연구자들은 파라미터를 더 세밀하게 만져 보고 싶어 합니다. 아마 우리는 꽤 오랫동안 두 집단 모두를 만족시킬 수 있을 거라고 생각합니다.

현실 세계의 머신러닝을 다루는 프로그램, 그라디언트 디센트를 듣고 계십니다. 진행은 저, 루카스 비왈드입니다. 오늘은 오랜 친구이자 현재 OpenAI에서 제품 및 파트너십 부문 부사장으로 GPT-3와 기타 제품을 총괄하고 있는 피터 웰린더와 이야기합니다. 그전에는 OpenAI에서 리서치 리드로 일하며 Weights & Biases의 아주 초기 고객 중 한 분이었고, 그 이전에는 드롭박스에서 머신러닝 총괄을 맡았습니다. 또한 Weights & Biases의 머신러닝 엔지니어 보리스 다이마와도 함께합니다. GPT-3와, 최근 발표된 GPT-3와 Weights & Biases의 통합에 대해 이야기해 보겠습니다. 아주 재미있는 시간이 될 겁니다.

GPT-3로 현실 세계의 문제 해결

피터, 우리가 마지막으로 이야기했을 때는 당신이 OpenAI에서 리서치를 하고 있었던 걸로 기억해요. 제가 당신을 알아 온 대부분의 시간 동안 그랬죠. 그런데 이제 보니 OpenAI에서 제품 및 파트너십 부사장을 맡고 계시네요. 그게 정확히 어떤 역할인지, 그리고 하루하루 어떤 일을 하고 계신지 궁금합니다.

네, 그렇습니다. 지금 제가 하는 일은 과거에 연구를 하던 때와는 확실히 많이 다릅니다. 저에게 연구란 항상 세상에 가장 어려운 문제를 풀어 실제로 어떤 식으로든 영향을 주는 일이었습니다. 저는 연구 그 자체보다는 연구의 최종 목표에 훨씬 더 동기부여를 받는 편이에요. 연구는 정말 재미있고, 깊이 파고들며 탐구하는 과정도 즐겁지만, 그 끝에는 언제나 달성하고자 하는 목표가 있었습니다. GPT-3에서 흥미로운 일이 일어났죠. 제가 OpenAI에서 처음 했던 많은 일들은 로보틱스 쪽이었어요. 로보틱스는 여전히 연구실에서 할 수 있는 일과 실제 세계에서 할 수 있는 일 사이에 간극이 있습니다. 그런데 GPT-3에서는 초기 결과를 얻었을 때, 멋진 데모를 만드는 데 그치지 않고 실제 현실의 문제에 적용하기 시작할 수 있겠다는 게 분명해졌습니다. 로보틱스를 할 때는 최종적으로 루빅스 큐브를 푸는 로봇 손이라는 멋진 데모를 만들었지만, 그렇다고 그걸 당장 모든 가정에 배포하는 건 아니잖아요. 설령 그 정도로 견고하게 작동한다 해도, 루빅스 큐브를 푸는 게 얼마나 유용할지는 모르겠습니다. 비용도 너무 많이 들고요. 하지만 GPT-3는 온갖 다양한 문제를 해결하는 데 적용할 수 있는 언어 모델이었습니다. 번역부터 요약, 분류, 질의응답 등 정말 여러 작업에 쓸 수 있었죠. 매우 유연한 모델이었어요. 그래서 우리가 한 일은 이 모델이 실제 현실의 문제를 해결하기에 충분히 좋은지 확인해 보기 시작하는 것이었습니다. 저에게는 그 자체가 정말 즐겁게 집중할 수 있는 영역이었고요. 이렇게 아주 강력한 새로운 기술이 있을 때, 작동 방식을 크게 바꿀 잠재력이 있잖아요. 그때 중요한 건 공략할 올바른 문제를 찾는 것입니다. 그리고 내 도구 상자에 있는 도구로 그 문제들을 어떻게 풀지 모색하는 거죠. 차이는 이렇습니다. 연구자로서 제가 했던 일은, 아주 먼 목표를 향해 나아가면서 진전을 측정할 적절한 벤치마크와 평가 방법을 고안하는 것이었습니다. 일종의 토이 평가로 진척도를 재야 했죠. 이제는 고객들이 “이런 유즈케이스에 GPT-3를 적용해 보려는데 잘 안 된다”, “너무 느리다” 같은 이야기를 직접 해 줍니다. 훨씬 더 구체적인 문제들이죠. 제가 요즘 매일 하는 일은… 지금은 OpenAI에서 우리가 개발한 기술로 현실 세계의 문제를 해결할 수 있는 팀을 만드는 데 훨씬 더 초점을 맞추고 있습니다.

GPT-3와 요즘 대규모 언어 모델들이 따르는 다른 접근법들을 비교해 보면—그게 하나의 흐름처럼 보이긴 하는데—작동 방식에서 눈에 띄는 핵심적인 차이가 있을까요? 접근 자체가 somehow 다르다고 보시나요?

네, 좋은 질문이에요. 제가 GPT-3에서 정말 마음에 드는 점—그리고 제 생각에 가장 큰 차별점—은 아주 단순하다는 것입니다. GPT-3가 하는 일은 정말 간단해요. GPT-3는 대규모 언어 모델, 큰 신경망입니다. 구글이 몇 년 전에 소개해서 크게 유행한 Transformer 아키텍처를 사용하죠. 요즘은 사실상 모든 언어 모델의 기반이 되고 있고, 컴퓨터 비전 같은 다른 영역에도 점점 적용되고 있습니다. 그런데 GPT-3의 설정 방식은 매우 단순합니다. 컨텍스트가 있고, 기본적으로는 텍스트의 히스토리를 본다는 뜻이에요. 책을 읽는다고 하면, 한 페이지나 한 단락의 텍스트를 보고 나서 다음 단어를 예측하는 겁니다. GPT-3는 그런 방식으로 학습됩니다. 다양한 출처, 주로 인터넷에서 수집한 방대한 텍스트로 학습하죠. 이미 본 몇몇 단어를 바탕으로 다음 단어를 계속해서 예측하도록 반복적으로 학습하는 겁니다. 몇 단어만으로 시작할 수도 있지만, 오늘날 이런 모델을 학습할 때는 대략 수천 단어 규모의 컨텍스트를 사용합니다. 그 수천 단어를 되짚어보고 다음 단어를 예측하는 것이죠. 즉, 설정은 매우 매우 단순하고, 어마어마하게 큰 텍스트 데이터셋으로 다음 단어를 예측하는 능력을 끝없이 연마해 극도로 잘하게 만드는 겁니다. GPT-3에서 놀라웠던 점은, 그 단순한 과정을 그대로 두되 모델의 크기를 아주 크게—학습 용량을 엄청 키우면—예전에는 특화된 모델이 필요했던 여러 작업에서도 성능이 매우 좋아진다는 것이었습니다. 예를 들어 번역을 하고 싶으면 번역에 특화된 신경망이 필요했죠. 요약도 마찬가지로 네트워크를 특정 방식으로 설계하고 오직 요약 작업만으로 학습시켰습니다. 그런데 GPT-3에서는, 인터넷 텍스트로만 학습되어 그 어떤 작업에도 직접 맞춤 학습을 하지 않았음에도, 요약, 번역, 질의응답 같은 작업을 측정하는 여러 벤치마크에서 최신 수준에 매우 근접한 성능을 보였습니다. 읽었던 방식과 유사하게 텍스트를 재현할 수 있는 능력만으로도 그런 결과가 나온 것이죠.

번역 작업에 GPT-3 적용하기

실제로는 어떻게 번역 작업에 적용하나요? “다음 단어 예측”을 어떻게 번역으로 이어지게 만들 수 있죠?

네, 정말 좋은 질문이에요. 많은 다른 대규모 언어 모델에서는 텍스트 조각을 받아서 인코딩하는 단계가 있습니다. 즉, 신경망 안에 어떤 표현을 만들고, 그다음에는 그 표현을 받아 문장을 생성하는 디코더가 따로 있는 식이죠. 예를 들어 번역을 한다면, 입력을 어떤 표현으로 인코딩한 뒤, 신경망의 다른 부분이 그 표현을 받아 원하는 출력을 내도록 시도합니다. 입력은 독일어 문장, 출력은 영어 문장일 수 있고, 그 작업을 위해 특별히 학습되었죠. 그렇다면 GPT-3로는 무엇을 하느냐는 질문에 대해 설명드리면, 가장 간단한 방법은 순수한 텍스트로 번역 예시 몇 개를 제공하는 것입니다. “German:” 다음에 독일어 문장을 쓰고, “English:” 다음에 영어 문장을 쓰는 식이죠. 하나만 제공하면 원샷이라고 부릅니다. “German: … English: …” 형식의 예시를 몇 개 제공한 다음, 새로 번역하고 싶은 문장을 넣을 수도 있습니다. 이것이 퓨샷 세팅으로, 몇 개의 예시만으로도 모델이 컨텍스트에서 본 패턴을 따라 번역을 예측하고 생성할 수 있습니다. 설정이 매우 단순하죠. 저는 GPT에게 무엇을 하라고 지시하는 방식을, 사람이 이해할 수 있도록 지시하는 방식과 비슷하게 생각합니다. 이를테면 이메일을 쓴다고 하면… 제가 당신에게 “루카스, 몇 문장을 번역해 줘”라고 메일을 보낼 때, “이 문장들을 번역해 주세요”라고 요청하고, 어조를 파악하도록 예시 몇 개를 덧붙일 수 있습니다. 더 격식 있게 할지, 더 캐주얼하게 할지 등등이요. 그러면 당신은 그 패턴을 파악하겠죠. 그다음 독일어 문장을 주면—독일어를 아시는지는 모르겠지만—영어로 번역할 수 있을 겁니다. 이제 최신 모델들에서는 그런 예시조차 제공할 필요가 없는 경우가 많습니다. 사람에게 하듯 “이 문장을 번역해 줘”라거나 “이 텍스트를 요약해 줘”라고 그대로 요청할 수 있죠. 사용자들이 그런 식으로 모델을 쓰고 싶어 한다는 걸 알게 되었고, 저희도 그에 맞게 모델을 더 그렇게 작동하도록 만들었습니다. 핵심은 정말 간단하다는 겁니다. 무엇을 원하는지 말하면, 모델이 최선을 다해 그대로 수행합니다.

모델을 여러 언어로 학습시키기 위해 의도적으로 노력했나요, 아니면 주로 영어였나요? 코퍼스는 어디에서 가져왔나요?

사실 우리는 정반대로 했습니다. 초기에 GPT-3를 학습할 때는 영어 외의 다른 언어로 학습하지 않도록 의도적으로 노력했습니다. 모델이 아무리 커도, 데이터셋 구성에는 트레이드오프가 존재한다는 사실이 드러났거든요. 영어와 여러 다른 언어를 함께 학습시키면, 영어 과제에서의 성능이 그만큼 떨어집니다. 그리고 결국 우리가 학습할 때 보고 싶은 것은, 전반적으로 이 모델이 더 일반적인 능력에서 얼마나 잘할 수 있는가였죠. 우리는 번역에 그렇게 큰 우선순위를 두지 않았습니다. 그래서 다른 언어를 추가할 때마다, 질문 답변이나 요약 같은 영어 기반의 다른 작업 성능을 희생해야 했습니다. 그런데도 다른 언어를 대부분 필터링하려고 명시적으로 시도했음에도, 데이터의 몇 퍼센트포인트는 다른 언어로 남아 있었습니다. 그 정도만으로도 모델은 번역에서 놀라울 정도로 잘했습니다. 많은 번역 과제에서 최신 수준에 근접했죠. 저는 스웨덴어가 모국어이지만, 요즘은 거의 쓰지 않다 보니 스웨덴어로 글을 쓰는 능력을 잃었습니다. 요즘 제가 하는 방식은 영어로 쓰고 GPT-3에게 스웨덴어로 번역해 달라고 요청하는 겁니다. 보통 그렇게 합니다. 완벽하진 않아서 몇 군데 손봐야 하지만, 놀라울 만큼 좋습니다. 모델 안의 스웨덴어 학습 데이터 양은 정말, 정말 적었는데도요. 우리는 모델을 계속 업데이트하며 성능을 개선해 왔고, 이제는 이러한 트레이드오프를 더 최적화하는 방법을 어느 정도 찾아서 점점 더 많은 언어 데이터를 도입하고 있습니다. 하지만 처음에는 실제로 정반대를 원했어요. 우리는 영어에서 정말 잘하기만을 원했습니다.

단어를 예측하는 건가요, 아니면 한 번에 한 글자씩 예측하는 건가요? 그건 어떻게 작동하죠?

그 둘 다 아닙니다. 실제로는 토큰이라고 부르는 것을 예측합니다. 쉽게 말해 “단어의 일부”라고 생각하면 됩니다. 가장 흔한 영어 단어들은 하나의 토큰으로 표현됩니다. 토큰은 기본적으로… 현재 설정에서는 약 50,000개의 토큰이 있고, 이를 문자 시퀀스에 매핑합니다. 그래서 “hi”나 “the” 같은 흔한 단어는 한 개의 토큰이 됩니다. 반면에 “encyclopedia”처럼 덜 흔한 단어는 보통 두세 개의 토큰으로 쪼개집니다. 언어 모델이 텍스트를 더 쉽고 효율적으로 처리하도록 만든 단어 조각 같은 개념이죠. 원칙적으로는 문자 단위로도 할 수 있습니다. 다만 그렇게 하면 매우 비효율적입니다. 하지만 아시다시피, 분야의 흐름은 아마 그쪽으로 가고 있을 겁니다. 결국에는 문자 단위로 처리하게 될 가능성이 큽니다.

하지만 그러면 외국어가 정말 어려워지지 않을까요? 예를 들어 아시아 언어들은 그럼 불가능해지는 건가요? 토큰 수가 훨씬 더 많다면요. 아니면 이렇게도 볼 수 있겠네요. 글자 수가 많아서 더 큰 의미 단위를 담다 보니, 일종의 토크나이제이션을 언어 자체가 대신해 준 거라고요.

맞아요. 토크나이저를 어떻게 학습시키느냐가 각 언어에서의 성능에 영향을 주는 건 확실합니다. 보통 이 두 단계는 분리해서 진행합니다. 먼저 어떤 말뭉치로 토크나이저를 학습시키고, 그다음에 그 토크나이저를 써서 별도의 데이터셋으로 모델을 학습시키죠. 여러 언어에서 모델을 정말 잘하게 만들려면, 토크나이저도 다국어로 함께 학습시켜야 합니다. 그리고 확실히… 다른 언어를 쓰는 게 더 비용이 큽니다. 독일어 단어의 경우 우리가 상대적으로 적게 학습했기 때문에 토큰 수가 더 많아지는 반면, 영어는 많은 단어가 단일 토큰으로 표현되어 매우 효율적이죠. 그래서 다른 언어에서는 성능이 조금 떨어질 뿐만 아니라 비용도 더 많이 듭니다.

제가 일본어로 번역해도 될까요? GPT-3로 그런 일이 가능하기는 한가요?

아, 맞아요. 기억나는 피드백 중에 일본인 사용자분이 계셨어요. 그분은 영문 기술 문서를 일본어로, 혹은 일본어 기술 문서를 영어로 번역할 때 GPT-3를 즐겨 쓰셨는데, 기술 문서 번역에 한해서는 Google 번역보다 GPT-3가 훨씬 뛰어나다고 하시더라고요. 이게 1년쯤 전 이야기라 지금은 Google 번역이 더 좋아졌을 수도 있습니다. 아마 저희가 가지고 있던 데이터셋의 특성에 따른 우연일 가능성도 있고요. GPT-3의 번역 능력에서 정말 흥미로운 점은, 우리가 입력과 출력이 명시적으로 짝지어진 번역 쌍, 그러니까 흔히 말하는 “정렬된 텍스트”로 모델을 제대로 훈련시키지 않았다는 겁니다. 모델은 일본어를 많이 보긴 했지만, 엄청 많다고 할 수준은 아니고요. 일본어는 어느 정도, 영어는 아주 많이 본 셈이죠. 그런데 다음 단어를 예측하는 법을 배우는 과정에서, 글쓴이가 일본어와 영어를 오가거나, 문장 몇 개를 번역해 놓은 블로그 글 같은 조각들이 충분히 섞여 있어서, 그 안에서 매핑을 찾아냈고, 그 결과 임의의 번역 작업으로 일반화할 만큼 충분히 좋은 표현을 형성한 것 같아요. 저는 그게 정말 마법 같다고 느꼈습니다. 아주 많은 영어 텍스트와 많은 일본어 텍스트를 읽고, 데이터 속에 우연히 섞여 있던 소수의 정렬된 쌍을 발견하는 것만으로도 그런 번역을 해낼 수 있다는 게요. 제겐 정말 놀랍습니다.

카피라이팅과 기타 상업적 GPT-3 활용 사례

정말 놀랍네요. 이 성능이 이전 버전의 GPT와 눈에 띄게 다른가요? 예를 들어 GPT-3에서 OpenAI가 “좋아, 이제 실제 상업적 용도로 쓸 수 있겠다”라고 판단하게 만든 어떤 변화가 있었나요? 넘어야 했던 성능 임계점 같은 것이 있었나요?

네, 확실히 그렇습니다. GPT-2와 GPT-3의 큰 차이는 정말… 더 많은 데이터로 학습했고, 모델 자체가 훨씬 커졌다는 점이에요. 거의 두 자릿수 규모로요. 원래 GPT-2는 약 15억 개의 파라미터였고, GPT-3의 가장 큰 모델은 1,750억 개의 파라미터였습니다. 두 자릿수 규모로 커졌고, 모델이 훨씬 커진 만큼 더 많은 데이터가 필요했죠. 놀라운 점은, 그 변화만으로도 상호작용할 때 꽤 멍청하게 느껴지던 단계에서 벗어났다는 거예요. GPT-2도 꽤 멋지긴 했지만, 대부분의 경우 정말 믿기지 않을 정도로 멍청하게 느껴지곤 했거든요. GPT-3에선 가끔 놀랄 만큼 잘하는 순간들이 생겼습니다. 오해하지 마세요, GPT-3도 여전히 엉뚱한 실수를 많이 합니다. 그래도 어떤 과제들에선 대략 30~50% 정도는 제대로 해내고, 때로는 그보다 더 잘할 때도 있어요. 예전엔 표본을 많이 뽑아 이것저것 시도해 봐야 한 스무 번에 한 번 정도 “오, 이건 꽤 괜찮네” 싶은 결과가 나왔는데, GPT-3에선 그게 세 번에 한 번, 두 번에 한 번, 다섯 번에 한 번 꼴로 나오기 시작한 거죠. 그러면 “세상에, 이게 진짜…” 하는 느낌이 듭니다. 텍스트 요약 같은 작업에서요… 예로, “초등학교 2학년 수준의 스타일로 글을 요약”하는 과제가 있어요. 이 모델이 단어를 단순화하고, 핵심을 잡아내고, 그런 걸 해내는 게 정말 놀랍습니다. 물론 완벽하진 않지만, 정말 잘합니다. 분명 학술적 벤치마크도 많고, 그 지표들에서 성능이 훨씬 좋아진 것도 확인할 수 있어요. 하지만 무엇인가를 프로토타이핑해 보려고 할 때의 체감은 전혀 달랐습니다. 이제는 그럭저럭 잘 돌아가는 결과를 내기가 훨씬 쉬워졌거든요. 그래서 “이제는 쓸모가 있다”라고 판단한 겁니다. GPT-2는 같은 수준으로 유용하다고 느껴지지 않았지만, GPT-3는 여러 작업에서 “최첨단에 꽤 근접했다”고 느꼈어요. 특화된 모델이 있거나 뭐든, 똑똑한 개발자라면 자신들의 과제에 적용할 수 있겠다 싶었죠. 그걸 API로 검증해 보자고 설정했던 겁니다.

정말 잘 작동해서 자랑스럽게 생각하는 활용 사례에는 어떤 것들이 있나요? 우리가 상업적 환경에서 직접 사용해 볼 수 있는, 구체적으로 안내해 주실 수 있는 사례도 있을까요?

네, 물론이죠. 우리가 가장 놀랐던 분야 중 일부는 카피라이팅과 질의응답이었습니다. 전반적으로는 창의적 글쓰기요. 카피라이팅 쪽에서는 우리 플랫폼 위에 서비스를 구축하기 시작한 회사들이 여럿 있었습니다. 초기 사례로는 Copysmith, CopyAI 같은 곳이 있었고, Jarvis도 있었죠. 최근에는 다른 이름으로 바꾼 걸로 압니다. 이 밖에도 여러 회사들이 있었고요. 이들이 한 일은 정말 영리했습니다. 말씀드렸듯이 GPT-3로 어떤 작업을 하면 완벽하진 않다는 걸 깨달은 거죠. 가끔은 전혀 말이 안 되는 출력이 나오기도 합니다. 하지만 카피라이팅 같은 작업, 예를 들어 제품의 속성—신발이라면 밑창 종류, 색상, 기타 특징—을 바탕으로 매력적인 제품 설명을 쓰고 싶을 때, 사람인 당신이 겪는 문제는 일종의 ‘글 막힘’입니다. 대체 어디서 시작해야 하지? 같은 고민이죠. 이 회사들이 한 일은 GPT-3를 가져다가 제품 설명을 시작할 만한 몇 가지 초안이나 다양한 변주를 생성하게 한 것입니다. 보통은 다섯 개 정도 예시를 뽑아 보면, 그중 하나는 정말 좋아서 출발점으로 쓰기에 충분합니다. 그대로 써도 되고, 조금만 다듬어도 되고요. 일종의 인간 창작성을 보조하는 방법인 셈이죠. 저는 그게 정말 멋지다고 생각합니다. 작가들이 우리에게 이렇게 말하곤 했어요. “반년째 책을 쓰려고 했는데, 계속 글이 막혔어요. 그러다 GPT-3 플레이그라운드를 쓰기 시작했는데, 결국 2주 만에 책을 다 써냈어요.” 막혔을 때 모델이 흥미로운 전개를 만들어 주기도 합니다. 창작자로서 “아, 이 캐릭터가 그런 방향으로 갈 거란 생각은 못 했는데, 한번 파고들어 볼까?” 하면서 탐색을 시작하게 되죠. 그러면 훨씬 더 재미있고 몰입되는 과정이 됩니다. 거의 인간이 이제 다양한 작업에 적용할 수 있는 브레인스토밍 파트너를 얻은 것과 같습니다. 그리고 여러 회사가 그 점을 제대로 활용해, 이전에는 불가능했던 새로운 경험을 만든 걸 보는 게 정말 멋졌습니다. 그 부분이 무척 흥분되는 지점이고, 질의응답도 정말 대단합니다. 다만 질의응답은 꽤 예상 밖이었어요. 그렇게 큰 활용 사례가 될 거라고는 예측하지 못했던 것 같습니다.

OpenAI API로 GPT-3 파인튜닝하기

GPT-3의 장점 중 하나는 처음부터 별다른 설정 없이 바로 잘 작동한다는 점인 것 같습니다. 다만 어떤 팀들에겐, 문제가 생겼을 때 어떻게 대처해야 하는지에 대한 우려도 있을 것 같아요. 궁금한 점이 있어요. 보통 기업 내부의 ML 팀과 함께 일하시나요? 아니면, 자연어 처리의 이점을 얻기 위해 머신러닝 자체를 이해할 필요가 없다는 점에서 가치를 보는 엔지니어들과 더 많이 협업하시나요? 아니면 주로 ML 팀의 더 큰 ML 워크플로에 이걸 통합하는 편인가요?

네, 좋은 질문입니다. 혼합형에 가깝다고 말할 수 있을 것 같아요. 이미 자체 모델을 보유한 머신러닝 팀들과도 여러 번 협업했습니다. 온라인에서 모델을 내려받아 각자 과제에 맞게 튜닝해 쓰던 팀들이 우리 API를 발견하고 같은 일을 API로 해보면, 우리 모델이 훨씬 더 좋은 성능을 내는 경우가 많았어요. 그 이유 중 하나는, 우리가 보유한 가장 큰 모델이나 최고 성능 모델에 해당하는 오픈 소스 버전이 없기 때문입니다. 그래서 많은 과제에서는 우리 모델을 쓰는 게 가장 잘 맞습니다. 하지만 아마 고객의 다수는 “아주 똑똑한 개발자” 쪽에 가깝습니다. 여기서 개발자라는 말은 꽤 넓은 범주예요. 프로그래머, 엔지니어부터 디자이너, PM까지 다양합니다. 여러 분들이 OpenAI API가 프로그래밍에 입문하는 계기가 되었다고 말해 주셨어요. 우리 모델과 상호작용할 수 있는 플레이그라운드만 써도 매우 좋은 결과가 나오니, 아이디어가 떠오르고 코딩을 배우기 시작하고, Bubble IO 같은 노코드 도구와도 연결되었다고 하시더군요. 이 모델들로 좋은 결과를 얻기 위해 굳이 머신러닝 전문가가 될 필요는 없습니다. 대신 빠르게 반복하고, 모델에 어떤 지시를 어떻게 써야 하는지 파악하는 역량이 중요하죠. 약간 모두가 매니저가 되는 느낌과 비슷합니다. 원하는 방식으로 일을 하게 하려면 직원에게 아주 명확한 지시를 내려야 하잖아요. 이 모델들도 그와 매우 비슷합니다. 과제를 불충분하게 정의하면 결과의 분산이 매우 커집니다. 반대로 과제를 잘 특정하고, 몇 가지 예시까지 제공하면 결과가 훨씬 좋아집니다. 이건 머신러닝 스킬이라기보다 과제 정의와 매니지먼트에 가까운 기술입니다. 많은 사람들이 이 능력을 꽤 빨리 익힐 수 있다고 느껴요. 예전엔 머신러닝 박사 학위가 있어야 다룰 수 있을 것 같던 모델들에 이렇게 많은 분들이 접근하는 모습을 보며, 정말 신이 납니다.

이와 관련해서 요즘 “프롬프트 엔지니어”라는 새로운 역할 이야기를 들은 것 같아요. 원하는 일을 하도록 GPT-3를 어떻게 프롬프트해야 하는지 알아내는 역할 말이죠.

이 이야기가 흥미로운 이유는… 초기에 첫 번째 버전의 API를 내놨을 때, 세계적으로 유명한 작가이면서 동시에 프로그래머이기도 한 앤드루 메인이 있었거든요. 그는 API의 초기 사용자 중 한 명이었고, 내부적으로 “프롬프트 속삭이는 사람”, 혹은 “GPT-3 속삭이는 사람”이라는 별명을 얻었어요. 최고의 결과를 끌어내는 프롬프트를 만드는 법을 정말 잘 알��� 있었죠. 모델이 인터넷 텍스트로 학습되었기 때문에, 일종의 “인터넷 글은 어떻게 시작할까?”라는 관점을 가져야 했습니다. 정말 좋은 레시피를 원한다면, 레시피 책이나 푸드 블로그 글 같은 톤으로 글을 시작해야 했어요. 그냥 모델에게 원하는 일을 해달라고만 해서 되는 게 아니었습니다. 초기에는 이 부분이 매우 중요했다고 생각합니다. GPT-3의 미묘한 작동 방식을 이해하고, 아주 잘 설계된 프롬프트를 만드는 능력이 필요했죠. 하지만 출시 후 1년 반 정도 지나면서, 많은 사람들이 이 부분에서 어려움을 겪는 걸 보았고, 그래서 새로운 모델 세트를 개발했습니다. 우리가 그것을 InstructGPT라고 부르는데, 사실 지난주에 우리 API의 기본값이 되었어요. InstructGPT라고 부르는 이유는, 그냥 지시만 제공하면 되기 때문입니다. 그래서 지금은 프롬프트 디자인의 중요성이 예전보다 조금 줄었다고 말할 수 있어요. 모델에게 무엇을 하길 원하는지 그대로 말하고, 몇 가지 예시만 제공하면 됩니다. 여전히 형식이 예시 제공 방식에 영향을 줄 수 있는 부분은 조금 있어요. GPT-3는 그런 변화에도 굉장히 강건하지만, 가끔은 약간의 차이가 중요할 때가 있죠. 약간의 손질이 효과를 내기도 하고요. 그럼에도 불구하고, 1년 전보다 지금은 프롬프트 디자인의 비중이 확실히 줄었습니다. 그리고 제 바람은, 그 중요성이 점점 더 줄어들고, 상호작용성은 훨씬 더 커지는 것입니다.

모델을 파인튜닝할 수 있는 기능도 출시하셨잖아요. 그 배경에는 어떤 생각이 있었고, 어떤 경우에 특히 유용한가요?

GPT-3에서 놀라웠던 점은, 아무 예시도 없이 지시만으로도(제로샷) 정말 좋은 결과가 나왔다는 것입니다. 예를 들어 “이 문장을 독일어에서 영어로 번역해줘”처럼요. 또는 몇 쌍의 독일어–영어 예시를 제공하는 퓨샷 세팅에서도, 적은 예시만으로도 놀랄 만큼 괜찮은 결과를 얻을 수 있었죠. 하지만 실무적으로 이는 정확도가 과제별로 크게 달라진다는 뜻이기도 했습니다. 어떤 과제는 제품에 넣어도 될 만한 출력이 나오는 비율이 대략 30% 정도에 그치기도 하고, 더 단순한 과제는 70% 정도까지 올라가기도 했습니다. 매번 품질이 일정하지 않다면, 제품에 노출하는 방식을 매우 기민하게 설계해야 합니다. 그래서 카피라이팅 회사들에는 특히 잘 맞았어요. 몇 가지 결과만 제시해도 그중 최소 하나는 쓸 만했고, 사용자에게는 그 정도면 충분했으니까요. 하지만 파인튜닝을 하면 기본적으로 모델을 맞춤화할 수 있습니다. 원하는 입력–출력 쌍의 예시를 더 많이 제공할 수 있죠. 번역을 하든 기사 요약을 하든, 사람 손으로 쓴 요약이 달린 기사 수백 건을 예시로 주면, GPT-3를 그 작업에 훨씬 능하도록 실제로 업데이트할 수 있습니다. 이 모든 예시를 프롬프트에 다 넣을 수는 없습니다. 프롬프트에는 공간 제한이 있으니까요. 반면 파인튜닝은 이 예시들을 신경망의 연결, 즉 가중치에 스며들게 하는 과정입니다. 어떤 의미에서는 “무한한 프롬프트”를 갖게 되는 셈이죠. 원하는 만큼 예시를 제공할 수 있습니다. 물론 예시가 많을수록 파인튜닝에 시간이 더 걸리고 비용도 늘어납니다. 결국 파인튜닝은 다량의 입력–출력 예시를 모델에 녹여 넣어, 그 예시에 해당하는 특정 작업을 아주 잘하는 새로운 버전의 모델을 얻는 개념입니다. 수백 개, 많게는 백여 개 정도의 예시만으로도 정확도를 눈에 띄게 끌어올릴 수 있습니다. 이미 여러 고객이 이를 활용하고 있습니다. 예를 들어 Keeper Tax는 거래 내역을 분석해 공제 항목 등을 찾습니다. 관련 텍스트 조각을 추출하고 분류하는 등의 작업을 하죠. 이들은 모델을 파인튜닝해 훨씬 더 좋은 성능을 얻었습니다. 고객 사례에서 이런 패턴을 반복해서 봤습니다. 초기에는 프로토타입에 충분할 정도의 성능을 프롬프트만으로도 얻지만, 실제 운영 단계에서 필요한 높은 정확도—대개 90% 이상, 95% 또는 99%—에 도달하려면, 자체 보유 데이터셋이나 새로 구축한 데이터셋으로 파인튜닝하는 것이 마무리를 해줍니다. 덕분에 이전보다 훨씬 많은 애플리케이션을 구현할 수 있게 되었고, 저희는 이런 파인튜닝 과정을 매우 간단하게 만들었습니다.

W&B에 GPT-3 파인튜닝 프로젝트 로깅하기

좋네요. 그리고요, Weights & Biases 연동에 대해서도 꼭 여쭤보고 싶어요. 저희가 정말 신나 있거든요. 아마 듣고 계신 분들 중에는 모르시는 분도 있겠지만, 초창기부터 Weights & Biases를 써 주셨고, 제품에 반영된 엄청 유용한 피드백도 많이 주셨잖아요. 그런데 그 연동이 GPT-3 사용자들에게 어떻게 유용할지, 어떻게 생각하셨는지 궁금했습니다.

그래서 이게 제가 Weights & Biases를 사용하게 된 배경입니다. 초기 사용자 중 한 명이었고, 연구 워크플로가 워낙 좋아져서 지금은 Weights & Biases를 적극 추천하는 사람이 되었어요. 기본적으로 이 도구가 해주는 일은 실험을 아주 깔끔한 방식으로 추적하게 해준다는 겁니다. 모델을 학습시키는 동안 모든 통계를 볼 수 있죠. 머신러닝 모델을 학습해 본 사람이라면, 학습이 원하는 대로 이루어지는지 확인하려면 학습 중에 여러 곡선을 봐야 한다는 걸 잘 압니다. 머신러닝 엔지니어가 하는 일의 상당 부분은 모델을 반복적으로 개선해 보면서 결과를 끌어올릴 수 있는지 확인하는 겁니다. 그 과정의 많은 부분이 학습 곡선을 들여다보는 일이에요. Weights & Biases는 그동안 실행한 실험의 이력을 제공해 주기 때문에 정말 좋습니다. 실험을 서로 비교할 수 있고, 진행 상황을 추적하여 팀원들과 공유할 수도 있죠. 저희가 한 일은 이걸 통합한 겁니다. API를 통해 GPT 모델을 파인튜닝할 때, 모든 실험과 모든 학습 런이 Weights & Biases 인터페이스에 그대로 나타나도록요. 동일한 편의성을 그대로 누리되, 이제는 저희 클러스터에서 학습되는 작업에도 적용되는 거죠. 파인튜닝이 진행되는 동안—모델이 데이터셋을 반복해 지나가며 가중치를 업데이트할 때마다—메트릭이 어떻게 개선되는지 등을 확인할 수 있습니다. 또한 여러 가지 파라미터를 제공하기 때문에 값을 바꿔가며 반복 실험을 해 보고, 그에 따른 변화를 볼 수 있어요. 그렇게 하면 모델을 학습시키는 경험이 훨씬 즐거워집니다. 결과를 지속적으로 확인하러 갈 수 있는 한곳이 생기니까요. 저희에게도 무척 신나는 통합이었습니다. 모든 파인튜닝을 훨씬 더 좋은 방식으로 추적할 수 있게 해주거든요. 저희도 커맨드라인 인터페이스를 제공하긴 하지만, Weights & Biases만큼 보기 좋고 편리한 추적 방식은 아니니까요.

보리스, 실제로 당신이 그 연동 작업을 했다고 말씀하셨죠. 한 줄이면 됐다고 하셨는데, 맞나요? 그러니까 제 질문의 요지는 그 연동을 어떻게 활용할 수 있을지에 대한 당신의 생각을 듣는 거긴 한데, 궁금해서요. 정말로 한 줄짜리 연동이었나요?

코드 안에는 몇 줄 더 있지만, 사용자 입장에서는 그냥 한 줄, “openai wandb sync”만 입력하면 모든 런이 자동으로 대시보드에 동기화됩니다. 아이디어는, API를 쓰는 사람들 중엔 ML 엔지니어가 아닌 분들도 많기 때문에 “무엇을 로깅해야 하지? 데이터셋 관리는 어떻게 하지?” 같은 걸 새로 배워야 하지 않도록 하자는 것이었어요. OpenAI API는 정말 편리했죠. 모델을 학습시키고 싶다면 데이터셋 파일만 넘기면 되고, 알아서 정리해 준 다음 새 커맨드를 넘기면 파인튜닝까지 한 번에 됩니다. 그 단순함을 그대로 유지하고 싶었습니다. 그 한 줄 명령만 입력하면, 나머지 마법은 모두 백그라운드에서 일어납니다. 시각화가 전부 제공되고, 모델들을 비교하면서 “학습 샘플을 더 늘릴 가치가 있을까? 그걸로 모델이 얼마나 좋아졌지? 이 작은 파라미터를 조정했을 때 효과가 뭐지? 이 모델을 학습할 때 쓴 데이터셋은 무엇이었지?” 같은 질문에 답할 수 있어요. 초기에 Weights & Biases를 잘 모른다고 해도, 사용자들이 모든 기능의 이점을 최대한 쉽게 누릴 수 있도록 하는 것이 목표입니다.

두 분 모두께 여쭤볼게요. 실제로 조정할 수 있는 파라미터에는 뭐가 있나요? 말씀하신 방식으로 들으면 파라미터가 아예 없을 수도 있겠다는 생각이 들어서요. 여기서는 파라미터가 어떻게 개입되나요?

그 질문에 답하기에 앞서, 보리스가 말한 것 중 특히 인상 깊었던 점이 있어요. 제가 이번 통합을 전반적으로 정말 좋아했던 이유이기도 한데, 고급 기능들을 아주 단순하게 만든다는 개념입니다. 루카스, 당신과 숀, 크리스가 첫 Weights & Biases 데모를 했을 때가 아직도 기억나요. 사실상 “import wandb”만 하면 실험 로깅이 시작됐죠. 그렇게 시작을 극도로 간단하게 만드는 철학은 저희 API에도 동일하게 적용하려고 노력한 부분입니다. “import openai” 한 뒤에 단 한 번의 API 호출이나 Python, JavaScript 코드로 GPT-3를 바로 써서 컴플리션을 만들 수 있죠. 그 단순함이 정말 마음에 들었고, 이번 통합에서도 그 점을 그대로 구현하��� 했습니다. 이제 파라미터에 대한 질문으로 돌아가 보면, 저희는 API에서 이를 꽤 단순하게 만들려 했습니다. 기본값을 매우, 매우 잘 설정해 두었어요. 대체로 파라미터를 거의 건드리지 않아도 파인튜닝만으로 아주 좋은 결과를 얻을 수 있지만, 성능에 더 큰 영향을 주는 것들도 있습니다. 예를 들어 학습률을 설정할 수 있어요. 각 학습 스텝마다 가중치를 얼마나 업데이트할지 정하는 값이죠. 데이터를 몇 번 반복해 학습할지도 설정할 수 있습니다. 데이터를 너무 많이 반복하면 데이터셋에 과적합되기 쉽다는 점이 드러났어요. GPT-3 같은 거대한 모델의 경우, 보통은 데이터를 두 번에서 다섯 번 정도만 반복해도 매우 좋은 결과를 얻는 편입니다. 그 이상 가면 때로는 과적합이 발생하죠. 더 고급 파라미터들도 있지만, 개인적으로는 학습 에폭 수와 학습률만 조금 만져도 90%는 해결된다고 봅니다. 다른 파라미터들을 이리저리 조정해도 추가 이득은 그다지 크지 않을 때가 많습니다.

파라미터를 남겨 둔 것도 사용자가 직접 만져 보면서 얻는 재미를 주려는 의도가 있었나요?

솔직히 완전히 자동이면 정말 좋겠어요. 그렇다고 해도, 실험을 직접 만져 보는 걸 정말 좋아하는 연구 지향 고객들도 꽤 있습니다. 그래서 그걸 아예 없애기는 우리에게도 쉽지 않을 것 같아요. 하지만 말씀드린 대로, 사용자층이 두 부류가 있습니다. 연구자와 개발자죠. 개발자들은 계속 “버튼 하나면 끝나게 해 주세요. 그냥 최고의 모델이 나오면 됩니다.”라고 말하고, 연구자들은 파라미터를 더 만져 보고 싶어 하죠. 아마 우리는 꽤 오랫동안 두 부류 모두를 만족시킬 수 있을 거라고 봅니다.

보리스, 본인은 어느 쪽에 속한다고 생각하나요? 멋지고 인상적인 데모를 많이 만드시고, 또 파라미터 만지는 것도 좋아하시잖아요. GPT-3 모델을 가지고 직접 이것저것 시도해 본 경험이 궁금합니다.

기본값이 잘 설정되어 있는 건 정말 좋아요. 처음에는 무엇을 바꿔야 할지 잘 모르잖아요. 잘못된 파라미터를 골라서 아무것도 작동하지 않으면 최악의 경험이니까요. 그래서 아무것도 건드리지 않아도 이미 꽤 좋은 결과가 나오는 점이 마음에 들어요. 그다음에는 파라미터를 하나씩 조정해 보면서 “이건 어떤 효과가 있지?” 하고 직관을 검증해 보는 걸 정말 좋아합니다. 피터가 말한 파라미터들 외에, 제가 특히 관심 있는 게 두 가지 더 있어요. 첫째, 어떤 모델을 파인튜닝할지 결정할 수 있다는 점입니다. 모델 크기가 서로 다르죠. 더 큰 모델을 쓰면 API가 조금 느려질 수 있지만, 출력 품질은 더 좋아질 수 있어요. 어떤 때는 그럴 필요가 없고, 어떤 때는 확실히 필요할 수도 있죠. 그래서 어떤 모델을 쓰느냐에 따른 효과를 보는 걸 좋아합니다. 둘째, “학습 샘플을 몇 개까지 줄 수 있나?”의 효과를 보는 겁니다. 예를 들어 20개만 주는 경우와 100개, 200개를 주는 경우를 비교해 보는 거죠. 그러면 데이터셋을 늘려 갈수록 내 모델이 얼마나 더 좋아지는지 감이 잡혀요. 이처럼 저는 여러 가지 파라미터들을 가지고 놀면서, 그에 따라 예측이 어떻게 달라지는지 확인하는 걸 좋아합니다.

맞아요, 방금 그 부분이 정말 중요합니다. 우리가 사람들에게 반복해서 가장 자주 하는 조언 중 하나라고 생각해요. 작은 예시 세트로 시작해서, 그다음엔 두 배로 늘리고 얼마나 개선되는지 보세요. 보통은… 학습 데이터를 두 배로 늘리면 오류율이 선형적으로 개선되는 경향을 볼 수 있어요. 예를 들어 오류율이 10%였다가 학습 데이터를 두 배로 늘리면 8% 정도로 내려가고, 다시 두 배로 늘리면 6%로 내려가는 식이죠. 그런 추세가 보이기 시작하면, “원하는 결과를 얻으려면 데이터 라벨링 비용 등으로 실제로 얼마나 들까?”를 금방 가늠할 수 있게 됩니다. 이건 정말 강력한 접근법입니다.

이 모델들을 학습시킨 결과는 재현 가능할까요? 매번 파인튜닝할 때 변동성이 어느 정도 있나요? 같은 데이터로 두 번 파인튜닝하면 동일한 모델을 얻을 수 있나요?

원칙적으로는 재현 가능성을 꽤 높게 설정할 수 있습니다. 동일한 데이터로 학습한다는 전제에서… 기본적으로 학습 시에 각 이터레이션마다 여러 개의 예시로 이루어진 배치를 사용합니다. API에서 배치 크기, 즉 한 번의 업데이트에 사용할 예시 수를 설정할 수 있고, 기본값은 32 정도였던 것으로 기억합니다. 그때 데이터를 섞는 것도 중요합니다. 학습 데이터에서 무작위로 샘플을 뽑아야 하죠. 그 무작위화 과정을 학습 실행 간에 일관되게 유지하면, 결국 거의 같은 모델을 얻게 됩니다. 재현성은 꽤 높게 나옵니다. 다만 한 가지 주의할 점은, 실제로는 추론 단계에서도 마찬가지라는 겁니다. 출력의 변동성을 조절하는 temperature라는 파라미터가 있는데, 값을 높일수록 변동성이 커집니다. 0으로 두더라도 완전히 결정적인 출력을 보장하긴 어렵습니다. 아주 큰 모델을 GPU에서 돌릴 때 부동소수점 연산 특성 등으로 인한 노이즈와 약간의 비정상성이 존재하기 때문에, 완전한 결정성을 보장하는 건 매우 어렵습니다. 이 부분에 대해 자주 문의를 받는데, 답변은 늘 “안타깝지만 그 보장은 드릴 수 없습니다. 다만 꽤 높은 수준의 재현성은 얻을 수 있습니다.”에 가깝습니다. 결국 실험 자체를 결정성에 과도하게 의존하지 않도록 충분히 견고하게 설계하는 것이 좋습니다.

OpenAI API 뒤에 숨은 엔지니어링 과제들

운영 관점에서 보면, 모든 사람이 각자 파인튜닝한 모델을 가지도록 하는 것은, 모두가 같은 모델을 호출하는 API를 사용하는 것보다 인프라 측면에서 훨씬 더 큰 도전일 것 같습니다. 그걸 가능하게 하는 데 큰 노력이 필요했나요? 예를 들어, 사람들이 자신들의 모델을 쓰기 시작하면 서로 다른 모델을 계속 바꿔 끼워야 하나요?

네, 맞아요. 확실히요. 초기에 우리가 파인튜닝을 하던 방식은… 일종의 GPU 세트를 임대해서 그 위에서 모델을 돌리는 형태였어요. 가장 초기 파인튜닝 고객 일부에게는 GPU 사용 시간당 과금하기도 했습니다. 즉, 모델을 얼마나 오래 돌렸는지에 따라 시간 단위로 요금을 받았죠. API를 출시하고 6개월쯤 지났을 때부터 이미 파인튜닝된 모델을 쓰는 몇몇 선택된 고객들이 있었고, 당시엔 그런 방식으로 운영됐습니다. 문제는 새로운 시도를 해보려면 GPU 시간이 비싸다는 겁니다. 1시간의 일부만 쓰더라도 GPU를 예약하는 비용을 내고 싶지 않잖아요. 비용이 정말, 정말 빠르게 불어납니다. 그래서 목표를 이렇게 잡았습니다. “파인튜닝이 끝나자마자 바로 그 모델을 쓸 수 있어야 하고, 추론 시에는 들어가는 토큰에 대해서만 비용을 내도록 하자.” 즉, 프롬프트에 넣는 것 기준으로 과금하자는 거죠. 그 경험을 훌륭하게 만드는 건 정말 큰 엔지니어링 과제였어요. 사용자는 파인튜닝을 시작만 하면 되고, 끝나면 파인튜닝된 모델 이름을 받습니다. 이제 그 모델을 API에서 바로 써서 곧바로 결과를 얻을 수 있죠. 시간 단위 과금 같은 건 없고, API와 동일한 방식으로 과금됩니다. 이건 정말 까다로운 일이었습니다. OpenAI에는 훌륭한 엔지니어링 팀이 있어서, 모델을 어디에 배치할지 균형을 맞추고, 적절한 방식으로 캐시하는 등 여러 가지 트릭을 통해 그 경험을 아주 좋게 만드는 데 성공했습니다.

전체 모델을 파인튜닝하는지, 아니면 효율성을 높이기 위해 일부만 파인튜닝하는지 궁금합니다.

우리가 이걸 가능하게 만들기 위해 쓰는 트릭이 정말 많습니다. 늘 새로운 방법을 찾아내려고 노력하고 있어요. 750억 개 파라미터의 전체 모델을 파인튜닝하려고 하면 여러 가지 도전 과제가 생깁니다. 비용도 정말 많이 들고 어렵기도 하고요. 다만 훨씬 더 빠르게 만들 수 있는 여러 가지 요령들이 있습니다.

여러분이 자연어 작업에 GPT-3를 사용하는 데 있어 가장 큰 장벽이 모델 자체의 품질과 성능이라고 느끼시나요? 아니면 다른 무언가일까요? 통합, 프로덕션 환경에서의 모니터링 같은 문제인가요, 혹은 그와 비슷한 걸까요?

우리가 API를 만들 때 가장 ���점적으로 본 핵심은… 무엇보다 모델의 역량이었습니다. 그다음으로 중요한 건 빠른 추론 속도였죠. 우리 API를 만들기 전에는, 언어 모델 분야에서 추론은 거의 신경 쓰지 않았습니다. 모두가 학습을 얼마나 빨리 끝낼 수 있느냐만 관심 있었죠. 그래야 결국 벤치마크를 당일에 해결할 수 있으니까요. 우리는 추론을 엄청나게 빠르게 만들기 위해 정말 많은 엔지니어링을 했습니다. 첫 API 프로토타입을 고객이 쓰기 시작한 뒤 몇 달 동안, 추론 속도를 대략 200배 가까이 끌어올렸던 걸 기억합니다. 엄청난 노력이 투입됐고, 그 결과 매우 빨라졌죠. 세 번째는 안전과 관련된 부분입니다. 우리가 InstructGPT 모델에 투자한 이유 중 하나는, 가끔 예기치 못한 놀라운 출력이 나온다는 걸 봤기 때문이에요. 예를 들어 아주 순한 문장을 넣었는데 어떤 이유로 갑자기 매우 어두운 방향으로 흐를 수 있고, 여러 방식으로 편향된 출력이 나올 수도 있죠. 지시 기반 모델은 기본적으로 훨씬 예측 가능한 방식으로 동작하고, 원하는 행동을 더 잘 명시할 수도 있습니다. 안전과 역량이 함께 가면, 제어 가능성이 높아질수록 제품은 더 좋아진다는 게 드러났습니다. 이것들이 우리가 확실히 집중해 온 부분이고, 기존 대안들보다 훨씬 잘하고 있다고 생각합니다. 그리고 또 하나… 우리가 크게 집중한 세 번째 축은 정말 쓰기 쉽게 만드는 것이었습니다. 모델을 직접 로드할 필요가 없고, 파인튜닝된 모델을 API로 한 줄짜리 Python 호출로 바로 쓸 수 있다는 사실이 우리에게 매우 중요했어요. 모두가 쉽게 사용할 수 있도록 만드는 것이 우리의 목표입니다.

아웃트로

멋집니다. 정말 감사합니다. 이렇게 이야기 나눌 수 있어 기쁘고, 훌륭한 제품을 만드신 것 축하드립니다. 인터뷰를 재미있게 보셨고 더 알아보고 싶다면, 설명란의 쇼 노트 링크를 클릭하세요. 언급된 모든 논문 링크, 보조 자료, 그리고 저희가 공들여 제작한 녹취록을 확인하실 수 있습니다. 꼭 살펴보세요.