科研模拟面试

Simulation d'entretien de recherche (Research Mock Interview) – Skill Hermes

1. Qu'est-ce que c'est ?

Un système de simulation d'entretien de recherche local-first livré sous forme de Skill Hermes. Il lit les documents réels du candidat (CV / projets / articles) et, pour les scénarios d'admission en master/doctorat, d'entretien de poste en recherche, de soutenance, de réunion d'équipe et de PhD à l'étranger, utilise un backend LLM interchangeable pour jouer le rôle d'un examinateur rigoureux lors d'un dialogue multi-tours. Lorsque le candidat répond de manière trop superficielle à propos de ses projets / code, le système déclenche une relance dure. À la fin, il produit une note, une base de points faibles et un rapport de débriefing.

1.1 Cohérence avec l'architecture (décisions verrouillées)

• X1 Utilisateur cible : Tous les profils (admission master/doctorat + version légère pour entretien). La base de questions v1 couvre les six scénarios : admission master/doctorat, entretien de poste, soutenance, réunion d'équipe, PhD à l'étranger.
• X2 Format : Skill Hermes local + contenu public pour attirer ; ce dépôt est le Skill lui-même.
• X3 Vocale : v1.1 intègre un « duplex vocal interchangeable » – mock permet de tester toute la chaîne hors ligne sans dépendance ; les vrais STT (vosk/whisper) et TTS (pyttsx3/edge-tts) sont des backends optionnels, chargés paresseusement, avec message d'erreur clair en cas de dépendance manquante (sans casser le cœur zéro-dépendance).
• X4 Collecte depuis WeChat : Abandonné. Ce Skill ne collecte aucune source externe.
• X5 Version Python : Cible 3.12, minimum 3.11 (voir requirements.txt et §6).
• Backend LLM interchangeable : Interface abstraite + mock (hors ligne, zéro dépendance) / ollama (backend local par défaut) / cloud (BYOK, clé jamais écrite sur le disque).
• Données de démarrage à froid : Exemples anonymisés fournis (data/sample_profile.json), point d'entrée réservé pour les données réelles (cli run --profile).
• Règle de confidentialité absolue : Locataire unique local, supprimable, aucune télémétrie, aucune donnée hors domaine ; tenant_id=local ; purge supprime en un clic toutes les données du propriétaire.

2. Quand déclencher

• L'utilisateur souhaite s'entraîner / faire un débriefing pour un entretien de recherche (admission master/doctorat, poste en recherche, soutenance, réunion d'équipe, PhD à l'étranger).
• L'utilisateur veut un test de résistance basé sur son expérience de projet, pour « expliquer clairement, expliquer en détail ».
• L'utilisateur a besoin d'un rapport de débriefing structuré et d'une liste de points faibles consolidée.

3. Workflow (ordre d'exécution par l'utilisateur)

Étape 1 : Préparation de l'environnement (une fois)

cd research-mock-interview
python --version            # doit être >=3.11, recommandé 3.12
pip install -r requirements.txt   # optionnel : requis seulement si vous utilisez config.yaml (PyYAML)

Étape 2 : Exécuter la démo (même hors ligne)

python src/cli.py run --demo

--demo utilise les données d'exemple intégrées + le backend mock, exécute automatiquement le cycle « question → réponse → relance dure → notation → rapport de débriefing », prouvant que le système fonctionne hors ligne et que les données sont écrites dans SQLite local.

Étape 3 : Intégrer vos vraies données

Préparez votre vrai CV/projet en JSON (voir les champs de data/sample_profile.json), puis :

python src/cli.py run --profile /chemin/vers/votre_profil.json --scenario admission_master

Mode interactif : répondez tour par tour ; tapez /finish pour terminer et générer le rapport, /quit pour quitter en cours de route (les enregistrements sont conservés).

Étape 4 : Changer de backend LLM (optionnel)

Copiez config.example.yaml en config.yaml, modifiez llm.backend en :

• mock : zéro dépendance hors ligne (par défaut, idéal pour démo / sans réseau).
• ollama : backend de production local par défaut, renseignez base_url / model (ex. qwen2.5:7b).
• cloud : API cloud (BYOK), la clé vient uniquement d'une variable d'environnement (ex. RMI_LLM_API_KEY), jamais codée en dur / écrite sur le disque.

Étape 5 : Consulter les données et exercer le droit de suppression

python src/cli.py list          # Liste tous les entretiens de ce tenant
python src/cli.py report --id <8 premiers ou session_id complet>   # Voir le rapport
python src/cli.py weakness      # Voir la base de points faibles
python src/cli.py purge --yes   # Droit de suppression : efface toutes les données locales de ce tenant

Étape 6 (nouveau v1.1) : Mode duplex vocal (interchangeable)

# Auto-test hors ligne : duplex mock, sans micro ni réseau, prouve que la chaîne vocale fonctionne
python src/cli.py run --demo --voice

# Intégration vocale réelle (nécessite pip install des dépendances optionnelles, voir requirements.txt)
# Copiez config.example.yaml en config.yaml, mettez voice.enabled=true ou ajoutez --voice à l'exécution,
# et modifiez voice.stt/tts.backend en vosk/whisper/pyttsx3/edge, renseignez les chemins de modèles.

Étape 7 (nouveau v1.1) : Analyse transversale des points faibles

python src/cli.py analyze                 # Agrégation tous scénarios
python src/cli.py analyze --scenario admission_master   # Un seul scénario
python src/cli.py analyze --out report.md  # Exporter en rapport Markdown

Dimensions d'agrégation : répartition par catégorie, répartition par gravité, tendance transversale (amélioration / détérioration / stable), points faibles récurrents (≥2 fois) et recommandations d'action.

4. Responsabilités des modules (src/)

• llm_backend.py : Abstrait LLMBackend + MockBackend / OllamaBackend / CloudBackend, usine from_config(cfg) pour basculer selon la config.
• storage.py : Store encapsule la persistance SQLite locale, isolée par tenant, purge_owner() implémente le droit de suppression.
• interview_engine.py : InterviewSession pilote le cycle « importation → questions → relance dure → notation → base de points faibles → rapport de débriefing ».
• voice_io.py (v1.1) : STTProvider / TTSProvider / DuplexVoice interchangeables ; mock zéro dépendance hors ligne, vrais backends chargés paresseusement avec garde de dépendance manquante.
• analytics.py (v1.1) : aggregate_weaknesses / render_aggregate_report pour l'agrégation transversale des points faibles (bibliothèque standard uniquement).
• cli.py : Point d'entrée argparse (run / list / report / weakness / purge / analyze, run supporte --voice).

5. Règles de conception (à ne pas enfreindre)

1. Pas de données hors domaine : Toutes les données restent dans SQLite local ; le backend cloud envoie uniquement le texte de l'entretien à l'API configurée par l'utilisateur, la clé vient uniquement d'une variable d'environnement.
2. Pas de télémétrie : Aucune collecte ni envoi de données d'utilisation.
3. Supprimable : data_dir peut être supprimé entièrement ; purge offre une suppression programmatique en un clic.
4. Backend interchangeable : Le code métier dépend uniquement de l'abstrait LLMBackend ; ajouter un nouveau backend nécessite seulement d'implémenter generate().
5. Démarrage à froid : Les données d'exemple garantissent un fonctionnement immédiat ; les données réelles sont importées via --profile, avec un format rétrocompatible.

6. Environnement d'exécution

• Python cible 3.12 ; minimum 3.11 (voir commentaires requirements.txt).
• Dépendances cœur uniquement de la bibliothèque standard ; PyYAML est optionnel (uniquement si vous utilisez config.yaml).
• La partie vocale est optionnelle : le cœur reste sans dépendance tierce ; les dépendances STT/TTS réelles ne sont nécessaires que si la voix est activée et qu'un vrai moteur est choisi (voir commentaires requirements.txt).