모델이 다섯 가지 방식으로 작성할 수 있는 문서 섹션은 그 모델의 소유물이 아닙니다. 그것은 여러분의 원본 자료가 아직 답하지 못한 질문입니다. 대부분의 문서 생성 워크플로우는 초안을 한 번 읽어 평가하는데, 이는 유창함을 보상하고 불일치를 숨깁니다. 아래 워크플로우는 이러한 판단을 측정으로 대체합니다. 즉, 동일한 섹션 프롬프트를 여러 번 작성해보고, 단어 표현이 얼마나 변하는지 점수화하며, 그 점수가 최종 텍스트를 누가 작성할지 결정하게 하는 것입니다. 이 결과물은 여러분이 실제 엔드포인트에 연결하기 전에 오프라인으로 테스트 환경(fixture)에 대해 실행할 수 있는 작은 Python 하네스입니다.
단일 샘플의 문제점
모델 초안 하나는 일관성 있고, 구체적이며, 완성되어 보여서 마치 결정처럼 읽힙니다. 동일한 프롬프트를 다시 실행하면 종종 다른 숫자, 다른 순서, 실패 시 발생하는 상황에 대한 다른 주장을 얻게 됩니다. 이러한 분산(variance)은 평균화하여 제거해야 할 노이즈가 아니라 여러분의 입력에 대한 정보입니다. 샘플 간에 형태가 변하는 섹션은 일반적으로 근본적인 사양(spec), 설정(config), 또는 오류 텍스트가 모호하거나 누락되었음을 의미합니다.
따라서 유용한 질문은
이 내용을 draft_stability.py로 저장하세요. 네트워크 코드가 없기 때문에 CI 환경, 노트북, 스케줄링된 작업 모두에서 동일한 파일이 작동합니다.
#!/usr/bin/env python3
"""draft_stability.py — 반복적인 모델 실행에 걸쳐 문서 섹션의 안정성을 점수화합니다.
...
2단계: 모델이 아닌 하우징(harness)을 증명하는 테스트 케이스
samples.json 파일을 만들어 샘플 데이터를 준비하세요. 핵심은 실제 호출을 하기 전에 스코어링 경로를 처음부터 끝까지 검증하고, 엔드포인트가 사용 불가능할 때도 이 확인 작업이 실행되도록 유지하는 것입니다.
{
"sections": {
"install": [
...
python draft_stability.py --fixture samples.json --k 3 --out record.md를 실행하세요. 테스트 케이스는 install이 수렴하고, retry-behavior가 발산 검사를 실패하도록 조정되었습니다. 정확한 점수는 이 세 개의 문자열만을 설명합니다. 대략 다음과 같을 것으로 예상하세요:
install 0.9x MODEL-DRAFT / HUMAN-APPROVE
retry-behavior 0.xx HUMAN
claims disagree across samples: 100, 2, 200, 250, 3, 30, 5, 503, 504, 500
두 번째 줄이 전체 방법론을 하나의 출력으로 보여줍니다. 모델은 retry-behavior를 유창하게 작성할 수 있지만, 재시도 정책(retry policy)은 모델이 읽을 수 있는 곳 어디에도 결정되지 않았습니다.
3단계: 단일 함수 계약으로 실제 샘플 수집하기
이 하우징은 클라이언트에 대해 의도적으로 아무것도 알지 못합니다. 자체 클라이언트를 연결하되, 하나의 함수라는 계약을 유지하세요.
# 이미 사용하고 있는 어떤 클라이언트든 연결하면 됩니다. 이 하우징은 이 형태만 필요합니다.
def backend(prompt: str) -> str:
...
...
그런 다음 python draft_stability.py --fixture live.json --k 5 --out record.md를 실행하세요. --k 5는 다섯 개의 샘플 전체에 대해 재계산하며, 기록 파일은 실제로 사용한 입력값을 기록합니다.
4단계: 판결을 과제로 전환하기
MODEL-DRAFT는 편집자가 톤을 검토하고 리뷰어가 명령어를 확인하는 것을 의미하며, MODEL-OUTLINE은 사람이 제한 사항, 보증 또는 기본값을 명시하는 모든 문장을 작성해야 함을 의미합니다. HUMAN은 다음 작업이 아예 글쓰기가 아니라는 뜻입니다. 질문을 확정하는 설정 파일, 사고 기록(incident), 또는 담당자를 찾아낸 후 프롬프트로 돌아오십시오.
5단계: 입력값이 변경될 때 재실행하기
안정성은 영구적인 라벨이 아니라 특정 순간의 속성입니다. 섹션에 공급되는 설정 파일, 오류 문자열 또는 릴리스 노트가 변경되면 하네스(harness)를 재실행하고, 점수가 떨어지는 것을 해당 섹션의 진실 출처(source of truth)가 벗어났다는 신호로 간주하십시오. 리뷰어가 어떤 섹션이 측정되었고 어떤 섹션은 단순히 작성되었는지 볼 수 있도록 페이지 옆에 record.md를 커밋하십시오.
MonkeyCode가 적합한 곳과 증명하지 못하는 것
반복적인 샘플링은 호출 비용을 발생시키며, 이것이 무료 모델 경로에 대한 실질적인 논거입니다. 이 방법은 한 번의 비싼 호출이 아니라 동일한 프롬프트의 여러 세대(generations)가 필요하기 때문입니다. MonkeyCode의 무료 모델 액세스는 하네스를 변경하지 않고도 해당 루프를 커버하며, 무료 서버 옵션은 기록을 최신 상태로 유지할 수 있도록 픽스처 모드 작업이 스케줄에 따라 실행될 장소를 제공합니다. 공개 고지: 이 문서는 MonkeyCode의 제품 홍보의 일환으로 작성되었습니다.
가용성은 운영자가 공급하는 것이며 내구성 보증은 아니므로, CI에서 픽스처 실행을 최소 기준으로 유지하십시오. 즉, 라이브 엔드포인트에 도달할 수 없을 때도 확인 작업이 여전히 실행되고 올바르게 실패해야 합니다. 만약 항상 픽스처 모드로만 실행한다면, 문서가 아니라 점수 계산기(scorer)를 테스트한 것입니다.
한계점과 이 기능을 건너뛰어야 하는 사람
유사성 측정은 진실이 아닌 표현을 측정합니다: 다섯 개의 샘플은 잘못된 재시도 횟수에 동의하고 아름답게 점수를 매길 수 있습니다. 이것이 divergent-claim 체크가 존재하는 이유이며 사람이 여전히 MODEL-DRAFT를 검토해야 하는 이유입니다. 결정론적 샘플러는 모든 점수를 부풀리므로, 실제로 배포할 때의 변화를 가지고 샘플링하십시오. 매우 짧은 섹션은 단일 조각으로 저하되며, 변경 로그와 생성된 예시는 설계상 불안정하고, 법률적이거나 계약적인 텍스트는 절대 점수가 할당되어서는 안 됩니다. 모델 품질의 벤치마크를 찾는 사람은 이것을 사용해서는 안 됩니다. 이것은 입력값이 확정되었는지 여부를 측정합니다.
무료 모델 액세스에서 샘플링 루프를 시도하고 싶다면, 위의 하네스는 변경 없이 작동하며, 먼저 고정(fixture)이 실행됩니다.