SearchJev가 검색 에이전트의 잦은 짧은 판단을 로짓 한 번으로 대체한다

무엇인가

LLM 기반 검색 에이전트는 추론과 검색을 번갈아 수행하면서 매 스텝마다 짧은 판단을 반복한다. 이 문서가 관련 있는가, 근거가 충분한가, 다음에 어느 링크를 열어야 하는가 같은 결정들이다. 논문은 이를 카너먼의 구분에 빌려 System-1 판단으로 규정하고, 계획과 답변 생성에 필요한 System-2 추론과 분리한다. 문제는 두 종류를 같은 생성 과정으로 처리할 때 생긴다. 짧은 판단마다 토큰을 순차 디코딩해야 하므로 지연이 쌓이고, 프롬프트로 물어 얻은 확신도는 캘리브레이션이 어긋나 있다. 태스크별 리랭커나 질의 복잡도 분류기는 개별 기능만 담당하고 각각 별도 모델과 지도가 필요하다.

어떻게 동작하나

SearchJev의 핵심은 스키마 조건부 토큰 로짓 읽기다. 각 판단 필드마다 자연어 질문과 합법 선택지 집합이 스키마로 주어지고, 선택지에는 A, B처럼 어휘집에 이미 존재하는 단일 토큰 라벨이 붙는다. 모델은 검색 상태와 스키마를 합친 입력을 받아 첫 출력 위치의 어휘 로짓 벡터를 얻고, 합법 라벨에 해당하는 로짓만 소프트맥스로 정규화해 결정 분포를 만든다. 선택지 설명 자체는 여러 토큰이어도 되고 라벨만 단일 토큰이면 된다. 별도 파라미터를 추가하지 않고 기존 LM 헤드를 그대로 쓰며, JSON 파싱도 순차 생성도 필요 없다.

무엇과 다른가

확률을 신뢰할 수 있게 만드는 장치가 SLCD(Soft-Label Learning for Calibrated Decisions)다. 지도 출처마다 신뢰도가 다르므로 정답을 원-핫이 아니라 선택지 위의 소프트 타깃 분포로 표현하고, 교차엔트로피와 Brier 손실을 가중 합으로 결합해 그 분포를 직접 적합한다. 두 손실 모두 proper scoring rule이라 결합 손실의 최소점이 소프트 타깃 분포와 일치한다. LLM이 붙인 라벨, 데모, 구성된 리라이트에는 가중치 0.5를, 나머지에는 1을 준다. 스키마 문구를 중국어와 영어로 바꿔 쓰고 순서 없는 필드의 선택지는 섞어 위치 편향을 줄인다. 학습 후에는 검증셋 5,000개 판단으로 출력 타입별(Choice, Score, Noul) 온도를 적합해 확률 스케일을 조정하며, 검증 표본이 부족한 타입은 전체 타입에 맞춘 온도를 쓴다.

어떻게 쓰나

이 모델은 이중 시스템 에이전트에 들어간다. System 2(Qwen3.5-27B)는 계획, 질의 생성, 최종 답변 작성을 맡고, SearchJev는 스키마로 정의된 짧은 판단만 처리한다. 각 필드에서 최대 확률이 임계값 δ 이상이면 그 결정을 수용하고, 아니면 같은 질문을 System 2가 합법 선택지 안에서 해결한다. δ가 위임량을 조절한다. 검색 컨트롤러는 확정된 판단을 search, open, rerank, stop 같은 행동으로 매핑한다. 평가를 위해 여섯 가지 판단 유형(routing, rewriting, relevance, sufficiency, navigation, verification)을 하나의 상태-스키마 형식으로 통일한 SearchDecision-Bench도 함께 제안한다. BANKING77, LCQMC, QReCC, T2Ranking, DuReader-Retrieval, MuSiQue, VitaminC 등에서 데이터를 모으고, OOD 평가에는 FRAMES, RAGTruth, CANDY, Search Arena, AgentRewardBench, QReCC 테스트 분할을 쓴다.

전제와 한계

결과는 결정 수준과 에이전트 수준 모두에서 제시된다. SearchDecision-Bench의 여섯 개 in-distribution 계열에서 SearchJev-0.8B와 4B는 같은 크기 Qwen3.5 AR(JSON)보다 모든 계열에서 판단 품질이 높고, 평균 ECE는 0.8B에서 74.4%, 4B에서 40.7% 낮아졌다. 판단 지연은 같은 크기 대비 5.2~5.3배, Jev 1.13 대비 7.2~9.6배 빠르다. BrowseComp-Plus에서는 100개 질문을 무작위 표본으로 한 번씩 실행해, 이중 시스템 에이전트가 46.0%(0.8B)와 54.0%(4B) 정확도를 기록했다. System-2 단독(27B)은 45.0%, Jev 1.13 에이전트는 46.0%였다. System-2 단독 대비 중앙 능동 시간이 3.7~4.7배 빨라지고 출력 토큰은 3.3~4.8배 줄었다. Jev 1.13 에이전트와 비교하면 SearchJev-4B는 정확도를 8.0%포인트 올렸고, 0.8B는 같은 정확도에서 호출 수와 토큰, 시간을 더 적게 썼다.

학습하지 않은 데이터로의 전이도 일부 확인된다. OOD에서 두 크기 모두 같은 크기 Qwen3.5 AR(JSON)보다 routing, rewriting, relevance가 좋았고 routing은 11.9~12.1%포인트 올랐다. rewriting에서는 Jev 1.13도 앞섰고, 4B는 relevance에서도 앞섰다. 속도 이점은 유지되어 같은 크기 대비 5.3~5.5배, Jev 1.13 대비 7.4~9.9배 빠르다.

실무 관점에서 이 논문이 주는 신호는 명확하다. 검색 파이프라인의 매 스텝에서 LLM을 불러 JSON 판단을 받아오는 구조라면, 그 판단을 단일 토큰 로짓 분류로 바꾸는 것만으로 지연과 토큰 비용을 크게 줄일 수 있다. 특히 확신도에 따라 위임 여부를 정하는 게이트는 잘못된 판단을 비용으로 흡수하는 안전장치이므로, 도입 시 임계값 δ와 검증셋 규모를 먼저 정해야 한다. 다만 캘리브레이션은 검증 데이터에 온도를 적합하는 방식이라 도메인이 바뀌면 다시 맞춰야 하고, 판단 스키마와 선택지 라벨을 단일 토큰으로 설계하는 제약도 감수해야 한다.

저자들이 밝힌 한계도 분명하다. Jev 1.13은 in-distribution에서 navigation이, OOD에서 routing과 verification이 더 강했고 평균 ECE가 가장 낮았으며 navigation과 verification 캘리브레이션이 가장 좋았다. OOD에서 verification은 0.8B에서 개선됐지만 4B에서는 오히려 나빠졌다. 저자들은 학습된 판단 선호가 캘리브레이션보다 데이터 소스 간에 더 일관되게 전이된다고 정리한다. 또한 검증 표본이 부족한 출력 타입은 전체 타입에 맞춘 온도를 사용하고, BrowseComp-Plus 평가는 100개 질문을 한 번씩만 실행한 결과라는 점이 전제로 깔려 있다.