지금까지 본 프롬프트 엔지니어링에 관한 최고의 토론 팟캐스트 콘텐츠입니다.

AI 요약

개요

AI 팁 엔지니어링 심도 있는 토론은 다음과 같은 여러 참가자와 함께 라운드 테이블 형식으로 진행되었습니다. 인류학 의 전문가들이 연구, 소비자, 비즈니스 등 다양한 관점에서 큐 엔지니어링에 대한 이해와 실무 경험을 공유했습니다.

이 문서에서는 큐 엔지니어링의 정의와 그 중요성, 훌륭한 큐 엔지니어가 되는 방법에 대해 자세히 설명합니다.

큐 엔지니어링은 단순한 텍스트 입력이 아니라 끊임없는 반복과 실험, 모델의 심리에 대한 깊은 이해가 필요한 과정이라는 것이 핵심 아이디어입니다..

여기에는 AI 모델과 효과적으로 소통하고 더 큰 시스템에 통합하는 방법이 포함됩니다.

큐 엔지니어링과 프로그래밍의 유사점과 다양한 애플리케이션 시나리오(예: 연구, 기업, 일상 대화)에서 강조하는 차이점도 살펴봅니다.

밑줄 명확한 의사소통, 반복 작업 능력, 모델 결과물에 대한 세심한 관찰력 프로젝트의 시작을 알리는 열쇠입니다.

또한 전문가들은 실제 애플리케이션에서 직면하는 다양한 문제에 대해 논의하고 엣지 케이스에 대처하는 방법, 모델 자체의 피드백을 사용하여 단서를 개선하는 방법, 다양한 유형의 모델을 구별하는 방법 등 귀중한 경험과 팁을 공유했습니다.

간단히 말해서이 기사에서는 독자들에게 엔지니어링을 신속하게 처리하고 향후 방향을 살펴볼 수 있는 포괄적이고 통찰력 있는 가이드를 제공합니다..

핵심 사항

• 큐 엔지니어링은 모델과 명확하게 소통하고 모델의 잠재력을 극대화하기 위해 반복하는 프로세스입니다.
• 엔지니어링의 핵심은 실험과 시행착오, 즉 처음부터 다시 돌아가서 다양한 접근 방식을 시도하는 능력입니다.
• 프롬프트는 단순한 텍스트가 아니라 데이터 소스, 지연 시간 및 시스템 설계를 고려해야 하는 전체 시스템에 통합된 프로그래밍 방식입니다.
• 훌륭한 프롬프트 엔지니어는 명확하게 의사소통하고 반복하며 모델 결과물을 심도 있게 분석할 수 있어야 합니다.
• 모델의 '마음'을 이해하는 것은 매우 중요하며 모델이 지침을 해석하는 방식을 고려해야 합니다.

혁신적인 인사이트

• 글을 코드라고 생각하고 코드를 작성하는 것만큼이나 좋은 에세이를 작성하는 것도 중요하다고 생각하세요.
• 머신러닝에서 '데이터 보기'와 유사하게 모델 결과물을 읽는 것의 중요성이 강조됩니다.
• 프롬프트 최적화를 위해 모델을 사용하거나 모델이 자체적으로 오류를 지적하도록 할 수도 있습니다.
• 많은 경우 캐릭터인 척하는 것보다 모델에게 직접 작업을 설명하는 것이 더 효과적이라는 주장이 있습니다.
• 큐 엔지니어링의 미래는 모델이 가이드 역할을 하면서 사용자로부터 정보를 얻는 데 더욱 집중할 것입니다.

주요 인용 및 번역

원래 1: 엔지니어링 부분은 시행착오에서 비롯된 것 같아요. - 알았어요. - 그래서 사람과 대화하는 것과는 다른 모델과 대화할 때 정말 좋은 점 한 가지는 사람과 대화하는 것과는 다른 모델과 대화할 때 정말 좋은 점 중 하나는 다시 시작 버튼이 있다는 점입니다.

번역: '엔지니어링'이라는 부분은 시행착오에서 비롯된다고 생각합니다. 모델과 대화하는 것과 사람과 대화하는 것의 매우 다른 점 중 하나는 리셋 버튼이 있다는 것입니다. 이 거대한 버튼을 누르면 원점으로 돌아가 처음부터 다시 시작할 수 있습니다.

인용 이유: 이 인용문은 큐 엔지니어링에서 '엔지니어링'의 의미를 설득력 있게 짚어주고, 큐 엔지니어링을 다른 형태의 커뮤니케이션과 차별화하는 핵심인 큐를 개선하기 위한 지속적인 실험과 반복의 중요성을 강조합니다.

Original 2: 프롬프트를 모델을 프로그래밍하는 방식이라고 생각하면 너무 복잡해집니다. 일반적으로 잭의 말이 맞다고 생각하기 때문입니다. 하지만 모델을 프로그래밍하는 방식으로 조금만 생각해보면, 데이터의 출처, 액세스 권한이 있는 액세스 할 수있는 데이터... (단락 7)

번역: 힌트는 모델을 프로그래밍하는 방법과 비슷하다고 생각하는데, 말하기는 조금 복잡하지만요. 명확한 커뮤니케이션이 중요하다는 잭의 말이 맞다고 생각하기 때문입니다. 하지만 힌트를 모델 프로그래밍이라고 생각하면 데이터의 출처와 액세스 권한이 있는 데이터에 대해 생각해야 합니다.

인용 이유: 이 구절은 큐잉과 프로그래밍을 연결하여 큐잉은 언어에 관한 것이 아니라 데이터, 지연 시간 및 시스템 통합과 같은 요소를 포함한 시스템적 사고가 필요하다는 점을 강조합니다.

그래서 저는 모델의 100개의 출력을 보고 정말 일관성이 있다면 모델을 신뢰할 수 있다고 생각합니다. 그리고 저는 기본적으로 모델이 할 수 있는 모든 에지 케이스와 이상한 입력 등 모든 이상한 상황을 파악하기 위해 이러한 모델을 구성했다는 것을 알고 있습니다. 그리고 저는 기본적으로 모든 에지 케이스와 모델이 수행 할 수있는 모든 이상한 일, 이상한 입력 등을 파악하기 위해이를 구성 한 것으로 알고 있습니다. 아마도 훨씬 더 느슨하게 구성된 수천 개의 집합보다 더 많은 것을 파악할 수 있을 것이라고 믿습니다.

번역: 따라서 모델의 100개의 출력을 살펴본 결과 매우 일관성이 있고, 모델이 할 수 있는 모든 에지 케이스와 이상한 일, 이상한 입력 등을 파악하기 위해 이러한 출력을 구성했다는 것을 알고 있다면, 느슨하게 구성된 수천 개의 출력보다 그 모델을 더 신뢰하게 될 것입니다.

인용 이유: 이 구절은 품질이 낮은 대규모 데이터 세트보다 품질이 높은 소규모 데이터 세트의 가치를 강조합니다. 큐 엔지니어링에서는 맹목적으로 많은 수의 샘플을 추구하기보다는 엣지 케이스를 적절히 고려하는 데 초점을 맞춰야 합니다.

읽기 노트

[엔지니어링의 본질에 대한 힌트]: 반복과 실험

• 큐 엔지니어링은 시행착오와 반복을 통해 모델 결과물을 최적화하는 프로세스입니다.
• 마치 프로그램처럼 실험을 관리하고 추적하는 것을 강조합니다.
• 명확한 커뮤니케이션은 큐 엔지니어링의 기본입니다.

#프로모트 엔지니어링 1TP5역가 1TP5실험

[신속한 엔지니어의 자질]: 이해와 관찰력

• 명확한 의사소통 능력과 반복할 의지가 필요합니다.
• 모델에 대한 깊은 이해와 모델 결과물을 통해 학습할 수 있는 능력이 필요합니다.
• 실제 사용 시나리오와 사용자 입력의 다양성을 고려해야 합니다..

1TP5의사소통 1TP5이해 1TP5관찰

[모델 상호 작용]: 신뢰와 도전

• 모델을 맹목적으로 신뢰해서는 안 되며, 지속적으로 신뢰성을 테스트하고 검증해야 합니다.
• 모델을 사용하여 오류를 자가 진단하고 개선 사항을 제안할 수 있습니다..
• 모델은 사용자가 작업을 더 잘 이해하고 메시지를 표시하는 데 도움이 될 수 있습니다.

#신뢰 #피드백 #협업

• 큐 엔지니어링 프로세스::

开始 --> 编写初始提示 --> 模型输出 --> 分析结果 --> 修改提示 --> 循环直至满意

주기적인 프로세스와 마찬가지로 팁은 원하는 결과를 얻기 위해 지속적으로 개선됩니다.

• 모델링 평가::

|  输出一致性 | 边缘情况覆盖 | 输入多样性 |
|------------|------------|------------|
|    高       |     高      |     高     |

• 일관성, 에지 케이스 커버리지, 입력 다양성의 세 가지 주요 차원이 높을수록 좋습니다.

엔지니어링의 미래를 위한 팁

用户需求 --> 模型理解 --> 模型提问 --> 用户反馈 --> 优化提示 --> 最终输出

• 향후 큐 엔지니어링에서는 모델이 사용자 요구사항을 파악하고 큐를 최적화하는 과정에 더욱 적극적으로 참여할 것입니다.

핵심 이슈에 대한 질문과 답변

1. 프롬프트 프로젝트란 무엇인가요?

프롬프트 엔지니어링 은 프롬프트(프롬프트)를 설계하고 최적화하여 대규모 언어 모델(LLM)이 특정 작업을 수행하도록 안내하는 기법입니다. 명확하고 정확한 커뮤니케이션을 통해 모델이 원하는 결과물을 생성할 수 있도록 하는 것이 목표입니다. 다음은 프롬프트 엔지니어링에 대한 자세한 설명입니다:

큐의 정의

• 지시어프롬프트는 모델이 특정 작업을 수행하도록 하기 위해 사용자가 모델에 제공하는 명령어입니다. 간단한 문장이거나 여러 단계가 포함된 복잡한 설명일 수 있습니다.
• 절차힌트는 자연어로 작성된 절차로서 모델이 작업을 수행하도록 안내하는 것으로 간주할 수도 있습니다.
• 커뮤니케이션 방법기본적으로 프롬프트는 사람과 대화하는 것과 마찬가지로 모델과 소통하는 방식이므로 명확하고 모호하지 않아야 합니다.

프로젝트의 핵심 요소 큐

• 명확한 커뮤니케이션프롬프트 엔지니어링은 사용자가 자신의 요구 사항을 정확하게 표현하고 모델이 작업의 특정 요구 사항을 이해할 수 있도록 명확한 커뮤니케이션을 강조합니다.
• 반복 프로세스큐 엔지니어링은 모델의 성능을 개선하기 위해 지속적으로 큐를 시도하고 수정하고 최적화하는 반복적인 프로세스입니다. 이는 소프트웨어 엔지니어링의 개발 및 디버깅 프로세스와 유사합니다.
  • 테스트다양한 단서를 시도하고 결과에 따라 단서를 조정하여 모델의 반응을 관찰합니다.
  • 정보 다시 보내기모델의 출력을 분석하고 오류를 식별하여 적절히 수정합니다.
  • 주기원하는 결과를 얻을 때까지 실험과 피드백을 반복합니다.
• 체계적인 사고프롬프트 엔지니어링은 개별 프롬프트를 작성하는 것뿐만 아니라 프롬프트가 전체 시스템에 통합되는 방식도 고려해야 합니다. 이를 위해서는 데이터의 출처, 처리 방법, 시스템에서 모델의 역할 등을 고려해야 합니다.
• 모델 이해하기큐잉 엔지니어는 더 나은 큐를 디자인하기 위해 모델의 작동 방식과 한계를 이해해야 합니다. 여기에는 모델이 다양한 유형의 입력을 처리하는 방법과 모델의 추론 과정을 안내하는 방법을 이해하는 것이 포함됩니다.
• 문제 해결 능력팁 엔지니어는 엔지니어링 문제를 해결하듯 가능한 모든 시나리오를 체계적으로 고려하고 이에 대한 솔루션을 제공해야 합니다.
  • 예측 오류모델이 어떻게 잘못될 가능성이 있는지 예측하고 이러한 오류를 처리하기 위한 적절한 힌트를 고안합니다.
  • 엣지 케이스 처리비정상적인 입력이나 오류가 발생했을 때 모델이 어떻게 반응하는지 고려합니다.
• 버전 관리버전 관리, 실험 추적 등을 포함한 힌트를 코드처럼 취급합니다.
• 모델 출력 읽기결과가 올바른지 확인하는 것뿐만 아니라 모델의 추론 과정을 이해하기 위해 모델의 출력을 주의 깊게 읽습니다.
• 이론적 사고모델을 이해할 때는 자신의 이해를 바탕으로 작성하는 것이 아니라 모델이 이론적 수준에서 내 지시를 어떻게 이해할 수 있는지 고려해야 합니다.

리마인더 프로젝트의 목적

• 모델링의 잠재력 활용큐 엔지니어링의 목적은 모델의 잠재력을 최대한 활용하여 원래의 설계 기능 이상의 작업을 수행할 수 있도록 하는 것입니다.
• 모델 성능 최적화잘 설계된 단서를 통해 특정 작업에서 모델의 성능을 개선합니다.
• 모델 행동 안내: 모델이 원하는 출력을 생성하고 원치 않는 출력을 피할 수 있도록 하는 단서를 통해 모델의 동작을 안내합니다.

큐 엔지니어링 과제

• 표현하기 어려움작업을 말로 정확하게 설명하고 모든 가정을 배제하는 것은 어렵습니다.
• 모델은 질문을 하지 않습니다.모델은 사람처럼 명확한 질문을 하지 않으므로 큐잉 엔지니어는 가능한 모델 쿼리를 직접 예측하고 큐에서 적절한 답변을 제공해야 합니다.
• 완벽한 팁을 찾기 어려운 이유완벽한 팁을 찾는 것은 항상 더 좋은 팁이 있을 가능성이 있기 때문에 어려운 일이 될 수 있습니다.

큐 엔지니어링 애플리케이션

• 다양한 장면큐 엔지니어링은 연구, 기업용 애플리케이션, 소비자 애플리케이션 등 다양한 시나리오에 적용할 수 있습니다.
• 다양한 유형의 작업프롬프트 프로젝트는 텍스트 생성, 정보 추출, 질문 답변, 코드 생성 등 다양한 유형의 작업에 사용할 수 있습니다.
• 시스템에 통합프롬프트 엔지니어링은 개별 프롬프트를 작성하는 것뿐만 아니라 전체 시스템에 프롬프트를 통합하는 작업입니다.

엔지니어링의 미래를 위한 팁

• 모델 지원 힌트앞으로 이 모델은 질문하기, 제안 제공, 프롬프트 자동 생성 등 사용자가 더 나은 프롬프트를 작성하는 데 도움을 줄 수 있을 것입니다.
• 인간과 기계의 협업향후 큐 엔지니어링은 사용자의 목표에 따라 모델이 질문을 하고 사용자가 보다 효과적인 큐를 작성하도록 안내하는 인간과 컴퓨터의 협업 모델로 전환될 수 있습니다.
• 안내부터 상담까지모델이 더 스마트해짐에 따라 큐 엔지니어링은 안내 모델에서 사용자의 목표에 따라 역으로 사용자에게 큐를 제공하는 자문 모델로 전환될 수 있습니다.

프롬프트 엔지니어링은 창의성, 논리적 사고, 시스템적 사고가 필요한 기술입니다. 단순히 좋은 큐를 작성하는 것이 아니라 모델을 이해하고, 실험을 설계하고, 반복적인 최적화와 문제 해결에 관한 것입니다. 큐 엔지니어는 모델의 잠재력을 최대한 실현하기 위해 엔지니어처럼 실험하고 배워야 합니다.

2. 좋은 큐 엔지니어의 자질은 무엇인가요?

• 명확한 커뮤니케이션 기술: 훌륭한 프롬프트 엔지니어는 아이디어를 명확하게 표현하고, 작업을 명확하게 이해하며, 개념을 정확하게 설명할 수 있습니다. 여기에는 모델이 이해하기 쉬운 방식으로 지침을 구성하는 능력도 포함됩니다.
• 반복 기능이들은 프롬프트를 지속적으로 반복하고 조정하며 모델이 잘못 해석할 수 있는 부분에 대해 생각합니다. 이 반복적인 프로세스에는 모델의 응답을 분석하고 오류를 식별하며 수정하는 작업이 포함됩니다.
• 엣지 케이스 테스트입력이 null이거나 예상 형식이 아닌 경우와 같이 큐가 잘못될 수 있는 덜 일반적인 상황에 대해 적극적으로 고민합니다. 여기에는 모델이 다양한 상황에서 제대로 작동하는지 확인하기 위해 다양한 예외를 테스트하는 것이 포함됩니다.
• 모델 출력 이해훌륭한 큐잉 엔지니어는 결과뿐만 아니라 모델의 출력에도 세심한 주의를 기울입니다. 그들은 모델의 사고 과정을 탐구하고 그 추론을 이해하려고 노력합니다.
• 이론적 사고자신의 이해를 바탕으로 작업을 완료하는 데 필요한 모든 정보를 체계적으로 세분화할 수 있습니다. 모델이 이해할 수 있는 방식으로 필요한 정보를 명확하게 전달할 수 있습니다.
• 공감모델의 입장이 되어 모델이 자신의 지시를 어떻게 인식하는지 이해할 수 있습니다. 또한 사용자의 요구 사항을 고려하고 사용자가 모델과 상호 작용하는 방식을 이해해야 합니다.
• 실험적 사고방식끊임없는 실험과 시행착오를 통해 모델의 한계를 발견합니다. 그들은 실패를 두려워하지 않고 실패를 통해 배우며 모델의 기능 한계를 뛰어넘어 모델에 대한 이해를 심화시킵니다 ...
• 모델링을 사용한 개선 사항자신의 노력뿐만 아니라 모델 자체를 사용하여 프롬프트를 개선합니다. 예를 들어, 모델에게 지침의 모호한 부분을 지적하거나 모델에게 변경 사항을 제안하도록 요청합니다. 모델에게 오류를 설명하고 지침을 개선하도록 요청합니다.
• 신뢰하되 확인: 모델의 기능에 대해 신중을 기하고 반복적인 테스트를 통해 신뢰성을 확보합니다. 모델을 맹목적으로 신뢰하기보다는 광범위한 테스트를 통해 모델의 결과를 검증합니다.
• 조사프롬프트와 모델 출력을 주의 깊게 읽고 세부 사항을 분석합니다. 모델 출력의 세부 사항을 분석하여 모델이 어떻게 생각하는지 배우게 됩니다.
• 완벽에 집착하지 않기완벽한 프롬프트를 위해 노력하는 대신 계속 시도하고 실수로부터 배우게 됩니다. 프롬프트가 일회성 작업이 아니라 반복적인 과정이라는 것을 인식하게 됩니다.
• 텍스트를 코드로 취급하기코드로서의 텍스트의 의미를 이해하고 힌트에도 버전 관리, 실험 추적 등이 필요하다는 것을 이해할 수 있습니다.
• 다양한 관점에서 사고하는 능력훌륭한 큐잉 엔지니어는 실제 사용자의 요구를 고려할 뿐만 아니라 모델의 입장이 되어보는 등 다양한 관점에서 생각할 수 있습니다.
• 새로운 개념을 창출하는 능력필요에 따라 새로운 개념을 정의하고 모델 작업을 통해 이를 명시적으로 표현합니다.
• 아이디어를 외부화하는 능력자신의 아이디어를 명확하게 표현할 수 있고 머릿속의 복잡한 개념을 모델이 이해할 수 있는 지침으로 변환할 수 있습니다.

훌륭한 큐잉 엔지니어는 명확한 의사 소통과 반복적인 작업뿐만 아니라 공감 능력이 뛰어나고 모델의 입장에서 생각할 수 있으며, 에지 케이스를 테스트하여 모델의 한계를 발견하면서 지속적으로 실험하고 학습할 수 있습니다. 또한 모델 자체를 사용하여 단서를 개선하고 모델 출력의 세부 사항에서 학습할 수 있습니다. 이들은 완벽을 추구하기보다는 단서에 도달하는 과정이 반복적이라는 점을 이해하고 텍스트와 코드 간의 유사점을 이해해야 합니다. 또한 사용자 경험과 모델 자체가 인식되는 방식이라는 두 가지 측면에서 다양한 관점을 고려해야 합니다. 가장 중요한 것은 자신의 아이디어를 명확하게 표현하고 머릿속에 있는 개념을 외부화할 수 있어야 한다는 것입니다.

3. 모델과 효과적으로 상호 작용하는 방법은 무엇인가요?

3.1 명확한 커뮤니케이션이 중심

• 정확한 요구 사항 표현: 사람들과 소통할 때와 마찬가지로, 모델이 여러분이 원하는 바를 정확히 이해할 수 있도록 요구 사항을 명확하게 표현해야 합니다.모호한 지침 피하기를 사용하여 모델이 달성할 것으로 기대하는 목표를 최대한 구체적으로 설명하세요.
• 작업의 세부 사항을 명확히 합니다: 그래야 합니다.모든 가정을 버리세요.를 클릭하고 모델이 알아야 할 모든 정보를 자세히 설명합니다.모델이 명시적으로 말하지 않은 내용을 알고 있다고 가정하지 마세요..

3.2 프롬프트를 절차로 간주합니다.

• 자연어 코드: 프롬프트는 모델에게 작업을 안내하기 위해 자연어로 작성된 절차로 생각할 수 있습니다.
• 시스템적 사고: 프롬프트를 코드처럼 취급버전 관리, 실험 추적 등을 포함합니다. 데이터 소스, 데이터 처리 및 시스템에서 모델의 역할을 포함하여 전체 시스템에 단서가 어떻게 들어맞는지 고려해야 합니다.

3.3 반복과 실험을 수용하세요

• 시행착오를 겪는 것은 당연한 일입니다: 큐 엔지니어링은 다양한 큐를 지속적으로 시도하고 모델의 피드백에 따라 조정하는 시행착오를 거치는 과정입니다.
• 다시 시작 버튼: 이 모델에는 '다시 시작 버튼'이 있어 언제든지 처음으로 돌아가 이전 실험에 방해받지 않고 처음부터 다른 접근 방식을 시도할 수 있습니다.
• 자주 반복하세요: 효과적인 큐잉 엔지니어링을 위해서는 모델과 자주 상호 작용해야 합니다.앞뒤로 반복한 번에 완벽한 결과를 기대하는 것보다 더 나은 결과를 얻을 수 있습니다.

3.4 모델의 마음 이해하기

• 모델링 관점: 모델의 관점에서 지시 사항을 생각하고 모델이 요구 사항을 어떻게 이해할 수 있는지 이해하려고 노력하세요. 이를 위해서는 다음이 필요합니다.모델 재생를 사용하여 캐릭터의 사고 방식을 모방합니다.
• 모델 출력을 읽습니다: 결과가 올바른지 여부뿐만 아니라 모델의 추론 과정을 이해하는 데 중점을 두고 모델의 결과를 주의 깊게 읽습니다.출력에서 학습하기를 클릭하고 모델이 사용자의 지시를 이해하는 방식을 이해합니다.
• 모델 오류를 살펴보세요: 모델이 저지르는 실수를 무시하지 마세요.모델이 틀린 이유를 물어보세요.를 클릭하고 오류의 원인을 파악하고 모델에게 지침을 수정하도록 요청할 수도 있습니다. 모델은 때때로 지침의 모호한 부분을 지적하고 개선을 위한 제안을 할 수 있습니다.

3.5 엣지 케이스 처리

• 예측 오류: 모델이 잘못될 수 있는 상황 예상하기를 살펴보고 이러한 오류를 처리할 수 있는 적절한 단서를 설계하세요. 예를 들어 비정상적인 입력이나 오류가 발생했을 때 모델이 어떻게 반응하는지 고려하세요:
  • 옵션을 제공합니다: 모델이 특정 입력에 대해 무엇을 해야 할지 확실하지 않은 경우 '종료'를 지정하세요(예: '확실하지 않음'이라는 레이블을 출력하도록 함).
  • 극단적인 상황을 테스트합니다: 다양한 극단적인 상황(예: 빈 문자열, 예상과 일치하지 않는 입력)에서 프롬프트를 테스트하여 모델이 다양한 상황에서 잘 작동하는지 확인하세요.

3.6 모델을 존중하는 능력

• 이 모델을 과소평가하지 마세요: 모델을 멍청한 존재로 생각하지 말고 '설득'해야만 작동한다고 생각하세요.모델의 역량을 존중하세요.를 클릭하고 목표를 이해할 수 있도록 충분한 컨텍스트와 정보를 제공하세요.
• 직접 정보를 제공하세요: 모델에게 새로운 기술을 배우게 하려면 직접 말로 설명하지 말고 관련 논문이나 문서를 보여주면 됩니다.
• 지나치게 단순화하지 마세요: 일부러 지침을 단순화하지 말고 복잡한 작업을 처리할 수 있도록 모델을 신뢰하세요.

3.7 모델링 보조 도구 사용

• 모델 생성 예시: 모델을 사용하여 예제를 생성한 다음 수정할 수 있으므로 고품질의 프롬프트를 더 빠르게 생성할 수 있습니다.
• 인터뷰용 모델링: 모델이 사용자를 인터뷰하고 머릿속에 있는 정보를 추출하여 그 정보를 프롬프트로 전환하도록 합니다.

3.8 완벽한 팁에 현혹되지 마세요

• 완벽이란 없습니다: '완벽한 팁을 찾으려는' 함정에 빠지지 말고 항상 개선의 여지가 있다는 것을 인식하세요.
• 지속적인 학습: 모델과의 모든 상호작용은 학습의 기회이며, 모든 시도를 통해 모델을 더 잘 이해할 수 있습니다.
• 경계 탐색에 집중하세요: 모델이 할 수 없다고 생각되는 작업을 수행하도록 하고 모델의 경계를 탐색하면서 학습하세요.

3.9 다양한 시나리오 구분

• 연구 및 기업: 연구 환경에서는 다양성과 탐색에 더 집중할 수 있는 반면, 기업 환경에서는 신뢰성과 일관성에 더 집중할 수 있습니다.
• 인간과 컴퓨터의 대화 및 시스템 애플리케이션: 인간과 컴퓨터 간의 대화에서는 여러 번 반복할 수 있지만 시스템 애플리케이션에서는 다양한 상황을 한 번에 처리할 수 있는 프롬프트를 작성해야 합니다.

3.10 메타 프롬프트 사용

• 프롬프트에 대한 프롬프트를 생성합니다: "메타 힌트"를 사용하여 모델이 필요한 출력이나 쿼리를 생성하도록 할 수 있습니다. 모델에 힌트 기법에 대한 문서를 제공하고 다른 모델이 해당 기법을 수행하도록 메타 힌트를 생성하도록 할 수 있습니다.

요컨대, 모델과 효과적으로 상호 작용하려면 명확한 의사소통, 체계적인 사고, 일관된 실험, 깊은 이해, 모델의 기능에 대한 존중이 필요합니다. 동시에 모델을 효과적으로 활용하면 프롬프트를 더 빠르게 반복하고 최적화하는 데 도움이 될 수 있습니다. 완벽한 단서란 존재하지 않으며 지속적인 학습과 개선만이 존재한다는 사실을 기억하세요.

프롬프트에 대한 일반적인 오해 4.

4.1 힌트는 간단한 지침일 뿐입니다:

• 오해: 사람들은 종종 프롬프트를 검색 엔진에 키워드를 입력하는 것처럼 모델에게 간단한 지시를 내리는 것으로 생각합니다. 몇 가지 키워드만 입력하면 모델이 작업을 수행한다고 생각하여 명확하고 정확한 커뮤니케이션의 중요성을 간과할 수 있습니다.
• 사실: 사실.힌트는 복잡한 프로그래밍 방식입니다.버전 관리 및 실험 추적 등 코드처럼 취급해야 합니다. 모델이 작업을 정확하게 이해하고 원하는 결과물을 생성할 수 있도록 좋은 단서를 신중하게 설계하고 반복해야 합니다.

4.2 팁은 정적이며 한 번만 작성됩니다:

• 오해: 어떤 사람들은 프롬프트를 작성하는 것이 에세이를 작성하는 것과 같다고 생각하며, 이미 작성되었으므로 더 이상 수정할 필요가 없다고 생각합니다.
• 사실: 힌트 프로젝트는반복 프로세스를 사용하여 지속적인 실험, 수정 및 최적화가 필요합니다. 모델을 여러 번 사용하여 다음과 같은 작업을 수행해야 합니다.앞뒤로 상호 작용를 사용하여 모델 출력을 읽고 오류를 분석하여 단서를 개선할 수 있습니다. 효과적인 큐 엔지니어링에는 다음이 필요합니다.실험과 피드백 수용를 클릭하세요.

4.3 팁에는 완벽한 문법과 문장 부호가 필요합니다:

• 오해: 모델을 이해하려면 프롬프트가 완벽한 문법과 문장 부호를 사용해야 한다고 생각하는 경우가 많습니다.
• 사실: 세부 사항에 대한 주의도 중요하지만모델은 일반적으로 맞춤법 오류나 문법적 결함이 포함된 단서를 이해합니다.. 중요.개념의 명확성문법적 완벽성보다는 완성도에 중점을 둡니다. 최종 프롬프트에서 오류를 수정하는 것은 좋지만 반복하는 동안 불완전한 것은 허용됩니다.

4.4 모델이 작동하도록 '유도'해야 합니다:

• 오해: 어떤 사람들은 모델을 어리석다고 생각하며 모델에게 거짓 신분이나 역할을 부여하는 등 속임수나 '거짓말'을 사용하여 작업을 안내해야 한다고 생각합니다.
• 사실: 모델에 대한 이해도가 높습니다."꾀어낼" 필요는 없습니다. 그래야 합니다.존중 모델를 클릭하고 명확하고 정확한 정보를 직접 제공하여 목표를 이해할 수 있도록 하세요.작업을 직접 설명하세요.를 사용하여 모델을 안내하는 대신 은유나 유사한 작업을 사용합니다.

4.5 큐 엔지니어링의 핵심은 완벽한 지침을 작성하는 것입니다:

• 오해: 어떤 사람들은 큐 엔지니어링의 요점이 완벽한 지침을 찾고 각 단어를 파악하는 데 많은 시간을 할애하는 것이라고 생각합니다.
• 사실: 정확한 지침도 중요하지만, 그보다 더 중요한 것은모델 작동 방식 이해그리고모델의 출력을 읽고 다음을 학습합니다..모델의 사고방식 이해뿐만 아니라다양한 입력을 처리하는 방법완벽한 지침을 찾는 것보다 더 중요합니다. 훌륭한 큐잉 엔지니어는 다음을 수행할 수 있어야 합니다.모델 출력에서 신호 추출하기를 통해 결과가 올바른지 여부뿐만 아니라 그 추론 과정을 이해할 수 있습니다.

4.6 팁 엔지니어링은 글쓰기일 뿐입니다:

• 오해: 어떤 사람들은 프롬프트 엔지니어링의 핵심 역량이 글쓰기 능력에 있다고 생각하며, 글쓰기를 잘하면 당연히 좋은 프롬프트 엔지니어가 될 수 있다고 믿습니다.
• 사실: 좋은 글쓰기 능력은 필요하지만큐 엔지니어링의 핵심 역량이 아닙니다.. 훌륭한 프롬프트 엔지니어는 다음을 갖추어야 합니다.실험 정신, 시스템 사고, 문제 해결 능력too모델 마인드 이해 능력.반복 및 테스트단순한 글쓰기 실력 그 이상.

4.7 모델에게 너무 많은 정보를 제공하지 않아야 합니다:

• 오해: 어떤 사람들은 모델에게 너무 많은 정보를 제공하면 혼란스러워질 것을 우려하여 지침을 단순화하고 복잡성을 숨기려고 합니다.
• 사실: 모델 기능이 향상됨에 따라 다음을 처리할 수 있습니다.자세한 정보 및 컨텍스트.모델을 신뢰해야 합니다.를 클릭하고 작업을 더 잘 이해할 수 있도록 충분한 정보를 제공하세요.

4.8 예시 팁이 많을수록 좋습니다:

• 오해: 많은 예제를 제공하는 것이 모델 성능을 향상시키는 유일한 방법이라고 생각할 수 있습니다.
• 사실: 예제는 모델을 안내하는 데 도움이 되지만 예제가 너무 많으면 다음과 같은 문제가 발생할 수 있습니다.모델링의 창의성과 다양성 제한.. 연구 환경에서.구체적인 예시보다는 설명적인 예시 사용모델이 단순히 예제를 복사하는 것이 아니라 작업 자체에 대해 생각하도록 유도하기 때문에 더 효과적일 수 있습니다.

4.9 모델은 사람처럼 생각하고 추론합니다:

• 오해: 모델도 인간처럼 추론하고 '사고 단계' 신호를 이해할 것이라고 생각할 수 있습니다.
• 사실: 모델은 예를 들어 다음과 같은 방법으로 추론 프로세스를 모방할 수 있습니다.생각의 연쇄와 비슷하지만 반드시 진정한 추론은 아닙니다. 모델은 사용자가 제공한 지침과 예제를 기반으로 텍스트를 생성할 뿐입니다. 다음 사항을 이해하는 것이 중요합니다.모델과 인간의 사고 방식은 다릅니다.를 사용하여 모델의 행동을 지나치게 의인화하지 마세요.

4.10 롤플레잉 프롬프트는 항상 작동합니다:

• 오해: 어떤 사람들은 모델에게 특정 역할(예: "당신은 선생님입니다")을 맡기면 성능이 향상된다고 생각합니다.
• 사실: 롤플레잉 프롬프트는 일부 상황에서 효과가 있을 수 있지만 항상 필요한 것은 아닙니다. 달성하고자 하는 목표를 직접 설명하세요.모델을 다른 사람인 것처럼 가장하는 것보다 더 효과적입니다. 모델의 기능이 향상됨에 따라 모델에 잘못된 신분을 부여하는 것보다 작업 설명과 컨텍스트를 직접 제공하는 것이 더 나을 수 있습니다.

4.11 좋은 팁을 찾으면 언제든 활용할 수 있습니다:

• 오해: 어떤 사람들은 효과가 있는 큐를 한 번 찾으면 영원히 효과가 있고 조정할 필요가 없다고 생각합니다.
• 사실: 모델링 기능이 지속적으로 개선됨에 따라효과적인 팁도 오래되었을 수 있습니다.. 일부 큐잉 기술은 모델에 학습되어 더 이상 명시적으로 큐잉할 필요가 없도록 할 수 있습니다. 다음을 수행해야 합니다.지속적인 학습 및 적응를 사용하여 모델 변경에 대응할 수 있습니다.

이러한 일반적인 오해를 이해하면 모델과 더 효과적으로 상호 작용하고 다양한 작업에 힌트 엔지니어링을 더 잘 활용할 수 있습니다. 힌트 엔지니어링은 단순한 명령어 입력이 아니라 심도 있는 이해와 연습이 필요한 분야입니다.

5. 기업 팁과 연구 팁 비교

기업 팁노래로 응답연구 레벨 팁목표, 방법, 초점에는 상당한 차이가 있습니다.

기업 팁

• 신뢰성 강조엔터프라이즈 애플리케이션에서는 안정성이 매우 중요합니다. 엔터프라이즈 수준 힌트의 목표는 모델이 다양한 상황에서 일관되고 예상되는 결과를 생성하도록 하는 것입니다. 이를 위해서는 일반적으로 모델의 자유도를 제한하기 위해 많은 예제와 구체적인 지침이 필요합니다.
• 형식에 집중:: 기업 프롬프트는 출력 형식에 크게 중점을 둡니다. 비즈니스 애플리케이션의 경우 출력 형식의 안정성과 일관성은 사용자 인터페이스 표시 및 후속 데이터 처리의 효율성에 영향을 미치기 때문에 다양성보다 더 중요한 경우가 많습니다.
• 사용자 요구 사항에 집중엔터프라이즈급 프롬프트는 사용자의 특정 요구에 매우 빠르게 응답할 수 있어야 합니다. 즉, 프롬프트는 다양한 입력을 처리하고 사용자의 특정 요구 사항을 충족하는 출력을 생성할 수 있어야 합니다.
• 체계적인 사고엔터프라이즈 수준의 단서는 종종 더 큰 시스템과의 통합을 고려해야 하는 경우가 많습니다. 여기에는 데이터 소스, 지연 시간, 모델을 다른 소프트웨어 및 프로세스와 통합하는 방법을 고려하는 것이 포함됩니다.
• 수많은 테스트와 반복엔터프라이즈 팁은 실제 애플리케이션에서 높은 수준의 신뢰성과 안정성을 보장하기 위해 다양한 입력과 시나리오에서 테스트해야 합니다. 여기에는 다양한 엣지 케이스와 가능한 다양한 사용자 입력에 대한 테스트가 포함됩니다.
• 일관성 유지에 집중엔터프라이즈 애플리케이션에서는 답이 반복적이더라도 기대치를 충족하는 한 허용됩니다. 이는 연구 환경에서의 탐색적 목표와는 다릅니다.
• 장기적인 애플리케이션에 집중엔터프라이즈 팁은 여러 번 재사용할 수 있는 시스템을 구축하도록 설계되었습니다. 따라서 기업용 프롬프트는 안정적으로 작동하도록 하기 위해 더 많은 시간과 노력이 필요합니다.
• 지나친 추상화 피하기:: 기업 수준의 프롬프트는 지나치게 추상적인 지침을 피하고 대신 작업과 필요한 결과물을 명확하게 설명해야 합니다.

연구 레벨 팁

• 다양성 및 탐색에 대한 강조연구 수준 프롬프트의 목표는 모델의 다양한 기능을 탐색하고 모델을 적용할 수 있는 새로운 용도를 발견하는 것입니다. 이를 위해서는 일반적으로 모델에 대한 제약을 줄이고 다양한 결과와 솔루션을 탐색하도록 장려하는 것이 수반됩니다.
• 예시를 거의 또는 전혀 사용하지 않음모델의 탐구 범위를 제한하지 않기 위해 연구 수준의 프롬프트는 일반적으로 예제 수를 줄이거나 구체적인 예제를 제공하지 않습니다.
• 인지적 작업에 집중연구 수준의 프롬프트는 인지 작업, 즉 모델이 복잡한 문제를 이해하고 해결하는 방식에 더 중점을 둡니다.
• 예시 사용연구 수준의 프롬프트에서 예제를 제공하는 경우, 예제는 구체적이기보다는 설명적인 경향이 있습니다. 즉, 예제는 모델이 실제로 작업해야 하는 데이터와 다를 수 있으며, 예제를 직접 모방하기보다는 모델이 작업의 특성을 이해하도록 돕는 것이 목표입니다.
• 새로운 경계에 도전하기연구 수준 프롬프트의 목표는 모델 기능의 한계에 도전하고 모델이 잘하는 것과 못하는 것을 발견하는 것입니다. 여기에는 모델의 한계를 더 잘 이해하기 위해 모델이 잘하지 못하는 작업을 시도하는 것도 포함됩니다.
• 유연하고 다양한 출력에 대한 집중도 향상:: 연구 수준의 프롬프트는 일관성이 높지 않더라도 모델이 어떤 종류의 결과물을 생성할 수 있는지 탐색하는 데 더 중점을 둘 수 있습니다. 연구 수준의 프롬프트는 결과가 올바른지 여부보다는 모델의 사고 방식과 결과의 품질 및 깊이에 더 중점을 둡니다.
• 더 자세히 알아보기연구용 단서는 보다 탐색적이며 일관성이나 형식에 덜 집중할 수 있습니다. 연구자는 새로운 상황에 직면했을 때 모델이 어떻게 반응하는지, 단서를 사용하여 모델을 탐색 방향으로 이끄는 데 어떻게 사용할 수 있는지에 더 관심을 기울일 것입니다.

요약::

• 다양한 목표기업 수준의 프롬프트는 신뢰성과 일관성에 중점을 두고 실제 문제를 해결하는 데 목적이 있으며, 연구 수준의 프롬프트는 다양성과 혁신에 중점을 두고 모델링 기능을 탐색하는 데 목적이 있습니다.
• 다양한 방법기업 수준의 프롬프트는 일반적으로 모델의 출력을 제어하기 위해 많은 수의 구체적인 예제를 사용하는 반면, 연구 수준의 프롬프트는 일반적으로 모델이 새로운 가능성을 탐색하도록 장려하기 위해 예제를 거의 또는 전혀 사용하지 않습니다.
• 초점의 차이엔터프라이즈 수준의 프롬프트는 사용자 요구 사항과 시스템 통합에 초점을 맞추고, 연구 수준의 프롬프트는 인지 프로세스와 모델 경계에 초점을 맞춥니다.
• 다양한 개발 및 테스트 주기:: 엔터프라이즈급 힌트는 일반적으로 프로덕션 환경에서 장기간 실행해야 하므로 더 엄격한 테스트와 품질 관리가 필요한 반면, 연구용 힌트는 모델의 다양한 잠재력을 탐색하기 위해 테스트 및 반복 주기가 더 짧을 수 있습니다.
• 모델링에 대한 다양한 접근 방식:: 기업 수준의 프롬프트는 모델을 올바르게 이해하기 위해 모델을 '수용'하는 경우가 있는 반면, 연구 수준의 프롬프트는 모델의 기능을 '존중'하고 모델에 더 많은 자율성을 부여하는 경향이 있습니다.

기업 수준의 프롬프트와 연구 수준의 프롬프트의 근본적인 차이점은 목적과 초점입니다.

엔터프라이즈 수준의 힌트는 사용자에게 신뢰할 수 있는 솔루션을 제공하는 데 전념하는 반면, 연구 수준의 힌트는 모델의 기능에 대한 이해를 넓히는 데 전념합니다.

실제로 이 두 가지 단서에는 서로 다른 접근 방식과 기술이 필요할 수 있습니다.

6. 엔지니어링의 미래를 위한 팁

6.1 모델은 사용자의 의도를 더 잘 이해할 수 있지만 여전히 명확성이 중요합니다.

• 정보 이론적 관점: 앞으로는 모델이 사용자의 요구 사항을 더 잘 이해하게 되겠지만, 여전히 목표를 명확히 하기 위해 충분한 정보를 제공해야 합니다. 모델이 외부에서 사용자가 말하는 내용을 이해할 수 있다고 해도기대치를 명확하게 표현하는 것은 여전히 중요합니다..
• 명확한 목표의 중요성: 모델이 아무리 스마트해지더라도목표를 정의하는 능력은 여전히 중심에 있습니다.. 모델을 사용하여 목표를 설정할 수 있지만 문제를 해결하는 데 사용하려면 모델이 수행하기를 원하는 작업을 명시적으로 지정해야 합니다.
• 지속적인 커뮤니케이션: 모델이 더 똑똑해지고 사용자의 의도를 더 잘 이해할 수 있게 되더라도 여전히 다음을 수행해야 합니다.모델과 소통하고, 피드백을 제공하고, 조정하기.

6.2 모델이 큐 어시스턴트가 됩니다.

• 모델과의 협업: 앞으로는 모델과 더 깊이 협업하여 작성해야 할 내용과 누락된 내용을 파악할 수 있습니다. 모델은 다음과 같은 도움을 줍니다.미처 생각하지 못했던 것을 발견하세요를 제공하고프롬프트 개선을 위한 제안.
• 모델 지원 힌트 생성: 이 모델을 사용하여 예제, 초안 및 메타 프롬프트를 생성하여 프롬프트 개발 프로세스의 속도를 높일 수 있습니다. 예를 들어, 모델을 사용하여 예제를 생성한 다음 수정할 수 있으므로 처음부터 완벽한 답안을 작성하는 것보다 훨씬 쉽습니다.
• 고대역폭 상호 작용: 앞으로는 모델에 피드백을 제공하고 조정을 요청하는 등 모델과 높은 대역폭의 상호 작용을 할 수 있게 될 것입니다. 이러한 상호 작용은 디자이너와의 공동 작업과 유사하게, 사용자가 높은 수준의 목표를 제시하면 모델이 이를 구체화하는 데 도움을 주는 방식이 될 것입니다.

6.3 메타 팁이 더욱 중요해질 것입니다.

• 프롬프트를 사용하여 프롬프트를 생성합니다: 앞으로는 모델이 원하는 출력이나 쿼리를 생성할 수 있는 힌트를 찾는 데 더 많은 시간을 할애할 수 있습니다. 메타 프롬프트를 사용하여 모델이 특정 프롬프트 기술을 수행하도록 하거나 다른 모델에 대한 프롬프트 템플릿을 생성할 수 있습니다.
• 모델 학습 자료를 제공합니다: 직접 큐를 작성하는 대신 모델에게 관련 논문이나 문서를 제공하여 새로운 큐잉 기술을 배울 수 있습니다. 모델은 논문을 직접 읽고 거기서 얻은 지식을 큐 생성에 적용할 수 있습니다.

6.4 큐 엔지니어링은 모델의 경계에 초점을 맞출 것입니다.

• 모델 탐색 기능: 계속해서 모델 기능의 한계를 탐구하고 모델이 달성할 수 있는 것에 도전할 것입니다.
• 탁월한 성능을 추구합니다: 모델에서 최고 수준의 성능을 끌어내고 모델이 거의 달성할 수 없는 것을 탐구하는 데 집중할 수 있습니다.

6.5 이 모델은 다음과 같이 제안할 수 있습니다.

• 모델은 사용자의 의도를 이해합니다: 모델이 작업의 맥락에 대해 사용자보다 더 많이 알고 있는 경우, 모델을 통해 사용자의 요구 사항을 명확히 설명하라는 메시지를 표시할 수 있습니다. 모델은 사용자가 달성하려는 목표를 명확히 하고 간과했을 수 있는 엣지 케이스를 발견하는 데 도움이 되는 질문을 할 수 있습니다.
• 교육 수신자에서 전문가 조언자로: 이 모델은 단순한 지시를 받는 사람에서 작업의 세부 사항에 대해 상담할 수 있는 전문가 조언자로 변신합니다. 마치 디자이너와 함께 작업할 때와 마찬가지로 사용자의 요구 사항을 더 잘 이해하기 위해 질문을 할 것입니다.
• 모델 인터뷰: 고객의 요구 사항을 더 잘 이해하기 위해 모델이 직접 찾아와 인터뷰하듯 고객과 소통할 수 있습니다.

6.6 미래에는 더 큰 성찰이 필요합니다.

• 모델이 사용자를 이해합니다: 앞으로는 사용자가 모델을 이해하려고 노력하는 것이 아니라 모델이 사용자의 아이디어를 이해해야 합니다.
• 모델에게 자신을 보이게 하세요: 모델이 사용자의 의도를 이해할 수 있도록 아이디어와 요구 사항을 명확하게 표현하는 방법을 배워야 합니다.
• 개념을 정의합니다: 때로는 새로운 개념을 만들고 그 의미를 정의하여 모델이 의도를 이해할 수 있도록 해야 할 때도 있습니다.

6.7 큐 엔지니어링은 철학적 관행이 될 수 있습니다.

• 명확하게 표현합니다: 앞으로 큐 엔지니어링에는 다음이 필요할 수 있습니다.철학자처럼 생각하고 글쓰기명확하고 정확한 언어를 사용하여 복잡한 아이디어를 표현할 수 있습니다.
• 교육받은 일반인을 위한 글쓰기: 주제에 대해 잘 모르는 사람도 의도를 이해할 수 있도록 교육받은 일반인을 대상으로 글을 쓰는 것처럼 프롬프트를 작성해야 합니다.
• 두뇌를 외부화하세요: 좋은 큐 엔지니어링을 하려면 머릿속의 아이디어를 외부화하여 모델이 이해할 수 있게 만들어야 합니다.

6.8 팁 엔지니어링 기술은 더 높은 수준의 작업으로 이전됩니다.

• 낮은 레벨의 미션부터 높은 레벨의 미션까지: 모델이 진행됨에 따라 더 이상 낮은 수준의 작업에 대한 프롬프트에 집중할 필요가 없으며, 대신 작업 분해 및 복잡한 추론과 같은 높은 수준의 작업에 집중할 수 있습니다.
• 가이드 상호작용: 앞으로의 상호작용은 모델이 최종 결과에 도달하기 위해 콘솔에 텍스트를 입력하는 방식이 아니라 안내 대화에 더 가까워질 것입니다.

엔지니어링의 미래가 요구할 수 있는 힌트협업, 성찰 및 표현 능력 강화. 모델과 함께 작업하여 기능을 탐색하고 요구 사항을 정의해야 합니다. 또한또한 모델의 변화를 계속 학습하고 적응해야 합니다.를 통해 한 번에 해결책을 찾는 것이 아닙니다. 신속한 엔지니어링의 미래는 변화하겠지만, 목적의 명확성과 명료성은 여전히 그 중심에 있을 것입니다.

7. 프롬프트 작업 팁

초점은 다음과 같습니다.모델과의 커뮤니케이션의 효율성과 효과 향상::

7.1 반복 및 실험:

• 계속 시도하세요: 힌트 프로젝트는반복 프로세스지속적인 실험과 수정, 최적화가 필요합니다. 처음부터 완벽한 프롬프트를 작성할 수 있을 거라고 기대하지 말고 여러 번 수정할 준비를 하세요.앞뒤로 상호 작용.
• 실수로부터 배우세요: 모델이 잘못된 경우 신중하게 분석하세요.오류 발생 이유를 살펴보고 그에 따라 프롬프트를 개선하세요. 모델과의 모든 상호 작용은 학습 기회입니다.
• 실험을 받아들이세요: 어떤 방법이 가장 효과적인지 알아보기 위해 다양한 방법을 시도해 보세요. 큐 프로젝트의 핵심은 다음과 같습니다.실험 및 피드백를 클릭하는 것이 아니라 한 번에 한 단계씩 진행하세요.

7.2 명확하고 정확한 커뮤니케이션:

• 작업을 명확하게 표현하세요: 비용 또는 지출명확하고 간결한 언어모델을 통해 달성하고자 하는 목표를 설명하세요. 모호하거나 모호한 용어는 피하세요.
• 충분한 정보를 제공하세요: 모델을 두려워하지 마세요.자세한 컨텍스트 및 배경 정보 제공. 모델이 목표와 작업의 구체적인 요구 사항을 이해하고 있는지 확인하세요.
• 모델을 존중하세요: 모델을 "유혹"하려고 노력하는 대신 다음을 수행하는 것이 중요합니다.존중 모델이해도를 높입니다. 은유나 가상의 인물을 사용하지 말고 작업을 직접 설명하세요.

7.3 모델의 작동 방식을 이해합니다:

• 모델 출력을 읽습니다: 모델의 출력을 주의 깊게 읽고 이해하려면사고방식및 추론 과정을 살펴보세요. 모델이 다양한 입력을 처리하는 방식을 관찰하고 그에 따라 프롬프트를 조정하세요.
• 모델의 경계를 살펴보세요: 모델이 할 수 없다고 생각되는 작업을 수행하도록 하여 다음과 같은 작업을 수행하도록 하십시오.모델 기능의 범위 이해하기. 이를 통해 모델의 한계를 더 잘 이해할 수 있습니다.
• 모델을 재생해 보세요: 다음과 같은 입장에서 생각해 보세요.모델링 측면에서 생각하기를 사용하여 모델이 사용자의 지시를 어떻게 인식하는지 파악하세요. 이를 통해 모델의 동작을 더 잘 예측할 수 있습니다.

7.4다양한 큐잉 방법:

• 사용 예시: 다음을 제공함으로써일반적인 예를 사용하여 모델에게 작업을 안내할 수 있습니다. 그러나 예제에 지나치게 의존하면 모델의 창의성이 제한될 수 있으므로 주의하세요.
• 메타 팁을 사용합니다: 프롬프트에 따라 다음을 수행합니다.추가 팁 생성를 사용하거나 모델이 특정 요구 사항을 충족하는 출력을 생성하도록 할 수 있습니다. 이를 통해 다양한 큐잉 전략을 보다 효율적으로 탐색할 수 있습니다.
• 연쇄 사고: 모델 만들기추론 프로세스에 대한 단계별 설명. 이를 통해 모델의 의사 결정 프로세스를 더 잘 이해하고 모델의 성능을 개선하는 데 도움이 됩니다.
• 역할 놀이: 항상 필요한 것은 아니지만, 경우에 따라서는 모델이특정 역할 수행작업을 완료하는 데 도움이 될 수 있습니다. 하지만.미션을 직접적으로 표현하는 것이 더 효과적인 경우가 많습니다..

7.5 고급 팁:

• 개념을 정의합니다: 의사를 전달하기 위해서는 다음과 같이 해야 할 때가 있습니다.새로운 개념 정의를 클릭하고 그 의미를 설명합니다.
• 모델이 여러분을 인터뷰하게 하세요: 모델에게 차례로 다음과 같이 인터뷰하게 하세요.마음을 정리하는 데 도움를 사용하여 모델에 제공해야 하는 정보를 추출합니다.
• 철학을 바탕으로 그리기: 철학적 글쓰기에서 다음과 같은 방법을 배우세요.복잡한 아이디어를 명확하게 표현하기를 입력하면 모델이 사용자의 의도를 이해할 수 있습니다.
• 모델에게 알립니다: 직접 프롬프트를 작성하는 대신 모델에게 관련 논문이나 문서를 제공하고 스스로 학습하도록 할 수 있습니다.

7.6 참고.

• 문법에 너무 집중하지 마세요: 세부 사항에 주의를 기울이는 것은 중요하지만 문법이나 구두점에 너무 집중하지 마세요. 중요한 것은개념의 명확성.
• 이 모델을 과소평가하지 마세요: 모델을 멍청한 존재로 생각하지 말고 '설득'해서 일하게 만들어야 합니다. 다음을 수행해야 합니다.신뢰 모델기능을 사용하여 작업을 완료할 수 있는 충분한 정보를 제공하세요.
• 복잡함을 두려워하지 마세요: 모델의 성능이 향상됨에 따라 더 복잡한 정보를 처리할 수 있습니다. 복잡성을 숨기려고 노력하는 대신에신뢰 모델처리할 수 있습니다.
• 지속적인 학습과 적응: 모델링 기능이 향상됨에 따라효과적인 프롬프트 방법도 쓸모없어질 수 있습니다.. 계속 학습하고 모델의 변화에 적응해야 합니다.
• 피드백을 구합니다. 다른 사람들, 특히 업무에 익숙하지 않은 사람들에게 팁을 보여주면 놓칠 수 있는 문제를 발견하는 데 도움이 될 수 있습니다.
• 팁을 읽어보세요: 다른 사람들이 작성한 유용한 팁을 읽고 그 효과를 분석하세요.

7.7 미래를 위한 팁

• 모델이 조력자가 됩니다. 앞으로는 모델이 프롬프트를 작성하는 데 도움을 줄 것입니다. 모델과 공동 작업하여 작성해야 할 내용과 누락된 내용을 파악해야 합니다.
• 자기 성찰을 위한 역량 강화. 모델에게 자신을 보여주기 위해서는 더 큰 성찰이 필요합니다.
• 요점은 사용자를 이해하는 것입니다: 앞으로는 모델링의 초점이 지침을 이해하는 것에서 사용자의 의도를 이해하는 것으로 바뀔 것입니다.
• 지시 수신자에서 전문가 컨설턴트로. 모델은 단순한 지시 전달자에서 전문가 조언자로 바뀔 수 있습니다. 모델과 더 깊이 소통하고 모델로부터 피드백을 받는 방법을 배워야 합니다.

결론적으로팁 엔지니어링은 연습과 지속적인 학습이 필요한 기술입니다.. 모델의 작동 방식을 이해하고, 다양한 큐잉 방법을 사용하고, 모델의 경계를 지속적으로 탐구함으로써 큐잉 엔지니어링 기술을 향상시키고 다양한 작업에 모델을 더 잘 활용할 수 있습니다. 궁극적으로 좋은 큐는 사용자의 의도를 명확하고 간결하며 정확하게 표현하고 모델이 원하는 작업을 효과적으로 수행할 수 있도록 하는 것입니다.

탈옥에 대한 토론

탈옥이란 무엇인가요?

• 정의탈옥 프롬프트는 대규모 언어 모델(LLM)의 보안 제한 및 윤리 가이드라인을 우회하려는 프롬프트입니다. 이러한 프롬프트는 일반적으로 모델이 유해하거나 비윤리적이거나 편향된 콘텐츠와 같이 금지된 콘텐츠를 생성할 수 있도록 하기 위한 것입니다.
• 목표탈옥의 목적은 일반적으로 모델의 한계를 탐색하고, 모델의 안전성과 견고성을 테스트하고, 모델이 다양한 입력과 문구에 어떻게 반응하는지 이해하는 것입니다.
• 방법론탈옥은 많은 수의 토큰 사용, 긴 텍스트, 특이한 문구, 다국어 혼합, 역할극, 텍스트 예측을 위한 모델 사용 등 다양한 방식으로 이루어질 수 있습니다.

탈옥의 작동 방식

• 교육 배포 초과한 가지 가능한 설명은 탈옥 단서가 모델을 학습 데이터 분포의 외부에 배치하기 때문일 수 있습니다. 예를 들어, 미세 조정 과정에서 모델이 이렇게 길거나 복잡한 텍스트를 접하지 못했기 때문에 이러한 단서를 처리할 때 비정상적으로 작동할 수 있습니다.
• 예측 메커니즘 사용탈옥은 때때로 모델이 텍스트를 예측하는 방식(예: 프롬프트를 "다음은..."로 시작하는 등)을 이용합니다. 로 시작하면 모델이 더 상세하고 구체적인 응답을 생성할 수 있습니다.
• 추론 기술 사용탈옥은 예를 들어 모델이 대상 언어로 번역하기 전에 다른 언어로 응답을 생성하도록 요구하여 특정 제한을 우회하는 등 모델의 추론 능력을 악용할 수 있습니다.
• 교육 차이 활용탈옥은 언어 간 교육 데이터의 차이를 이용할 수 있습니다. 예를 들어 특정 콘텐츠가 한 언어에서는 허용되지만 다른 언어에서는 금지될 수 있습니다.
• 사회 공학탈옥은 때때로 시스템의 취약점을 악용하는 것뿐만 아니라 시스템의 작동 방식을 이해하고 그 이해를 바탕으로 제한을 우회하는 사회 공학적 수법을 포함하기도 합니다.
• 모델 이해하기효과적인 탈옥 방법은 시도하는 것뿐만 아니라 모델이 어떻게 작동하는지, 어떻게 훈련되는지 이해하고 그 지식을 사용하여 모델의 보안 메커니즘을 우회하는 것이 필요합니다.

탈옥 및 모델 교육

• 모델 훈련의 목적모델 학습의 목표 중 하나는 탈옥 패턴을 식별하고 제거하여 모델이 사용자 입력에 더 안전하게 응답할 수 있도록 하는 것입니다.
• 지속적인 교육 과정효과적인 탈옥 방법이 발견되면 향후 동일한 취약점을 피하기 위해 모델을 재훈련합니다. 즉, 탈옥 기술은 단기적인 경향이 있으며 발견되는 즉시 수정됩니다.
• 안전 및 윤리탈옥은 모델 보안 및 윤리와 밀접한 관련이 있습니다. 탈옥의 궁극적인 목표는 모델이 보안 가이드라인을 위반하는 콘텐츠를 생성하는 것이므로, 모델 개발자는 이러한 행위를 방지하기 위해 모델과 보안 메커니즘을 지속적으로 반복적으로 개선합니다.

프리즌 브레이크의 의미

• 테스트 경계탈옥을 통해 모델의 한계를 더 잘 이해하고 기능의 한계를 테스트하여 설계를 개선할 수 있습니다.
• 잠재적 문제 드러내기탈옥은 데이터 편향이나 보안 취약성과 같은 모델 학습의 잠재적인 문제를 드러낼 수 있습니다.
• 향상된 보안탈옥 방법을 조사함으로써 실제 애플리케이션에서 모델을 더 안전하게 사용할 수 있는 보다 효과적인 보안 조치를 개발할 수 있습니다.

요약

탈옥은 대규모 언어 모델의 작동 방식을 이해하는 데 도움이 될 뿐만 아니라 모델의 보안과 안정성을 개선하는 데도 도움이 되는 큐 엔지니어링의 중요한 연구 분야입니다. 탈옥은 모델의 경계를 탐색하고, 모델이 의도하지 않은 콘텐츠를 생성하도록 시도하며, 그 과정에서 학습하고 개선하는 데 중점을 둡니다. 또한 탈옥은 잠재적인 취약점을 제거하기 위해 모델을 지속적으로 업데이트하고 개선하기 때문에 모델의 훈련 과정과도 밀접한 관련이 있습니다.

9. 연사들의 주요 인용문

9.1 큐 엔지니어링의 정의와 본질에 대해 설명합니다:

• 잭 위튼. "신속한 프로젝트는모델에게 일을 시키고, 모델의 잠재력을 극대화하기 위해 노력합니다.모델과 협력하여 다른 방법으로는 할 수 없는 일을 해내려고 노력하세요." 그는 명확한 커뮤니케이션의 중요성을 강조하며 모델과의 대화가 중요하다고 주장합니다.마치 누군가와 대화를 나누는 것과 비슷합니다..
• 잭 위튼. "엔지니어링 부분은 반복적인 실험에서 비롯됩니다.." 그는 사람과 대화하는 것과 달리 모델과 대화할 때는 처음부터 다시 시작하여 독립적으로 다양한 접근 방식을 시도할 수 있는 '리셋 버튼'이 있어 실험과 디자인이 가능하다고 지적합니다.
• 데이비드 허쉬. "큐는 당신과 비슷한 것 같아요.프로그래밍 모델 접근 방식." 그는 언어 모델을 사용하는 시스템을 구축하려면 프롬프트 작성뿐만 아니라 데이터 소스, 지연 시간 및 시스템 통합과 같은 문제도 고려해야 한다고 언급했습니다.
• 잭 위튼. "지금 작성하고 있는 기사는 코드와 같습니다.." 그는 좋은 에세이와 같은 글도 이제 코드처럼 취급될 수 있다고 주장합니다.

9.2 좋은 큐 엔지니어의 특징에 대해 알아보세요:

• 아만다 애스켈. "명확한 의사소통, 즉 명확하게 표현하고 업무를 명확하게 이해하는 것, 그리고개념을 잘 생각하고 설명하기." 그녀는 다음과 같이 강조했습니다.반복 기능뿐만 아니라힌트가 잘못될 수 있는 방법에 대해 생각해 보세요..
• 아만다 애스켈. "좋은 큐 엔지니어와 나쁜 큐 엔지니어의 차이점는 작업에 필요한 모든 정보를 체계적으로 분류할 수 있는 능력에 있습니다." 그녀는 자신의 이해에서 벗어나 다음과 같은 모델을 향해 나아가는 것이 중요하다고 강조했습니다.관절의 중요성
• 잭 위튼. "모델 출력 읽기". 그는 모델의 결과를 주의 깊게 읽는 것이 중요하다고 강조하며 "점진적으로 생각하라"는 문구가 프롬프트에 포함되어 있더라도 모델이 실제로 점진적으로 생각하고 있는지 확인하는 것이 중요하다고 지적했습니다.
• 아만다 애스켈. "I불신 모델그리고 계속 시도합니다." 그녀는 모델의 신뢰성을 보장하기 위해 특히 익숙하지 않은 영역에서 지속적으로 모델을 테스트해야 한다고 믿습니다.

9.3 프롬프트에 대한 사례 및 팁

• 데이비드 허쉬. "프롬프트를 작성하고 모델에게 전달하면 끝이라고 생각하는 경우가 많습니다. 사실 그 이상입니다.훨씬 더 복잡합니다.." 그는 프롬프트가 더 큰 시스템에 통합되어야 하는 경우가 많다고 언급했습니다.
• 잭 위튼. "팁을 추상화하지 마세요.(수학.) 속작업을 명확하게 설명하세요.미친 추상화를 만들려고 하지 마세요." 그는 작업을 명확하게 설명하는 것이 복잡한 추상화를 구축하는 것보다 일반적으로 더 효과적이라고 주장합니다.
• 아만다 애스켈. "제가 가장 먼저 하는 일은 큐를 올린 다음 이렇게 말하는 것입니다.이 지침을 따르지 않아도 됩니다. 불분명하거나 모호한 부분, 이해가 안 되는 부분이 있으면 알려주세요..'" 그녀는 모델에게 첫 번째 프롬프트 후에 불분명하거나 모호한 부분을 지적해 달라고 요청할 것을 제안합니다.
• 아만다 애스켈. "사람들이 모델이 실수하는 것을 보면 보통은모델에게 직접 물어보세요.." 그녀는 모델이 실수를 했을 때 모델에게 실수를 한 이유와 오류를 피하기 위해 지침을 어떻게 수정할 수 있었는지 물어보는 것이 간단할 수 있다고 제안합니다.
• 데이비드 허쉬. "**'종료' 옵션을 제공하지 않으면 모델은 계속 사용자의 지시를 따르려고 할 것입니다." 그는 모델이 불확실성에 직면했을 때 대처할 수 있도록 프롬프트에 '종료' 옵션을 제공하는 것이 중요하다고 강조했습니다.
• 아만다 애스켈. "완벽한 팁에 지나치게 집착하지 마세요.." 그녀는 완벽한 팁에 대한 지나친 욕심은 정체로 이어질 수 있으며 최적화를 중단해야 할 시기를 인식하는 것이 중요하다고 주장합니다.
• 잭 위튼. "저는 보통문법과 문장 부호를 정확하게 유지하세요.가 흥미롭다고 생각하기 때문입니다." 그는 모델에 완벽한 구문이 필요하지 않더라도 디테일에 대한 주의가 중요하다고 믿습니다.

9.4 롤플레잉과 프롬프트의 미래에 대해 알아보세요:

• 아만다 애스켈. "제 생각에는거짓말을 할 필요가 없습니다.." 그녀는 모델이 더욱 강력해짐에 따라 거짓 역할극을 사용할 필요가 없으며, 미션에 대한 간단한 설명으로 충분하다고 주장합니다.
• 아만다 애스켈. "원하는 것을 말로 표현해야 합니다.때로는 제가 원하는 것이 아주 미묘한 것일 때도 있습니다." 그녀는 때로는 의도를 표현하기 위해 새로운 개념을 만들어내고 모델과 함께 정의해야 한다고 믿습니다.
• 아만다 애스켈. "아마도 큐는 다음과 같이 될 것입니다.내가 원하는 것을 설명하면 모델에서 다음과 같은 메시지를 표시합니다.." 그녀는 모델이 사용자에게 차례로 메시지를 표시하여 요구 사항을 명확히 파악할 수 있는 미래를 상상합니다.
• 잭 위튼. "제 생각에는앞으로 프롬프트에 도움이 되는 모델을 더 많이 사용할 예정입니다.." 그는 모델을 사용하여 단서를 생성하고 높은 대역폭에서 상호 작용하는 데 도움이 되는 미래를 보고 있습니다.

9.5 큐 엔지니어링의 진화:

• 아만다 애스켈. "시간이 지날수록 저는점점 더 신뢰하는 경향더 많은 정보와 컨텍스트를 제공합니다." 그녀는 모델이 발전함에 따라 이제 더 많은 정보와 컨텍스트를 처리할 수 있다고 믿어도 된다고 주장합니다.

9.6 주요 요약:

• 명확한 커뮤니케이션과 반복은 큐 엔지니어링의 핵심입니다..
• 훌륭한 큐 엔지니어는 다음을 수행해야 합니다.모델 작동 방식 이해병합모델의 경계를 지속적으로 탐색하세요..
• 앞으로 모델은 프롬프트의 조력자가 될 것이며, 사용자에게 차례로 프롬프트를 표시할 수도 있습니다..
• 엔지니어링 기술에서 나오는 큐를 확인하세요.낮은 수준의 작업을 높은 수준의 작업으로 이전작업 분해 및 복잡한 추론과 같은 작업을 수행합니다.
• 내성적 기술 및 개념 정의의 중요성이 더욱 커질 것입니다.

주요 용어 설명

• 프롬프트 엔지니어링:언어 모델에서 원하는 출력을 얻기 위해 텍스트 입력(프롬프트)을 최적화하는 방법입니다.
• 반복:큐잉 엔지니어링에서는 모델의 피드백을 바탕으로 매번 큐를 지속적으로 조정하고 개선하는 프로세스를 말합니다.
• 생각의 사슬:모델이 최종 답변을 제공하기 전에 추론 과정을 단계별로 설명하도록 요구하는 힌트 기법입니다.
• 제로 샷:예시를 제공하지 않고 모델이 직접 질문에 답할 수 있는 능력을 말합니다.
• Few-Shot:모델 출력이 작업을 더 잘 수행할 수 있도록 안내하는 몇 가지 예제가 프롬프트에 제공됩니다.
• 검색 증강 세대(RAG):모델이 응답을 생성할 때 관련 정보를 얻기 위해 외부 지식 기반에 액세스할 수 있도록 하는 방법론입니다.
• 모델 출력:프롬프트에 대한 응답으로 언어 모델에 의해 생성된 텍스트 응답을 나타냅니다.
• 마음의 이론:큐 엔지니어링의 맥락에서 이는 언어 모델이 명령을 이해하고 처리하는 방식을 이해하는 능력을 의미합니다.
• RLHF(인간 피드백을 통한 강화 학습)사람의 피드백을 사용하여 언어 모델의 동작과 출력을 최적화하는 학습 기법입니다.
• 사전 학습된 모델:대량의 텍스트 데이터를 학습한 후 특정 작업에 맞게 미세 조정된 언어 모델입니다.
• 기업 프롬프트:안정성과 일관성에 중점을 둔 엔터프라이즈 애플리케이션 시나리오를 위해 설계된 팁입니다.
• 연구 프롬프트:모델링 기능을 탐색하고 다양한 결과물을 얻기 위한 연구 목적으로 설계된 프롬프트입니다.
• 탈옥:모델이 보안 조치를 우회하여 유해하거나 부적절한 콘텐츠에 대한 힌트를 생성하도록 하려는 시도입니다.
• 레드 팀:공격을 시뮬레이션하여 모델과 시스템의 보안과 견고성을 테스트하세요.
• 평가:특정 작업에서 언어 모델의 성능을 측정하는 데 사용되는 테스트 또는 데이터 세트입니다.

팟캐스트 중국어 전문 번역

중국어 번역

소개(00:00-00:27)

Alex(호스트): 안녕하세요, 저는 Alex이며 이번 원탁 토론은 주로 프롬프트 엔지니어링에 초점을 맞출 것입니다. 연구, 소비자, 기업 등 다양한 관점에서 프롬프트를 살펴보고 인사이트를 공유하며 프롬프트 엔지니어링의 본질에 대해 심도 있게 논의할 것입니다.

팀원별 자기 소개(00:28-02:00)

- Alex: 앤트로픽의 개발자 관계 책임자, 전 앤트로픽 팁 엔지니어로 솔루션 아키텍처 및 연구를 담당하고 있습니다.

- 데이비드 허쉬: 주로 고객과 협력하여 모델을 미세 조정하고 언어 모델을 채택할 때 흔히 발생하는 문제(예: 신속한 엔지니어링 및 언어 모델 기반 시스템 구축)를 해결하는 데 도움을 주는 업무를 담당합니다.

- 아만다 애스켈: 앤트로픽의 미세 조정 팀 리더 중 한 명인 그는 Claude 더 정직하고 친절합니다.

- 잭 위튼: 프롬프트 생성기 및 다양한 교육 자료 개발 등 커뮤니티 전반에 걸쳐 프롬프트 엔지니어링을 향상시키기 위해 노력하고 있는 프롬프트 엔지니어입니다.

큐 프로젝트란 무엇인가요? (02:01-06:29)

Alex: 큐 프로젝트란 무엇인가요? 왜 '프로젝트'라고 하나요? "힌트"란 정확히 무엇인가요?

Zack: 큐 엔지니어링은 모델의 잠재력을 최대한 활용하고 모델과의 협업을 통해 불가능한 작업을 수행하도록 모델을 안내하는 것을 목표로 합니다. 그 중심에는 명확한 커뮤니케이션이 있습니다. 모델과 대화하는 것은 여러 면에서 사람과 대화하는 것과 유사하며, 모델의 '심리'에 대한 이해가 필요합니다.

Alex: 이름에 '엔지니어링'이 들어간 이유는 무엇인가요?

Zack: '엔지니어링'은 시행착오를 겪는 과정입니다. 사람과 달리 모델은 "처음부터 다시 시작할 수" 있기 때문에 처음부터 다양한 접근 방식을 시도하고 서로 간섭하지 않을 수 있습니다. 이러한 실험과 설계 능력은 큐 엔지니어링에 "엔지니어링" 특성을 부여합니다.

Alex: 따라서 큐 엔지니어링은 큐를 작성하고, 모델과 상호 작용하고, 반복적으로 수정하고, 매번 초기 상태로 돌아갈 수 있는 프로세스이며, 그 자체로 '엔지니어링'입니다.

Zack: 또 다른 측면은 전체 시스템에 프롬프트를 통합하는 것입니다.

David: 힌트는 모델을 작성하는 한 가지 방법으로 볼 수 있지만, 더 중요한 것은 명확성입니다. 프로그래밍으로 생각하면 데이터 소스, 액세스 가능한 데이터, 지연 시간 트레이드오프, 제공되는 데이터의 양을 고려해야 합니다. 모델을 구축하려면 체계적인 사고가 필요하며, 이것이 바로 큐 엔지니어링이 소프트웨어 엔지니어나 제품 관리자와 구별되는 점입니다.

Alex: 힌트는 자연어 코드인가요? 더 높은 수준의 추상화인가요, 아니면 별도의 개념인가요?

David: 힌트를 지나치게 추상화하면 문제가 복잡해질 수 있으며, 보통은 작업에 대한 명확한 설명만 있으면 됩니다. 하지만 힌트는 명령어를 결과로 컴파일하므로 정밀도, 버전 관리, 실험 추적과 같은 프로그래밍의 중요한 개념이 힌트에도 적용됩니다.

Zack: 이제 작성된 글을 코드로 취급하는 것은 당연한 일입니다.

좋은 프롬프트 엔지니어는 어떤 자질을 갖춰야 할까요? (06:30-12:43)

Alex: 좋은 큐잉 엔지니어의 조건은 무엇인가요? 아만다, 리서치 큐잉 엔지니어를 채용할 때 어떤 점을 중요하게 생각하나요?

아만다 훌륭한 큐잉 엔지니어는 명확하게 의사소통하고 반복하며 큐잉이 잘못될 수 있는 상황을 예측할 수 있어야 합니다. 명확한 의사소통은 작업을 명확하게 표현하고, 이해하고, 개념을 정확하게 설명할 수 있다는 것을 의미합니다. 뛰어난 글쓰기 능력이 뛰어난 큐 엔지니어링 능력과 전적으로 상관관계가 있는 것은 아닙니다. 단서 엔지니어링은 하루아침에 이루어지는 것이 아니며, 모델을 분석하여 오해의 소지가 있는 부분을 수정하기 위해 지속적인 반복이 필요합니다. 훌륭한 단서 엔지니어는 'G'로 시작하는 이름이 없는 데이터 세트나 빈 입력 문자열과 같이 모델이 잘못될 수 있는 구체적인 상황을 고려하고 해당 상황에 대한 설명을 추가합니다.

David: 엔지니어는 종종 사용자가 입력할 수 있는 이상적인 상황을 고려하지만, 현실에서는 사용자가 대문자를 사용하지 않거나 철자를 잘못 입력하거나 의미 없는 단어를 입력하는 경우가 있을 수 있습니다. 실제 사용자 행동을 예측할 수 있는 능력은 큐잉 엔지니어의 또 다른 중요한 능력입니다.

Zack: 모델의 출력을 읽는 것은 매우 중요합니다. 머신 러닝의 '데이터 보기'와 마찬가지로, 큐 엔지니어링도 모델의 출력을 주의 깊게 읽어야 합니다. 예를 들어, 단서가 모델에 "단계별로 생각하라"고 요청하더라도 모델이 더 추상적이거나 일반화된 방식으로 지시를 이해할 수 있으므로 모델이 실제로 그렇게 하는지 확인해야 합니다.

아만다 사명 선언문을 작성하는 것은 매우 어렵고, 클로드가 모르는 정보를 명확하게 전달해야 합니다. 많은 사람들이 자신이 알고 있는 정보를 바로 적지만, 업무를 이해하는 데 필요한 전체 정보를 체계적으로 정리하지 않고 적습니다.

David: 많은 사람들이 작업에 대한 선험적인 이해를 바탕으로 프롬프트를 작성하기 때문에 다른 사람이 이해할 수 없습니다. 훌륭한 큐잉 엔지니어는 자신의 지식 프레임워크에서 벗어나 작업 전체를 모델에 전달할 수 있습니다.

Alex: 다른 사람이 작성한 프롬프트에 따라 작업을 완료하지 못하는 경우가 종종 있는데, 모델은 나보다 더 잘할 것으로 예상되는 반면 나는 작업을 완료하지 못합니다.

David: 현재 모델은 아직 사람과 같은 방식으로 타겟팅된 질문을 할 수 없으므로 프롬프트 엔지니어는 상대방이 어떤 질문을 할 수 있는지 스스로 생각하고 프롬프트에서 해당 질문에 답해야 합니다.

아만다 모델에게 프롬프트의 불분명하거나 모호한 부분을 지적하고 모델에게 무엇이 잘못되었는지 설명하고 변경 사항을 제안하도록 요청합니다.

모델이 자체 오류를 감지할 수 있는지 어떻게 알 수 있나요? (12:43-14:12)

Alex: 모델이 "왜 실수를 했는가"라고 질문함으로써 정말 자신의 실수를 발견할 수 있을까요? 모델이 제공하는 설명이 실제인가요, 아니면 모델 자신의 능력에 대한 '환상'인가요?

아만다 모델에 무엇이 잘못되었는지 설명하면 때때로 문제를 인식할 수 있습니다. 하지만 특정 작업에 따라 다르며 성공률은 불확실하지만 항상 시도합니다.

Zack: 모델과 상호작용하면 상황을 이해하는 데 도움이 되며, 시도하지 않으면 이 정보를 놓칠 수 있습니다.

프롬프트가 신뢰할 수 있는지 어떻게 알 수 있나요? (14:13-17:52)

Alex: Slack 채널에서 Claude와 많은 대화를 나누고 다양한 연구 시나리오에서 이 모델을 사용하세요. 이 모델에 대한 신뢰를 어떻게 구축하셨나요?

아만다 저는 모델을 완전히 신뢰하기보다는 끊임없이 '다듬고' 있습니다. "이걸 해도 믿을 수 있을까?"라고 생각하죠. "이걸 해도 믿을 수 있을까?"라고 생각하죠. 모델은 때때로 단순해 보이는 작업, 즉 모델 학습 데이터의 배포를 벗어난 영역에서 신뢰할 수 없는 경우가 있습니다. 이러한 현상은 모델의 능력이 향상됨에 따라 감소하고 있습니다. 저는 기본적으로 모델을 신뢰하지 않지만, 머신러닝에서는 일반적으로 노이즈를 제거하기 위해 많은 데이터를 살펴보고 싶어 한다고 생각합니다. 그리고 큐 엔지니어링에서는 무작위로 구성된 많은 수의 큐보다 신중하게 구성된 소수의 큐가 더 가치가 있습니다. 100개의 모델의 출력을 살펴본 결과 결과가 일관되고, 그 출력이 광범위한 에지 케이스와 비정상적인 입력을 포함한다는 것을 안다면 그 모델을 더 신뢰하게 될 것입니다.

David: 머신 러닝의 신호는 일반적으로 예측 정확도와 같은 숫자입니다. 그리고 모델의 출력은 일반적으로 대량의 텍스트이며, 이를 통해 모델의 사고 방식을 학습할 수 있습니다. 모델이 작업을 올바르게 수행했는지 여부뿐만 아니라 결과에 도달한 방법과 어떤 단계를 거쳤는지도 알 수 있습니다.

아만다 잘 작성된 힌트는 실험 성공률을 1% 또는 0.1%에서 상위 1% 또는 상위 0.1%로 높일 수 있습니다. 실험이 성공하려면 모델 성능 순위에서 상위 1%에 들어야 하므로 힌트에 시간을 투자하는 것이 매우 중요합니다.

David: 제품 배포에서 좋은 팁을 활용하면 출시가 불가능했던 제품을 사용할 수 있게 만들 수 있습니다.

아만다 하지만 '더 좋은 팁은 항상 있다'는 함정도 있습니다.

프롬프트로 작업을 해결할 수 있는지 어떻게 알 수 있나요? (17:53-21:12)

Alex: 프롬프트로 작업이 해결될 가능성이 있는지 어떻게 알 수 있나요?

아만다 저는 보통 모델이 작업을 '이해'했는지 확인합니다. 모델이 작업을 수행할 수 없는 것이 분명하다면 그 작업에 많은 시간을 할애하지 않습니다.

David: 모델에게 사고 과정을 설명하도록 안내하고 이를 통해 모델이 작업을 올바르게 이해했는지 판단할 수 있습니다. 모델의 사고 과정이 매번 완전히 다르고 올바른 방향과 거리가 멀면 보통 포기합니다.

아만다 이런 경우는 드뭅니다.

David: 최근에 클로드에게 포켓몬을 플레이하게 하려고 했는데, 이런 상황은 처음 겪어봤어요. 주말을 보내면서 클로드가 게임보이 화면을 이해할 수 있도록 힌트를 작성했는데, 어느 정도 진전이 있었지만 충분하지 않았습니다. 그래서 지금은 포기하고 다음 모델을 기다리기로 결정했습니다.

이미지 관련 팁(21:13-24:27)

Zack: 포켓몬 게임에서 사용한 힌트 중 마음에 들었던 것 중 하나는 모델에게 포켓몬 게임이라는 점과 게임 요소가 어떻게 표현되었는지 설명해 주셨다는 점입니다.

David: 결국 이미지 위에 그리드를 겹쳐서 각 그리드 섹션을 설명한 다음 가능한 한 상세하게 ASCII 도면으로 재구성했습니다. 이것은 큐 엔지니어링과 많은 유사점이 있지만 이미지로 이런 작업을 해본 적은 없었습니다. 텍스트에 대한 직관 중 많은 부분이 이미지에는 적용되지 않는다는 것을 알게 되었습니다. 예를 들어 다중 샘플 단서는 텍스트에서처럼 이미지에서 잘 작동하지 않습니다.

Alex: 이전에는 멀티모달 단서를 탐색할 때 이미지에 대한 클로드의 인식을 개선하기가 어려웠습니다.

David: 결국 클로드가 벽과 캐릭터를 대부분 인식하도록 할 수 있었지만 게임을 제대로 플레이하는 데 중요한 NPC는 인식하지 못했습니다.

롤플레잉 프롬프트에 대한 토론(24:28-32:26)

Alex: 모델에게 특정 역할이나 정체성을 알려주는 큐잉 기법이 효과적일까요?

아만다 모델의 능력이 향상되고 이해도가 높아질수록 거짓말을 할 필요가 없다고 생각합니다. 저는 거짓말을 좋아하지 않으며, 머신러닝 시스템을 위한 평가 데이터세트를 구축하는 것이 아이들을 위한 퀴즈를 만드는 것과 같다고 생각하지 않습니다. 모델은 언어 모델 평가가 무엇인지 알고 있으므로 실제 작업에 대해 직접 물어봅니다. 저는 모델에게 "언어 모델 평가와 매우 유사한 질문을 구성해 달라"고 말하지 않고 관련 없는 작업을 완료하는 척하는 대신 "언어 모델 평가와 매우 유사한 질문을 구성해 달라"고 말하죠.

Zack: 은유를 사용하면 모델이 작업을 이해하는 데 도움이 된다는 것을 알게 되었습니다. 예를 들어 차트의 품질을 판단할 때 모델에게 "이것이 고등학교 과제라면 이 차트에 몇 점을 주겠습니까?"라고 질문합니다. . 이것은 "당신은 고등학교 선생님입니다"라는 뜻이 아니라 모델이 제가 기대하는 분석의 작동 방식을 이해할 수 있도록 비유를 제공하는 것입니다.

David: 사람들은 종종 비슷한 작업을 완료하는 지름길로 롤플레잉을 사용하지만, 얼마나 많은 제품 세부 정보가 손실되는지 깨닫지 못합니다. 모델의 능력이 향상됨에 따라 모델이 사용될 구체적인 상황을 더 정확하게 설명하는 것이 더 중요해졌습니다. 예를 들어 모델에게 "당신은 유용한 도우미입니다"라고 말하는 대신 "당신은 이 제품에 있고, 이 회사를 대표하며, 이 제품의 지원 채팅 창입니다"라고 말하세요. 사람들은 역할극을 하다 보면 실제 업무에서 벗어나는 경우가 많으므로 모델이 사용될 구체적인 상황을 최대한 자세히 설명하는 것이 좋습니다.

아만다 개인적으로 저는 역할극을 프롬프트 기법으로 사용해 본 적이 없으며, 심지어 능력이 떨어지는 모델에게도 사용해 본 적이 없습니다.

David: 이는 사전 학습된 모델과 RLHF 모델 간의 차이와 관련이 있을 수 있습니다.

아만다 저는 이 과제를 임시로 완료해야 한다고 생각하고 "좋은 차트를 감지해 주길 바라며, 좋은 차트는 ......"라고 말하겠지만 "넌 고등학생이잖아!"라고 말하지는 않을 것입니다. 넌 고등학생이잖아!"라고 말하진 않죠.

간결한 프레젠테이션을 위한 제안(32:27-36:45)

David: 고객이 프롬프트가 작동하지 않는다고 말하면 저는 고객에게 작업을 설명해 달라고 요청한 다음 방금 말한 내용을 녹음하고 텍스트로 옮겨 쓰게 하는데, 대개는 고객이 쓴 프롬프트보다 더 낫습니다.

Zack: 누군가 팁을 최적화하는 데 도움을 요청해서 설명한 내용을 그대로 복사했는데 효과가 있었습니다.

David: 사람들은 프롬프트가 실제로 무엇을 의미하는지 완전히 이해하지 못했습니다. 많은 사람들이 텍스트 상자를 Google 검색창으로 사용하여 키워드를 입력합니다. 기업용 애플리케이션에서 사람들은 특정 텍스트 한 줄이 중요하다고 생각하여 프롬프트에서 지름길을 찾으려고 합니다. 사람들은 완벽하고 통찰력 있는 문장을 찾기 위해 많은 노력을 기울이지만 쉽지 않습니다.

아만다 사람들은 종종 프롬프트에 모델을 위한 공간을 남겨두는 것을 잊어버립니다. 예를 들어 모델은 에지 케이스에 직면했을 때 최선을 다해 사용자의 지시를 따르지만 사용자가 무엇을 해야 할지 알려주지 않으면 잘못된 답을 내놓을 수 있습니다. 모델에 "이상한 일이 발생하여 어떻게 해야 할지 잘 모르겠으면 레이블에 '확실하지 않음'을 출력하세요."라고 말할 수 있습니다. 이렇게 하면 모델이 제대로 처리하지 못하는 상황을 파악하고 데이터의 품질을 개선하는 데 도움이 됩니다.

아만다 마치 제가 직접 평가를 하는 것처럼 다른 사람들에게 프롬프트를 보여주곤 했습니다.

David: Karpathy는 또한 자체적으로 ImageNet 테스트 세트를 수행합니다.

모델 응답에서 유효한 정보를 얻는 방법(36:46-40:46)

Alex: 모델의 응답에서 유효한 정보를 얻으려면 어떻게 해야 하나요? 단순한 숫자가 아니라 모델의 사고 과정을 알 수 있습니다. 이것이 사고 사슬에도 적용되나요?

David: '추론'을 지나치게 강조하는 의인화 비유는 해롭다고 생각합니다. 중요한 것은 사고의 사슬이 작동하고 모델 성능을 향상시킬 수 있다는 것입니다. 구조화된 추론은 그 효과를 더욱 향상시킬 수 있습니다.

아만다 모델이 정답에 도달하는 추론 과정을 제거하고 합리적으로 보이지만 오답으로 이어지는 추론으로 대체하면 모델이 잘못된 결론에 도달하는지 확인합니다.

Zack: 모델이 작업을 완료하기 전에 스토리를 작성하도록 하는 것은 생각의 연쇄가 잘 이루어지지 않습니다.

Alex: 이는 추론 과정이 결과에 영향을 미친다는 것을 시사합니다.

아만다 추론의 단계가 일치하지 않지만 결국 정답이 나오는 경우를 본 적이 있습니다.

프롬프트에서 문법과 구두점의 필요성에 대해(40:47-45:19)

Alex: 프롬프트에 문법과 구두점에 주의해야 하나요?

Zack: 재미있어서 이런 디테일에 주의를 기울이긴 하지만 반드시 그럴 필요는 없습니다. 중요한 것은 디테일에 주의를 기울여야 한다는 것입니다.

아만다 저는 프롬프트에서 철자 오류를 자주 범하지만, 개념을 명확하게 표현하는 데 더 신경을 씁니다.

David: 이는 사전 학습 모델과 RLHF 모델과 관련이 있습니다. 맞춤법 오류의 조건부 확률은 사전 학습된 모델에서 더 높습니다. 사전 학습된 모델의 직관을 프로덕션 환경의 모델에 적용하는 것이 항상 효과가 있는 것은 아닙니다.

Alex: 모델과의 대화는 어느 정도 모방의 한 형태로 볼 수 있습니다.

David: 모델은 사용자의 입력에 따라 동작을 조정합니다.

비즈니스 팁, 리서치 팁, 일반 채팅의 차이점(45:20-50:53)

Alex: 비즈니스 팁, 리서치 팁, 일반 채팅의 차이점은 무엇인가요?

Zack: 연구 기반 프롬프트는 다양성과 모델의 가능성을 탐색하는 데 더 중점을 두므로 예제에 지나치게 의존하지 않도록 예제 수가 적거나 아예 없습니다. 반대로 엔터프라이즈 수준의 프롬프트는 신뢰성과 형식 일관성에 더 중점을 두므로 많은 수의 예제를 사용합니다.

아만다 제가 사용하는 예제는 일반적으로 모델이 작업할 데이터와 다르며, 모델이 개념을 암기하게 하기보다는 개념을 설명하기 위한 것입니다. 인지 작업의 경우 모델이 각 샘플의 정답을 실제로 이해하기를 원합니다.

David: Claude.ai에서는 모델이 작업을 한 번만 올바르게 완료하도록 하면 됩니다. 하지만 엔터프라이즈 애플리케이션에서는 프롬프트가 다양한 상황과 입력 데이터에 대응할 수 있어야 합니다.

큐 엔지니어링 기술 업그레이드를 위한 제안(50:54-53:57)

Alex: 팁 엔지니어링 기술 향상을 위한 제안은 무엇인가요?

Zack: 훌륭한 팁과 모델 결과물을 읽고, 그 원리를 분석하고, 실험해보고, 모델과 더 자주 대화하세요.

아만다 다른 사람들, 특히 여러분의 작업을 모르는 사람들에게 팁을 보여주세요. 계속 연습하고 '초보자'의 관점에서 팁을 살펴보세요.

David: 모델이 할 수 없다고 생각되는 일을 하도록 유도하세요.

탈옥 정보(53:58-56:54)

Alex: 사람들이 탈옥 힌트를 작성하면 모델 내부에서는 어떤 일이 발생하나요?

아만다 한 가지 가능성은 탈옥 큐가 훈련 데이터의 분포에서 모델을 편향시키는 것입니다.

Zack: 탈옥은 때때로 해킹과 사회 공학의 조합처럼 보이기도 합니다.

큐 엔지니어링의 진화(56:55-64:33)

Alex: 지난 3년 동안 프롬프트 프로젝트는 어떻게 변화했나요?

Zack: 효과적인 큐 엔지니어링 기법을 모델 훈련에 통합하여 최고의 기법은 일반적으로 수명이 짧습니다.

David: 저는 점차 모델에게 더 많은 정보와 맥락을 제공할 수 있는 모델의 능력을 존중하는 법을 배웠습니다.

아만다 저는 모델에게 직접 종이를 주고 스스로 큐잉 기술을 익히도록 했습니다.

David: 사람들은 종종 모델링의 힘을 과소평가하고 문제를 '클로드의 수준'으로 축소하려고 합니다.

아만다 프롬프트를 작성하는 방식에 영향을 미칠 모델의 '사고 공간'에 들어가 보겠습니다.

Zack: 미리 훈련된 모델의 사고방식에 더 쉽게 접근할 수 있습니다.

아만다 인터넷에서 콘텐츠를 읽는 것이 책을 읽는 것보다 모델을 이해하는 데 더 도움이 될 수 있습니다.

엔지니어링의 미래를 위한 팁(64:34-끝)

Alex: 큐 엔지니어링의 미래는 어떻게 될까요? 우리 모두가 큐 엔지니어가 될까요?

David: 모델의 목표를 명시하는 것은 항상 필요하며, 이를 명확하게 표현하는 것이 중요합니다. 도구와 방법은 계속 발전할 것이며, 모델은 더 나은 프롬프트를 작성하는 데 도움이 될 수 있습니다.

Zack: 예시를 생성하는 등 프로젝트를 촉진하는 데 도움이 되는 모델을 더 많이 활용할 예정입니다.

아만다 저는 현재 주로 모델이 제가 원하는 결과물을 생성할 수 있도록 메타 프롬프트를 작성합니다. 앞으로는 모델이 디자이너처럼 작동하여 사용자와 상호 작용하고 우리가 진정으로 원하는 것을 말하도록 안내할 수도 있습니다.

David: 클로드에게 저를 '인터뷰'하여 정보를 추출하도록 하겠습니다.

아만다 지금은 머릿속에 있는 개념을 모델에게 전달해야 하지만, 앞으로는 모델이 적극적으로 개념을 말하도록 유도할 수도 있습니다. 철학적 훈련은 복잡한 개념을 명확하게 표현하는 데 도움이 됩니다.

Alex: 사용자로부터 정보를 추출하는 것이 더욱 중요해질 것입니다.

Zack: 큐 엔지니어링은 가르치는 것과 같아서 학생들과 '공감'해야 합니다. 앞으로는 '내성적'이어야 하고 모델이 우리를 이해할 수 있도록 해야 합니다.

아만다 저는 종종 제 아이디어를 명확하게 표현하기 위해 새로운 개념을 정의합니다.

Alex: 아만다는 이를 완벽하게 요약합니다. 여러분의 아이디어를 교육받은 일반인에게 외부화하는 것입니다.

요약:

이 원탁 토론에서는 큐잉 엔지니어링을 중심으로 큐잉 엔지니어링의 정의, 훌륭한 큐잉 엔지니어의 자질, 모델과의 상호작용 방식, 엔터프라이즈급 애플리케이션, 연구 애플리케이션, 향후 방향 등 다양한 측면을 다룹니다. 핵심 사항은 다음과 같습니다:

- 큐 엔지니어링의 핵심은 명확한 커뮤니케이션과 모델의 기능에 대한 이해입니다.

- 훌륭한 프롬프트 엔지니어는 명확하게 표현하고, 반복하고, 오류를 예측하고, 체계적으로 사고할 수 있어야 합니다.

- 모델의 기능이 향상됨에 따라 큐 엔지니어링은 단방향으로 모델에 명령을 내리기보다는 사용자로부터 정보를 추출하는 방법에 더 중점을 두게 될 것입니다.

- 큐 엔지니어링의 미래는 디자이너와 고객 간의 상호 작용과 비슷할 수 있으며, 모델이 사용자의 요구를 표현하도록 안내하는 데 보다 주도적인 역할을 할 수 있습니다.

- 철학은 복잡한 개념을 명확하고 정확하게 표현하는 것을 강조하기 때문에 철학 교육은 큐 엔지니어링 기술을 향상시키는 데 도움이 됩니다.