실무에서 계속 쓰게 되는 프롬프트 패턴 정리
작년부터 기획/개발 문서 작업에 LLM을 붙여서 쓰고 있는데, 결국 살아남은 패턴 몇 개만 정리해봅니다.
1. 역할과 출력 형식을 먼저 고정하기
'너는 X다'보다 '출력은 반드시 아래 JSON 스키마를 따른다'가 훨씬 효과가 컸습니다.
2. 예시를 2~3개 넣기
설명 열 줄보다 예시 두 개가 나았습니다. 특히 애매한 경계 케이스를 예시로 넣으면 결과가 안정됩니다.
3. 한 번에 다 시키지 않기
요약 + 분류 + 번역을 한 번에 시키면 항상 하나가 부실해집니다. 단계를 나눠서 중간 결과를 검수하는 게 최종 품질이 더 좋았습니다.
4. 실패 케이스를 다시 프롬프트에 반영
틀린 출력을 모아두고, 그걸 반례 예시로 넣는 방식이 제일 효율적이었습니다.
결국 프롬프트도 코드처럼 테스트가 필요하다는 결론입니다. 잘 쓰는 분들 다른 팁 있으면 알려주세요.
9 개의 답변
ㅇㅈ 특히 4번. 실패 케이스 모아서 반례로 넣는 거 진짜 효과 크더라
1번은 좀 갈리는 듯. 나는 역할 지정이랑 출력 형식 둘 다 넣어야 안정적이었음. 형식만 고정하면 톤이 너무 기계적으로 나와서
출처 있음? 아니면 본인 경험 정리한 거?
글쎄 2번은 케이스 바이 케이스 아님? 도메인이 좁으면 예시 두 개로 충분한데, 도메인 넓어지면 예시 늘리는 순간 프롬프트만 몇천 토큰 되더라. 그럴 땐 차라리 규칙을 촘촘히 쓰는 게 나았음
저도 비슷하게 쓰는데 3번은 진짜 공감. 요약+분류 한 번에 시키면 분류가 항상 부실해짐ㅋㅋ 단계 나누면 토큰 더 먹어도 결과물 손보는 시간이 확 줄어서 총합은 이득
오 이건 몰랐네. 반례 예시 넣는 건 생각 못 했음
여기에 하나 추가하자면 temperature나 seed 고정해서 돌리는 것도 은근 중요합니다. 같은 프롬프트인데 결과가 매번 달라지면 개선이 되는 건지 운인지 판단이 안 돼서요. 그리고 실패 케이스는 그냥 모아두기만 하면 안 되고, 왜 실패했는지 한 줄로 라벨링해두면 나중에 반례 넣을 때 훨씬 편합니다. 저는 이거 안 해서 두 달치 로그를 다시 까봤음...
동의 안 됨. 요즘 모델들은 그냥 대충 던져도 알아서 잘 뽑아주던데 굳이 이렇게까지 해야 하나 싶음. 물론 정형화된 산출물 뽑을 땐 님 말이 맞음