LLM은 명시적 지시에도 불구하고 구조화된 출력에 추론 과정을 노출시킵니다

문제: LLM 검증 과정에서 추론 내용이 유출됨

Claude에 대한 병렬 API 호출을 수행하고 각 호출의 구조화된 출력을 파싱하는 도구를 개발하는 개발자가 간헐적인 문제를 발견했습니다. 각 호출은 [COVER], [SLIDE 1], [CAPTION] 등과 같은 특정 마커 안에 내용을 반환합니다. 두 번째 LLM 패스는 출력을 규칙에 대해 검증하고 실패한 부분을 재작성합니다.

검증 프롬프트는 명시적으로 다음과 같이 명시합니다: "정확히 동일한 형식으로 수정된 텍스트만 반환하세요. 설명 없음. 추론 없음. 위반 목록 없음."

그럼에도 불구하고, 검증 모델은 가끔 수정된 내용 앞에 추론을 출력합니다. 예를 들어: "이 텍스트의 위반 사항을 확인해야 합니다... 이 문장들은 순전히 효과를 위해 사용된 연속적인 극적 쌍을 형성합니다. 다음은 재작성된 내용입니다:" 뒤에 실제 수정된 텍스트가 옵니다.

하류 영향

이 추론 텍스트는 파서로 바로 전달됩니다. 파서는 [COVER]에서 시작하는 내용을 기대하지만 메타 설명을 받게 됩니다. 이로 인해 하류에서 필드 정렬이 잘못됩니다. 한 경우에는 검증기의 추론 텍스트가 이미지 프롬프트 필드 안에 들어가게 되었는데, 파서가 추론을 본문 내용으로 인식하여 모든 것을 몇 줄 아래로 이동시켰기 때문입니다.

프롬프트 강화만으로는 문제를 해결하지 못했습니다. 지시를 더 명확하게 만들고, "출력은 반드시 첫 번째 내용 마커로 시작해야 합니다"를 추가하고, "절대 추론을 포함하지 마세요"를 추가하는 것은 빈도를 줄였지만 완전히 제거하지는 못했습니다. 모델은 특히 수정할 위반 사항을 발견할 때 지시를 무시하는 경우가 있습니다—자신의 작업 과정을 보여주고 싶어 합니다.

해결책: 이중 방어층

효과가 있었던 해결책은 두 가지 층을 포함했습니다:

• 1층: 프롬프트 강화. 문제 발생 빈도를 줄이기 때문에 여전히 가치가 있습니다.
• 2층: 모든 파싱이 발생하기 전에 모든 검증 출력에서 실행되는 방어적 제거 함수입니다. 구조화된 형식의 경우, 첫 번째 인식된 마커에 고정하여 그 앞의 모든 것을 버립니다. 일반 텍스트 형식의 경우, 알려진 검증기 설명 패턴(예: "이 텍스트를 확인해 보겠습니다" 또는 "이것은 제약 조건을 위반합니다")과 일치하는 줄을 제거합니다.

파싱 전 제거 순서가 핵심입니다. 모든 하류 파서는 이미 정제된 출력에서 작동합니다. 이는 필드별 제거 로직을 유지하거나 새로운 추론 형식과의 끊임없는 싸움을 피할 수 있게 합니다.

구현 고려사항

일반 텍스트 제거 패턴의 경우, 신중한 설계가 필요합니다. "This is a violation"을 포착하는 정규식은 합법적인 내용의 "This is a common mistake"도 포착할 수 있습니다. 패턴은 "This violates the/a rule/constraint"와 같이 검증기 특정 언어만 일치하도록 강화되어야 하며, "This is"나 "This uses"와 같은 광범위한 일치는 피해야 합니다. 각 패턴은 배포 전 실제 내용에 대해 검토가 필요합니다.

LLM에서 구조화된 출력을 파싱하는 경우, 프롬프트 지시를 최선의 노력의 첫 번째 패스로 취급하고 항상 파서 앞에 코드 수준의 방어 장치를 두세요. 모델은 95%의 시간 동안 준수하지만, 준수하지 않는 5%의 경우 간헐적이기 때문에 재현하기 어려운 방식으로 하류 로직을 중단시킬 것입니다.