<div id="readability-page-1" class="page"><div data-pagefind-body="">    <blockquote>
<p><strong>2026-09-23 기준</strong> — 답은 Claude Code(Opus 5.5)와 Codex CLI(GPT-6 Sol)로 만들었고, 채점도 같은 두 모델이 했습니다. 모델명과 설정 이름은 이 날짜 기준입니다.</p>
</blockquote>
<p>두 달 전 <a href="/posts/2026/07/22/2026-07-22-search-api-blind-ab-eval/">검색 API 블라인드 평가</a>에서 에이전트의 검색 백엔드를 Perplexity로 정했습니다. 그때는 Claude Code 내장 검색이 약하다고 보고 외부 API끼리만 비교했는데, 정작 내장 검색은 같은 조건에서 비교해 본 적이 없었습니다. 그래서 Codex 내장 검색까지 넣어 세 가지를 같은 쿼리로 다시 비교했습니다.</p><p>결론은 이번에도 Perplexity였습니다. Perplexity를 붙인 답이 Claude 내장 검색을 쓴 답을 Claude judge 기준 50승 8패, GPT judge 기준 39승 19패로 이겼습니다. Codex 검색은 judge에 따라 순위가 뒤집혀서 Perplexity를 바꿀 근거가 되지 못했습니다.</p>
<p>오히려 눈에 띈 건 judge 쪽이었습니다. Codex 검색은 Claude judge에게는 꼴찌, GPT judge에게는 1위였습니다. Claude judge는 58개 중 56개에서 Claude가 쓴 답을, GPT judge는 26.5개에서 Codex 답을 1위로 골랐는데, <strong>둘 다 무작위로 골랐을 때(약 39개, 19개)보다 많습니다.</strong> 한 회사 모델로만 judge를 구성했다면 Codex 검색의 순위가 한쪽으로 기울었을 겁니다.</p>
<section><h2 id="검색-도구만-바꾼-세-가지-방식">검색 도구만 바꾼 세 가지 방식<a href="#검색-도구만-바꾼-세-가지-방식"><span data-pagefind-ignore="">#</span></a></h2><p>세 방식 모두 질문을 받으면 웹을 찾아보고 결론·근거·출처를 정리하는 리서치 에이전트이고, 프롬프트도 같습니다. 다른 건 검색 도구뿐입니다.</p>
























<table><thead><tr><th>방식</th><th>답을 쓴 모델</th><th>검색 도구</th></tr></thead><tbody><tr><td>Perplexity</td><td>Claude Opus 5.5 (<code>claude -p</code>)</td><td>Perplexity Search API(MCP) + WebFetch</td></tr><tr><td>Claude 내장</td><td>같음</td><td>내장 WebSearch + WebFetch</td></tr><tr><td>Codex 내장</td><td>GPT-6 Sol (Codex CLI)</td><td>내장 web_search(live)</td></tr></tbody></table><p>Claude Code 쪽 두 방식은 <code>--tools</code>로 쓸 수 있는 도구를 고정하고 <code>--strict-mcp-config</code>로 평소 쓰던 MCP 서버를 모두 끈 다음, Perplexity 방식에만 Perplexity MCP를 붙였습니다. Codex는 설정에 <code>web_search = "live"</code>를 넣어 실시간 검색을 쓰게 했습니다. 예전 설정 키(<code>tools.web_search = true</code>)로는 검색 요청에 <code>"external_web_access": false</code>가 찍혀 캐시 검색으로 동작했습니다.</p><p>쿼리는 7월 글과는 다른, 리서치 에이전트에 실제로 물었던 질문 50개에 상품 구매 질문 8개를 더한 58개입니다. 세 방식을 한 시간 남짓 동안 섞어서 돌렸고, Codex 4개는 사용량 한도에 걸려서 같은 날 저녁에 다시 돌렸습니다. ChatGPT 앱의 쇼핑 리서치는 Codex 검색과 별개 기능이라 비교에 넣지 않았습니다.</p></section>
<section><h2 id="claude-judge와-gpt-judge를-같은-조건으로-맞췄습니다">Claude judge와 GPT judge를 같은 조건으로 맞췄습니다<a href="#claude-judge와-gpt-judge를-같은-조건으로-맞췄습니다"><span data-pagefind-ignore="">#</span></a></h2><p>judge는 각 회사에서 답을 쓴 바로 그 모델로 정했습니다. Claude 쪽은 Opus 5.5, GPT 쪽은 GPT-6 Sol입니다. 양쪽 모두 같은 관점 셋(근거, 실행 가능성, 새 정보)으로 한 번씩, 모두 세 번 채점하게 했고 도구는 둘 다 쓰지 못하게 막았습니다. 답은 가·나·다로 익명화하고 쿼리마다 순서를 섞었습니다.</p><p>처음에는 Claude Sonnet으로 세 번, GPT-6 Sol로 한 번 채점했는데, 양쪽 조건이 달라서 지금 구성으로 다시 채점했습니다. 처음 채점에서도 결론의 방향은 같았습니다.</p><p>서식도 맞췄습니다. 드라이런을 해 보니 Codex 답만 본문에 마크다운 링크를 달고 제목 없이 시작해서, 서식만 봐도 어느 모델 답인지 티가 났거든요. 그래서 <code>결론</code>·<code>근거</code>·<code>출처</code> 구조와 출처 표기 방식을 통일한 다음 judge에게 넘겼습니다.</p></section>
<section><h2 id="perplexity가-claude-내장-검색보다-나았습니다">Perplexity가 Claude 내장 검색보다 나았습니다<a href="#perplexity가-claude-내장-검색보다-나았습니다"><span data-pagefind-ignore="">#</span></a></h2>
























<table><thead><tr><th>쿼리별 승패</th><th>Claude judge (Opus 5.5)</th><th>GPT judge (GPT-6 Sol)</th></tr></thead><tbody><tr><td>Perplexity 대 Claude 내장</td><td><strong>50승 8패</strong> (p&lt;0.001)</td><td><strong>39승 19패</strong> (p=0.012)</td></tr><tr><td>Perplexity 대 Codex 내장</td><td>56승 2패</td><td>25승 33패 (p=0.36)</td></tr><tr><td>Claude 내장 대 Codex 내장</td><td>42승 16패</td><td>13승 40패 5무</td></tr></tbody></table><p>첫 줄은 양쪽 judge가 같은 방향이고 부호검정으로도 유의합니다. 모델과 프롬프트가 같고 검색 도구만 다른 비교라, 두 달 전에 전제로 깔았던 “내장 검색이 약하다”를 이번에 처음 같은 조건에서 확인한 셈입니다. 평균 소요 시간도 Perplexity가 짧았습니다(101초 대 118초).</p><p>평가 설정이 답에 새어 나온 경우도 있었습니다. Claude 내장 검색 답 58개 중 19개에 “Perplexity MCP가 이 세션에 없어서 기본 웹 검색을 썼다”는 문장이 들어 있었습니다. 제 전역 지침에 “외부 정보는 Perplexity로 찾는다”는 규칙이 있는데 도구만 빼 버려서 생긴 일입니다. 이 문장이 있는 답과 없는 답을 나눠 봐도 Perplexity가 이기는 건 같았습니다.</p></section>
<section><h2 id="claude-judge와-gpt-judge는-codex-검색의-순위를-정반대로-매겼습니다">Claude judge와 GPT judge는 Codex 검색의 순위를 정반대로 매겼습니다<a href="#claude-judge와-gpt-judge는-codex-검색의-순위를-정반대로-매겼습니다"><span data-pagefind-ignore="">#</span></a></h2><p>Codex 답이 들어간 비교에서는 양쪽 judge의 결과가 반대였습니다. Perplexity 대 Codex 내장 검색을 Claude judge는 56승 2패로, GPT judge는 25승 33패로 채점했습니다. 같은 회사 judge끼리와 다른 회사 judge끼리 순위가 얼마나 일치했는지 계산해 보면 이렇습니다.</p>
























<table><thead><tr><th>비교</th><th>1위 일치율</th><th>두 답씩 짝지었을 때 순서 일치율</th></tr></thead><tbody><tr><td>Claude judge끼리</td><td>0.79</td><td>0.88</td></tr><tr><td>GPT judge끼리</td><td>0.67</td><td>0.79</td></tr><tr><td>Claude judge 대 GPT judge</td><td>0.41</td><td>0.56</td></tr></tbody></table><p>두 답씩 짝지어 순서를 비교하면 무작위로 매겨도 절반은 맞습니다. 같은 회사 judge끼리는 0.8 안팎으로 비슷하게 채점했지만, 회사가 다르면 0.56으로 무작위보다 조금 나은 수준이었습니다. 짝별로 보면 Perplexity 대 Claude 내장에서는 0.67로 대체로 맞았고, Codex가 낀 짝에서 0.47, 0.55로 떨어졌습니다.</p><p>1위를 누구에게 줬는지 보면 쏠림이 더 분명합니다. 세 답 중 둘이 Claude 답이라 무작위라도 Claude judge의 1위는 39개쯤 Claude 답이 되는데, 실제로는 56개였습니다. GPT judge가 Codex 답을 1위로 고른 26.5개(공동 1위는 나눠 셌습니다)도 무작위 기대치(19개쯤)보다 많습니다.</p></section><section><h2 id="자기-회사-편인지-긴-답을-좋아하는-건지">자기 회사 편인지, 긴 답을 좋아하는 건지<a href="#자기-회사-편인지-긴-답을-좋아하는-건지"><span data-pagefind-ignore="">#</span></a></h2><p>다만 이것만으로 자기 회사 편을 든다고 단정할 수는 없었습니다. Codex 답은 본문이 평균 694자로 다른 두 답(Perplexity 1,479자, Claude 내장 1,313자)의 절반 정도였고, 목록도 거의 쓰지 않았거든요.</p>
























<table><thead><tr><th>답의 특징</th><th>Claude judge</th><th>GPT judge</th></tr></thead><tbody><tr><td>본문 길이</td><td><strong>+0.67</strong></td><td>−0.16</td></tr><tr><td>출처 URL 수</td><td>+0.40</td><td>−0.04</td></tr><tr><td>목록 항목 수</td><td>+0.63</td><td>−0.21</td></tr></tbody></table><p>표의 값은 같은 쿼리 안에서 그 특징이 큰 답을 얼마나 위에 두는지를 나타낸 스피어만 상관계수의 평균입니다. Claude judge는 긴 답을 위에 두는 경향이 뚜렷했습니다. 다만 둘 다 Claude가 쓴 두 답끼리 비교하면 긴 쪽이 대부분 Perplexity 답이라, 이 부분은 길이 선호만으로 보기 어렵습니다.</p><p>Codex 답이 다른 답보다 긴 경우는 거의 없었습니다. 그래서 채점 결과만으로는 길이 선호, 자기 회사 선호, Codex 답의 실제 품질 차이를 서로 떼어낼 수 없었습니다.</p></section>
<section><h2 id="7개-쿼리를-직접-채점했습니다">7개 쿼리를 직접 채점했습니다<a href="#7개-쿼리를-직접-채점했습니다"><span data-pagefind-ignore="">#</span></a></h2><p>처음 채점에서 judge들의 1위가 엇갈렸던 쿼리 7개를 제가 블라인드로 직접 채점했습니다. 읽을 분량을 줄이려고 세 답의 결론 부분만(700자까지) 읽고 1위 하나만 골랐습니다.</p>
















<table><thead><tr><th></th><th>제 1위와 같은 쿼리 수</th></tr></thead><tbody><tr><td>Claude judge</td><td>3.5 / 7</td></tr><tr><td>GPT judge</td><td>2.5 / 7</td></tr></tbody></table><p>저는 Codex 답을 한 번도 1위로 고르지 않았습니다(Perplexity 3.5, Claude 내장 3.5, 공동 1위 1개는 양쪽에 0.5씩 나눠 셌습니다). GPT judge가 Codex 답을 1위로 올린 4개도 모두 제 선택과 달랐습니다. 이 7개만 보면 GPT judge가 Codex 답을 후하게 채점한 것으로 보입니다.</p><p>Claude judge도 저와 절반만 일치했습니다. Claude judge는 7개 모두 Perplexity 답을 1위로 골랐는데, 저는 그중 3개에서 Claude 내장 검색 답을 골랐습니다. 제 채점도 한 사람의 취향이라, 이것만으로 Codex 검색이 못하다고 말할 수는 없습니다.</p></section>
<section><h2 id="사실-확인은-judge에게-맡길-수-없었습니다">사실 확인은 judge에게 맡길 수 없었습니다<a href="#사실-확인은-judge에게-맡길-수-없었습니다"><span data-pagefind-ignore="">#</span></a></h2><p>채점 기준에는 “사실과 다르거나 지어낸 내용”을 표시하는 항목도 있었지만, 이 표시는 기준으로 쓰기 어려웠습니다. judge는 도구 없이 글만 읽고 판단했고, 오답 표시 수도 Claude judge는 522건 중 9건, GPT judge는 67건으로 일곱 배 넘게 차이가 났습니다. GPT judge가 표시한 67건 중 65건은 Claude가 쓴 답이었습니다.</p><p>그래서 사실 정확도는 따로 확인했습니다. 상품 질문 12개(새로 넣은 8개와 기존 50개 중 상품 질문 4개)의 답 36개에서 가격·판매 상태·사양 같은 주장 142개를 뽑아 당일 웹에서 대조했습니다. 대조는 Claude Opus에게 맡겼고, 어느 방식의 답인지 모르게 가·나·다 라벨만 보여 줬습니다.</p>




































<table><thead><tr><th>방식</th><th>주장</th><th>맞음</th><th>틀림</th><th>확인 불가</th><th>정확도</th></tr></thead><tbody><tr><td>Perplexity</td><td>48</td><td>46</td><td>2</td><td>0</td><td>0.96</td></tr><tr><td>Claude 내장</td><td>48</td><td>40</td><td>6</td><td>2</td><td>0.87</td></tr><tr><td>Codex 내장</td><td>46</td><td>43</td><td>2</td><td>1</td><td>0.96</td></tr></tbody></table><p>Codex 내장 검색은 답이 짧은데도 정확도가 Perplexity와 같았습니다. 다만 답이 짧아서 확인할 주장 자체가 적은 쿼리도 있었고, 세 방식의 차이는 통계적으로 유의하지 않았습니다(Fisher 검정, Perplexity 대 Claude 내장 p=0.15). 가격은 76개 중 74개가 맞아서, 얼마에 파는지 정도는 셋 중 무엇을 써도 대체로 맞게 찾아옵니다.</p></section>
<section><h2 id="이-평가의-한계">이 평가의 한계<a href="#이-평가의-한계"><span data-pagefind-ignore="">#</span></a></h2><p>Claude를 주로 쓰는 제 환경에서 진행한 평가라, Codex에 불리했을 수 있는 부분이 있습니다.</p><ul>
<li>프롬프트와 채점 기준은 Claude로만 돌렸던 이전 실험에서 정한 것을 그대로 썼고, Codex에 맞춰 다듬지 않았습니다.</li>
<li>사실 대조도 Claude Opus가 했습니다.</li>
<li>직접 채점은 저 혼자 7개 쿼리의 결론 부분만 본 것이고, 쿼리도 한국어 비중이 높은 제 실사용 질문입니다.</li>
</ul></section>
<section><h2 id="llm-judge로-모델을-비교할-때-주의할-점">LLM judge로 모델을 비교할 때 주의할 점<a href="#llm-judge로-모델을-비교할-때-주의할-점"><span data-pagefind-ignore="">#</span></a></h2><ul>
<li>judge를 한 회사 모델로만 구성하지 않습니다. 회사가 다른 judge를 같은 조건으로 섞고, 서로 얼마나 일치하는지를 결과와 같이 봅니다. 결론이 같으면 믿고, 엇갈리면 결론을 미룹니다.</li>
<li>judge끼리 엇갈린 쿼리에서 일부를 뽑아 사람이 직접 채점합니다.</li>
<li>사실 정확도는 judge 점수에 맡기지 않고 따로 대조합니다.</li>
<li>답 길이 차이가 크면 같은 길이의 요약으로 만들어 채점합니다.</li>
</ul></section>  </div></div>

Monologg Blog

2026-09-23 기준 — 답은 Claude Code(Opus 5.5)와 Codex CLI(GPT-6 Sol)로 만들었고, 채점도 같은 두 모델이 했습니다. 모델명과 설정 이름은 이 날짜 기준입니다.
두 달 전 검색 API 블라인드 평가에서 에이전트의 검색 백엔드를 Perplexity로 정했습니다. 그때는 Claude Code 내장 검색이 약하다고 보고 외부 API끼리만 비교했는데, 정작 내장 검색은 같은 조건에서 비교해 본 적이 없었습니다. 그래서 Codex 내장 검색까지 넣어 세 가지를 같은 쿼리로 다시 비교했습니다.
결론은 이번에도 Perplexity였습니다. Perplexity를 붙인 답이 Claude 내장 검색을 쓴 답을 Claude judge 기준 50승 8패, GPT judge 기준 39승 19패로 이겼습니다. Codex 검색은 judge에 따라 순위가 뒤집혀서 Perplexity를 바꿀 근거가 되지 못했습니다.
오히려 눈에 띈 건 judge 쪽이었습니다. Codex 검색은 Claude judge에게는 꼴찌, GPT judge에게는 1위였습니다. Claude judge는 58개 중 56개에서 Claude가 쓴 답을, GPT judge는 26.5개에서 Codex 답을 1위로 골랐는데, 둘 다 무작위로 골랐을 때(약 39개, 19개)보다 많습니다. 한 회사 모델로만 judge를 구성했다면 Codex 검색의 순위가 한쪽으로 기울었을 겁니다.
검색 도구만 바꾼 세 가지 방식
세 방식 모두 질문을 받으면 웹을 찾아보고 결론·근거·출처를 정리하는 리서치 에이전트이고, 프롬프트도 같습니다. 다른 건 검색 도구뿐입니다.
방식
답을 쓴 모델
검색 도구
Perplexity
Claude Opus 5.5 (claude -p)
Perplexity Search API(MCP) + WebFetch
Claude 내장
같음
내장 WebSearch + WebFetch
Codex 내장
GPT-6 Sol (Codex CLI)
내장 web_search(live)
Claude Code 쪽 두 방식은 --tools로 쓸 수 있는 도구를 고정하고 --strict-mcp-config로 평소 쓰던 MCP 서버를 모두 끈 다음, Perplexity 방식에만 Perplexity MCP를 붙였습니다. Codex는 설정에 web_search = "live"를 넣어 실시간 검색을 쓰게 했습니다. 예전 설정 키(tools.web_search = true)로는 검색 요청에 "external_web_access": false가 찍혀 캐시 검색으로 동작했습니다.
쿼리는 7월 글과는 다른, 리서치 에이전트에 실제로 물었던 질문 50개에 상품 구매 질문 8개를 더한 58개입니다. 세 방식을 한 시간 남짓 동안 섞어서 돌렸고, Codex 4개는 사용량 한도에 걸려서 같은 날 저녁에 다시 돌렸습니다. ChatGPT 앱의 쇼핑 리서치는 Codex 검색과 별개 기능이라 비교에 넣지 않았습니다.
Claude judge와 GPT judge를 같은 조건으로 맞췄습니다
judge는 각 회사에서 답을 쓴 바로 그 모델로 정했습니다. Claude 쪽은 Opus 5.5, GPT 쪽은 GPT-6 Sol입니다. 양쪽 모두 같은 관점 셋(근거, 실행 가능성, 새 정보)으로 한 번씩, 모두 세 번 채점하게 했고 도구는 둘 다 쓰지 못하게 막았습니다. 답은 가·나·다로 익명화하고 쿼리마다 순서를 섞었습니다.
처음에는 Claude Sonnet으로 세 번, GPT-6 Sol로 한 번 채점했는데, 양쪽 조건이 달라서 지금 구성으로 다시 채점했습니다. 처음 채점에서도 결론의 방향은 같았습니다.
서식도 맞췄습니다. 드라이런을 해 보니 Codex 답만 본문에 마크다운 링크를 달고 제목 없이 시작해서, 서식만 봐도 어느 모델 답인지 티가 났거든요. 그래서 결론·근거·출처 구조와 출처 표기 방식을 통일한 다음 judge에게 넘겼습니다.
Perplexity가 Claude 내장 검색보다 나았습니다
쿼리별 승패
Claude judge (Opus 5.5)
GPT judge (GPT-6 Sol)
Perplexity 대 Claude 내장
50승 8패 (p<0.001)
39승 19패 (p=0.012)
Perplexity 대 Codex 내장
56승 2패
25승 33패 (p=0.36)
Claude 내장 대 Codex 내장
42승 16패
13승 40패 5무
첫 줄은 양쪽 judge가 같은 방향이고 부호검정으로도 유의합니다. 모델과 프롬프트가 같고 검색 도구만 다른 비교라, 두 달 전에 전제로 깔았던 "내장 검색이 약하다"를 이번에 처음 같은 조건에서 확인한 셈입니다. 평균 소요 시간도 Perplexity가 짧았습니다(101초 대 118초).
평가 설정이 답에 새어 나온 경우도 있었습니다. Claude 내장 검색 답 58개 중 19개에 "Perplexity MCP가 이 세션에 없어서 기본 웹 검색을 썼다"는 문장이 들어 있었습니다. 제 전역 지침에 "외부 정보는 Perplexity로 찾는다"는 규칙이 있는데 도구만 빼 버려서 생긴 일입니다. 이 문장이 있는 답과 없는 답을 나눠 봐도 Perplexity가 이기는 건 같았습니다.
Claude judge와 GPT judge는 Codex 검색의 순위를 정반대로 매겼습니다
Codex 답이 들어간 비교에서는 양쪽 judge의 결과가 반대였습니다. Perplexity 대 Codex 내장 검색을 Claude judge는 56승 2패로, GPT judge는 25승 33패로 채점했습니다. 같은 회사 judge끼리와 다른 회사 judge끼리 순위가 얼마나 일치했는지 계산해 보면 이렇습니다.
비교
1위 일치율
두 답씩 짝지었을 때 순서 일치율
Claude judge끼리
0.79
0.88
GPT judge끼리
0.67
0.79
Claude judge 대 GPT judge
0.41
0.56
두 답씩 짝지어 순서를 비교하면 무작위로 매겨도 절반은 맞습니다. 같은 회사 judge끼리는 0.8 안팎으로 비슷하게 채점했지만, 회사가 다르면 0.56으로 무작위보다 조금 나은 수준이었습니다. 짝별로 보면 Perplexity 대 Claude 내장에서는 0.67로 대체로 맞았고, Codex가 낀 짝에서 0.47, 0.55로 떨어졌습니다.
1위를 누구에게 줬는지 보면 쏠림이 더 분명합니다. 세 답 중 둘이 Claude 답이라 무작위라도 Claude judge의 1위는 39개쯤 Claude 답이 되는데, 실제로는 56개였습니다. GPT judge가 Codex 답을 1위로 고른 26.5개(공동 1위는 나눠 셌습니다)도 무작위 기대치(19개쯤)보다 많습니다.
자기 회사 편인지, 긴 답을 좋아하는 건지
다만 이것만으로 자기 회사 편을 든다고 단정할 수는 없었습니다. Codex 답은 본문이 평균 694자로 다른 두 답(Perplexity 1,479자, Claude 내장 1,313자)의 절반 정도였고, 목록도 거의 쓰지 않았거든요.
답의 특징
Claude judge
GPT judge
본문 길이
+0.67
−0.16
출처 URL 수
+0.40
−0.04
목록 항목 수
+0.63
−0.21
표의 값은 같은 쿼리 안에서 그 특징이 큰 답을 얼마나 위에 두는지를 나타낸 스피어만 상관계수의 평균입니다. Claude judge는 긴 답을 위에 두는 경향이 뚜렷했습니다. 다만 둘 다 Claude가 쓴 두 답끼리 비교하면 긴 쪽이 대부분 Perplexity 답이라, 이 부분은 길이 선호만으로 보기 어렵습니다.
Codex 답이 다른 답보다 긴 경우는 거의 없었습니다. 그래서 채점 결과만으로는 길이 선호, 자기 회사 선호, Codex 답의 실제 품질 차이를 서로 떼어낼 수 없었습니다.
7개 쿼리를 직접 채점했습니다
처음 채점에서 judge들의 1위가 엇갈렸던 쿼리 7개를 제가 블라인드로 직접 채점했습니다. 읽을 분량을 줄이려고 세 답의 결론 부분만(700자까지) 읽고 1위 하나만 골랐습니다.
제 1위와 같은 쿼리 수
Claude judge
3.5 / 7
GPT judge
2.5 / 7
저는 Codex 답을 한 번도 1위로 고르지 않았습니다(Perplexity 3.5, Claude 내장 3.5, 공동 1위 1개는 양쪽에 0.5씩 나눠 셌습니다). GPT judge가 Codex 답을 1위로 올린 4개도 모두 제 선택과 달랐습니다. 이 7개만 보면 GPT judge가 Codex 답을 후하게 채점한 것으로 보입니다.
Claude judge도 저와 절반만 일치했습니다. Claude judge는 7개 모두 Perplexity 답을 1위로 골랐는데, 저는 그중 3개에서 Claude 내장 검색 답을 골랐습니다. 제 채점도 한 사람의 취향이라, 이것만으로 Codex 검색이 못하다고 말할 수는 없습니다.
사실 확인은 judge에게 맡길 수 없었습니다
채점 기준에는 "사실과 다르거나 지어낸 내용"을 표시하는 항목도 있었지만, 이 표시는 기준으로 쓰기 어려웠습니다. judge는 도구 없이 글만 읽고 판단했고, 오답 표시 수도 Claude judge는 522건 중 9건, GPT judge는 67건으로 일곱 배 넘게 차이가 났습니다. GPT judge가 표시한 67건 중 65건은 Claude가 쓴 답이었습니다.
그래서 사실 정확도는 따로 확인했습니다. 상품 질문 12개(새로 넣은 8개와 기존 50개 중 상품 질문 4개)의 답 36개에서 가격·판매 상태·사양 같은 주장 142개를 뽑아 당일 웹에서 대조했습니다. 대조는 Claude Opus에게 맡겼고, 어느 방식의 답인지 모르게 가·나·다 라벨만 보여 줬습니다.
방식
주장
맞음
틀림
확인 불가
정확도
Perplexity
48
46
2
0
0.96
Claude 내장
48
40
6
2
0.87
Codex 내장
46
43
2
1
0.96
Codex 내장 검색은 답이 짧은데도 정확도가 Perplexity와 같았습니다. 다만 답이 짧아서 확인할 주장 자체가 적은 쿼리도 있었고, 세 방식의 차이는 통계적으로 유의하지 않았습니다(Fisher 검정, Perplexity 대 Claude 내장 p=0.15). 가격은 76개 중 74개가 맞아서, 얼마에 파는지 정도는 셋 중 무엇을 써도 대체로 맞게 찾아옵니다.
이 평가의 한계
Claude를 주로 쓰는 제 환경에서 진행한 평가라, Codex에 불리했을 수 있는 부분이 있습니다.
프롬프트와 채점 기준은 Claude로만 돌렸던 이전 실험에서 정한 것을 그대로 썼고, Codex에 맞춰 다듬지 않았습니다.
사실 대조도 Claude Opus가 했습니다.
직접 채점은 저 혼자 7개 쿼리의 결론 부분만 본 것이고, 쿼리도 한국어 비중이 높은 제 실사용 질문입니다.
LLM judge로 모델을 비교할 때 주의할 점
judge를 한 회사 모델로만 구성하지 않습니다. 회사가 다른 judge를 같은 조건으로 섞고, 서로 얼마나 일치하는지를 결과와 같이 봅니다. 결론이 같으면 믿고, 엇갈리면 결론을 미룹니다.
judge끼리 엇갈린 쿼리에서 일부를 뽑아 사람이 직접 채점합니다.
사실 정확도는 judge 점수에 맡기지 않고 따로 대조합니다.
답 길이 차이가 크면 같은 길이의 요약으로 만들어 채점합니다.

Perplexity vs Claude 내장 검색 vs Codex 내장 검색: Codex 검색의 순위는 judge가 어느 회사 모델이냐에 따라 뒤집혔습니다

댓글