AI 분류 프롬프트 예시: 애매한 문의를 구분하는 좋은 예시 만들기

분류는 단어 찾기보다 처리 목적이 먼저입니다

가상의 생활용품점에 “배송이 늦어서 취소하고 싶어요”라는 문의가 들어왔습니다. “배송”이라는 단어 때문에 배송 문의로 분류하면 취소 요청을 놓칠 수 있습니다. 담당팀 연결이 목적이라면 취소 의사를 우선해야 합니다. 반면 불편 원인을 집계하려면 배송 지연도 함께 기록하는 것이 유용합니다.

하나의 분류 열로 두 목적을 동시에 해결하지 마세요. 처리 요청과 불편 원인을 별도 열로 두면 “취소 / 배송 지연”처럼 표현할 수 있습니다. 이 설계는 특정 모델의 기능보다 업무 기준의 문제입니다. AI에 입력하기 전에 분류표를 사용하는 사람이 어떤 결정을 내릴지부터 정해야 합니다.

쉬운 예시와 헷갈리는 예시를 함께 줍니다

“주문을 취소해 주세요”는 취소의 쉬운 예시입니다. “언제 도착하나요?”는 상태 확인의 쉬운 예시입니다. 여기에 “늦으면 취소할 수도 있어요”를 추가하면 확정 요청과 조건부 의사 표현의 경계가 드러납니다. 예시가 모두 쉬운 문장이라면 실제 복합 문의에서 분류가 흔들릴 수 있습니다.

예시 답을 만들 때 담당자끼리 먼저 합의합니다. 사람 두 명이 다르게 분류하는 문장을 AI에게만 일관되게 처리하라고 요구할 수는 없습니다. 합의되지 않은 경우에는 보류 분류를 허용하고 확인 질문을 붙입니다. 모든 행을 억지로 세 종류에 넣는 것보다 애매한 행을 남겨두는 편이 후속 업무에 도움이 됩니다.

입출력 형식을 고정한 복사 프롬프트

예시의 개수보다 서로 다른 경계가 담겨 있는지가 중요합니다. 아래 양식에서는 문장을 처리 요청과 원인으로 나누며, 결과 옆에 판단 근거가 된 원문의 짧은 구간을 남깁니다. 고객 이름·주소·주문번호를 제거한 연습 자료부터 시험하세요.

가상 고객 문의를 분류합니다. 목적은 담당자가 처리 순서를 정하는 것입니다.
처리 요청은 취소 / 배송 상태 / 확인 필요 중 하나만 고르세요. 불편 원인은 별도 열에 적습니다.
예시1: “배송이 늦어 주문을 취소합니다” → 취소 / 배송 지연.
예시2: “늦으면 취소할 수도 있어요” → 확인 필요 / 배송 우려.
예시3: “언제 출발하나요” → 배송 상태 / 미명시.
출력 열: 문의 ID, 처리 요청, 불편 원인, 근거 구간, 사람 확인 여부. 실제 취소나 답변 발송은 하지 않습니다. 기준에 없는 사안은 가장 비슷한 분류에 억지로 넣지 마세요.
분류할 자료: [가상 또는 비식별 문의 목록]

잘못된 결과는 예시 하나씩 보완합니다

처음 결과가 조건부 취소를 모두 취소로 분류했다면 “취소할 수도 있다”와 “취소한다”의 차이를 명시합니다. 반대로 확정 취소까지 확인 필요로 보내면 명확한 요청 문장을 추가합니다. 같은 뜻의 예시를 여러 개 늘리는 것보다 자주 틀리는 경계를 한 쌍으로 보여주는 편이 수정 이유를 설명하기 쉽습니다.

예시를 추가한 뒤에는 새로 고친 문장만 보지 말고 이전에 맞았던 문장도 함께 넣습니다. 취소 기준을 강화하면서 배송 상태 문의가 잘못 바뀔 수 있기 때문입니다. 변경 전과 후의 결과를 문의 ID로 연결하면 어떤 유형이 좋아지고 나빠졌는지 확인할 수 있습니다. 전체 정확도만으로는 이런 차이를 놓치기 쉽습니다.

분류 정확도를 확인하는 작은 시험표를 만듭니다

처음에는 가상 문의 12개 정도를 준비해 사람이 정답을 정합니다. 단순 문의, 복합 문의, 문장이 짧은 문의, 조건부 요청을 섞습니다. 분류 규칙을 만드는 데 쓴 예시와 별도로 처음 보는 시험용 문장을 남겨두세요. 이미 보여준 예시만 맞히는 것은 실제 업무에서의 재현성을 충분히 보여주지 못합니다.

검수할 때는 오분류 개수뿐 아니라 그 결과를 봅니다. 취소 요청을 상태 문의로 보낸 오류는 응대 지연을 만들 수 있습니다. 반대로 확인 필요 항목이 너무 많으면 담당자의 검토량이 줄지 않습니다. 오류의 중요도와 보류율을 함께 기록하고, 자동 처리를 확대하기 전에 사람이 결과를 확인하는 기간을 둡니다.

짧은 반응은 문맥이 없으면 보류합니다

“괜찮아요”라는 한마디는 만족일 수도 있고 제안을 사양하는 말일 수도 있습니다. 배송 지연 사과 뒤에 나온 답인지, 교환 제안 뒤에 나온 답인지에 따라 의미가 달라질 수 있습니다. 분류 입력이 마지막 문장만 포함한다면 문맥이 부족하다는 상태를 허용해야 합니다. 앞선 내용을 알고 있는 사람의 정답과 짧은 입력만 본 AI의 결과를 같은 조건으로 비교하지 마세요.

가상 시험표에는 같은 “괜찮아요”를 서로 다른 앞 문장과 함께 넣어볼 수 있습니다. 예시를 만들 때 사람도 해석이 갈리면 확인 필요를 정답으로 둡니다. 단일 분류가 꼭 필요한 시스템이라면 업무 담당자가 우선 기준을 정하고 보류 항목이 어디로 전달되는지 확인해야 합니다. 빈칸을 줄이는 것보다 잘못된 자동 처리가 생기지 않는지 살피는 것이 실제 운영에서 더 중요한 평가가 될 수 있습니다.

분류표를 바꿀 때 예시도 같이 갱신합니다

상품 교환 항목을 새로 만들었다면 기존 취소 예시 중 교환에 해당하는 문장이 없는지 살핍니다. 분류 이름만 바꾸고 예시는 그대로 두면 상충하는 지시가 됩니다. 규칙의 적용일과 담당자를 기록하면 과거 통계와 현재 통계의 차이를 설명할 수 있습니다. 새 항목 추가로 비율이 변한 것을 고객 행동 변화로 단정하지 마세요.

OpenAI 공식 프롬프트 안내에서도 입력과 기대 출력의 예시를 사용하는 방법을 소개합니다. 이 글의 문의 문장과 처리 기준은 그 방법을 연습하기 위해 새로 만든 가상 설계입니다. 실제 상점 정책을 대신하지 않으므로 반품·취소 가능 여부 같은 결론은 담당자가 확인한 정책으로 별도 관리해야 합니다.