IterSynth, 검색 기록이 길어질수록 답이 흐릴 때 무엇을 버려야 할까
검색 기록이 길어질수록 앞 근거가 뒤쪽 잡음에 묻힐 수 있습니다. IterSynth는 원 질문과 갱신된 전역 요약만 다음 계획 단계에 넘깁니다. 계획과 근거 정리를 한 역할에 섞지 않는 방식이 핵심입니다.
30초 요약
- Planner는 현재 요약으로 다음 검색 또는 답변 종료를 고릅니다.
- Synthesizer는 새 근거를 전역 요약에 반영할 뿐 검색·답변은 하지 않습니다.
- 이 글은 공식 논문·저장소를 바탕으로 한 문서 기반 해설이며 실행 후기가 아닙니다.
왜 긴 검색 기록은 판단을 흐릴까?
긴 조사에는 검색 결과와 중간 추론, 기각한 가설이 함께 쌓입니다. 한 컨텍스트에서 계획·근거 선별·답변 작성을 모두 하면, 다음 검색어를 고를 때 오래된 단서도 같은 무게로 남기 쉽습니다.
논문은 이를 역할 결합과 컨텍스트 누적으로 설명합니다. 기록을 짧게 만든다고 판단이 자동으로 좋아지지는 않습니다.
Planner와 Synthesizer는 무엇이 다른가?
공식 설명 기준으로 별도 모델 둘이 아니라 하나의 공유 LLM 정책이 역할 프롬프트와 행동 제약을 달리 받아 번갈아 작동합니다.
| 역할 | 입력 | 행동 |
|---|---|---|
| Planner | 원 질문 q + 전역 요약 M_t |
다음 검색 또는 최종 답변 |
| Synthesizer | 현재 상태 + 검색 결과 | 근거를 골라 M_{t+1}로 갱신 |
역할 분리는 모델 수를 늘리는 일이 아니라 행동 경계를 만드는 일입니다.
한 번의 검색 뒤에는 무엇이 바뀌나?
문서 기반 예시입니다.
q: “X 라이브러리가 Python 3.12를 지원하나?”
M_t: “공식 문서 확인 필요.”
Planner → SEARCH(공식 릴리스 노트)
Synthesizer → M_t+1: “지원 확인. 제한 조건 추가 확인 필요.”
다음 행동의 재료는 긴 로그가 아니라 갱신된 연구 상태입니다. 충분하면 Planner가 답변하고, 빈칸이 있으면 해당 빈칸을 겨냥해 검색합니다.
적용 전에는 상태 스키마를 먼저 정하세요
공개 저장소는 범용 앱이 아니라 verl 위에 적용하는 RL 학습 인프라 패치입니다. README는 호환 verl, 패치 적용, ps_pipeline 전환을 안내하며 SFT 체크포인트는 포함하지 않습니다.
confirmed: [근거와 URL]
unresolved: [남은 질문]
conflicts: [출처 충돌]
원문 도구 로그를 그대로 붙이지 않는 규칙과 출처·충돌·미확인 항목이 함께 있어야 합니다.
언제 유용한가?
여러 출처를 대조하고 하위 질문이 계속 갈라지는 조사에 맞습니다. 반대로 한두 번의 API 호출로 끝나는 정형 작업에는 역할 전환 비용이 더 클 수 있습니다. 검색 라운드가 짧다면 역할 분리보다 입력·출력 계약을 단순하게 유지하는 편이 낫습니다.
RDPO는 무엇을 더하나?
Role-Decoupled Policy Optimization(RDPO)는 최종 결과 보상과 역할별 턴 루브릭을 합치고, Planner와 Synthesizer의 이점을 역할별로 따로 정규화하는 학습 방법입니다. 이 작업 흐름을 프롬프트로 적용하는 일과 RDPO 학습 재현은 별개이며, 후자에는 SFT 데이터·모델·도구 키·학습 환경이 필요합니다.
작업 환경을 함께 정리한다면
IterSynth의 필수 구성요소는 아니며, 긴 조사에서 문서·상태 스키마 편집을 보조하는 환경 도구입니다.
이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.
출처
- IterSynth 공식 논문, arXiv:2609.29444v1, 2026-09-24: https://arxiv.org/abs/2609.29444
- Tencent/IterSynth 공식 저장소 README, 확인일 2026-09-27: https://github.com/Tencent/IterSynth
핵심 정리: 다섯 가지 질문과 답
Q. 긴 로그를 왜 버리나요?
최신 요약으로 다음 판단을 선명하게 하기 위해서입니다.
Q. 두 모델이 필요한가요?
아닙니다. 공유 정책에 역할별 행동 경계를 둡니다.
Q. Synthesizer가 검색하나요?
아닙니다. 근거 상태 갱신만 맡습니다.
Q. 요약만 있으면 충분한가요?
아닙니다. 공백 탐색과 근거 통합의 책임도 분리해야 합니다.
Q. 짧은 자동화에도 필요한가요?
대체로 단순한 입력·출력 계약이 더 적합합니다.
글을 읽어 주셔서 감사합니다.
이 글이 도움이 되었고 새로운 정보를 계속 받아보고 싶으시다면 구독해 주세요.
'AI > AI 최신 기술' 카테고리의 다른 글
| PISA 블록 희소 어텐션, O(N log N)이라 믿기 전 봐야 할 계산 범위 (0) | 2026.09.28 |
|---|---|
| AgentKernel 프롬프트 인젝션, 도구 실행 전에 어디서 끊어야 할까 (0) | 2026.09.27 |
| WanPE 역구성 방식, 한 줄 영상 프롬프트가 샷 계획으로 바뀌는 이유 (0) | 2026.09.26 |
| 토큰 중첩 학습, 두 텍스트를 한 번에 예측해도 되는 이유와 멈춰야 할 지점 (0) | 2026.09.26 |
| SWE-bench 점수, 높은데도 에이전트를 바로 맡기면 안 되는 이유 (0) | 2026.09.25 |
댓글