유피테르
유피테르
🧙 AI 위자드
🏅 베스트오브베스트

Hermes로 법률의견서에 세 명의 평가자와 조정자를 붙여, 예측 Gold까지 검증했다

📝 한줄 요약

법률의견서 평가 Skill에 빠른 단일 평가와 앙상블 평가 선택 단계를 넣고, 같은 가상 의견서를 세 명의 독립 평가자·검증자·조정자에게 맡겨 보았습니다. 점수를 높이는 것이 아니라 법적 권위, 사실 전제, 인용 연결, 과잉 감점, 미해결 불확실성을 따로 확인하는 구조를 만든 것이 핵심입니다.

바쁘시면 이것만 읽어도 돼요:

  • 기존에는 한 명의 평가자가 법률의견서의 범위·사실·법리·권위·실무성을 한 번에 판단하는 방식이 중심이었습니다.

  • 지금은 평가자 A·B·C가 서로의 결과를 보지 않고, 검증자가 점수를 보기 전에 독립 체크리스트를 작성합니다.

  • 조정자는 평균이나 다수결로 결론을 내리지 않고, 충돌한 문항만 원문과 공식 근거로 다시 읽습니다.

  • 합성 납품지연 fixture를 실제로 7회 호출하여 7회 성공했고, 최종 점수 80.0과 SCOPED_GOLD: ex-ante-prediction을 확인했습니다.

  • 이 Gold는 실제 소송 승소나 손해액을 보증하는 라벨이 아닙니다. 정해진 기준일과 자료 범위 안에서 사전예측의 구조와 불확실성 처리가 평가계약을 통과했다는 뜻입니다.

🎯 이런 분들께 도움돼요

  • AI로 법률의견서나 법률 검토문을 반복 평가하는 분

  • 여러 모델을 쓰되 단순 평균·다수결을 넘는 운영 규칙을 만들고 싶은 분

  • 법령·판례 인용과 사실 전제를 함께 검수해야 하는 법무·감사·연구 담당자

  • 실제 판결이나 처분이 아직 없는 사전예측형 법률의견서를 평가하는 분

  • AI 평가 결과를 바로 Gold로 저장하지 않고, 근거와 한계를 남기고 싶은 분

  • 모델을 더 붙이는 것과 실제 평가 신뢰성을 높이는 것이 다르다고 느끼는 분

😫 문제 상황 (Before)

법률의견서 평가는 처음에는 꽤 단순해 보였습니다.

의견서 읽기
→ 점수 매기기
→ 가장 설득력 있는 이유 쓰기
→ 부족한 부분 알려주기

하지만 법률의견서를 한 명의 평가자에게만 맡기면, 비슷한 점수가 반복되어도 그 점수가 정말 안정적인지 알기 어렵습니다. 같은 관점과 같은 오독을 반복한 것일 수도 있기 때문입니다.

법률의견서에는 논술 답안과 다른 위험도 있었습니다.

  • 존재하지 않는 판례를 그럴듯하게 만들어낼 수 있습니다.

  • 기준일이 다른 법령을 섞을 수 있습니다.

  • 합성 사실을 실제 증거처럼 취급할 수 있습니다.

  • 인접 조문이 빠졌다는 이유만으로 의견서를 과도하게 감점할 수 있습니다.

  • 실제 판결이나 처분이 없다는 이유만으로 사전예측형 의견서를 LIMITED 처리할 수 있습니다.

이 문제를 본격적으로 다루게 된 계기는 다음 요청이었습니다.

논술 채점 Skill에 세 명의 채점자와 조정자를 붙인 사례글을 참고해서 우리 법률의견서 평가 Skill에도 평가자를 붙이는 과정을 사례게시글로 작성해보자.

처음부터 “모델을 세 개 더 붙이면 되겠다”고 생각하지 않았습니다. 세 평가자가 서로 같은 오류를 반복하지 않도록 정보 경계를 만들고, 검증자와 조정자의 권한을 분리하는 것이 먼저였습니다.

🛠️ 사용한 도구

  • Hermes Agent: 평가 역할을 독립 프로세스로 실행하고, 호출·retry·게이트·최종 상태를 기록했습니다.

  • legal-opinion-evaluator Skill: 법률의견서의 입력 게이트와 다섯 가지 평가축을 사용했습니다.

  • ENSEMBLE runtime: 평가자 A·B·C, 독립 검증자, 조건부 조정자를 연결했습니다.

  • 법률 권위 확인 계층: 기준일 법령 receipt, claim manifest, external recheck, citation map을 사용했습니다.

  • write-post 형식: 비개발자 독자가 작업 배경과 결과를 따라올 수 있도록 Before–During–After 구조로 다시 썼습니다.

  • Lecture Recap Library: 검증된 사례글을 원본과 구분되는 active canonical로 등록했습니다.

이번 사례에서는 실제 개인정보가 포함된 자문 원문을 게시글에 넣지 않았습니다. 반복 실행이 가능한 합성 fixture만 사용하고, 실제 결과가 없는 사전예측 평가라는 점을 처음부터 명시했습니다.


🔧 작업 과정

1. 한 명의 평가에서 QUICK / ENSEMBLE 선택으로 바꿨습니다

처음부터 모든 평가를 긴 앙상블로 돌리면 속도와 비용이 부담됩니다. 반대로 중요한 법률의견서까지 한 명의 평가자에게만 맡기면 관점의 누락을 발견하기 어렵습니다.

그래서 먼저 두 가지 평가 방식을 선택하도록 했습니다.

평가 방식을 선택해 주세요.

1. 빠른 단일 평가: 평가자 1명 + 독립 검증자 1명
2. 앙상블 평가: 독립 평가자 3명 + 검증자 + 필요 시 조정자

초안에 대한 빠른 피드백은 QUICK으로 처리하고, 제출 전 검토나 Gold 후보처럼 근거와 오류를 함께 확인해야 하는 경우 ENSEMBLE을 선택합니다.

이렇게 나누고 나니 평가자 수 자체보다 목적에 맞는 실행을 고르는 일이 먼저라는 점이 분명해졌습니다. 모든 문서에 같은 무게의 검증을 적용하는 것이 아니라, 위험도와 사용 목적에 따라 평가 깊이를 조절할 수 있게 된 것입니다.


2. 평가자 세 명에게 서로 다른 질문을 맡겼습니다

세 평가자는 같은 루브릭을 사용하지만 중심 관점을 달리했습니다.

평가자

중심 관점

주로 확인하는 것

A

범위·사실·출처

질의 충족, 사실·가정 구분, 자료와 출처 연결

B

법리·권위·논증

법령의 현재성, 요건·예외·반론, 법리 연결

C

증거·사용성·반론

입증책임, 상대방 최강 반론, 실무 선택지, 민감도

세 평가자는 서로의 점수나 의견을 보지 않습니다.

평가자 A 실행
평가자 B 실행
평가자 C 실행
→ 각 결과를 독립적으로 보관
→ 검증자가 독립 체크리스트 작성
→ 검증자가 제한된 요약만 보고 대조

여기서 중요한 것은 모델 이름을 다르게 부르는 일이 아니었습니다. 각 평가자가 무엇을 보았고 무엇을 보지 않았는지를 운영 규칙으로 고정하는 일이었습니다.

예를 들어 평가자 B가 법령의 현재성과 법리 연결을 깊게 확인하더라도, 평가자 A의 점수나 평가자 C의 반론 목록을 미리 볼 수 없게 했습니다. 그래야 “앞의 평가자가 이렇게 말했으니 나도 그렇게 보겠다”는 연쇄 동조를 줄일 수 있습니다.


3. 검증자는 점수를 보기 전에 먼저 읽게 했습니다

검증자에게 평가자 결과를 처음부터 보여 주면, 평가자의 점수와 표현에 끌릴 수 있습니다. 그래서 검증자는 먼저 다음 항목만 독립적으로 작성합니다.

  • 질의와 평가범위

  • 결론을 바꿀 사실과 가정

  • 기준일과 법령 버전

  • 필수 권위 앵커

  • 필수 법리 연결

  • 상대방의 최강 반론

  • 증거 공백

  • 산술 검증 준비 상태

그 다음에야 평가자별 결과를 제한적으로 비교합니다. 검증자는 점수를 직접 고치는 역할이 아니라 다음 오류를 찾습니다.

  • 근거 없는 감점 또는 가점

  • 원문 오독

  • 필수 권위와 선택적 보강 권위의 혼동

  • 요건과 증거의 연결 누락

  • 평가자 간 critical issue 불일치

  • 점수 산술 오류

  • 조정자 호출 필요 여부

실제 canary에서는 평가자 A와 B가 Gold contract에 필수로 들어 있지 않은 민법 제387조를 사실상 필수 권위처럼 취급했습니다. 평가자 C는 이를 critical issue로 보지 않았습니다.

검증자가 이 불일치를 찾아냈고, 조정자는 제387조를 이번 scoped Gold의 필수 권위가 아니라 선택적 보강사항으로 재분류했습니다. 세 명 중 두 명이 같은 말을 했다는 이유만으로 그 판단을 자동 채택하지 않은 것입니다.


4. 조정자는 평균을 내지 않고 충돌 문항만 다시 읽었습니다

조정자는 세 점수의 평균을 내는 사람이 아닙니다. 다음과 같은 충돌이 있을 때만 개입합니다.

  • 평가자 간 영역별 점수 차이가 큰 경우

  • 총점 범위가 기준을 넘는 경우

  • 평가 가능성·중심 권위·critical issue 판정이 충돌하는 경우

  • 검증자가 과잉 감점·중대한 누락·오독을 지적한 경우

조정자는 전체 의견서를 처음부터 다시 평가하지 않았습니다. 충돌 문항과 관련된 원문, Gold contract, 공식 권위 receipt, external recheck, citation map만 확인했습니다.

이번 과정에서 조정자의 가장 중요한 역할은 결론을 강제로 하나로 만드는 것이 아니었습니다.

필수 권위인가?
선택적 보강사항인가?
치명적 결함인가?
보완 가능한 논증 공백인가?
계속 공개해야 할 limitation인가?

이 질문을 구분하면서 점수를 바꾸지 않고도 평가의 품질을 높일 수 있었습니다.


5. 반복해서 돌릴 수 있는 가상 의견서를 고정했습니다

평가자 구조가 제대로 작동하는지 확인하려면 같은 입력을 여러 번 돌려 봐야 합니다. 그래서 실제 개인정보가 포함된 자문 원문 대신 합성 법률의견서를 fixture로 고정했습니다.

항목

fixture 내용

계약일

2026-01-10

약정 인도일

2026-02-01

실제 인도일

2026-02-20

주장된 대체 구매비용

100만 원

관할

대한민국

기준일

2026-02-20

필수 권위

민법 제390조·제393조·제396조

의뢰 질의는 다음과 같습니다.

이 의견서가 매도인의 납품 지연에 관한 채무불이행·손해배상 쟁점과 반론·증거·권고를 적절히 연결하는지 평가하라.

이 fixture는 다음 연결을 시험합니다.

  • 납품 지연과 채무불이행

  • 귀책사유와 불가항력

  • 지연과 대체구매 사이의 인과관계

  • 통상손해·특별손해와 예견가능성

  • 채권자 과실과 손해확대 방지

  • 원래 계약가격과 대체구매가격의 비교

  • 증거 목록과 각 요건의 연결

  • 상대방의 최강 반론

  • 보수적인 청구액 산정

반면 계약상 면책·불가항력·책임제한·유예·통지 조항, 운송장애의 실제 원인, 원계약가격, 대체품의 동등성, 직접 관련 판례, 실제 손해액은 확정하지 않았습니다.

처음부터 모르는 것을 모른다고 적은 이유는, 실제 법률문서처럼 보이게 만드는 것보다 평가가 무엇을 전제로 하는지 반복해서 확인하는 일이 더 중요했기 때문입니다.


6. 실제 결과가 없다고 평가를 멈추지 않았습니다

이번 fixture에는 실제 판결이나 행정처분이 없습니다. 그렇다고 다음처럼 처리하지 않았습니다.

실제 결과 없음 → LIMITED → 점수 없음

대신 두 질문을 나누었습니다.

질문

평가 층위

실제 소송이나 처분의 결과가 적법했는가

나중의 OUTCOME_VALIDATION

결과가 나오기 전 작성된 의견서의 예측 구조가 합리적이었는가

현재의 ex-ante 평가

질의, 합성 사실, 기준일, 관할, 필수 조문 receipt, 독립 재확인 자료를 확인할 수 있었으므로 입력 게이트는 EVALUABLE로 판정했습니다.

다만 이것은 실제 청구액이나 소송 결과를 판단했다는 뜻이 아닙니다. 평가 대상은 사전예측형 의견서의 구조와 위험통제입니다.


7. 점수보다 먼저 Gold contract를 고쳤습니다

첫 live canary는 실행 자체에는 성공했습니다.

호출 7회
성공 7회
실패 0회

하지만 바로 Gold를 부여하지는 않았습니다. 실행 성공과 Gold 자격은 다른 문제였기 때문입니다.

처음에는 본문 인용과 권위 receipt의 연결이 충분히 결정되지 않았고, 미해결 불확실성 처리도 지나치게 엄격했습니다. 사전예측형 의견서의 특성상 실제 계약서·가격자료·판례 원문이 없을 수 있는데, 이를 모두 치명적 결함으로 보면 정직하게 한계를 공개한 의견서가 오히려 불리해집니다.

그래서 Gold contract에 다음을 분리해서 넣었습니다.

  • 기준일과 관할

  • 필수 권위 조문

  • verified authority receipt

  • claim과 source_refs

  • opinion locator

  • external recheck

  • evidence pack

  • 경쟁 해석과 decision pivot

  • bounded uncertainty

  • SCOPED_GOLD: ex-ante-prediction

불확실성을 허용했지만 숨긴 것은 아닙니다. 공개된 불확실성, Full moderator, 외부 재확인, 차단 상태 부재를 함께 요구했습니다.


8. 법령 인용을 citation map으로 연결했습니다

“본문에 민법 제390조가 적혀 있다”는 말만으로는 충분하지 않았습니다. 그래서 다음 연결을 만들었습니다.

필수 조문
→ verified authority receipt
→ claim ID
→ 의견서 위치
→ 실제 인용 문구

이번 fixture의 필수 권위는 다음과 같이 연결되었습니다.

조문

receipt

의견서 위치

민법 제390조

AUTH-390-HIST-20260220

제4절 제1문단

민법 제393조

AUTH-393-HIST-20260220

제4절 제2문단

민법 제396조

AUTH-396-HIST-20260220

제4절 제3문단

이렇게 해야 다음을 각각 확인할 수 있습니다.

  • 공식 법령 원문이 실제로 확인되었는가

  • 해당 조문이 이번 평가의 필수 권위인가

  • claim이 receipt와 연결되어 있는가

  • 본문에 실제 citation text가 있는가

  • opinion locator가 존재하는가

  • 필수 조문 전체가 빠짐없이 매핑되었는가

법령 권위 receipt가 확인되었다고 해서 직접 관련 판례까지 확인된 것은 아닙니다. 계약·가격 증거가 없다는 사실도 별도로 남겼습니다.


9. 법률 표현 하나를 고치고 v5를 다시 돌렸습니다

v4에서 SCOPED_GOLD 자격을 회복한 뒤에도 조정자는 민법 제396조와 관련된 표현을 다시 읽었습니다.

당시 문구는 다음과 같았습니다.

참작될 수 있다

조정자의 지적을 반영하여 다음과 같이 보정했습니다.

참작하여야 한다

수정 원문의 SHA-256을 다시 계산하고, claim manifest와 citation map을 동기화한 뒤 mock과 실제 Hermes Full live를 모두 재실행했습니다.

이 과정에서 인상적이었던 점은, Gold를 한 번 받았다고 해서 문장 검토가 끝나지 않았다는 사실입니다. 평가 시스템을 만드는 목적은 Gold 라벨을 얻는 것이 아니라, 법문과 본문 표현 사이의 작은 차이를 다시 발견하는 데 있었습니다.


✅ 결과 (After)

Before vs After

항목

Before

After

평가 방식

한 명의 평가자 중심

QUICK 또는 ENSEMBLE 선택

평가 관점

한 사람이 범위·법리·증거를 모두 확인

A·B·C가 범위·법리·증거 관점 분리

독립성

결과를 서로 대조하는 경계가 불명확

서로의 점수·결과를 보지 않는 정보 경계

검증 순서

점수와 근거를 함께 확인

검증자가 점수 전에 독립 체크리스트 작성

조정 방식

평균 또는 종합 의견에 의존할 위험

충돌 문항만 공식 receipt로 재검토

법령 인용

본문에 조문이 있다는 수준

조문·receipt·claim·locator·문구 연결

불확실성

미확인 자료를 Gold 차단 사유로 섞을 위험

bounded uncertainty와 fatal defect 분리

live 실행

설계와 실행을 혼동할 위험

7회 호출, 7회 성공, retry 0 read-back

최종 상태

결과 Gold와 예측 평가가 섞일 위험

SCOPED_GOLD: ex-ante-prediction으로 한정

실제 실행 결과

v5 Hermes Full live의 read-back 결과는 다음과 같습니다.

항목

결과

Grader A

77.0

Grader B

84.75

Grader C

80.0

최종 점수

80.0

전체 호출

7회

성공

7회

실패

0회

retry

0회

inspection gate

PASS

input gate

EVALUABLE

Full moderator

완료

authority citation map

필수 3개 조문 모두 PASS

Gold

SCOPED_GOLD: ex-ante-prediction

오프라인 회귀 테스트도 32개를 통과했습니다.

무엇이 달라졌나요?

가장 큰 변화는 평균 점수가 아닙니다. A·B·C의 점수가 77.0, 84.75, 80.0으로 서로 달랐음에도, 왜 차이가 생겼는지 설명할 수 있게 되었습니다.

  • A는 범위·사실·자료의 빈틈을 강조했습니다.

  • B는 법리·권위·이행지체 연결의 보강 필요성을 강조했습니다.

  • C는 증거 설계와 실무 사용성을 중점적으로 읽었습니다.

  • 검증자는 제387조를 필수 권위처럼 요구한 부분을 표시했습니다.

  • 조정자는 이를 선택적 보강사항으로 재분류했습니다.

  • 민법 제396조 표현은 문구 수준에서 다시 보정되었습니다.

결과물

이번 작업의 결과는 하나의 점수표가 아니라 다음 묶음입니다.

  • 평가자별 rubric과 근거

  • 검증자 독립 체크리스트와 flags

  • 조정자 disputed items와 source recheck

  • authority citation map

  • evidence pack과 external recheck

  • bounded uncertainty

  • 최종 점수와 Gold scope

  • 실제 호출·성공·retry 기록

실제 판결이나 처분이 없으므로 OUTCOME_GOLD는 부여하지 않았습니다. 나중에 공고·처분·판결·실제 계약자료가 생기면 별도의 OUTCOME_VALIDATION으로 다시 확인해야 합니다.


💬 이 과정에서 배운 AI 활용 팁

효과적이었던 것

  1. 평가자 수보다 정보 경계를 먼저 정했습니다. 세 명의 평가자가 서로의 결과를 보지 않게 하니, 다수결보다 서로 다른 누락을 발견하는 데 도움이 되었습니다.

  2. 검증자를 점수 뒤가 아니라 점수 앞에 배치했습니다. 검증자가 먼저 원문·기준일·필수 권위를 읽어야 평가자 결과에 끌려가지 않습니다.

  3. 조정자에게 전체 재평가를 시키지 않았습니다. 충돌 문항과 관련 receipt만 주어야 조정자가 새로운 추측을 덧붙이지 않습니다.

  4. Gold contract를 점수표와 분리했습니다. 높은 점수와 근거 검증은 서로 다른 품질 게이트입니다.

  5. 모르는 자료를 limitation으로 남겼습니다. 직접 판례, 계약 조항, 실제 가격자료가 없다는 사실을 숨기지 않았습니다.

이렇게 하면 안 돼요

  1. 모델 세 개의 점수를 단순 평균하고 “더 정확해졌다”고 말하면 안 됩니다.

  2. 평가자 두 명이 같은 조문을 요구했다고 해서 Gold contract 밖의 조문까지 필수로 만들면 안 됩니다.

  3. 실제 결과가 없다는 이유만으로 사전예측형 법률의견서를 자동 LIMITED로 내려서는 안 됩니다.

  4. 법령 receipt가 있다는 이유로 직접 관련 판례나 실제 증거까지 확인했다고 쓰면 안 됩니다.

  5. 설계 문서에 적힌 예정 흐름을 live 성공으로 표현하면 안 됩니다. 호출 수, 게이트, retry, citation map을 실제로 읽어야 합니다.

  6. SCOPED_GOLD를 승소 가능성이나 실제 손해액 보장처럼 사용하면 안 됩니다.


🌍 다른 업무에 적용한다면?

이 구조는 법률의견서뿐 아니라 내부 감사 대응 메모에도 적용할 수 있습니다.

예를 들어 감사 지적에 대한 법무 검토문을 평가한다고 가정해 보겠습니다.

  • 평가자 A는 감사 지적 사실, 계약·문서의 시간순서, 누락된 자료를 확인합니다.

  • 평가자 B는 적용 법령, 내부 규정, 권한과 절차, 기준일을 확인합니다.

  • 평가자 C는 감사기관의 최강 반론, 재발방지 조치, 실무자가 실제로 할 수 있는 대응을 확인합니다.

  • 검증자는 세 평가자의 점수를 보기 전에 감사 질문과 필수 근거의 독립 체크리스트를 만듭니다.

  • 조정자는 처분 가능성이나 중대한 위법성처럼 의견이 갈린 문항만 원문과 공식 근거로 재검토합니다.

이렇게 하면 “법적으로 맞는가”와 “감사 대응에 실제로 쓸 수 있는가”를 한 점수로 섞지 않고, 사실·권위·증거·실무 조치를 나누어 볼 수 있습니다.


🚀 앞으로의 계획

이번 실행은 사람 채점자의 Gold 정답과 비교한 실험이라기보다, 평가 구조와 근거 추적성을 검증한 canary였습니다.

다음에는 비식별 법률의견서와 사람 판정을 연결해 단일 평가와 앙상블을 비교할 예정입니다. 점수 하나만 보지 않고 다음 지표를 확인하려고 합니다.

  • 사람 판정과의 평균절대오차

  • 영역별 점수 분산

  • 핵심 법리·권위 누락 발견률

  • unsupported deduction 비율

  • citation map 완성률

  • EVALUABLE / LIMITED / DEFERRED 판정 일치율

  • 조정자 개입률과 개입 후 오류 감소율

  • 호출 시간과 비용

  • 실제 결과가 생긴 뒤의 OUTCOME_VALIDATION 일치·불일치 양상

목표는 모델을 계속 늘리는 것이 아닙니다. 어떤 의견서는 QUICK으로 충분하고, 어떤 의견서는 ENSEMBLE과 조정자까지 필요한지 운영 기준을 더 선명하게 만드는 것입니다.


📋 재사용 가능한 프롬프트

프롬프트 1: 독립 법률의견서 평가자

당신은 법률의견서 평가자 [A/B/C]입니다. 아래 의견서 원문, 의뢰 질의, 사실·전제, 기준일·관할, 공식 권위 receipt만 사용하여 [범위·사실·출처 / 법리·권위·논증 / 증거·사용성·반론] 관점에서 독립적으로 평가해 주세요. 다른 평가자의 점수나 의견은 보지 않았다고 전제하세요. 확인되지 않은 판례·조문·사실은 만들지 말고 AUTH, MISSING, LIMITATION으로 표시하세요. 각 점수에는 의견서 위치와 근거를 연결하고, 결론을 바꾸는 사실과 상대방의 최강 반론을 함께 적어 주세요. 실제 소송 결과나 승소 가능성을 평가하지 말고, 기준일 당시 사전예측의 구조와 실무성을 평가해 주세요. [의견서 원문], [의뢰 질의], [사실·전제], [권위 receipt]는 실제 자료로 교체하세요.

프롬프트 2: 독립 검증자와 조정자

먼저 평가자 점수와 결론을 보지 않고 [질의·범위], [결정적 사실·가정], [기준일·법령 버전], [필수 권위], [필수 법리 연결], [증거 공백], [상대방 반론] 체크리스트를 작성하세요. 그 다음 평가자 결과를 대조하여 원문 오독, 근거 없는 감점, 필수 권위와 선택적 보강 권위의 혼동, citation map 불일치, 산술 오류, 조정 필요 여부를 표시하세요. 조정이 필요하면 충돌한 문항만 [원문], [Gold contract], [공식 receipt], [external recheck]로 재검토하세요. 평균·다수결로 법적 결론을 정하지 말고, 점수 변경 여부와 별도로 미해결 불확실성과 재개 조건을 기록하세요. [required_authority_articles], [authority_receipts], [citation_map], [grader_digest]는 이번 평가 자료로 교체하세요.


📚 도움받은 글

이 사례는 MOSL님이 작성하신 사례글을 직접 읽고, 빠른 단일 평가와 앙상블 평가의 선택·독립 채점자·점수 전 검증·충돌 문항 조정이라는 구조를 법률의견서 평가의 권위 receipt·증거·기준일 체계에 대조해 정리했습니다.

원문에서 배운 구조를 그대로 복사하지 않고, 논술의 제시문 근거를 법률의견서의 법령·판례·증거 receipt로 바꾸고, SCOPED_GOLD: ex-ante-prediction, authority citation map, bounded uncertainty, OUTCOME_VALIDATION 분리를 추가했습니다.



🏁 마무리

세 명의 평가자와 조정자를 붙이는 일은 AI에게 같은 질문을 세 번 던지는 일이 아니었습니다. 중요한 것은 모델 수가 아니라 다음 네 가지였습니다.

독립성
공식 권위의 범위
불확실성의 공개
재현 가능한 감사 기록

이번 앙상블은 점수를 한쪽으로 끌어올리지 않았습니다. 어떤 평가는 과잉 감점을 되돌렸고, 어떤 평가는 법률 표현을 더 엄격하게 고치게 했습니다.

최종 Gold도 점수의 높이에 붙인 것이 아닙니다. 무엇을 확인했고 무엇을 아직 모르는지 설명할 수 있는 상태에 붙였습니다.

따라서 이번 사례의 Gold는 다음 의미로만 사용합니다.

SCOPED_GOLD: ex-ante-prediction은 정해진 기준일·관할·권위·사실 전제 안에서 사전예측형 법률의견서의 구조·근거·조건부 논증·불확실성 처리가 평가계약을 통과했다는 뜻입니다. 실제 판결·처분·승소·손해액을 보증하는 라벨은 아닙니다.

실제 결과자료가 생기는 날에는 별도의 OUTCOME_VALIDATION을 다시 실행해야 합니다.

지피터스 뉴스레터

이번 주 AI, 딱 쓸 것만

매주 월요일 오후,
읽고 바로 써먹을 AI 소식만