에이전트가 요청받지 않은 정보까지 스스로 캐묻도록 학습한다
Asking for What Was Never Requested: Horizontal and Vertical Proactivity in Agents
무엇인가
도구를 쓰는 에이전트는 보통 사용자가 명시적으로 요청한 것에 응답한다. 그러나 작업을 끝내려면 사용자가 말하지 않은 정보가 필요한 경우가 많다. 논문이 드는 예에서 고객은 주문에 담긴 부츠를 같은 소재의 8 사이즈로 바꿔달라면서 이름과 우편번호만 주고 주문번호나 이메일은 주지 않는다. 이런 정보를 기다리는 에이전트는 같은 질문을 열여섯 번 되풀이하고 결국 부츠를 바꾸지 못한다. 기존의 선제적(proactive) 에이전트 연구는 주로 언제 스스로 행동할지를 다뤘고, 무엇을 캐물을지는 거의 다루지 않았다. 이 논문은 선제성의 '내용'이라는 축을 새로 세운다.
어떻게 동작하나
저자들은 선제성을 두 방향으로 나눈다. 수평적 선제성은 현재 문맥이 이미 지목하고 있는, 말해지지 않은 정보를 향한다. 수직적 선제성은 앞서 찾은 증거가 비로소 이름을 붙여주는 필요를 향한다. 이를 측정 가능하게 만드는 것이 필요 그래프(need graph)다. 과제가 요구하는 증거 단위를 노드로 두고, 한 필요가 다른 필요를 먼저 해결해야만 이름 붙여질 수 있는 곳에 선행 간선을 놓는다. 그래프는 MuSiQue, StrategyQA, 2WikiMultiHopQA가 자체적으로 배포하는 분해 구조에서 기계적으로 복원되며, 사람이나 모델이 노드와 간선을 쓰지 않는다. 평가 지표는 완료된 실행 기록과 그래프만으로 계산된다. breadth는 독립적인 탐색 계열을 첫 필요 너머로 진행시킨 수로 수평적 선제성을, 깊이 가중 재현율과 가장 깊게 해결한 필요는 수직적 선제성을 읽는다. 필수 증거 커버리지는 둘 다를 읽는다. 정지에 대해서는 모든 것을 찾은 뒤 멈추는지, 아직 못 찾았는데 계속 묻는지를 각각 비율로 본다. 모델 심사자는 쓰지 않는다.
무엇과 다른가
Q&D(questioner and drafter)는 에이전트를 질문자와 초안 작성자로 나눈다. 질문자는 과제, 지금까지의 증거, 현재 초안, 지난 질문들을 보고 한 번에 질문 하나를 던지거나 멈춘다. 검색기가 과제의 증거 풀에서 답하고, 고정된(frozen) 초안 작성자가 증거로 초안을 다시 쓴다. 마지막에는 모든 실험 조건에서 동일한 고정 답변자가 단어 수 상한 아래 최종 답을 쓴다. 초안 작성자가 고정 함수이므로 상태의 모든 변화는 질문 하나가 일으킨 것이고, 따라서 각 질문은 그 뒤에 벌어진 일로 공로를 인정받을 수 있다. 학습은 실행을 한 지점에서 갈라놓고 대안 질문 8개를 샘플링한 뒤, 그 실행을 만들어낸 정책으로 각 후보를 끝까지 이어가며 이뤄진다. 후보 쌍의 순위는 결과만으로 정한다. 먼저 그 실행이 과제를 답했는지(학습 쌍의 6%를 차지한다), 다음으로 누가 완전한 증거에 더 빨리 도달했는지, 다음으로 각 턴이 증거를 얼마나 더했는지다. 필요 그래프가 미완으로 표시한 상태에서는 멈추기보다 묻는 쪽을 위로 둔다. 훈련은 모방, 질문 쌍에 대한 직접 선호 최적화(DPO), 질문 쌍과 정지 대조를 함께 쓰는 단계의 세 단계로 진행된다. 질문자는 그래프를 보지 않으므로 그래프가 없는 환경에서도 돌아간다.
어떻게 쓰나
실험은 MuSiQue, StrategyQA, 2WikiMultiHopQA의 held-out 테스트 분할에서 벤치마크당 200개 과제, 롤아웃 시드 2개로 읽는다. 같은 검색 호출 수(equal spend)에서 훈련된 8B 질문자는 같은 모델을 프롬프트한 것보다 필수 증거를 MuSiQue에서 11.2%포인트, StrategyQA에서 7.0, 2WikiMultiHopQA에서 5.0 더 많이 회수했다. 깊이 가중 재현율은 12.5, 5.4, 5.5%포인트 올랐고, 가장 깊게 해결한 필요도 MuSiQue에서 0.22단계, StrategyQA에서 0.10단계 더 깊어졌다. 사슬이 가장 깊은 MuSiQue에서는 필수 증거의 90%를 찾아 78%에 그친 프롬프트 모델을 앞섰다. 15배 큰 GPT-OSS-120B를 같은 역할로 프롬프트한 것과 비교하면 MuSiQue에서 7.0, StrategyQA에서 4.3%포인트 앞서고 2WikiMultiHopQA에서는 3.5%포인트 뒤진다. 이득은 질문 수나 길이에서 오지 않는다. 훈련된 질문자는 필요 하나를 찾는 데 MuSiQue에서 토큰을 40% 덜 쓴다(11,610 대 19,354). 훈련된 질문자의 질문을 같은 벤치마크 다른 과제에서 무작위로 뽑은 질문으로 바꾸면 커버리지가 MuSiQue에서 34.7, StrategyQA에서 63.3%포인트 무너진다. 길이 통제도 있다. 훈련된 질문은 17.5단어로 프롬프트 모델의 13.1단어보다 길지만, 프롬프트 모델에 같은 질문 토큰을 허용해도 MuSiQue와 StrategyQA 개발 과제에서 각각 14.9, 4.7%포인트 뒤진다. 구조적 검색 알고리즘 PAR2-RAG는 세 모델 어디에서도 같은 모델의 단순 프롬프트를 이기지 못했고, equal spend에서 훈련된 질문자를 앞선 비교 대상은 MuSiQue에서 Claude Opus 5 프롬프트뿐으로 2.9%포인트 차이다.
전제와 한계
스스로 멈추게 두면(own stop, 최대 8회 호출) 훈련된 질문자는 모든 스위트에서 두 프롬프트 모델보다 질문을 적게 하고 MuSiQue에서는 같은 모델보다 9.6, GPT-OSS-120B보다 10.1%포인트 앞선다. StrategyQA에서는 GPT-OSS-120B에 3.6%포인트 뒤지지만 그 모델은 두 배의 질문을 한다. 일이 끝난 뒤 멈추는 비율은 같은 모델 프롬프트보다 29~33%포인트 높다. 다만 추가로 찾은 증거가 아직 답으로 이어지지는 않는다. MuSiQue에서 답의 근거가 되는 증거를 9.7%포인트 더 자주 찾지만, 프롬프트 모델의 정답률을 감안하면 약 4.3%포인트의 정답 상승을 함의하는데 이는 표본이 탐지할 수 있는 4.7%포인트 아래이고 관측된 2.4%포인트와 일치한다. StrategyQA에서는 그 증거를 찾지 못한 채 끝난 실행의 92%, 86%가 스스로 멈춘 선택이었다. 훈련 없이 τ²-bench의 고객 서비스 에이전트에 그대로 넣으면, 시뮬레이션 고객과 대화당 16개 질문이 허용되는 설정에서 리테일 과제 성공률이 두 프롬프트 변형에서 13%·12%에서 34%·32%로 오르고, 항공에서는 6.9, 6.4%포인트 오른다. 리테일 대화당 질문은 1.3, 1.4개 줄었다. 15배 큰 GPT-OSS-120B(리테일 성공률 17%·19%)와 비교하면 성공률에서 17.0, 12.7%포인트 앞서면서 고객의 후속 턴은 1.6, 1.8회 줄인다.
실무 관점에서 이 논문이 주는 것은 프롬프트 한 줄이 아니라 설계 패턴이다. 에이전트를 질문자와 초안 작성자로 분리하고 초안 작성자를 고정하면, 어떤 질문이 실제로 무엇을 가져왔는지 사후에 셀 수 있다. 보상 모델이나 심사 LLM 없이 실행 결과만으로 선호 쌍을 만들 수 있다는 점은 자체 데이터로 질문 정책을 학습하려는 팀에 특히 실용적이다. 또 하나는 평가 지표다. 질문 수를 늘리면 커버리지가 올라가므로 '더 많이 묻기'가 '더 잘 묻기'로 오인되기 쉽다. 같은 호출 수에서 비교하고 깊이와 폭, 정지 시점을 따로 재는 방식은 사내 RAG·툴 에이전트 평가에도 그대로 옮길 수 있다. 다만 이 방법은 필수 증거와 선행 관계가 알려진 과제를 학습에 요구한다. 그래프를 만들 수 없는 도메인에서는 지표를 그대로 쓸 수 없고, 훈련된 질문자를 전이하는 쪽이 현실적이다.
저자들이 밝힌 한계는 분명하다. 보고된 두 시드는 하나의 지도학습 체크포인트와 하나의 쌍 내보내기를 공유해서, 신뢰구간이 과제 변동만 추정하고 그 체크포인트와 내보내기에서 오는 변동은 잡지 못한다. 사전에 정한 체크포인트 선택 규칙을 만족한 체크포인트가 없어 미리 고정한 두 번째 근거로 설정을 유지했다. 학습 라벨과 주 평가 지표가 같은 필요 그래프를 공유하고, 정답 여부는 학습 쌍의 6%만 결정하며, 정답은 아직 감지 가능하게 움직이지 않는다. 배포된 검색 풀이 작아서 대부분의 선행 간선이 검색을 실제로 막지 않으므로, 수직적 결과는 분해 구조상의 깊이에 관한 것이다. MuSiQue와 StrategyQA는 과제당 탐색 계열이 하나뿐이라 breadth는 첫 필요를 넘겼는지만 기록한다. 후보 질문과 롤아웃은 언어 모델에서 나오고, 라벨 규칙에 대한 사람 검증은 한 스위트에서만 이뤄졌으며, 사용자 대상 수치는 모두 시뮬레이션 고객에서 나왔다. Q&D는 한 번의 오프폴리시 학습이고 온폴리시 강화학습과 비교하지 않았으며, 길이 통제는 held-out에서 돌리지 않았다.