모델이 작성한 문서가 제약 조건을 조용히 잃어버리는 문제: 파이썬 약 100줄로 구현하는 규범적 문장 게이트

대부분의 문서 검토는 잘못된 문장에 주의를 기울입니다. 모델이 초안을 작성한 페이지의 경우, 비용이 많이 드는 실패는 보통 사라진 문장입니다. 즉, '반드시 하지 말아야 할 것(must not)', 사용 중단 공지(deprecation notice), 또는 재작성 과정에서 조용히 사라져버린 전제 조건 같은 것입니다. 아래 게이트는 제약 조건의 제거를 명시적이고 서명된 행위로 만들어서, 모델은 연결적인 산문 작성을 계속할 수 있고 인간은 페이지를 떠나는 모든 제한 사항에 대한 소유권을 유지할 수 있게 합니다.

1. 실패 모드는 발명이 아니라 손실이다

'이 페이지를 개선하라'는 요청을 받은 모델은 이를 글쓰기 작업으로 읽고, 글쓰기 작업은 간결함을 보상합니다. 제약 조건 문장은 어떤 페이지에서든 가장 간결하지 않은 부분입니다. 왜냐하면 좋은 페이지는 개요(overview), 절차(procedure) 내부, 그리고 문제 해결(troubleshooting)에서도 경고를 반복하기 때문입니다. 단축 지침을 한 번 적용하면 이러한 반복은 하나의 언급으로 축소되며, 위에서 아래로 diff를 읽는 검토자는 약해진 페이지가 아니라 더 깔끔한 페이지를 보게 됩니다.

소스 확인만으로는 이를 잡아낼 수 없습니다. '초안의 모든 주장에 출처가 있다'고 확인하는 검사기는 초안이 대체된 페이지보다 적은 주장을 포함할 경우 기쁘게 통과합니다. 왜냐하면 그것은 오직 전방(forward)만을 보기 때문입니다. 여러분에게 필요한 것은 반대 방향입니다. 이전 페이지에서 시작하여, 그 페이지가 가지고 있던 제약 조건들을 나열하고, 인간이 명시적으로 제거해야 한다고 말하지 않는 한 어떤 것도 사라지도록 허용하지 않아야 합니다. 이 확인은 기계적이고 저렴하며, 어떤 모델이 초안을 생성했는지와 무관합니다.

2. 섹션별이 아닌 문장 유형별로 초안 작성 권한 분할하기

섹션 수준의 소유권은 설명하기는 쉽지만 강제하기는 어렵습니다. 왜냐하면 재작성은 섹션 경계를 넘나들고 흥미로운 문장들은 여기저기 흩어져 있기 때문입니다. 문장 분류(Sentence classification)는 실행 가능합니다. 왜냐하면 양태 동사(modal verb)와 지문(fingerprint)은 스크립트가 실제로 볼 수 있는 것들이기 때문입니다. 아래 분할이 바로 게이트가 인코딩하는 것입니다. 이를 시작 정책으로 간주하고, 오른쪽 열을 여러분의 제품에 맞게 조정하십시오.

3. 마커 리스트를 사용하여 제약 조건 문장 추출하기

아래 스크립트는 Python 표준 라이브러리만을 사용하므로, 초안이 생성되는 모든 곳에서 실행되기를 원한다면 유용합니다. 이 스크립트는 페이지를 문장으로 분할하고, 모달 마커 정규식(modal-marker regex)과 일치하는 문장만 유지하며, 이전 세트와 초안 세트를 비교합니다. 제약 조건은 정규화된 문장이 정확하게 살아남으면 present로, 유사한 일치 항목이 있으면 reworded로, 초안에 비슷한 내용이 전혀 없으면 missing으로 분류됩니다.

#!/usr/bin/env python3
"""normative_gate.py - 모델이 작성한 문서에서 제약 조건을 조용히 제거하는 것을 방지합니다.

...

유사성 임계값(similarity threshold)만이 조정 가능한 숫자이며, 0.75는 의도적으로 느슨하게 설정된 기본값입니다. 이는 재작성된 제약 조건을 missing이 아닌 reworded로 분류하여, 사람이 단일하고 불분명한 삭제 대신 이전 문장과 새 문장을 나란히 볼 수 있게 합니다.

4. 제거 메모는 인간의 서명이다

missing 또는 reworded 제약 조건이 자동으로 오류인 것은 아닙니다. 때로는 제한 사항 자체가 정말로 구식이거나 더 이상 필요하지 않을 수도 있기 때문입니다. 중요한 점은 그 결정이 귀속 가능해야 한다는 것입니다. 승인된 모든 변경 사항에는 원본 문장의 지문(fingerprint)에 키가 지정된 항목이 생깁니다:

{
  "6b1f0c9a2d34": {
    "owner": "avery",
...

두 가지 세부 사항이 이 기능을 단순한 의례가 아닌 지속 가능한 시스템으로 만듭니다. 첫째, 키가 문장 텍스트에서 파생되므로, 메모가 다른 제약 조건으로 잘못 이동할 수 없습니다. 만약 문장이 편집되면 지문(fingerprint)이 변경되고 메모는 STALE 상태가 되어 패킷에 표시됩니다. 이 경우 조용히 무시되는 것이 아니라 알림을 받게 됩니다. 둘째, 게이트는 어떤 계정이라도 누락될 때 0이 아닌 값을 반환하므로, CI(Continuous Integration) 작업에서 검토자가 보는 것과 동일한 신호로 출판을 제어할 수 있습니다.

5. 초안 작성 루프에 연결하기 (Wire it into the drafting loop)

1. 생성 전에 게시된 페이지를 고정합니다: git show HEAD:docs/retries.md > docs/before/retries.md.
2. 보호되는 문장을 명시하고 해당 문장의 편집을 금지하는 프롬프트를 사용하여 새 페이지 초안을 작성합니다.
3. 초안을 docs/after/retries.md로 저장하고 게이트를 실행합니다.
4. 전체 페이지가 아닌 패킷을 읽습니다: 유지되어야 할 부분을 복원하거나, 소유자와 이유와 함께 메모를 작성합니다.
5. unaccounted=0이 될 때까지 반복한 후, 일반적인 산문(prose) 검토를 진행합니다.
6. 메모 파일과 페이지를 함께 커밋하여, 추론 과정(reasoning)이 텍스트와 함께 전송되도록 합니다.

초안 작성 단계는 프롬프트를 조정하는 동안 여러 번 초안을 재생성해야 하므로 관대한 무료 티어에서 이점을 얻습니다. MonkeyCode의 무료 모델 액세스를 사용하여 초안을 실행하고, 무료 서버 옵션으로 게이트를 실행하면, 전체 사이클이 유료 런타임과 노트북 간에 파일을 옮기는 대신 하나의 환경 내에 유지됩니다. 고지: 본 기사는 MonkeyCode의 제품 홍보의 일환으로 작성되었습니다. 언급된 두 가지 가용성 주장은 제가 실행한 벤치마크가 아니라 운영자(operator)로부터 나온 것이므로, 의존하는 프로세스를 구축하기 전에 현재 약관을 확인하십시오.

6. 신뢰하기 전에 게이트 테스트하기 (Test the gate before trusting it)

항상 통과하는 게이트는 게이트 자체가 없는 것보다 더 나쁘기 때문에, 알려진 답변이 있는 피처(fixtures)를 사용하여 검증해야 합니다:

for c in 1 2 3 4 5; do
  python3 normative_gate.py fixtures/c$c.before.md fixtures/c$c.after.md \
    --notes fixtures/c$c.notes.json > /dev/null
...

만약 case 2가 통과한다면, 사용자의 마커 목록이 너무 협소하다는 의미입니다. 만약 case 5가 침묵한다면, 오래된 노트들이 축적되어 미래의 삭제를 조용히 사전 승인하게 되며, 이것이 바로 이 게이트(gate)가 존재하여 막으려는 실패 사례입니다.

7. 제한 사항 및 사용 권장 대상

이 게이트는 진실성(truth)이 아닌 존재 여부(presence)를 확인합니다. 즉, 초안에 제약 조건이 원문 그대로 복사되었으나 현재 코드와 모순되는 경우에도 통과할 수 있으며, 페이지와 구현체를 비교하는 사람이 직접 확인해야만 이를 발견할 수 있습니다. 마크다운(Markdown)에서의 문장 분리는 근사치입니다. 왜냐하면 표(tables), 중첩 리스트(nested lists), 코드 블록(code blocks) 등은 단순한 분리기를 망가뜨리기 때문이며, 사용자가 required나 should 같은 일반 단어를 사용하는 경우에도 마커 목록이 오탐지(false positives)를 일으킬 수 있습니다. 이 지문(fingerprints)들은 정규화 규칙(normalization rules)이 고정되어 있는 동안에만 안정적입니다. 따라서 정규 표현식(regex)을 변경하면 기존 노트들이 무효화되므로, 재생성된 노트와 함께 단일 커밋으로 처리해야 합니다.

다음과 같은 경우에는 이 접근 방식을 건너뛰어야 합니다. 문서가 코드로부터 완전히 생성되며 수동 편집이 전혀 없는 경우입니다. 보호할 사전 인간의 제약 조건(prior human constraint) 자체가 없기 때문입니다. 또한, 팀원들이 모든 삭제에 대해 한 줄짜리 이유를 작성하는 데 동의하지 못한다면 건너뛰어야 합니다. 왜냐하면 모두가 가볍게 수정하는 허용 목록(allowlist)은 고무 도장(rubber stamp)이 되어버리기 때문입니다. 이 게이트는 소수의 페이지가 실제 운영 위험을 지니고 있으며 모델이 지속적으로 재작성할 것으로 예상되는 곳에 가장 적합합니다.

가장 중요한 두 가지 사례, 즉 case 2와 case 3부터 시작하여, 사용자가 소유한 가장 위험한 단일 페이지에 적용해 보세요. 만약 게이트가 그곳에서 작동한다면, 그렇지 않았다면 배포했을 삭제를 발견했다는 의미입니다. 무료 서버 옵션으로 실행하는 경우, 첫 번째 실행 비용은 아무것도 들지 않지만 마커를 작성하는 시간만 소요됩니다.