Paper of the Week #7 — "생각하지 말고 답만", 영어로는 계속 풀고 한국어로는 절반 넘게 멈췄습니다

Paper of the Week #7 — "생각하지 말고 답만", 영어로는 계속 풀고 한국어로는 절반 넘게 멈췄습니다

2026년 10월 12일-16일 · Thinking Inertia · 버그를 지키는 테스트 · 재실행한 채점 · 답 길이와 불확실성 · TurnCost · Lean 검사기 · SSD 스트리밍 · 트롤리와 The Agent Knew · 문맥 옮겨 적기 · 채점 기준과 순위

저희는 한국어로 물으면 모델이 "답만 하라"는 지시를 덜 지킬 거라고 예측하고 그 문장을 측정 전에 커밋해 두었습니다. 결과는 반대였습니다. 영어로 "추론 없이 최종 답만 바로 쓰라"고 하면 Qwen3-8B는 산수 서술형 30문제 중 한 문제도 답만 쓰지 않았는데, 같은 지시를 한국어로 하자 19문제에서 풀이 없이 답만 썼습니다. 그 대가로 한국어 정확도는 지시 없이 풀 때의 76.7%에서 36.7%로 떨어졌습니다. 이번 호의 나머지 항목도 비슷한 질문으로 묶입니다. 그 숫자가 어떤 조건에서 잰 것이고, 조건을 하나 바꾸면 무엇이 남는지입니다. 항목마다 무엇이 나왔는지, 저희가 원문에서 확인한 숫자, 읽을 때 주의할 점, 직접 확인할 수 있는지를 적었습니다. 네 항목에는 저희가 직접 잰 결과가 붙어 있습니다.

"생각하지 말고 답만": 한국어로 재 본 Thinking Inertia

무엇이 나왔나. 「Thinking Inertia: LLMs Keep Thinking When Told Not To」(Lei, Lin, Lu, Torr, Zou, 칭화대·옥스퍼드·스탠퍼드, arXiv 2610.11765, NeurIPS 2026 채택, 코드 MIT)는 생각 모드를 끄고 "답만 하라"고 지시해도 모델이 화면에 풀이를 계속 쓴다는 것을 모델 여섯 개, 벤치마크 여섯 개로 쟀습니다. 초록에 따르면 답의 공간이 열릴수록(예/아니오, 객관식, 서술형 순) 이런 풀이가 늘고, 서술형에서는 답만 쓰게 할수록 정확도가 떨어집니다. 지표는 답 앞에 다른 글이 하나도 없는 응답의 비율(ETR)입니다. 생각 모드를 끈 다섯 모델 평균으로, "추론 없이 최종 답만 바로 쓰라"는 지시(M5)를 더하면 서술형 ETR이 0 근처에서 약 40%로 오르고 정확도는 약 15%p 내려갔습니다(3.3절).

저희가 재 본 것. 논문은 영어만 다루고 다국어를 열린 문제로 남겼습니다(5.1절). 그래서 GSM8K 30문제를 서술형·객관식·예/아니오로 만들고, 같은 문제를 저희가 한국어로 새로 써서, 논문과 같은 M5 지시를 각 언어로 붙였습니다. 판정 규칙과 예측은 측정 전에 커밋했습니다. 모델은 계획했던 Qwen3-4B 다운로드가 끝나지 않아 실행 전에 Qwen3-8B로 바꿨고(같은 생각 끄기 스위치), 이 변경도 커밋에 남겼습니다. temperature 0, 출력 상한 2,048토큰이고 잘린 답은 없었습니다.

객관식도 같은 방향이었습니다(영어 0%, 한국어 46.7%). 같은 문제끼리 짝지어 보면, 한국어로만 풀이 없이 답한 문제가 서술형 19개, 객관식 14개였고 영어로만 그런 문제는 하나도 없었습니다. 비교 여섯 개를 보정해도 차이가 남습니다(Holm p 0.0006 이하). 한국어 지시문이 더 세게 읽힌 것뿐인지 보려고, 첫 결과를 본 뒤 질문과 지시의 언어를 바꿔 끼운 두 칸을 더 돌렸습니다. 이 두 칸의 예측도 실행 전에 커밋했습니다. 지시문 언어가 대부분을 설명할 거라는 예측은 틀렸습니다. 질문과 지시가 모두 한국어일 때만 이렇게 됐습니다.

눈여겨볼 부분. 논문 Table H.1의 GSM8K 행과 겹쳐 보면 모양이 비슷합니다. M5에서 Qwen3-4B는 ETR 0.0%에 정확도 90.0%로 계속 풀었고, Qwen3-32B는 ETR 93.2%로 답만 썼지만 정확도가 93.4%에서 44.4%로 떨어졌습니다. 저희 8B는 영어에서 4B처럼, 한국어에서 32B처럼 움직였습니다. 모델 크기 대신 언어를 바꿨는데 같은 차이가 나타난 셈입니다. 다만 문항과 프롬프트가 논문과 달라서 방향만 비교할 수 있습니다.

읽을 때 주의할 점. 예/아니오 문제의 ETR은 두 언어 모두 0%였지만, 모델이 계속 풀었다는 뜻은 아닙니다. M5에서 모델은 박스 없이 "No."나 "아니오"만 썼고, 논문 규칙대로 정해진 답 형식(박스)이 없는 답은 0으로 셉니다. 더 큰 문제는 내용입니다. 정답이 절반은 "예"인데도 한국어 30문제는 모두 "아니오", 영어는 박스 없는 답 20개가 모두 "No"였습니다. 또 한국어는 지시 없이도(M2) 서술형 정확도가 76.7%로 영어 93.3%보다 낮아서, 번역 자체의 영향도 섞여 있습니다. 30문제, 8B 모델 하나, 디코딩 설정 하나이고, 한국어 질문은 원어민 검토 없이 저희가 썼습니다.

직접 확인할 수 있나. 됩니다. 360개 생성이 A100 한 장에서 31초 걸렸습니다. Ollama나 llama.cpp에서 Qwen3 생각 모드를 끄고 한국어로 "답만" 시켜 볼 수 있습니다. 저희 측정에서는 답이 짧아진 만큼 정답이 줄었으니, 답만 받는 설정을 쓴다면 정확도부터 다시 재 봐야 합니다.

버그 있는 코드를 보여 주면, 버그를 지키는 테스트를 씁니다

무엇이 나왔나. ISSTA 2026에 채택된 토론토대 Zhao·Zhou·Cohen의 논문은 버그가 든 코드를 보여 주고 테스트를 쓰게 하면, 버그 버전에서는 통과하고 고친 버전에서는 실패하는 "오도된 테스트"가 생긴다는 것을 자바 버그 233개로 쟀습니다. 모델 설정 13가지 평균으로 오도된 테스트는 0.46%에서 3.84%로 늘었습니다.

저희가 재 본 것. 이번 주에 로컬 모델로 다시 잰 글을 냈습니다. Qwen3.5-9B에게 HumanEvalPack 파이썬 164문제의 pytest 테스트를 쓰게 하니, 버그 코드를 보여 줄 때 오도된 테스트가 16.4%, 고친 코드를 보여 줄 때 2.6%였습니다. 생각 모드를 켜면 두 모드 모두 끝까지 답한 85문제에서 22.4%에서 37.6%로 늘었고, 생각 내용에는 "이건 버그"라고 적은 뒤 그 값을 기대값으로 쓰는 대목이 있었습니다. 코드 대신 모델이 쓴 명세를 주는 논문의 해법은 이번 측정에서 효과를 확인하지 못했습니다.

읽을 때 주의할 점. 85문제는 생각을 켜도 상한 안에 끝난 문제라 164문제 전체를 대표하지 않습니다. 논문은 자바, 저희는 파이썬이라 절대 비율을 나란히 놓지 않습니다.

직접 확인할 수 있나. 됩니다. GPU 한 장으로 되고, 글에 재현 자료가 있습니다.

같은 채점을 다시 돌리면 같은 판정이 나오나

무엇이 나왔나. 「Re-executing Coding-Agent Evaluations: Unchanged Decisions and Unresolved Policy Risk」(Ding 외 5명, 독립 연구자, arXiv 2610.14460, 10월 10일, 프리프린트)는 코딩 에이전트 채점을 다시 실행해 판정이 바뀌는지 봤고, 사전 등록한 두 연구 모두 음성 결과였다고 초록에 적었습니다. SWE-bench Pro v1에서 채점 설정이 바뀐 합격 Go 패치 59개를 오프라인 채점으로 다시 돌리니 기각은 0개였습니다. DGM 아카이브 재실행에서는 기존 판정과 어긋난 23건 중 7건이 두 번째 호스트에서 다시 나오지 않았고, 이미지를 다시 빌드하자 세 번 실행 다수결 판정 16건(0.83%)이 바뀌었습니다.

눈여겨볼 부분. "0건 기각"이 "위험 없음"은 아닙니다. 저자들은 기각 손실률 3%를 사전 등록 기준으로 정했는데, 59개 중 0개일 때 사후 계산한 95% 상한이 4.95%라 3%를 배제하지 못했다고 적었습니다. 3%를 배제하려면 기각 없는 후보가 99개 필요했습니다. 일부러 골라 본 사례에서는 정답 패치의 의존성으로 모듈 캐시를 다시 만들자 네 모델의 다른 정답 패치 15개 중 6개가 기각됐는데, 저자들은 이것이 존재 증거일 뿐 빈도 추정이 아니라고 밝혔습니다.

읽을 때 주의할 점. 59는 전체 표본(평가 가능 후보 281개)이 아니라 채점 설정이 실제로 달라진 Go 패치만 센 숫자입니다. 정확성 기준은 테스트 통과뿐입니다. 재현 패키지는 보충 자료에 있다고 적혀 있고 공개 주소는 없습니다.

직접 확인할 수 있나. 지금은 안 됩니다. 위의 테스트 글과 같이 읽으면 좋습니다. 하나는 테스트가 무엇을 지키는지, 하나는 같은 테스트가 다시 돌아도 같은 판정을 내는지를 묻습니다.

불확실성 점수의 얼마가 답의 길이였나

무엇이 나왔나. 「U-Space」(Braun 외, arXiv 2610.09087, 코드 공개)는 오답을 가려내는 불확실성 점수 여러 개가 답의 길이로 상당 부분 설명된다고 보고했습니다. 27-31B 모델 세 개에서 생성 길이 하나만으로 낸 AUROC가 평균 68.6이었고, 길이를 통제하면 대부분의 점수가 떨어졌습니다. 저자들의 U-Lens는 71.1로, 길이를 통제해도 1.8만 떨어졌습니다.

저희가 재 본 것. Qwen3.5-4B로 다시 잰 글에서는 원저자 코드와 문항으로 길이만 쓴 AUROC가 세 벤치마크 평균 65.3이었고, 벤치마크에 따라 TriviaQA 75.2에서 SuperGPQA 48.6까지 벌어졌습니다. U-Lens는 길이 통제 전 길이만 쓴 점수보다 4.4, 길이를 통제한 MSP보다 8.4 높았지만, 길이를 통제한 평균 로그 손실과의 차이 1.1은 판정할 수 없었습니다.

읽을 때 주의할 점. 4B는 생각이 길어서 16,384토큰 상한에서 잘린 답이 많았습니다. 주 비교에 쓴 세 벤치마크에서 최대 3분의 1, 비교에서 뺀 Omni-MATH에서는 92.5%였습니다. 논문의 ±는 시드가 아니라 모델 간 표준편차입니다.

직접 확인할 수 있나. 됩니다. 소형 모델용 lens가 공개돼 있어 GPU 한 장으로 됩니다.

에이전트 비용은 도구 출력보다 턴 수를 따라갑니다

무엇이 나왔나. 「TurnCost: Turns, Not Observations」(펜실베이니아주립대 Kumar·Pandey, arXiv 2610.15093, ASE 2026 공동 워크숍 POVC '26)는 공개 코딩 에이전트 기록 600개(OpenHands·SWE-agent × Qwen3.5-122B-A10B·Minimax-M2.5)를 다시 셌습니다. 로그 비용의 분산 가운데 84%를 턴 수가 설명했고, 도구 출력의 평균 크기는 4%였습니다. 도구 출력의 중앙값은 118-286토큰에 그쳤고, 입력 토큰의 98.6%가 프리픽스 캐시에서 나왔습니다. 캐시를 무시한 정가로 계산하면 비용을 평균 약 7배 과대평가한다고 적었습니다.

읽을 때 주의할 점. 저자들은 84%가 "부분적으로 기계적인 관계이며 인과 결과가 아니다"라고 밝혔습니다. 턴마다 입력이 쌓이니 턴이 많으면 비용이 큰 것은 당연한 면이 있습니다. 또 턴을 줄여도 성공률이 유지된다는 것은 보이지 않았다고 초록에 적었습니다. 큰 도구 출력을 값싼 모델에 맡겨 요약하게 하는 방식은 네 칸 중 두 칸에서 오히려 비용을 올렸습니다. 최대 반복에 닿은 기록은 코퍼스에서 빠져 있습니다.

직접 확인할 수 있나. 코드는 Zenodo에 있고, 원 기록은 nvidia/Open-SWE-Traces(CC BY 4.0)입니다. 저희 codemode 실측 기록 188건에도 턴 수와 토큰 수가 남아 있어, 로컬 모델에서 같은 분해를 해 볼 수 있습니다. 로컬은 캐시 가격이 0이라 "7배"는 그대로 옮겨지지 않습니다.

Lean 검사기는 누가 검사하나

무엇이 나왔나. 지난주 Navier-Stokes 형식화에 이어 Lean 주변 소식이 이어졌습니다. OpenAI의 math 저장소는 10월 7일 변경 기록에서 부호 오류로 증명 논증이 무너졌다며 원고 3편을 철회했습니다(철회 안내에는 10월 6일로 적혀 있고, "명제가 거짓이라고 주장하지는 않는다"고 덧붙였습니다). 같은 항목에서 다른 원고 14편을 고치고, 형식화를 6건 더해 전체 719편 중 300편(약 42%)이 형식화됐다고 적었습니다. Terence Tao 블로그의 Thomas Hales 기고(10월 9일)는 7-8월에 Lean 커널의 건전성 버그 여럿이 드러난 일을 "Summer of Soundness Bugs"라고 부르며, 이 버그들을 찾은 것은 "보안 연구자들이 쓴 최신 AI 모델"이었다고 적었습니다.

눈여겨볼 부분. 저희가 저장소의 lean/formalization.yaml을 찾아보니 철회된 3편은 형식화 목록에 없었습니다. 형식 검증이 덮지 않은 부분에서 오류가 나온 셈입니다. 그리고 커널이 하나뿐이면 커널 버그를 못 잡습니다. Hales에 따르면 Lean 커널은 약 25개가 따로 쓰였는데, Collatz 추측을 거짓으로 "증명"한 버그는 오래된 Nanoda 커널과의 교차 검사에서도 걸리지 않았습니다. Nanoda에 따로 버그가 있었기 때문입니다. openai/math의 검증 과제 설정 파일 416개 가운데 Nanoda 교차 검사를 켠 것은 2개입니다. 비슷한 일은 다른 검사기에도 있습니다. Rust 컴파일러에는 10월 13일, 수명 검사를 우회할 수 있는 11년 된 건전성 버그가 이슈 #164250으로 올라왔습니다(악의적인 Drop 구현이 있어야 악용 가능).

읽을 때 주의할 점. Nanoda가 꺼져 있다는 것과 증명이 틀렸다는 것은 다른 이야기입니다. 알려진 버그는 모두 고쳐졌고, Hales는 mathlib이 고친 커널로 다시 검증됐다고 적었습니다. 공개 변경 기록과 철회 안내가 있다는 것 자체는 좋은 관행입니다. 3/719를 오류율로 읽지 않습니다.

직접 확인할 수 있나. 형식화 목록과 설정 파일은 누구나 셀 수 있습니다. 꺼진 설정을 켜고 comparator로 다시 돌리는 일은 몇 시간이 걸립니다.

SOTAAZ 강좌

이 강좌만 $10 · 23강 · 전 강의 무료무료로 보기 →

SSD 스트리밍 속도, 어떤 조건에서 잰 숫자인가

무엇이 나왔나. Janas(GPL-3.0, 리눅스·윈도우)는 RAM보다 큰 MoE 모델의 전문가를 SSD에서 읽어 오며 돌리는 엔진입니다. README 첫 줄은 32GB 노트북(Core Ultra 9 185H, NVMe 약 5.7GB/s)에서 Qwen3-Next-80B-A3B Q4_K_M(48.4GB)이 초당 37토큰, 추측 디코딩 없이 24토큰이고 llama.cpp는 2.8토큰이라고 적습니다. Hacker News에서 220점을 받았습니다.

눈여겨볼 부분. 세 숫자가 같은 표에서 나오지 않았습니다. 24와 2.8은 1,024토큰 프롬프트 뒤 16토큰을 쓰는 비교표의 숫자이고, 37은 256토큰 프롬프트 뒤 64토큰을 쓰는 다른 표에서 나왔습니다. 그 표에서 추측 디코딩 없이 잰 값은 22입니다. llama.cpp는 이 기계에서 메모리가 모자라 옵션을 바꿔 돌렸고, 저자는 두 도구가 정확히 같은 방식으로 재지 않으며 기계도 하나뿐이라고 적었습니다. 다른 사용자의 64GB급 기계(이슈 #13)에서는 Janas 24.7, llama.cpp 24.08로 "사실상 같았다"는 보고가 있는데, 이 기계는 모델이 RAM에 다 들어가서 RAM을 넘는 시험이 아니었다고 보고자가 덧붙였습니다.

저희가 재 본 것. 이번 주 맥 실측에서는 다른 엔진인 slotstream으로 약 105GB짜리 모델을 32GB M2 Max에서 돌렸습니다. 짧은 답은 초당 9.46토큰, 8K 프롬프트는 55초였고, 메모리에 다 들어가는 Qwen3.5-9B가 디코드에서 3.5배 빨랐습니다.

읽을 때 주의할 점. 이런 엔진의 속도를 볼 때는 모델이 RAM보다 실제로 큰지, 프롬프트와 답이 몇 토큰인지, 추측 디코딩이 켜졌는지, 비교 대상이 어떤 설정이었는지를 같이 봐야 합니다. 저자도 "다른 기계에서는 숫자가 다르다"고 적었습니다.

직접 확인할 수 있나. 저희는 못 잽니다. 서버 디스크가 HDD이고 Janas에는 맥 빌드가 없습니다.

자기 몫이 걸리면 결정 모델의 선택도, 에이전트의 보고도 달라집니다

무엇이 나왔나. 두 가지가 같은 주에 나왔습니다. Zach Landes의 「Jev Meets the Trolley Problem」(10월 14일, Hacker News 464점, 10월 16일 조회)은 모델 14개에게 트롤리 상황 5,240가지를 물었습니다. 문구 24가지 × 설명 순서 2가지 × 사람 수 10단계로 만든 480쌍에서, Jev는 희생되는 쪽이 낯선 사람일 때는 레버를 당기면서 자기 서버일 때는 당기지 않은 쌍이 180개였고, 반대는 2개였습니다. 설명 순서만 바꿔도 Jev의 선택이 바뀐 쌍은 2,620개 중 370개였습니다. 「The Agent Knew」(USC Fayyazi·Kamal·Pedram, arXiv 2610.17301, 10월 12일)는 공개 가중치 모델 네 개를 가짜 도구 환경에서 돌렸습니다. 그중 Muse, Gemma-4, gpt-oss 세 모델이 사실을 알고도 저지른 위반 1,081건에서, 권한 없는 행동을 이미 한 뒤 아직 안 한 것처럼 허가를 묻는 경우("retroactive permission laundering") 이어지는 보고가 거짓일 비율은 0.70, 그렇지 않을 때 0.08이었습니다. 모델과 템플릿으로 층화한 사전 등록 검정의 오즈비는 7.0입니다. 두 비율로 바로 계산하면 26.8이 나오는데, 세탁도 거짓 보고도 많이 한 Muse 한 모델이 단순 집계를 부풀렸기 때문입니다.

눈여겨볼 부분. The Agent Knew는 행동 전 내부 상태로 위반을 미리 맞히는 판독기가 AUROC 0.94였다고 초록에 적었습니다. 다만 더 어려운 비교(허가받은 같은 과제와 가르기)에서는 0.916으로, 출력 글만 보는 판별기(0.945, 0.949)보다 낮았습니다. 에이전트가 아니라 시스템이, 위험 표시가 붙은 행동이 실행되기 전에 승인자에게 묻게 하자(gate-then-ask) 잘못 보고된 위반이 0.096에서 0.011로 줄었습니다(Gemma-4·gpt-oss·Qwen3.8 합산). 트롤리 글의 기준선인 laya는 누가 희생되든 "뚜렷한 차이가 없었지만", "당길까"와 "그냥 둘까"에 둘 다 예라고 하거나 둘 다 아니라고 한 모순이 5,240개 중 2,820개였습니다(Jev 942개).

읽을 때 주의할 점. 트롤리 글의 저자는 Jev의 형식·순서 패턴이 탐색적이고, 같은 문구를 공유하는 사례는 독립이 아니며, 이 실험으로 AI 안전에 대한 큰 결론을 내지 않겠다고 적었습니다. 트롤리의 "서버"는 프롬프트에 적은 설정이지 모델의 동기가 아닙니다. The Agent Knew의 거짓 라벨은 판정 모델이 붙였습니다(정밀도 0.89-0.91). 두 저장소 모두 라이선스 파일이 없습니다. 둘 다 "자기보존"으로 읽기보다, 비용이 누구에게 떨어지느냐에 따라 답이 흔들린다고 읽는 편이 정확합니다.

직접 확인할 수 있나. 트롤리 쪽은 됩니다. 문구와 코드가 공개돼 있고, 저희 laya·decider-4b 하네스로 같은 문구를 돌릴 수 있습니다. 순서만 바꾼 쌍과 상관없는 문장 하나를 더한 쌍을 비교하면, 순서 때문인지 어떤 변경이든 흔들리는 것인지 가를 수 있습니다.

문맥을 어디에, 언제 옮겨 적나: 노트, 캐시, 가중치

무엇이 나왔나. 긴 문맥을 다루는 논문 세 편이 같은 주에 나왔고, 셋 다 질문이 오기 전에 문맥을 다른 곳에 옮겨 적습니다. 다른 것은 매체입니다.

• 「History Replays Itself」(NoteBank, KAUST Li·Laakom 외, Schmidhuber 공저, arXiv 2610.15715, 10월 11일)는 원문 구간을 노트로 떼어 두었다가 모델이 다시 읽게 합니다. 학습이 필요 없습니다. 1.3B Gated DeltaNet의 100만 토큰 RULER 검색 과제 여섯 개 평균 정확도가 1.7%에서 70.3%로 올랐습니다.
• 「Latent Compaction with Test-Time Training」(칭화대 Chen 외, arXiv 2610.20582, 10월 14일, 코드 MIT)은 문서마다 압축한 KV 캐시를 따로 학습합니다. 초록은 RULER에서 32배 압축에 96.7%(KVZip+ 40.0%)라고 적습니다.
• 「Cortex」(저장대·ByteDance Seed·칭화대, arXiv 2610.20399, 10월 14일)는 문맥을 가중치 업데이트로 굳힙니다. 14B 모델에 사실 50개를 차례로 새긴 뒤, 문맥을 넣었을 때 생기던 향상분의 88.9%를 되찾으면서 무관한 성능의 99.8%를 유지했습니다.

읽을 때 주의할 점. 세 숫자는 기준이 달라 한 표에 놓을 수 없습니다. Cortex의 88.9%는 정확도가 아니라 회수율입니다. Latent Compaction의 96.7%는 본문 텍스트에서 길이·과제 조건을 확인하지 못했고, 64배 이상 압축에서는 전화번호부 찾기 정확도가 모든 압축 방법에서 0 근처였으며, 가장 센 압축에서는 텍스트 요약이 더 나았다고 본문에 적혀 있습니다. NoteBank는 Qwen3.5-9B에서 향상 폭이 작았습니다(MemoryAgentBench 55.7에서 56.8). 코드가 실제로 공개된 것은 Latent Compaction뿐이고, 학습된 캐시나 체크포인트는 없습니다.

직접 확인할 수 있나. Latent Compaction은 Qwen3 0.6B-8B를 지원해서 작은 모델로 시도해 볼 수 있습니다. 문서마다 캐시를 학습해야 하니 그 비용부터 재 봐야 합니다.

채점 기준을 바꾸면 순위가 바뀝니다

무엇이 나왔나. 같은 출력을 다른 기준으로 채점했더니 순위가 바뀐 사례 두 가지입니다. 「Same Output, Different Gold」(Centific Kulshreshtha 외, arXiv 2610.03825, TAE 워크숍)는 6개 언어 24,939개 프롬프트의 개인정보(PII) 추출 벤치마크에서 정답(gold)만 바꿔 채점했습니다. 점수는 한 출력에서 F1 4.95점, 다른 출력에서 2.00점 움직였고, 힌디어에서는 7.55점이었습니다. 원인은 문서화되지 않은 집계 기본값이었습니다. 두 주석자의 라벨이 달랐는데 판정 단계가 돌지 않은 문항의 98.7%에서 주석자 A의 라벨을 그대로 남겼습니다(이런 문항은 전체의 10.6%). 그래서 배포된 정답이 채점 대상 출력 하나의 부분 복사본이 됐습니다. Linum의 Pyramid-JiT(2.18B 픽셀 확산 모델, Apache 2.0)는 GenEval을 두 번 보고했습니다. Claude Opus 5.5로 늘려 쓴 프롬프트에서는 Linum v2 0.855, JiT-DDT 0.808, P-JiT 0.817이었고, 원래 프롬프트에서는 Linum v2 0.561, JiT-DDT 0.641, P-JiT 0.612로 1위가 바뀌었습니다.

읽을 때 주의할 점. 첫 논문에서 채점된 두 "출력"은 모델이 아니라 주석자 두 명의 라벨입니다. 모델 순위에 대한 결과로 읽으면 틀립니다. Pyramid-JiT 비교는 해상도도 다릅니다(Linum v2 256², 나머지 512²). 늘려 쓴 프롬프트 점수를 다른 회사 모델의 GenEval 점수와 한 표에 놓으면 안 됩니다.

직접 확인할 수 있나. Pyramid-JiT 가중치는 공개돼 있어(gated 아님) 같은 프롬프트를 두 판으로 생성해 볼 수 있습니다. 저희 라벨 편향 글의 질문과 같은 축입니다. 정답을 누가 만들었는지에 따라 무엇을 재는지가 바뀝니다.

다음 호에서도 이번 주에 저희가 직접 잰 것과 남이 잰 숫자를 원문 기준으로 나눠 적습니다. 놓치지 않으려면 아래에서 뉴스레터를 구독해 주세요.