PANINI-DR가 공유 워크스페이스로 딥리서치 오류 전파를 막는다

무엇인가

딥리서치 질문은 여러 출처에 걸친 증거를 모으고 연결해야 하며, 어떤 문서가 관련 있는지 처음에는 드러나지 않는다. 질문을 하위 질문으로 쪼개고, 각각의 증거를 찾고, 그 결과를 다시 다음 탐색의 입력으로 쓰는 반복 과정이 필요하다. 문제는 이 중간 결과가 여러 번의 검색과 모델 호출을 거치며 누적된다는 점이다. ReAct처럼 진행 상태를 상호작용 이력에 암묵적으로 남기는 방식에서는 이력이 길어질수록 앞선 발견을 다시 꺼내 쓰기 어려워지고, 입력 중간 정보 활용이 떨어진다는 연구들도 있다. 더 나쁜 것은 의존관계를 타고 오류가 전파된다는 점이다. 논문이 드는 예에서, 캠프 데이비드 협정 서명 당시 대통령을 카터가 아니라 레이건으로 잘못 특정하면, 이후에는 '잘못된 인물의 아내'에 대한 정확한 정보를 찾아 나이까지 올바르게 계산하고도 최종 답은 틀리게 된다.

어떻게 동작하나

PANINI-DR은 이 두 가지 문제, 즉 연구 상태 유지와 중간 발견의 검증을 분리하는 다중 에이전트 하네스다. 중심에는 Orchestrator가 있고, 먼저 Planner가 Generative Semantic Workspace(GSW) 표현으로 구조화된 연구 계획 P0를 만든다. 계획은 질문이 제공한 정보, 해결해야 할 하위 질문들, 그리고 그 답들 사이의 의존관계와 계산을 기록한다. 의존구조는 방향성 비순환 그래프(DAG)로, 노드는 하위 질문과 최종 답 타깃 v*에 대응하고 간선 u→v는 u의 발견이 v를 푸는 데 쓰인다는 뜻이다. 각 노드의 미지의 답은 GSW 계획에서 빈칸으로 표현되고, Planner는 그 빈칸의 관계와 질문 맥락을 반영한 자연어 '검색 힌트'(예: "[아내]는 언제 태어났는가?")를 붙인다. 빈칸에는 기대 답 유형("date" 등)과 검증 주장("제안된 날짜는 [아내]의 생일이다") 같은 메타데이터도 달린다. 연구를 시작하기 전에 하네스는 잘못된 참조, 답 타깃의 누락·중복, 순환 의존성, 힌트와 의존관계의 불일치 같은 구조적 오류를 검사하고, 별도 LLM 호출이 제안한 수정안을 다시 검사한 뒤에만 적용하는 제한된 복구 절차를 돌린다. 이 계획 검사는 제안된 발견을 심사하는 Verifier와는 별개다.

무엇과 다른가

작업 공간은 W_t=(P_t, S_t)로 표기되며, P_t는 현재 계획, S_t는 노드에 연결된 연구 레코드 집합이다. 레코드는 발견, 뒷받침 증거, 리뷰 상태를 담는다. Orchestrator는 의존관계를 보고 조사할 하위 질문을 골라 Researcher 에이전트를 배정한다. Researcher는 사용 가능한 발견을 검색 힌트에 대입해 한 번 검색하고, 검색된 문단에서 인용과 함께 후보 답을 제안한다. 유형 검사와 검증을 통과하면 작업 공간에 기록되고, 실패하면 이미 얻은 후보·출처·피드백을 유지한 채 ReAct 방식으로 반복 검색·추론을 이어간다(할당당 20턴). 읽기 도구는 별도 LLM 에이전트로 관련 정보와 인용문만 추출해 컨텍스트 비대화를 막는다. Verifier는 결정적 검사(답 유형, 증거 첨부)와 LLM 평가를 결합하는데, 인용 증거가 후보를 하위 질문의 답으로 뒷받침하는지와 그 후보를 그럴듯한 대안들과 구별해 주는지를 모두 통과해야 승인한다. 실패하면 빠진 근거나 모호성을 지적하는 피드백을 돌려주고, 할당당 최대 5회 재시도가 허용된다. 하위 질문별로 리뷰가 이뤄지므로 서로 다른 Researcher의 제안을 병렬로 검사할 수 있다. 입력이 모두 준비되면 계획된 계산은 코드로 실행되고(예: 1927년 8월 18일 출생과 1978년 9월 17일 서명일로부터 51세), Researcher가 계획에 없던 중간 사실이 필요하다고 판단하면 추가 하위 질문을 제안해 Planner가 계획을 개정하고 영향받는 발견을 다시 열 수 있다.

어떻게 쓰나

실험은 BrowseComp-Plus(BCP, 공식 10만 문서 코퍼스의 CF-150 분할, easy/medium/hard 각 50문항), FRAMES 824문항, MoNaCo 1,315문항에서 이뤄졌다. 비교 대상은 PyRAG, Re-TRAC, IterResearch, SLEUTH, Omni-Decision, HyMem, Open Deep Search 등 7개 최신 하네스이며, 모두 gpt-oss-120b 백본과 동일한 동결 코퍼스, BM25 + Qwen3-Embedding-8B 밀집 검색 + jina-reranker-v3.5 검색 서비스를 공유한다. PANINI-DR은 세 벤치마크 평균에서 가장 좋은 성능을 냈고, BCP에서 정확도 73.3%로 2위 하네스보다 16.0점 앞섰다. 격차는 어려운 질문에서 가장 컸는데, ReAct 계열이 가장 못 푸는 BCP hard 그룹에서 PANINI-DR은 SLEUTH의 거의 두 배를 맞혔다. MoNaCo에서는 HyMem이 F1 1위이고 PANINI-DR은 5위였지만, PANINI-DR의 컬렉션 답변이 가장 정밀했다.

전제와 한계

절제 실험은 구조화된 계획과 지속 상태의 효과를 보여준다. Researcher와 Verifier는 그대로 두고 산문 노트만 쓰는 조건(Off)과 계획·하위 질문에 연결된 발견·계획 개정을 추가한 조건(On)을 비교하면 BCP 정확도가 41.3%에서 58.0%로 올랐고, 동일한 최종 답 합성 방식을 쓰게 해도 56.7% 대 73.3%로 16.7점 차이가 유지됐다. 질문에 없던 새 엔티티가 이후 다른 연구 할당에서 다시 등장하는 비율도 계획·상태가 있을 때 77.4%로, 없을 때의 32.1%보다 훨씬 높았다. 검증의 효과도 크다. 작업 공간과 도구를 고정한 채 Verifier와 인용·증거 첨부 검사를 제거하면 BCP 정확도와 Obs.가 16.0점 떨어졌다. 제안 이력 분석에서는 이전에 거부됐다가 승인된 101건 중 77건이 답이나 인용 출처를 바꿨다. 비용 측면에서 PANINI-DR은 대부분의 베이스라인보다 많은 프롬프트 토큰을 보내지만 Re-TRAC보다는 적고, 입력 토큰의 66.5%는 vLLM 서버의 프리픽스 캐시에서 나왔다. 캐시를 반영한 추정 연산량은 SLEUTH의 7.3배인데, SLEUTH를 질문당 8회 반복해 최빈 답을 택하면 1.12배 연산으로 BCP 64.7%에 그친다.

논문은 정답 여부만으로는 충분하지 않다고 보고 '관찰된 지원(Observed support)'을 제안한다. 공식 정답이면서 그 내용이 시스템이 저장한 증거에서 복원 가능할 때만 점수를 주는 지표로, Obs = (1/N) Σ c_i·s_i 형태다. PANINI-DR은 세 벤치마크 모두에서 Obs. 1위였고, 가장 강한 베이스라인인 SLEUTH와의 격차는 공식 점수보다 오히려 벌어졌다. 모델 기반 주장-지원 감사에서도 세 벤치마크 모두 SLEUTH를 앞섰다. BCP에서 PANINI-DR은 주석된 출처 페이지의 대부분에 도달한 반면 SLEUTH는 절반에 못 미쳤고, 인용한 페이지 중 주석이 달린 비율도 더 높았다. 같은 gpt-oss-120b 리더에게 네 시스템의 증거만 주고 답하게 하는 공통 리더 테스트에서도 PANINI-DR의 증거가 세 벤치마크 모두 최고 품질의 답을 만들었다.

실무 관점에서 이 논문이 주는 시사점은 명확하다. 여러 단계 검색·추론을 하는 에이전트를 만들 때 '무엇을 조사할지'를 정하는 조정 계층과 '개별 하위 질문을 파고들고 검증하는' 실행 계층을 분리하고, 그 사이에 하위 질문·의존관계·발견·증거·리뷰 상태를 담은 명시적 작업 공간을 두는 설계가 유효하다는 것이다. 특히 발견을 다음 단계에 재사용하기 전에 인용 증거와 대조해 검사하는 절차가 성능에 기여한다는 절제 결과는, 검색 증강 파이프라인의 중간 산출물을 그냥 다음 호출에 넘기는 관행에 대한 반례가 된다. 다만 이득은 공짜가 아니다. 기본 설정에서도 추정 연산량이 SLEUTH의 7배를 넘고, 턴 수를 20에서 50, 80으로 늘리면 BCP 정확도가 73.3%→74.7%→76.0%로 오르지만 80턴은 기본 대비 2.8배 토큰을 써서 2.7점을 더 얻는 수준이라 저자들은 기본값 20턴을 유지한다. 검증 예산을 늘리는 것이 항상 답 품질을 올리지는 않는다는 점도 함께 봐야 한다.

저자들이 밝힌 한계도 분명하다. 검증은 Planner가 세운 하위 질문, 연구 중 고려된 후보, Verifier가 접근할 수 있는 증거에 의존하므로 모델 기반 판단이 틀릴 수 있고, 개별 발견을 검사하는 것으로는 계획이 원래 질문에 필요한 모든 것을 포괄한다는 보장이 없다. 주요 비교는 하나의 연구 백본과 고정된 벤치마크 코퍼스에서만 이뤄졌고, 다른 모델이나 오픈 웹 연구로의 일반화는 검증되지 않았다. Observed support는 저장된 증거로부터의 답 복원 가능성을 측정할 뿐 모든 주장이 뒷받침된다는 것을 입증하지 않으며, 보완적 주장-지원 감사 역시 모델 판단에 의존한다. 하네스는 상당한 연산을 요구하고, 검증 허용량을 늘려도 답 품질이 일관되게 좋아지지는 않았다. 저자들은 더 넓은 모델과 오픈 웹 데이터셋으로 연구를 확장하고, 검증을 확장하는 신뢰성 있고 계산 효율적인 방법을 개발하는 것을 향후 과제로 남긴다.