Agent RAG conversationnel via Telegram qui interroge mes documents Google Drive (papiers immobilier, assurance, contrats) et indexe automatiquement de nouvelles collections. Architecture multi-workflow n8n : orchestrateur Telegram + pipeline d'ingestion idempotent (Postgres + Qdrant) + agent RAG hybride metadata + sémantique.
À l'achat de mon appartement (octobre 2024), je me retrouve avec un Google Drive saturé de papiers : acte notarié, crédit immobilier, contrats d'assurance, assemblées de copropriété, factures travaux. Retrouver une info précise ("quelle est la franchise dégât des eaux ?", "date de la prochaine AG ?") devient pénible : il faut ouvrir chaque PDF un par un et le parcourir à la main, sans garantie de trouver.
Objectif : un agent RAG conversationnel via Telegram qui interroge mes documents indexés et met à jour automatiquement la collection quand j'ajoute des fichiers dans Drive. Conçu générique dès le départ : 1 dossier Drive = 1 collection RAG paramétrée par nom. Aujourd'hui un dossier unique rag_appart qui regroupe tous les papiers de l'appart (crédit, assurance, AG copro, contrats, manuels) ; demain un rag_societe ou un autre contexte si besoin, sans refonte.
Mon rôle : conception et développement complet de l'architecture multi-workflow n8n (orchestrateur + 2 sous-workflows), déploiement self-hosted.
Bot Telegram qui accepte texte ou audio (transcription LLM), avec un AI Agent routeur qui sélectionne dynamiquement entre 2 outils : recherche RAG ou indexation d'un nouveau dossier. Mémoire conversationnelle indexée par chat.
Défis techniques : entrée multi-modale (text + voice), routing fiable vers les bons sous-workflows selon la requête, mémoire stable par utilisateur sans fuite entre conversations.
Solutions : Switch n8n sur le type de message (text vs voice), AI Agent avec system prompt strict définissant les 2 outils + leurs cas d'usage, sous-workflows exposés comme tools n8n (Tool Workflow) callables comme des fonctions par l'agent.
Workflow d'indexation avec 3 triggers (formulaire, webhook, sub-workflow) qui scanne un dossier Google Drive, détecte les fichiers nouveaux/modifiés, les chunke, génère les embeddings et persiste dans Qdrant. Metadata enrichies par un summarizer LLM (theme, topics, painPoints, keywords).
Défis techniques : éviter le re-embedding inutile à chaque exécution (coût), gérer la suppression propre dans Qdrant quand un fichier est modifié, prendre en charge plusieurs formats (PDF, DOCX, Google Docs natifs), créer dynamiquement les tables Postgres et collections Qdrant par dossier.
Solutions : table Postgres metadata par collection avec dates de référence, comparaison Drive vs Postgres → skip si inchangé, sinon delete sur metadata.fileId dans Qdrant + reinsert ; switch sur mimeType pour brancher l'extracteur PDF ou DOCX ; chunking 800 / overlap 100 ; tables et collections nommées par dossier pour cloisonner les domaines.
Sous-workflow qui répond aux questions utilisateur en 2 étapes : d'abord validation de la collection cible (un mini-agent vérifie qu'elle existe, sinon demande à clarifier), ensuite recherche hybride (un agent principal interroge les metadata Postgres pour identifier les documents pertinents, puis fait la recherche sémantique Qdrant en filtrant sur les fileId retenus).
Défis techniques : éviter le bruit du RAG pur sémantique (extraits hors-sujet qui correspondent par embedding seul), garantir la traçabilité des sources dans la réponse, robustifier le format de sortie JSON malgré les hallucinations LLM.
Solutions : pré-filtrage par metadata structurée (theme/topics/keywords) avant la recherche sémantique, output structuré {message, sources: {documents, themes, keywords}} avec citation systématique des fichiers, auto-fixing parser via le pattern LangChain OutputFixingParser (LLM secondaire Claude Sonnet qui reformate l'output JSON quand le LLM principal sort un format invalide).
rag_appart : ~30 documents indexés (acte notarié, crédit immobilier, contrats d'assurance, AG copropriété, manuels électroménagers, factures travaux)