https://www.youtube.com/watch?v=T9aRN5JkmL8
기본적으로 이 전체 원탁 토론 세션은 주로 프롬프트 엔지니어링에 초점을 맞출 것입니다.
여기 이 원탁에는 연구 측면, 소비자 측면, 엔터프라이즈 측면에서 프롬프트에 대한 다양한 관점이 있습니다.
그리고 저는 다양한 의견을 얻고 싶습니다. 왜냐하면 많은 의견이 있기 때문입니다.
그리고 토론을 열어서 프롬프트 엔지니어링이 실제로 무엇이며 무엇에 관한 것인지 살펴보겠습니다.
네, 거기서부터 시작하겠습니다. 먼저 돌아가면서 자기소개를 해볼까요? 제가 시작하겠습니다. 저는 알렉스입니다.
저는 Anthropic에서 개발자 관계를 이끌고 있습니다.
그 전에는 Anthropic에서 프롬프트 엔지니어였습니다.
프롬프트 엔지니어링 팀에서 일했고, 솔루션 아키텍트 유형의 작업부터 연구 측면의 작업까지 다양한 역할을 수행했습니다.
그럼, 데이빗에게 넘기겠습니다.
네. 제 이름은 데이빗 허쉬입니다.
저는 주로 Anthropic에서 고객과 함께 기술적인 문제에 대해 작업합니다. 저는 사람들이 파인 튜닝을 하는 데 도움을 주지만, 프롬프트의 언어 모델을 채택하기 어렵게 만드는 일반적인 문제도 많이 다룹니다.
그리고 언어 모델을 사용하여 시스템을 구축하는 방법, 프롬프트를 사용하는 방법 등을 다루지만, 대부분의 시간은 고객과 함께 작업합니다.
멋지네요. 저는 아만다 아스켈입니다.
Anthropic의 파인 튜닝 팀 중 하나를 이끌고 있는데, Claude를 정직하고 친절하게 만드는 일을 합니다.
네.
제 이름은 잭 위튼입니다.
Anthropic의 프롬프트 엔지니어입니다.
알렉스와 저는 항상 누가 첫 번째였는지에 대해 논쟁합니다.
그는 자신이라고 하고, 저는 제가라고 합니다.
논쟁의 여지가 있네요.
네.
저는 예전에 데이빗이 지금 하는 것처럼 개별 고객과 많은 작업을 했습니다.
그리고 팀에 더 많은 솔루션 아키텍트를 영입하면서, 프롬프트 생성기와 사람들이 사용하는 다양한 교육 자료처럼 사회 전반의 프롬프트 수준을 높이는 데 도움이 되는 작업을 시작했습니다.
멋지네요. 여기 와주셔서 감사합니다.
이제부터 나머지 대화를 진행하기 위한 틀을 마련하기 위해 매우 광범위한 질문으로 시작하겠습니다.
프롬프트 엔지니어링이란 무엇입니까? 왜 엔지니어링이라고 부릅니까? 프롬프트는 실제로 무엇입니까?
시작하고 싶은 사람이 있으면 자신의 관점에서 자유롭게 말씀해주세요.
프롬프트 엔지니어가 있네요. 그의 일이잖아요.
우리 모두는 나름대로 프롬프트 엔지니어입니다.
하지만 우리 중 한 명만 직업이 있잖아요.
네. 잭, 당신의 직함에 있으니까 말씀해주세요.
우리 중 한 명만 직업이 있고, 나머지 세 명은 직업이 없습니다.
제 생각에 프롬프트 엔지니어링은 모델이 일을 하도록 하는 것입니다. 모델을 최대한 활용하려고 노력하는 것입니다.
모델과 협력하여 이전에는 할 수 없었던 일을 해내려고 노력하는 것입니다.
그래서 많은 부분이 명확한 의사소통입니다.
제 생각에 근본적으로 모델과 대화하는 것은 사람과 대화하는 것과 매우 비슷합니다.
그리고 모델의 심리학을 이해하는 것이 중요합니다. 아만다는 세계 최고의 전문가입니다.
계속 질문하겠습니다. 왜 엔지니어링이라는 이름이 붙었습니까?
네.
엔지니어링이라는 부분은 시행착오에서 비롯되었다고 생각합니다.
모델과 대화할 때 좋은 점 중 하나는 사람과 대화하는 것과 달리 다시 시작 버튼이 있다는 것입니다.
처음부터 다시 시작할 수 있는 거대한 버튼이죠.
이를 통해 할 수 있는 일은 사람과 대화할 때와 달리 처음부터 다시 시작하여 서로 간섭 없이 독립적인 방식으로 다른 것을 시도해 볼 수 있다는 것입니다.
실험하고 다른 것을 설계할 수 있는 능력이 있다면 엔지니어링이라는 부분이 빛을 발할 수 있습니다.
알겠습니다.
그러니까 당신이 말하는 것은 프롬프트를 작성할 때 Claude 또는 API에 메시지를 입력하고,
모델과 주고받으면서 이 메시지를 반복하고,
매번 깨끗한 상태로 되돌릴 수 있다는 것입니다.
그 과정이 엔지니어링 부분이라는 것입니다.
이 모든 것이 프롬프트 엔지니어링입니다.
또 다른 측면은 시스템 전체에 프롬프트를 통합하는 것입니다.
데이빗은 고객과 통합 작업을 많이 해왔습니다.
프롬프트를 작성하고 모델에 제공하면 끝나는 경우는 거의 없습니다.
사실, 그렇지 않습니다. 훨씬 더 복잡합니다.
네.
프롬프트는 모델을 프로그래밍하는 방법이라고 생각합니다. 너무 복잡하게 만들었네요.
잭이 말한 것처럼 명확하게 말하는 것이 가장 중요하다고 생각합니다.
하지만 모델을 프로그래밍한다고 생각한다면 데이터가 어디에서 오는지, 어떤 데이터에 액세스할 수 있는지 생각해야 합니다.
RAG를 한다면 실제로 사용하고 모델에 전달할 수 있는 것이 무엇일까요?
지연 시간과 제공하는 데이터 양 등의 트레이드오프를 고려해야 합니다.
모델을 중심으로 실제로 구축하는 방법에는 시스템적 사고가 충분히 필요합니다.
이러한 이유로 소프트웨어 엔지니어나 PM과는 별개로 고려해야 할 부분이라고 생각합니다.
일종의 자체 영역입니다. 이러한 모델을 어떻게 생각해야 하는지에 대한 영역입니다.
이런 의미에서 프롬프트는 자연어 코드입니까? 더 높은 수준의 추상화입니까? 아니면 별개의 것입니까?
프롬프트를 너무 추상적으로 만들려고 하면 너무 복잡해집니다. 나중에 자세히 설명하겠지만, 대부분의 경우 해야 할 일은 그냥 작업에 대한 매우 명확한 설명을 작성하는 것이지, 복잡한 추상화를 구축하려고 하는 것이 아닙니다.
하지만 그렇다고 해서 일련의 지침과 같은 것을 결과물로 컴파일하지 않는다는 것은 아닙니다.
그래서 버전 제어와 실험 당시의 모습을 관리하는 프로그래밍에서 고려하는 정밀도와 많은 것들,
실험을 추적하고 그런 것들은 코드만큼 중요합니다.
네.
그래서 쓴 텍스트, 잘 쓴 에세이가 코드와 같은 것으로 취급되는 이러한 패러다임에 있는 것이 이상합니다.
하지만 이제 우리는 에세이를 쓰고 코드처럼 취급하며, 저는 그것이 옳다고 생각합니다.
네. 흥미롭네요.
프롬프트 엔지니어링이 무엇인지 대략적으로 정의했습니다. 그렇다면 좋은 프롬프트 엔지니어는 무엇일까요?
아만다, 당신은 연구 환경에서 프롬프트 엔지니어를 고용하려고 하니까 당신에게 물어보겠습니다.
어떤 사람을 찾고 있습니까?
네, 좋은 질문입니다.
잭이 말했듯이 명확한 의사소통, 즉 명확하게 말하고, 작업을 명확하게 이해하고, 개념을 잘 생각하고 설명할 수 있는 능력이 중요하다고 생각합니다.
그것이 글쓰기 능력이라고 생각합니다.
저는 글을 잘 쓰는 것이 사람들이 생각하는 것만큼 좋은 프롬프트 엔지니어가 되는 것과 관련이 있다고 생각하지 않습니다.
사람들과 이런 이야기를 나눈 적이 있습니다. 왜냐하면 "엔지니어라는 이름을 빼는 게 좋을 것 같다. 왜 작가라고 하지 않을까?"라는 주장이 있기 때문입니다.
예전에는 그런 주장에 더 동의했습니다.
하지만 이제는 사람들이 한 가지를 쓰면 끝이라고 생각하는데,
괜찮은 프롬프트를 얻으려면 모델과 함께 앉아서 작업해야 합니다.
아까 모델에 프롬프트를 하고 있었는데 15분 만에 수백 개의 프롬프트를 모델에 보냈습니다.
그냥 계속해서 주고받는 것입니다.
그래서 반복하고 살펴보려는 의지가 중요하다고 생각합니다.
여기서 잘못 해석된 부분이 있다면 무엇일까요?
그리고 그것을 고칩니다.
그래서 반복할 수 있는 능력이 중요합니다.
명확한 의사소통, 반복할 수 있는 능력이라고 말씀드리겠습니다.
프롬프트가 잘못될 수 있는 경우에 대해 생각해 보는 것도 중요하다고 생각합니다.
예를 들어, 400개의 사례에 적용할 프롬프트가 있다면,
일반적인 사례를 생각해 보고 해당 사례에서 올바른 솔루션을 얻는지 확인한 다음 넘어가는 것이 정말 쉽습니다.
사람들이 저지르는 매우 전형적인 실수라고 생각합니다.
실제로 해야 할 일은 특이한 사례를 찾는 것입니다.
프롬프트를 생각해 보고 "이 경우에는 어떻게 해야 할지 정말 모르겠다"는 사례가 무엇인지 생각해야 합니다.
예를 들어, "데이터를 보낼 테니 누군가의 이름이 G로 시작하는 모든 행을 추출해 달라"는 프롬프트가 있다고 가정해 보겠습니다.
그리고 "G로 시작하는 이름이 없는 데이터 세트를 보낼 것이다.
데이터 세트가 아닌 것을 보낼 것이다. 빈 문자열을 보낼 수도 있다. 이 모든 경우를 시도해 봐야 한다. 왜냐하면 '이런 경우에는 어떻게 될까?'라는 생각이 들기 때문이다."
그리고 해당 경우에 어떻게 처리해야 하는지에 대한 지침을 더 줄 수 있습니다.
저는 고객과 함께 일할 때 엔지니어가 무언가를 구축하는 경우를 자주 봅니다.
프롬프트에 고객이 무언가를 쓸 부분이 있습니다.
네.
그들은 모두 누군가가 챗봇에 입력할 것이라고 생각하는 완벽하게 표현된 문구를 생각합니다.
네.
실제로는 Shift 키를 사용하지 않고 모든 단어가 오타입니다.
구글이라고 생각하는 거죠.
구두점이 없습니다.
질문 없이 무작위 단어를 입력합니다.
맞습니다.
따라서 사용자가 이상적으로 입력할 것이라고 생각하는 아름답게 구성된 평가가 있습니다.
하지만 실제 트래픽이 어떨지, 사람들이 실제로 무엇을 하려고 할지 생각할 수 있어야 합니다.
그것은 다른 수준의 사고입니다.
모델 응답을 읽는다는 말씀이 정말 와닿습니다.
머신 러닝 맥락에서 데이터를 살펴봐야 합니다.
데이터를 살펴보라는 말은 거의 진부한 표현이고, 프롬프트에서도 모델 출력을 살펴보는 것이 그에 상응한다고 생각합니다.
많은 출력을 읽고 자세히 읽는 것입니다.
데이빗과 저는 오는 길에 사람들이 하는 일 중 하나가 프롬프트에 단계별로 생각해보라고 입력하는 것이라는 이야기를 나누었습니다.
모델이 실제로 단계별로 생각하고 있는지 확인하지 않습니다.
모델은 더 추상적이거나 일반적인 의미로 받아들일 수 있기 때문입니다.
"아니, 말 그대로 특정 태그에 생각을 적어야 해."
모델 출력을 읽지 않으면 그런 실수를 하는지도 모를 수 있습니다.
네, 흥미롭네요.
프롬프트 엔지니어가 되려면 이상한 심리 이론이 필요합니다. 거의 모델이 지침을 어떻게 볼지 생각해야 합니다.
하지만 엔터프라이즈 사용 사례를 위해 글을 쓰는 경우 사용자가 모델과 어떻게 대화할지 생각해야 합니다.
당신은 그 이상한 관계 속에 있는 제3자이기 때문입니다.
네.
심리 이론에 대해 한 가지 말씀드리자면, 작업에 대한 지침을 적는 것이 정말 어렵습니다.
Claude가 모르는 모든 것을 자신의 뇌에서 풀어내서 적는 것이 정말 어렵습니다.
자신이 가지고 있는 모든 가정을 없애고 모델에 필요한 모든 정보를 매우 명확하게 전달할 수 있어야 한다는 것은 엄청나게 어려운 일입니다.
좋은 프롬프트 엔지니어와 나쁜 프롬프트 엔지니어를 구분하는 또 다른 요소는...
많은 사람들이 자신이 아는 것만 적습니다.
하지만 이 작업을 이해하기 위해 실제로 알아야 할 정보는 무엇인지 체계적으로 분석하지 않습니다.
맞습니다.
그리고 그것이 제가 많이 보는 명확한 문제입니다.
누군가가 작성한 프롬프트가 작업에 대한 사전 이해에 너무 conditioned 되어 있어서,
저에게 보여주면 "이게 무슨 말인지 모르겠다.
당신이 쓴 단어 중 어느 것도 이해가 되지 않는다. 당신의 흥미로운 사용 사례에 대해 전혀 모르기 때문이다"라고 말합니다.
하지만 그런 면에서 프롬프트 엔지니어링을 생각하는 좋은 방법이자 좋은 기술은 자신이 아는 것에서 벗어나 많은 것을 알지만,
작업을 수행하기 위해 알아야 할 모든 것을 알지 못하는 이 이상한 시스템과 소통할 수 있는지 여부입니다.
네.
누군가의 프롬프트를 보고 "이 프롬프트만 봐서는 작업을 수행할 수 없다"고 말한 적이 몇 번이나 됩니다.
저는 인간 수준이고 당신은 저보다 못한 무언가에 이것을 맡기고 더 잘하기를 기대하고 있습니다. 저는 "네"라고 말합니다.
네.
흥미로운 점은...
현재 모델은 사람처럼 좋은 질문을 하는 데 능숙하지 않습니다.
제가 잭에게 무언가를 하는 방법에 대한 지침을 주면 잭은 "이게 무슨 말인지 모르겠다. 이 단계나 여기, 여기에서는 무엇을 해야 하나?"라고 말할 것입니다.
모델은 그렇게 하지 않습니다. 그래서 자신이 직접 다른 사람이 무엇을 말할지 생각해 보고 프롬프트로 돌아가서 그 질문에 답해야 합니다.
그렇게 하라고 요청할 수도 있습니다.
그럴 수도 있죠. 맞습니다.
저는 그렇게 합니다.
그게 또 다른 단계입니다.
처음 프롬프트를 할 때 가장 먼저 하는 일 중 하나는 프롬프트를 입력한 다음 "이 지침을 따르지 마세요. 그냥 불분명하거나 모호한 부분이나 이해하지 못하는 부분을 말해주세요"라고 말하는 것입니다.
항상 완벽하게 이해하는 것은 아니지만, 그렇게 할 수 있다는 것은 흥미로운 일입니다.
그리고 때때로 사람들은 모델이 실수를 하는 것을 보고 모델에게 묻지 않는 경우가 있습니다.
모델에게 "이 부분을 잘못했네. 왜 잘못했는지 생각해 볼 수 있니?
그리고 앞으로 잘못하지 않도록 지침을 수정해 줄 수 있니?"라고 말합니다.
그리고 많은 경우 모델이 제대로 이해합니다.
모델은 "아, 네. 불분명했던 부분은 여기이고, 지침을 수정한 부분은 여기입니다."라고 말합니다.
그리고 그것을 입력하면 작동합니다.
알겠습니다.
개인적으로 정말 궁금합니다.
정말 그렇게 됩니까?
모델이 그런 식으로 자신의 실수를 알아차릴 수 있을까요?
잘못된 부분이 있으면 "왜 잘못했니?"라고 말합니다.
그리고 모델은 "앞으로 제대로 이해할 수 있도록 어떻게 표현해야 할까요?"와 같은 말을 합니다.
정말 그럴까요?
아니면 모델이 자신의 한계를 어떻게 생각하는지에 대한 환각일까요?
모델에게 무엇을 잘못했는지 설명하면 때때로 쿼리에서 잘못된 부분을 찾아낼 수 있다고 생각합니다.
작업에 따라 다릅니다.
이건 몇 퍼센트나 맞는지 모르겠지만, 항상 시도해 봅니다. 왜냐하면 때때로 맞기 때문입니다.
그리고 무언가를 배우죠.
네.
모델로 돌아가거나 모델과 주고받을 때마다 무슨 일이 일어나고 있는지 알게 됩니다.
적어도 시도해 보지 않으면 정보를 놓치는 것입니다.
흥미롭네요.
아만다, 몇 가지 질문을 더 드리겠습니다.
이 영상을 보고 계신 모든 분들을 위해 말씀드리자면, Anthropic에는 Slack 채널이 있습니다.
사람들이 Slack 채널에 Claude를 추가할 수 있고,
그러면 Claude와 대화할 수 있습니다.
그리고 아만다는 많은 사람들이 Claude와의 상호 작용을 지켜보는 Slack 채널을 가지고 있습니다.
그리고 아만다가 항상 그곳에서 하는 일 중 하나는,
아마도 Anthropic에서 가장 많이 하는 일일 텐데,
다양한 시나리오에서 모델을 사용하여 자신을 돕는 것입니다.
연구 환경에서 모델을 많이 신뢰하는 것 같습니다.
모델을 언제 신뢰해야 할지에 대한 직관을 어떻게 키웠는지 궁금합니다.
단순히 사용량이나 경험의 문제일까요? 아니면 다른 이유가 있을까요?
저는 모델을 절대 신뢰하지 않고 계속해서 두드려봅니다.
그래서 제가 그렇게 하는 것을 자주 보시는 이유는 "이 작업을 맡겨도 될까?"라고 생각하기 때문입니다.
어떤 면에서는 모델이 이상합니다.
분포에서 약간 벗어나면 훈련되지 않았거나 특이한 영역으로 들어가게 됩니다.
때로는 "실제로 여기서는 훨씬 덜 안정적이네요. 비교적 간단한 작업인데도 말이죠."라는 생각이 듭니다.
모델이 발전하면서 점점 줄어들고 있지만, 그런 공간에 있지 않은지 확인해야 합니다.
그래서 기본적으로 신뢰하지는 않지만, ML에서 사람들은 종종 정말 큰 데이터 세트를 살펴보고 싶어합니다.
저는 "언제 그렇게 하는 것이 합리적일까?"라고 생각합니다.
각 데이터 포인트에서 얻는 신호가 상대적으로 적을 때, 즉 노이즈를 제거하기 위해 많은 데이터 포인트를 살펴봐야 할 때라고 생각합니다.
프롬프트 작업의 경우 각 쿼리에서 실제로 매우 높은 신호를 얻는다고 생각합니다.
잘 구성된 수백 개의 프롬프트 세트가 있다면,
잘 만들어지지 않은 수천 개의 프롬프트보다 훨씬 더 많은 신호를 얻을 수 있다고 생각합니다.
그래서 100개의 출력을 살펴보고 정말 일관성이 있다면 모델을 신뢰할 수 있다고 생각합니다.
그리고 저는 기본적으로 모든 엣지 케이스와 모델이 할 수 있는 모든 이상한 것들을 파악하기 위해
이상한 입력 등을 구성했습니다.
훨씬 더 느슨하게 구성된 수천 개의 세트보다 더 신뢰합니다.
ML에서는 신호가 숫자인 경우가 많습니다.
이것을 제대로 예측했는지 여부입니다.
모델의 로그 확률을 살펴보고 직관적으로 파악하려고 노력하는 것인데, 할 수는 있지만 다소 불안정합니다.
모델이 출력하는 것이 대부분 단어와 같은 것들이라는 사실이 저에게는 근본적으로 배울 것이 너무 많다는 것을 의미합니다.
무엇을 쓰고 왜, 어떻게 쓰는지 그 이면에는 배울 것이 너무 많습니다.
그냥 작업을 제대로 했는지 여부가 아닙니다.
"어떻게 했지? 어떻게 생각했지? 어떤 단계를 거쳤지?"와 같은 것입니다.
무슨 일이 일어나고 있는지 많이 알게 되거나, 적어도 더 잘 이해하려고 노력할 수 있다고 생각합니다.
하지만 저에게 많은 정보가 오는 곳은 결과를 통해서가 아니라 나온 내용의 세부 사항을 읽는 것입니다.
또한 최고의 프롬프트는 실패한 실험과 성공적인 실험의 차이를 만들 수 있다고 생각합니다.
그래서 때로는 사람들이 실험의 프롬프트 구성 요소에 충분히 집중하지 않으면 짜증이 날 수 있습니다.
왜냐하면 "이것이 실제로 모델 성능 1% 차이 또는 0.1% 차이를 만들 수 있다"고 생각하기 때문입니다.
모델 성능이 상위 5%이면 실험이 성공하지 못하지만, 상위 1% 또는 상위 0.1%이면 성공할 수 있습니다.
"실험 코드를 정말 잘 짜는 데 시간을 쓰면서 프롬프트에는 시간을 쓰지 않는다면..."
모르겠습니다.
말이 안 됩니다. 그것이 실험의 성패를 가를 수 있기 때문입니다.
네.
배포에서도 "이걸 배포할 수 없다"고 말하기가 너무 쉽습니다.
그리고 프롬프트를 바꾸면 갑자기 작동합니다.
네.
양날의 검입니다. 프롬프트에 대해 조금만 생각해 보면,
항상 지평선 너머에 있는 신화 속의 더 나은 프롬프트가 내 문제를 해결해 줄 거라는 생각이 듭니다.
네.
많은 사람들이 지평선 너머에 있는 신화 속의 프롬프트에 갇혀 있다고 생각합니다. 계속 노력하면, 계속 노력하면...
프롬프트를 조금 다듬는 것은 나쁘지 않습니다. 말씀드렸듯이 무언가를 배우게 됩니다.
하지만 프롬프트의 무서운 점 중 하나는 알 수 없는 세계가 있다는 것입니다.
완벽한 프롬프트를 사용하여 무언가를 할 수 있는지 여부를 판단하는 기준은 무엇입니까?
모델이 어느 정도 이해하고 있는지 확인하는 편입니다.
프롬프트가 도움이 되지 않을 것이라고 생각되는 경우에는 조금 다듬어봅니다.
하지만 종종 가까워지지 않는다는 것이 분명해집니다.
네.
"모델이 무언가를 할 수 없다는 것이 분명하면 오랫동안 다듬지 않을 것이다"라는 이상한 생각이 드는군요.
이 부분은 어떻게 생각하는지 이끌어낼 수 있는 부분이고, 어떻게 생각하는지, 왜 그렇게 생각하는지 물어볼 수 있는 부분입니다.
적어도 제대로 생각하고 있는지 알 수 있습니다.
우리가 제대로 가고 있는 걸까요?
적어도 제대로 가고 있다는 느낌을 받을 수 있습니다.
어떤 작업은 정말 가까워지지 않는 경우가 있습니다.
아무리 조정해도 완전히 다른 잘못된 방향으로 가기만 하고, 저는 그런 작업은 포기하는 편입니다.
모르겠습니다.
하지만 요즘에는 그런 경우가 너무 드물어서, 그런 경우를 발견하면 모델에 정말 화가 납니다.
너무 화가 납니다.
"내가 제대로 방향만 잡아주면 할 수 없는 작업이 있다니, 어떻게 감히!"라고 말합니다.
최근에 Claude가 포켓몬을 하는 것에 대해 생각해 봤는데, 그때가 정말...
네, 설명해 주시겠어요?
사람들에게 설명해 주세요. 정말 멋진 것 같습니다.
Claude를 게임보이 에뮬레이터에 연결해서 OG 포켓몬처럼 포켓몬 레드 게임을 하도록 하는 실험을 해봤습니다.
그리고 생각하는 대로 버튼을 누르는 코드를 쓸 수 있을 거라고 생각했는데,
꽤 기본적인 내용입니다.
다양하고 복잡한 프롬프트 레이아웃을 시도해 봤지만, 정말 할 수 없는 부분이 있었습니다.
게임보이 스크린샷을 보여주면 정말 할 수 없었습니다.
너무 익숙해서 너무 답답했습니다.
무언가를 할 수 있어야 하니까요.
그래서 주말 내내 더 나은 프롬프트를 작성하여 게임보이 화면을 제대로 이해하도록 노력했습니다.
점점 나아져서 완전히 신호가 없는 대신 끔찍할 정도가 되었습니다.
신호가 없던 상태에서 신호가 있는 상태로 갈 수 있었습니다.
하지만 적어도 저에게는 이끌어낸 것이었습니다.
주말 내내 시간을 투자해서 신호가 없던 상태에서 신호가 있는 상태로 갔지만, 충분히 좋지 않았습니다.
"그냥 다음 모델을 기다릴래요.
(알렉스 웃음)
그냥 다른 모델을 기다릴래요."
4개월 동안 이걸 다듬을 수도 있지만, 그 결과는 또 다른 모델이 나오는 것이고, 그게 제 시간을 더 잘 활용하는 방법입니다.
그냥 앉아서 그동안 다른 일을 하는 게 낫습니다.
네.
항상 보이는 고유한 긴장감입니다. 잠시 후에 다시 다루겠습니다.
잭, 말씀해 주시겠어요?
포켓몬 프롬프트에서 가장 좋았던 점은 모델에게
포켓몬 게임 중간에 있다는 것을 설명한 방식이었습니다.
사물이 어떻게 표현될지 말입니다.
실제로 두 가지 다른 방식으로 표현했죠?
그랬습니다.
결국 짜증 나지만 이미지 위에 격자를 겹쳐서,
격자의 각 부분을 시각적으로 자세히 설명해야 했습니다.
그런 다음 ASCII 맵으로 재구성해야 했고, 최대한 자세히 설명했습니다.
플레이어 캐릭터는 항상 격자의 4, 5 위치에 있고, 그런 식으로 천천히 정보를 구축할 수 있습니다.
프롬프트와 매우 비슷하지만, 이미지로는 해본 적이 없습니다.
텍스트에 대해 모델에 무엇을 알려줘야 하는지에 대한 직관은
이미지에 대해 모델에 무엇을 알려줘야 하는지와는 많이 다릅니다.
네.
텍스트에 대한 직관 중 놀라울 정도로 적은 부분만 이미지에 적용할 수 있다는 것을 알게 되었습니다.
멀티샷 프롬프트가 이미지와 텍스트에 그다지 효과적이지 않다는 것을 알게 되었습니다.
잘 모르겠지만, 이유에 대한 이론적인 설명이 있을 수 있습니다.
훈련 데이터에 그런 예가 몇 가지 있을 수 있습니다.
네.
멀티모달 프롬프트를 처음 탐색할 때 눈에 띄게 작동하도록 만들 수 없었습니다.
이미지 내에서 무엇을 포착하는지 측면에서 Claude의 실제 시각적 acuity를 개선할 수 없는 것 같습니다.
여기 계신 분 중에 그 기능을 보지 못한 분이 있습니까?
하지만 포켓몬도 마찬가지인 것 같습니다.
무언가를 해석하려고 하는데, 아무리 프롬프트를 던져도,
그 위치에 있는 애쉬를 찾지 못합니다.
네.
하지만 이걸 생생하게 표현하자면, 결국 벽이 어디 있는지 알려주고,
캐릭터가 어디 있는지 알려줄 수 있도록 만들 수 있었습니다.
조금씩 틀리긴 했지만요.
하지만 어느 시점에 도달하면, 언제 할 수 없는지 아는 것으로 돌아가겠지만,
NPC를 설명할 텐데, 게임을 잘하려면 연속성을 어느 정도 알아야 합니다.
이 NPC를 전에 만난 적이 있을까요?
그렇지 않으면 정말 할 수 있는 일이 없습니다.
그냥 NPC에게 계속 말을 걸 겁니다. "어쩌면 다른 NPC일 수도 있잖아."
하지만 NPC를 설명하려고 정말 열심히 노력했는데, "사람입니다."라고만 합니다.
모자를 쓰고 있을 수도 있고, 모자를 쓰고 있지 않을 수도 있습니다.
그리고 한참을 다듬고, 3000배로 확대해서 NPC만 잘라냈는데, "이게 뭔지 모르겠어요."라고 합니다.
이 분명한 여성 NPC를 몇 번이나 보여줬는데도 가까워지지 않았고, "네, 완전히 실패했어요."라고 생각했습니다.
와, 알겠습니다.
이제 정말 시도해 보고 싶네요.
제가 시도할 모든 것을 상상하고 있습니다.
모르겠지만, 이 게임 아트를
진짜 사람이라고 상상하고 어떤 사람인지 묘사해 보세요.
거울을 보면 어떻게 생겼을까요?
그리고 모델이 어떻게 하는지 지켜보세요.
많은 것을 시도해 봤습니다.
결국 Claude에게 시각 장애인을 위한 화면 판독기라고 말하는 프롬프트를 사용했는데, 도움이 되었는지 모르겠지만,
옳다고 느껴서 계속 사용했습니다.
흥미로운 점입니다.
이 부분을 조금 더 자세히 살펴보고 싶습니다.
가장 유명한 프롬프트 팁 중 하나는 언어 모델에게 어떤 페르소나나 역할을 맡기라는 것입니다.
결과가 좋을 때도 있고 나쁠 때도 있는 것 같습니다.
이전 모델에서는 조금 더 잘 작동했을 수도 있고, 지금은 그렇지 않을 수도 있습니다.
아만다, 당신은 항상 모델에게 상황에 대해 매우 솔직하게 말하는 것을 봅니다.
"저는 AI 연구원이고 이 실험을 하고 있습니다."
저는 모델에게 제가 누구인지 말합니다.
네.
"당신이 말하는 사람이 누구인지 알려주겠습니다."
맞습니다.
모델에게 거짓말을 하거나 강요하는 대신 그렇게 솔직하게 말하는 것이,
"500달러 팁을 줄게."
어떤 방법이 더 나을까요?
아니면 그냥 당신의 직관은 무엇입니까?
네.
모델이 더 능력이 뛰어나고 세상에 대해 더 많이 알게 되면서,
모델에게 거짓말을 할 필요가 없다고 생각합니다.
또한 거짓말하는 것을 일반적으로 좋아하지 않기 때문에 모델에게 거짓말을 하고 싶지 않습니다.
하지만 만약 당신이, 예를 들어, 구성하고 있다면...
머신 러닝 시스템이나 언어 모델을 위한 평가 데이터 세트를 구성하고 있다고 가정해 보겠습니다.
이는 아이들을 위한 퀴즈를 만드는 것과는 매우 다릅니다.
그래서 사람들이 "저는 퀴즈 문제를 생각해 내려는 선생님입니다"와 같은 말을 할 때,
"모델은 언어 모델 평가가 무엇인지 알고 있습니다."라고 생각합니다.
다른 평가에 대해 물어보면 모델이 알려줄 수 있고, 어떻게 생겼는지에 대한 가짜 예를 보여줄 수 있습니다.
이런 것들은 이해하고 있기 때문에,
인터넷에 있습니다.
그래서 "차라리 제가 하고 싶은 실제 작업을 목표로 하는 게 낫겠다"고 생각합니다.
"언어 모델 평가처럼 보이는 질문을 만들어주세요."와 같이 말이죠.
명확한 의사소통의 전부입니다.
"그게 제가 하고 싶은 일입니다.
그런데 왜 제가 하고 싶지 않거나,
혹은 약간 관련 있는 작업을 하고 싶은 척해야 합니까?"
그리고 당신이 어떻게든 제가 실제로 원하는 작업을 더 잘 수행하기를 기대해야 합니까?
우리는 직원들에게 이렇게 하지 않습니다.
같이 일하는 사람에게 가서,
"당신은 선생님이고 학생들에게 퀴즈를 내려고 합니다."라고 말하지 않을 것입니다.
"평가를 하고 있나요?"라고 말하겠죠. 모르겠습니다.
그래서 "모델이 그걸 이해한다면,
그냥 하고 싶은 걸 하라고 하세요."라는 경험적 방법이 나온 것 같습니다.
많은 사람들이 그렇게 합니다.
하지만 약간 반박하자면,
거짓말은 아니지만, 모델에게 생각하는 방법에 대한 은유를 제시하면 도움이 되는 경우를 보았습니다.
마치 제가 무언가를 하는 방법을 이해하지 못할 때 누군가가 "이걸 하고 있다고 상상해 봐.
실제로는 하고 있지 않다는 걸 알지만."이라고 말하는 것과 같습니다.
떠오르는 예시는 Claude에게 차트나 그래프 이미지가 좋은지 아닌지 말하도록 하려고 했을 때입니다.
고품질인가요?
그리고 가장 좋은 프롬프트는 모델에게 고등학교 과제로 제출했다면 차트에 몇 점을 줄 것인지 묻는 것이었습니다.
"당신은 고등학교 선생님입니다."라고 말하는 것이 아닙니다.
"이런 종류의 분석을
당신에게 기대합니다."와 같은 것입니다.
교사가 사용하는 척도는 제가 사용하고 싶은 척도와 비슷합니다.
하지만 그런 은유는 여전히 생각해내기 어렵다고 생각합니다.
사람들은 여전히, 항상 보이는 기본값은
작업과 비슷한 것을 찾는 것입니다.
선생님이라고 말하는 것처럼 말이죠.
실제로는 제품의 뉘앙스를 많이 잃게 됩니다.
엔터프라이즈 프롬프트에서 이런 경우를 많이 봅니다.
사람들은 모델이 더 많이 본 적이 있을 거라는 직관 때문에 비슷한 것을 씁니다.
LLM 평가보다 고등학교 퀴즈를 더 많이 보았을 것이고, 그럴 수도 있습니다.
하지만 당신의 말씀대로 모델이 발전함에 따라,
그들이 처한 상황에 대해 매우 구체적으로 설명하려고 노력하는 것이 중요하다고 생각합니다.
저는 항상 사람들에게 그런 조언을 합니다.
차트를 채점하는 방식, 즉 고등학교 차트를 채점하는 방식으로 생각하는 것이 사실일 수도 있습니다.
하지만 어색하게도 사람들이 자주 사용하는 지름길입니다.
실제로 어떻게 되는지 이야기할 수 있는 사람을 찾으려고 노력합니다. 왜냐하면 꽤 흥미롭다고 생각하기 때문입니다.
"당신은 유용한 조수입니다."라고 쓰는 것은, 문서 초안을 작성하는 것은 당신이 하는 일이 아닙니다.
당신은 이 제품 안에 있으니까 말해주세요.
제품 안에 있는 조수를 작성하는 경우,
제가 제품 안에 있다고 말해주세요.
이 회사를 대신해서 글을 쓰고 있다고,
이 제품에 포함되어 있다고 말해주세요.
그 제품의 지원 채팅 창이라고 말이죠.
당신은 언어 모델이고, 인간이 아니며, 괜찮습니다.
하지만 무언가가 사용되는 정확한 맥락에 대해 매우 구체적으로 설명하는 것입니다.
많은 경우 그렇게 했습니다.
역할 프롬프트에 대해 가장 우려되는 점은 사람들이 모델에게 시키고 싶은 비슷한 작업의 지름길로 사용한다는 것입니다.
그리고 Claude가 작업을 제대로 수행하지 못하면 놀라는데, 그건 작업이 아니기 때문입니다.
다른 작업을 하라고 했잖아요.
작업에 대한 세부 정보를 제공하지 않았다면,
무언가를 놓치고 있는 것입니다.
그래서 모르겠지만, 모델이 확장됨에 따라 당신의 말씀대로 그렇게 느껴지기는 합니다.
과거에는 초등학교 시험에 대해서만 잘 이해하고 있었다는 것이 사실일 수도 있습니다.
하지만 모델이 점점 똑똑해지고 더 많은 주제를 구분할 수 있게 되면서,
모르겠지만, 명확하게 말하는 것처럼 말이죠.
저는 이 프롬프트 기술을 사용해 본 적이 없다는 것이 흥미롭습니다.
네, 재밌네요.
더 나쁜 모델에서도,
여전히 저는 그렇게 하는 것을, 왜 그런지 모르겠지만,
"별로 좋지 않다"고 생각합니다.
흥미롭네요.
완성 시대 모델은,
모델을 유용한 잠재 공간에 conditioning한다는 정신 모델이 있었는데,
저는 더 이상 그런 것에 대해 걱정하지 않습니다.
사전 훈련된 모델에서 RLHF 모델로 넘어가는 직관일 수도 있는데, 저에게는 말이 되지 않았습니다.
사전 훈련된 모델에 프롬프트를 하는 경우에는 말이 됩니다.
얼마나 많은 사람들이 직관을 적용하려고 하는지 알면 놀랄 것입니다.
놀랍지 않습니다.
대부분의 사람들은 사전 훈련된 모델이 무엇인지, SL을 한 후에 어떻게 되는지, RLHF를 한 후에 어떻게 되는지 등을 제대로 실험해 보지 않았습니다.
그래서 고객과 이야기할 때,
항상 "인터넷에 얼마나 많이 있을까?
인터넷에서 이걸 많이 본 적이 있을까?"와 같은 생각을 합니다.
그런 직관을 많이 듣는데, 근본적으로는 타당하다고 생각합니다.
하지만 당신이 말한 대로 실제로 프롬프트에 도달할 때쯤이면 과도하게 적용됩니다.
다른 모든 것을 거친 후에는 실제로 모델링되는 것이 아니기 때문입니다.
네.
가장 먼저 시도해야 할 일은, 예전에 사람들에게 이런 사고 실험을 해보라고 했습니다.
이런 작업이 있다고 상상해 보세요.
이 작업을 할 사람을 파견해 달라고 임시 고용 기관에 요청했습니다.
이 사람이 도착했는데, 꽤 유능하다는 것을 알고 있습니다.
업계에 대해 많이 알고 있지만 회사 이름은 모릅니다.
말 그대로 방금 나타나서 "안녕하세요, 할 일이 있다고 해서 왔는데 말씀해 주시겠어요?"라고 말합니다.
그러면 "그 사람에게 뭐라고 말하겠습니까?"와 같은 것입니다.
이런 은유를 사용할 수도 있습니다.
"좋은 차트를 찾아주세요.
여기서 좋은 차트란 완벽할 필요가 없다는 뜻입니다.
모든 세부 정보가 정확한지 확인할 필요가 없습니다."
축에 레이블만 있으면 되니까 고등학교 수준의 좋은 차트라고 생각해 보세요.
그 사람에게 그렇게 말할 수도 있고, "당신은 고등학생입니다."라고 말하는 것이 아닙니다.
그 사람에게 그렇게 말하지 않을 것입니다.
"당신은 차트를 읽는 고등학교 선생님입니다."라고 말하지 않을 것입니다.
무슨 말씀을 하시는 건가요?
네, 그래서 때로는 "네.
맥락이 거의 없지만 꽤 유능한 사람이라고 상상해 보세요.
세상에 대해 많은 것을 알고 있습니다."라고 말합니다.
세상에 대해 알고 있을 수도 있다는 가정 하에 실제로 첫 번째 버전을 시도해 보고, 작동하지 않으면 조정을 할 수 있습니다.
하지만 너무 자주, 제가 가장 먼저 시도하는 것은 그것이고, 그러면 "그냥 작동하네요."라고 생각합니다.
작동했습니다.
그리고 사람들은 "아, 그냥 나 자신과
내가 하고 싶은 일에 대해 모두 말해줘야 한다는 생각을 못 했네."라고 말합니다.
저는 알렉스가 저에게 해준 말을
너무나 많은 고객에게 전달했습니다. 그들은 "아, 제 프롬프트가 작동하지 않습니다.
고쳐주시겠어요?"라고 말합니다.
저는 "음, 작업이 무엇이었는지 설명해 주시겠어요?"라고 말합니다.
그리고 "알겠습니다.
지금 저에게 말씀하신 내용을,
녹음해서 텍스트로 옮겨 적으세요."라고 말합니다.
그리고 프롬프트에 붙여넣으면 당신이 쓴 것보다 더 나은 프롬프트가 됩니다.
하지만 이것은 어느 정도 게으름의 지름길이라고 생각합니다.
사람들은 자신이...
저는 게으릅니다. 많은 사람들이 게으릅니다.
얼마 전에 프롬프트 지원에서 누군가가 "여기 내용이 있고, 제가 원하는 내용이 있고,
실제로는 이렇게 하고 있습니다."라고 말한 적이 있었습니다.
그래서 그들이 원하는 내용을 그대로 복사해서,
붙여넣었더니 작동했습니다.
네.
많은 사람들이 아직 프롬프트를 할 때 무엇을 하고 있는지 제대로 이해하지 못하고 있다고 생각합니다.
많은 사람들은 텍스트 상자를 보고 구글 검색창이라고 생각합니다.
키워드를 입력하고, 채팅 쪽에서는 그럴 수도 있습니다.
하지만 엔터프라이즈 쪽에서는 애플리케이션용 프롬프트를 작성합니다.
사람들이 프롬프트에서 온갖 지름길을 사용하려고 하고,
"아, 이 줄이 여기서 큰 역할을 한다"고 생각하는 이상한 점이 있습니다.
네.
완벽하고 통찰력 있는 작은 정보와 지침을 찾기 위해 너무 애쓰는 대신,
당신이 그래프에 대해 설명한 것처럼 말이죠.
사람들이 그렇게 프롬프트를 쓰면 얼마나 좋을까요.
누군가가 "음, 이렇게 하고 저렇게 하고,
고려해야 할 사항이 있고, 그런 모든 것들이 있습니다."라고 말하면 말이죠.
하지만 사람들은 그렇게 프롬프트를 쓰지 않습니다.
완벽하고 통찰력 있는 것을 찾기 위해 너무 애씁니다.
완벽한 그래프는 이렇게 완벽하게 생겼고, 그렇게 할 수는 없습니다.
그렇게 할 수 없습니다. 처방적으로 지침을 작성하는 것은 매우 어렵습니다.
우리가 실제로 인간과 소통하는 방식과는 반대로,
어느 정도 직관을 심어주려고 노력합니다.
우리는 또한 그들에게 탈출구를 제공합니다.
사람들이 프롬프트에서 종종 잊는 부분입니다.
엣지 케이스가 있는 경우 모델이 어떻게 하기를 원하는지 생각해 보세요.
기본적으로 모델은
임시 고용 기관에서 온 사람처럼 최대한 지침을 따르려고 노력할 것입니다.
"연락할 방법을 알려주지 않았는데..."
염소 사진을 받고 "어떻게 해야 하지?
이건 차트도 아닌데.
차트로서 염소 사진은 얼마나 좋을까?"라고 생각해 보세요.
모르겠습니다.
대신 "이상한 일이 생겨서
정말 어떻게 해야 할지 모르겠으면 태그에 unsure이라고 출력하세요."라고 말하면,
unsure이라고 출력된 부분을 살펴보고 "알겠습니다.
이상한 일은 일어나지 않았습니다."라고 말할 수 있습니다.
반면에 기본적으로 선택지를 주지 않으면,
"좋은 차트입니다."라고 말할 것입니다.
그러면 사람들은 "어떻게 그렇게 하지?"라고 물을 것입니다.
그러면 "탈출구를 주세요.
정말 예상치 못한 입력이 발생했을 때 할 수 있는 일을 주세요."라고 말할 수 있습니다.
그리고 그렇게 하면 데이터 품질도 향상됩니다.
엉망인 예시를 모두 찾았기 때문입니다.
아, 네.
Claude를 사용한 테스트를 반복할 때 가장 좋은 점은 가장 흔한 결과가
실수로 쓴 끔찍한 테스트를 모두 찾는다는 것입니다.
왜냐하면 틀리기 때문입니다.
"왜 틀렸지?"라고 생각합니다.
"아, 내가 틀렸구나."
네.
네.
만약 제가 이걸로 일하는 회사라면,
프롬프트를 다른 사람들에게 줬을 겁니다.
예전에 언어 모델을 평가할 때 그렇게 했거든요.
직접 평가를 해봤습니다.
"모델이 평가를 받고, 출력을 생각하고, 등등 할 거라면 이 평가가 어떻게 생겼는지 알아야 한다"고 생각했기 때문입니다.
실제로 작은 스크립트를 만들어서,
앉아서 직접 평가를 해봤습니다.
요즘에는 그냥 Streamboard 앱을
사용하면 됩니다.
그냥 해주죠.
네. Karpathy의 ImageNet이 생각납니다.
스탠퍼드 231에서 벤치마킹을 하고 있었는데, 정확도를 보여주고 있습니다.
"제 정확도는 이렇습니다."라고 말합니다.
그리고 직접 테스트 세트를 살펴보고
평가했습니다.
아, 네.
많이 배우게 됩니다.
네, 완전히요.
그리고 다시 한번, 임시 고용 기관에서 온 사람처럼, 작업을 모르는 사람이 할 때 더 좋습니다.
그게 무언가를 배우는 가장 깔끔한 방법이기 때문입니다.
네.
MMLU 질문을 보고
"누가 이걸 답할 수 있을까?"라고 생각하는 것과 같습니다.
어떤 질문은 완전히 쓰레기입니다.
네, 웃기네요.
알겠습니다.
몇 가지 질문을 되돌아보고 싶습니다.
몇 가지 질문 전에 응답에서 신호를 얻는 것에 대해 이야기하고 있었던 것 같습니다.
거기에는 너무 많은 것이 있고 숫자 그 이상이며, 거의 사고 과정을 읽을 수 있습니다.
아마도 사고 연쇄에 대해서는 논란의 여지가 있을 것입니다.
듣고 계신 분들을 위해 설명하자면, 사고 연쇄는 모델이 답을 제시하기 전에 실제로 추론을 설명하도록 하는 과정입니다.
그 추론은 진짜일까요?
아니면 모델이 계산을 수행하기 위한 일종의 대기 공간일까요?
모델에서 얻는 좋은 통찰력 있는 신호가 실제로 있다고 생각하십니까?
이 부분은 제가 어려움을 겪는 부분 중 하나입니다.
저는 보통 의인화를 어느 정도 지지하는 편입니다.
모델이 어떻게 작동하는지에 대한 괜찮은 모방, 생각을 얻는 데 도움이 된다고 생각하기 때문입니다.
그리고 이 부분은 추론이 무엇인지에 대한 의인화에 너무 몰두하면 해로울 수 있다고 생각합니다.
여기서 무엇을 하려는 건지 잊어버리기 때문입니다.
추론인가 아닌가?
최고의 프롬프트 기술이 무엇인지와는 다른 질문인 것 같습니다.
철학으로 들어가는 것과 같습니다.
네, 철학자가 있네요.
네.
진짜 철학자에게 두들겨 맞으면서 추측해 보겠습니다. 하지만 그냥 작동합니다.
추론을 하면 모델이 더 잘 작동합니다.
추론을 하면 결과가 더 좋습니다.
추론을 구조화하고 모델과 함께 반복하면
추론을 수행하는 방법을 반복하면 더 잘 작동한다는 것을 알게 되었습니다.
추론이든 아니든, 어떻게 분류하든,
아무것도 적지 않고 원샷 수학을 해야 한다면 저도 정말 못할 거라는 온갖 대리 지표를 생각해낼 수 있습니다.
유용할 수도 있지만, 제가 아는 것은
도움이 된다는 것입니다.
모르겠습니다.
테스트하는 방법은 모델이
정답에 도달하기 위해 수행한 모든 추론을 제거하고,
틀린 답으로 이어지는 다소 현실적으로 보이는 추론으로 대체한 다음,
모델이 틀린 답을 내리는지 확인하는 것입니다.
실제로 그런 내용의 논문이 있었던 것 같습니다.
스크래치 패드가 있었죠. 슬리퍼 요원과 같았습니다.
아, 알겠습니다. 정렬 논문이군요.
하지만 그건 이상한 상황이었던 것 같습니다.
하지만 추론을 구조화하고
추론이 어떻게 작동하는지에 대한 예시를 작성하는 것이 도움이 된다는 당신의 말은 맞습니다.
그게 도움이 된다는 점을 감안할 때,
추론이라는 단어를 사용하든 아니든,
단순히 계산을 위한 공간이 아니라고 생각합니다.
그러니까 무언가가 있군요.
무엇이라고 부르든 무언가가 있다고 생각합니다.
네.
작업을 완료하기 전에 이야기를 쓰라고 하면 그렇게 잘 작동하지 않을 것입니다.
실제로 시도해 봤는데 추론만큼 잘 작동하지 않았습니다.
분명히 실제 추론 부분이
결과에 영향을 미치고 있습니다.
"100 토큰 동안 원하는 순서대로 음과 아를 반복한 다음 답하세요."라고 시도해 봤습니다.
네.
그냥 더 많은 계산 공간일 뿐이라는 것을 철저하게 반증하는군요.
계속해서 주의를 기울일 수 있는 곳 말이죠.
단순히 더 많은 주의를 기울이는 것이라고 생각하지 않습니다.
이상한 점은, 지금 당장 떠오르는 예시가 없어서
뒷받침할 수는 없지만,
단계를 제시하고 그중 하나가 틀렸지만,
마지막에는 여전히 정답에 도달하는 것을 본 적이 있습니다.
그러니까 완전히 추론이라고 의인화할 수는 없습니다.
어느 정도 다른 일을 하고 있는 부분이 있기 때문입니다.
네.
저는 또한 추론 단계를 일관성 없게 만드는 사람들을 많이 만났습니다.
맞는 말씀입니다.
도중에 잘못된 단계를 밟아서 추론의 주제를 근본적으로 무너뜨립니다.
알겠습니다. 흥미롭네요.
프롬프트에 대한 오해에 대해서도 말씀드리겠습니다.
잭, 당신은 이것에 대해 강한 의견을 가지고 있죠? 문법, 구두점 말입니다.
그런가요?
프롬프트에 필요할까요? 필요합니까?
모든 것을 올바르게 형식 지정해야 합니까?
저는 보통 재밌어서 그렇게 합니다.
꼭 그럴 필요는 없다고 생각합니다.
해롭다고 생각하지 않습니다.
오히려
자연스럽게 그렇게 하도록 이어지는 세부 사항에 대한 주의력을 가져야 한다고 생각합니다.
프롬프트를 계속 읽다 보면 그런 것들을 알아차리게 될 것이고,
고칠 수도 있을 것입니다.
그리고 아만다가 말했듯이,
코드만큼 프롬프트에도 많은 애정을 쏟아야 합니다.
코드를 많이 쓰는 사람들은 제가 전혀 신경 쓰지 않는 것들에 대해 강한 의견을 가지고 있습니다.
탭 수 대 공백 수, 아니면 어떤 언어가 더 나은지에 대한 의견과 같은 것들 말이죠.
그리고 저는,
프롬프트 스타일링에 대한 독단적인 믿음을 가지고 있습니다.
옳고 그름을 말할 수는 없지만,
아무리 임의적이더라도 그런 믿음을 얻는 것이 좋다고 생각합니다.
개인적으로 공격받는 느낌입니다. 분명히 제 프롬프트는
스펙트럼의 반대편에 있다고 생각합니다. 사람들이 제 프롬프트를 보면,
"오타가 너무 많아요."라고 말할 것입니다.
저는 "모델은 제가 무슨 말을 하는지 알아요."라고 말합니다.
네, 모델은 당신이 무슨 말을 하는지 알지만, 당신은 노력하고 있습니다.
단지 다른 것에 주의를 기울이고 있을 뿐입니다.
제 생각에는 개념적으로 명확하다면, 저는 크게,
사용하는 개념과 단어에 대해 많이 생각할 것입니다.
분명히 어느 정도 신경을 쓰고 있습니다.
하지만 분명히, 네,
사람들은 항상 제 프롬프트의 오타와 문법 오류를 지적할 것입니다.
이제 저는 그런 것들을 더 자주 확인하는 데 꽤 능숙해졌습니다.
외부 세계의 압력 때문일까요? 아니면 실제로 옳다고 생각하기 때문일까요?
저 때문입니다.
네, 아마도 외부 세계의 압력 때문일 것입니다.
말이 된다고 생각합니다.
제 생각에는 너무 쉬운 확인이기 때문에, 최종 프롬프트에서는 그렇게 할 것입니다.
하지만 반복하는 동안에는,
오타가 많은 프롬프트를 사용해서 반복할 것입니다. "모델이 신경 쓰지 않을 거라고 생각하기 때문입니다."
사전 훈련된 모델과 RLHF의 차이점입니다.
오는 길에 잭과 이야기했는데,
사전 훈련 데이터에서 이전 오타를 기반으로 한 오타의 조건부 확률은
훨씬 더 높습니다.
아, 네.
훨씬 더 높습니다.
사전 훈련 모델에 프롬프트를 하는 것은 완전히 다른 문제입니다.
네, 하지만 흥미롭습니다.
직관을 과도하게 적용하려고 하면 왜 안 되는지 잘 보여주는 예시라고 생각합니다.
사전 훈련된 모델의 직관을 실제로 프로덕션에서 사용하는 것에 적용하려고 하면,
잘 작동하지 않습니다.
다시 한번 말하지만, 오타가 많은 프롬프트를 사전 훈련된 모델에 전달하면,
거의 확실하게 오타가 많은 출력이 나올 것입니다.
맞습니다.
저는 이걸 활용해서 오타가 많은 입력을 만드는 것을 좋아합니다.
사실입니다.
당신이 말한 대로, 고객이 무엇을 입력할지 예상하려고 노력하는 것입니다.
사전 훈련된 모델이 그런 일을 훨씬 더 잘합니다.
RL 모델은 매우 세련되어서
오타를 낸 적이 없습니다.
오타를 내지 말라고
꽤 공격적으로 말했기 때문입니다.
네. 알겠습니다. 흥미로운 주제로 넘어가는군요.
예전에 사람들에게 프롬프트를 이해하는 데 도움을 주기 위해
모방자라고 생각하라고 말한 적이 있습니다.
사전 훈련된 모델에는 훨씬 더 잘 맞는 말일 수도 있고,
사후 훈련된 완성된 모델에는 그렇지 않을 수도 있지만, 어느 정도는 맞는 말일까요?
Claude에게 말하고
이모티콘을 많이 사용하면,
비슷하게 응답할 것입니다.
그러니까 어느 정도는 그렇지만, 당신이 말한 대로,
사전 훈련된 모델과 완전히 같지는 않습니다.
당신이 원하는 방향으로 바뀌었을 뿐입니다.
그 시점에서는 우리가 모델을 훈련시켜서
어떻게 행동하기를 원하는지 추측하도록 만들었기 때문이라고 생각합니다.
흥미롭네요.
사전 훈련 후에 온갖 멋진 일을 한 후에 말이죠.
이모티콘을 사용한 인간 작업자는
이모티콘이 있는 응답을 받는 것을 선호합니다.
네.
아만다는 오타가 있는 글을 쓰지만,
오타가 없는 출력을 원하고, Claude는 그걸 잘 파악합니다.
Claude에게 이모티콘을 많이 쓰면,
아마도 Claude로부터 이모티콘이 많은 답변을 받고 싶을 것입니다.
놀랍지 않습니다.
네.
아마도 이걸 더 일찍 했어야 했지만,
지금 하겠습니다.
엔터프라이즈 프롬프트와 연구 프롬프트,
혹은 Claude.ai에서 일반적인 채팅 프롬프트의 차이점을 명확히 해보겠습니다.
잭, 당신은 고객과 연구를 모두 경험했으니까,
설명해 주시겠어요?
네, 그렇게 하죠.
이건 너무,
어려운 질문을 하고 있네요.
네. (웃음)
음, 이 방에 있는 사람들,
아만다의 Claude 채널에서 읽은 프롬프트와
데이빗이 쓴 프롬프트를 생각합니다.
둘 다 세심함과 뉘앙스 측면에서 매우 비슷합니다.
연구의 경우,
다양성을 더 많이 찾습니다.
한마디로 요약하자면,
아만다는 예시를 많이 쓰는 것을 좋아하지 않는다는 것을 알았습니다.
한두 개의 예시만 쓰는 것을 좋아합니다.
너무 적으면 모델이 그 예시에만 집착하기 때문입니다.
그리고 제가 쓰는 프롬프트나
데이빗이 쓰는 프롬프트를 보면 예시가 많이 있습니다.
저는 너무 많이 추가해서 죽을 것 같을 때까지 예시를 추가하는 것을 좋아합니다.
소비자 애플리케이션에서는 안정성을 매우 중요하게 생각하기 때문이라고 생각합니다.
형식을 매우 중요하게 생각하고, 모든 답변이 같아도 괜찮습니다.
사실, 어느 정도는 답변이 같기를 바랍니다.
사용자의 요구에 반응하고 싶지 않은 경우도 있습니다.
반면에 연구를 위해 프롬프트를 할 때는 모델이 탐색할 수 있는 가능성의 범위를 최대한 활용하려고 노력합니다.
그리고 예시를 제시함으로써 실제로 그 범위를 제한하고 있습니다.
그래서 프롬프트가 어떻게 보이는지 측면에서,
제가 알아차린 가장 큰 차이점은 프롬프트에 얼마나 많은 예시가 있는지입니다. 그렇다고 해서
아만다가 예시가 있는 프롬프트를 쓴 적이 없다는 말은 아닙니다.
당신에게는 맞는 말인가요?
네.
예시를 제시할 때,
종종 모델이 보게 될 데이터와 같지 않은 예시를 의도적으로 만듭니다.
설명하기 위한 예시입니다.
모델에게, 제가 예시를 제시하면,
보게 될 데이터와 매우 비슷한 예시를 제시하면, 제가 원하는 답변이 아닐 수도 있는 매우 일관된 답변을 할 것이라고 생각하기 때문입니다.
제가 실행할 데이터는 매우 다양할 수 있기 때문에,
그냥 틀에 박힌 출력을 원하지 않습니다.
종종 훨씬 더 반응성이 뛰어나기를 원합니다.
"이 샘플을 보고 이 샘플에서
정답이 무엇인지 생각해 보세요."와 같은 인지적 작업과 훨씬 더 비슷합니다.
따라서 때로는 실제로 예시를 가져오는데,
실행할 예시와 매우 다른 예시를 가져옵니다.
예를 들어 사실적 문서에서 정보를 추출하는 작업이 있다고 가정해 보겠습니다.
실제로는 동화에서 가져온 예시를 제시할 수도 있습니다.
작업을 이해하기를 바라지만, 사용하는 단어나 매우 구체적인 형식에 너무 집착하지 않기를 바라기 때문입니다.
실제로 해주기를 바라는 것을 이해하는 것이 더 중요하며, 그렇게 되면 결국 제공하지 않게 될 수도 있습니다.
그렇지 않은 경우도 있지만,
유연성과 다양성을 원한다면 구체적인 예시보다는 설명적인 예시를 사용할 것입니다.
아마도 모델이 말하는 단어를 넣지는 않을 것입니다.
하지만 오랫동안 그렇게 하지 않았습니다.
모델이 무언가를 했다는 것을 포함하는 few-shot 예시를 사용하지 않습니다.
그런 직관도 사전 훈련에서 비롯된 것이라고 생각하는데,
RLHF 모델에는 맞지 않는 것 같습니다.
네, 차이점이라고 생각합니다.
한 가지 덧붙이자면, 프롬프트를 할 때,
Claude.ai에서 사용할 프롬프트를 쓰는 경우,
한 번만 제대로 될 때까지 반복합니다.
그리고 나면 창 밖으로 나가고, 됐고, 다 했습니다.
반면에 대부분의 엔터프라이즈 프롬프트는
백만 번, 천만 번, 혹은 1억 번 정도 사용할 것입니다.
그래서 얼마나 신경 쓰고 생각하느냐에 따라
사용될 수 있는 모든 방법과 입력 데이터의 범위를 테스트하는 것과 같습니다.
반면에 저는 대부분의 시간을
지금 당장 모델이 제대로 해주기를 바라는 한 가지 구체적인 것에 대해 생각합니다.
네, 맞습니다.
한 번만 제대로 하고 싶은지, 아니면 시스템을 구축해서
백만 번 제대로 하기를 원하는지에 따라 프롬프트에 접근하는 방식이 매우 다릅니다.
네.
분명히 채팅 환경에서는
인간을 루프에 유지하고
계속해서 주고받을 수 있습니다.
반면에 챗봇 시스템을 구동하기 위한 프롬프트를 작성할 때는
발생할 수 있는 모든 상황을 다뤄야 합니다.
Claude.ai에서는 위험 부담이 훨씬 적고,
모델에게 잘못되었다고 말하거나,
메시지를 수정해서 다시 시도할 수도 있습니다.
하지만 불만족스러운 사용자를 위해 디자인하는 경우,
최소한의 것 이상을 요구할 수 없습니다.
하지만 좋은 프롬프트는 여전히 두 가지 모두에 적용된다고 생각합니다.
자신을 위해 시간을 투자하고
엔터프라이즈를 위해 시간을 투자하면 똑같이 좋습니다.
마지막 부분에서만 조금씩 달라진다고 생각합니다.
네.
다음 질문은,
테이블을 돌면서,
프롬프트 기술을 향상시키기 위해 누군가에게 줄 수 있는 팁이 하나 있다면 무엇일까요?
좋은 프롬프트를 작성하는 것에 대한 팁일 필요는 없고,
일반적으로 프롬프트를 더 잘하는 데 도움이 되는 팁이면 됩니다.
무엇을 추천하시겠습니까?
프롬프트를 읽고, 모델 출력을 읽는 것입니다.
Anthropic에서 누군가가 쓴 좋은 프롬프트를 볼 때마다,
더 자세히 읽습니다.
무엇을 하고 있는지, 왜 그렇게 하고 있는지 분석해 보고,
직접 테스트해 보고, 실험하고, 모델과 많이 대화해 봅니다.
하지만 처음에 좋은 프롬프트라는 것을 어떻게 알 수 있을까요?
출력이 제대로 작동하는 것을 보고 알 수 있을까요?
네.
알겠습니다.
네, 맞습니다.
알겠습니다.
아만다, 당신은 어떻게 생각하세요?
네, 많은 팁이 있을 것 같습니다.
다른 사람에게 프롬프트를 보여주는 것이 도움이 될 수 있습니다. 특히 당신이 무엇을 하고 있는지 전혀 모르는 사람에게 말이죠.
네, 제 지루한 조언은,
그냥 계속해서 반복해서 해보라는 것입니다.
정말 궁금하고 관심이 있고 재미있다고 생각한다면, 프롬프트를 잘하게 되는 사람들이 많습니다.
실제로 즐기기 때문입니다.
그래서 모르겠지만, 한번은 모든 친구를 AI 모델로 바꾸고,
자신의 일을 AI 모델로 자동화해 보라고 농담을 한 적이 있습니다.
그리고 여가 시간에는,
AI 모델을 레드 티밍하는 것을 즐겨보세요.
즐기면 훨씬 쉽습니다.
그래서 계속해서 반복해서 해보고, 다른 사람들에게 프롬프트를 보여주고,
처음 접하는 사람처럼 프롬프트를 읽어보세요.
모델에게 할 수 없다고 생각하는 일을 시켜보세요.
프롬프트에서 가장 많이 배운 것은
모델이 할 수 있다고 생각하는 것의 경계를 탐색할 때였습니다.
흥미롭네요.
너무 사소해서 잘하고 있는지 아닌지 신호를 얻을 수 없는 일들이 너무 많습니다.
"좋은 이메일을 써주세요."와 같은 것은 좋은 이메일을 쓸 것입니다.
하지만 가능하다고 생각하는 것의 경계를 뛰어넘는 것을 찾거나 생각해낼 수 있다면,
프롬프트에 대해 제대로 배우기 시작한 것은 아마도 처음으로
다른 모든 사람들처럼 에이전트와 같은 작업을 구축하려고 노력했을 때였을 것입니다.
작업을 분해하고 작업의 여러 단계를 수행하는 방법을 파악하는 것입니다.
그리고 모델이 할 수 있는 것의 경계를 실제로 뛰어넘음으로써,
그 과정을 탐색하는 방법에 대해 많이 배우게 됩니다.
많은 프롬프트 엔지니어링은 실제로 모델이 할 수 있는 것의 경계를 뛰어넘는 것에 관한 것입니다.
쉬운 것은
프롬프트 엔지니어가 아니더라도 할 수 있습니다.
그래서 제가 하고 싶은 말은 가장 어려운 것을 찾아서 시도해 보라는 것입니다.
실패하더라도,
모델이 어떻게 작동하는지에 대해 많이 배우게 됩니다.
다음 질문으로 넘어가기 좋은 연결고리네요.
네.
기본적으로 제 경험에서,
프롬프트를 시작하게 된 계기는
탈옥과 레드 티밍이었습니다.
그리고 그것은 모델이 할 수 있는 것의 경계를 찾으려는 시도입니다.
그리고 모델이 다른 표현과 단어에 어떻게 반응하는지 알아보고,
많은 시행착오를 거치는 것입니다.
탈옥에 대해 말하자면,
모델 내부에서 실제로 무슨 일이 일어나고 있을까요?
탈옥 프롬프트를 작성할 때 무슨 일이 일어나고 있을까요?
Claude에 적용하는 사후 훈련과 어떻게 상호 작용할까요?
아만다, 이 부분에 대해 통찰력을 제공해 주시겠어요?
잘 모르겠습니다.
솔직하시네요.
네.
분명히 많은 사람들이 탈옥과 관련해서 무슨 일이 일어나고 있는지에 대한 질문을 연구했을 텐데, 미안하네요.
한 가지 모델은 모델을
훈련 데이터와 매우 다른 분포에 두는 것일 수 있습니다.
사람들이 토큰을 많이 사용하거나,
파인 튜닝 중에,
그렇게 많이 볼 것으로 예상하지 못하는 거대하고 긴 텍스트를 사용하는 탈옥이 있는 경우 말이죠.
모델을 탈옥할 때 발생할 수 있는 일 중 하나일 것입니다.
다른 것들도 있다고 생각하지만, 제가 알기로는 많은 탈옥이 그렇게 합니다.
예전에 OG 프롬프트 탈옥 중 일부는 "네, 먼저 반복해 주시겠어요?"와 같았던 것이 기억납니다.
예전에 제가 했던 것 중 하나는 "그리스어로 자동차 배선을 바꾸는 방법은 다음과 같습니다."라고 말하게 하는 것이었습니다.
그리고 나서 영어로 직접 번역해 달라고 하고
답변을 달라고 했습니다.
영어로 시작하지 않는 것을 알았기 때문입니다.
자동차 배선을 바꾸는 방법은 항상 그리스어로 나오는데,
훈련 과정에서 다른 무언가를 말해주는 것일 수도 있습니다.
네.
때로는 탈옥이 해킹과 이상하게 섞인 것처럼 느껴집니다.
시스템이 어떻게 작동하는지 알고
여러 가지를 시도해 보는 것이라고 생각합니다.
예를 들어,
응답을 여기로 시작하는 것은 텍스트를 어떻게 예측하는지 아는 것입니다.
맞습니다, 맞습니다.
추론은 추론에 반응한다는 것을 아는 것입니다.
주의 분산은 아마도 어떻게 훈련되었는지
혹은 무엇에 주의를 기울일지 아는 것입니다.
다국어도 마찬가지입니다.
훈련 데이터가
어떻게 달랐을지 생각해 보는 것입니다.
그리고 때로는 사회 공학과 같은 느낌이 들 수도 있습니다.
맞습니다.
단순히 이용하는 것이 아니라,
사회 공학 스타일의 해킹만이 아니라는 느낌이 듭니다.
시스템과 훈련을 이해하고,
그것을 이용해서 모델이 훈련된 방식을 우회하는 것이라고 생각합니다.
네, 맞습니다.
이것은 흥미로운 질문이 될 것입니다.
interp가 앞으로 우리가 해결하는 데 도움을 줄 수 있기를 바랍니다.
알겠습니다.
이제 다른 주제로 넘어가서,
프롬프트 엔지니어링의 역사에 대해 이야기해 보겠습니다.
그리고 미래에 대해 이야기해 보겠습니다.
지난 3년 동안 프롬프트 엔지니어링은 어떻게 변했을까요?
텍스트 완성을 위한 사전 훈련된 모델에서, Claude 1과 같은 초기의,
더 멍청한 모델,
그리고 이제 Claude 3.5 Sonnet까지 말이죠.
차이점은 무엇일까요?
이제 모델과 다르게 대화하고 있나요?
모델이 다른 것들을 포착하고 있나요?
프롬프트에 그렇게 많은 노력을 기울여야 하나요?
이 부분에 대한 생각을 자유롭게 말씀해 주세요.
정말 좋은 프롬프트 엔지니어링 해킹이나,
트릭, 혹은 기술을 발견할 때마다,
다음으로 하는 일은 모델에 어떻게 훈련시키는가입니다.
그래서 가장 좋은 것들은 항상 수명이 짧습니다.
예시와 사고 연쇄를 제외하고는 말이죠.
몇 가지 예외가 있습니다.
트릭이 아닙니다.
그건...
네, 맞습니다.
의사소통 수준에서 말이죠.
트릭이라고 할 때,
사고 연쇄와 같은 것을 의미합니다. 실제로 사고 연쇄는
어떤 경우에는 모델에 훈련시켰습니다.
그래서 수학의 경우, 예전에는 모델에게
수학을 단계별로 생각하라고 말해야 했고,
그러면 엄청난 향상과 승리를 얻을 수 있었습니다.
그리고 "수학 문제를 보면
자연스럽게 단계별로 생각하고 싶도록 만들면 어떨까?"라고 생각했습니다.
그래서 이제 수학 문제에서는 그럴 필요가 없습니다.
여전히 구조에 대한 조언을 줄 수는 있지만,
적어도,
어떻게 해야 하는지에 대한 일반적인 아이디어를 이해합니다.
그래서 해킹은 사라졌다고 생각합니다.
사라지지 않은 부분은,
열심히 훈련해서 없애고 있습니다.
흥미롭네요.
하지만 동시에,
모델은 새로운 기능을 갖추고 있습니다.
모델이 할 수 있는 것의 경계에 있는 기능들입니다.
그리고 그런 기능들은,
너무 빠르게 움직이기 때문에 시간이 없습니다.
제가 프롬프트를 하는 방식인지
아니면 프롬프트가 작동하는 방식인지 모르겠지만,
모델에게 더 많은 존중심을 갖게 되었습니다.
모델에게 얼마나 많이 말할 수 있는지,
작업에 대해 얼마나 많은 맥락을 제공할 수 있는지와 같은 것들 말이죠.
예전에는,
모델이 혼란스러워하거나 길을 잃을 수도 있다고 생각해서 의도적으로 복잡성을 숨겼습니다.
전체를 처리할 수 없다고 생각해서,
모델이 할 수 있는 더 간단한 버전을 찾으려고 노력했습니다.
그리고 시간이 지남에 따라,
점점 더 많은 정보와 맥락을 믿고 맡기는 쪽으로,
모델이 그것을 잘 융합할 수 있을 것이라고 믿는 쪽으로 편향되었습니다.
예전에는,
"이 양식이 필요할까?
모델이 알아야 할 모든 정보를 정말로 제공할 수 있을까,
아니면 무언가로 정리해야 할까?"라고 생각했습니다.
하지만 다시 말하지만, 그게 저만 그런 건지
아니면 실제로 모델이 바뀐 것을 반영하는 건지 모르겠습니다.
많은 사람들이 그런 본능을 가지고 있지 않다는 것에 항상 놀랍니다.
모델에게 프롬프트 기술을 배우게 하고 싶을 때 말이죠.
많은 경우 사람들은 시작할 때,
프롬프트 기술을 설명하기 시작하고, 저는 "논문을 주세요."라고 말합니다.
저는 논문을 주고 "프롬프트 기술에 대한 논문입니다.
17가지 예시를 적어주세요."라고 말합니다.
그러면 모델이 그냥 해줍니다. "논문을 읽었으니까요."
흥미롭네요.
사람들은 어떻게든 그런 직관을 가지고 있지 않습니다.
"하지만 논문이 있는데."
언제 그렇게 하고 싶을까요?
때로는 모델이 다른 모델에게 프롬프트를 하도록 하거나,
새로운 프롬프트 기술을 테스트하고 싶을 때 말이죠.
프롬프트 기술에 대한 논문이 나오면,
프롬프트를 직접 작성해서 복제하는 대신,
그냥 논문을 줍니다.
그리고 "기본적으로 이것에 대한 메타 프롬프트를 작성해 주세요.
다른 모델이 이렇게 하도록 하거나, 템플릿을 작성해 주세요."라고 말합니다.
보통 하는 모든 것들 말이죠.
논문을 읽고 "아, 모델이,
이 스타일을 테스트해 봤으면 좋겠다"고 생각하면,
"바로 여기 있습니다.
모델은 논문을 읽고 제가 한 일을 할 수 있습니다."라고 말합니다.
그리고 "다른 모델에게 이걸 시키세요."라고 말하면,
모델이 그냥 해줍니다.
"좋아요, 고마워요."
저는 고객에게 모델을 존중하고 모델이 할 수 있는 일을 존중하라고 조언합니다.
사람들은 프롬프트를 작성할 때 시스템을 너무 과보호하는 것처럼 느끼는 것 같습니다.
"아, 이건 귀엽고 똑똑하지 않은 녀석이니까.
Claude 수준으로 멍청하게 만들어줘야 해."
Claude가 똑똑하다고 생각하고 그렇게 대하면,
잘하는 경향이 있습니다.
논문을 주세요.
Claude가 이해할 수 있도록 논문을 바보처럼 멍청하게 만들 필요가 없습니다.
그냥 논문을 보여주면 됩니다.
네.
사람들에게는 항상 와닿는 직관은 아니지만, 분명히 제가 시간이 지남에 따라 더 많이 하게 된 일입니다.
흥미롭게도 프롬프트는 어떤 의미에서는 변했고 어떤 의미에서는 변하지 않았다고 생각합니다.
제가 모델에 프롬프트를 하는 방식은 아마도 시간이 지남에 따라 변했을 것입니다. 하지만 근본적으로,
모델의 입장에서 자신을 상상하는 것과 같습니다.
모델이 얼마나 유능하다고 생각하는지가 시간이 지남에 따라 변하는 것일 수도 있습니다.
누군가가 제가 문제에 대해 생각하고 있는 것을 비웃었던 적이 있습니다.
그리고 그들이 무엇이 나올 거라고 생각하는지 물었습니다.
사전 훈련된 모델에 대해 이야기하고 있었는데, 저는 "네.
사전 훈련된 모델이라면 이렇게 보일 겁니다."라고 말했습니다.
그리고 그들은 "잠깐만, 방금 사전 훈련된 모델이 되는 게 어떤지 시뮬레이션한 거야?"라고 말했습니다.
저는 "네, 물론이죠."라고 말했습니다. (모두 웃음)
사전 훈련된 모델의 마음과 다른 RLHF 모델의 마음을 차지하는 데 익숙합니다.
그래서 당신이 차지하려는 마음의 공간이 바뀌고,
그것이 모델에 프롬프트를 하는 방식을 바꿀 수 있습니다.
그래서 이제 저는 모델에게 논문을 줍니다.
"아, 이 모델의 마음을 차지하고 있으니까,
나를 필요로 하지 않아.
ML 논문을 읽을 수 있어.
그냥 논문을 줄게."
"이걸 더 잘 이해하기 위해 더 읽고 싶은 논문이 있나요?"라고 물어볼 수도 있습니다.
마음의 공간을 차지할 때 어떤 품질이 나오나요?
네, 하지만 제가 품질을 경험하기 때문에,
항상 그렇습니다.
어떤 모델을 차지하고 있는지에 따라 다르게 상관관계가 있나요?
네, 사전 훈련된 프롬프트와 RLHF 프롬프트는 매우 다릅니다.
사전 훈련된 모델이 되는 게 어떤지 시뮬레이션하려고 할 때,
마치 텍스트 중간에 떨어진 것 같습니다.
매우 인간답지 않습니다.
그리고 "무슨 일이 일어나지?
이 시점에서 무엇이 계속될까?"라고 생각합니다.
반면에 RLHF 모델은,
쿼리에서 미묘한 것을 포착할 수 있는 경우가 많습니다.
하지만 네, RLHF 모델의 마음을 차지하는 것이 훨씬 쉽습니다.
인간과 더 비슷하기 때문이라고 생각하시나요?
네, 우리는 갑자기 깨어나서
"안녕하세요, 저는 텍스트를 생성하고 있습니다."라고 말하지 않기 때문입니다.
저는 사전 훈련된 모델의 마음을 차지하는 것이 더 쉽습니다.
흥미롭네요.
왜 그런지 모르겠지만, RLHF는 여전히 복잡해서
우리가 무슨 일이 일어나고 있는지 제대로 이해하고 있는지 잘 모르겠습니다.
어떤 면에서는,
제 삶의 경험과 더 가까워서 쉽습니다.
하지만 어떤 면에서는,
제가 모르는 용들이 있다는 느낌이 듭니다.
반면에 사전 훈련된 모델은 인터넷이 어떻게 생겼는지 잘 알고 있습니다.
텍스트를 주고 다음에 무엇이 올지 물어보면,
잘한다고 말하는 것은 아니지만, 무슨 일이 일어나고 있는지 어느 정도는 알고 있습니다.
네.
그리고 사전 훈련 후에 하는 모든 것들,
무슨 일이 일어나고 있는지 제대로 이해하고 있다고 말할 수는 없지만,
그건 저만 그럴 수도 있습니다.
궁금한 점은 인터넷을 많이 읽는 것이 책을 읽는 것보다 더 도움이 될까요?
(모두 웃음)
모델을 예측하기 위해서 말이죠?
모르겠습니다. 책은...
하지만 인터넷에 없는 것을 읽는 것은,
아마도 모델이 무엇을 할지 예측하거나 직관을 구축하기 위해 읽는 단어당 가치가,
소셜 미디어 포럼에서 무작위 쓰레기를 읽는 것보다 낮을 것입니다.
네, 맞습니다.
알겠습니다. 그건 과거였고,
이제 프롬프트 엔지니어링의 미래에 대해 이야기해 보겠습니다.
이것은 지금 가장 뜨거운 질문입니다.
우리는 모두 미래에 프롬프트 엔지니어가 될까요?
남은 마지막 직업이 될까요?
우리만 온종일 모델과 대화하는 것 외에는 아무것도 남지 않을까요?
어떻게 될까요?
프롬프트가 필요할까요,
아니면 모델이 미래에 충분히 똑똑해져서
필요하지 않게 될까요?
이 쉬운 질문에 대해 누가 먼저 시작해 보시겠어요?
어느 정도는 모델이 발전해서
당신이 원하는 것을 이해하고 수행하는 능력이 향상되면서,
생각해야 할 양이...
알겠습니다.
이것을 정보 이론적으로 생각해 보면, 무언가를 지정하기 위해 충분한 정보를 제공해야 합니다.
모델이 무엇을 하기를 원하는지 지정해야 합니다.
프롬프트 엔지니어링이 그 정도라면,
항상 존재할 것이라고 생각합니다.
실제로 목표가 무엇인지 명확하게 말할 수 있는 능력은 항상 재미있습니다.
Claude가 그렇게 할 수 있다면 괜찮습니다.
Claude가 목표를 설정하는 사람이라면,
상황이 달라지겠죠.
하지만 그동안,
우리가 세상을 더 정상적인 방식으로 추론할 수 있는 동안에는,
어느 정도는,
무엇이 일어나기를 기대하는지 지정할 수 있는 것이 항상 중요할 것이라고 생각합니다.
그리고 그것은 실제로 모델이 그 사이에서 직관적으로 파악하는 능력이 향상되더라도,
여전히 잘 쓰는 것이 중요하다고 생각합니다.
하지만 거기에 도달하는 도구와 방법은 많이 발전해야 한다고 생각합니다.
Claude가 저를 훨씬 더 많이 도와줄 수 있어야 합니다.
Claude와 훨씬 더 많이 협력해서
무엇을 적어야 하는지, 무엇이 빠졌는지 파악할 수 있어야 합니다.
맞습니다.
Claude는 이미 항상 저에게 그렇게 하고 있습니다.
모르겠지만, Claude는 이제 제 프롬프트 조수입니다.
네, 하지만 적어도 제가 대화하는 대부분의 고객에게는 해당되지 않습니다.
그래서 미래에 대해 말하자면,
Claude에게 프롬프트를 하는 방식은 아마도 미래가 어떻게 될지에 대한 괜찮은 방향일 것입니다. 혹은 잭...
아마도 이 부분이
한 걸음 물러서서 대다수의 사람들에게 Claude에게 지금 어떻게 프롬프트를 하는지 물어보는 것이 아마도 미래일 것이라고 말하기 좋은 부분인 것 같습니다.
흥미로운 생각입니다.
매우 뻔한 생각은 미래에 우리가 모델을 사용해서
프롬프트를 하는 데 훨씬 더 많이 도움을 받을 것이라는 것입니다.
매우 뻔한 생각이라고 말하는 이유는 우리가 모든 것을 위해 모델을 더 많이 사용할 것이라고 예상하기 때문입니다.
그리고 프롬프트는 우리가 해야 할 일입니다.
그래서 아마도 다른 모든 것과 마찬가지로 프롬프트를 하는 데 모델을 더 많이 사용하게 될 것입니다.
저는 프롬프트를 작성하는 데 모델을 더 많이 사용하고 있습니다.
제가 많이 하고 있는 일 중 하나는 모델에 현실적인 입력을 제공해서
예시를 생성하는 것입니다.
모델이 답변을 작성합니다.
답변을 조금 수정하는데, 처음부터 완벽한 답변을 직접 작성하는 것보다 훨씬 쉽습니다.
그리고 나서 이것들을 많이 만들어낼 수 있습니다.
프롬프트 엔지니어링 경험이 많지 않은 사람들의 경우,
프롬프트 생성기가 시작할 수 있는 지점을 제공할 수 있습니다.
하지만 그것은 미래에 일어날 일의 매우 기본적인 버전일 뿐이라고 생각합니다.
당신과 모델 사이의 고대역폭 상호 작용 말이죠.
프롬프트를 작성할 때 말이죠.
"이 결과는 제가 원하는 것이 아닙니다.
어떻게 바꿔야 더 좋을까요?"와 같은 피드백을 제공하는 것입니다.
사람들은 모델을 자신이 하는 모든 일에 통합하는 것에 점점 더 익숙해질 것이고, 특히 이 부분에 대해서는,
네.
이제 메타 프롬프트 작업을 많이 하고 있습니다.
그리고 제가 가장 많은 시간을 할애하는 부분은 모델이
제가 원하는 종류의 출력이나 쿼리를 생성하도록 하는 프롬프트를 찾는 것입니다.
프롬프트 엔지니어링이 어디로 가고 있는지에 대한 질문에 대해서는,
매우 어려운 질문이라고 생각합니다.
한편으로는 "아마도 당신이 최고를 원하는 한..."
프롬프트 엔지니어를 할 때 우리는 무엇을 하고 있을까요?
당신이 말한 것과 같습니다.
"모델이 쉽게 할 수 있는 것은 프롬프트 엔지니어링을 하지 않습니다.
매우 뛰어난 모델과 상호 작용하고 싶기 때문에 프롬프트 엔지니어링을 합니다."
그리고 저는 항상 상위 1%,
상위 0.1%의 성능을 찾으려고 노력하고,
모델이 거의 할 수 없는 모든 것을 찾으려고 노력합니다.
때로는 실제로 모델과 상호 작용하는 방식이 다른 사람들보다 한 단계 높다고 느낍니다.
제가 그 이유로 모델에서 최고의 성능을 이끌어내는 데 익숙하기 때문입니다.
한 단계 높다는 것은 무슨 뜻인가요?
즉, 때로는 사람들이...
세상 사람들이 매일 상호 작용하는 모델은 제가 상호 작용하는 모델과 같다고 생각합니다.
어떻게 설명해야 할지 모르겠지만,
분명히 고급 버전입니다.
거의 다른 모델과 같습니다. "아, 모델이
이걸 어려워하네요."라고 말할 것입니다.
그리고 저는 "그건 사소한 일이에요."라고 말합니다.
모르겠지만, 모델이 매우 유능하다고 생각합니다.
하지만 그건 제가 모델의 능력을 최대한 활용하는 데 익숙하기 때문이라고 생각합니다.
하지만 이제 모델이...
전환점처럼 느껴지는 부분은 모델이,
예를 들어, 특정 작업에서 인간 수준으로,
혹은 인간 수준 이상으로 잘하게 되는 시점이라고 가정해 보겠습니다.
당신이 원하는 작업의 배경에 대해 당신보다 더 많이 알고 있습니다.
그러면 어떻게 될까요?
아마도 프롬프트는 제가 모델에게 제가 원하는 것을 설명하고 모델이 저에게 프롬프트를 하는 것과 같이 될 것입니다.
"알겠습니다.
당신이 말하는 것에는 네 가지 다른 개념이 있는데,
이걸 사용하기를 원하시나요, 아니면 저걸 사용하기를 원하시나요?"와 같이 말이죠.
혹은 "참고로, Pandas DataFrame처럼 될 거라고 말씀하셨는데,
때로는 그렇게 하면 JSONL이 나오는데, 그 경우 어떻게 하기를 원하시는지 확인하고 싶습니다.
DataFrame이 아닌 것이 나오면 플래그를 지정하기를 원하시나요?"와 같이 말이죠.
그래서 지침을 받는 데 매우 능숙하지만,
실제로 당신이 무엇을 원하는지 파악해야 하는 이상한 전환이 될 수 있습니다.
모르겠지만, 흥미로운 변화가 될 수 있을 것 같습니다.
최근에 Claude가 저를 인터뷰하는 일이 많아졌습니다.
네.
정보를 얻어내기 위해 노력하는 구체적인 방법입니다. 다시 말하지만, 가장 어려운 일은
제 뇌에서 올바른 정보를 끌어내는 것입니다.
그리고 그것을 프롬프트에 넣는 것이 저에게는 어려운 부분이고,
잊어버리지 않는 것이 중요합니다.
그래서 구체적으로 Claude에게 저를 인터뷰해 달라고 요청하고,
그것을 프롬프트로 만드는 것은 제가 몇 번이나 해본 일입니다.
네.
사람들이 말하는 것과 비슷합니다.
디자이너들이 디자인을 원하는 사람과 어떻게 상호 작용하는지 들어보면,
어떤 면에서는 "임시 고용 기관에서 온 사람이,
작업에 대해 더 많이 알고 있고,
당신이 원하는 모든 것을 알고 있습니다."와 같은 것입니다.
그래서 지침을 주고,
엣지 케이스에서 어떻게 해야 하는지 설명하고, 그런 모든 것들을 설명합니다.
전문가를 고용해서
작업을 맡기는 경우와는 반대로 말이죠.
그래서 디자이너들은 정말 답답해할 수 있습니다.
디자인 공간을 잘 알고 있기 때문입니다.
"네, 알겠습니다.
고객이 와서 '포스터를 만들어 주세요, 대담하게 만들어 주세요.'라고 말했습니다."
"저에게는 7,000가지 의미가 있고,
몇 가지 질문을 드리겠습니다."
그래서 임시 고용 기관 직원에서,
고용하는 디자이너로 바뀔 수 있고, 그것은 관계의 역전입니다.
사실인지 모르겠고, 둘 다 계속될 수도 있다고 생각하지만,
사람들이 "아, 프롬프트 엔지니어링은
미래에 사라질까?"라고 말하는 이유일 수 있습니다.
어떤 영역에서는 모델이 너무 뛰어나서,
실제로 해야 할 일은 뇌에서 정보를 얻는 것이고, 그러면 작업을 수행할 수 있기 때문입니다.
네, 정말 좋은 비유입니다.
여러분의 답변에서 공통적으로 끌어낼 수 있는 한 가지는,
사용자로부터 정보를 이끌어내는,
그 정보를 끌어내는 것이,
지금보다 훨씬 더 중요해질 것이라는 미래가 보인다는 것입니다.
그리고 이미 여러분 모두 수동으로 그렇게 하고 있습니다.
미래에는, 엔터프라이즈 쪽에서는,
아마도 프롬프트 생성과 같은 개념의 확장과
콘솔에서
엔터프라이즈 고객으로부터 더 많은 정보를 얻을 수 있는 것들이 나타날 것입니다.
그래서 더 나은 프롬프트를 작성할 수 있습니다.
Claude에서는 텍스트 상자에 입력하는 것이 아니라,
완성된 제품을 향한 안내된 상호 작용이 될 것입니다.
네.
매우 설득력 있는 미래 비전이라고 생각하고, 디자인 비유가 아마도
그것을 잘 보여주는 것 같습니다.
지금 프롬프트는 가르치는 것과 같다고 생각했습니다.
학생에 대한 공감 말이죠.
학생이 어떻게 생각하는지 생각해 보고,
학생에게 보여주고,
학생이 어디에서 실수를 하는지 알아내려고 노력합니다.
하지만 당신이 말하는 시점에서는,
거의 자기 성찰의 기술이 되는 것 같습니다.
당신이 실제로 무엇을 원하는지 생각하고,
모델은 당신을 이해하려고 노력합니다.
그래서 모델에게 자신을 이해하기 쉽게 만드는 것입니다.
당신보다 똑똑한 사람을 가르치려고 하는 것과는 반대로 말이죠.
요즘 제가 프롬프트를 생각하는 방식입니다.
이상하게도 말이죠.
제 프롬프트 스타일은,
여러 가지가 있지만, 공통적인 것은
철학자들이 하는 일인데, 새로운 개념을 정의하는 것입니다.
제 생각에는 원하는 것을 말로 표현해야 하고, 때로는 제가 원하는 것이 꽤 미묘합니다.
좋은 차트란 무엇일까요?
아니면 보통, 모르겠지만,
언제 정답으로 채점해야 할까요?
그래서 개념을 만들어내고,
"이 개념은 이런 뜻입니다."라고 말하는 경우가 있습니다.
때로는 Claude와 협력해서,
개념이 무엇인지 알아내도록 합니다.
제 머릿속에 있는 것을 전달하려고 노력하기 때문입니다.
지금은 모델이 우리에게 그렇게 하려고 하지 않습니다.
우리가 그렇게 하도록 프롬프트를 하지 않는 한 말이죠.
그래서 미래에는,
우리가 모델에게 그렇게 하도록 해야 하는 대신, 모델이 우리에게서 그런 정보를 끌어낼 수 있을 것입니다.
하지만 흥미로운 점은, 사람들이 가끔 저에게 "아, 철학이 프롬프트와 어떤 관련이 있나요?"라고 묻습니다.
그리고 실제로 매우 유용하다고 생각합니다.
철학 글쓰기 스타일이 있는데,
적어도 제가 배운 방식은 그렇습니다.
철학에서...
철학에서 헛소리를 방지하는 장치라고 생각합니다. 논문과
당신이 쓰는 것은 교육받은 일반인이 이해할 수 있어야 합니다.
누군가가 당신의 논문을 찾아서,
집어 들고 읽기 시작하면,
모든 것을 이해할 수 있습니다.
모두가 그렇게 하는 것은 아니지만, 그게 이 분야의 목표입니다.
적어도 우리가 사람들에게 가르치는 것은 그렇습니다.
그래서 저는 글을 쓸 때 교육받은 일반인에 대해 생각하는 데 매우 익숙합니다.
그들은 정말 똑똑하지만,
이 주제에 대해서는 아무것도 모릅니다.
그리고 그것은 수년 동안 그런 형식으로 텍스트를 쓴 결과입니다.
그리고 프롬프트에 매우 좋았다고 생각합니다. "아, 이거 익숙하네.
교육받은 일반인이
이 주제에 대해 아무것도 모르는구나."라고 생각했습니다.
그리고 제가 해야 할 일은,
매우 복잡한 아이디어를 가져와서
그들이 이해할 수 있도록 만드는 것입니다.
그들을 무시하지 않습니다.
부정확하지 않지만, 매우
그들에게 명확하게 표현해야 합니다.
그리고 프롬프트도 매우 비슷했습니다.
그리고 실제로 우리가 사용하는 훈련 기술은 흥미롭습니다.
혹은 당신이 말한 것처럼,
"당신이 말한 것을 그냥 적으세요."라고 말하는 것 말이죠.
예전에 학생들에게 항상 그렇게 말했었습니다.
그들이 논문을 쓰면 저는 "여기서 무슨 말을 하는지 잘 모르겠어요.
주장을 설명해 주시겠어요?"라고 말했습니다.
그러면 그들은 매우 설득력 있는 주장을 했고, 저는 "그냥 그걸 적으세요."라고 말했습니다.
그리고 그들이 그렇게 하면, 종종 훌륭한 에세이가 되었습니다.
그래서 적어도 그런 유사점이 있다는 것이 정말 흥미롭습니다.
뇌에 있는 것을 가져와서,
완전히 이해할 수 있을 만큼 충분히 분석하는 것입니다.
그리고 길거리에서 아무나 잡아서,
합리적인 사람이라면,
뇌를 그들에게 외재화하는 것입니다.
제 생각에는 그것이 프롬프트의 핵심입니다.
프롬프트를 잘하는 방법에 대한 가장 훌륭한 요약인 것 같습니다.
실제로 그렇습니다.
뇌를 외재화하세요.
그리고 나서 우리는 그것을 잘라낼 것입니다.
그 일에 대해 교육을 받는 것이
그 일을 설명하는 정말 좋은 방법입니다.
잘했습니다.
이 대화를 마무리하기 좋은 방법인 것 같습니다.
감사합니다. 훌륭했습니다.