프롬프트 템플릿 최적화 및 세분화
프롬프트 템플릿을 반복적으로 개선하여 일관되고 고품질의 결과를 얻습니다. 좋은 프롬프트 템플릿은 처음 시도할 때 거의 완벽하게 작성되지 않습니다.
필수 Edition
| 지원 제품: Lightning Experience |
| 지원 제품: Einstein for Platform 또는 Einstein 또는 세일즈용 Agentforce 또는 서비스 추가 기능 또는 Agentforce Foundations를 사용하는 Enterprise, Performance 및 무제한 Edition |
최적화는 프롬프트가 필요한 출력을 일관되게 생성할 때까지 테스트, 평가, 세분화하는 반복적인 프로세스입니다. AI 모델은 문구, 구조 또는 지침의 소형 변경 사항에 민감하며, 가장자리 사례는 실제 데이터에서만 나타납니다. 반복은 실패의 증거가 아닙니다. 이는 좋은 프롬프트가 훌륭한 프롬프트가 되는 프로세스입니다.
7단계 반복 주기
1단계: 써봐. 초기 프롬프트 템플릿 초안을 작성합니다. 완벽을 목표로 하지 말고 "테스트에 적합함"을 목표로 합니다. 명확한 과업 정의, 기본 지침(5~7개의 핵심 포인트), 필수 병합 필드, 간단한 형식 요구 사항, 하나 또는 두 가지 핵심 제약으로부터 시작합니다.
2단계: 테스트. 5~10개의 다양한 실제 Salesforce 레코드를 사용하여 프롬프트 템플릿을 실행합니다. 일반적인 사례, 가장자리 사례(일반적이지 않은 값, 최소 데이터, 최대 데이터), 과거에 문제가 있었던 레코드를 포함합니다. 평가를 위해 모든 응답을 저장하고 오류 또는 실패를 문서화합니다.
3단계: 평가하십시오. 평가 범주를 사용하여 성공 기준과 결과를 비교합니다. 각 응답 점수 매기기: 각 기준을 충족하고, 통과율이 어떻게 되며, 실패가 일관되었는지 아니면 무작위입니까?
4단계: 문제 확인. 실패 및 패턴을 분석합니다. 일반적인 문제 범주에는 다음이 포함됩니다.
- 데이터 누락: 명령에 명시적으로 요구되지 않으므로 응답에 필수 요소가 포함되지 않습니다.
- 잘못된 음성: 어조 명령이 모호하거나 누락되어 있기 때문에 응답이 너무 공식적이거나 사례적이거나 로봇적입니다.
- 잘못된 길이: 길이 제약이 누락되거나 무시되어 응답이 너무 길거나 너무 짧습니다.
- 나쁜 구조: 형식 사양이 명확하지 않으므로 응답이 예상되는 형식을 따르지 않습니다.
- 잘못된 내용: 병합 필드가 올바르지 않거나 컨텍스트가 부족하므로 응답에 잘못된 정보가 포함됩니다.
- 결과 불일치: 지침이 가장자리 사례를 처리하지 않으므로 테스트 사례에 따라 품질이 크게 다릅니다.
5단계: 세분화. 학습한 내용을 기반으로 프롬프트 템플릿을 업데이트합니다.
- 정보가 누락된 경우 필수 요소를 나열하는 명시적 지침을 추가합니다.
- 어조가 잘못된 경우 예와 함께 특정 어조 지침을 추가합니다.
- 길이가 잘못된 경우 단어 또는 문자 수와 함께 명시적인 길이 제약을 추가합니다.
- 구조가 잘못되면 자세한 형식 사양을 추가합니다.
- 콘텐츠가 부정확한 경우 추가 컨텍스트를 추가하거나 병합 필드를 수정합니다.
- 결과가 일관되지 않을 경우 빈 필드와 같은 가장자리 사례에 대한 명시적인 처리를 추가합니다.
6단계: 다시 시험해봐. 이전에 사용한 동일한 테스트 데이터에 대해 세분화된 프롬프트를 실행합니다. 통과율이 증가했는지 여부, 이전 실패가 이제 통과되고 있는지 여부, 하나의 문제를 수정하여 새 문제가 발생했는지 여부를 측정합니다. 목표 통과율에 도달할 때까지 반복합니다(일반적으로 프로덕션 사용의 경우 85~95%).
| 버전 | 패스율 | 노트 |
|---|---|---|
| 버전 1 | 60% (6/10) | 제목 줄이 누락되었으며, 어조가 너무 정식 |
| 버전 2 | 80% (8/10) | 제목 줄이 고정되었으며 어조가 개선되었지만 2는 너무 길었습니다. |
| 버전 3 | 90% (9/10) | 길이가 고정되었으며, 한 개의 가장자리 사례만 남았습니다. |
단계 7: 배포. 프롬프트가 일관되게 품질 응답을 생성하면 프로덕션에 배포합니다.
반복 모범 사례
- 버전 내역을 유지합니다. 해당 버전에 대한 통과율과 함께 변경 사항 및 이유에 대한 메모와 함께 각 버전의 프롬프트를 저장합니다.
- 버전 간에 동일한 테스트 데이터를 사용합니다. 이를 통해 개선 사항을 직접 비교할 수 있습니다.
- 가능한 경우 한 번에 한 번씩 변경하십시오. 세 가지 사항을 변경하고 품질이 향상되면 어떤 변경 사항이 도움이 되었는지 알 수 없습니다. 초기 반복은 여러 수정 사항을 일괄 처리할 수 있지만, 이후 반복은 대상이 지정된 변경 사항을 적용해야 합니다.
- 작동하지 않는 항목을 문서화합니다. 상황을 악화하는 시도한 접근 방식을 기록합니다. 그러면 나중에 시간을 절약할 수 있습니다.
- 팀과 학습을 공유합니다. 하나의 프롬프트를 최적화하는 과정에서 배운 내용이 다른 프롬프트에 적용되는 경우가 많습니다.
일반 반복 오류
- 너무 일찍 포기합니다. 프로덕션 품질에 도달하기 전에 3~5번 반복해야 합니다. 이 프로세스에 대한 예산 시간입니다.
- 실제 데이터로 테스트하지 않음. 프로덕션 데이터가 어렵습니다. 항상 기본 테스트 사례가 아닌 실제 Salesforce 레코드를 사용하십시오.
- 한 번에 너무 많은 것을 바꾸는 거야. 이후 반복 시 효과가 있는 항목을 식별할 수 있도록 대상이 지정된 변경 사항을 적용합니다.
- 기타 사례 무시하기. 테스트 데이터에 가장자리 사례를 포함하고 지침에 명시적으로 처리합니다.
- 성공 기준 없음. 반복을 시작하기 전에 측정 가능한 구체적인 2~3개의 성공 기준을 정의합니다. 명확한 목표가 없으면 반복이 목적이 없습니다.
최적화 체크리스트
프로덕션에 준비된 프롬프트 템플릿을 고려하기 전에 다음 항목을 확인하십시오.
- 실제 Salesforce 레코드 15~20개 이상으로 테스트됨
- 이 사용 사례의 목표를 충족하는 통과율(일반적으로 85~95%)
- Edge 사례가 적절하게 처리됩니다.
- 모든 성공 기준이 일관되게 충족됨
- 버전 내역은 통과율 및 변경 노트와 함께 문서화됩니다.
- 최신 버전에 비해 측정 가능한 개선 사항이 표시된 세부 사항
- 남아 있는 문제는 드물고 영향력이 적습니다.
- 팀에서 검토 및 승인
