판단만 하는 모델을 지식 시스템 어디에 둘 것인가

01글을 쓰지 않는 모델

2026년 9월 15일 TypeSafe가 공개한 Jev는 글을 쓰지 않습니다. 문서와 기준을 넣고 "이 중 어느 것인가, 그런가, 어느 단계인가"를 물으면 Choice, Noul, Score 세 가지 형태로 값과 확률만 돌려줍니다. 학습 목표가 사람이 읽기 좋은 문장이 아니라 소프트웨어가 바로 쓸 결정과 확률입니다.

Choice

정해 둔 선택지(최대 255개) 가운데 하나와 선택지별 확률

Noul

예 또는 아니오에 대한 0~1 사이 값 하나. confidence 필드가 없습니다.

Score

순서 있는 2~10단계 가운데 어디쯤인지, 확률 가중 값

입력 100만 토큰당 $0.042이고 출력 요금은 없으며, 제가 잰 호출 지연은 중앙값 0.52초였습니다(2026-09-24, 341회). 선택지에 없는 답은 내지 않지만, 그것은 형식의 보장이지 의미가 맞다는 보장이 아닙니다.

싸고 빠르고 형식이 맞는다는 것과, 그 판단이 제 업무에서 맞는다는 것은 다른 문제입니다. 이 사이트는 그 간격을 잰 기록입니다.

02왜 지식 시스템인가

제 볼트에는 10,000+ 노트가 있고, 지식이 움직이는 순간은 두 번입니다. 들어올 때 어디에 둘지, 꺼낼 때 무엇을 먼저 읽을지. 두 순간 모두 답이 닫혀 있습니다. 87개 서브카테고리 중 하나, 검색이 찾아온 후보 중 하나입니다.

검색 엔진은 후보를 넓게 찾는 데 강하고 생성 모델은 문장을 쓰는 데 강하지만, "이 중 무엇인가"라는 닫힌 질문에 매번 부르기에는 생성 모델이 느리고 비쌉니다. 한 번에 1초가 안 걸리는 판단기라면 모든 검색과 모든 새 노트에 붙여 볼 수 있습니다. 닫힌 질문에 확률로 답하는 부품은 바로 이 자리에 맞습니다.

대신 경계를 먼저 그었습니다. 후보를 만드는 일은 검색 엔진과 코드가, 고르는 일은 Jev가, 확정과 이동은 제가 합니다. 저는 이 분업을 PROPOSE라고 부릅니다.

PROPOSE제가 이 부품에 기대하는 것은 정답을 대신 내리는 일이 아니라, 제가 확정할 후보를 좁히고 그 근거를 기록으로 남기는 일입니다.

03무엇을 쟀나

9월 24일 첫 실측에서 같은 confidence 0.7 이상 구간이 채점 재현에서는 97.4%(n=38), 87분류에서는 61.5%(n=13)로 갈렸습니다. 그래서 컷은 과제마다 새로 고르기로 하고, 9월 26일 새벽 세 라운드 3,560회 호출(입력 8,264,570 토큰, $0.3471)로 입력과 검색을 다시 쟀습니다.

라운드마다 첫 호출 전에 절차를 등록했고, 최종 시험 표본은 봉인했다가 한 번만 열었고, 결과를 보고 세운 가설은 앞 라운드가 쓰지 않은 노트로 다시 쟀습니다. 모든 조건에는 Jev를 부르지 않는 코드 기준선을 같은 항목에 붙였습니다.

가장 강한 결과는 검색입니다. 처음 보는 위키 질문 49개에서 Jev가 고른 후보는 44개가 찾던 페이지였고, 검색 목록 1위는 16개였습니다. 후보마다 "이 질문에 필요한가"를 묻고 0.3을 넘는 것만 남기자, 찾던 페이지 45개 중 44개를 지키면서 후보가 평균 17.55개에서 2.39개로 줄었습니다.

분류는 달랐습니다. 87개 칸의 이름만 주면 120건 중 24건, 칸마다 정의 한 줄과 "형식을 먼저 보라"는 지시를 붙이면 91건이었지만, 같은 조건으로 처음 보는 폴더에 가면 65건 중 28건이었습니다.

04계획에서 바뀐 것

전날 계획에서 검색 재정렬은 보류였습니다. 외부 실험의 개선 폭이 작았기 때문입니다. 제 볼트의 한국어 질문에서는 세 라운드 모두 같은 방향으로 가장 큰 차이를 냈고, 이제 가장 먼저 붙이는 자리가 됐습니다.

반대로 frontmatter의 type만 보고 분류를 정하는 규칙표는 2라운드 최종 표본에서 120건 중 101건으로 가장 좋아 보였지만, 새 폴더에서는 적용된 27건 중 1건만 맞았습니다(2026-09-26). 그래서 규칙이 먼저 끝내고 Jev가 나머지를 맡는 안을 기본값에서 뺐고, 분류는 상위 3개 제안을 제가 고르는 자리로 물렸습니다.

프로젝트 제안은 프로젝트마다 README 설명 한 줄을 넣자 80건 중 69건에서 78건으로 올라(2026-09-26), 설명을 처음부터 넣습니다.

가장 큰 개선은 Jev 밖에서 나왔습니다. 검색 색인이 한글을 음절 단위로 저장하고 있어서 "기록"으로 찾으면 0건, "기 록"으로 찾으면 2,726건이 나왔습니다.

같은 색인, 2026-09-26 07:30

질의를 음절 구문으로 바꾸자 후보에 정답이 든 비율이 55건 중 46건에서 50건으로 올랐습니다. Jev를 고치기 전에 후보를 만드는 층부터 고칩니다.

05주장하지 않는 것

모든 수치는 볼트에 이미 적힌 분류와 위치를 얼마나 재현하는지입니다. 사람이 새로 만든 정답은 아직 0건이라 사람 대비 정확도와 검토 시간 절감은 주장하지 않습니다.

찾는 노트가 후보에 없을 때 Jev가 "해당 없음"을 고른 경우는 5번 중 0번, 4번 중 0번이라(2026-09-26) 그 신호를 믿지 않고, 제안이 없거나 보류이면 원래 검색 목록을 그대로 보입니다.

질문은 생성 모델이 만든 것이고, 조건마다 한 번 실행했으며, 0.3이라는 컷은 이 과제에서 한 번 통과한 값입니다. 커뮤니티 사례의 속도와 비용 숫자도 작성자의 주장이라 제 결과와 섞지 않습니다.

다음 순서는 사람 골드입니다. 순서를 뒤집어 물었을 때 답이 갈린 7건부터 제가 판정하고, 판정에 든 시간도 함께 잴 계획입니다.

Jev는 제안하고, 실행은 코드와 사람이 합니다.

Next이어서 보기