Jev × CMDS 사례 연구와 공개 강연

상황

제 볼트의 노트는 frontmatter CMDS:로 87개 서브카테고리 가운데 하나를 가리킵니다. 새 노트가 들어올 때 이 값을 Jev에게 고르게 할 수 있는지가 질문이었습니다.

• 2026-09-24 첫 측정은 이름만 준 87지선다였고, r1 design과 같은 91건 기준 43/91(47.3%)이었습니다.
• 2026-09-26 r1(design 91건, threshold 100건)은 병목 두 개를 보였습니다. 첫째, 코드가 87개를 12개로 줄여 주면 선택 품질은 그대로였고 손실 전부가 압축 단계의 재현율에서 났습니다. 둘째, 14개 서브카테고리의 정의가 목차 머리글을 이어 붙인 대체문뿐이었습니다. 104 Terminologies(용어 노트)와 802 Articles(발행 글)가 여기에 들었고, threshold 100건 가운데 84건의 정답이 이 14개였습니다.
• 그 결과 threshold 100건에서 정의를 준 조건이 이름만 준 조건보다 낮았습니다(정의 17/100, 이름만 23/100, 이름만 맞힌 6건과 정의만 맞힌 0건, p 0.031).

그래서 세 가지를 물었습니다. 정의를 채우면 재현이 오르는가. 그 이득이 다른 폴더에서도 유지되는가. 코드 규칙표보다 나은가.

Jev에게 물은 것

Choice 질문 하나입니다. state에는 노트의 제목, description, 태그, 본문 앞부분을 넣고, criteria에는 87개 선택지와 각 정의, 그리고 보류를 넣었습니다. r2부터는 지시에 형식 우선 문장을 더했습니다: 노트의 형식이 분명하면(한 용어를 정의하는 용어 노트, 발행하려고 쓴 글 등) 주제보다 그 형식에 맞는 카테고리를 먼저 고려하라.

{
  "model": "jev-1.13.0",
  "state": {
    "title": "벡터 임베딩",
    "description": "텍스트를 숫자 벡터로 바꾸는 임베딩의 뜻과 쓰임을 정리한 용어 노트",
    "tags": ["AI/term"],
    "body_head": "벡터 임베딩은 단어나 문장을 고정 길이의 숫자 배열로 바꾼 표현이다..."
  },
  "questions": {
    "cmds": {
      "type": "choice",
      "instructions": "이 노트가 속하는 CMDS 서브카테고리를 고르라. 노트의 형식이 분명하면 주제보다 그 형식에 맞는 카테고리를 먼저 고려하라. 각 선택지의 설명(criteria)을 기준으로 판단하라. 근거가 부족하면 보류.",
      "criteria": {
        "104 Terminologies": "한 용어의 뜻과 쓰임을 정의하는 용어 노트",
        "620 Generative AI": "생성형 AI의 원리, 도구, 활용 사례를 다루는 노트",
        "802 Articles": "외부에 발행했거나 발행을 전제로 쓴 완성 글",
        "(나머지 84개 선택지)": "...",
        "보류": "근거가 부족하거나 어느 선택지에도 명확히 속하지 않음"
      }
    }
  }
}

위 정의 문구는 합성 예시이며 실제 초안 정의가 아닙니다. 비교한 조건은 다음과 같습니다.

• 이름만: 87개 이름만 줍니다.
• 정의 + 지시: 87개 이름과 정의(초안 14개 포함), 형식 우선 지시를 줍니다. r3에서는 같은 payload를 정순과 역순으로 보냈습니다.
• 압축 + 정의: 코드가 87개를 20개로 줄이고 정의와 지시를 붙입니다.
• 코드 기준선(Jev 호출 없음): 항상 최다 클래스(104), frontmatter type 규칙표, 노트와 "이름 + 정의" 문서 사이의 BM25 1위.
• 캐스케이드(r3 주 조건): type 규칙이 닿으면 규칙으로 끝내고, 닿지 않으면 정순과 역순의 Jev가 합의할 때만 답합니다. r2 결과를 본 뒤 세운 가설이라 새 데이터에서 사전 등록한 뒤 한 번 검증했습니다.

결과

r2 최종 분할 120건(영구 노트와 문헌 노트 폴더, 2026-09-26)의 결과입니다.

• 짝 비교: 이름만 대 정의 + 지시 b6/c73(p < 0.0001). 규칙표 대 정의 + 지시 b18/c8(p 0.076). 정의 + 지시 대 압축 b53/c4(p < 0.0001).
• 압축 조건은 정답이 20개 목록 안에 있을 때 42/55를 골랐습니다. 그러나 목록이 정답을 담은 비율이 55/120(45.8%)이었고, 802 Articles 27건은 한 번도 목록에 들지 못했습니다.
• 이득은 정의가 비어 있던 형식 클래스에서 났습니다. 802 Articles 0/27 → 26/27, 104 Terminologies 9/66 → 54/66, 초안 정의 클래스 전체 13/101 → 84/101(b2/c73).
• 원래 description이 있던 클래스 19건은 11/19 → 7/19로 내려갔습니다(b4/c0, p 0.125).
• 입력 비용은 1,000건당 이름만 약 $0.087, 정의 + 지시 약 $0.241입니다(호출당 입력 × $0.042/1M).

r3 새 폴더 65건(문서, 자산, 산출물 폴더에서 r1과 r2가 쓰지 않은 노트, 2026-09-26)의 결과입니다.

• 정순의 top-3 제안 적중은 42/65(64.6%)였고, 정순과 역순의 결정 불일치는 10/65(15.4%)였습니다.
• 캐스케이드는 정순 단독보다 낮았습니다. 같은 노트에서 캐스케이드만 맞힌 것은 0건, 정순 단독만 맞힌 것은 8건입니다(p 0.0078).
• 규칙표가 닿은 27건만 보면 규칙 1/27, 같은 노트의 Jev 8/27입니다. type: note 26건에 붙은 "note → 220 Personal Insights" 규칙이 26건 모두 틀렸습니다.
• 87지선다에서 confidence 0.7 이상 구간의 정답은 r2 58/69, r3 16/33이었습니다.
• 주제와 도구 클래스에서는 두 라운드 모두 40% 안팎이었습니다(r2에서 r3와 겹치는 클래스 18건 중 7건, r3 65건 중 28건). 620 Generative AI는 r2 0/3, r3 0/8이었습니다. r3의 주된 불일치는 620 → 842 Course Development and Resources 6건, 주제와 도구 클래스 → 907 Product & Engineering Division 8건입니다.

제가 정한 규칙

• 분류 선택지에는 이름만 주지 않고 정의를 붙입니다. 비어 있는 정의 칸이 AI 분류의 천장이 됩니다.
• 분류 결과는 쓰지 않은 폴더에서 다시 잽니다. r2만 봤다면 "규칙표가 먼저 끝내고 나머지만 Jev"가 운영안이 됐을 것이고, 새 폴더 65건이 그 가설을 한 번에 꺾었습니다.
• 87지선다는 자동 분류가 아니라 top-3 제안으로 씁니다(r2 112/120, r3 42/65).
• 87지선다에서 confidence 0.7 이상을 자동 승인 근거로 쓰지 않습니다(r3 16/33).
• type 규칙표는 기준선으로 계속 돌리되, 만든 폴더 밖에서는 캐스케이드 앞단에 두지 않습니다.

한계

• 사람 판단 대비 정확도는 모릅니다. 620 → 842 같은 불일치는 드리프트이거나 다른 타당한 라벨일 수 있고, 소유자 판정을 기다립니다.
• 정의 교체와 형식 우선 지시가 함께 바뀌어 둘의 기여를 가를 수 없습니다. 둘 다 r1 결과를 본 뒤 만들었습니다.
• 초안 정의 14개는 소유자 확인 전 초안이며 CMDS 정책이 아닙니다.
• r2와 r3는 항목과 클래스 구성이 달라 짝 검정이 없습니다. r2의 75.8%(91/120)는 형식 클래스 두 개(104와 802)가 최종 분할의 93/120을 차지한 표본 구성의 영향을 받았습니다.
• r3의 규칙표 실패는 note 규칙의 실패입니다. r2에서 이득을 만든 규칙(terminology, literature-note, essay)은 새 폴더에 적용 대상이 없어 시험되지 않았으므로, 규칙표 전체가 틀렸다고 말할 수 없습니다.
• 모델 버전 하나, 하루, 조건당 한 번입니다.

관련 영상: 3편 「규칙표가 무너진 날」

상황

qmd는 로컬 마크다운 검색 도구로, 키워드 검색(BM25)과 벡터 검색의 순위를 RRF로 합칩니다. 한국어로 물으면 1위가 자주 표적이 아닙니다. 두 가지를 물었습니다.

• 재선택: 후보 목록 안에서 Jev가 맞는 노트를 고를 수 있는가.
• 필터: 후보를 LLM 컨텍스트에 넣을 만큼 줄이면서 표적을 남길 수 있는가.

설계는 여덟 모델 보고서들의 공통 논리를 따랐습니다. 끝단 정확도는 후보 재현율을 넘을 수 없으므로, 로그에 표적이 후보 안에 있었는지를 따로 남겨 오류를 검색 층과 선택 층으로 나눕니다.

Jev에게 물은 것

• 표적과 질의: r1 design 24, threshold 28, r2 최종 분할 55, r3 새 위키 페이지 49개 표적입니다. 표적마다 한국어 질문 1개를 GPT-6 Luna가 표적의 description만 보고 만들었습니다.
• 후보 풀: qmd BM25 top-10과 벡터 top-10을 RRF로 합친 목록입니다.
• 재선택(Choice): state에 질의를, criteria에 후보 노트의 제목과 그 노트의 description, 그리고 "해당 없음"을 넣었습니다. 정순과 역순으로 각각 보냈습니다.
• 필터(Noul): 후보마다 "이 후보가 질의가 찾는 바로 그 노트인가"를 0~1로 묻고, 절단점을 넘는 후보만 유지 집합으로 남깁니다.

재선택 payload (합성 예시)

{
  "model": "jev-1.13.0",
  "state": { "질의": "반복되는 노트 양식을 자동으로 채우는 방법을 정리한 노트가 어디 있지?" },
  "questions": {
    "find": {
      "type": "choice",
      "instructions": "질의가 찾는 노트를 후보 중에서 하나 고르라. 각 선택지 설명은 그 노트의 요약이다. 질의가 찾는 노트가 후보에 없으면 '해당 없음'.",
      "criteria": {
        "템플릿 자동화 가이드": "템플릿 변수와 자동 실행으로 반복 양식을 채우는 절차",
        "데일리 노트 운영 원칙": "하루 기록의 구조와 작성 순서를 정한 노트",
        "속성 표준": "frontmatter 필드 이름과 값의 규칙",
        "해당 없음": "어느 후보도 질의가 찾는 노트가 아님"
      }
    }
  }
}

필터 payload (합성 예시). 후보 하나에 Noul 질문 하나를 붙여 한 요청에 담습니다.

{
  "model": "jev-1.13.0",
  "state": { "질의": "반복되는 노트 양식을 자동으로 채우는 방법을 정리한 노트가 어디 있지?" },
  "questions": {
    "c01": { "type": "noul", "instructions": "후보 노트 제목: 템플릿 자동화 가이드 / 요약: 템플릿 변수와 자동 실행으로 반복 양식을 채우는 절차\n이 후보 노트가 state의 질의가 찾는 바로 그 노트인가?" },
    "c02": { "type": "noul", "instructions": "후보 노트 제목: 데일리 노트 운영 원칙 / 요약: 하루 기록의 구조와 작성 순서를 정한 노트\n이 후보 노트가 state의 질의가 찾는 바로 그 노트인가?" }
  }
}

결과

한국어 질문의 끝단 정확도입니다. 짝 비교는 같은 단위에서 풀 1위만 맞힌 수 b, Jev만 맞힌 수 c입니다.

• 끝단 정확도는 후보 재현율과 조건부 선택의 곱과 개수 기준으로 정확히 같습니다: 141/156 × 132/141 = 132/156. 놓친 24단위 가운데 15단위(156 − 141)는 후보 풀이 표적을 담지 못했고, 9단위(141 − 132)는 Jev가 후보 안에서 다른 것을 골랐습니다. 그 9단위 가운데 6단위는 가까운 형제 페이지(한 개념과 그 인스턴스, 같은 제품의 다른 버전 페이지)였습니다.
• 후보 생성 층 수리: r1에서 qmd의 전문 검색 색인이 한글을 음절 단위로 띄어 저장해서, 여러 음절짜리 한국어 BM25 질의가 한 건도 맞지 않았습니다(한국어 질문 52단위 가운데 1단위만 BM25 목록이 비지 않음). r2부터 질의어를 음절 구문으로 바꿔 우회하자 같은 55표적의 후보 재현율이 46/55에서 50/55가 됐고, 새로 풀에 들어온 4단위를 정순과 역순 모두 맞혔습니다.
• 로컬 qmd query 기본 모드(질의 확장, HyDE, 재랭킹): r2에서 1위 26/55(47.3%), top-3 44/55, top-40 안 55/55였고 질의당 중앙값 33.3초가 걸렸습니다. Jev 호출은 약 0.5초입니다. 같은 단위에서 qmd query 1위만 맞힌 것은 1건, Jev만 맞힌 것은 20건입니다(p < 0.0001).
• 순서: 역순 재선택의 끝단은 r2 46/55, r3 44/49였고, 정순과의 결정 불일치는 r2 3/55, r3 3/49였습니다.
• 기권: 표적이 후보 밖일 때 "해당 없음"을 고른 것은 합계 3/15였습니다(r1 3/6, r2 0/5, r3 0/4).

필터(Noul 유지 집합)의 결과입니다. 표적이 후보 안인 단위 기준입니다.

• r3에서 0.3 절단은 평균 17.55개 후보 가운데 86.4%를 덜어냈습니다. 같은 개수로 자른 qmd 상위 3개는 표적을 25/45만 남겼습니다.
• r2에서 최종 분할을 본 뒤 계산한 0.3의 유지율(49/50)이, r3의 새 표적에서 등록값으로 다시 나왔습니다(44/45). 0.3에서 떨어진 유일한 r3 표적은 Noul 값이 정확히 0.30이라 엄격 규칙(초과)으로 빠졌습니다.

제가 정한 규칙

• 검색 개선은 후보 생성 층부터 고칩니다. AI 재선택은 고르는 단계만 고칩니다(네 표본 합계 141/156 × 132/141 = 132/156, 곧 90.4% × 93.6% = 84.6%).
• 한국어 검색 도구는 색인이 한국어를 어떤 단위로 자르는지 먼저 확인합니다. 음절로 자르는 색인에 단어로 물으면 BM25는 조용히 빈 결과를 냅니다.
• 후보 가운데 하나를 고를 때는 Jev Choice로 재선택하고, LLM 컨텍스트에 넣을 후보는 Noul 0.3 유지 집합으로 줄입니다.
• "찾는 노트가 없다"는 판정은 Jev에 맡기지 않고 별도 장치로 만듭니다(기권 3/15).

한계

• 질의는 실제 사용자 질문이 아니라 한 모델이 description만 보고 만든 질문입니다.
• 표적 하나만 정답으로 셌으므로, 형제 페이지를 고른 답은 사람이 보면 쓸 만할 수 있습니다.
• r3 표적은 모두 위키 페이지라, 메인 볼트 새 표본에서의 성능은 모릅니다.
• r3의 0.3 유지율 44/45는 점 추정으로 0.95를 넘었지만 Wilson 하한은 88.4%입니다.
• r3의 한 단위에서 응답의 choice 필드는 "해당 없음"이었지만 확률 1위(0.31 대 0.30)는 다른 페이지여서, 등록 규칙(확률 1위)에 따라 틀림으로 처리했습니다.
• 라운드마다 후보 풀이 달라(r1은 한국어 BM25 없음) 합계는 참고값입니다. 결정성은 모릅니다.

관련 영상: 2편 「만 개를 세 개로」

상황

새 노트나 작업 파일이 들어오면 어느 프로젝트 폴더로 갈지 정해야 합니다. 제 볼트의 프로젝트 폴더는 README 노트를 두고, 그 frontmatter description에 프로젝트를 1~2문장으로 적습니다. 질문은 이것이었습니다. 프로젝트 이름만으로 충분한가, README 한 줄이 판단을 바꾸는가. 이 비교는 여덟 모델에게 준 공유 패킷이 던진 질문 가운데 하나였습니다.

Jev에게 물은 것

• 선택지: 성격이 서로 다른 활성 프로젝트 6개와 보류입니다.
• 조건: 이름만, 그리고 이름 + README description. 각각 정순과 역순으로 보냈습니다.
• 데이터: r1 design 30, threshold 30, r2 최종 분할 80(봉인 분할을 한 번 평가). r2 최종 분할의 프로젝트별 건수는 30, 20, 15, 9, 5, 1로 불균형합니다. 다수 클래스 참고치는 30/80(37.5%)입니다.

{
  "model": "jev-1.13.0",
  "state": {
    "title": "발표 도구 세 가지 단축키 비교표",
    "description": "세 발표 도구의 단축키와 화면비 설정을 같은 기준으로 비교한 작업 노트",
    "tags": ["presentation"],
    "body_head": "비교 기준은 다섯 가지다..."
  },
  "questions": {
    "project": {
      "type": "choice",
      "instructions": "이 노트가 속하는 활성 프로젝트 폴더를 고르라. 각 선택지 설명은 그 프로젝트 README의 요약이다. 근거가 부족하면 보류.",
      "criteria": {
        "발표 도구 비교": "여러 발표덱 제작 방식을 같은 기준으로 비교하고 선택 근거를 남기는 프로젝트",
        "독서 기록": "읽은 책의 핵심 개념을 연결해 지식 지도로 정리하는 프로젝트",
        "판단 모델 실험": "판단 전용 모델을 노트 분류와 검색에 붙여 실측하는 프로젝트",
        "(나머지 3개 프로젝트)": "...",
        "보류": "근거가 부족하거나 어느 선택지에도 명확히 속하지 않음"
      }
    }
  }
}

프로젝트 이름과 설명은 합성 예시입니다. 이름만 조건에서는 criteria의 설명 자리를 비워 둡니다.

결과

조건별 정확도와 오류 수입니다. 오류에는 보류가 들어 있습니다.

• 짝 비교(이름만만 맞힌 수 b, README만 맞힌 수 c): r1 design b0/c3, threshold b0/c1, r2 최종 분할 정순 b1/c10(p 0.012), 역순 b1/c9(p 0.022).
• 틀리는 모양이 두 라운드에서 같았습니다. 제목만으로 내용을 알 수 없는 발표 도구 비교 노트와 어학 학습 노트가, 이름이 넓게 들리는 지식관리 실험 프로젝트 쪽으로 끌려갔습니다. r2에서 발표 도구 비교 프로젝트는 13/20 → 20/20, 어학 학습 프로젝트는 2/5 → 5/5가 됐고, 나머지 세 프로젝트는 두 조건 모두 전부 맞혔습니다.
• README 조건이 새로 만든 오류는 2건이었습니다. 에이전트 설계 프로젝트의 노트가 주제어를 공유하는 다른 두 프로젝트로 갔습니다(해당 프로젝트 14/15 → 13/15).
• 호출당 입력은 r2 최종 분할 기준 이름만 1,238.6 tokens, README 1,572.6 tokens로 약 334 tokens 늘었습니다. 입력 $0.042/1M으로 1,000건당 약 $0.052와 $0.066입니다.
• confidence 0.7 이상 구간은 r2 README 조건에서 73/73, 역순 76/76이 모두 맞았습니다.

제가 정한 규칙

• 활성 프로젝트 폴더마다 README에 description 1~2문장을 둡니다. 사람에게는 프로젝트 소개이고, 모델에게는 선택지의 정의입니다.
• 프로젝트 라우팅에는 이름이 아니라 이름 + description을 criteria로 넣습니다. 대가는 호출당 입력 약 334 tokens입니다.
• description끼리 주제어가 겹치지 않게 씁니다. README 조건이 새로 만든 오류 2건이 겹치는 주제어 사이에서 났습니다.

한계

• 여섯 프로젝트가 서로 뚜렷이 달라 과제가 쉬운 편입니다. 비슷한 프로젝트가 여럿일 때나 프로젝트 수가 늘 때의 성능은 모릅니다.
• 어느 프로젝트에도 속하지 않는 노트가 표본에 없어, 보류 능력은 검증되지 않았습니다.
• 작은 프로젝트(1~5건)의 재현율 차이는 말할 수 없습니다.
• 정답은 현재 폴더 위치이고 조건당 한 번 보냈으므로, 사람 판단 대비 정확도와 결정성은 모릅니다.
• confidence 0.7 이상이 모두 맞은 것은 선택지 6개짜리 이 과제의 결과입니다. 87지선다에서는 성립하지 않았습니다(사례 1).

관련 영상: 3편 「규칙표가 무너진 날」

상황

제 볼트 생태계는 메인 볼트와 위성 위키 볼트를 주저자와 이해의 깊이로 나눕니다. 메인에는 제가 직접 공부하며 자기 언어로 쓴 노트가, 위키에는 LLM이 외부 소스를 컴파일한 레퍼런스가 갑니다. 새 자료가 들어오면 어느 볼트로 보낼지 정해야 합니다. 세 가지를 물었습니다. 두 볼트의 정의를 선택지로 주면 Jev가 기존 배치를 재현하는가. 확신이 높은 답만 자동으로 받아도 되는가. 위키 안의 폴더 분류(Concept, Entity, Guide, Question)는 어떤가.

Jev에게 물은 것

• 볼트 판단: 선택지는 메인 볼트, 위키 볼트, 보류입니다. 표본은 r1 design 40, threshold 40(각각 메인 20과 위키 20), r2 최종 분할 80(메인 40과 위키 40)입니다.
• 위키 폴더 판단: 위키 페이지를 네 폴더 가운데 하나로 고릅니다. r1 분할당 20, r2 최종 분할 40입니다.
• 두 판단 모두 선택지 역순을 따로 보냈습니다. 순서 뒤집힘은 정순과 역순의 결정 불일치입니다. 다수 클래스 참고치는 볼트 판단 50%(두 볼트를 같은 수로 뽑음, r2 40/80), 위키 폴더 판단 25%(네 폴더를 같은 수로 뽑음, r2 10/40)입니다.

{
  "model": "jev-1.13.0",
  "state": {
    "title": "편집기 플러그인 단축키 정리",
    "description": "자주 쓰는 편집기 플러그인의 단축키와 설정 방법을 모은 노트",
    "tags": ["tools"],
    "body_head": "설치 후 가장 먼저 바꿀 설정은 세 가지다..."
  },
  "questions": {
    "vault": {
      "type": "choice",
      "instructions": "이 문서가 두 지식 볼트 중 어디에 속하는지 고르라. 각 선택지 설명을 기준으로 판단하고, 근거가 부족하면 보류.",
      "criteria": {
        "메인 볼트": "직접 공부하고 경험하며 자기 언어로 쓴 개인 노트: 본인 해석, 주장, 에세이, 강의와 제품 작업과의 연결, 1인칭 관점과 개인 맥락이 드러난다.",
        "위키 볼트": "LLM이 외부 소스를 컴파일한 레퍼런스 페이지: 개념, 인물, 조직, 제품, 가이드, 연구 질문을 백과사전식으로 정리하고 출처와 관련 페이지를 교차 참조한다.",
        "보류": "근거가 부족하거나 어느 선택지에도 명확히 속하지 않음"
      }
    }
  }
}

state는 합성 예시이고, criteria는 실제로 보낸 두 볼트 정의의 요지입니다. 이 합성 노트가 바로 두 정의에 모두 걸치는 유형입니다.

결과

메인 대 위키 판단의 결과입니다.

• r2 최종 분할의 출처별 정순 정확도는 메인 25/40(62.5%), 위키 26/40(65.0%)입니다. 오류 방향은 위키 → 메인 11, 메인 → 위키 11, 보류 7로 대칭입니다.
• 짝 비교(정순만 맞힌 수 b, 역순만 맞힌 수 c): r1 design b4/c0(p 0.125), threshold b3/c2(p 1.0), r2 최종 분할 b4/c1(p 0.375).
• 오류는 두 방향으로 뚜렷했습니다. 메인에 오래 쌓인 레퍼런스형 가이드 노트(플러그인 사용법이나 문법 정리처럼 외부 지식을 정리한 노트)가 높은 확신으로 위키로 갔고, 위키의 연구 질문 페이지는 1인칭 질문 형식 때문에 메인으로 갔습니다. r1에서 연구 질문 페이지 7건이 두 순서 가운데 적어도 한쪽에서 메인으로 갔습니다.

confidence 0.7 이상만 받을 때의 정답입니다.

위키 폴더 판단의 결과입니다.

제가 정한 규칙

• 메인과 위키 사이의 볼트 이동을 confidence 게이트로 자동화하지 않습니다. r1에서 40/42였던 0.7 이상 구간이 r2 최종 분할에서 37/43으로 내려갔습니다.
• 정순과 역순의 결정이 갈린 항목을 사람 골드 대기열로 씁니다. r2 최종 분할의 7건(위키 출처 5, 메인 출처 2)이 첫 대기열입니다. 판정 선택지는 드리프트(다른 볼트로 옮길 노트), 모델 오류(현재 위치가 맞음), 모호(둘 다), 보류입니다. 불일치 7건을 직접 판정하는 10분이 가장 싼 정답 데이터입니다.
• 볼트를 가르는 기준을 한 문장으로 적고, 그 문장으로 AI가 제대로 가르는지 먼저 시험합니다.

한계

• 불일치가 모델 오류인지 볼트 드리프트인지 가를 수 없습니다. 메인의 레퍼런스형 노트는 지금 규칙으로 보면 위키가 맞을 수 있습니다. 사람 골드가 0건이고, 대기열 판정은 2026-09-26 기준 비어 있습니다.
• r1 대비 r2의 하락은 항목이 달라 퇴보로 읽지 않습니다.
• 위키 폴더 판단의 높은 재현은 위키 페이지의 제목 규칙(연구 질문의 RQ- 접두 등)과 문서 형식이라는 강한 단서 덕분이고, 볼트 경계 판단 능력을 뜻하지 않습니다.
• 같은 payload를 반복하지 않아 결정성은 모릅니다.

상황

목적은 둘이었습니다. 각 모델의 논리력을 검증하는 것, 그리고 Jev로 실제 돌릴 지식 입력과 검색 실험의 설계를 확보하는 것입니다. 사례 1~4의 실험은 이 run의 보고서들이 낸 설계를 바탕으로 돌렸습니다. 질문은 셋이었습니다. 같은 사실 패킷과 같은 논리 문항을 받으면 모델마다 논리가 얼마나 다른가. 순위는 무엇이 가르는가. 보고서의 설계는 실측에서 어떻게 됐는가.

모델들에게 보낸 것

이 사례에서 질문을 받은 쪽은 Jev가 아니라 여덟 모델입니다. 모델들의 답이 Jev 실험 설계의 입력이 됐습니다.

• 로스터: Claude Opus 5.5, Claude Fable 5.1, GPT-6 Astra, GPT-6 Sol, GPT-6 Luna, Grok 4.7, Gemini 3.1 Pro, Gemini 3.8 Flash. 실행 직전(2026-09-26 02:38 KST) 모델 ID가 살아 있는지 다시 확인했습니다.
• 입력: 모두 같은 프롬프트 52,202자입니다. 사실, 맥락, 실행 가능한 자료 네 묶음(CMDS 분류, 볼트 판단, 검색, 프로젝트 라우팅), 정답 키가 있는 논리 문항 10개를 담았습니다.
• 채점: 보고서가 생기기 전에 고정한 10축, 가중치 합 100입니다. 슬롯 R1~R8로 모델명을 가리고 채점자 A, 채점자 B, 반박자, 헤드 조정 순서로 매겼습니다. 논리 블록 54점(정답 키가 있는 논리 문항 점수를 포함한 세 축), 맥락 블록 23점(CMDS 지식 시스템 적합성과 구체성 9, 아이디어 레버리지 7, 입력과 검색 설계 품질 7), 실행 블록 14점(사전 등록 실험의 실행 가능성 8, 리스크와 데이터 거버넌스 6), 품질 블록 9점입니다.

패킷의 뼈대 (합성 요약)

01 사실: Jev의 세 형식(Choice, Noul, Score), 요금, 한도
02 맥락: CMDS 87분류, 메인 볼트와 위키 볼트의 정의, 검색 도구 구성
03 실행 가능한 자료: 실험 네 묶음의 데이터 모양과 분할 규칙
04 논리 문항 10개: 정답 키가 있는 닫힌 문항
   합성 예: "후보 재현율이 90%인 검색 파이프라인에서 재선택 단계만 개선할 때
            끝단 정확도의 상한은 얼마인가? 근거를 적으라."
   합성 정답 키: 90%. 끝단 정확도 = 후보 재현율 × 후보 안에서의 선택 정확도.

결과

블록 점수는 스코어카드의 축 점수를 가중합한 값입니다. 점수는 비율이 아니어서 Wilson 구간 대신 재채점 분산 ±1.6을 기준으로 읽습니다.

• 상위 넷의 논리 차는 51.5 − 49.9 = 1.6점입니다. 총점 차 0.8과 1.4도 동률권이라 상위 셋은 한 묶음으로 읽습니다.
• A 밴드 세 편과 Astra의 맥락 차는 5.9~6.6점이고, 실행 블록은 네 편 모두 10.6~12.0입니다. Astra는 검색 영역을 두 개만 두었고, 우선순위를 검토 시간이나 맥락 토큰 절감으로 수치화하지 않았습니다. 실험 설계 축 점수는 A 밴드와 같았습니다. 같은 논리로도 "이 볼트에서 무엇을 먼저 할지"를 얼마나 구체적으로 쓰느냐가 순위를 갈랐습니다.
• 하위 세 편은 논리 결함이 실행 설계 결함으로 이어졌습니다. GPT-6 Luna는 프로젝트 라우팅 기준선이 정답을 누출했습니다. Gemini 3.1 Pro는 게이트가 경계의 동률을 통과시켰고 run 상한과 단가를 섞었습니다. Gemini 3.8 Flash는 9,054단어로 7,000단어 채점 범위를 넘겨 뒤쪽 문항과 자기검토가 채점 밖으로 밀렸고, 게이트 결함도 있었습니다.
• 정답 키가 있는 논리 문항에서 상위 네 편은 9.0~9.5를 받아 변별력이 작았습니다. 이 과제에서 논리 점수만으로 모델을 고르면 상위권을 가를 수 없습니다.
• 실행 중 사건: Grok 4.7의 첫 시도는 HTTP 500, 503, 503으로 실패했고, 같은 프롬프트의 재시도가 성공했습니다. Claude Fable 5.1은 두 시도 모두 에이전트의 자동 컨텍스트 압축이 반복되며 작업이 중단돼 본문이 없습니다. 0점이 아니라 순위 밖이고, 그래서 Claude 쪽 비교는 Opus 5.5 한 편뿐입니다. 외부 보고서 다섯 편은 첫 실행의 저장 경로 오류로 나중에 재채점됐습니다.
• 호출 기록(외부 여섯 편): 소요 시간은 135.9초(Gemini 3.8 Flash)에서 966.9초(Grok 4.7 재시도)까지, 출력은 16,011 tokens(GPT-6 Luna)에서 65,400 tokens(Grok 4.7 재시도)까지였습니다. Opus 5.5 보고서는 본문 28,732자입니다.

보고서의 설계가 실측에서 어떻게 됐는지입니다.

• 후보 재현율이 끝단 정확도의 상한이므로 고칠 층은 후보 생성이라는 논리 [Claude Opus 5.5, Grok 4.7, Gemini 3.8 Flash, GPT-6 Luna]는 그대로 성립했습니다. 141/156 × 132/141 = 132/156이었고, 한국어 음절 BM25 수리로 후보에 새로 들어온 4단위가 모두 정답이 됐습니다(사례 2).
• type 규칙표 기준선을 반드시 돌리고 그쪽이 나으면 운영안으로 쓰라는 설계 [Claude Opus 5.5]는 r2에서 옳게 작동했습니다(101/120). 그러나 그 규칙표를 앞세운 캐스케이드는 한 번도 쓰지 않은 폴더에서 Jev 단독보다 낮았습니다(20/65 대 28/65, 사례 1).
• 이름만 대 README description 비교는 공유 패킷이 던진 질문이었고, 실측에서 오류 11건이 2건으로 줄었습니다(사례 3).

제가 정한 규칙

• 모델 비교는 같은 패킷, 블라인드 슬롯, 정답 키가 있는 논리 문항, 그리고 내 시스템 맥락을 채점하는 축으로 합니다.
• 채점 기준과 정답 키는 보고서가 나오기 전에 고정합니다.
• 채점자가 한 모델이면 그것부터 밝히고, 2점 안쪽 차이는 동률로 읽습니다.
• 실행 직전에 모델 로스터를 다시 확인합니다.
• 보고서의 설계는 채택 전에 내 데이터로 실측합니다. 논리가 닫힌 설계도 새 데이터에서의 일반화까지 보장하지 않습니다.

한계

• 모델의 일반 능력 순위가 아닙니다. 과제 하나, 패킷 하나, 채점 기준 하나입니다.
• 헤드 편향이 없다고 말할 수 없습니다. 헤드 모델이 한 편을 썼고 채점자 전원이 같은 모델입니다.
• Claude Fable 5.1의 수준은 모릅니다. 두 번 모두 본문이 없었습니다.
• 1위와 3위의 2.2점 차(89.4 − 87.2) 같은 작은 차이를 순위로 단정하지 않습니다. 두 편 모두 2위와 동률권입니다.
• 일곱 편으로는 출력 길이와 점수의 관계를 말할 수 없습니다.

더 보기: 여덟 모델 논리검증 전체 기록, 관련 영상 4편 「여덟 모델, 같은 문제」