Avant de construire quoi que ce soit, définissons ce qui sera réellement utile.
Vous apportez le problème. J'écoute, je pose des questions et je vous aide à déterminer si l'IA y a vraiment sa place. Si oui, nous construisons ensemble un produit fonctionnel.
Posez votre question. Trouvez le bon moment de la vidéo
Live Navigator est un bot Telegram gratuit en langue russe qui interroge les archives YouTube publiques de l'école de pensée Apeiron. Posez une question avec vos propres mots : le bot retrouve les questions les plus proches abordées dans les archives et ouvre la vidéo source au moment pertinent.
Le problème est simple : les gens retiennent le sens, pas la formulation exacte, et l'idée recherchée peut être enfouie au milieu d'une longue session en direct.
Posez une question libre → parcourez les questions les plus proches et les sujets liés → ouvrez la vidéo d'origine à l'horodatage correspondant.
État actuel
Première bêta publique, présentée à la communauté et testée par un petit groupe. L'index couvre 92 vidéos publiques, 57 thèmes et plus de 82 000 formulations de questions consultables.
Ce que j'ai pris en charge
Il s'agit de mon initiative indépendante. J'ai défini le problème, le flux produit, l'architecture de recherche, les garde-fous, les contrôles de coûts, les tests et le lancement. Des agents IA de développement m'ont aidé à écrire le code. J'ai vérifié le résultat avec des tests et directement dans l'interface.
Décisions produit
• De la recherche, pas des conseils. Le bot effectue une recherche. Il ne donne pas de conseils psychologiques. Les résultats restent liés à des vidéos publiques et à des horodatages.
• Formulation naturelle. Les questions d'origine sont enrichies de formulations alternatives. L'utilisateur n'a pas besoin de la phrase exacte d'un direct.
• Gestion des résultats faibles. Des boutons de clarification et de questions liées prennent en charge les résultats faibles, multisujets ou vides.
• Exploitation contrôlée. Un panneau d'administration, un filtre en deux étapes, des réponses en cache et des limites d'usage permettent de maîtriser les coûts et les abus.
Interface
Parcours Telegram en russe : poser une question, parcourir les questions les plus proches, ouvrir la vidéo source.
Sujets suggérés et question libre.Questions classées avec liens vers les sources.Questions liées pour poursuivre la recherche.
Architecture technique
Le bot fonctionne comme un système de recherche hybride TypeScript/Node.js sur Oracle VM. Mastra coordonne le workflow. Gemini via OpenRouter assure la classification, la planification, le scoring et la synthèse.
Couche de connaissances
Les transcriptions publiques deviennent des index de questions d'origine et synthétiques : plus de 82 000 formulations consultables réparties dans 57 fichiers JSON par thème, construites à partir de transcriptions automatiques (ASR) plutôt que des sous-titres automatiques de YouTube. Les données de recherche restent dans des fichiers JSON inspectables. SQLite stocke l'état de Mastra.
Chemin de recherche
Filtre regex → filtre LLM → chemin rapide via la FAQ ou recherche prioritaire dans les fichiers avec grep → scoring parallèle avec Map → agrégation avec Reduce → résultats liés aux sources. Les correspondances d'origine et synthétiques sont dédoublonnées par vidéo et horodatage, avec un garde-fou déterministe contre les sujets liés quasi-identiques.
Mises à jour du contenu
Un pipeline de mise à jour incrémentale de la playlist ne traite que les nouvelles vidéos, classifie les questions extraites et construit des variantes synthétiques. Les index de base se mettent à jour immédiatement. La reconstruction, plus lourde, du cache FAQ ne tourne que lorsque c'est nécessaire.
Exploitation
Accès limité aux conversations privées, limites par utilisateur et pour l'ensemble du service, tableau de bord d'administration, suivi de l'usage, des coûts et de la latence. Les questions de suivi mises en cache peuvent contourner le pipeline LLM complet ; les explications des sujets liés proviennent d'une table prégénérée — instantanées et gratuites.
Stack : TypeScript · Node.js · Mastra · Gemini via OpenRouter · Telegram Bot API · JSON / SQLite · Oracle VM
Ce qui comptait
Les gens retiennent le sens, pas les mots exacts. Le système devait relier cette formulation vague au bon moment de la vidéo, montrer la source publique, et s'arrêter là.
Experts Panel permet de choisir plusieurs praticiens de l'IA, de poser une seule question en anglais ou en russe et de recevoir des réponses distinctes, chacune appuyée sur les contenus publiés par le praticien choisi. Le système montre ensuite les points d'accord et de désaccord, avec des liens vers les publications, commentaires et vidéos d'origine.
J'ai construit cet outil parce que le savoir utile des praticiens se dispersait entre les canaux Telegram, les fils Reddit et les vidéos. La recherche était manuelle. Un LLM généraliste pouvait produire une réponse plausible. Il ne permettait pas d'attribuer clairement chaque position ni d'en retrouver la source.
Mon outil du quotidienSystème public en productionUtilisé directement et via des agents IA
Choisissez les praticiens → posez une question → recevez des réponses distinctes adossées aux sources → comparez les points de consensus et de désaccord → ouvrez les sources d'origine.
Résultat concret
Je l'utilise presque tous les jours. Cela représente déjà des centaines de petites décisions. L'explication de Refat sur l'approche centrée sur les fichiers a directement influencé Live Navigator, où j'ai stocké questions et réponses dans un stockage fondé sur des fichiers.
Ce que j'ai pris en charge
Il s'agit de mon produit indépendant. J'ai défini les corpus, le flux de recherche et de comparaison, les vérifications des sources, les intégrations d'agents, la sélection de nouveaux experts, les tests, le déploiement et la mise à jour des données en production. Des agents IA de développement m'ont aidé à écrire le code. J'ai vérifié le résultat avec des tests automatisés, en ouvrant les sources citées et directement dans l'interface.
Décisions produit
• Les sources restent liées aux réponses. Publications, commentaires et liens restent visibles. Les identifiants des sources citées sont validés avant la synthèse.
• Les corpus des experts restent séparés. Chaque corpus est traité seul avant la comparaison inter-experts, pour que le désaccord ne se dissolve pas dans une réponse moyenne.
• Les sources issues de la communauté restent séparées. Un module Reddit optionnel interroge les discussions en cours, enrichit les fils prometteurs avec des commentaires et les classe selon leur capacité à répondre à la question. Les résultats faibles sont écartés au lieu de remplir la section. Le même pipeline est aussi exposé via une API autonome authentifiée : elle renvoie une synthèse, une abstention honnête ou un échec technique explicite — jamais une réponse vide présentée avec assurance.
• La couche de sources sert aussi les agents IA. Panex fournit à d'autres projets Codex et Claude une synthèse adossée aux sources, un ensemble de sources auditable ou une expansion ciblée des sources. La décision reste au projet destinataire.
• La Knowledge Matrix filtre les nouveaux experts. Elle cartographie la couverture et le recoupement des corpus avant que j'ajoute quelqu'un au panel. La décision finale reste humaine.
• Expert Lens reste limité à un seul corpus. Il applique un seul corpus à l'analyse d'un projet sans simuler l'expert ni inventer un verdict.
Une requête sur trois corpus d'experts.Réponse de l'expert à côté de la publication source.Consensus et recommandations après analyse individuelle.Signaux uniques tenus hors du consensus.Commentaires des sources conservés comme contexte.
Architecture technique
Le système s'appuie sur un backend Python/FastAPI et un frontend React/TypeScript. Corpus Telegram, index de recherche, embeddings, commentaires, liens de sources et traductions en cache sont stockés dans SQLite. Les modèles Gemini passent par OpenRouter. La même couche de sources sert l'interface web, les appels API et CLI de Panex et les agents IA en lecture seule.
Recherche (retrieval)
Le mode de recherche hybride utilisé par Panex étend la requête, puis lance en parallèle les embeddings Gemini et la recherche FTS5/BM25. La Reciprocal Rank Fusion réunit les deux classements avant le scoring de pertinence par LLM. Chaque requête reste dans le corpus de l'expert sélectionné.
Pipeline d'analyse
Les analyses des experts sélectionnés s'exécutent en parallèle, mais chaque corpus reste isolé de la recherche à la synthèse, en passant par l'analyse des sources et la validation. Un module Reddit optionnel tourne à côté de ce pipeline et renvoie les sources issues de la communauté séparément. Il reformule une question russe en requêtes adaptées à la recherche communautaire et combine plusieurs canaux de découverte — la recherche native Reddit, un miroir d'archives en texte intégral et la recherche Google — avant l'enrichissement par commentaires et le reclassement selon la capacité à répondre. Une panne du module ne supprime pas les réponses d'experts déjà obtenues.
Écosystème d'agents
Panex expose les ensembles de sources, les synthèses d'experts et l'expansion des sources par des appels API et CLI explicites. Des agents IA en lecture seule utilisent cette interface depuis des projets Codex et Claude. La Knowledge Matrix compare la couverture des experts avant leur intégration, et Expert Lens applique un seul corpus à une analyse de projet limitée. Le sous-système Reddit est exposé séparément via un endpoint authentifié avec des jetons révocables propres à chaque utilisateur : une CLI portable et un skill d'agent l'encapsulent pour les agents IA, et un paquet client partageable le distribue à des tiers de confiance en dehors du panneau.
Production et opérations sur les corpus
La production tourne dans des conteneurs Docker sur une VM Oracle derrière Caddy. Chaque push vers main déclenche le déploiement via GitHub Actions et se termine par un health check. Les mises à jour de corpus synchronisent le nouveau contenu, construisent les index et les embeddings, valident une base SQLite intermédiaire, créent une sauvegarde et permettent un retour arrière.
Garder les corpus d'experts séparés me permet de comparer les positions sans perdre qui a dit quoi. Je peux ouvrir la source avant d'appliquer une réponse à un projet réel.
NEXX est une plateforme d'approvisionnement B2B qui réunit l'ensemble du parcours acheteur-fournisseur en un seul endroit : découvrir des fournisseurs, établir une relation, commander et assurer le suivi. Chaque entreprise travaille dans son propre espace et peut agir comme acheteur, comme fournisseur, ou les deux.
Le problème concret était la fragmentation entre outils et transferts manuels. NEXX maintient le processus dans un flux unique, cloisonné par entreprise.
Projet clientPremière démo fonctionnelleMulti-tenant dès la conceptionAnglais · letton · russeInterface non publiée
Comment ça marche
Choisir l'entreprise active → trouver des fournisseurs et des articles de catalogue → établir une relation acheteur-fournisseur → constituer le panier → valider la commande → créer des commandes spécifiques par fournisseur.
État actuel
Était-ce terminé ? Non. Le client a vu une première démo fonctionnelle, construite sur le contrat d'API réel, couvrant le catalogue, les relations, le panier, la validation de commande et le suivi des commandes. L'interface était encore provisoire et les écrans client ne sont pas publiés.
Ce que j'ai pris en charge
Au départ, j'ai utilisé Codex pour construire une partie du backend. Quand un développeur backend dédié a pris le relais, je suis passé entièrement au frontend. J'ai construit l'interface Next.js sur le contrat d'API réel et utilisé Codex pour implémenter l'orientation visuelle provisoire élaborée dans Claude Design. C'est cette version qui a été montrée au client.
Décisions de développement
• Multi-tenant et multilingue dès le départ. Le contexte d'entreprise, les rôles acheteur/fournisseur et les trois langues étaient intégrés à l'architecture.
• Des fichiers, pas du chat. Je travaillais dans Codex. Le développeur backend travaillait dans Claude Code. Les deux agents s'appuyaient sur OpenAPI, des fichiers de passation, un client typé généré et des vérifications de contrat.
• Le comportement avant le code. Le travail quotidien suivait le BDD/TDD : définir le comportement, consigner l'échec RED, implémenter le plus petit changement, passer les vérifications GREEN et relire le diff.
• La frontière avec l'ERP restait explicite. NEXX gérait le flux d'approvisionnement. Documents officiels, numérotation, PDF, TVA/comptabilité et écritures d'entrepôt restaient hors de la plateforme.
Développeur backend + Claude CodeBackend · implémentation de l'API
ComportementREDImplémentationGREENRevue
Architecture technique
Le frontend utilisait Next.js, React et TypeScript. La plateforme utilisait Python, Django REST Framework et PostgreSQL. Le navigateur ne l'atteignait que par un proxy Next.js de même origine et par le contrat versionné /api/internal/v1.
Frontière d'exécution
Navigateur → proxy Next.js → plateforme NEXX. La frontière ERP/1C était définie, mais la démo utilisait un mock au lieu d'une intégration finale. Les documents, la comptabilité et les écritures d'entrepôt côté ERP restaient hors de la plateforme.
Modèle multi-tenant et d'approvisionnement
JWT Bearer, X-NEXX-Company-ID et vérifications d'appartenance côté backend assuraient la frontière d'entreprise active. Les rôles acheteur/fournisseur et les relations actives conditionnaient l'approvisionnement. La validation de commande produisait des instantanés spécifiques par fournisseur. Anglais, letton et russe étaient intégrés dès le départ.
Passation par contrat
OpenAPI générait le schéma typé. frontend-handoff.json fixait le commit backend, l'empreinte du schéma, les changements, les actions requises et les limites connues. Les vérifications de contrat détectaient les dérives. Codex et Claude Code travaillaient à partir de ces fichiers au lieu de déduire le comportement de l'API.
Dispositif de vérification
Chaque tâche allait du comportement écrit au RED, puis à la plus petite implémentation, aux vérifications GREEN et à la relecture du diff. L'Architecture Impact Gate passait avant tout changement non trivial. Après le GREEN, une passe séparée simplifiait le diff. Les vérifications couvraient les contrats d'API, Vitest, les tests Playwright et d'accessibilité lancés lors du déploiement, le lint, le typecheck et le build.
NEXX, c'est là que j'ai appris à coordonner le travail frontend et backend avec des agents IA de développement distincts. OpenAPI, les fichiers de passation et la boucle BDD/TDD ont permis de maintenir le frontend et le backend alignés jusqu'à la démo.
Privé · Étude de cas
Oyster Logistics.
Relie les commandes clients aux factures fournisseurs. Signale les écarts à vérifier.
Oyster Logistics est un MVP en langue russe pour un distributeur d'huîtres. Il relie les commandes clients aux demandes fournisseurs et aux factures entrantes, puis signale les écarts de quantité ou d'unité ainsi que les lignes sans correspondance.
Avant le MVP, le processus était éparpillé entre messages, e-mails, documents, tableurs et vérifications manuelles. Je l'ai ramené dans un flux unique construit autour de Google Sheets, Gmail et Telegram.
MVP clientTesté avec des données métier historiques réellesNon utilisé au quotidienEn russe uniquement
Comment ça marche
Formulaire de commande → feuille de travail partagée → brouillons fournisseurs en français à relire → extraction des factures → rapprochement sur quatre champs → exceptions visibles → suivi dans Google Sheets et Telegram.
État actuel
J'ai testé le MVP dans un environnement séparé avec de vraies commandes historiques, des e-mails fournisseurs et des factures, puis je l'ai démontré au client. Le développement s'est arrêté avant un pilote en conditions réelles, car l'étape suivante ne rentrait pas dans le budget disponible. Le client et moi avons testé le formulaire de commande avec des données préparées. Les clients du distributeur ne l'ont pas utilisé.
Ce que j'ai pris en charge
J'ai mené le projet de bout en bout : découverte du processus, conception du flux, décisions produit, architecture, implémentation, tests avec données historiques et démonstration au client. Des agents IA de développement m'ont aidé à écrire le code. Il n'y avait aucun autre développeur sur le projet.
Décisions produit
• Une même ligne conserve les deux côtés. La commande d'origine et la facture fournisseur restent côte à côte. Les écarts restent visibles.
• L'IA extrait. Le code décide. Gemini lit les corps d'e-mails, les PDF et les images. Des règles explicites contrôlent le rapprochement, le statut et les exceptions.
• Les messages aux fournisseurs restent sous contrôle humain. Le système prépare des brouillons Gmail distincts en français, groupés par ferme. Le client les relit et les envoie.
• Victor peut lire, pas agir. L'assistant Telegram répond aux questions opérationnelles et envoie les briefings du matin. Il n'a aucun chemin d'écriture vers la feuille de travail.
Interface
Le formulaire de commande est généré à partir du code du MVP. La feuille opérationnelle et les vues Telegram sont des reconstitutions avec des données synthétiques. Aucun enregistrement client n'est montré.
Vue AIRPLANE synthétique. Les données de la commande d'origine et de la facture fournisseur restent sur une seule ligne.
Le formulaire de commande mobile en fonctionnement, montré avec des données synthétiques.Vue Telegram synthétique du briefing matinal en lecture seule de Victor.
Architecture technique
Le MVP est une application Google Workspace sans serveur. Le formulaire mobile HTML/JavaScript écrit dans Google Sheets via Apps Script. Gmail gère les brouillons fournisseurs et la réception des factures. Drive stocke les documents sources. Le bot Telegram lit les mêmes données opérationnelles mais ne peut pas les modifier.
Enregistrement opérationnel
AIRPLANE est la feuille de travail principale. Elle conserve les données de commande à gauche et les données de facture fournisseur à droite. Les couleurs de statut montrent les demandes non envoyées, les écarts, les lignes non appariées et les factures révisées.
Flux fournisseurs
Le système vérifie le produit, la quantité, l'unité, la date de livraison, la ferme, le destinataire et le transporteur pour chaque ligne sélectionnée. Un dictionnaire maintenu à la main traduit les noms de produits et les unités en français. Apps Script groupe les lignes par ferme et crée des brouillons Gmail séparés à relire.
Pipeline de factures
Un processus Gmail planifié envoie le corps de l'e-mail et chaque pièce jointe PDF ou image à Gemini. Les lignes extraites sont normalisées puis rapprochées des commandes par produit, destinataire, date de livraison et ferme. Les documents sources sont archivés dans Drive.
Opérations Telegram
Un Cloudflare Worker accuse réception des webhooks Telegram avant le traitement Apps Script. Les identifiants des mises à jour déjà traitées sont filtrés. Victor répond aux questions textuelles et vocales à partir des données opérationnelles, peut inspecter les documents joints et envoie un briefing matinal. Il ne peut pas modifier la feuille.
Stack : Google Apps Script · JavaScript · HTML/CSS · Google Sheets · Gmail · Google Drive · Gemini · OpenRouter · Telegram Bot API · Google Cloud TTS · Cloudflare Workers
Ce qui comptait
Je devais comprendre le processus du client avant de décider où l'IA pouvait aider et où elle devait s'arrêter. Gemini traitait les documents désordonnés. Le rapprochement, les modifications et les messages sortants restaient régis par des règles explicites et soumis à une validation humaine.
Public · À tester
Ukido AI Sales Assistant.
Répond aux parents. Transmet les demandes d'essai à HubSpot.
Les parents posent des questions sur les cours, les prix, les enseignants ou un problème que rencontre leur enfant. L'assistant répond en russe, en ukrainien ou en anglais. Il conserve le contexte de la conversation et envoie une demande d'essai à HubSpot quand le parent est prêt.
J'ai commencé par une question technique précise : comment l'assistant peut-il trouver la bonne partie d'une base de connaissances sans tout charger dans chaque prompt ? Puis je suis passé à la conversation elle-même : contexte, intention qui évolue, refus et étapes suivantes sur plusieurs tours.
C'est mon expérience indépendante. Ukido ne l'a ni commandée ni validée. J'ai utilisé l'école comme cadre. Les cours, les prix, la base de connaissances et les scénarios de dialogue sont synthétiques.
Un parent pose une question → l'assistant répond à partir des connaissances sélectionnées → conserve le contexte au fil des échanges → cesse de relancer après un refus ou envoie une demande d'essai à HubSpot quand le parent est prêt.
État actuel
Une démo publique fonctionnelle. J'ai testé les parcours principaux par des scénarios de dialogue multi-étapes. Elle n'a pas été utilisée par une équipe de vente en conditions réelles. Je ne présente donc aucun taux de conversion ni résultat commercial.
Ce que j'ai pris en charge
J'ai construit tout le projet de A à Z : idée produit, entreprise synthétique, base de connaissances, logique de dialogue, backend, interface web, intégration HubSpot, scénarios de test et déploiement. Des agents IA de développement m'ont aidé à écrire le code. Je décidais ce que le système devait faire et vérifiais ce qu'il faisait réellement.
Décisions produit
• Seules les connaissances pertinentes entrent dans le prompt. Le module Router sélectionne jusqu'à quatre documents. Le Generator ne reçoit que ce contenu.
• La conversation peut changer de direction. Le système suit l'exploration, l'anxiété, la sensibilité au prix et la disposition à s'inscrire. Il utilise ces signaux pour ajuster le ton et l'étape suivante.
• Pas de relances commerciales répétitives. Le système suit les refus, les actions terminées et les limites de CTA pour éviter de répéter la même offre.
• Un seul flux fonctionne en trois langues. Russe, ukrainien et anglais partagent les mêmes connaissances et la même logique de vente.
Interface
Conversations capturées depuis la démo publique. Tous les cours, prix et données d'école montrés sont synthétiques.
Russe : un enfant timide.Ukrainien : prix et format des leçons.Anglais : orientation de cours.Russe : l'assistant cesse de relancer après un refus.
Architecture technique
La démo tourne comme un service Python/FastAPI sur un VPS Ubuntu partagé chez Beyond Horizon. Gemini 2.5 Flash assure les deux étapes IA via OpenRouter. Le Router classifie le message et sélectionne les connaissances. Le Generator rédige la réponse. FastAPI la diffuse au navigateur par SSE. L'orchestration reste en Python pur, sans LangChain ni framework d'agents.
Connaissances et routage
Quatorze documents Markdown décrivent l'école synthétique, les cours, les prix, les enseignants, les méthodes, les règles de sécurité et les conditions. Des résumés JSON aident le Router à sélectionner jusqu'à quatre documents pour chaque réponse.
Comportement de conversation
Le système conserve les dix derniers messages et suit quatre indicateurs liés au parent, l'état du dialogue, les refus, les actions terminées et l'usage des CTA. Des quotas par utilisateur et un historique limité permettent de maîtriser chaque dialogue.
Tests de dialogue
Des scénarios multi-étapes modélisent différents parents et des changements au sein d'une même conversation. Les rapports suivent les transitions de signaux, le contexte, le ton, le comportement des CTA, les refus et les régressions entre tours.
Livraison et intégration
Les demandes d'essai créent ou mettent à jour des contacts HubSpot. Pydantic valide les données. Restrictions CORS, limites par utilisateur, routes admin protégées, health checks Docker, Pytest et Playwright couvrent le chemin de l'API au navigateur.
Une seule bonne réponse ne m'apprenait presque rien. J'avais besoin de voir le dialogue entier : ce dont l'assistant se souvenait, comment il réagissait quand le parent changeait de direction, quand il proposait un essai et s'il s'arrêtait après un refus. Les scénarios multi-étapes ont rendu ces vérifications reproductibles.
Posez une question. Trouvez une pensée issue d'une collection familiale.
Papa's Phrasebook est une archive familiale en langue russe. Vous décrivez une situation ou posez une question. Le service retrouve une ou deux pensées correspondantes dans une collection commencée avec 99 pensées que mon père avait lui-même réunies.
Je l'ai d'abord construit pour ma famille, puis ouvert à tous. Il est déjà utilisé par mon père, des proches et des amis. Je ne mesure pas le nombre d'utilisations.
Mon projet indépendantPublic et fonctionnelEn russe uniquement
Choisissez la collection complète ou un auteur → posez la question avec vos mots → recevez une ou deux entrées exactes de cette source. La collection complète peut aussi être parcourue par thème.
État actuel
La recherche en ligne couvre 3 774 entrées. La collection principale en contient 2 497, dont 2 398 ajouts que j'ai relus en les comparant aux 99 entrées d'origine. Les collections séparées de Khayyam, Rumi, Jvanetski, Guberman et La Rochefoucauld sont fusionnées et dédoublonnées à l'exécution.
Ce que j'ai pris en charge
J'ai construit le projet de A à Z. J'ai défini le produit, élargi et relu la collection, conçu la recherche et les règles de sources, construit l'interface et le backend, testé le résultat et déployé sur Fly.io. Des agents IA de développement m'ont aidé à écrire le code. J'ai conservé la responsabilité des décisions.
Décisions produit
• Le modèle n'écrit pas la sagesse. Gemini sélectionne des identifiants. Le backend les vérifie et renvoie le texte exact stocké.
• La collection d'origine donne le ton. Mon père a réuni les 99 premières entrées. Je ne présente pas les ajouts ultérieurs comme ses propres mots.
• Un auteur peut rester silencieux. Une collection personnelle n'est utilisée que pour une correspondance directe à haute confiance. Sinon, le système le dit et interroge la collection complète.
• Le coût a une limite stricte. Le service a un budget Vertex AI quotidien et tourne sur une seule machine Fly.io avec démarrage automatique.
Interface
Le produit public est en russe. Les captures d'écran proviennent de l'interface fonctionnelle et utilisent les collections réellement stockées. Aucune donnée d'exemple générée n'a été ajoutée pour le portfolio.
La collection complète avec 3 774 entrées et des filtres par thème.Une question traitée depuis la collection d'un auteur choisi.Écran de question sur mobile.Deux entrées exactes renvoyées sur mobile.Une étagère d'auteur sur mobile.
Architecture technique
Le backend utilise Python et FastAPI. Le frontend est en HTML, CSS et JavaScript simples. Gemini passe par Vertex AI et l'application est déployée sur Fly.io.
Corpus et provenance
La base physique contient 2 497 entrées : 99 de la collection de mon père et 2 398 ajouts relus. À l'exécution, la base et cinq collections d'auteurs sont fusionnées et dédoublonnées en 3 774 entrées. Les textes et la provenance restent dans des fichiers JSONL inspectables.
Recherche et sélection
Pour la collection complète, Gemini 2.5 Flash Lite aiguille chaque question vers un ou deux des 15 thèmes. Gemini 3 Flash sélectionne ensuite les identifiants dans ce sous-ensemble restreint. Le backend rejette les identifiants qui n'ont pas été fournis au modèle et insère le texte exact de la source.
Collections d'auteurs
Chaque auteur dispose d'un corpus distinct, conservé dans son texte exact. Les nouvelles collections d'auteurs sont préparées sur un VPS privé à l'aide de Harvester, mon processus de recherche, et d'agents Codex affectés à des étapes distinctes. Recherche, relecture des sources, curation, dédoublonnage et approbation humaine restent des étapes séparées.
Évaluation et opérations
L'ancien parcours de recherche sur l'ensemble du corpus a retrouvé le groupe thématique attendu dans 79 cas sur 80. Le parcours fondé sur le routage thématique a atteint 80 sur 80 et utilisé environ 81 % de jetons en moins dans la même évaluation. Le service limite aussi la mémoire, évite les répétitions récentes, suit les versions du corpus et plafonne les dépenses quotidiennes.
Je voulais tester la technologie sérieusement et offrir aux gens quelque chose d'utile et d'agréable. La partie difficile a été de savoir quand ajouter les embeddings et le FTS. Le parcours actuel fondé sur le routage thématique a retrouvé le groupe thématique attendu dans 80 cas sur 80 et utilisé environ 81 % de jetons en moins que l'ancien parcours. Pour l'instant, cela suffit. Les embeddings et le FTS peuvent attendre.
