Deep Review à la Google : segmentation → vérification parallèle → contre-expertise → consolidation

Reproduit la conception publique du Deep Review de Google (successeur du Paper Assistant Tool testé à STOC, ICML, NeurIPS, ICLR pour les auteurs) à l'aide de sous-agents Claude. Objectif : montrer à l'auteur, avant soumission, les véritables erreurs (lacunes de preuve, erreurs de calcul, incohérences numériques, affirmations plus fortes que les preuves, comparaisons manquantes) qu'il ne peut pas voir lui-même, classées par priorité et vérifiables. Pas de note.

Étapes et justification :

Étape	Responsable	Justification
1 Ingestion	Script	Préparer à la fois le texte et les images de page. Le texte extrait déforme les équations et tableaux, donc les images sont nécessaires.
2 Segmentation et allocation budgétaire	Vous	Concentrer les calculs sur les parties denses en preuves, survoler rapidement l'introduction et les travaux connexes.
3 Vérification parallèle approfondie	Sous-agents (segment x perspective, lentilles)	Limiter la plage de lecture approfondie à la fois, augmenter la couverture avec des regards indépendants de perspectives différentes.
4 Fusion et dédoublonnage	Script	Vérifier mécaniquement si les citations textuelles existent dans l'article, regrouper les mêmes problèmes.
5 Contre-expertise	Sous-agent	La recherche d'erreurs génère de plus en plus de faux positifs à mesure qu'on répète les essais. Un regard différent, soupçonneux, rétablit la précision.
6 Synthèse	Sous-agent	Détermination de la sévérité, priorité, contrôle de la longueur, feedback général.
7 Rapport	Script → Vous	Créer report.md / report.html, résumer brièvement les points clés.

La justification de la conception (d'où viennent les connaissances de quelles références) se trouve dans references/research_basis.md.

Ci-dessous, <skill_dir> est le répertoire contenant ce SKILL.md, <ws> est le dossier de travail, deep_review.py est l'abréviation de python <skill_dir>/scripts/deep_review.py. Si python n'existe pas, utiliser python3.

0. Avant tout : vérifier la profondeur et le focus

Identifier le document cible. Le PDF est le meilleur (permet de créer des images de page). Accepte également .md / .txt / .tex, mais dans ce cas, impossible de vérifier les images des figures et équations. Si seul le source LaTeX est disponible et qu'il peut être compilé, le convertir en PDF avant utilisation.
Demander la profondeur et le focus en une seule fois, via un outil de question (AskUserQuestion) ou par chat. Ne pas demander les éléments déjà connus par le message de lancement. Si la réponse est "Fais-le tout de suite" ou "Je te laisse faire", commencer avec standard et aucun focus.
- Question 1 "Profondeur" : Standard (recommandé) / Quick / Deep (joindre une explication basée sur le tableau ci-dessous)
- Question 2 "Points à examiner attentivement" (choix multiples possibles) : Aucun en particulier / Preuves et équations / Expériences et statistiques / Nouveauté et travaux connexes (possibilité d'ajouter une cible de publication ou un texte libre dans "Autre")

Profondeur	Nombre de segments	Nombre de traces par segment	Lentilles	Cible de la contre-expertise	Estimation du nombre d'agents	Estimation du temps
quick	2 à 4	1	L0 (synthèse)	Major et emplacement inconnu	4 à 8	10 à 20 min
standard	4 à 8	High 2, autres 1	L1, L2, L3	Major et emplacement inconnu	10 à 20	20 à 45 min
deep	5 à 12	High 3, Medium 2, Light 1	L1, L2, L3	+ Minor liés aux équations, statistiques, valeurs ; agent critique	20 à 40	45 à 90 min

Le temps varie considérablement selon la longueur de l'article.

Si l'utilisateur semble vouloir examiner le manuscrit d'autrui en tant que relecteur, ajouter un mot pour vérifier la politique d'utilisation de l'IA de la cible de publication (de nombreux éditeurs et conférences interdisent de soumettre un manuscrit en cours de relecture aux outils d'IA). Inutile si l'auteur examine son propre manuscrit.

1. Ingestion

python <skill_dir>/scripts/deep_review.py init <chemin du document> --depth standard --focus "<focus, omettre si aucun>" --venue "<cible de publication, omettre si aucune>" --lang fr

Le dossier de travail sera <dossier du document>/<nom du document>_deep_review/ (si impossible à écrire, sous le répertoire courant, peut être spécifié avec --ws)
Il crée paper.txt (séparé par === Page N ===), pages/page_NNN.png (150 dpi), pages.json, config.json
Le plan de chaque page (nombre de mots, proportion de symboles mathématiques, nombre d'équations numérotées, nombre de théorèmes et preuves, titres, légendes de figures/tableaux) sera utilisé à l'étape suivante
Lire les WARN s'il y en a. Si le texte extrait est pauvre (PDF scanné, etc.), ajouter dans la demande à chaque agent de se concentrer sur les images de page.
La langue du rapport est --lang (ja / en). Adapter à la langue de l'utilisateur. Les citations restent en langue originale.

2. Segmentation et allocation budgétaire

Examiner le plan et écrire <ws>/segments.json. Si le titre ne suffit pas à comprendre le contenu de la page, regarder la page correspondante dans paper.txt (inutile de lire tout le texte).

Règles :

Diviser en blocs logiques (théorie, méthode, expériences, introduction, etc.). Les chevauchements sont autorisés, la continuité n'est pas nécessaire. Par exemple, "l'énoncé du théorème dans Sec. 3" et "sa preuve dans l'annexe B" peuvent être dans le même segment.
Inclure toutes les pages dans un segment (plan le vérifie).
Déterminer la piste (profondeur) par densité d'information :
- high : théorème principal et sa preuve, déductions centrales, cœur de l'algorithme dont on affirme la correction. Si l'affirmation principale de l'article est le résultat expérimental lui-même, inclure la section avec les tableaux/figures des résultats principaux.
- medium : description de la méthode, expériences, expériences supplémentaires en annexe.
- light : introduction, travaux connexes, discussion, conclusion.
- none : références, remerciements, etc. (reason obligatoire ; les références seront examinées par la lentille L3).
Les segments en high doivent faire 8 à 10 pages maximum (si plus long, diviser).
theme : intro / related_work / discussion / other / method / algorithm / system / theory / appendix_proofs / experiments / analysis / appendix_experiments / references
Dans notes, on peut écrire une ligne sur ce qu'on veut dire à l'agent responsable (l'affirmation que ce segment soutient, l'emplacement de la définition dont il dépend, etc.).

{
  "segments": [
    {"id": "S1", "title": "Introduction et contributions", "pages": "1-2", "theme": "intro", "track": "light",
     "notes": "Contributions C1 – C3 dans la liste à puces p.2"},
    {"id": "S2", "title": "Théorème principal et sa preuve", "pages": "4-5,13-16", "theme": "theory", "track": "high",
     "notes": "Preuve du Théorème 2 (p.5) dans l'annexe B (p.13–16). Hypothèses : Assumption 1–3 p.3"},
    {"id": "S3", "title": "Algorithme proposé", "pages": "3-4", "theme": "algorithm", "track": "medium"},
    {"id": "S4", "title": "Expériences", "pages": "6-9", "theme": "experiments", "track": "medium"},
    {"id": "S5", "title": "Travaux connexes et conclusion", "pages": "9-10", "theme": "related_work", "track": "light"},
    {"id": "S6", "title": "Références", "pages": "11-12", "theme": "references", "track": "none",
     "reason": "Les références sont inspectées ponctuellement par la lentille L3"}
  ]
}

Créer ensuite le plan :

python <skill_dir>/scripts/deep_review.py plan <ws>

plan.json contient la liste des agents à lancer (ID de tâche, segment responsable, piste, trace = perspective, pages, sortie, effort recommandé). En cas d'erreur, corriger segments.json et réexécuter.

Informer l'utilisateur en une ligne : Segmentation terminée : 6 segments (1 High, 2 Medium, 2 Light), lancement parallèle de 9 agents de vérification

3. Vérification parallèle approfondie

Lancer toutes les tâches de plan.json en parallèle dans un seul message à l'aide de l'outil Agent (si plus de 10, les diviser en vagues d'environ 8). Chaque tâche a un effort. Si l'outil Agent permet de spécifier l'effort, lancer avec cette valeur (pour allouer plus de raisonnement aux pistes High).

Message de mission pour l'agent de vérification de segment (kind: segment)

Vous êtes un "agent de vérification de segment" du Deep Review. Lisez d'abord ce qui suit jusqu'au bout, puis suivez les instructions et le format de sortie.
  <skill_dir>/references/segment_reviewer.md
  <skill_dir>/references/checklists.md (sections pertinentes pour le thème)
  <skill_dir>/references/schemas.md §1 et §4

- Texte complet de l'article : <ws>/paper.txt (=== Page N === est le numéro de page)   Images des pages : <ws>/pages/page_NNN.png
- Document original : <ws>/<input_copy de config.json>
- Tâche : <T03>   Segment : <S2> "<titre>"   Pages : <4-5,13-16>   Thème : <theory (proof)>
- Piste : <high>   Trace : <B — contre-exemples, limites, hypothèses>
- Note du segment : <notes, ou "aucune" si absent>
- Focus spécifié par l'utilisateur : <focus ou "aucun">   Cible de publication : <venue ou "aucune">
- Sortie : <ws>/<candidates/T03_S2_B.json>
- Aide : python <skill_dir>/scripts/pdf_tools.py (crop, render --grid pour agrandir figures et équations)

Lisez l'intégralité du texte comme contexte, mais concentrez vos remarques sur les pages qui vous sont attribuées. Un autre agent examine le même segment sous une perspective différente.

Pour les tâches qui regroupent plusieurs segments sur la piste Light, lister tous les segments dans le champ segment.

Message de mission pour l'agent lentille (kind: lens)

Vous êtes un "agent lentille" du Deep Review (<L2 Nouveauté et importance>). Lisez d'abord ce qui suit jusqu'au bout, puis suivez les instructions et le format de sortie de la section de votre lentille.
  <skill_dir>/references/lens_reviewers.md
  <skill_dir>/references/checklists.md (§6 à §8)
  <skill_dir>/references/schemas.md §1 et §4

- Texte complet de l'article : <ws>/paper.txt   Images des pages : <ws>/pages/page_NNN.png
- Tâche : <T08>   Lentille : <L2>
- Focus spécifié par l'utilisateur : <...>   Cible de publication : <...>
- Sortie : <ws>/<candidates/T08_L2.json> (inclure également overall_notes)

Examinez l'ensemble de l'article de manière transversale sous l'angle de votre lentille. Des vérifications approfondies par plage sont effectuées par d'autres agents.

Attendre que tous les agents aient terminé, puis réexécuter plan pour vérifier que toutes les tâches sont marquées [done]. Relancer une seule fois les tâches manquantes. Si elles manquent encore, passer à l'étape suivante et ordonner à l'agent de synthèse de les mentionner dans les limitations.

Informer l'utilisateur en une ligne : Vérification 9/9 terminée

4. Fusion et dédoublonnage

python <skill_dir>/scripts/deep_review.py merge <ws>

Vérifie si chaque citation textuelle de chaque candidat existe dans l'article (exact / fuzzy / not_found) et sa page, regroupe les candidats proches en clusters (K01, …) et les écrit dans merged.json.
support est le nombre de tâches qui ont trouvé le même problème de manière indépendante. Plus un problème est trouvé par plusieurs traces différentes, plus il a de chances d'être réel.
Le lot de contre-expertises (V01, …) est généré. S'il y a des avertissements invalid ou missing outputs, les enregistrer comme des problèmes de l'agent qui a écrit le fichier concerné.

Informer l'utilisateur en une ligne : 64 candidats → fusion en 38, dont 9 soumis à contre-expertise

5. Contre-expertise

Lancer les verify_tasks de merged.json en parallèle dans un seul message.

Message de mission pour l'agent de contre-expertise

Vous êtes un "agent de contre-expertise" du Deep Review. Lisez d'abord <skill_dir>/references/verifier.md et 
<skill_dir>/references/schemas.md §2 jusqu'au bout.

- Texte complet de l'article : <ws>/paper.txt   Images des pages : <ws>/pages/page_NNN.png
- Cibles de vérification : parmi les clusters de <ws>/merged.json, <K01, K04, K07> (pages pertinentes : <...>)
- Sortie : <ws>/verdicts/<V01>.json

Pour chaque candidat, essayez d'abord de le réfuter en partant du principe que "l'article est correct", puis ne confirmez que ceux que vous pouvez reproduire vous-même de manière indépendante (avec des preuves concrètes comme un recalcul, un contre-exemple, deux citations contradictoires, etc.).

Une fois terminé :

python <skill_dir>/scripts/deep_review.py collate <ws>

Crée collated.json qui associe les résultats de vérification aux clusters. refuted / cannot_locate sont recommandés pour suppression.

Informer l'utilisateur en une ligne : Contre-expertise terminée : 5 confirmés, 2 valides, 2 faux positifs

6. Synthèse

Message de mission pour l'agent de synthèse

Vous êtes un "agent de synthèse" du Deep Review. Lisez d'abord <skill_dir>/references/synthesis.md et 
<skill_dir>/references/schemas.md §3 et §4 jusqu'au bout.

- Entrée : <ws>/collated.json (candidats, résultats de vérification, observations des lentilles, distribution des perspectives), <ws>/paper.txt,
        <ws>/pages/, <ws>/config.json (profondeur, focus, cible de publication, langue)
- Sortie : <ws>/findings.json
- Après avoir écrit, exécuter python <skill_dir>/scripts/deep_review.py render <ws> --check et
  corriger jusqu'à ce qu'il n'y ait plus d'erreurs.
- Langue du rapport : <français>   Focus spécifié par l'utilisateur : <...>   Cible de publication : <...>
- Complément : <tâches manquantes, etc., à écrire dans limitations. "aucun" si absent>

Uniquement pour deep : agent critique. Une fois que l'agent de synthèse a terminé, charger un autre sous-agent avec :

Vous êtes un "agent critique" du Deep Review. Vérifiez <ws>/findings.json (brouillon de l'agent de synthèse) en le confrontant à <ws>/paper.txt et
<ws>/pages/. Examinez tous les éléments selon les perspectives de <skill_dir>/references/synthesis.md §8
(précision de la citation et de l'emplacement, spécificité, validité de la sévérité, existence des références externes, ton, longueur) et
vérifiez personnellement tous les Major.
Ne cherchez pas de nouvelles remarques.
Écrivez le résultat dans <ws>/critique.md sous forme de liste à puces "ID · Problème · Correction".

Une fois critique.md créé, demander à l'agent de synthèse (via SendMessage) : "lis critique.md, intègre les points valides dans findings.json et exécute render --check". (Si SendMessage n'existe pas, lancer un nouvel agent de synthèse avec la même demande.)

Enfin :

python <skill_dir>/scripts/deep_review.py render <ws>

Crée report.md et report.html. Le HTML permet de filtrer par Major / Minor / Suggestions et de basculer entre l'ordre du rapport et l'ordre des pages.

7. Rapport à l'utilisateur

Lire findings.json et résumer brièvement. Ne pas coller l'intégralité du rapport.

Nombre (Major / Minor / Suggestions) et nombre de faux positifs exclus par la contre-expertise.
Tous les Major concerns, une ligne chacun (ID, emplacement, point clé).
Synthèse (bottom_line) en 1 à 2 phrases.
Fichiers : report.html (à ouvrir dans un navigateur), report.md, dossier de travail.
Un mot d'avertissement : ce sont des remarques d'IA, l'auteur doit vérifier chaque remarque avant de modifier le manuscrit.

Proposer la suite : approfondissement d'une remarque spécifique, nouvelle relecture après correction, cycle de relecture avec notation et révision (paper-review-loop).

Suivi

Approfondissement ("Plus de détails sur MJ2") : désigner l'emplacement de la remarque comme périmètre de responsabilité, lancer un seul agent de vérification en piste high et trace B (contre-exemples), intégrer le résultat dans findings.json → render.
Nouvelle relecture d'une version révisée : refaire le processus complet à partir du nouveau PDF (utiliser init dans un nouveau dossier de travail). Ajouter le chemin du précédent findings.json dans le message de mission de l'agent de synthèse, et ordonner d'écrire l'état de la correspondance dans previous.
Reprise après interruption : examiner les fichiers dans le dossier de travail (segments.json → plan.json avec [done] → merged.json → verdicts/ → collated.json → findings.json), et reprendre à l'étape suivant la dernière étape terminée. init --force efface les résultats précédents, à n'utiliser que si on veut recommencer.

Lorsqu'il est appelé par d'autres skills

review2revise-loop, etc., peut appeler ce skill comme étape de relecture dans une boucle itérative. Si l'appelant spécifie l'entrée, le dossier de travail (--ws), la profondeur, le focus, la cible de publication, et le précédent findings.json :

Ne pas poser les questions du §0. Utiliser les valeurs spécifiées.
Effectuer les §1 à §6 normalement, créer findings.json, report.md, report.html. Si le précédent findings.json est spécifié, l'ajouter au message de mission de l'agent de synthèse comme previous.
Pour le rapport du §7, se limiter à une seule ligne indiquant "Nombre de Major / Minor / Suggestions" et retourner à l'appelant. Ne pas proposer la suite.
Les critères de relecture, la profondeur et la limite du nombre de remarques sont les mêmes que d'habitude. Ne pas les assouplir pour les besoins de l'appelant.

Environnement sans sous-agents

Les étapes sont les mêmes, mais vous effectuez chaque tâche vous-même séquentiellement. L'indépendance étant réduite, respecter ce qui suit.

Recommander la profondeur quick (standard si l'utilisateur le souhaite).
Avant chaque tâche, relire les pages concernées dans paper.txt et les images de page, ne pas se fier à la mémoire.
Pour chaque tâche, ne considérer que les perspectives du guide de cette tâche (segment_reviewer.md, etc.).
Pour la contre-expertise, ne pas regarder le raisonnement qui a produit les candidats ; se reposer uniquement sur les passages pertinents de l'article pour porter un nouveau jugement.

Principes et leur justification

Ne pas émettre de remarque invérifiable : citations textuelles, vérification des équations/tableaux par images, reproduction des calculs par code, existence réelle des références externes. Un rapport mêlé de faux positifs fait perdre du temps à l'auteur et érode la crédibilité des vraies remarques.
Priorité plutôt que quantité : les Major ne doivent concerner que les affirmations principales. Respecter la limite de nombre. L'insistance sur les détails et les rapports trop longs sont ce qui est le plus détesté dans les relectures par IA.
Pas de note : Deep Review se concentre sur les erreurs et les points d'amélioration, sans attribuer de note subjective. Les notes des LLM sont biaisées vers l'optimisme et instables. Si une note est souhaitée, utiliser paper-review-loop.
Laisser la décision à l'humain : C'est un outil pour l'auteur avant soumission, pas un substitut à la relecture par les pairs. La décision finale revient à l'auteur et aux relecteurs.
Protéger la confidentialité du manuscrit : Ne pas inclure de phrases du manuscrit ni de titres non publiés dans les requêtes de recherche Web. Ne pas envoyer le manuscrit à des services externes.
Ne pas modifier les fichiers originaux : tout le travail se fait dans <ws>.

Deep Review à la Google

Qu'est-ce que Deep Review à la Google ?

Demander à votre IA préférée

Documentation