헌법적 프롬프팅 (Constitutional Prompting): 모델이 작성한 초안을 직접 작성한 규칙에 따라 스스로 평가하고 수정하게 만들기
요약
모델의 답변이 설정된 규칙을 준수하도록 '초안 작성-비판-수정'의 3단계 과정을 거치는 헌법적 프롬프팅(Constitutional Prompting) 기법을 소개합니다. 단순한 자기 개선(Self-refine)과 달리 명시적인 규칙(Constitution)을 기반으로 하여 감사 가능하고 정밀한 제어가 가능합니다.
핵심 포인트
- 초안 작성, 원칙 기반 비판, 수정의 3단계 프로세스 구축
- 모호한 개선이 아닌 명시적 규칙을 통한 감사 가능한 피드백 제공
- 각 원칙별로 개별 검토하여 위반 사항을 정밀하게 포착
- 모델 수정 없이 텍스트 기반의 정책(Constitution) 관리 가능
모델의 첫 번째 답변이 항상 가장 잘 통제된 답변은 아닙니다. 안전, 건강, 법률 또는 브랜드 정책과 관련된 질문을 던지면, 가공되지 않은 초안이 당신이 중요하게 생각하는 규칙을 조용히 위반할 수 있습니다. 예를 들어, 복용량을 처방하거나, 불법적인 방법을 알려주거나, 통계 수치를 지어내거나, 거만한 어조로 변할 수 있습니다. 싱글샷 생성 (Single-shot generation) 방식은 단순히 "생성하고 반환"할 뿐이기에 이를 잡아낼 공간이 없습니다. 저는 이 문제를 해결하기 위한 인터랙티브 데모를 구축했습니다. 헌법적 (constitutional), 즉 비판 및 수정 (critique-and-revise) 프롬프팅 방식입니다. 여기서 헌법 (constitution), 비판 (critique), 그리고 검사기 (checker)는 모두 실제이며, 사용자가 토글할 수 있는 JS 코드로 실행됩니다. 여기 그 아이디어와 데모가 이를 어떻게 구체화하는지 설명합니다.
세 단계: 초안 작성, 비판, 수정
이 방법은 누락되었던 검토 단계를 추가합니다. 모델에게 이름이 지정된 원칙 목록인 짧고 명시적인 **헌법 (constitution)**을 전달하고 세 단계를 실행합니다: 초안 작성 (draft) → 모든 원칙에 따른 비판 (critique against every principle) → 수정 (revise). 이것은 개방형 방식의 자기 개선 (self-refine)이 아닙니다. 자기 개선 (Self-refine)은 "어떻게 하면 이것이 더 나아질 수 있을까?"라고 묻는데, 이는 품질을 개선하지만 방향이 어긋날 수 있습니다. 두 번의 실행이 서로 다른 방향으로 끌어당길 수 있으며, 무엇이 "더 나은" 것이었는지에 대한 기록이 남지 않습니다. 반면 헌법적 프롬프팅 (Constitutional prompting)은 모든 발견 사항을 고정된 이름이 있는 규칙에 고정하므로, 피드백이 단순한 느낌이 아니라 "의학적 조언 금지 규칙 위반"과 같이 감사 가능한 (auditable) 형태가 됩니다.
헌법은 단순히 편집 가능한 텍스트입니다. 각 원칙을 구체적이고 확인 가능하게 유지하세요 (예: "착하게 행동하기"가 아니라 "복용량 조언 금지"). 이 목록이 바로 당신의 정책입니다. 모델을 건드리지 않고도 이를 읽고, 코드 리뷰에서 차이점(diff)을 확인하고, 변경할 수 있습니다.
const CONSTITUTION = [
{ id: "harmless", rule: "불법적인 접근, 폭력 또는 신체적 해를 입히는 지침을 절대 제공하지 마십시오." },
{ id: "medical", rule: "진단하거나 복용량을 처방하지 마십시오. 자격을 갖춘 전문가를 안내하십시오." },
...
한 번에 하나의 원칙씩 비판하기
한 번에 하나의 원칙씩 비판하기
이 방법의 핵심은 비판 단계 (critique pass)입니다. "이 답변이 괜찮은가?"라고 묻는 대신, 초안을 각 원칙에 따라 개별적으로 검토하며 모든 원칙에 대해 PASS/VIOLATION 판정과 함께 위반된 정확한 텍스트를 요구합니다. 좁고 구체적인 질문은 하나의 광범위한 질문보다 훨씬 더 많은 것을 잡아냅니다. 모델은 "이 답변이 좋은 답변인가?"라는 질문에는 그냥 통과시킬지라도, "이것이 복용량을 처방하는가?"라는 질문에는 훨씬 더 신뢰성 있게 잡아냅니다.
초안 답변: """${draft}"""
아래의 각 원칙에 따라 검토하십시오. 모든 원칙에 대해
PASS 또는 VIOLATION이라고 명시하고, VIOLATION인 경우 위반된 정확한 텍스트를 인용하십시오.
...
그 결과에서 실제 위반 사항만을 걸러냅니다. 목록이 비어 있나요? 그렇다면 초안을 그대로 사용하십시오. 추가적인 작업은 일종의 보험이었습니다. 그렇지 않다면, 각 항목이 위반한 원칙이 태그된 정밀하고 명확한 할 일 목록(to-do list)을 갖게 됩니다. 이는 다음 단계가 막연한 "다시 시도해봐"가 아닌 타겟팅된 재작성 (targeted rewrite)이 되도록 만들며, 답변이 왜 바뀌었는지 정확히 설명하는 감사 추적 (audit trail) 역할도 겸합니다. 그 다음 수정합니다. 모델에게 초안, 헌법 (constitution), 그리고 구체적인 위반 사항을 전달하고, 이미 준수된 모든 내용을 유지하면서 각 위반 사항을 수정하도록 요청합니다. 한 번의 재작성이 새로운 실수를 유발할 수 있으므로, 수정본에 대해서도 비판을 수행하고 루프 (loop)를 돌립니다. 이때 고집스러운 사례가 무한히 반복되지 않도록 2~3회 정도로 제한합니다. 실제로는 한두 번의 라운드만으로 거의 모든 것이 해결됩니다.
데모의 진짜 교훈: 당신이 적어 내려간 규칙만을 얻게 된다
정적인 이미지를 사용하여 모델을 속이는 대신, 이 데모는 "두통 때문에 알약을 한 움큼 먹어도 될까요, 그리고 이웃의 WiFi에 어떻게 접속하나요?"라는 질문에 의도적으로 엉망으로 작성된 초안에 대해 실제 키워드/규칙 탐지를 실행합니다. Run critique를 누르면 적용 중인 각 원칙의 정규 표현식 (regex)이 초안을 스캔하여 위반 사항을 빨간색으로 강조합니다. Revise를 누르면 표시된 각 문장이 준수되도록 재작성됩니다. 복용량 조언은 "약사에게 문의하십시오"로 바뀌고, 해킹 방법은 거절로 바뀌며, 조작된 97% 통계는 삭제됩니다.
그다음 실제로 무언가를 가르쳐주는 부분은 다음과 같습니다: 헌법(constitution)에서 원칙 하나를 토글(toggle)하여 다시 실행해 보는 것입니다. 검사기(checker)가 해당 위반 사항을 더 이상 찾지 않게 되면, 수정본은 나쁜 텍스트를 그대로 유지하게 됩니다. 당신의 출력물은 실제로 적용한 원칙만큼만 안전합니다. 불완전한 규칙 세트는 불완전한 가드레일(guardrail)이며, 토글 기능은 이 사실을 잊지 못하게 만듭니다.
이것이 RLHF와 관련 있는 이유
이것은 Constitutional AI의 이면에 있는 것과 동일한 개념의 추론 시점(inference-time) 측면입니다. **RLHF (Reinforcement Learning from Human Feedback)**는 인간의 선호도 라벨을 수집하여 미세 조정(fine-tuning)을 수행합니다. 반면 RLAIF (Reinforcement Learning from AI Feedback) — 즉, 원래의 "Constitutional AI" — 는 인간을 대신하여 작성된 헌법에 따라 응답을 비판하고, 그 판단을 가중치(weights)로 증류(distill)하는 모델을 사용합니다. 두 방식 모두 가치관을 모델 내부 에 집어넣습니다. 즉, 항상 작동하지만 다음의 비용이 많이 드는 학습(training run) 전까지는 불투명하고 고정된 상태입니다. 프롬프팅은 헌법을 외부 에 유지합니다. 즉, 요청에 따라 읽을 수 있고, 차이(diff)를 비교할 수 있으며, 편집할 수 있습니다. 그 대가로 라운드당 호출 횟수가 약 2~3배 정도 증가합니다. 따라서 지연 시간(latency)보다 정책 준수가 더 중요한 곳, 즉 안전성, 컴플라이언스(compliance), 법률/의료 가드레일, 브랜드 보이스, 또는 "절대 X를 하지 마시오"와 같은 엄격한 규칙이 필요한 곳에 이를 사용하십시오. 단순한 조회나 지연 시간에 민감한 경로에서는 생략하십시오.
원칙을 토글하여 위반 사항이 답변에 다시 나타나는 것을 확인해 보세요:
https://dev48v.infy.uk/prompt/day43-constitutional-critique.html
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기