테스트시 검색 이득은 구조적 워크플로 계획의 선택 실패를 가린다

무엇인가

이 논문은 재난 대응용 구조적 워크플로 계획에서 테스트시 추론의 성능 향상이 어디서 오는지 감사한다. DisasterBench에서는 자연어 목표를 26개 도구의 타입 지정 워크플로로 구성하는데, 인터페이스 제약을 모두 만족해도 객체 분할 맵을 생성 이미지 대신 산사태 분할 단계에 넣는 식의 정보 흐름 오류가 생길 수 있다. 기존 비교는 측정된 이득이 방법 이름이 말하는 메커니즘에서 왔다는 가정과 최종 정확도가 방법을 요약한다는 가정에 기대지만, 프롬프트·후처리·후보 유지·선택이 다르면 둘 다 흔들린다. 저자들은 이를 발견, 구조 검증, 선택의 세 단계로 분해하는 DVS 분석을 제안한다.

어떻게 동작하나

실험은 233개 전문가 검증 과제 중 50개를 개발에 쓰고 183개를 평가에 쓴다. GPT-4o-mini와 Qwen3.5-9B에서 독립 샘플링(IS), 명목상 CoT-tree, 프롬프트 매칭 IS, 다중 연산자 검색(MO-Tree)을 비교한다. CoT-tree는 기존 MCTS 구현의 CoT 전용 변형으로 다른 네 연산자를 끄고 각 CoT 샘플을 별도 요청의 독립 리프로 유지하므로, 완전 워크플로 수준에서는 비적응적이다. 프롬프트 매칭 IS는 같은 확장 프롬프트·디코딩·생성 수를 쓰되 트리를 만들지 않고 완전 워크플로를 독립 샘플링한다. IS·CoT-tree·프롬프트 매칭 IS는 GPT-4o-mini 32회, Qwen 34회 생성한다. MO-Tree는 재표현, 직접 답변, CoT, 분할정복, 자기개선을 결합한 적응형 비교군이다. 예산은 모델·서빙 백엔드별 실제 토큰 지출로 측정하고, 모든 후보 풀은 추출·정규화·구조 검증·선택의 공통 파이프라인을 거친다. 선택은 정확한 워크플로 동일성으로 그룹화한 뒤 다수결로 하며, 각 절차의 고유 유지 규칙에 따라 투표 중복을 센다. 구조 검증은 표현과 도구 인터페이스의 일관성만 보고, 입력값·타입의 의미적 적합성은 보지 않는다.

무엇과 다른가

핵심 결과는 CoT-tree의 겉보기 검색 이득이 트리 구조에서 나왔다는 증거가 없다는 것이다. GPT-4o-mini에서 CoT-tree는 183개 중 153개 과제에서 정답 워크플로를 발견했고 IS는 139개였지만, 프롬프트 매칭 IS는 154개로 CoT-tree와 1개 차이(p=1.000)였고 IS보다 15개 많았다(p=.0015). Qwen에서는 프롬프트 매칭 IS가 160개로 CoT-tree 두 런의 162·157개 범위 안에 들었고, 선택 정확도는 127개 대 132·133개로 유의하지 않았다. MO-Tree도 일관되게 IS를 앞서지 못했고, Qwen에서는 Oracle 커버리지가 유의하게 낮았다(p≤.008). MO-Tree의 원래 탐색 폭을 복원하면 추론 비용이 54% 늘지만 Oracle 정답은 3개만 회복됐고, 40개 과제 파일럿도 유의한 우위가 없었다. 11개 후보 풀 모두에서 Oracle EM이 Selected EM보다 18~34개 높았다. 예산을 늘리면 발견은 계속 개선되지만 선택은 일찍 포화됐다. GPT-4o-mini CoT-tree는 8회 생성에서 전체 예산 Selected 131개에 도달했지만 Oracle 커버리지는 153개까지 증가했고, Qwen IS는 Oracle이 1회 107개에서 전체 예산 159개로 늘어난 반면 Selected는 4회 이후 124~129개에 머물렀다. 9개 주요 풀의 Oracle–Selected 손실 231건 중 Top-2에 정답이 있는 경우는 137건(59.3%), Top-3는 181건(78.4%)이었다.

어떻게 쓰나

정답 워크플로는 구조 검증에서 사라지지 않고 선택에서 사라진다. 11개 풀 전체에서 구조 필터링이 Oracle-positive 과제의 마지막 정답 워크플로를 제거한 경우는 없었다. 45,246개 정규화 후보 중 정확 일치 후보가 구조 검증에 실패한 사례도 없었다. 발견됐지만 선택되지 않은 289개 풀-과제 중 265개(91.7%)가 엄격한 투표 손실, 24개가 동률 손실이었다. 필터링은 16개 풀-과제에서 선택 결과를 바꿨고 6개를 바로잡았지만 새 오류는 만들지 않았다. 반면 다수결은 풀마다 18~34개 과제(초록 기준 10~19%)에서 이미 발견된 정답을 선택하지 않았다. 60개 투표 손실 사례 감사에서 57개(95.0%)가 실질적 계획 오류였고, 35개는 잘못된 도구 선택, 22개는 잘못된 의존성 구성이었다. 나머지 3개는 독립 단계의 의미 보존 순열이었다. 예컨대 Task 123에서는 Building_damage_assessment가 Change_Mapping_and_Detection을 대체한 워크플로가 22표를 얻어 정답의 2표를 이겼고, Task 22에서는 독립 분기를 순차 의존으로 바꾼 잘못된 워크플로가 GPT-4o-mini IS에서 32표 중 25표를 얻었다. 같은 워크플로가 프롬프트 매칭 IS에서는 1표, CoT-tree에서는 2표였다.

전제와 한계

다수결 실패는 단순한 Exact Match 인공물이 아니다. 265개 엄격 투표 손실의 잘못된 승자 중 참조 도구 순서를 보존한 경우는 27.5%뿐이었고 완전한 파라미터 정확성을 가진 경우는 없었다. 도구 순서가 맞는 승자 73개 중 68개는 교차 단계 입력 바인딩이 틀렸고, 5개는 리터럴 입력값만 달랐다. 잘못된 승자는 반복되기도 한다. Qwen에서 CoT-tree와 IS는 공유 투표 손실 15개 중 14개(93%)에서 같은 잘못된 워크플로를 선택했고, IS의 런 간 반복은 25개 중 24개(96%)였다. GPT-4o-mini에서는 IS가 CoT-tree의 잘못된 승자를 22개 중 5개(23%)만 반복했고, 평균 잘못된 승자 점유율은 IS 68%에서 CoT-tree 41%로 낮아졌다. 또한 GPT-4o-mini IS의 투표 손실 18개 중 17개에서는 가장 좋은 정답이 잘못된 승자와 2표 이내에 들지 못할 만큼 오류가 집중됐다.

도구 명세를 아는 의미 검증기는 선택 격차를 안정적으로 메우지 못한다. Top-3 검증기는 다수결이 틀렸지만 정답이 Top-3에 있는 181개 풀-과제에서 90개(49.7%)를 맞혔고, 균등 무작위 기대 66개보다는 나았다. 그러나 최소 두 개의 유효 워크플로 그룹이 있는 경합 사례 전체에서 다수결 오류 90개를 고친 대신 정답 다수결 결정 175개를 뒤집었다. 9개 풀 중 8개가 하락했고 4개는 유의했다. 투표 마진으로 검증기 개입을 제한해도 신뢰할 만한 이득은 없었다. 최선의 사후 임계값 t=.15도 4개 풀-과제를 더했을 뿐(p=.69)이었고, leave-one-run-out 임계값 선택은 순변화 -1이었다. 잘못된 개입은 고친 경우보다 단계를 더 추가하는 경우가 많았다(52.6% 대 27.8%).

개발자 관점에서 이 논문은 LLM 에이전트의 검색·투표·검증 조합을 평가할 때 방법 라벨이 아니라 실제 실행 파이프라인을 감사해야 한다고 말한다. 후보 발견과 최종 선택을 분리해 Oracle EM과 Selected EM을 함께 보고하고, 프롬프트 매칭 대조군과 실제 토큰·분기·유지 규칙을 명시해야 한다. 선택 단계에서는 교차 단계 의미 호환성, 후보 지지도, 긴 워크플로 선호 같은 편향을 점검할 필요가 있다. 저자들이 밝힌 한계는 분명하다. DisasterBench 한 벤치마크와 두 모델 계열만 썼고, 오프라인 워크플로 구성만 평가해 런타임 실행 효과는 범위 밖이다. CoT-tree 설정이 비적응적이고 MO-Tree의 분기가 서빙 백엔드에 따라 달라지므로, 이 결과를 적응형 트리 탐색 일반의 무효성으로 확대하지 않는다. 감사는 60개 표본에 LLM 보조 라벨과 세 명의 인간 검토를 적용했지만 독립적 블라인드 주석은 아니며, 선택 분석도 다수결과 LLM 판정자에 한정된다. 학습형·실행 인지형·신뢰도 보정 선택기는 Oracle 커버리지를 더 회복할 수 있다는 여지를 남긴다.