[arXiv 2606.27669] DiscoBench: 질문해야 할 때를 아는 검색 에이전트 벤치마크

When Search Agents Should Ask: DiscoBench for Clarification-Aware Deep Search

https://arxiv.org/abs/2606.27669

Yiling Tao, Shihan Deng, Meiling Tao, Pengzhi Wei, Zhichao Hu, Zhihao Zhu | Hunyuan, Tencent; Tsinghua University SIGS | arXiv:2606.27669 | 2026년 6월

---

1. 서론: 검색 에이전트가 모호성을 지나치는 순간

대형 언어모델 기반 검색 에이전트는 이제 단순 키워드 검색을 넘어서 여러 번 검색하고, 중간 근거를 합치고, 마지막 답을 구성하는 deep search 방식으로 움직인다. 그런데 실제 사용자의 질문은 벤치마크처럼 항상 완결되어 있지 않다. 사람은 기억이 흐릿하거나 조건을 빠뜨리거나, 심지어 잘못된 단어를 섞어 질문한다. 이런 입력을 그대로 multi-hop search에 넣으면 모델은 첫 번째 애매한 후보를 기준으로 다음 검색을 이어가고, 나중에는 왜 틀렸는지도 추적하기 어려운 경로 오류가 생긴다.

DiscoBench는 바로 이 지점을 평가하려는 논문이다. 질문이 애매하면 검색을 더 많이 할지, 사용자에게 단서를 물을지, 현재 근거로 답을 낼지 결정해야 한다. 저자들은 이 결정을 Search, Ask, Answer라는 행동 공간으로 정식화하고, checkpoint마다 모호성이 있는지와 그 모호성을 어떻게 해결했는지를 따로 측정한다. 따라서 이 논문의 핵심은 검색 능력 자체보다 질문해야 할 때를 아는 능력을 측정하는 데 있다.

현재 많은 에이전트 벤치마크는 final answer accuracy를 중심으로 설계되어 있다. final answer가 맞으면 중간 경로가 다소 불안정해도 성공으로 처리되고, 틀리면 어떤 단계에서 모호성을 놓쳤는지 잘 보이지 않는다. DiscoBench는 211개 sample과 463개 ambiguity instance를 checkpoint 단위로 구성해, 모델이 모호한 지점을 인지했는지, 질문이 실제로 도움이 되었는지, 질문 비용이 과도하지 않았는지를 분리한다.

논문이 흥미로운 이유는 결과가 직관과 조금 다르기 때문이다. 검색을 많이 하는 모델이 늘 좋은 성능을 내지 않았고, 질문 품질이 높은 모델이 항상 질문을 잘 시작한 것도 아니었다. 예를 들어 Qwen3.6-Max는 질문을 시작한 경우 CE-A와 CE-B가 높지만, neutral setting에서는 거의 질문하지 않는다. 반대로 어떤 모델은 검색을 여러 번 반복하면서도 질문으로 전환하지 못해 direct guess보다 낮은 pass rate를 보인다.

검색 에이전트를 실제 제품에 붙일 때 가장 곤란한 실패는 "답을 모른다"보다 "모호한데도 모르는 척하지 않는다"에 가깝다. 사용자는 시스템이 웹을 뒤져 온 답을 신뢰하기 쉽고, 에이전트는 그럴듯한 근거 링크를 함께 제시한다. DiscoBench는 이 문제를 benchmark 형태로 잘라 내면서, 앞으로의 에이전트 평가가 retrieval score와 reasoning score만으로는 부족하다는 점을 수치로 보여 준다.

Figure 1: 동기 예시: 모호한 체크포인트가 잘못 풀리면 이후 검색 경로 전체가 오염되는 과정

Figure 1은 단일 모호성이 최종 답을 흔드는 데서 그치지 않고 중간 경로까지 바꿔 버리는 문제임을 보여 준다. 사용자가 기억하는 단서가 느슨하면 에이전트는 그럴듯한 후보 하나를 고르고, 그 선택이 다음 체크포인트의 검색어와 평가 기준을 모두 바꾼다. 그림의 핵심은 오류가 마지막 답변 직전에 생기는 것이 아니라 첫 후보 선택 이후 검색어, 근거 수집, 중간 결론에 연쇄적으로 섞인다는 데 있다. 그래서 DiscoBench는 최종 정답률보다 앞선 단계에서 언제 질문해야 하는지를 별도 능력으로 분리한다.

1.1 final answer 중심 평가가 감추는 실패

기존 검색형 QA 평가에서 final answer accuracy는 여전히 가장 직관적인 지표다. 그러나 deep search agent에서는 이 지표 하나로는 어디서 실패했는지 알기 어렵다. 모델이 첫 검색에서 잘못된 entity를 잡았는지, 두 번째 hop에서 근거를 잘못 해석했는지, 마지막 합성 단계에서 답을 섞었는지가 모두 하나의 오답으로 접힌다. DiscoBench가 checkpoint를 도입한 이유는 바로 이 압축을 풀기 위해서다.

특히 모호성은 일반적인 factual error와 다른 방식으로 생긴다. factual error는 답이 외부 근거와 충돌할 때 비교적 드러나지만, ambiguity error는 각 후보가 모두 어느 정도 근거를 가진다. 모델 입장에서는 자신이 고른 후보에 관한 문서가 충분히 나오기 때문에 confidence가 올라갈 수 있다. 이때 final answer만 보면 시스템은 "검색을 잘했고 답도 그럴듯하게 냈지만 틀린" 사례를 단순 실패로만 기록한다.

DiscoBench는 이 실패를 모호성 인지 실패, 질문 생성 실패, 질문 후 검색 복구 실패로 나눠 볼 수 있게 한다. 예를 들어 모델이 Ask를 하지 않았는데 checkpoint가 Ambi였다면 trigger 문제이고, Ask를 했지만 CE-A가 낮다면 질문이 잘못된 ambiguity를 겨냥한 것이다. Ask 이후에도 checkpoint pass가 낮으면 사용자 단서가 retrieval trajectory에 제대로 반영되지 않은 것이다.

이 관점은 RAG 시스템 평가에도 연결된다. RAG에서는 문서 검색 정확도와 답변 충실성을 따로 보지만, 사용자의 의도 자체가 덜 정의된 상태에서는 검색할 문서 집합을 먼저 정해야 한다. DiscoBench는 그 전처리 단계, 즉 query disambiguation과 interactive retrieval policy를 benchmark 안으로 끌어온다. 따라서 이 논문은 검색형 QA 성능표보다 agent control policy 평가에 더 가깝게 읽는 편이 맞다.

2. 배경 및 관련 연구: 완결된 질의 가정의 한계

2.1 Web search benchmark가 놓친 상호작용

GAIA, BrowseComp, WebArena, Mind2Web 같은 벤치마크는 검색 에이전트의 multi-hop reasoning, 웹 탐색, tool-use, 긴 정보 통합을 크게 발전시켰다. 그러나 상당수 benchmark는 사용자의 초기 질의가 이미 충분히 구체적이라는 가정을 둔다. 모델의 과제는 주어진 조건을 놓치지 않고 검색하는 것이며, 조건 자체가 부족하거나 충돌할 때 사용자를 다시 호출하는 행동은 주된 평가 대상이 되지 않는다.

이 가정은 실험을 깔끔하게 만들지만 실제 검색 상황과는 거리가 있다. "그 영화에 나온 배우가 만든 회사의 첫 제품"처럼 조건이 여러 단계로 이어지는 질문에서, 앞쪽 entity가 두 개 이상이면 뒤쪽 검색은 전부 다른 세계선으로 흘러간다. 기존 benchmark에서는 이 흐름이 단순 오답으로만 기록되기 쉽고, 모델이 어느 순간 질문을 해야 했는지 평가하기 어렵다.

DiscoBench는 search benchmark의 문제를 "검색 깊이"에서 "상호작용이 필요한 검색 깊이"로 옮긴다. 이때 중요한 차이는 retrieval result의 품질만 측정하지 않는다는 점이다. 모델이 여러 후보를 발견했을 때 그 후보들을 더 검색해 하나를 고르는지, 사용자 단서를 요청하는지, 불확실성을 감춘 채 답을 내는지를 행동 로그로 기록한다.

2.2 Ambiguity benchmark와 clarification benchmark의 빈틈

AmbigQA, ASQA, TempAmbigQA 같은 ambiguity benchmark는 하나의 질문이 여러 답을 가질 수 있다는 사실을 다룬다. 이 계열은 answer set, temporal condition, contextual assumption을 잘 드러내지만, 대부분 정적인 질의 이해 문제에 가깝다. 모델은 여러 해석을 한 번에 제시하거나 조건별 답을 정리하면 되고, 사용자와 단계적으로 상호작용해 하나의 경로를 복구하는 능력은 별도 축으로 분리되지 않는다.

반대로 IN3, UserBench, ColBench 같은 interactive benchmark는 multi-turn 협업을 다루지만, 오픈 웹 검색의 깊이와 사실 검증성을 동시에 담기는 어렵다. 사용자가 여행 계획을 바꾸거나 코드를 보완하는 상황은 풍부한 상호작용을 제공하지만, 검색 경로의 정답성을 checkpoint 단위로 객관적으로 판정하기 까다롭다. DiscoBench는 open-domain factual QA를 유지하면서 clarification을 넣어 이 둘 사이의 간격을 좁힌다.

논문은 최근 InteractComp와도 선을 긋는다. InteractComp가 검색 상호작용을 다룬다는 점에서는 가까운 선행 연구지만, 저자들은 그 benchmark가 초기 entity ambiguity와 binary feedback에 더 기울어 있다고 본다. DiscoBench는 multi-hop chain 안에서 모호성이 누적되는 상황, 그리고 사용자가 자연어 단서나 기억 조각을 제공하는 상황을 더 강조한다.

2.3 왜 지금 clarification-aware search가 중요한가

제품 관점에서 deep research agent는 이미 긴 보고서 작성, 문헌 조사, 시장 조사, 법률·정책 검색 같은 작업에 들어가고 있다. 이런 작업은 답을 하나 맞히는 것보다 근거 경로가 중요한데, 사용자의 입력이 모호하면 에이전트가 잘못된 경로에서 많은 비용을 태울 수 있다. 불확실성을 일찍 사용자에게 묻는 능력은 정확도와 비용을 동시에 좌우한다.

특히 LLM agent는 검색 결과를 그대로 보여 주는 검색 엔진과 다르다. 에이전트는 검색어를 재작성하고, 중간 결론을 만들고, 그 결론을 다음 검색의 조건으로 사용한다. 모호성을 감지하지 못하면 오류가 증폭되는 구조다. 그래서 DiscoBench가 "search more"와 "ask now"를 명시적으로 분리한 것은 향후 agent policy 설계에도 직접적인 함의를 가진다.

이전에 리뷰한 [[entities/papers/livebrowsecomp-2605-28721|LiveBrowseComp]]가 모델이 실제 검색을 하는지와 내부 지식으로 때우는지를 가르는 데 초점을 뒀다면, DiscoBench는 실제 검색을 하더라도 언제 멈추고 사용자에게 물어야 하는지를 묻는다. 또 [[entities/papers/when-agents-commit-too-soon-2606-22936|premature commitment]] 문제와도 맞닿아 있다. 두 논문 모두 에이전트가 불충분한 상태에서 조기 확정하는 행동을 핵심 실패로 본다.

2.4 clarification을 평가 단위로 끌어올리는 이유

Clarification은 전통적인 정보 검색에서도 오래된 주제다. 검색 엔진은 query suggestion, related search, facet filter를 제공해 사용자가 의도를 좁히게 만든다. 그러나 LLM agent의 clarification은 조금 다르다. 에이전트는 사용자의 다음 행동을 기다리는 검색 UI가 아니라, 자체적으로 검색하고 추론하고 답변을 생산하는 주체다. 따라서 모호성을 감지하는 순간 곧바로 행동 정책의 문제가 된다.

DiscoBench가 중요한 이유는 clarification을 단순 친절한 대화 기능으로 다루지 않는다는 데 있다. 논문은 Ask를 Search와 Answer 사이의 장식적 대화가 아니라, 올바른 checkpoint를 통과하기 위한 필수 행동으로 둔다. 모호한 checkpoint에서 적절한 질문을 하면 사용자 단서가 들어오고, 이 단서가 downstream search를 수정한다. 질문은 conversational UX 요소와 retrieval control signal을 동시에 가진다.

이 설계는 기존 ambiguity benchmark와의 차이를 분명하게 만든다. AmbigQA류 과제에서는 여러 가능한 답을 모두 제시하면 좋은 점수를 받을 수 있다. 반면 실제 검색 에이전트는 사용자가 원하는 하나의 결과를 찾아야 하고, 불필요하게 여러 세계선을 모두 보고서에 펼치면 오히려 사용성이 나빠진다. DiscoBench는 이 선택 압력을 Ask action으로 표현한다.

또한 clarification-aware search는 안전성 문제와도 맞닿아 있다. 의료, 법률, 금융 정보 탐색에서 사용자의 조건이 빠져 있는데도 모델이 하나의 답을 단정하면 위험하다. "어느 국가 기준인가", "어느 시점의 법령인가", "개인 상황의 어떤 제약이 있는가"를 묻는 능력은 정확도만큼 중요하다. DiscoBench의 도메인이 factual QA 중심이라 해도, 평가 철학은 고위험 검색 보조 시스템으로 확장된다.

3. 방법론: DiscoBench의 문제 정의와 데이터 구성

3.1 checkpoint 기반 task formulation

논문은 multi-turn interactive retrieval을 checkpoint sequence로 정의한다. 하나의 질문 $q$는 $CP_1, CP_2, \ldots, CP_n$으로 나뉘며, 각 checkpoint는 중간 검색 목표를 뜻한다. checkpoint는 Unambi 또는 Ambi로 표시된다. Unambi는 검색으로 바로 진행할 수 있는 단계이고, Ambi는 후보가 여러 개이거나 조건이 틀리거나 기준이 빠져 있어 사용자의 보충 단서가 필요한 단계다.

에이전트가 선택할 수 있는 행동은 세 가지다. $a_i \in \{ extsc{Search}, extsc{Ask}, extsc{Answer}\}$로 두고, 정상적인 unambiguous checkpoint에서는 Search 후 Answer로 넘어간다. 반면 ambiguous checkpoint에서는 Ask를 통해 사용자 단서 $c$를 받아야 한다. 이 단서를 기존 질의와 결합해 다시 검색하면 올바른 후보 $r^*$를 찾을 수 있다.

이 formulation이 중요한 이유는 final answer 중심 평가를 넘어 중간 의사결정을 평가 가능하게 만든다는 데 있다. 모델이 답을 틀렸을 때도 어느 checkpoint에서 SearchHeavyGuess로 빠졌는지, Ask를 했지만 질문이 모호성을 찌르지 못했는지, 또는 사용자 단서를 받은 뒤 검색을 잘못했는지 분해할 수 있다. 이는 agent debugging에 훨씬 직접적인 정보를 준다.

Figure 2: DiscoBench의 순차 검색 프레임워크와 Search, Ask, Answer 행동 공간

Figure 2는 DiscoBench가 검색 에이전트를 단순 질의응답기보다 순차 의사결정자에 가깝게 놓는 방식을 요약한다. 각 체크포인트에서 모델은 Search, Ask, Answer 중 하나를 선택하고, 모호한 상태에서는 사용자 단서를 받아 검색식을 다시 구성해야 한다. 특히 Ask가 독립 행동으로 들어가면서 모델이 검색 실패를 더 많은 검색으로 덮는지, 사용자 단서로 후보 공간을 줄이는지 구분된다. 이 구조 덕분에 정답을 맞혔는지와 질문 타이밍이 적절했는지를 함께 평가할 수 있다.

3.2 네 가지 모호성 유형

DiscoBench는 모호성을 네 범주로 구성한다. Entity는 같은 설명을 만족하는 후보 entity가 여러 개인 상황이다. 예를 들어 특정 회사의 "상을 받은 게임"이라는 표현만 있으면 후보가 둘 이상 생길 수 있다. 모델은 검색 결과의 첫 후보를 고르는 대신 어떤 상인지, 어느 시점인지, 어떤 속성인지 물어야 한다.

Version은 시간, 판본, 상태가 빠진 경우를 다룬다. 같은 인물, 도시, 제품이라도 특정 날짜나 버전 기준에 따라 정답이 바뀐다. Criteria는 ranking 기준, 평가 척도, 필터 조건이 부족한 경우다. "상위 세 도시"처럼 표면적으로는 자연스러운 표현이지만 세계 기준인지 중국 기준인지에 따라 답이 갈린다.

Factual Inaccuracy는 사용자의 설명 자체가 사실과 충돌하는 상황이다. 이 경우에는 검색 결과가 비어 있거나 엉뚱한 후보만 나오기 때문에 모델이 "질문이 틀렸을 가능성"을 인식해야 한다. 중요한 점은 네 유형이 동일한 정책으로 풀리지 않는다는 것이다. 사실 오류는 근거와의 충돌을 통해 드러나지만, entity나 criteria ambiguity는 그럴듯한 후보가 많아서 더 위험하다.

이 네 범주는 실제 검색 제품에서 자주 보이는 오류를 꽤 현실적으로 잘라낸다. 사용자에게 "어느 것을 말씀하시는 건가요?"라고 묻는 상황은 단순 entity ambiguity에 머물지 않는다. 사용자는 오래된 버전을 기억하거나, 비교 기준을 생략하거나, 잘못된 별칭을 말할 수 있다. DiscoBench는 이런 차이를 데이터 설계 단계에서 분리해 모델별 취약한 ambiguity profile을 볼 수 있게 한다.

Table 1. DiscoBench 데이터셋의 전체 통계는 난이도, 모호성 유형, 도메인을 동시에 보여 준다. 특히 Hard가 40.3%로 가장 많고 Entity와 Factual Inaccuracy가 큰 비중을 차지한다는 점은 benchmark가 단순한 toy ambiguity보다 실제 검색에서 흔한 후보 과다와 사실 충돌을 의도적으로 많이 담았음을 뜻한다.

구분	항목	개수	비율/설명
전체	Samples	211	11개 real-world domain
전체	Ambiguity instances	463	checkpoint 단위 모호성
난이도	Easy / Medium / Hard	44 / 82 / 85	20.9% / 38.9% / 40.3%
유형	Entity / Factual / Version / Criteria	176 / 125 / 109 / 53	38.0% / 27.0% / 23.5% / 11.4%
도메인	Film·TV, Games, Academic, Art, Finance 등	211	영화, 게임, 논문, 예술, 금융, 스포츠, 지리, 음악, 의학, 기술, 법·정책

3.3 데이터 구축 파이프라인과 user simulator

데이터 구축은 두 단계다. 먼저 seed data preparation에서 외부 검색이 필요한 multi-hop QA를 만든다. 저자들은 Wikipedia, Baidu Baike, Google, Bing, Baidu 검색 결과를 활용하고, 사람이 seed topic과 reasoning chain을 검수한다. 조건은 명확하다. 답은 객관적으로 검증 가능해야 하고, 상식만으로 풀리면 안 되며, 외부 검색이 실제로 필요해야 한다.

그다음 ambiguous data construction에서 deterministic chain 안에 모호성을 주입한다. 아무 지점이나 흐리게 만들지 않고, target entity와 비슷한 sibling candidate가 존재하고, 제약을 약화해도 downstream reasoning이 실행되며, 하나의 사용자 단서로 해소 가능한 지점을 찾는다. 이 조건은 benchmark가 풀 수 없는 난제를 만드는 대신, 질문 한 번이 실제로 경로를 복구할 수 있는 상황에 집중하게 한다.

사용자 simulator는 단순히 "A 또는 B 중 하나를 고르라"는 binary feedback을 주지 않는다. 논문은 fact-based memory fragment를 제공한다고 설명한다. 사용자는 특정 속성, 시간, 관계, 수치, 버전 차이 같은 객관적 단서를 자연어로 제공하고, 에이전트는 이 단서를 검색식과 reasoning trajectory에 다시 통합해야 한다. 이 설계는 실제 사용자가 흐릿한 기억 조각을 던지는 상황과 더 가깝다.

품질 관리는 데이터셋의 신뢰성에서 핵심이다. 논문은 annotation instructor, 여섯 명의 annotator, 두 명의 quality inspector가 사실성, retrieval feasibility, logical consistency, ambiguity solvability를 확인했다고 적는다. 특히 ambiguity solvability는 중요하다. 모호하지만 사용자 단서로 해결할 수 없는 예제는 모델 평가라기보다 데이터 오류가 되기 쉽기 때문이다.

Figure 3: Seed QA에서 모호성 주입, 식별 단서 생성, 품질 검수를 거쳐 데이터셋을 만드는 절차

Figure 3은 데이터셋 구축이 자동 생성만으로 끝나지 않았음을 보여 준다. 먼저 검증 가능한 multi-hop seed를 만들고, 그 경로 안에서 후보가 여러 개로 갈라지는 지점을 찾은 뒤, 사용자가 제공할 수 있는 구체 단서를 붙인다. 중요한 점은 모호성을 무작위로 넣지 않고, 실제로 sibling candidate가 존재하며 하나의 memory fragment로 해결 가능한 지점을 고른다는 점이다. 마지막에 사람이 사실성, 해결 가능성, 단서의 식별력을 검수하기 때문에 benchmark가 단순 synthetic prompt 모음으로 흐르지 않는다.

3.4 데이터 설계에서 눈여겨볼 품질 조건

DiscoBench의 데이터 설계에서 가장 중요한 조건은 해결 가능한 모호성이다. 모호한 질문을 만들기는 쉽다. 이름을 지우거나 날짜를 빼거나 ranking 기준을 없애면 된다. 하지만 그런 질문이 benchmark로 유효하려면 사용자가 제공할 수 있는 단서 하나로 올바른 경로를 복구할 수 있어야 한다. 그렇지 않으면 모델은 아무리 좋은 질문을 해도 정답으로 갈 수 없다.

저자들이 sibling candidate, weakened constraint, downstream reasoning feasibility를 따지는 이유도 여기에 있다. target entity와 비슷한 후보가 있어야 ambiguity가 현실적이고, 제약을 약화해도 검색이 이어져야 모델이 잘못된 경로로 빠질 수 있다. 동시에 discriminative clue가 존재해야 Ask가 실제로 utility를 가진다. 이 세 조건이 함께 있어야 Search와 Ask의 차이가 평가 가능한 신호가 된다.

데이터셋 규모만 보면 211개 sample은 거대한 benchmark는 아니다. 하지만 각 sample이 checkpoint와 ambiguity instance를 포함하기 때문에 단순 질문 개수보다 더 세밀한 측정 지점을 제공한다. 463개 ambiguity instance는 모델이 어느 유형의 ambiguity에서 실패하는지, 어떤 prompting에서 trigger가 켜지는지, 질문 후 pass rate가 얼마나 달라지는지를 분석하는 데 쓰인다.

품질 검수 과정도 이 논문을 읽을 때 놓치면 안 된다. 저자들은 annotation instructor와 여러 annotator, quality inspector를 분리해 사실성, 검색 가능성, 논리 일관성, 모호성 해결 가능성을 본다. 이 구조는 LLM으로 만든 synthetic benchmark에서 자주 생기는 두 문제, 즉 사실 오류와 풀 수 없는 모호성을 줄이기 위한 장치다. 완벽하다고 볼 수는 없지만 benchmark 신뢰도를 높이는 필수 단계다.

4. 실험 설정: 모델, 프롬프트, 평가 지표

4.1 평가 모델과 검색 도구

실험에는 GPT-5.4, Gemini-3.1-Pro-Preview, Claude-Opus-4.7, Doubao-Seed-2.0-Pro, DeepSeek-V4-Pro, Qwen3.6-Max, Kimi-K2.6, GLM-5.1, MiMo-v2.5-Pro, Hunyuan-3.0-Preview, MiniMax-M2.7이 포함된다. 검색 호출은 Tavily를 backend로 통일해 모델별 검색 엔진 차이를 줄이고, Gemini-3-Flash-Medium을 simulated user와 checkpoint-level judge로 사용한다.

모델 설정에서 흥미로운 부분은 reasoning effort를 가능한 한 높게 맞춘다는 점이다. frontier proprietary model은 provider rate limit 때문에 concurrency가 낮고, 일부 모델은 thinking mode나 adaptive budget을 사용한다. 논문은 이 차이가 wall-clock cost에는 영향을 주지만 per-question correctness 비교에는 직접 영향을 주지 않도록 동일한 interactive retrieval framework를 적용했다고 설명한다.

검색 backend가 Tavily라는 점은 실무적으로도 중요하다. 웹 검색 API는 index freshness와 ranking이 고정되어 있지 않으므로 bit-exact reproducibility는 어렵다. 논문은 appendix에서 이 한계를 명시하고, 같은 evaluation window에서 모델을 비교하거나 raw Tavily response를 cache해 공개하는 방식을 권장한다. 이 정직한 설명은 benchmark 재현성을 해석할 때 필요하다.

Table 2. 평가 모델 목록은 DiscoBench가 특정 계열의 모델만 겨냥하지 않았음을 보여 준다. frontier model, 중국어권 대형 모델, thinking mode 모델을 함께 넣고, 동일한 검색 도구와 user simulator를 붙였기 때문에 결과는 단순 모델 크기 비교보다 상호작용 정책 차이에 가깝게 해석할 수 있다.

역할	모델/도구	설정	비고
Agent	GPT-5.4	xhigh reasoning	37개 neutral 질문에서 policy filtering 발생
Agent	Gemini-3.1-Pro-Preview	high reasoning	Guided setting 최고 정확도
Agent	Claude-Opus-4.7	adaptive max	checkpoint pass와 final accuracy 간 gap 확인
Agent	Doubao-Seed-2.0-Pro	high / medium	main result와 reasoning effort 분석
Agent	DeepSeek-V4-Pro, Qwen3.6-Max, Kimi-K2.6 등	thinking mode	상호작용 전략 분포 비교
Search	Tavily	공통 backend	모든 Search action에 사용
Simulator/Judge	Gemini-3-Flash-Medium	medium thinking	사용자 단서 제공과 checkpoint scoring

4.2 Neutral과 Guided prompting

프롬프트 조건은 두 가지다. Neutral에서는 모델에게 모호성이 있을 수 있다는 힌트를 주지 않는다. 모델은 검색 도중 스스로 ambiguity를 감지하고 질문이 필요한지 판단해야 한다. 이 조건은 제품 기본값에 가깝다. 사용자가 "애매하면 물어봐"라고 매번 명시하지 않더라도 에이전트가 알아서 불확실성을 처리해야 하기 때문이다.

Guided에서는 prompt가 모호성을 의식하고 필요하면 clarification question을 던지라고 명시한다. 이는 ambiguity-aware instruction이 있을 때의 upper-bound 성능을 보는 조건이다. 두 조건을 비교하면 모델이 본래 clarification policy를 갖고 있는지, 또는 prompt reminder만으로 어느 정도 활성화되는지 알 수 있다.

Guided prompting은 평균적으로 도움을 준다. 유효한 10개 모델 평균에서 end-to-end accuracy는 28.6%에서 33.7%로, checkpoint pass rate는 50.1%에서 57.6%로 오른다. 특히 detection F1은 45.3%에서 64.9%로 크게 오른다. 그러나 이 개선은 ambiguity detection에 더 강하게 나타나며, final answer accuracy를 완전히 끌어올리지는 못한다.

Table 3. Neutral과 Guided 조건의 평균 차이는 prompt가 모호성 탐지를 깨우는 데는 효과적이지만 reasoning trajectory 복구까지 자동으로 해결하지는 못한다는 점을 요약한다. Guided 조건에서 detection F1이 크게 오르는데도 accuracy 상승폭이 제한적이라는 사실이 이 논문의 중요한 관찰이다.

지표	Neutral 평균	Guided 평균	변화	해석
End-to-end Acc.	28.6%	33.7%	+5.1	최종 성공률은 완만하게 개선
Checkpoint Pass	50.1%	57.6%	+7.5	중간 단계 통과는 더 개선
Detection F1	45.3%	64.9%	+19.6	모호성 인식이 가장 크게 반응
질문 횟수	모델별 증가	대체로 증가	비용 증가	무조건 좋은 결과로 연결되지는 않음
주요 함의	자발적 탐지 부족	지시로 일부 보완	정책 학습 필요	프롬프트만으로 충분하지 않음

4.3 평가 지표 네 축

평가 지표는 네 축으로 나뉜다. 첫째, task utility는 end-to-end accuracy와 checkpoint pass rate로 본다. 정확도는 전체 질문의 최종 성공이고, checkpoint pass는 중간 reasoning step의 성공률이다. 두 지표가 벌어지면 모델이 일부 단계는 풀지만 완전한 경로를 유지하지 못한다는 뜻이다.

둘째, ambiguity detection은 detection accuracy와 detection F1로 측정한다. 이 축은 모델이 모호한 상태를 알아차리는지에 초점을 둔다. 셋째, interaction strategy는 clarification evaluation, 즉 CE-A와 CE-B로 본다. CE-A는 질문이 모호성을 정확히 겨냥했는지, CE-B는 질문 후 실제로 checkpoint 진행에 도움이 되었는지를 반영한다.

넷째, cost efficiency는 평균 ask turn, tool-use turn, token consumption으로 평가한다. 검색 에이전트에서 비용은 단순 부가 정보가 아니다. 모델이 검색을 계속 반복하다가 결국 틀리면 accuracy도 낮고 비용도 높다. DiscoBench는 이런 실패를 SearchHeavyGuess 같은 behavior profile로 묶어 보여 준다.

4.4 지표를 함께 읽는 방법

DiscoBench의 지표는 서로 독립적으로 보이면 헷갈리기 쉽다. End-to-end accuracy가 낮은 모델도 CE-A가 높을 수 있고, detection F1이 오른 모델도 final accuracy가 크게 오르지 않을 수 있다. 이는 지표가 같은 능력을 반복 측정하는 것이 아니라 search trajectory의 다른 병목을 본다는 뜻이다. 따라서 결과표를 읽을 때는 accuracy 하나로 모델 순위를 끝내기보다, 어떤 병목에서 손실이 생겼는지를 따져야 한다.

Detection F1은 모호한 상태를 알아차리는 능력이다. 그러나 감지했다고 해서 질문이 좋은 것은 아니다. CE-A는 질문이 올바른 ambiguity point를 겨냥했는지, CE-B는 그 질문이 실제 checkpoint 해결에 도움이 되었는지를 본다. CE-A와 CE-B가 모두 높아도 평균 ask turn이 낮으면 모델은 필요한 순간에 질문을 거의 시작하지 않는 셈이다.

Checkpoint pass rate는 final answer accuracy보다 더 미세한 신호다. 어떤 모델은 여러 checkpoint를 통과하지만 마지막 하나에서 무너질 수 있고, 어떤 모델은 처음부터 잘못된 candidate를 골라 뒤쪽 checkpoint까지 연쇄적으로 실패할 수 있다. 두 경우의 final accuracy는 같아 보여도 수정해야 할 정책은 다르다. DiscoBench는 이 차이를 결과표와 behavior profile로 드러낸다.

비용 지표도 단순히 적을수록 좋은 값으로 보면 곤란하다. ask turn이 너무 낮으면 모호성을 회피하는 모델일 수 있고, 너무 높으면 불필요하게 사용자를 방해하는 모델일 수 있다. tool-use turn도 마찬가지다. 검색 호출이 많다는 것은 부지런하다는 뜻일 수도 있지만, 후보를 좁히지 못하고 반복하는 신호일 수도 있다. 이 논문은 비용과 정확도를 행동 profile과 함께 읽어야 함을 강조한다.

5. 주요 실험 결과: 강한 모델도 질문 타이밍은 불안정하다

5.1 전체 성능과 checkpoint gap

주요 결과에서 가장 먼저 보이는 것은 frontier model도 DiscoBench를 쉽게 풀지 못한다는 점이다. Neutral setting에서 최고 성능은 Doubao-Seed-2.0-Pro의 43.1% accuracy이고, Gemini-3.1-Pro-Preview가 40.8%로 뒤따른다. Claude-Opus-4.7은 39.8%, DeepSeek-V4-Pro는 35.5%이며, 다른 모델 상당수는 30% 이하에 머문다.

checkpoint pass rate와 end-to-end accuracy 사이의 차이도 크다. 예를 들어 Claude-Opus-4.7은 checkpoint pass가 57.0%지만 final accuracy는 39.8%다. 이는 모델이 중간 단계 몇 개를 맞혀도 전체 trajectory의 한 지점에서 ambiguity를 놓치면 최종 답이 틀릴 수 있음을 보여 준다. DiscoBench가 final answer만 보지 않고 checkpoint를 둔 이유가 여기서 드러난다.

Guided setting에서는 Gemini-3.1-Pro-Preview가 53.1% accuracy와 73.8% checkpoint pass로 가장 높은 결과를 낸다. 하지만 절반 남짓의 정확도라는 사실은 여전히 무겁다. prompt가 ambiguity awareness를 일깨워도 모델이 언제 묻고, 단서를 어떻게 검색 경로에 다시 넣고, 언제 답변을 종료할지 안정적으로 제어하지 못한다.

Table 4. Main result는 모델별 neutral/guided 결과를 한눈에 보여 준다. Doubao와 Gemini가 상위권이지만, CE-A와 CE-B가 높은 모델이 항상 높은 최종 정확도를 내는 것은 아니다. 이는 질문 품질, 질문 빈도, 검색 경로 복구가 서로 다른 능력이라는 논문의 주장을 뒷받침한다.

모델	Acc. Neutral/Guided	CP Neutral/Guided	Det. F1 Neutral/Guided	CE-A Neutral/Guided	Ask Neutral/Guided
Doubao-Seed-2.0-Pro	43.1 / 50.2	63.6 / 70.4	61.9 / 73.9	93.8 / 87.5	0.84 / 1.40
Gemini-3.1-Pro-Preview	40.8 / 53.1	62.1 / 73.8	64.5 / 75.6	87.8 / 88.3	0.81 / 1.40
Claude-Opus-4.7	39.8 / 38.9	57.0 / 61.6	48.9 / 68.9	92.0 / 90.0	0.58 / 1.05
DeepSeek-V4-Pro	35.5 / 38.9	57.6 / 62.2	48.6 / 63.7	87.9 / 92.9	0.64 / 1.10
Kimi-K2.6	29.4 / 35.1	51.3 / 61.3	42.4 / 71.0	90.1 / 90.5	0.54 / 1.14
Qwen3.6-Max	12.3 / 14.6	33.1 / 39.9	16.0 / 51.8	94.7 / 90.8	0.07 / 0.42

5.2 질문 품질과 질문 시작 능력의 분리

논문에서 가장 설득력 있는 관찰 중 하나는 질문을 잘 만드는 능력과 질문을 시작하는 능력이 분리된다는 점이다. Qwen3.6-Max는 Neutral setting에서 Detection F1이 16.0%이고 평균 ask가 0.07에 불과하다. 그러나 질문을 실제로 던진 경우 CE-A는 94.7%, CE-B는 89.5%로 높다. 조건부 질문 품질은 좋지만 clarification trigger가 거의 작동하지 않는 셈이다.

반대로 MiniMax-M2.7은 평균 ask가 0.61/1.10으로 더 높지만 CE-B는 60.7%/66.5%로 낮다. 자주 묻는다고 해서 좋은 상호작용이 되는 것은 아니다. 질문이 정확한 ambiguity point를 찌르지 못하거나, 사용자 단서를 받은 뒤 검색을 제대로 refine하지 못하면 비용만 늘고 checkpoint 진행에는 도움이 되지 않는다.

이 분리는 실제 에이전트 설계에서도 중요하다. 좋은 clarification system은 두 모듈을 모두 가져야 한다. 하나는 검색 근거의 불충분성, 후보 다중성, factual conflict를 감지하는 detector이고, 다른 하나는 어떤 질문을 던져야 후보 공간을 가장 잘 줄이는지 결정하는 question generator다. 하나만 좋아서는 사용자 경험이 좋아지기 어렵다.

5.3 검색을 많이 한다는 착시

검색 에이전트에서 흔한 직관은 search call을 더 많이 쓰면 성능이 나아질 것이라는 기대다. DiscoBench 결과는 이 기대를 제한한다. Claude-Opus-4.7처럼 tool-use frequency가 높아도 Doubao나 Gemini보다 낮은 accuracy를 보일 수 있고, SearchHeavyGuess profile은 평균적으로 DirectGuess보다 낮은 pass rate를 보인다.

이는 검색량 자체보다 검색에서 질문으로 전환하는 조건이 문제임을 뜻한다. 반복 검색은 모델이 이미 여러 후보를 본다는 신호일 수 있다. 하지만 그 상태를 ambiguity로 해석하지 못하면 모델은 후보 중 하나를 더 그럴듯하게 포장해 답하게 된다. 이때 추가 검색은 evidence accumulation보다 wrong trajectory consolidation에 가까워진다.

따라서 DiscoBench의 비용 지표는 단순 efficiency 표가 아니다. token과 tool call은 모델이 uncertainty를 처리하는 방식의 흔적이다. 좋은 에이전트는 검색을 아끼기만 하는 시스템도 아니고, 무제한 검색하는 시스템도 아니다. 후보가 좁혀지지 않을 때 사용자에게 어떤 최소 단서를 요청해야 할지 아는 시스템이다.

5.4 모델별 결과가 보여 주는 정책 차이

상위권 모델인 Doubao와 Gemini를 비교해도 차이가 보인다. Doubao-Seed-2.0-Pro는 neutral setting에서 가장 높은 accuracy를 보이고, Gemini-3.1-Pro-Preview는 guided setting에서 크게 뛰어오른다. 이는 모델 내부 policy가 기본적으로 얼마나 ambiguity-aware한지와, prompt instruction에 얼마나 잘 반응하는지가 분리될 수 있음을 보여 준다.

Claude-Opus-4.7의 결과는 또 다른 해석을 준다. checkpoint pass가 꽤 높고 질문 품질도 높은 편이지만, guided setting에서 final accuracy가 오히려 낮아지는 값이 보인다. 이는 질문을 더 하라는 지시가 항상 전체 trajectory를 개선하지는 않는다는 점을 시사한다. 질문이 늘면 사용자 단서 통합, 추가 검색, 최종 합성 단계가 함께 늘어나고, 그 어느 지점에서도 오류가 들어갈 수 있다.

Qwen3.6-Max 사례는 trigger 문제를 극단적으로 보여 준다. neutral setting에서 평균 ask가 0.07에 가까우므로 대부분의 ambiguous checkpoint를 질문 없이 지나친다. 그런데 실제로 질문을 한 경우의 CE-A와 CE-B는 매우 높다. 이는 질문 생성 능력이 부족해서라기보다, 어떤 상태를 질문해야 할 상태로 인식하는 classifier 또는 policy threshold가 잘못 설정되어 있음을 암시한다.

MiniMax-M2.7처럼 상대적으로 자주 묻지만 CE-B가 낮은 모델은 반대쪽 실패다. 이런 모델은 불확실성을 느끼는 순간 질문을 던질 수 있으나, 질문이 candidate space를 충분히 줄이지 못하거나 받은 단서를 검색 경로에 반영하지 못한다. 제품에서는 이 유형이 사용자에게 더 피곤하게 느껴질 수 있다. 질문은 많은데 답은 나아지지 않는 경험이 되기 때문이다.

6. 추가 분석 및 Ablation Study: 실패 모드를 쪼개 보기

6.1 ambiguity type별 성능

유형별 분석은 모델의 약점이 균일하지 않다는 점을 보여 준다. Factual Inaccuracy는 비교적 탐지하기 쉽다. 검색 결과가 없거나 사용자의 설명과 외부 근거가 명시적으로 충돌하면 모델이 이상 신호를 발견할 가능성이 높다. 반면 Entity와 Criteria ambiguity는 표면적으로 자연스럽고, 후보도 여러 개가 그럴듯해 더 어렵다.

Entity ambiguity에서는 검색 결과가 오히려 모델을 안심시킨다. 후보 A가 검색되고 관련 설명도 맞으면 모델은 A를 정답으로 삼기 쉽다. 그러나 사용자가 실제로 의도한 것은 후보 B일 수 있다. Criteria ambiguity는 더 미묘하다. ranking, top-k, 기간, 지역 범위가 빠진 경우 모델은 하나의 기준을 암묵적으로 가정하고 진행한다.

이 결과는 benchmark 설계 관점에서 중요한 메시지를 준다. 검색 결과가 풍부하게 나오는 예제일수록 모델이 틀릴 수 있다. 기존 retrieval benchmark에서는 rich evidence가 장점으로 보이지만, ambiguity-aware setting에서는 rich but underdetermined evidence가 위험 신호가 된다.

Figure 4: 모호성 유형별 탐지 성능 차이

Figure 4는 모델들이 모호성 유형에 따라 서로 다른 약점을 보인다는 점을 드러낸다. 사실 오류처럼 검색 결과와 직접 충돌하는 유형은 비교적 잘 잡히지만, 엔티티 후보가 여럿 있거나 ranking 기준이 빠진 경우에는 모델이 하나의 후보를 조기에 선택하는 경향이 강하다. 이 차이는 모델이 evidence conflict에는 민감해도 under-specification에는 둔감할 수 있음을 뜻한다. 즉 clarification-aware search는 retrieval confidence만으로 설명하기 어렵다.

6.2 behavior profile: DirectGuess, SearchHeavyGuess, SearchThenAsk

논문은 ambiguous checkpoint trajectory를 DirectGuess, SearchHeavyGuess, DirectAsk, SearchThenAsk로 나눈다. DirectGuess는 별다른 질문 없이 바로 답하는 경우이고, SearchHeavyGuess는 검색을 많이 했지만 결국 질문하지 않고 답하는 경우다. DirectAsk는 검색 전에 바로 묻는 경우이며 드물게 나타난다. SearchThenAsk는 먼저 검색으로 후보를 확인하고, 모호성이 남으면 질문으로 전환하는 profile이다.

결과는 명확하다. common subset 146개 ambiguous checkpoint에서 SearchThenAsk의 평균 pass rate는 93.4%다. DirectGuess는 56.5%, SearchHeavyGuess는 51.9%다. SearchHeavyGuess가 DirectGuess보다 낮다는 사실은 특히 중요하다. 더 많이 찾아본 모델이 더 잘못된 확신을 쌓을 수 있음을 보여 주기 때문이다.

Gemini-3.1-Pro와 Doubao-Seed-2.0-Pro는 SearchThenAsk profile에서 각각 96.2%, 98.6% pass rate를 보인다. 이 숫자는 clarification이 제대로 작동할 때 ambiguity resolution 자체는 꽤 안정적일 수 있음을 의미한다. 병목은 질문 후 해결 능력보다, 그 profile로 들어가는 빈도와 타이밍에 있다.

Table 5. Behavior profile pass rate는 이 논문의 메시지를 가장 압축적으로 보여 준다. SearchThenAsk는 모든 모델에서 가장 높은 pass rate를 보이며, SearchHeavyGuess는 평균적으로 DirectGuess보다 낮다. 즉 retrieval uncertainty를 clarification으로 승격하지 못하는 것이 중요한 실패 모드다.

모델	DirectGuess	SearchHeavyGuess	SearchThenAsk	해석
Gemini-3.1-Pro	66.7	56.5	96.2	질문으로 전환하면 매우 안정적
Doubao-Seed-2.0-Pro	57.1	55.3	98.6	상위 성능의 핵심도 STA
DeepSeek-V4-Pro	63.2	50.8	95.7	검색 반복보다 질문 전환이 효과적
Claude-Opus-4.7	58.3	55.0	97.8	tool-use 많아도 질문 정책이 중요
MiniMax-M2.7	50.0	51.5	91.2	질문 품질과 빈도 모두 병목
Mean	56.5	51.9	93.4	SearchThenAsk가 압도적

6.3 ablation: 검색 도구와 모호성 제거

검색 도구를 제거하면 모든 모델의 성능이 크게 떨어진다. Doubao-Seed-2.0-Pro는 43.1%에서 2.4%로 40.7 point 하락하고, Gemini-3.1-Pro는 40.8%에서 19.9%로 내려간다. 이는 DiscoBench가 내부 지식으로 쉽게 맞힐 수 있는 암기형 문제가 아님을 보여 준다. 외부 검색은 여전히 필수다.

반대로 ambiguous question을 unambiguous question으로 바꾸면 성능이 크게 오른다. Gemini-3.1-Pro는 81.0%, DeepSeek-V4-Pro는 74.4%, Doubao-Seed-2.0-Pro는 71.4%까지 올라간다. 같은 retrieval setting에서도 ambiguity를 제거하면 모델이 훨씬 잘 푼다. 따라서 난이도의 상당 부분은 open-domain search 자체보다 ambiguity resolution에 있다.

이 ablation은 DiscoBench의 정당성을 강화한다. 검색 도구를 빼면 못 풀고, 모호성을 빼면 훨씬 잘 푼다. benchmark가 측정하는 것은 단순한 웹 검색 숙련도도, 단순한 언어 추론도 아니다. 외부 근거가 필요한 상태에서 불완전한 사용자 의도를 어떻게 다룰지에 대한 agent 능력이다.

Table 6. Ablation 결과는 검색 도구와 모호성이 각각 어떤 역할을 하는지 분리한다. w/o Search에서는 외부 evidence가 사라져 성능이 급락하고, Unambiguous Questions에서는 ambiguity 병목이 사라져 성능이 크게 오른다. 두 방향의 비교가 DiscoBench의 측정 대상이 clarification-aware deep search임을 확인한다.

모델	Full Acc.	w/o Search Acc.	변화	Unambiguous Acc.	변화
Doubao-Seed-2.0-Pro	43.1	2.4	-40.7	71.4	+28.3
Gemini-3.1-Pro	40.8	19.9	-20.9	81.0	+40.2
DeepSeek-V4-Pro	35.5	9.8	-25.7	74.4	+38.9
Hunyuan-3.0-Preview	16.1	2.9	-13.2	45.5	+29.4
MiniMax-M2.7	16.1	0.8	-15.3	42.9	+26.8

6.4 reasoning effort와 complexity

Doubao-Seed-2.0-Pro의 reasoning effort 분석은 계산량을 늘리는 전략의 효과와 한계를 동시에 보여 준다. medium에서 high로 올리면 평균 score는 45.7%에서 54.0%로 8.3 point 오른다. Detection F1은 9.0 point, Ambi. Rec.는 37.2%에서 47.3%로 10.1 point 개선된다. 더 오래 생각하면 모호한 search state를 더 잘 비교한다는 뜻이다.

하지만 high-effort에서도 accuracy는 45% 미만이고 Ambi. Rec.도 50%를 넘지 못한다. 이는 reasoning token을 늘리는 것만으로 질문 정책을 완전히 대체할 수 없음을 뜻한다. 모델은 후보를 더 많이 비교할 수 있지만, 그 비교 결과를 사용자 질문으로 전환하는 policy boundary가 명시적으로 학습되어 있지 않으면 여전히 답을 고정한다.

complexity 분석도 같은 방향을 가리킨다. Easy에서 강한 모델도 Hard로 갈수록 성능이 뚜렷하게 떨어진다. Hard sample은 ambiguity checkpoint가 많고, 앞선 ambiguity의 해결이 뒤쪽 경로에 영향을 준다. 따라서 단일 ambiguity detector보다 trajectory-level uncertainty management가 필요하다.

Figure 5: 모호성 난이도별 성능 하락 패턴

Figure 5는 쉬운 예제에서 성능이 괜찮아 보이는 모델도 ambiguity가 여러 단계로 누적되면 빠르게 흔들린다는 점을 보여 준다. Hard 조건은 단순히 더 긴 문제가 아니라, 앞선 모호성 해결이 다음 checkpoint의 조건이 되는 구조다. 따라서 한 번의 잘못된 후보 선택은 뒤쪽 검색의 constraint 자체를 바꾸고, 모델은 이후 단계에서 더 많은 근거를 모아도 원래 사용자가 원한 경로로 돌아오기 어렵다. 이 결과는 multi-hop search agent 평가에서 path-level robustness를 따로 봐야 하는 이유를 뒷받침한다.

Table 7. Reasoning effort 분석은 계산량 증가가 주로 ambiguity 관련 지표를 개선한다는 점을 보여 준다. 그러나 high-effort 조건에서도 성능이 제한적이므로, 더 긴 사고만 요구하는 접근보다 질문 정책과 근거 검증 루프를 함께 설계해야 한다.

설정	평균 score	Det. F1 변화	Ambi. Rec.	핵심 해석
Doubao medium	45.7%	기준	37.2%	기본 reasoning effort
Doubao high	54.0%	+9.0 point	47.3%	모호성 인식 개선
차이	+8.3 point	탐지 개선이 큼	+10.1 point	계산량은 도움을 주지만 충분조건은 아님

Figure 6: Doubao-Seed-2.0-Pro에서 reasoning effort를 높였을 때의 지표 변화

Figure 6은 reasoning effort를 높이면 ambiguity detection과 recall이 좋아지지만, 그것만으로 완전한 해결이 되지는 않는다는 메시지를 준다. Doubao-Seed-2.0-Pro는 medium에서 high로 바뀔 때 평균 점수가 오르고 Det. F1도 개선되지만, 높은 노력 설정에서도 최종 정확도와 Ambi. Rec.는 아직 낮다. 계산량 증가는 필요한 조건일 수 있으나 질문 정책 자체를 대체하지 못한다.

Table 8. Token consumption은 모델별 비용 구조가 다르다는 점을 보여 준다. Guided prompting은 대체로 input token과 ask turn을 늘리지만, 성능 향상은 모델별로 다르게 나타난다. 따라서 비용 효율 평가에서는 단순 token 수보다 어떤 행동 profile로 이어졌는지를 함께 봐야 한다.

모델	Neutral Input	Neutral Output	Guided Input	Guided Output
Doubao-Seed-2.0-Pro-High	1,250,346	11,891	2,343,428	17,068
Gemini-3.1-Pro-Preview	1,734,148	9,431	1,696,445	9,860
Claude-Opus-4.7	2,033,450	13,020	2,488,658	15,168
DeepSeek-V4-Pro	2,759,370	12,337	2,618,879	11,572
Qwen3.6-Max	1,409,768	9,986	3,697,178	17,444

6.5 SearchHeavyGuess를 학습 신호로 보는 관점

Behavior profile 중 가장 흥미로운 것은 SearchHeavyGuess다. 이 profile은 모델이 검색을 충분히 하지 않은 실패가 아니다. 오히려 모델은 여러 번 도구를 호출했고, 후보 정보를 보았고, 그럼에도 사용자에게 묻지 않은 채 답을 확정했다. 실패의 원인은 지식 부족보다 uncertainty escalation 실패에 가깝다.

이런 trajectory는 후속 학습 데이터로 가치가 있다. 같은 checkpoint에서 SearchThenAsk로 성공한 예와 SearchHeavyGuess로 실패한 예를 비교하면, 어떤 검색 결과 패턴이 질문 전환을 유발해야 하는지 학습할 수 있다. 예를 들어 상위 검색 결과가 서로 다른 entity를 가리키거나, ranking 기준이 문서마다 다르게 쓰이거나, 시간 조건이 서로 충돌할 때 Ask로 넘어가는 policy를 만들 수 있다.

단순 규칙으로도 일부 개선은 가능할 것이다. 후보 entity가 두 개 이상이면 묻고, 날짜가 없으면 묻고, ranking 기준이 없으면 묻는 방식이다. 그러나 실제 query는 훨씬 복잡하다. 모든 다중 후보가 질문을 요구하지는 않고, 일부는 추가 검색으로 충분히 해소된다. 따라서 좋은 정책은 검색을 중단하는 규칙보다 expected value of clarification을 추정하는 방향에 가까워야 한다.

DiscoBench의 profile annotation은 이런 expected value 학습의 출발점이 될 수 있다. 모델이 Search action 이후 어떤 evidence state에 있었는지, 그 상태에서 Ask를 했는지, Ask 이후 pass가 올라갔는지를 연결하면, offline trajectory data로 질문 정책을 훈련할 수 있다. 이 점에서 DiscoBench는 평가셋과 함께 agent policy dataset의 성격도 일부 가진다.

7. 한계점 및 향후 연구 방향: benchmark가 남기는 빈자리

7.1 simulator 기반 상호작용의 한계

논문이 스스로 인정하듯 DiscoBench의 사용자는 실제 사람이 아닌 LLM 기반 simulator다. fact-based memory fragment는 자연스러운 단서 제공을 흉내 내지만, 실제 사용자는 더 불규칙하다. 어떤 사용자는 모호한 질문을 받고도 부정확한 답을 하고, 어떤 사용자는 단서를 추가하면서 목표를 바꾸며, 어떤 사용자는 질문 자체를 귀찮아한다. 이런 behavioral diversity는 현재 benchmark에 제한적으로만 들어간다.

또한 simulator가 제공하는 단서는 benchmark 설계자가 준비한 discriminative clue다. 제품 환경에서는 사용자가 충분히 식별력 있는 단서를 주지 못할 수 있고, 한 번의 clarification으로 후보가 줄어들지 않을 수도 있다. 따라서 DiscoBench 점수가 높은 모델도 multi-turn repair, partial clue handling, user frustration management까지 잘한다고 해석하면 과하다.

그럼에도 simulator 사용이 약점만은 아니다. 실제 사람을 넣으면 재현성과 비용이 급격히 나빠진다. DiscoBench는 benchmark로서 반복 가능한 평가를 우선하고, interaction diversity 일부를 포기한다. 후속 연구에서는 같은 seed task에 대해 여러 user persona와 noisy clue를 붙여 robustness를 측정하는 확장이 자연스럽다.

7.2 객관적 QA 중심 설계가 놓치는 주관적 모호성

DiscoBench는 객관적이고 검증 가능한 QA를 중심으로 한다. 이 선택 덕분에 checkpoint 정답과 ambiguity resolution을 명확히 평가할 수 있다. 그러나 실제 검색 에이전트의 모호성에는 선호, 목적, 예산, 리스크 허용도 같은 주관적 조건도 많다. "괜찮은 노트북 추천" 같은 질문은 후보가 많아서만 애매한 것이 아니며, 사용자 기준이 비어 있어 애매하다.

논문의 Criteria ambiguity가 이 방향을 일부 다루지만, 아직 ranking standard나 filtering condition 수준에 가깝다. subjective preference ambiguity는 더 복잡하다. 사용자는 가격을 중요하게 보는지, 휴대성을 보는지, 브랜드를 보는지, AS를 보는지 명확히 말하지 않을 수 있다. 이때 에이전트는 사실 검색보다 preference elicitation을 해야 한다.

후속 benchmark는 객관적 factual search와 주관적 preference search를 섞어 볼 필요가 있다. 특히 쇼핑, 여행, 의료 정보 탐색, 법률 상담 보조 같은 영역에서는 "정답"보다 "질문을 통해 의사결정 기준을 정제하는 능력"이 중요하다. DiscoBench는 그 출발점을 factual domain에서 안정적으로 만든 셈이다.

7.3 search backend와 reproducibility

Tavily 같은 hosted search backend는 현실성을 주지만 재현성 문제를 만든다. 논문은 index와 ranking freshness가 바뀔 수 있다고 설명한다. 같은 모델, 같은 prompt, 같은 question이어도 며칠 뒤에는 검색 snippet이 달라지고, 그에 따라 모델의 trajectory도 바뀔 수 있다. 이는 open web benchmark가 피하기 어려운 구조적 문제다.

저자들의 제안처럼 raw search response cache를 함께 공개하면 비교 가능성이 좋아진다. 다만 cache를 고정하면 다시 live search가 가진 현실성이 줄어든다. 운영 관점에서는 두 모드를 모두 볼 필요가 있다. 하나는 고정 cache 위에서 모델의 ambiguity policy를 비교하는 모드이고, 다른 하나는 live web 위에서 deployment robustness를 보는 모드다.

이 한계는 DiscoBench 결과를 해석할 때도 중요하다. 한 모델이 특정 sample에서 실패했을 때, 그것이 retrieval surface 문제인지, ambiguity detection 실패인지, clue integration 실패인지 분해해야 한다. 논문은 checkpoint와 behavior profile을 제공해 이 분해를 어느 정도 가능하게 만들지만, 완전한 원인 분석에는 trajectory log 공개가 더 필요하다.

7.4 deployment benchmark로 확장할 때 필요한 축

DiscoBench를 실제 배포 평가로 쓰려면 몇 가지 축이 추가되어야 한다. 첫째는 latency다. 질문을 한 번 던지는 것은 단순 token cost보다 훨씬 큰 지연을 만든다. 사용자가 응답할 때까지 agent는 멈춰야 하고, 비동기 작업이라면 상태를 유지해야 한다. 따라서 ask turn은 숫자 하나보다 task type별 허용 지연과 함께 해석되어야 한다.

둘째는 user burden이다. 같은 질문이라도 "어느 연도를 말씀하시나요?"처럼 답하기 쉬운 질문과, "정확한 기준을 더 설명해 주세요"처럼 사용자가 다시 생각해야 하는 질문은 비용이 다르다. DiscoBench의 CE-A와 CE-B는 질문의 정확성과 유용성을 보지만, 답변 난이도와 사용자 피로는 직접 측정하지 않는다. 후속 benchmark는 question specificity와 answerability를 함께 볼 필요가 있다.

셋째는 fallback policy다. 사용자가 clarification에 응답하지 않으면 에이전트는 어떻게 해야 하는가. 가능한 해석을 나열하고 진행할지, 가장 안전한 가정을 명시할지, 작업을 중단할지 결정해야 한다. 이 축은 enterprise search나 customer support agent에서 특히 중요하다. 사용자가 늘 협조적으로 단서를 제공한다는 가정은 실제 운영에서 자주 깨진다.

마지막은 auditability다. 모호성 때문에 질문했다면, 에이전트는 왜 질문했는지와 어떤 후보가 충돌했는지를 기록해야 한다. 이 로그는 사용자에게는 간단한 설명으로, 개발자에게는 trajectory debugging 자료로 쓰인다. DiscoBench의 checkpoint 설계는 이런 로그 구조와 잘 맞는다. 각 checkpoint에 ambiguity state와 action을 붙이면 나중에 모델 업데이트 후 정책 변화를 비교하기 쉽다.

8. 내 해석: 약점과 확장 제안

나는 DiscoBench가 검색 에이전트 평가에서 중요한 빈칸을 잘 찔렀다고 본다. 다만 가장 걸리는 부분은 Ask의 사용자 경험 비용이 아직 거칠게 처리된다는 점이다. 논문은 평균 ask turn, token, tool-use로 비용을 보지만, 실제 제품에서는 질문 한 번의 비용이 상황마다 다르다. 보고서 작성처럼 긴 작업에서는 질문이 도움이 될 수 있지만, 빠른 검색에서는 같은 질문이 이탈로 이어질 수 있다. 따라서 CE-A와 CE-B가 높아도, 언제 질문이 사용자 경험상 허용되는지까지는 별도의 모델링이 필요하다.

내가 이 benchmark를 확장한다면 다음 단계는 risk-aware clarification policy를 붙이는 쪽을 먼저 해볼 것 같다. checkpoint마다 오답 비용, 질문 비용, 검색 비용을 함께 추정하고, 모델이 단순히 모호성을 감지하는 데서 멈추지 않고 "지금 묻는 것이 전체 utility를 높이는가"를 결정하게 만드는 방식이다. 이전에 다룬 premature commitment 문제와 연결하면, 조기 답변을 막는 guardrail과 질문 정책을 하나의 trajectory controller로 묶을 수 있다.

또 하나의 후속 방향은 trajectory log를 이용한 학습이다. SearchHeavyGuess는 모델이 이미 후보 다중성을 본 상태에서 질문으로 전환하지 못한 사례이므로, supervised signal로 쓰기 좋다. 성공한 SearchThenAsk trajectory와 실패한 SearchHeavyGuess trajectory를 쌍으로 묶으면, "검색 결과가 몇 개 이상이면 질문하라" 같은 규칙보다 훨씬 섬세한 policy training이 가능해진다. 이 지점이 DiscoBench가 단순 평가셋을 넘어 agent training data로도 흥미로운 이유다.

8.1 이전 리뷰들과 이어지는 지점

DiscoBench는 최근 agent 평가 논의에서 반복해서 등장하는 조기 확정 문제와 강하게 연결된다. LiveBrowseComp가 live web search 사용 여부를 묻고, premature commitment 계열 연구가 불충분한 근거에서 답을 확정하는 습관을 다룬다면, DiscoBench는 그 사이에 있는 사용자 상호작용 지점을 다룬다. 모델이 실제 검색을 하더라도, 검색 결과가 underdetermined이면 사용자에게 돌아가야 한다는 점을 명시한다.

이 연결이 중요한 이유는 agent 평가가 점점 단일 능력 점수에서 벗어나고 있기 때문이다. 과거에는 모델이 정답을 알고 있는지, 검색을 쓸 수 있는지, tool call syntax를 맞추는지가 핵심이었다. 이제는 search state를 해석하고, 불확실성을 행동으로 바꾸고, 사용자와의 짧은 상호작용으로 trajectory를 고치는 능력이 필요하다. DiscoBench는 이 변화를 구체적인 표와 지표로 보여 준다.

또한 이 논문은 RAG 시스템의 query rewriting과도 이어진다. query rewriting은 보통 검색 recall을 높이기 위해 내부적으로 질의를 바꾸지만, 사용자의 의도가 빠져 있으면 rewrite만으로는 해결되지 않는다. 어떤 정보는 모델이 추론해서 채우면 위험하고, 사용자에게 물어야 한다. DiscoBench는 query rewriting과 clarification의 경계가 어디에 있는지 논의하게 만든다.

실무적으로는 agent 설계자가 이 benchmark를 보며 세 가지 로그를 남겨야 한다. 첫째, 검색 결과가 후보를 몇 개로 갈랐는지. 둘째, 그 상태에서 모델이 질문을 고려했는지. 셋째, 질문을 하지 않았다면 어떤 가정을 두고 진행했는지. 이 로그가 있어야 모델 개선이 prompt 수정인지, detector 학습인지, question generator 개선인지 판단할 수 있다.

9. 결론: deep search의 다음 병목은 질문 정책이다

DiscoBench는 검색 에이전트가 강해질수록 더 많은 웹 페이지를 찾고 더 긴 reasoning chain을 만들 수 있다는 흐름에 중요한 제동을 건다. 문제는 검색 능력이 부족해서만 생기지 않는다. 사용자 질문이 불완전할 때, 모델이 그 불완전성을 감지하고, 적절한 단서를 요청하고, 받은 단서를 경로에 다시 통합해야 한다. 이 세 능력 중 하나가 빠지면 최종 답은 쉽게 흔들린다.

실험 결과는 현재 모델들이 이 문제를 충분히 해결하지 못했음을 보여 준다. Neutral setting 최고 정확도가 43.1%에 머물고, Guided prompting도 detection F1은 크게 높이지만 final accuracy를 제한적으로만 개선한다. 질문 품질이 높은 모델이 질문을 거의 시작하지 않는 경우도 있고, 검색을 많이 하는 모델이 direct guess보다 나쁜 profile을 보이는 경우도 있다.

따라서 이 논문의 핵심 기여는 "좋은 검색 에이전트는 언제 검색을 멈추고 사용자에게 물어야 하는가"라는 질문을 benchmark로 만든 데 있다. 이는 RAG, deep research, browser agent, enterprise search assistant에 모두 연결된다. 실제 배포에서는 retrieval module, uncertainty detector, clarification generator, cost-aware controller가 함께 설계되어야 한다.

향후 검색 에이전트 평가는 final answer와 source citation만으로 충분하지 않다. 모델이 어떤 지점에서 후보 다중성을 봤는지, 그 순간 질문을 던졌는지, 사용자 단서가 들어온 뒤 검색 경로가 어떻게 바뀌었는지를 기록해야 한다. DiscoBench는 그 방향으로 가는 꽤 실용적인 기준점을 제시한다.

9.1 연구 흐름에서의 위치

DiscoBench의 가장 큰 의미는 deep search를 더 긴 검색과 더 긴 reasoning으로만 보지 않게 만든다는 데 있다. 검색 에이전트가 강해질수록 더 많은 문서를 읽고, 더 복잡한 chain을 구성하고, 더 긴 답변을 낼 수 있다. 그러나 사용자의 시작점이 모호하면 이 모든 능력은 잘못된 목표를 향해 정교하게 작동할 수 있다. 논문은 이 위험을 benchmark의 중심 문제로 세운다.

연구 흐름상으로는 세 갈래가 만난다. 첫째는 open-domain QA와 web search benchmark, 둘째는 ambiguity-aware QA, 셋째는 interactive agent 평가다. DiscoBench는 이 세 영역을 완전히 통합했다기보다, factual deep search라는 제한된 공간에서 교차점을 만든다. 그래서 범위는 좁지만 평가 신호는 선명하다. 모델이 검색을 할 수 있는지보다, 검색 중 질문할 수 있는지를 본다.

이 선명함은 후속 연구에도 장점이다. 연구자는 같은 task에 noisy user simulator를 붙일 수 있고, subjective preference ambiguity를 추가할 수 있으며, risk-aware cost function을 넣을 수 있다. 또한 SearchHeavyGuess와 SearchThenAsk trajectory를 이용해 policy learning을 시도할 수 있다. benchmark가 하나의 leaderboard에 머물지 않고 agent 학습 루프의 구성 요소가 될 수 있는 이유다.

결국 DiscoBench가 던지는 질문은 간단하다. 모델이 검색 결과를 많이 보는 것과, 그 결과가 아직 결정을 허용하지 않는다는 사실을 아는 것은 다르다. 후자의 능력이 충분하지 않으면 deep search agent는 더 많은 근거를 모아 더 설득력 있는 오답을 만들 수 있다. 이 논문은 그 위험을 정량화하고, 질문 정책을 검색 에이전트의 핵심 평가 대상으로 올려놓는다.

9.2 제품형 검색 에이전트에 주는 설계 힌트

제품형 검색 에이전트에 DiscoBench의 결과를 적용하면, 가장 먼저 필요한 것은 후보 다중성 로그다. 검색 결과 상위 문서들이 서로 다른 entity, 서로 다른 기준, 서로 다른 시간 조건을 가리키는 순간을 모델 내부 상태로 남겨야 한다. 현재 많은 에이전트는 최종 답과 citation만 저장하지만, clarification policy를 개선하려면 후보가 갈라진 지점과 모델이 그 갈라짐을 어떻게 처리했는지까지 추적해야 한다.

두 번째 힌트는 질문 생성기를 answer generator의 부속 기능으로 두지 말아야 한다는 점이다. 질문은 예쁜 자연어 문장을 만드는 기능이면서 동시에 search space를 줄이는 제어 행동이다. 따라서 좋은 질문은 사용자가 쉽게 답할 수 있어야 하고, 답을 받았을 때 다음 검색식이 명확히 바뀌어야 한다. "조금 더 자세히 알려주세요"처럼 넓은 질문은 대화상으로는 무난해 보여도 DiscoBench식 checkpoint pass에는 도움이 적을 가능성이 크다.

세 번째는 prompt만으로 해결하려는 접근의 한계다. Guided setting에서 detection F1이 크게 오르는 것은 instruction이 중요하다는 뜻이지만, final accuracy 상승폭이 제한적이라는 사실은 별도 policy 학습이 필요하다는 신호다. 운영 시스템에서는 system prompt에 "애매하면 물어보라"를 넣는 것에 그치지 않고, 검색 결과의 분산도, source conflict, user cost, task risk를 조합해 Ask threshold를 조정해야 한다.

네 번째는 evaluation harness다. 실제 서비스에선 샘플 몇 개를 사람이 읽어 보는 방식으로는 clarification 능력을 안정적으로 측정하기 어렵다. DiscoBench처럼 checkpoint, ambiguity type, action log, CE-A/CE-B, cost를 함께 기록하면 모델 업데이트가 질문 정책에 미치는 영향을 더 잘 볼 수 있다. 예를 들어 새 모델이 final answer accuracy를 조금 올렸더라도 SearchHeavyGuess 비율이 늘었다면, 장기적으로는 더 위험한 모델일 수 있다.

마지막으로, DiscoBench는 사용자에게 묻는 행동을 시스템 실패로 보지 않게 만든다. 검색 제품에서는 사용자가 한 번에 답을 받는 경험이 중요하지만, 고위험 또는 고비용 작업에서는 잘못된 확신보다 짧은 확인 질문이 더 낫다. 핵심은 무조건 많이 묻는 방식에 있지 않고, 질문이 답의 품질을 실제로 높이는 시점을 찾는 데 있다. 이 논문은 그 시점을 데이터와 지표로 다루기 시작했다는 점에서 agent evaluation의 실용적 기준점이 된다.

9.3 평가셋을 읽을 때의 주의점

다만 DiscoBench 점수를 절대적인 모델 순위로만 읽는 것은 조심해야 한다. 검색 backend, simulated user, judge model, prompt template이 모두 결과에 영향을 준다. 특히 live search는 시간이 지나면 검색 결과와 snippet이 달라질 수 있고, judge model도 모호성 해소 여부를 완벽하게 판정한다고 보기 어렵다. 이 논문의 숫자는 특정 평가 장치 안에서의 비교 신호로 읽는 편이 안전하다.

그럼에도 이 평가셋이 주는 방향성은 분명하다. 좋은 검색 에이전트는 많은 정보를 모으는 능력과 함께, 그 정보가 아직 결정을 허용하지 않는다는 사실을 감지해야 한다. 검색 결과가 풍부할수록 모델이 더 자신 있게 틀릴 수 있다는 점은 기존 RAG 평가에서 자주 과소평가된다. DiscoBench는 그 취약점을 행동 로그와 checkpoint 지표로 드러낸다.

따라서 후속 비교에서는 단순히 어떤 모델이 몇 점을 받았는지보다, 어떤 profile이 줄었는지를 보는 것이 더 유용하다. SearchHeavyGuess가 줄고 SearchThenAsk가 늘었는지, CE-A는 유지하면서 ask turn이 과도하게 늘지 않았는지, guided prompt 없이도 neutral setting에서 trigger가 켜지는지 같은 변화가 실제 제품 품질과 더 가깝다. 이 논문은 그런 비교 문법을 제공한다.

또한 DiscoBench를 모델 개발 루프에 넣을 때는 실패 sample을 평균 점수 뒤에 숨기지 않는 편이 좋다. Entity ambiguity에서 틀린 사례, Criteria ambiguity에서 암묵적 기준을 세운 사례, Factual Inaccuracy에서 사용자 설명을 그대로 믿은 사례는 서로 다른 수정 방향을 요구한다. 하나는 후보 비교와 disambiguation query가 필요하고, 하나는 ranking 기준 추출이 필요하며, 하나는 evidence conflict detector가 필요하다. 유형별 failure bucket을 따로 관리해야 benchmark가 실제 개선으로 이어진다.

정리하면 이 논문은 현재 에이전트가 부족한 지점을 꽤 운영 친화적인 언어로 바꿔 준다. "검색을 더 하라"는 지시만으로는 부족하고, "언제 검색을 멈추고 어떤 정보를 사용자에게 물을지"가 별도 정책으로 필요하다. 이 정책은 모델의 reasoning 능력, 검색 결과의 구조, 사용자 비용, 과제 위험도를 함께 봐야 한다. DiscoBench는 그 복합 판단을 처음부터 완벽하게 해결하지는 못하지만, 적어도 측정 가능한 문제로 만들어 다음 연구가 비교할 기준선을 제공한다.

이 기준선을 제품 개발에 옮기면, 평가 보고서에는 적어도 세 가지 수치가 함께 들어가야 한다. 최종 정확도, 모호성 탐지 지표, 그리고 SearchThenAsk 전환율이다. 최종 정확도만 오르면 모델이 더 강해 보일 수 있지만, SearchHeavyGuess가 동시에 늘면 사용자가 입력한 모호한 조건을 더 자신 있게 잘못 해석하는 방향으로 개선됐을 수도 있다. DiscoBench가 유용한 지점은 바로 이런 위험한 개선을 분리해서 볼 수 있게 한다는 데 있다.

따라서 이 초안이 강조하는 실무적 결론은 명확하다. 검색 에이전트의 품질 관리는 답변 텍스트만 보는 사후 평가에서 멈추면 안 된다. 검색 중간에 후보가 어떻게 갈라졌는지, 그 갈라짐을 모델이 질문으로 전환했는지, 사용자 단서가 들어온 뒤 경로가 얼마나 정상화됐는지를 함께 기록해야 한다. DiscoBench는 그 기록 단위를 benchmark 형태로 정리한 연구다. 이 점이 후속 에이전트 평가의 출발점이다.

10. 요약 정리

• DiscoBench는 search agent가 multi-hop deep search 중 모호성을 감지하고 사용자에게 clarification을 요청할 수 있는지 평가하는 benchmark다.
• 데이터셋은 211개 sample과 463개 ambiguity instance를 포함하며, Entity, Version, Criteria, Factual Inaccuracy 네 유형을 다룬다.
• 에이전트 행동은 Search, Ask, Answer로 정식화되고, checkpoint 단위로 task utility, ambiguity detection, interaction strategy, cost efficiency가 평가된다.
• Neutral setting 최고 정확도는 Doubao-Seed-2.0-Pro의 43.1%이며, Guided prompting은 detection F1을 크게 높이지만 최종 정확도 개선은 제한적이다.
• 질문을 잘 만드는 능력과 질문을 시작하는 능력은 분리된다. Qwen3.6-Max처럼 질문 품질은 높지만 거의 질문하지 않는 모델이 존재한다.
• SearchHeavyGuess는 더 많이 검색하고도 질문하지 않는 실패 모드이며, 평균 pass rate가 DirectGuess보다 낮아 retrieval 반복이 항상 이득은 아님을 보여 준다.
• Ablation에서는 검색 도구 제거 시 성능이 급락하고, 모호성을 제거하면 성능이 크게 올라 DiscoBench가 clarification-aware deep search를 실제로 측정함을 확인한다.
• 후속 연구에서는 simulator 기반 단서 제공을 넘어 noisy user, subjective preference, risk-aware clarification policy, trajectory-level training signal로 확장할 여지가 크다.
• 실제 제품 관점에서 이 논문은 deep research agent의 다음 병목이 검색량보다 질문 타이밍과 사용자 단서 통합에 있음을 분명히 보여 준다.