실습 키트와 판단 영수증 뷰어

Kit v2요청 파일 6개

공개 전에 이 요청 파일 6개를 실행해 보지는 않았으므로, 응답값은 직접 확인해 주세요.

• README.txt사용법: 웹 Playground와 터미널 curl
• s1-cmds-routing.json입력, 정의를 붙인 서브카테고리 분류 (87개 중 8개 발췌)
• s2-vault-routing.json입력, 개인 볼트 대 위키 볼트
• s3-project-routing-l1-l2.json입력, 프로젝트 이름만(L1) 대 이름 + README 요약(L2)
• s4-retrieval-choice.json검색, 후보 8개 중 하나 고르기
• s5-retrieval-noul-keepset.json검색, 후보마다 예/아니오로 유지 집합 만들기
• s6-reverse-order-reask.json입력, 선택지 순서를 뒤집어 다시 묻기

Viewer판단 영수증 뷰어

호출 기록(JSONL)을 호출별 영수증으로 펼쳐 보내는 payload, 두 순서의 확률, 제안과 보류의 규칙을 보여 주고, 사람의 수락과 수정을 따로 내보내는 단일 HTML 도구입니다. 연 파일은 브라우저 안에서만 읽습니다.

Scenarios시나리오 여섯 개

근거 수치는 2026-09-26 r1(jev-1.13.0, 1,557회 호출, 전부 HTTP 200)의 두 분할(설계, 임계값) 값이고, 볼트에 이미 있던 메타데이터를 얼마나 재현했는지입니다. 숫자가 두 개 나란히 있으면 두 분할의 값입니다.

S1 입력: 정의를 붙인 서브카테고리 분류

87개 중 8개를 뽑아 선택지마다 뜻을 적었습니다. state는 지식관리를 주제로 뉴스레터에 싣기 위해 쓴 1인칭 원고라서, 주제(601 Knowledge Management), 1인칭 해석(220 Personal Insights), 발행 형식(802 Articles)이 경쟁합니다. 802 설명에는 "주제가 무엇이든 발행 형식의 원고면 여기"라는 정책을 직접 적었습니다. answers.cmds.probabilities에서 세 선택지가 확률을 어떻게 나누는지, "보류"에 확률이 가는지 보세요.

r1에서 87개 이름만 준 조건은 45.1%(41/91), 이름 + 정의는 49.5%(45/91)였고, 발행 원고가 정답인 25건 중 이름만으로 맞힌 것은 1건, 13건은 지식관리 주제 분류로 갔습니다. 이 형식 대 주제 충돌이 r2에서 형식 우선 지시와 정의로 91/120까지 올라간 자리입니다. 802 설명의 끝 문장을 지우거나 모든 설명을 null로 바꿔 다시 보내 보세요.

S2 입력: 개인 볼트 대 위키 볼트

내가 직접 쓴 노트와 외부 자료를 정리한 레퍼런스를 가르는 판단입니다. state는 일부러 경계에 두었습니다. 형식은 정규식 패턴 모음이라는 레퍼런스인데 "나는 ②와 ④를 가장 먼저 쓴다" 같은 1인칭 습관이 한 줄 섞여 있습니다. answers.vault.probabilities가 한쪽으로 몰리는지 보세요.

r1 정확도는 80.0%(32/40), 75.0%(30/40)였고, 순서를 뒤집으면 결정이 바뀐 비율은 4/40, 5/40이었습니다. 선택지가 두 개인 이 과제에서는 confidence 0.7 이상 구간이 19/19, 21/23 맞았습니다. 다만 r2 최종에서는 51/80으로 내려가 저는 이 판단을 명령으로 만들지 않았습니다. 본문의 1인칭 문장을 지우거나 두세 문장 더 넣어 확률이 옮겨 가는지 보세요.

S3 입력: 프로젝트 이름만(L1) 대 이름 + README 요약(L2)

한 요청에 질문 두 개를 넣었습니다. project_names_only는 설명이 null이고, project_with_readme는 README 한 줄 요약을 설명으로 줍니다. 가상 프로젝트 6개 중 둘(프로젝트 등대, 프로젝트 소금)은 이름만으로는 내용을 알 수 없는 코드명이고, state는 제목이 "메모 03"뿐인 도구 비교 메모입니다. 두 질문의 1위가 같은지, L1에서 "보류"나 다른 프로젝트로 가는지 보세요.

r1에서 이름만은 90.0%(27/30), 96.7%(29/30), 이름 + 요약은 30/30, 30/30이었고, 호출당 입력은 1,261에서 1,595 tokens로 늘었습니다. 순서를 뒤집어 결정이 바뀐 것은 120쌍 중 0건이었습니다. 비슷한 프로젝트를 하나 더 넣거나 어느 프로젝트에도 맞지 않는 메모로 바꿔 보류가 나오는지 보세요. r1이 재지 못한 부분입니다.

S4 검색: 후보 8개 중 하나 고르기

검색 도구가 가져온 후보를 Jev가 다시 고르는 재선택입니다. 선택지 설명은 각 후보 노트의 요약이고, 찾는 노트는 목록 4번째에 두었으며, 서식 노트와 용어 노트처럼 가까운 형제 후보도 넣었습니다. answers.find.choice가 4번째 후보인지, 형제 후보와 "해당 없음"에 확률이 얼마나 가는지 보세요.

r1에서 검색 1위만 쓰면 33.3%(8/24), 39.3%(11/28), Jev가 고르면 83.3%(20/24), 82.1%(23/28)였습니다. 찾는 노트가 후보 안에 있을 때 Jev가 그 노트를 고른 비율은 95.2%(20/21), 92.0%(23/25)였고, 없을 때 "해당 없음"을 고른 것은 6건 중 3건이었습니다. 찾는 노트를 criteria에서 지우고 다시 보내 보세요. 가장 덜 측정된 행동입니다. 이 질의는 회의 내용을 다루므로 제 retrieve 명령은 개인정보 규칙에 따라 보내지 않습니다. 가상 문장이라 원시 API 연습용으로만 둡니다.

S5 검색: 후보별 Noul로 유지 집합 만들기

하나만 고르지 않고 "이 후보가 찾는 바로 그 노트인가"를 후보마다 따로 묻습니다. S4와 같은 질의와 후보 8개를 질문 8개(c01~c08)로 담았고, 질문 이름은 모델에 전달되지 않으므로 후보 제목과 요약을 지시문 안에 넣었습니다. 각 noul 값 중 몇 개가 0.5를, 몇 개가 0.3을 넘는지 보세요.

r1에서 0.5를 넘는 후보만 남기면 평균 1.58개, 1.18개로 줄이면서 찾는 노트를 95.2%(20/21), 96.0%(24/25) 지켰고, 0.3에서는 두 분할 모두 21/21, 25/25를 지키며 평균 2.54개, 2.14개였습니다. 검색 상위 3개를 고정으로 남기면 14/21, 20/25만 지켰습니다. r3에서 절단 0.3을 새 표본에 다시 재 보니 44/45였습니다. 찾는 노트(c04)를 빼고 보내 유지 집합이 비는지 보세요. 비면 코드는 검색 단계로 돌려보냅니다.

S6 입력: 선택지 순서를 뒤집어 다시 묻기

같은 질문을 선택지 순서만 뒤집어 한 번 더 묻고, 두 답이 다르면 사람에게 넘깁니다. cmds_order_a는 S1과 같은 순서, cmds_order_b는 역순이고 "보류"는 두 순서 모두 맨 끝입니다. state는 용어 정의(104)인데 연구 두 편의 요지가 붙어 있어 문헌 종합(210), 개념(201)과 경쟁합니다. 두 질문의 1위가 같은지, 확률 분포가 순서에 따라 얼마나 움직이는지 보세요.

r1에서 순서를 뒤집어 결정이 바뀐 비율은 12개 목록 + 정의 13.2%(12/91), 17.0%(17/100)였고, 같은 91건을 2026-09-24에 87개 이름만으로 물었을 때는 31.9%(29/91)였습니다. 선택지가 적은 과제는 훨씬 안정적이었습니다(볼트 2개 4/40, 5/40, 검색 후보 104쌍 중 1, 프로젝트 120쌍 중 0). 두 순서 확률을 평균해 결정하는 방법은 호출을 두 배로 쓰면서 정확도 이득이 없었으므로, 저는 역순 재질문을 선택지가 많은 분류를 점검하는 진단 도구로 씁니다. r1은 두 순서를 별도 요청으로 보냈고, 이 키트는 한 요청에 질문 두 개로 묶었습니다(질문은 서로 독립으로 평가됩니다).

How to해 보는 법

curl -sS -X POST https://api.typesafe.ai/v1/systemone \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d @s1-cmds-routing.json

설계와 명령은 시스템, 수치 전체는 실측 결과에 있습니다.