이 시리즈는 만들고 있는 Obsidian 플러그인(공개 전)의 LLM 판단을 판단 전용 모델로 바꿀 수 있는지 재 보는 기록이다. 후보는 TypeSafe의 Jev와 OpenAI의 Decisions API다. 둘 다 정해 둔 선택지 중 하나를 고르고 확신 값을 붙여 주는데, 한 번에 0.2초 안팎이라 일반 LLM 호출보다 열 배 넘게 빠르다. 앞 글에서는 “두 노트가 같은 개념인가”라는 판단에서, 질문을 참·거짓 셋으로 나누자 Decisions API가 일반 호출로 부른 gpt-6-luna만큼 맞혔다.
이번에는 다른 판단이다. 플러그인에는 LLM이 노트 사이의 중복 문장을 지우는 단계가 있는데, 문장을 지운 뒤 남은 문장이 망가지는 일이 반복됐다. 앞 문장을 가리키던 “이 기술 체계”가 가리킬 대상을 잃거나, “또한 …”으로 시작하는 문장만 남거나, 목록의 일부만 남아 뜻이 바뀌는 식이다. 그 경위는 다른 글에 적었다. 결론은 고친 노트를 LLM에게 다시 읽혀 “이 수정 때문에 새로 생긴 문제가 있는가”를 판정하게 하자는 것이었고, gpt-6-luna로 한 판정이 꽤 잘 맞았다. 노트 하나에 3초쯤 걸린다. 이 판정도 판단 전용 모델로 0.2초에 할 수 있을까.
무엇으로 쟀나 — LLM-as-a-judge 벤치마크
플러그인 실제 테스트와 재현 실험에서 LLM이 중복을 지우며 고친 노트 134개를 모았다. 노트마다 고치기 전과 후, 그리고 바뀐 문단을 함께 넣는다. 정답은 내가 전부 읽고 정했다. 실제로 깨진 노트 20개, 애매한 노트 11개, 정상 103개다.
세 가지 방식을 비교했다.
- gpt-6-luna 일반 호출: 플러그인 설정대로 reasoning high. 판정 기준 네 가지를 풀어 쓴 프롬프트로 묻는다.
- 질문 하나: 같은 기준을 담은 “문제 없음 / 문제 있음” 선택지 질문. 앞 시리즈에서 선택지 순서에 따라 답이 쏠린 적이 있어서 두 순서로 다 물었다.
- 질문 넷으로 나눔: 가리키는 말이 대상을 잃었나, 미완결 문장이 생겼나, 뜻이 바뀌었나, 절 제목과 내용이 어긋났나를 참·거짓으로 따로 묻고, 하나라도 참이면 문제 있음으로 본다. 앞 글에서 Decisions API를 살린 방식이다.
결과 — 판단 전용 모델은 정상 노트를 네 배쯤 더 걸었다 (오탐률 비교)
| 방식 | 깨진 노트를 잡은 수 | 정상 노트를 잘못 건 수 | 한 번 걸리는 시간 |
|---|---|---|---|
| gpt-6-luna | 18/20 | 3/103 | 약 2.9초 |
| Decisions API, 질문 하나 | 15~16/20 | 12~18/103 | 약 0.25초 |
| Jev, 질문 하나 | 14~17/20 | 10~12/103 | 약 0.17초 |
| Decisions API, 질문 넷 | 19/20 | 74/103 | 약 0.26초 |
| Jev, 질문 넷 | 18/20 | 49/103 | 약 0.17초 |
질문 하나로 물으면 두 모델 모두 깨진 노트를 덜 잡고, 정상 노트는 gpt-6-luna보다 네 배쯤 더 걸었다. 걸린 노트는 고치기 전으로 되돌릴 생각이었으니, 정상 노트를 거는 건 해야 할 중복 정리를 버리는 일이다.
질문을 나누자 오히려 나빠졌다 (Decisions API predicate · Jev noul)
앞 글에서는 질문을 나눠야 Decisions API가 제대로 맞혔다. 이번에는 정반대였다. 깨진 노트는 거의 다 잡았지만 정상 노트의 절반 이상을 걸었다.
어느 질문이 문제였는지 보니 둘이었다. Decisions API는 정상 노트 103개 중 64개에서 “절 제목과 내용이 어긋났나”에, 48개에서 “뜻이 바뀌었나”에 참을 줬다. 반면 “가리키는 말이 대상을 잃었나”는 정상 노트에서 거의 0이었고, ‘이 기술 체계’, ‘the shortlist’처럼 실제로 대상을 잃은 노트에서는 1.0 가까이 나왔다. 정확한 기준으로 물은 질문은 제 역할을 했고, 느슨한 두 질문이 거의 모든 노트에 걸린 것이다.
이유는 확인하지 않은 추측이지만 짐작은 간다. 중복 문장을 지우면 절은 짧아지고 노트가 말하는 범위도 줄어든다. “제목과 내용이 어긋났나”, “뜻이 바뀌었나”를 글자 그대로 읽으면 중복을 지운 노트는 대부분 어느 정도 참이다. 내가 묻고 싶었던 건 “중복을 지운 것 말고, 그 때문에 새로 생긴 문제가 있나”였다. gpt-6-luna는 reasoning을 거치며 그 구분을 했고, 한 번에 답하는 판단 전용 모델은 질문을 적힌 대로 받았다. 앞 글에서 “같은 구체적 사건을 요약했나”를 “같은 기사냐”로 읽었던 것과 같은 모양이다.
확신으로 걸러 써도 아끼는 게 적었다 (confidence threshold)
앞 시리즈에서 쓸 만했던 구성은 “판단 전용 모델이 확신 높을 때만 그 답을 쓰고, 나머지는 gpt-6-luna에 넘기기”였다. Jev는 틀릴 때 스스로 자신 없어 하는 경향이 이번에도 그대로였다. 질문 하나로 물었을 때 틀린 답의 확신은 가장 높은 게 선택지 순서에 따라 0.74, 0.82였다. Decisions API는 한 순서에서 0.88로 틀린 답이 두 개 있었다.
문제는 확신이 높은 답 자체가 적었다는 점이다. 확신 0.8 이상만 따르면 깨진 노트를 잡은 수는 gpt-6-luna 혼자일 때와 같고 잘못 건 정상 노트는 같거나 두 개 많았지만,
판단 전용 모델이 혼자 처리한 노트는 134개 중 1529개였다. gpt-6-luna 호출을 1122% 줄이는 데 그친다. 확신
기준을 0.9로 올리면 그마저 6~15개로 줄었다.
같은 노트 정리 한 번에 고치는 노트는 몇 개뿐이고, gpt-6-luna로도 노트 하나에 3초쯤이다. 아끼는 시간에 비해 모델 하나를 더 붙이는 복잡도가 크다. 그래서 이 판정은 gpt-6-luna 하나로 하기로 했다.
남는 생각
앞 글은 “질문을 나누니 됐다”로 끝났다. 이번에 같은 방법을 다른 판단에 그대로 가져가자 정상 노트의 절반 이상을 걸었다. 앞 글에서 통한 건 “질문 나누기”라는 방법 자체가 아니라, 나눈 질문 하나하나가 내가 의도한 뜻으로만 읽히게 적혀 있었다는 점이었다. 이번에 나눈 넷 중 둘은 그렇지 않았다.
두 판단의 성격도 달랐다. “두 노트가 같은 개념인가”는 노트 전체를 보고 하는 판단이다. “고친 노트에 끊긴 문장이 생겼나”는 긴 노트 안에서 문제 문장 하나를 찾고, 그 문제가 중복 정리의 정상적인 결과인지 아닌지까지 가려야 한다. 판단 전용 모델이 앞의 판단에서 LLM만큼 했다고 해서 뒤의 판단도 그럴 거라고 기대한 건, 같은 이름의 도구니까 같은 결과가 나올 거라고 본 것이었다. 판단마다 따로 재 봐야 했다.