TL;DR

• 여러 제약 조건을 지키게 하고 싶은 생성 태스크에서, 「생성 → 자기 체크」를 동일 턴 내의 1회 지시로 몰아넣는 방식과, 생성 후 출력을 새로운 메시지로 다시 붙여넣어 별도의 턴에서 대조·수정하게 하는 방식을 비교했다.
• 8개의 제약 조건(환불 대응 메일 상정)으로 테스트한 결과, 내용 계열의 제약(금지 표현, 정형문, 서명 누락 등)은 별도 턴 확인을 통해 거의 해소되었으나, 「150자 이내」라는 글자 수 제약만은 ChatGPT, Claude, Gemini 3사 모두 몇 번을 확인시켜도 고쳐지지 않았다.
• 생성과 검증을 별도 턴으로 나누는 효과는, 검증자가 생성 당시의 문맥으로부터 분리됨으로써 자기 확증 편향(Self-confirmation bias, 자신이 방금 작성한 출력을 관대하게 판정하는 경향)이 줄어드는 데서 기인한다고 생각된다. 다만 이는 의미·내용 면의 제약에는 효과가 있으나, 글자 수와 같이 세어야 하는 제약에는 다른 한계가 작용한다.
• LLM은 텍스트를 서브워드(Subword) 단위의 토큰(Token)으로 처리하고 있으며, 문자를 하나씩 세는 조작을 네이티브하게 수행하는 것이 아니다. 따라서 「글자 수를 다시 세어 주세요」라는 지시 자체도 모델이 잘하는 처리 방식과 일치하지 않는다.

배경

이전 기사(8/2 「사죄 메일 지시는 2번 붙여넣으면 효과가 있다」)에서는 동일 턴 내에서 Prompt Repetition, 역할 지정, 자기 체크 지시를 조합하여 제약 준수율을 높이는 방법을 시도했다. 5개까지는 효과가 있었으나, 제약을 7개로 늘리자 가장 공들인 조합에서도 1개를 지키지 못했다.

이번에는 접근 방식을 바꾸어, 「생성」과 「검증」을 물리적으로 다른 대화(턴)로 분리했을 때 준수율이 어떻게 변하는지 확인했다. 생성 직후의 대화 흐름을 이어가는 것이 아니라, 출력을 복사하여 새로운 메시지로 보내고 제약 리스트와 대조시키는 방식이다.

원리 1: 턴 분리는 검증자의 자기 확증 편향을 줄인다

동일 턴 내에서 「생성한 뒤 스스로 체크하세요」라고 지시할 경우, 모델은 자신이 직전에 생성한 텍스트를 검증하게 된다. 생성과 검증이 동일한 문맥과 동일한 생성의 흐름 속에서 이루어지기 때문에, 모델이 자신의 출력을 대폭 수정하는 것을 피하고 표면적인 확인으로 끝내려는 경향이 나타나기 쉽다.

반면, 출력을 새로운 메시지로 전달하는 방식에서는 모델에게 그 문장이 「자신이 이제부터 검증해야 할, 전달받은 입력」으로 취급된다. 생성된 순간의 문맥에서 분리됨으로써 더욱 비판적인 대조가 작동하기 쉬워진다고 생각된다.

다음은 방금 작성한 환불 대응 메일 문구입니다.
아래의 제약 리스트와 하나씩 대조하여, 지켜지지 않은 항목이 있다면
지적한 뒤, 전문을 수정하여 출력해 주세요.
...

실측 결과, ChatGPT, Claude, Gemini 모두 동일 턴 방식보다 별도 턴 방식에서 지켜진 제약 조건의 수가 늘어났다 (3사 모두 56/8 → 67/8). 특히 「정형문을 사용하지 않는다」, 「완곡한 표현을 피한다」, 「서명 누락」과 같이 텍스트를 읽고 의미적으로 판정할 수 있는 제약은 별도 턴에서의 대조를 통해 거의 해소되었다.

원리 2: 글자 수 준수 확인은 턴 분리로 해결되지 않는 세기(Counting) 문제

한편, 「150자 이내」라는 제약만은 3사 모두 별도 턴에서의 재확인 후에도 지켜지지 않았다. 2번째 턴에서 「글자 수를 다시 세어 주세요」라고 명시적으로 지시해도, 모델은 「148자입니다」와 같이 자기 신고를 하면서도, 실제로 복사하여 카운트하면 160자 전후까지 초과하곤 했다.

이는 턴 분리로 해결된 내용 계열의 제약과는 성질이 다르다. LLM은 입력·출력을 서브워드 단위의 토큰 열로 처리하고 있으며, 「한 글자씩 세는」 조작은 모델의 통상적인 처리 방식의 범위를 벗어나 있다. 턴을 나누어 다시 「세어라」고 지시해도 모델이 실제로 순차적인 카운트 처리를 수행하고 있다고 단정할 수 없으며, 학습 데이터 중의 유사한 패턴으로부터 「그럴듯한 숫자」를 출력하고 있을 가능성이 있다. 검증 문맥을 분리하더라도 이러한 종류의 태스크가 가진 난이도 자체는 변하지 않는다.

원리 3: Hard constraint와 Soft constraint는 유효한 검증 수단이 다르다

제약에는 크게 두 종류가 있다. 글자 수, 키워드 유무, 횟수와 같이 기계적으로 진위를 판정할 수 있는 「Hard constraint (세기·대조로 검증 가능한 제약)」와, 「정형문 같은 느낌」, 「완곡한 표현인지 여부」와 같이 문맥이나 의미의 해석이 필요한 「Soft constraint」이다.

이번 결과는 Soft constraint는 LLM 자체에 의한 별도 턴 검증(separate-turn verification)으로 개선되는 반면, Hard constraint 중 글자 수와 같은 계수(counting) 계열은 LLM에 의한 자기 검증(self-verification)만으로는 안정적으로 해결되지 않음을 보여준다. 이러한 구분은 LLM에 의한 검증(LLM-as-verifier)과 프로그램에 의한 검증(code-based verification)의 효과가 제약 조건(constraint)의 종류에 따라 다르다는 연구 지견과도 일치한다. 실무적으로는 글자 수와 같은 Hard constraint는 AI에 맡기지 않고, 에디터나 스크립트의 글자 수 카운트 기능을 통해 인간 측(또는 외부 도구)이 검증하는 것이 더 확실하다.

효과가 없었던 것

• "글자 수를 다시 세어 주세요"라고 턴을 나누어 반복해서 강조하기: 3개사 모두 자기 신고 글자 수와 실측값이 어긋난 채로 변하지 않았다. 계수 계열의 제약은 LLM의 자기 검증만으로 종결짓지 말고, 외부에서의 실측을 포함할 필요가 있다.
• 제약 리스트를 번호 없는 문장으로 전달하기: 개별 위반 사항을 "전체적으로 문제없습니다"라고 뭉뚱그려 넘기는 케이스가 있었다. 번호가 매겨진 글머리 기호(bullet points)를 사용함으로써 항목별 대조 정밀도가 향상되었다.

요약

생성과 검증을 턴으로 분리하는 운용은 의미·내용 측면의 제약(Soft constraint) 준수율을 높이는 효과적인 수단이다. 다만, 글자 수와 같이 계수가 필요한 제약(Hard constraint)은 턴을 나누어 LLM 스스로 확인하게 해도 해결되지 않는다. 제약의 종류에 따라 Soft constraint는 LLM의 별도 턴 검증, Hard constraint는 외부 도구를 통한 실측과 같이 검증 수단을 구분하여 사용할 필요가 있다.

Discussion