paper-radar — 빅테크 AI 논문 레이더은(는) 무엇을 하나요?
무상태(Stateless): 한 번 실행 = 한 기간 = 하나의 보고서. 논문 라이브러리는 유지되지 않습니다. arXiv만이 유일한 진실 공급원이며, 동일한 기간을 다시 실행하면 반드시 동일한 결과가 생성됩니다. 따라서 두 번째 복사본을 유지할 이유가 전혀 없습니다. 복사본을 유지하면 버전 관리 밖에서 조용히 표류하는 상태만 추가됩니다. 대가로 매 실행마다 전체 기간을 다시 스크래핑해야 합니다(3일 기준 약 1분, 14일 기준 약 3분). 대신 얻는 것은 재현성입니다.
먼저 읽어야 합니다. 그렇지 않으면 잘못된 결론에 도달합니다
arXiv는 게시 날짜별로 구성된 유일한 출처입니다. 모든 벤더의 자체 출판 페이지는 출판 연도 / 학회별로 구성되어 있어, 구조적으로 '지난 2주간 발표된 것'에 답할 수 없습니다. 이는 기술적 문제가 아닌 데이터 모델의 차이입니다. 측정 결과:
- Google Research: 상세 페이지에는 연도만 표시되며, 목록은 시간 순서가 아닙니다. 처음 8페이지에 걸친 85개 제목 중 2주 기간 내에 해당하는 것은 0개였으며, 가장 최근 항목의 arXiv 게시 날짜는 3개월 전이었습니다.
- Amazon Science: 연도별로 그룹화되어 있으며, 논문별 날짜가 없습니다.
- Microsoft:
/research/feed/는 편집자가 선별한 블로그입니다. 같은 기간에 대해 약 8%의 커버리지만 보입니다. - 13개 중국 기업 사이트: 모두에서 날짜 히트가 0개였습니다. 이들은 실험실 랜딩 페이지일 뿐, 논문 목록이 아닙니다.
또 하나 알아야 할 사실: arXiv 메타데이터에는 저자 소속 정보가 포함되어 있지 않습니다.
<arxiv:affiliation> 기입률은 1%, Semantic Scholar는 7%, OpenAlex는 프리프린트에 대해 0개의 raw_affiliation_strings를 반환합니다(측정 결과: 3/3이 비어 있었고, 동일한 엔드포인트는 출판된 Nature 논문에 대해 34/34를 반환했습니다). 업계 표준 파이프라인은 '출판사가 소속 문자열을 제출 → ML이 ROR에 매핑'이지만, arXiv는 해당 문자열을 절대 제출하지 않습니다. 따라서 소속은 논문 자체의 저자 블록에서 추출해야 합니다.
실행 방법
스크립트는 이 스킬 디렉토리에 있으며, 외부에 의존하지 않습니다. 순수 stdlib만 사용하며 pip 패키지가 필요 없습니다.
R=<skill-dir>/scripts/paper_radar.py
python3 $R # 지난 3일
python3 $R --days 14 # 지난 14일
python3 $R --from 2026-07-20 --to 2026-08-04
python3 $R --cats cs.AI,cs.CL,cs.LG,cs.CV # 카테고리 확장
python3 $R --no-scrape # 공식 출처 + 팀 이름만 (몇 초 — 빠른 회사 확인)
python3 $R -o path.md # 보고서를 여기에 작성
python3 $R -o - # 보고서를 표준 출력에 작성
소요 시간: 2주 기간(~3000개 논문)의 경우 메타데이터에 약 2분, 저자 블록 가져오기에 약 25초(6개 워커)가 소요됩니다. 3일 기간은 1분 이내에 완료됩니다. 더 긴 기간을 다루려면 기간을 넓히고 다시 실행하십시오. 쿼리할 수 있는 라이브러리가 없습니다.
보고서 위치 — 사용자가 결정하며, 스크립트는 추측하지 않습니다
스크립트는 호출하는 프로젝트가 연구 자료를 어디에 보관하는지 알지 못하며, 알아서도 안 됩니다. -o 옵션이 없으면 현재 작업 디렉토리에 작성합니다.
매 실행 전에 대상을 결정하십시오:
- 사용자가 경로를 지정했다면 → 그 경로 사용
- 보관할 가치가 있는 연구라면 → 해당 프로젝트의 연구 디렉토리에 기간을 파일명에 포함하여 작성
- 단지 한 가지 사실을 확인하는 것이라면(예: "샤오미가 자기 진화 AI에 대해 발표한 것이 있나?") →
-o -를 사용하고 파일을 남기지 마십시오. 일회성 질문에 파일이 남으면 나중에 연구 기록으로 오인될 수 있습니다.
파일
| 경로 (이 스킬 기준 상대 경로) | 역할 |
|---|---|
scripts/paper_radar.py | 파이프라인: 목록 가져오기 → 저자 블록 가져오기 → 소속 해석 → 보고서 작성 |
scripts/affiliation.py | 해석 계층: 위첨자 매핑 + 3단계 매칭 |
scripts/data/ror_anchors.json | 28개 연구소의 ROR ID + 98개 공식 이름 변형(중국어 포함) |
유일한 출력물은 하나의 마크다운 파일(위 규칙에 따른 경로)이며, '총 히트 수 / 그중 주도 수' 구분이 포함됩니다. 스킬 디렉토리 자체는 파일을 생성하지 않습니다.
6단계
0 목록 arXiv API: cat × submittedDate → ID로 중복 제거
1 전체 텍스트 arxiv.org/html/{id} + Range 처음 90KB, ltx_authors → ltx_abstract 로 자름 [85%]
2 구조 분석 오른쪽에서 왼쪽으로 스캔하여 오름차순 1,2,3… 실행의 마지막 위치 찾기
(author, marks[]) · (mark, affiliation) · 이메일 · 역할 마커 추출
3 개체 식별 (a) 이메일 도메인 (b) ROR 이름 변형 (c) 연구소 별칭 테이블
4 등급 분류 lead_orgs = 첫 번째 저자의 소속 (여러 개일 수 있음); intern = 마커 존재
5 보충 출처 Apple RSS · MSR 임베디드 JSON · arXiv 팀 이름
6 보고서 키 기준 중복 제거 (한 논문이 저자 블록과 공식 출처 모두에서 올 수 있음),
마크다운 작성, 증거 + matched_on 유지
5가지 원칙 — 각각은 버그로 대가를 치렀습니다
1. 저자 블록은 반드시 ltx_abstract에서 정확히 잘라야 합니다. 한 글자라도 더 가져가면 초록이 섞여 들어옵니다. 측정된 결과: Oracle 73건(모두 'oracle access'), MiniMax 17건(minimax 알고리즘), DeepSeek 58건(해당 모델을 언급하기만 한 논문). 깔끔하게 자르면 저자 블록의 중간 길이는 약 201자입니다.
2. 소속 목록은 오른쪽에서 왼쪽으로 찾아야 합니다. 저자 실행부의 "이름 + 위첨자 숫자"와 소속 실행부의 "숫자 + 소속"은 형태가 동일하므로, 왼쪽에서 오른쪽으로 스캔하면 Yuchen Zhao 1 Bingxuan Li에서 1 → "Bingxuan Li"로 잘못 파싱됩니다.
3. '단 하나의 회사만 매칭되었으므로 주도다'라는 휴리스틱을 절대 사용하지 마십시오. 이는 다른 소속이 추적 대상 회사가 아닐 뿐이라는 사실만 알려줍니다. 측정된 오류: Filesystem-Based Memory는 UIUC가 주도했지만, Adobe가 유일한 매칭이었기 때문에 Adobe 주도로 잘못 분류되었습니다.
4. 회사 이름이 논문에 있다고 해서 회사 논문인 것은 아닙니다. 보고서에서 *만이 주도를 의미합니다. 2주 기간 측정: Google은 10건 히트했지만 4건만 주도; Google DeepMind 7건 히트, 2건 주도; Adobe 5건 히트, 0건 주도. 'N개의 빅테크 논문'이라는 주장은 반드시 어떤 열(column)을 의미하는지 명시해야 합니다.
5. 수치를 제시하기 전에 맹점을 먼저 밝히십시오.
- 제출물의 12%는 PDF 전용이므로 보이지 않습니다 — 1단계의 한계
- Apple 누락률 약 78% (저자가 소속을 자주 생략함) → 공식 RSS 피드로 패치. 이 보충은 선택이 아닌 필수입니다
- 첫 번째 저자가 여러 소속을 나열할 경우 순위를 매길 수 없습니다. 둘 다
*처리됩니다. intern은 마커일 뿐 판단이 아닙니다. 인턴의 논문을 '해당'으로 셀지 여부는 정의적 질문이며, 호출자가 결정할 수 있도록 정보를 제공합니다.
세 가지 오류 계층 — 혼동하지 마십시오
| 계층 | 문제 | 실패 시 조치 |
|---|---|---|
| 1 추출 | 텍스트를 전혀 가져올 수 없음 | 보충 출처 사용; 오늘날 모든 누락은 이 계층에 있습니다 |
| 2 구조 | 저자를 소속에 매핑할 수 없음 | 전체 블록 스캔으로 저하 (정밀도는 낮아짐) |
| 3 개체 | 이 문자열이 어떤 회사인지 | unmatched는 원시 텍스트를 테이블에 유지; ROR은 이 계층에서만 작동합니다 |
ROR은 문자열-대-ID 조회 테이블입니다. 먼저 문자열이 필요합니다. 두 개의 샤오미 논문 측정: 하나는 HTML이 전혀 없었고, 다른 하나의 저자 블록에는 8명의 사람 이름만 있고 소속 단어는 하나도 없었습니다. ROR은 어느 쪽도 구할 수 없습니다. 보충 출처만이 가능합니다.
각 보충 출처가 유지되는 이유
| 출처 | 역할 | 증거 |
|---|---|---|
| Apple RSS | 체계적인 누락 수정, 필수 | 2주 기간: 스크래핑 2건 대비 공식 9건 — 78% 누락 |
| arXiv 팀 이름 | '회사 이름이 소속 슬롯이 아닌 저자 슬롯에 있는 경우' 커버 | Xiaomi MiMo Team / Kimi Team; 2개 논문 추가, 중복 없음 |
| MSR 임베디드 JSON | 교차 검증 프로브 | 25건 스크래핑 대비 7건 공식 — 중복되지만, 실행 내 통제로 유지: 공식 출처에 저자 블록이 놓친 논문이 있다면 1단계가 손상된 것 |
회사 결과가 0으로 나올 때 — 이 순서로 확인하십시오
- 잘못된 기간 — arXiv는 1-2일 늦게 색인되며 주말에는 발표하지 않습니다. 먼저 기간을 넓히십시오.
- 잘못된 카테고리 — 기본값은 cs.AI/cs.CL/cs.LG입니다. 로보틱스는 cs.RO, 비전은 cs.CV, 시스템은 cs.SE입니다.
- 팀 이름 검색 —
all:"Xiaomi"/"Hunyuan"/"Kimi Team"작동;all:"MiniMax"는 사용 불가 (minimax 알고리즘으로 5800개 이상 히트) —au:"MiniMax"사용 - 공식 채널 — Apple RSS, Meta의
ai.meta.com/results/?content_types[0]=publication(참고:/research/publications/는 일반 curl에 400 반환), NVIDIAresearch.nvidia.com/publications - 위의 모든 것이 비어 있을 때만 "이 회사는 이 기간에 아무것도 발표하지 않았습니다"라고 말할 수 있습니다.
로드맵
- TeX 소스를 1단계의 2티어로 추가 —
arxiv.org/e-print/{id}를 압축 해제하고\author{}를 읽습니다. 확인 결과: HTML이 없는 논문에도 TeX는 있는 경우가 많으며, 위첨자가 온전합니다. 가장 저렴하게 얻을 수 있는 커버리지 향상 - 실행 내 상태 자체 점검 — 1단계의 저자 블록 히트율과 '공식 출처에는 있지만 저자 블록에는 없는' 논문 수를 보고서 헤더에 직접 포함. arXiv 마크업 변경 시 조용한 오류를 방지합니다(78% Apple 누락은 우연히 발견되었습니다). 이를 위해 저장된 과거 히트율을 다시 도입하지 마십시오 — 실행 내 교차 검증으로 충분합니다.
한 가지 더
논문 수는 공급(supply)이지 인기(heat)가 아닙니다. 측정 결과: 2주 기간의 231개 빅테크 논문 중 0개가 Hacker News에서 논의되었으며, 같은 기간 Hacker News에서 논의된 모든 논문은 학계나 스타트업에서 나왔습니다. 인기를 판단하려면 별도의 사회적 신호가 필요합니다.