TL;DR

• 비슷한 질문이라도 LLM의 출력 품질이 들쑥날쑥한 최대 요인은 모델의 변덕이 아니라 지시에 적히지 않은 전제의 많음 - 효과가 있었던 것은 「읽는 이(대상) ens나」, 「수치 제약」, 「출력 형식」의 3가지를 지시에 추가하는 것이었다. 반대로 role prompting (당신은 ○○의 전문가입니다 등)에 공을 들이는 것은 거의 효과가 없었다.
• 전제를 전부 언어화하려고 하면 지시가 장문화되어 파탄 난다. 1지시 1변수씩 추가하는 운용이 현실적이다.

배경

일상 업무에서 ChatGPT, Claude, Gemini에게 요약이나 정리를 부탁하는 경우가 많은데, 거의 같은 문면의 프롬프트임에도 불구하고 「한 번에 사용할 수 있는 출력」과 「대폭적인 수정이 필요한 출력」이 무작위로 섞여 있다는 느낌을 받았습니다.

온도(Temperature) 파라미터나 모델의 기분 탓으로 돌리고 싶지만, 실제로 프롬프트를 나란히 놓고 재검토해 보면, 출력이 좋지 않았던 회차는 이쪽의 지시가 모호했다는 케이스가 대부분이었습니다. LLM은 지시에 없는 전제를 학습 데이터상에서 확률(Likelihood)이 높은 형태로 멋대로 보완합니다. 모호함은 채워주는 것이 아니라, 이쪽이 예상하지 못한 형태로 채워지는 것이 실태에 가깝습니다.

효과가 있었던 3가지 제약

1. 읽는 이(대상)의 명시

이 프로젝트의 진행 상황을 처음 듣는 신입 사원이 3분 만에 개요를 파악할 수 있도록 요약해 줘.
전문 용어는 사용하지 말고, 모른다는 전제로 설명해 줘.

대상을 적지 않으면, LLM은 「프롬프트를 작성한 사람」을 암묵적인 독자로 간주하여 요약을 생성하는 경향이 있습니다. 사내 문서나 의사록처럼 읽는 이가 쓰는 이와 다른 케이스에서 이것이 수정의 주된 원인이 되고 있었습니다.

2. 모호한 단어의 수치 변환

간결하게 정리해 줘

이 아니라

300자 이내, 소제목은 3개까지, 불렛 포인트(Bullet point) 중심으로 정리해 줘

「간결하게」, 「알기 쉽게」는 평가 함수로서 기능하지 않습니다. 글자 수, 항목 수, 소제목 수와 같은 수치로 변환하면 출력의 변동성이 체감될 정도로 크게 줄어들었습니다.

3. 출력 스키마(Schema)의 사전 지정

이 회의 내용을 「결정 사항 / 보류 사항 / ToDo (담당자 포함)」의 3개 항목으로 나누어 알려줘

자유 문장으로 내보낸 뒤 스스로 구조화하는 비용은 만만치 않습니다. 원하는 구조를 프롬프트 측에서 미리 전달함으로써, 후속 파싱(Parsing) 및 전기(Transcription)의 수고를 통째로 없앨 수 있습니다.

효과가 없었던 것

• role prompting (「당신은 전문 편집자입니다」 등): 출력의 톤에는 다소 영향을 미치지만, 위의 3가지에 비해 재현성에 대한 기여는 작다.
• 방대한 few-shot 예시 동봉: 입력 데이터의 형태가 매번 다른 태스크에서는, 예시가 오히려 출력을 예시의 방향으로 끌고 가 역효과가 나는 경우가 있었다.
• 「정확하게」, 「틀리지 말고」 등의 강조어: 제약으로서 기능하지 않으며, 단순한 바람의 표명으로 끝난다.

왜 이 3가지가 효과적인가

3가지의 공통점은, 모호한 자연어 요구를 모델이 직접 평가할 수 있는 제약(대상, 수치, 구조)으로 변환하고 있다는 점입니다. 「알기 쉽게」는 모델에게 최적화 대상이 되지 않지만, 「300자 이내, 소제목 3개」는 충족 여부를 스스로 체크할 수 있는 제약이 됩니다. 프롬프트 엔지니어링(Prompt Engineering)이라고 하면 어휘 선택이나 역할 설정에 주목하기 쉽지만, 실무에서 효과적인 것은 제약을 검증 가능한 형태로 떨어뜨리는 것이라는 감각입니다.

운용상의 주의사항

3가지를 한꺼번에 모두 담으려고 하면 프롬프트가 장문화되어 오히려 지시끼리 충돌하는 경우가 있었습니다 (예: 300자 이내와 3개 항목 구조를 모두 엄격하게 지킬 수 없는 경우, 모델이 어느 쪽을 우선할지 불안정해짐). 실무에서는 1회의 지시에 1~2개의 변수씩 추가하며 결과를 보면서 조정하는 운용으로 안착되었습니다.

요약

출력 품질의 변동성으로 고민된다면, 먼저 프롬프트의 어휘를 다듬기 전에 「읽는 이」, 「수치」, 「구조」의 3가지가 지시에 포함되어 있는지 확인하는 것이 가성비 좋은 한 수라고 생각합니다. 동일한 구조는 요약, 의사록, 사양서 초안 등 정확성과 재현성이 필요한 다른 생성 태스크에도 그대로 유용할 수 있습니다.

이 기사는 AI의 지원을 받아 작성되었으며, 사람이 내용을 확인 및 편집하여 공개하고 있습니다.

Discussion