로컬 markdown 논문 지식베이스(위키)를 NotebookLM으로 교차검증하는 운영 규칙이다. An Lab의 llm-wiki 운영에서 추출했으며, 검증 세션 64회, PDF 업로드 2,277건, 주장 판정 512건의 실측 결과에 근거한다. 같은 구조의 지식베이스를 운영하는 사람이 그대로 따라 구축할 수 있도록 쓴다.
- 로컬 지식베이스가 먼저 있어야 한다. 우리 구조는 papers/(정본 PDF), sources/(논문별 요약), wiki/(여러 논문을 합성한 페이지), logs/(실행 기록)다. 폴더 이름은 자유지만, 각 위키 페이지가 어떤 논문 PDF에 근거하는지 링크로 추적할 수 있어야 한다. 이 추적이 안 되면 아래의 manifest 동결이 불가능하다.
- CLI는 오픈소스 notebooklm-py를 쓴다. 버전을 고정하고(
uv tool install --force "notebooklm-py[browser,mcp]==0.8.1"), 여러 대의 컴퓨터를 쓰면 같은 버전을 맞춘다. - 계정 한도는 실측으로 notebook 200개, notebook당 source 약 50개다. 캠페인 설계 전에 이 한도를 먼저 계산한다.
- NotebookLM은 2차 블라인드 리뷰어다. 정본 근거가 아니다.
- NotebookLM의 요약, 인용, 모순 지적은 전부 후속 확인용 lead로 취급한다.
- NotebookLM 출력만으로 위키를 수정하지 않는다. 수정하려면 해당 주장을 정본 PDF에서 직접 재확인한다.
- 블라인드 원칙: 첫 질의에서 기존 위키 본문을 source로도 프롬프트로도 주지 않는다. 기존 서술에 anchoring되지 않은 독립 합성을 먼저 얻는 것이 목적이다.
이 역할 규정은 취향이 아니라 실측 결과다. 블라인드 합성은 100점 루브릭 벤치마크에서 기존 위키보다 높았지만(평균 86 대 73 — 수치 회수와 한정어 보존에서 강함), 자체 오류도 냈다. 240개 주장 판정에서 명백한 오류 8건이 나왔고, 874건의 인용-PDF 대조에서 6건은 해당 인용 위치에서 근거가 회수되지 않았다. 어느 쪽도 정본 PDF 판정을 대체하지 못한다.
- NotebookLM 업로드는 로컬 파일을 외부 서비스에 보내는 전송이다. 공개된 정본 논문 PDF만 올린다.
- 비공개 원고, 내부 노트, 미공개 그랜트, 사람·연락처 자료는 올리지 않는다.
- notebook은 private로 유지하고 공유 링크를 만들지 않는다.
- 범위 고정. 대상 위키 페이지와 그 페이지가 직접 인용하는 논문을 전부 열거하고, 예상 source 수 N을 먼저 고정한다.
- Manifest 동결. source마다 위키 경로, PDF 경로, 제목, 포함 이유를 기록한다. 회계 등식
expected == ready + failed + excluded를 캠페인 내내 유지한다. 없는 PDF를 말없이 빼지 않는다 — excluded로 명시한다. - 블라인드 합성. 페이지 slug와 날짜를 넣은 새 notebook을 만들고, manifest의 PDF만 올리고, 처리 완료(failed 0)를 확인한 뒤 아래 8슬롯 질문을 던진다.
- 대조. NotebookLM 답변과 위키 페이지를 claim 단위로 비교하고 verdict를 부여한다(5절).
- 판정. 불일치와 중요한 주장은 정본 PDF를 직접 열어 재확인한 뒤에만 위키에 반영한다. 코퍼스 밖 논문 제안은 위키 주장으로 넣지 않고 확보 후보 목록에만 적는다.
- 기록과 정리. 결과 번들을 로컬에 저장하고(8절), 캠페인이 닫히면 notebook을 삭제한다(7절).
페이지당 여덟 개의 고정 슬롯으로 질문한다: 정량 주장 2, 비교 주장 2, 기전·인과 주장 2, 제한·일반화 주장 2. 모든 답에 source 인용을 요구한다.
이 구성은 위키의 관용적 약점을 겨냥한 것이다. 위키는 수치와 분모를 틀리고, 벤치마크 한정 결과를 보편화하고, 상관을 인과처럼 쓰는 경향이 있다. 실측으로 이 프로토콜은 30페이지 캠페인 한 번에서 240개 판정 중 약 170건의 위키 보충(수치 추가, 한정어 추가, 인과 표현 축소, 오류 교정)을 만들었다. 공백 후보만 뽑아 검토하는 느슨한 방식은 같은 규모에서 12건에 그쳤다. 주장 단위 전수 판정이 수확량을 지배한다.
| Verdict | 의미 |
|---|---|
| supported | 위키 주장과 PDF-only 합성이 수렴한다 |
| partially-supported | 방향은 맞지만 범위, 조건, 수치가 더 좁아야 한다 |
| unsupported | NotebookLM이 근거를 찾지 못했고 정본 PDF 확인이 필요하다 |
| contradicted | source 간 또는 위키와 source 간 방향 충돌이 의심된다 |
| missing-from-wiki | PDF에는 있는 중요한 내용이 위키에 없다 |
| citation-mismatch | 주장에 연결된 논문이 틀렸을 가능성이 있다 |
| new-lead | 추가 후보지만 정본 확인 전에는 위키 주장이 아니다 |
실측에서 반복된 오류 유형이다. 판정 단계에서 체크리스트로 쓴다.
- 인과 방향 뒤집기 (A가 B를 억제한다를 반대로)
- 서로 다른 논문의 근거를 한 주장으로 융합
- 수치를 다른 대상·조건에 귀속 (분모 바꿔치기 포함)
- 논문에 없는 실험·과제를 그럴듯하게 창작
- 종 변환 (마우스 결과를 인간 결과처럼 서술)
- 방법 분류 오류 (예: SVD 기반 방법을 딥러닝으로 분류)
- 벤치마크 한정 결과의 보편화
빈도는 낮다 — 명백 오류 8/240, 인용 비회수 6/874. 그러나 이것은 폐쇄형 PDF 질의와 엄격한 인용 요구 프롬프트에서의 회수율이지 환각이 없다는 뜻이 아니다. 낮은 빈도가 판정 생략의 근거가 되지 않는다.
- NotebookLM의 업로드·질의 비용은 사실상 무시할 수준이라, 같은 manifest만 있으면 notebook은 언제든 몇 분 안에 재구성된다. 따라서 영구 보존 대상은 notebook이 아니라 로컬 결과 번들이다.
- 규칙: notebook은 캠페인 진행 중과 리포트 확정 전까지만 보존한다. 리포트가 확정되고 회계 등식이 닫히면 캠페인 notebook을 일괄 삭제한다.
- 삭제는 owner 승인 후에만 실행하고, 삭제 전 pre-delete inventory(전체 notebook 목록과 UUID)를 남기고, 삭제 후 전체 목록을 다시 받아 잔존 0을 검증한다.
- 이 규칙이 없으면 계정 한도 200개는 대규모 캠페인 두세 번에 소진된다. 우리는 실제로 한도에 걸려 계정 전체를 비운 적이 있다.
캠페인마다 폴더 하나를 만들고 다음을 보존한다.
YYYY-MM-DD-{campaign-slug}/
├── README.md # 범위, 상태, 회계, 읽는 순서
├── manifest.json # 동결된 target과 source 목록
├── notebooks.json # notebook ID, 처리 상태, source 수
├── responses/ # 페이지별 프롬프트 버전과 원문 답변
├── adjudications.jsonl # claim별 verdict, PDF 재확인, 위키 처분
└── validation.json # 회계 종결과 검증 결과
- 번들에 넣지 않는 것: PDF 사본, 논문 전문, 쿠키, 토큰, 인증 응답 원문.
- 회계 등식이 닫히기 전에는 캠페인을 complete로 표시하지 않는다.
- NotebookLM으로 위키 문장을 직접 생성해 붙여넣기.
- 로컬 검색·retrieval을 NotebookLM 질의로 대체.
- 위키 본문을 source로 업로드 (블라인드가 깨진다).
- 정본 PDF가 없는 페이지를 검증했다고 표시.
- 처리 실패를 웹 검색이나 다른 모델로 조용히 우회 — 실패는 failed로 세고 보고한다.
- 전수 요청을 표본으로 대체.
- 분업이 명확하다. NotebookLM은 닫힌 PDF 집합에서 정확한 수치, 제한 조건, 한정어를 회수하는 데 강하고, 로컬 위키는 교차 주제 구조, 범위 통제, 장기 누적에 강하다.
- 수확이 큰 페이지는 정량 주장이 밀집한 페이지다(통계 방법론, 벤치마크 비교, 효과 크기가 많은 주제). 잘 정리된 개념 페이지는 대부분 "유지" 판정이 나온다. 검증 대상 선정에 이 기준을 쓴다.
- 대상 페이지의 직접 관련 논문이 부족하면(우리 기준: source 충분성 70/100 미만) 검증 판정 자체를 보류한다. 이 점수는 그 자체로 위키 페이지의 근거가 부실하다는 신호이며, 논문 확보 우선순위로 쓴다.
- 규모 감각: 하루에 30페이지, 업로드 1,300건 정도가 한 사람이 판정까지 감당하는 실측 상한이었다.