BrowseComp

찾기는 어렵고 확인은 쉬운 질문으로 웹 검색 능력을 평가한다

BrowseComp 는 OpenAI 가 2025 년 4 월 공개한 브라우징 에이전트 벤치마크다. 브라우징 에이전트는 검색어를 넣고, 결과 페이지를 열어 읽고, 읽은 내용을 보고 검색어를 바꾸는 과정을 스스로 반복하는 LLM 시스템이다. BrowseComp 는 이 반복을 오래 이어 가야만 답이 나오는 질문 1,266 개로 이루어져 있다. 논문

논문이 겨냥한 빈자리는 질문의 난이도다. 기존 검색·질의응답 벤치마크는 대부분 쉽게 찾을 수 있는 정보를 묻고, 사람이 10 분 정도 검색하면 풀린다 (논문 §5). 이런 질문으로는 “한두 번 검색해서 찾는 능력” 과 “수십 번 검색을 이어 가며 후보를 좁히는 능력” 을 구분할 수 없다. BrowseComp 는 뒤쪽 능력만 남도록 질문을 만들었다.

정답은 사람 이름, 연도, 작품 제목처럼 짧은 문자열 하나라서 채점이 간단하다. 저자들은 이 설계를 프로그래밍 대회에 빗댄다. 대회 문제가 실무 코딩 전체를 대표하지는 않지만 코딩 능력의 유용한 대리 지표이듯, BrowseComp 도 실제 사용자 질문의 다양성을 포기하는 대신 “포기하지 않고 창의적으로 찾는 능력” 하나만 평가하도록 범위를 좁혔다.

항목	내용
만든 곳	OpenAI (Wei et al.)
공개	2025-04-16 arXiv, 평가 코드는 openai/simple-evals
규모	질문 1,266 개, 정답은 짧은 문자열 하나
환경	실제 웹. 검색 API 를 쓸지 브라우저를 띄울지는 평가하는 쪽이 정한다
지표	정확도(accuracy), 보조 지표로 calibration error

질문은 정답에서 거꾸로 만든다

역질문 만들기

BrowseComp 질문은 사람(논문에서는 trainer 라고 부른다)이 정답이 될 사실에서 출발해 거꾸로 쓴다. 논문은 이를 “inverted question” 이라고 부른다.

1. 정답이 될 대상 하나를 고른다. 사람, 사건, 논문, 경기 같은 것이다.
2. 그 대상의 특징을 여러 개 모은다. 특징 하나만으로는 후보가 많이 남을 만큼 넓은 것을 고른다.
3. 특징들을 한 질문에 묶는다. 모든 조건을 동시에 만족하는 대상은 사실상 하나만 남는다.

이렇게 만들면 찾기는 어렵고 확인은 쉬운 질문이 된다. 조건 하나로 검색하면 후보가 수백 개 나오므로, 조건을 서로 교차해 가며 좁혀야 한다. 반대로 누군가 답을 내놓으면 조건을 하나씩 대조해 몇 분 안에 맞는지 확인할 수 있다.

예시

논문은 데이터셋 예시를 인터넷에 평문으로 옮기지 말아 달라고 요청한다. 문제가 학습 데이터에 섞이면 모델이 답을 외워 버려 벤치마크가 무의미해지기 때문이다. 그래서 아래는 이 노트를 위해 같은 방식으로 만든 예시다. 실제 문제보다 훨씬 쉽다.

어떤 논문에서 제안된 기법의 이름을 답하라. (1) 논문은 2021 년 4 월 arXiv 에 처음 올라왔다. (2) 저자들은 중국 선전에 있는 한 회사 소속이다. (3) 2023 년 이후 공개된 여러 오픈 LLM 이 이 기법을 채택했다.

조건 (1) 만으로는 그달 arXiv 에 올라온 논문 수천 편이 모두 후보다. (2) 와 (3) 을 함께 걸면 RoFormer 논문(Su et al., Zhuiyi Technology)이 제안한 Rotary Positional Embedding 하나로 좁혀진다. 답이 맞는지는 arXiv 페이지의 제출일과 저자 소속만 보면 확인된다.

실제 문제는 조건이 더 많고 더 모호하다. 대상의 이름이나 대표적인 특징 대신, 그 대상의 주변 사실 몇 개만 주어진다.

너무 쉬운 질문을 걸러내는 조건

질문을 쓴 사람은 다음 세 가지를 확인해야 했다. 논문 §2.1

1. 당시 모델이 풀지 못한다. GPT-4o(브라우징 있는 버전과 없는 버전), OpenAI o1, 초기 Deep Research 모델이 모두 틀려야 한다.
2. 단순 검색으로 나오지 않는다. Google 에서 간단한 검색을 다섯 번 해서, 첫 결과 페이지들에 답이 없어야 한다.
3. 다른 사람도 10 분 안에 풀지 못한다. 두 번째 trainer 가 일부 문제를 풀어 보고, 40% 넘게 풀린 문제는 고쳐 썼다.

조건 1 때문에 BrowseComp 의 난이도는 2025 년 초 모델을 기준으로 정해졌다. 이 점은 한계 절에서 다시 다룬다.

주제는 TV·영화 16.2%, 과학·기술 13.7%, 예술 10.0%, 역사 9.9%, 스포츠 9.7%, 음악 9.2% 순으로 고르게 퍼져 있다 (논문 Figure 2).

채점은 정확도와 calibration error 두 가지다

답 형식과 정답 판정

모델은 정해진 형식으로 답한다. simple-evals 의 프롬프트는 다음 세 줄을 요구한다. 평가 코드

Explanation: {최종 답에 대한 설명}
Exact Answer: {간결한 최종 답}
Confidence: {0% 에서 100% 사이의 자신감}

정답 판정은 문자열 일치가 아니라 별도의 grader 모델 이 한다.

1. grader 는 질문, 평가 대상 모델의 응답, 정답 세 가지를 받는다.
2. 응답에서 최종 답을 뽑아내고, 정답과 의미가 같은지 비교한다. 수치 답은 작은 오차를 허용한다.
3. correct: yes 또는 correct: no 를 출력한다. 출력에서 이 줄을 찾지 못하면 오답으로 친다.

이 grader 프롬프트는 Humanity’s Last Exam(HLE)의 것을 가져왔다. 논문은 grader 로 어떤 모델을 썼는지 밝히지 않았고, 코드도 grader 모델을 평가하는 쪽이 넘겨주게 되어 있다.

정확도 는 전체 문제 중 grader 가 정답으로 판정한 비율이다.

Calibration error

두 번째 지표는 모델이 적은 Confidence 가 실제 정답률과 얼마나 어긋나는지를 본다. “80% 확신한다” 고 답한 문제들을 모았을 때 실제로 80% 정도를 맞혔다면 잘 보정된 것이다. 이 개념 자체는 probability calibration 노트에 있다. 논문은 calibration error 의 계산식을 따로 적지 않았고, “모델의 자신감이 답이 맞을 가능성을 얼마나 잘 반영하는가” 로만 설명한다 (§4.2).

이 지표가 따로 있는 이유는, 틀릴 것 같을 때 “확실하지 않다” 고 말하는 에이전트가 실제 서비스에서 더 쓸모 있기 때문이다. 다음 절의 결과에서 보듯, 브라우징을 하면 정확도와 함께 틀린 답에 대한 자신감도 올라갈 수 있다.

검색 방법은 벤치마크가 정하지 않는다

BrowseComp 데이터에는 질문과 정답만 있다. 공식 평가 코드 browsecomp_eval.py 도 질문을 모델에 보내고, 돌아온 글을 grader 에게 넘겨 채점할 뿐이다. 검색 도구는 주지 않는다. 평가 코드

검색은 평가 코드가 호출하는 모델 쪽(코드에서는 sampler)이 알아서 한다. 그 안에서 검색 API 를 부르든, 브라우저를 띄워 페이지를 클릭하든, 아예 검색하지 않든 벤치마크는 구분하지 않는다. 최종 답만 맞으면 된다. 그래서 BrowseComp 점수는 “모델” 의 점수가 아니라 “모델과 그 모델에 붙인 검색 도구 묶음” 의 점수다.

논문의 두 브라우징 구성도 방식이 다르다.

구성	검색 방식
GPT-4o w/ browsing	gpt-4o-search-preview-2025-03-11. API 호출 안에서 웹 검색까지 하도록 만든 OpenAI 모델이다. 호출하는 쪽은 별도 검색 도구를 붙이지 않는다
Deep Research	웹 브라우징용으로 학습한 o3 초기 버전 기반 에이전트다. system card 에 따르면 검색·클릭·스크롤·파일 해석을 하는 브라우징 도구와, 계산·분석용 Python 도구를 쓴다. 임의의 URL 을 직접 만들어 이동하는 것은 막혀 있다. 화면을 그려서 보는지, 페이지를 텍스트로 읽는지는 밝히지 않았다

출처: 논문 §4, Deep Research system card

논문 밖에서 에이전트를 직접 만들어 평가할 때는 보통 도구 두 개를 준다.

1. 검색 도구: 검색어를 받아 검색 결과의 제목·요약·URL 목록을 돌려준다. Google·Bing·DuckDuckGo 같은 검색 엔진을 API 로 호출한다.
2. 페이지 읽기 도구: URL 을 받아 그 페이지 본문을 텍스트로 돌려준다.

에이전트는 검색 결과를 보고 읽을 페이지를 골라 본문을 받아 읽고, 다시 검색어를 바꾸는 과정을 반복한다. 사람이 브라우저에서 하는 일을 도구 호출 두 종류로 나눈 셈이다. BFCL V4 의 웹 검색 과제도 같은 구성(DuckDuckGo 검색 함수와 페이지 본문 가져오기 함수)을 쓴다. 이 노트 뒤쪽의 BrowseComp-Plus 는 실제 웹 대신 고정된 문서 집합에 대한 검색 도구를 준다.

검색 도구가 점수를 얼마나 바꾸는지는 BrowseComp-Plus 결과가 보여 준다. 같은 GPT-5 가 검색기만 바꿨을 때 55.9% 와 70.1% 로 갈렸다. 점수를 인용하거나 비교할 때는 모델 이름과 함께 검색 엔진, 페이지 읽기 방식, 검색 횟수 제한을 적어야 한다.

발표 당시 결과

모델

논문 Table 3 의 결과다. GPT-4o, GPT-4.5, o1 은 브라우징 없이 평가했고, GPT-4o w/ browsing 과 Deep Research 는 브라우징을 썼다. 두 브라우징 구성의 차이는 앞의 검색 방법 절에 있다.

모델	정확도 (%)	Calibration error (%)
GPT-4o	0.6	69
GPT-4o w/ browsing	1.9	82
GPT-4.5	0.9	68
OpenAI o1	9.9	65
Deep Research	51.5	91

표에서 세 가지가 보인다.

• 검색 도구를 붙이는 것만으로는 거의 늘지 않는다. GPT-4o 는 0.6% 에서 1.9% 로 오르는 데 그쳤다. 검색을 한두 번 하고 멈추는 모델은 이 문제들을 풀지 못한다.
• 검색 없이도 추론으로 일부가 풀린다. 브라우징 없는 o1 이 9.9% 를 맞혔다. 조건들로부터 후보를 추론해 좁히는 능력이 점수에 기여한다.
• 가장 잘 맞힌 모델이 자신감은 가장 안 맞는다. Deep Research 는 51.5% 로 크게 앞섰지만 calibration error 도 91% 로 가장 높다. 표 각주에 따르면 Deep Research 는 BrowseComp 와 비슷한 과제를 겨냥한 데이터로 학습됐다.

사람

같은 문제를 trainer 들에게 AI 도구 없이 풀게 했다 (§3, Table 2). ChatGPT, Claude, Perplexity, Grok, Gemini 는 쓸 수 없었고, 두 시간을 들여도 못 풀면 포기할 수 있었다.

1. 1,266 문제 중 1,255 문제를 시도했다.
2. 888 문제(70.8%)는 두 시간 뒤 포기했다.
3. 367 문제(29.2%)에서 답을 냈다.
4. 답을 낸 367 문제 중 317 문제(86.4%)만 원래 정답과 같았다.

검색에 익숙한 사람도 문제의 70% 를 두 시간 안에 풀지 못했다. 답을 낸 경우에도 열에 하나 이상은 원래 정답과 달랐는데, 이는 답이 하나뿐이라는 보장이 없다는 한계와 이어진다.

같은 문제를 여러 번 풀게 하면 오른다

Deep Research 에게 한 문제를 64 번 풀게 하고, 나온 64 개 답 중 하나를 고르는 세 방식을 비교했다 (§4.3–4.4).

• 다수결(majority voting): 가장 많이 나온 답을 고른다.
• 가중 투표(weighted voting): 같은 답끼리 모델이 적은 자신감을 더해, 합이 가장 큰 답을 고른다.
• best-of-N: 자신감이 가장 높은 답 하나를 고른다.

논문은 세 방식 모두 한 번만 풀 때보다 성능이 15–25% 오르고, best-of-N 이 가장 높다고 보고한다. 저자들의 해석은 정답이 확인하기 쉬운 형태이므로 모델도 자기 답이 조건을 모두 맞추는지 어느 정도 판단할 수 있다는 것이다. 앞의 calibration error 결과와 함께 보면, Deep Research 의 자신감 값은 그대로 확률로 읽을 수 없지만 같은 문제에 대한 여러 답 중 무엇이 나은지 고르는 데는 쓸모가 있다.

한계와 후속 벤치마크

한계

• 실제 사용자 질문과 다르다. 짧은 정답 하나를 찾는 질문만 있다. 긴 보고서를 쓰거나, 모호한 요청을 되물어 구체화하는 능력은 평가하지 않는다. 논문도 이를 스스로 밝힌다.
• 정답이 하나라는 보장이 없다. 질문 작성자도 다른 답이 없다고 확신할 수는 없었다 (§2.1). 사람 실험에서 답을 낸 문제의 13.6% 가 원래 정답과 달랐다.
• 웹이 바뀐다. 실제 웹을 검색하므로 페이지가 사라지거나 검색 엔진 순위가 바뀌면 같은 모델도 점수가 달라진다. 검색 API 가 서로 다르면 모델끼리가 아니라 “모델과 검색 도구의 조합” 끼리 비교하게 된다.
• 난이도 기준이 2025 년 초 모델이다. 당시 모델이 틀리는 문제만 남겼으므로, 이후 모델의 점수는 빠르게 오른다. 같은 점수라도 언제 측정했는지를 함께 봐야 한다.
• 오염 위험이 있다. 배포되는 CSV 는 문제와 정답을 암호화해 두었다. 행마다 있는 canary 문자열의 SHA-256 해시를 키로 삼아 XOR 하는 단순한 방식이다. 웹을 긁어 학습 데이터를 만드는 수집기가 평문을 가져가지 않게 하려는 장치이고, canary 문자열은 학습 말뭉치에서 이 데이터를 찾아 걸러내는 표식 역할을 한다.

후속 벤치마크

벤치마크	BrowseComp 에서 바꾼 점	규모와 발표 당시 결과
BrowseComp-ZH (2025-04)	중국어 웹에서 같은 방식으로 질문을 만들었다	11 개 분야 289 문제. 대부분 모델이 10% 미만, 최고는 OpenAI DeepResearch 42.9%
BrowseComp-Plus (2025-08, Waterloo 등)	실제 웹 대신 고정된 문서 집합에서 검색한다	문서 100,195 개, 질문 830 개

BrowseComp-Plus 는 앞의 “웹이 바뀐다” 는 한계를 겨냥한다. 문제마다 사람이 확인한 근거 문서와, 비슷해 보이지만 답이 들어 있지 않은 문서(hard negative)를 말뭉치에 함께 넣었다. 말뭉치가 고정되어 있으니 검색기만 바꿔 끼우며 같은 LLM 을 평가할 수 있다. 논문 Table 1 에서 GPT-5 는 BM25 검색기를 붙였을 때 55.90%, 임베딩 벡터의 유사도로 문서를 찾는 Qwen3-Embedding-8B 를 붙였을 때 70.12% 를 맞혔다. Search-R1-32B 는 같은 두 검색기에서 3.86% 와 10.36% 였다. LLM 은 그대로 두고 검색기만 바꿨는데 14 점 넘게 차이가 났으므로, 실제 웹 BrowseComp 점수에도 검색 도구의 몫이 상당히 섞여 있다고 볼 수 있다.

BrowseComp 계열은 정답 하나를 깊이 파고드는 depth search 능력을 평가한다. 조건에 맞는 항목을 빠짐없이 모아 표로 채우는 breadth search 는 Ko-WideSearch 가 다룬다. 다른 에이전트 벤치마크와의 비교는 LLM Agent Benchmarks 에 모았다.

References

• Wei et al. (2025), BrowseComp: A Simple Yet Challenging Benchmark for Browsing Agents
• openai/simple-evals — browsecomp_eval.py
• Zhou et al. (2025), BrowseComp-ZH: Benchmarking Web Browsing Ability of Large Language Models in Chinese
• Chen et al. (2025), BrowseComp-Plus: A More Fair and Transparent Evaluation Benchmark of Deep-Research Agent