Deep Review 모방: 분할 → 병렬 검증 → 반증 → 통합
Google의 Deep Review(STOC·ICML·NeurIPS·ICLR에서 저자 대상으로 시험된 Paper Assistant Tool의 후속)의 공개된 설계를 Claude의 서브 에이전트로 재현합니다. 목적은 투고 전 저자가 스스로 발견할 수 없는 진짜 오류(증명의 구멍, 계산 착오, 수치 불일치, 증거보다 강한 주장, 누락된 비교)를 확인 가능한 형태로 우선순위별로 제시하는 것입니다. 점수는 부여하지 않습니다.
공정과 각 공정을 배치한 이유:
| 공정 | 담당 | 이유 |
|---|---|---|
| 1 추출 | 스크립트 | 텍스트와 페이지 이미지를 모두 확보합니다. 추출된 텍스트는 수식·표가 깨지므로 이미지가 필요합니다 |
| 2 세그먼트 분할·예산 할당 | 당신 | 증명이 밀집된 부분에 계산을 집중하고, 도입부나 관련 연구는 가볍게 봅니다 |
| 3 병렬 심층 검증 | 서브 에이전트(세그먼트×관점, 렌즈) | 한 번에 깊게 읽을 범위를 좁히고, 관점이 다른 독립적인 시선으로 포괄성을 높입니다 |
| 4 병합·중복 제거 | 스크립트 | 축어 인용이 논문에 실제로 존재하는지 기계적으로 확인하고, 같은 문제를 묶습니다 |
| 5 반증 검증 | 서브 에이전트 | 오류 찾기는 시도가 늘어날수록 오탐지가 증가합니다. 의심하는 다른 시선으로 정밀도를 되찾습니다 |
| 6 통합 | 서브 에이전트 | 심각도 결정, 우선순위, 길이 제어, Overall Feedback |
| 7 보고서 | 스크립트 → 당신 | report.md / report.html을 만들고, 요점을 간결하게 전달합니다 |
설계의 근거(어떤 문헌의 어떤 지식에서 유래했는지)는 references/research_basis.md에 있습니다.
이하, <skill_dir>은 이 SKILL.md가 있는 디렉토리, <ws>는 작업 폴더, deep_review.py는 python <skill_dir>/scripts/deep_review.py의 약칭입니다. python이 없으면 python3를 사용합니다.
0. 처음: 깊이와 초점 확인
- 대상 문서를 특정합니다. PDF가 가장 좋습니다(페이지 이미지 생성 가능). .md / .txt / .tex도 받지만, 그 경우 그림이나 수식의 이미지 확인이 불가능합니다. LaTeX 소스만 있고 빌드 가능하다면 PDF로 만든 후 사용합니다.
- 깊이와 초점을 AskUserQuestion 등의 질문 도구로 한 번에 묻습니다(없으면 채팅으로 묻습니다). 시작 메시지에서 이미 알고 있는 항목은 묻지 않습니다. "바로 해줘" "맡길게"라면 standard·초점 없음으로 시작합니다.
- 질문1 "깊이":
Standard(추천)/Quick/Deep(아래 표의 기준을 설명에 첨부) - 질문2 "중점적으로 봐줬으면 하는 부분"(복수 선택 가능):
특별히 없음/증명·수식/실험·통계/참신성·관련 연구(그 외에 투고처나 자유 기재도 가능)
- 질문1 "깊이":
| 깊이 | 세그먼트 수 | 1세그먼트 트레이스 수 | 렌즈 | 반증 검증 대상 | 에이전트 수 기준 | 시간 기준 |
|---|---|---|---|---|---|---|
| quick | 2~4 | 1 | L0(통합) | Major 및 소재 불명의 것 | 4~8 | 10~20분 |
| standard | 4~8 | High 2, 기타 1 | L1·L2·L3 | Major 및 소재 불명의 것 | 10~20 | 20~45분 |
| deep | 5~12 | High 3, Medium 2, Light 1 | L1·L2·L3 | +수식·통계·수치 계열의 Minor, 비평 담당 | 20~40 | 45~90분 |
시간은 논문 길이에 따라 크게 달라집니다.
- 사용자가 타인의 원고를 리뷰어로서 보려는 모양이라면, 투고처의 AI 이용 방침(많은 출판사·학회가 리뷰 중인 원고를 AI 도구에 입력하는 것을 금지하고 있음)을 확인하도록 한 마디 덧붙입니다. 저자가 자신의 원고를 보는 경우는 불필요합니다.
1. 추출
python <skill_dir>/scripts/deep_review.py init <문서의 경로> --depth standard --focus "<초점. 없으면 생략>" --venue "<투고처. 없으면 생략>" --lang ko
- 작업 폴더는
<문서가 있는 폴더>/<문서명>_deep_review/(쓸 수 없으면 현재 디렉토리 아래,--ws로 지정 가능) paper.txt(=== Page N ===구분),pages/page_NNN.png(150 dpi),pages.json,config.json이 생성됩니다.- 출력되는 페이지별 개요(단어 수, 수식 기호 비율, 식 번호 수, 정리·증명 수, 제목, 그림·표 캡션)를 다음 공정에서 사용합니다.
WARN이 나오면 읽습니다. 스캔 PDF 등으로 텍스트가 부족하면, 각 담당자에게 페이지 이미지 중심으로 읽도록 의뢰문에 추가합니다.- 보고서의 언어는
--lang(ja/en/ko). 사용자 언어에 맞춥니다. 인용은 원문 그대로
2. 세그먼트 분할과 예산 할당
개요를 보고 <ws>/segments.json을 작성합니다. 제목만으로 내용을 알 수 없는 페이지는 paper.txt의 해당 페이지를 확인합니다(전문 읽을 필요는 없음).
규칙:
- 논리적 단위로 나눕니다(이론, 방법, 실험, 도입 등). 겹쳐도 좋고, 연속적이지 않아도 좋습니다. 예: "Sec. 3의 정리 주장"과 "부록 B의 그 증명"은 같은 세그먼트로 합니다.
- 모든 페이지를 어떤 세그먼트에 포함시킵니다(
plan이 검사함). - 트랙(깊이)을 정보 밀도로 결정합니다:
high: 주요 정리와 그 증명, 핵심 유도, 정확성을 주장하는 알고리즘의 핵심. 논문의 주요 주장이 실험 결과 자체라면, 주요 결과 표·그림의 절도 포함.medium: 방법 설명, 실험, 부록의 추가 실험.light: 도입, 관련 연구, 고찰·결론.none: 참고문헌·사사 등(reason필수. 참고문헌은 렌즈 L3가 봄).
high세그먼트는 8~10페이지 이내로 합니다(길면 나눔).theme:intro/related_work/discussion/other/method/algorithm/system/theory/appendix_proofs/experiments/analysis/appendix_experiments/referencesnotes에 담당자에게 전할 사항(이 세그먼트가 뒷받침하는 주장, 의존하는 정의의 위치 등)을 한 줄로 적을 수 있습니다.
{
"segments": [
{"id": "S1", "title": "도입과 기여", "pages": "1-2", "theme": "intro", "track": "light",
"notes": "기여 C1–C3는 p.2의 항목"},
{"id": "S2", "title": "주요 정리와 그 증명", "pages": "4-5,13-16", "theme": "theory", "track": "high",
"notes": "정리2(p.5)의 증명은 부록B(p.13–16). 가정은 p.3의 Assumption 1–3"},
{"id": "S3", "title": "제안 알고리즘", "pages": "3-4", "theme": "algorithm", "track": "medium"},
{"id": "S4", "title": "실험", "pages": "6-9", "theme": "experiments", "track": "medium"},
{"id": "S5", "title": "관련 연구·결론", "pages": "9-10", "theme": "related_work", "track": "light"},
{"id": "S6", "title": "참고문헌", "pages": "11-12", "theme": "references", "track": "none",
"reason": "참고문헌은 렌즈 L3가 추출 검사함"}
]
}
다음으로 계획을 만듭니다:
python <skill_dir>/scripts/deep_review.py plan <ws>
plan.json에 기동할 에이전트(태스크 ID, 담당 세그먼트, 트랙, 트레이스=관점, 페이지, 출력처, 권장 effort)가 나열됩니다. 에러가 나면 segments.json을 수정하여 재실행합니다.
사용자에게 한 줄: 분할 완료: 6세그먼트(High 1·Medium 2·Light 2), 검증 에이전트 9를 병렬로 기동합니다
3. 병렬 심층 검증
plan.json의 모든 태스크를 하나의 메시지로 병렬 Agent 도구로 기동합니다(10을 넘으면 8 정도씩 웨이브로 나눕니다). 각 태스크에 effort가 있으며, Agent 도구에 effort 지정이 있으면 그 값으로 기동합니다(High 트랙에 추론을 두껍게 배분하기 위해).
세그먼트 검증 담당자용 의뢰문(kind: segment)
당신은 Deep Review의 "세그먼트 검증 담당"입니다. 먼저 다음을 끝까지 읽고, 절차와 출력 형식에 따라 주세요.
<skill_dir>/references/segment_reviewer.md
<skill_dir>/references/checklists.md(담당 테마 관련 절)
<skill_dir>/references/schemas.md의 §1과 §4
- 논문의 전체: <ws>/paper.txt(=== Page N ===이 페이지 번호) 페이지 이미지: <ws>/pages/page_NNN.png
- 원본 문서: <ws>/<config.json의 input_copy>
- 태스크: <T03> 세그먼트: <S2>"<제목>" 페이지: <4-5,13-16> 테마: <theory(proof)>
- 트랙: <high> 트레이스: <B — 반례·경계·가정>
- 세그먼트 메모: <notes. 없으면 "없음">
- 사용자 지정 초점: <focus 또는 "없음"> 투고처: <venue 또는 "없음">
- 출력: <ws>/<candidates/T03_S2_B.json>
- 보조: python <skill_dir>/scripts/pdf_tools.py(crop·render --grid로 그림이나 식 확대)
전체를 맥락으로 읽고, 지적은 담당 페이지에 집중해 주세요. 같은 세그먼트를 다른 관점의 담당도 보고 있습니다.
Light 트랙에서 복수 세그먼트를 묶은 태스크는 세그먼트란에 전부를 나열합니다.
렌즈 담당자용 의뢰문(kind: lens)
당신은 Deep Review의 "렌즈 담당(<L2 참신성·중요성>)"입니다. 먼저 다음을 끝까지 읽고, 담당 렌즈의 절의 절차와 출력 형식에 따라 주세요.
<skill_dir>/references/lens_reviewers.md
<skill_dir>/references/checklists.md(§6~§8)
<skill_dir>/references/schemas.md의 §1과 §4
- 논문의 전체: <ws>/paper.txt 페이지 이미지: <ws>/pages/page_NNN.png
- 태스크: <T08> 렌즈: <L2>
- 사용자 지정 초점: <…> 투고처: <…>
- 출력: <ws>/<candidates/T08_L2.json>(overall_notes도 쓸 것)
논문 전체를 담당 렌즈의 관점에서 횡단하여 봐 주세요. 범위별 심층 검증은 다른 담당이 수행하고 있습니다.
전원의 완료를 기다린 후 plan을 재실행하여 모든 태스크에 [done]이 붙었는지 확인합니다. 누락된 태스크는 한 번만 재기동합니다. 그래도 누락되면 진행하고, 통합 담당자에게 전달하여 limitations에 기재하게 합니다.
사용자에게 한 줄: 검증 9/9 완료
4. 병합과 중복 제거
python <skill_dir>/scripts/deep_review.py merge <ws>
- 각 후보의 축어 인용이 논문에 실제 존재하는지(
exact/fuzzy/not_found)와 그 페이지를 조사하고, 가까운 후보를 cluster(K01, …)로 정리하여merged.json에 작성합니다. support는 같은 문제를 독립적으로 발견한 태스크의 수입니다. 복수 트레이스가 독립적으로 발견한 문제일수록 진짜일 가능성이 높습니다.- 반증 검증 배치(V01, …)가 출력됩니다.
invalid나missing outputs경고가 있으면, 해당 파일을 작성한 담당자의 문제로 기록합니다.
사용자에게 한 줄: 후보 64건 → 38건으로 통합, 그중 9건을 반증 검증에 넘깁니다
5. 반증 검증
merged.json의 verify_tasks를 하나의 메시지로 병렬 기동합니다.
반증 검증 담당자용 의뢰문
당신은 Deep Review의 "반증 검증 담당"입니다. 먼저 <skill_dir>/references/verifier.md와
<skill_dir>/references/schemas.md의 §2를 끝까지 읽어 주세요.
- 논문의 전체: <ws>/paper.txt 페이지 이미지: <ws>/pages/page_NNN.png
- 검증 대상: <ws>/merged.json의 clusters 중 <K01, K04, K07>(관계 페이지: <…>)
- 출력: <ws>/verdicts/<V01>.json
각 후보에 대해, 먼저 "논문이 옳다"는 입장에서 반증을 시도하고, 그 위에 자신이 독립적으로 재현할 수 있었던 것
(재계산·반례·모순되는 두 곳의 인용 등 구체적인 근거가 있는 것)만을 confirmed으로 해 주세요.
완료되면:
python <skill_dir>/scripts/deep_review.py collate <ws>
검증 결과를 cluster에 결합한 collated.json이 생성됩니다. refuted / cannot_locate는 삭제 권장이 됩니다.
사용자에게 한 줄: 반증 검증 완료: 확인 5·타당 2·오탐지 2
6. 통합
통합 담당자용 의뢰문
당신은 Deep Review의 "통합 담당"입니다. 먼저 <skill_dir>/references/synthesis.md와
<skill_dir>/references/schemas.md의 §3과 §4를 끝까지 읽어 주세요.
- 입력: <ws>/collated.json(후보·검증 결과·렌즈 소견·관점 분포), <ws>/paper.txt,
<ws>/pages/, <ws>/config.json(깊이·초점·투고처·언어)
- 출력: <ws>/findings.json
- 작성 후 python <skill_dir>/scripts/deep_review.py render <ws> --check를 실행하고,
에러가 없어질 때까지 수정할 것
- 보고서 언어: <한국어> 사용자 지정 초점: <…> 투고처: <…>
- 보충: <누락된 태스크 등 limitations에 적어야 할 사항. 없으면 "없음">
deep만: 비평 담당. 통합 담당이 작성 완료하면, 다른 서브 에이전트에게 다음을 의뢰합니다.
당신은 Deep Review의 "비평 담당"입니다. <ws>/findings.json(통합 담당의 초안)을 <ws>/paper.txt와
<ws>/pages/에 비추어 점검해 주세요. <skill_dir>/references/synthesis.md의 §8의 관점
(인용과 위치의 정확성, 구체성, 심각도 타당성, 외부 문헌의 실재, 어조, 길이)으로 전 건수를 보고,
모든 Major는 자신이 확인해 주세요. 새로운 지적은 찾지 않습니다.
결과를 <ws>/critique.md에 "ID·문제·고치는 방법"의 항목으로 작성해 주세요.
critique.md가 완성되면, 통합 담당자에게 SendMessage로 "critique.md를 읽고 타당한 점을 findings.json에 반영하여 render --check를 통과"하도록 의뢰합니다(SendMessage가 없으면, 같은 의뢰로 통합 담당을 새로 기동합니다).
마지막으로:
python <skill_dir>/scripts/deep_review.py render <ws>
report.md와 report.html이 생성됩니다. HTML은 Major / Minor / Suggestions의 필터링과 보고서 순서/페이지 순서 전환이 가능합니다.
7. 사용자에게 보고
findings.json을 읽고 간결하게 정리합니다. 보고서 전문은 붙이지 않습니다.
- 건수(Major / Minor / Suggestions)와 반증 검증에서 제외한 오탐지 수
- Major concerns를 전 건, 한 줄씩(ID, 위치, 요점)
- 총괄(bottom_line) 1~2문장
- 파일:
report.html(브라우저에서 열기),report.md, 작업 폴더 - 주의 한 마디: AI의 지적이며, 원고를 바꾸기 전에 각 지적을 확인해 주시기 바랍니다.
다음 수단을 제안합니다: 특정 지적의 심층 분석, 수정 후 재리뷰, 점수 첨부 리뷰와 수정 루프(paper-review-loop).
후속 조치
- 심층 분석("MJ2를 더 자세히"): 해당 지적 부분을 담당 범위로 하고, high 트랙·트레이스 B(반례)로 검증 담당을 한 명 기동하여 결과를 findings.json에 반영 → render
- 수정판 재리뷰: 새로운 PDF로 1부터 실행(
init은 새 작업 폴더에서). 통합 담당 의뢰문에 이전findings.json의 경로를 추가하고,previous에 대응 상황을 기재하게 함. - 중단에서 재개: 작업 폴더에 있는 파일(segments.json → plan.json의
[done]→ merged.json → verdicts/ → collated.json → findings.json)을 보고, 마지막으로 완료한 공정 다음부터 계속합니다.init --force는 이전 결과를 지우므로, 다시 하고 싶을 때만 사용합니다.
다른 스킬에서 호출되었을 때
review2revise-loop 등이 반복 중 리뷰 공정으로 이 스킬을 호출할 수 있습니다. 호출 측이 입력·작업 폴더(--ws)·깊이·초점·투고처·이전 findings.json을 지정했다면:
- §0의 질문은 하지 않습니다. 지정된 값을 사용합니다.
- §1~§6을 그대로 수행하고,
findings.json·report.md·report.html을 만듭니다. 이전 findings.json이 지정되어 있으면, 통합 담당 의뢰문에 추가하여previous를 기재하게 합니다. - §7의 보고는 "Major / Minor / Suggestions의 건수" 한 줄만 하고 호출 측으로 돌아갑니다. 다음 수단 제안은 하지 않습니다.
- 리뷰 기준·깊이·건수 상한은 평소와 같습니다. 호출 측 사정으로 완화하지 않습니다.
서브 에이전트를 사용할 수 없는 환경
공정은 같고, 각 태스크를 자신이 순서대로 수행합니다. 독립성이 떨어지므로 다음을 지킵니다.
- 깊이는 quick을 권장합니다(사용자가 원하면 standard).
- 각 태스크 전에 담당 페이지를
paper.txt와 페이지 이미지에서 다시 읽고, 기억에 의존하지 않습니다. - 태스크마다 해당 태스크의 가이드(segment_reviewer.md 등)의 관점으로만 봅니다.
- 반증 검증은 후보를 썼을 때의 추론을 보지 않고, 논문의 해당 부분만으로 판단을 다시 합니다.
원칙과 그 이유
- 확인할 수 없는 지적은 내지 않는다: 인용은 축어, 수식·표는 이미지로 확인, 계산은 코드로 재현, 외부 문헌은 실재를 확인한 것만. 오탐지가 섞인 보고서는 저자의 시간을 빼앗고, 진짜 지적까지 신뢰를 잃습니다.
- 양보다 우선순위: Major는 주요 주장에 영향을 미치는 것만. 건수 상한을 지킵니다. 세부 사항에 집착하고 너무 긴 보고서는 AI 리뷰에서 가장 싫어합니다.
- 점수를 부여하지 않는다: Deep Review는 오류와 개선점에 집중하고, 주관적인 점수를 내지 않습니다. LLM의 점수는 낙관에 치우치고 불안정하기도 합니다. 점수가 필요하면 paper-review-loop를 사용합니다.
- 판단은 사람에게 남긴다: 이것은 투고 전 저자용 도구이며, 리뷰의 대체가 아닙니다. 최종 판단은 저자와 리뷰어가 수행합니다.
- 원고의 기밀을 지킨다: 웹 검색 쿼리에 원고 문장이나 미공개 제목을 넣지 않습니다. 원고를 외부 서비스에 보내지 않습니다.
- 원본 파일을 변경하지 않는다: 모든 작업은
<ws>안에서 수행합니다.