"engineering"이라는 단어가 이런 맥락에서 쓰이는 것은 매우 거슬림, 진짜 엔지니어링이라고 볼 수 없다고 생각함, 엔지니어링은 오랜 세월 쌓인 지식과 물리 법칙, 규칙 등을 기반으로 예측 가능하게 설계하고 만드는 일인데, 지금 하는 것은 결과가 나올 때까지 무작정 시도하는 것에 불과함
어떤 단어든 여러 의미가 있다고 생각함, "prompt engineering"에서의 "engineering"은 "social engineering"에서처럼 비슷하지만 다른 뉘앙스임, 예를 들면 구글의 engineering 정의 2번은 '술수를 부려 목적을 이루는 행동'임, Merriam-Webster 사전의 3번째 정의나, collins dictionary, yourdictionary 등에서 찾아봐도 “교묘한 조작, 계획을 세움”과 같은 기술적이지 않은 의미가 분명히 존재함, 단어의 확립된 부차적 의미임
나는 시리얼을 먹으면서 시리얼 박스의 스펙을 검토함, 매일 아침 그렇게 하고, 버스 타는 엔지니어링 스킬도 적용함, 왜냐하면 나는 prompt engineering으로 생계를 꾸리는 사람이기 때문임, 요즘은 너무 많은 단어들이 본래 의미를 잃어가고 있다는 생각이 들어서 자신만 짜증나는 게 아니라는 게 다행임
나는 캐나다의 접근 방식, 즉 엔지니어라는 직함을 쓰려면 각 주의 기술인 규제기관에서 면허를 받아야 하는 시스템을 계속 선호함, 미국은 모든 소프트웨어 개발자, 정비공, HVAC 설치기사, 배관공까지도 엔지니어라고 부르는 게 지나치다고 느낌
소프트웨어 엔지니어들은 컴퓨터 시스템에 대한 깊은 물리적 지식이 거의 없고, 실제 업무는 경험적 과학보다는 철학이나 어느 정도 수학과 더 관련됨, 2) 당신이 AI 발전 동향에 대해 잘 모르는 것 같음, 컴퓨터 공학처럼 prompt 작업을 위한 전문 용어와 레퍼런스, 문서를 이미 만들었음, 이 분야는 어디 학교에서도 배울 수 없는 독립 영역인데, 실무 경험 없으면 채용도 안 한다는 추세임
이런 논란은 사실 많은 "engineering 팀"들이 하는 일에도 똑같이 제기할 수 있다고 생각함, 엔지니어가 하면 그 일이 곧 엔지니어링이란 암묵적 전제가 깔려 있고, 더 나아가서 소프트웨어 자체가 소프트웨어 엔지니어링이라 부를 수 있는 가치가 있는지에 대한 깊은 가정도 있음
"Engineering"이라는 말은 사람들에게 그냥 문장 쓰기가 아니라는 인상을 주려는 수사적 장치라는 생각임, 솔직히 "prompt writing"이라고 하면 뭔가 가볍게 여겨질 수 있으니까 "soft" skill이라는 말을 싫어하는 사람들에게는 더욱 거북할 것임
오늘의 "초보자를 위한 연금술" 에피소드 같은 느낌임, 벤치마크 세트에서 랜덤 시드로 7을 주었을 때 알고리즘 속도가 30% 늘었던 사례가 떠오름, 8도 아니고 6도 아닌 7이었음
이렇게 비결정론적이고 복잡해지는 상황을 싫어할 수도 있지만, 이게 이제 우리의 일임, 내가 하지 않으면 누군가는 결국 해야만 할 일임, 나는 AI 응용 프로젝트에서 prompt engineering을 실제 엔지니어링과 분리시키고, 모든 필요 도구(컴포넌트화, 버전관리, 평가도구)를 세팅해서 prompt engineering을 가능한 체계적으로 할 수 있게 한 뒤, 그걸 도메인 전문가에게 넘겼음, prompt 엔지니어링이 시드 고르기 수준이라고 생각하면 프롬프트를 쓰면 안 된다고 보는 입장임
이 글을 읽으면서 나에게 중요한 깨달음은 출력 순서를 어떻게 가져갈지 생각하게 됨, 예를 들어, 답변하기 전에 증거나 인디케이터부터 뽑아내게 요청하는 것임, LLM이 확률적 자동완성인 것은 알았지만 이런 방식으로 프라이밍은 생각하지 못했었음
이 방식은 reasoning 모델에는 해당되지 않을 수 있음, reasoning 모델은 답 내기 전 원하는 방식대로 생각 과정을 거치기 때문에 출력 순서가 정확도에 미치는 영향이 적음, 이게 아마 OpenAI가 reasoning 강제하려는 이유가 아닐까 싶음
나는 보통 온라인에서 찾은 출처의 짧은 인용문부터 뽑아달라고 요청함(연관이 있을 경우), 이렇게 하면 정보의 신뢰도를 어느 정도 보완해 줌, 최근에 우리 조직에서 Cloudflare Zero Trust 구축하면서 매우 필요했던 방식임
반대로 답부터 내고 근거를 대라고 하면, 모델이 임의의 답을 내고 그걸 그럴듯하게 합리화하는 "헛소리 모드"에 들어감, 차라리 객관적으로 장단점부터 뽑게 하고 그 다음 결론을 내리게 하면 훨씬 신중하게 답변해줌
내 생각에 이 제출물 제목에 "(2024)"를 넣는 게 좋겠음
어려운 문제에서 내가 생각하는 최고의 prompt engineering 팁은 "펼치고 좁히기"임, 구체적으로 설명하면, 먼저 문제와 상황을 명확히 제시하고, AI에게 가능한 모든 옵션과 접근방법을 분석하고 찾아보게 해서 정보를 최대한 넓혀놓음, 그런 다음 각 방법의 장단점을 리스트업하고, 가장 적합한 해결책을 선택하게 하는 방식임, 쉬운 문제라면 이런 거 다 생략하고 바로 묻기만 해도 답이 나오지만, 어려운 문제에서 바로 답을 묻는다면 그냥 그럴듯하게 지어내기 때문에, 반드시 현실적인 근거에서 시작해야 함, 그래서 구체적 맥락 - 옵션 분석 - pros & cons - 최종 선택의 흐름이 필요함
이런 방식은 AI 문제 말고 다른 문제 해결에도 적용되는 것 같음
제목에 2024를 추가하라는 의견임
우리가 직접 했던 일을 AI에게 가르치고, 다시 AI가 그 일을 하도록 효과적으로 시키는 방법을 배우는 중이라는 생각이 듦, 만약 이 기술이 미국 전체 경제가 받쳐주지 않으면 마치 뜨거운 공기 풍선처럼 띄었다가 훅 가라앉을 수도 있겠음
다른 댓글들과 비슷하게 이게 정통 엔지니어링처럼 느껴지지 않음, 하지만 Anthropic이 모델 해석 가능성 분야에서 꽤 멋진 연구를 했다고 생각함, 만약 그 도구가 public API로 공개된다면 프롬프트에 따라 모델 내부 상태의 차이를 비교해보고 더 체계적인 튜닝을 할 수 있는 피드백 루프가 만들어질 수도 있을 것 같음
이 튜토리얼은 세 가지 모델(Sonnet, Haiku, Opus 3)을 위해 작성됨, 오늘날에도 적용될 교훈이 일부 있지만 더 똑똑한 RL 모델(Sonnet 4.5 등)에는 그다지 중요하지 않은 내용도 있음, 참고로 Claude 3 Haiku는 가장 작고 빠르며 저렴한 모델이고, Sonnet과 Opus는 더 지능적이며 Opus가 가장 우수함
3장과 6장은 현재 기준에서 덜 중요하다고 생각함, 반복적이거나 정확성이 중요한 prompt를 다루는 사람을 가정할 때 이 외에 덜 중요한 부분이 더 있을지 궁금함
Hacker News 의견
"engineering"이라는 단어가 이런 맥락에서 쓰이는 것은 매우 거슬림, 진짜 엔지니어링이라고 볼 수 없다고 생각함, 엔지니어링은 오랜 세월 쌓인 지식과 물리 법칙, 규칙 등을 기반으로 예측 가능하게 설계하고 만드는 일인데, 지금 하는 것은 결과가 나올 때까지 무작정 시도하는 것에 불과함
어떤 단어든 여러 의미가 있다고 생각함, "prompt engineering"에서의 "engineering"은 "social engineering"에서처럼 비슷하지만 다른 뉘앙스임, 예를 들면 구글의 engineering 정의 2번은 '술수를 부려 목적을 이루는 행동'임, Merriam-Webster 사전의 3번째 정의나, collins dictionary, yourdictionary 등에서 찾아봐도 “교묘한 조작, 계획을 세움”과 같은 기술적이지 않은 의미가 분명히 존재함, 단어의 확립된 부차적 의미임
나는 시리얼을 먹으면서 시리얼 박스의 스펙을 검토함, 매일 아침 그렇게 하고, 버스 타는 엔지니어링 스킬도 적용함, 왜냐하면 나는 prompt engineering으로 생계를 꾸리는 사람이기 때문임, 요즘은 너무 많은 단어들이 본래 의미를 잃어가고 있다는 생각이 들어서 자신만 짜증나는 게 아니라는 게 다행임
나는 캐나다의 접근 방식, 즉 엔지니어라는 직함을 쓰려면 각 주의 기술인 규제기관에서 면허를 받아야 하는 시스템을 계속 선호함, 미국은 모든 소프트웨어 개발자, 정비공, HVAC 설치기사, 배관공까지도 엔지니어라고 부르는 게 지나치다고 느낌
이런 논란은 사실 많은 "engineering 팀"들이 하는 일에도 똑같이 제기할 수 있다고 생각함, 엔지니어가 하면 그 일이 곧 엔지니어링이란 암묵적 전제가 깔려 있고, 더 나아가서 소프트웨어 자체가 소프트웨어 엔지니어링이라 부를 수 있는 가치가 있는지에 대한 깊은 가정도 있음
"Engineering"이라는 말은 사람들에게 그냥 문장 쓰기가 아니라는 인상을 주려는 수사적 장치라는 생각임, 솔직히 "prompt writing"이라고 하면 뭔가 가볍게 여겨질 수 있으니까 "soft" skill이라는 말을 싫어하는 사람들에게는 더욱 거북할 것임
오늘의 "초보자를 위한 연금술" 에피소드 같은 느낌임, 벤치마크 세트에서 랜덤 시드로 7을 주었을 때 알고리즘 속도가 30% 늘었던 사례가 떠오름, 8도 아니고 6도 아닌 7이었음
이 글을 읽으면서 나에게 중요한 깨달음은 출력 순서를 어떻게 가져갈지 생각하게 됨, 예를 들어, 답변하기 전에 증거나 인디케이터부터 뽑아내게 요청하는 것임, LLM이 확률적 자동완성인 것은 알았지만 이런 방식으로 프라이밍은 생각하지 못했었음
이 방식은 reasoning 모델에는 해당되지 않을 수 있음, reasoning 모델은 답 내기 전 원하는 방식대로 생각 과정을 거치기 때문에 출력 순서가 정확도에 미치는 영향이 적음, 이게 아마 OpenAI가 reasoning 강제하려는 이유가 아닐까 싶음
나는 보통 온라인에서 찾은 출처의 짧은 인용문부터 뽑아달라고 요청함(연관이 있을 경우), 이렇게 하면 정보의 신뢰도를 어느 정도 보완해 줌, 최근에 우리 조직에서 Cloudflare Zero Trust 구축하면서 매우 필요했던 방식임
반대로 답부터 내고 근거를 대라고 하면, 모델이 임의의 답을 내고 그걸 그럴듯하게 합리화하는 "헛소리 모드"에 들어감, 차라리 객관적으로 장단점부터 뽑게 하고 그 다음 결론을 내리게 하면 훨씬 신중하게 답변해줌
내 생각에 이 제출물 제목에 "(2024)"를 넣는 게 좋겠음
어려운 문제에서 내가 생각하는 최고의 prompt engineering 팁은 "펼치고 좁히기"임, 구체적으로 설명하면, 먼저 문제와 상황을 명확히 제시하고, AI에게 가능한 모든 옵션과 접근방법을 분석하고 찾아보게 해서 정보를 최대한 넓혀놓음, 그런 다음 각 방법의 장단점을 리스트업하고, 가장 적합한 해결책을 선택하게 하는 방식임, 쉬운 문제라면 이런 거 다 생략하고 바로 묻기만 해도 답이 나오지만, 어려운 문제에서 바로 답을 묻는다면 그냥 그럴듯하게 지어내기 때문에, 반드시 현실적인 근거에서 시작해야 함, 그래서 구체적 맥락 - 옵션 분석 - pros & cons - 최종 선택의 흐름이 필요함
제목에 2024를 추가하라는 의견임
우리가 직접 했던 일을 AI에게 가르치고, 다시 AI가 그 일을 하도록 효과적으로 시키는 방법을 배우는 중이라는 생각이 듦, 만약 이 기술이 미국 전체 경제가 받쳐주지 않으면 마치 뜨거운 공기 풍선처럼 띄었다가 훅 가라앉을 수도 있겠음
다른 댓글들과 비슷하게 이게 정통 엔지니어링처럼 느껴지지 않음, 하지만 Anthropic이 모델 해석 가능성 분야에서 꽤 멋진 연구를 했다고 생각함, 만약 그 도구가 public API로 공개된다면 프롬프트에 따라 모델 내부 상태의 차이를 비교해보고 더 체계적인 튜닝을 할 수 있는 피드백 루프가 만들어질 수도 있을 것 같음
이 튜토리얼은 세 가지 모델(Sonnet, Haiku, Opus 3)을 위해 작성됨, 오늘날에도 적용될 교훈이 일부 있지만 더 똑똑한 RL 모델(Sonnet 4.5 등)에는 그다지 중요하지 않은 내용도 있음, 참고로 Claude 3 Haiku는 가장 작고 빠르며 저렴한 모델이고, Sonnet과 Opus는 더 지능적이며 Opus가 가장 우수함