프롬프트 엔지니어링

대규모 언어 모델은 아주 많은 글을 미리 읽어 두고 앞의 말에 이어질 말을 골라 내놓는 프로그램입니다. 사실을 찾아 답하는 것이 아니라 그럴듯한 다음 말을 고르는 방식이라, 무엇을 물었는지에 따라 결과가 크게 갈립니다.

페이지덱에서 태오가 회의록 요약 기능을 처음 만들 때 지시문은 "다음 회의록을 요약해 줘" 한 줄이었습니다. 결과는 매번 달랐습니다. 어떤 회의는 두 줄, 어떤 회의는 열 줄로 나왔고 결정된 사항과 잡담이 같은 무게로 섞여 있었습니다. 지현이 검수하고 못 쓴다고 판정했습니다.

팀이 먼저 떠올린 답은 모델을 바꾸거나 우리 자료로 학습시키자는 것이었지만, 실제로 고친 것은 지시문 하나였습니다. 결정된 사항만 뽑고, 세 줄을 넘기지 말고, 회의록에 없는 내용은 적지 말라고 나눠 적자 같은 모델에서 쓸 만한 결과가 나왔습니다.

프롬프트 엔지니어링은 이 작업을 절차로 만든 것입니다. 모델을 건드리지 않고 지시문만 바꿔 결과를 옮기니 가장 싸고 빠릅니다. 그래서 대개 여기서 시작하고, 여기서 안 되는 것이 확인된 뒤에 다음 수단으로 넘어갑니다.

시작은 지시문을 쓰는 일이 아니라 합격 기준을 적는 일입니다.

1. 무엇을 쓸 수 없는 결과로 볼지 정합니다. 요약이 잘 나왔는지는 사람마다 다르게 판단하지만, 결정된 사항이 빠졌으면 실패이고 회의록에 없는 말이 들어갔으면 실패라고 적어 두면 판정이 같아집니다.
2. 지시문을 네 덩이로 나눠 적습니다. 누구로서 답할지, 무엇을 할지, 어떤 형식으로 낼지, 무엇을 하지 말지입니다. 한 문장에 몰아넣으면 뒤쪽 조건이 무시되는 일이 잦습니다.
3. 예시를 붙입니다. 형식은 말로 설명하기보다 보여 주는 편이 정확합니다. 원하는 입력과 출력을 두세 쌍 붙여 두면 길이와 말투와 항목 순서가 그 예시를 따라옵니다.
4. 출력 형식을 기계가 읽을 수 있게 고정합니다. 사람이 읽을 문장으로 받으면 코드가 다시 뜯어야 하고, 그 규칙은 모델이 문장을 조금 다르게 쓰는 순간 깨집니다. 정해진 항목 이름을 가진 구조로 받으면 됩니다.
5. 모르는 것은 모른다고 하게 만듭니다. 근거가 주어진 자료에 없으면 비워 두라고 적습니다. 이 한 줄이 없으면 모델은 빈칸을 채우는 쪽으로 움직이고, 그렇게 나온 문장이 회의록에 없던 결정사항으로 남습니다.
6. 실패 사례를 모아 고정 세트로 만듭니다. 실제 회의록 스무 건에서 잘못 나왔던 경우를 모아 두고 지시문을 고칠 때마다 다시 돌립니다. 하나를 고치면 다른 하나가 깨지는 일이 흔해서, 이 세트가 없으면 고치는 일이 제자리를 돕니다.
7. 지시문을 코드처럼 보관합니다. 누가 언제 무엇을 바꿨는지와 바꾼 앞뒤 결과를 함께 남깁니다.

잘 맞는 자리는 모델이 이미 할 수 있는 일을 원하는 형태로 꺼내는 경우입니다. 요약, 분류, 문장 다듬기, 형식 변환이 그렇습니다. 시간이 몇 시간 단위로 들고 배포도 지시문만 바꾸면 끝나서 먼저 해 볼 값이 있습니다.

안 맞는 자리는 셋입니다.

1. 모델이 모르는 내용이 필요한 경우. 사내 규정이나 우리 고객 데이터는 모델이 본 적이 없어서 지시문을 아무리 다듬어도 나오지 않습니다. 질문이 들어오면 사내 자료에서 관련 대목을 먼저 찾아 지시문에 붙여 주는 RAG가 이 자리를 맡습니다.
2. 말투나 분류 체계를 고정해야 하는 경우. 매번 지시문으로 설명하는 대신 파인튜닝으로 모델에 익히게 하는 편이 쌉니다. 다만 자료를 수백 건 모아야 해서 앞의 둘로 안 될 때 꺼냅니다.
3. 결과가 반드시 맞아야 하는 경우. 지시문은 확률을 옮기는 수단이라 100퍼센트를 만들지 못합니다. 금액을 계산하거나 권한을 판정하는 일은 코드가 하고, 모델은 그 앞뒤의 글을 다루게 둡니다.

한계가 하나 더 있습니다. 자리의 크기입니다. 지시문과 붙여 준 자료와 답이 모두 컨텍스트 윈도 안에 들어가야 합니다. 한 번에 넣을 수 있는 글의 총량인데, 여기에 예시를 스무 개씩 붙이면 정작 회의록이 들어갈 자리가 줄어듭니다.

"이거 프롬프트로 될 것 같은데요. RAG까지 갈 일은 아닌 것 같아요."

모델이 이미 아는 범위 안의 일이니 싼 수단으로 먼저 해 보자는 제안입니다.

"출력을 문장으로 받지 말고 형식을 고정하죠. 파싱이 계속 깨집니다."

코드가 받아 쓸 수 있는 구조로 내보내게 하자는 말입니다.

"이 스무 건 다시 돌려 봤어요? 지난번에 고친 게 깨졌습니다."

지시문을 고칠 때마다 고정 세트로 확인하자는 뜻입니다.

페이지덱의 회의록 요약은 지금 지시문 파일 하나로 관리됩니다. 태오가 그 파일을 코드와 같은 저장소에 두고, 고칠 때마다 스무 건짜리 세트를 돌려 결과를 나란히 붙입니다. 지현은 그 비교만 보고 통과를 판정합니다.

이 구조로 옮긴 뒤 논의가 짧아졌습니다. 전에는 요약이 이상하다는 말에 무엇이 이상한지부터 맞춰야 했고, 지금은 스무 건 중 몇 건에서 무엇이 빠졌는지로 이야기가 시작됩니다.

지시문을 잘 쓰면 무엇이든 된다고 여기는 경우가 많습니다. 한 줄을 고쳐 결과가 크게 좋아지는 경험을 하면 그렇게 읽힙니다. 하지만 이 수단은 모델이 이미 가진 것을 꺼내는 일이지 없는 것을 만들어 내는 일이 아닙니다. 사내 규정을 모르는 모델에게 규정대로 답하라고 적으면 규정처럼 생긴 문장이 나옵니다. 그 문장이 틀렸다는 것을 읽는 사람이 알 수 없다는 점이 더 나쁩니다. 모르는 내용이 필요한 순간에는 지시문을 다듬는 대신 자료를 붙여 주는 쪽으로 옮겨야 합니다.

한 번 잘 써 두면 끝이라고 보는 것도 흔합니다. 잘 도는 지시문은 코드처럼 안정돼 보입니다. 그런데 같은 지시문이 몇 달 뒤 다르게 동작합니다. 모델 판이 올라가거나 붙여 주는 자료의 길이가 늘어나면 결과가 옮겨 갑니다. 고정 세트 없이 굴리던 팀은 사용자 문의를 받고서야 이 사실을 알게 되고, 그때는 무엇이 언제부터 달라졌는지 되짚을 근거가 없습니다. 에이전트처럼 단계를 여러 번 밟는 구성에서는 이 변화가 더 크게 번집니다. 앞 단계의 결과가 뒤 단계의 입력이 되기 때문입니다.