paper-radar — ビッグテックAI論文レーダー は何をしますか?
ステートレス:1回の実行 = 1つの期間 = 1つのレポート。論文ライブラリは維持しません。 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 - # レポートをstdoutに書き出す
タイミング: 2週間のウィンドウ(約3000論文)の場合、メタデータ取得に約2分、著者ブロック取得に6ワーカーで約25秒。3日間のウィンドウは1分以内に終了します。より長い履歴をカバーするには、ウィンドウを広げて再実行してください — クエリ可能なライブラリはありません。
レポートの出力先 — あなたが決めます。スクリプトは推測しません。
スクリプトは、呼び出し元のプロジェクトが研究をどこに保存しているかを知らず、知るべきでもありません。-o が指定されない場合、カレントワーキングディレクトリに書き込みます。
実行ごとに出力先を決定してください:
- ユーザーがパスを指定した → それを使う
- これは保存する価値のある研究 → そのプロジェクトの研究ディレクトリに、ファイル名にウィンドウを含めて書き込む
- ただ一つの事実を確認しているだけ(「Xiaomiは自己進化型AIについて発表したか?」) →
-o -を使用し、ファイルを残さない。捨てるだけの質問でファイルを残すと、後で研究記録のように偽装されます。
ファイル
| パス(このスキルからの相対) | 役割 |
|---|---|
scripts/paper_radar.py | パイプライン:リスト取得 → 著者ブロック取得 → 所属解決 → レポート書き出し |
scripts/affiliation.py | 解決層:上付きマッピング + 3層マッチング |
scripts/data/ror_anchors.json | 28ラボのROR ID + 98の公式名称バリアント(中国語を含む) |
唯一の出力は1つのMarkdownファイル(上記のパスに従う)で、「総ヒット数/うちリード数」の分割表示が含まれます。スキルディレクトリ自体はファイルを生成しません。
6段階
0 リスティング arXiv API:カテゴリ × submittedDate → IDで重複排除
1 全文テキスト arxiv.org/html/{id} + Range 最初の90KB、ltx_authors で切り取り → ltx_abstract [85%]
2 構造解析 右から左にスキャンし、昇順 1,2,3… の連続が始まる最後の位置を見つける
抽出 (著者, マーク[]) · (マーク, 所属) · メール · 役割マーカー
3 エンティティ (a) メールドメイン (b) ROR名称バリアント (c) ラボエイリアステーブル
4 グレーディング lead_orgs = 最初の著者の所属(複数の可能性あり)、intern = マーカー存在
5 補足 Apple RSS · MSR埋め込みJSON · arXivチーム名
6 レポート キーで重複排除(1つの論文が著者ブロックと公式ソースの両方から来ることがある)、
Markdownを書き、evidence + matched_on を保持
5つの規律 — それぞれがバグ代を払って得たもの
1. 著者ブロックは ltx_abstract で厳密に切り取らなければならない。 1文字でも多く取るとアブストラクトが混入する。実測結果:Oracle 73論文(すべて「oracle access」)、MiniMax 17(minimaxアルゴリズム)、DeepSeek 58(単にモデルに言及した論文)。きれいに切り取った場合、著者ブロックの中央値は約201文字。
2. 所属リストは右から左に見つけなければならない。 著者ラン内の「名前+上付き数字」と所属ラン内の「数字+所属」は同じ形状を持つため、左から右へのスキャンは Yuchen Zhao 1 Bingxuan Li を 1 → "Bingxuan Li" と解析してしまう。
3. 「マッチした会社が1つだけだからリード」というフォールバックは絶対にしない。 それは単に、他の所属がトラックしている企業でないことを示すだけ。実測誤認識:Filesystem-Based Memory はUIUC主導だが、Adobeが唯一のマッチだったためAdobe主導と評価された。
4. 会社のバイライン=その会社の論文ではない。 レポート内の * のみがリードを意味する。2週間のウィンドウで実測:Google 10件ヒット、リードはわずか4件;Google DeepMind 7件ヒット、リード2件;Adobe 5件ヒット、リード0件。「N本のビッグテック論文」という主張は、どの列を指すかを明示しなければならない。
5. 盲点を数値の前に述べよ。
- 提出物の12%はPDFのみで不可視 — 段階1のハード上限
- Appleの見逃し率は約78%(著者が所属を省略することが多い)→ 公式RSSフィードでパッチ。この補足は必須、オプションではない
- 最初の著者が複数の所属をリストしている場合、それらは順位付けできない。両方に
*が付く internはマーカーであり、判断ではない — インターンの論文を「カウントするか」は定義上の問題であり、呼び出し側が決定するために情報を提示している
3層のエラー — 混同しないでください
| 層 | 問題 | 失敗時の対処 |
|---|---|---|
| 1 抽出 | テキストをまったく取得できない | 補足ソース;今日のミスはすべてこの層にある |
| 2 構造 | 著者を所属にマッピングできない | 精度は低下するが、ブロック全体スキャンに劣化 |
| 3 エンティティ | この文字列はどの会社か | unmatched は生テキストをテーブルに保持;RORはここでのみ動作する |
RORは文字列からIDへのルックアップテーブルであり、まず文字列が必要です。 2件のXiaomi論文で実測:1件はHTMLがまったくなく、もう1件の著者ブロックには人物名8つと所属の単語が1つもなかった。RORはどちらも救えません — 補足ソースのみが可能。
各補足ソースが残る理由
| ソース | 役割 | 根拠 |
|---|---|---|
| Apple RSS | 体系的な見逃しを修正、必須 | 2週間のウィンドウ:スクレイプ2件 vs 公式9件 — 78%見逃し |
| arXivチーム名 | 「会社名が著者スロットにあり、所属スロットにない」場合をカバー | Xiaomi MiMo Team / Kimi Team;2論文追加、重複ゼロ |
| MSR埋め込みJSON | クロスチェックプローブ | スクレイプ25件 vs 公式7件 — 冗長、実行内コントロールとして維持:公式ソースが著者ブロックが見逃した論文を持っている場合、段階1が壊れている |
企業がゼロ件と表示された場合 — この順序で確認
- ウィンドウが間違っている — 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見逃しは偶然発見された)。このために過去のヒット率を保存してはいけない — 実行内クロスチェックで十分
もう一つ
論文数は熱量ではなく供給を示す。 実測:2週間のウィンドウ内のビッグテック論文231件のうち、Hacker Newsで議論されたものは0件。一方、同じウィンドウでHNで議論されたすべての論文はアカデミアまたはスタートアップからのものだった。熱量を判断するには、別の社会的シグナルが必要です。