Trois mois plus tard : je code toujours, j'apprends toujours, je suis toujours bloqué (parfois)

Mise à jour (2026) : Le projet de chatbot financier S&P 500 a finalement été abandonné. Sydney est de retour et se concentre maintenant sur le contenu du blog et les produits. Essaie Sydney →

---

Je me demandais si je devais même écrire cette mise à jour sur mon parcours de codage. Les progrès n'ont pas été spectaculaires ni visibles de l'extérieur — alors pourquoi se donner la peine ?

Eh bien, peut-être que ce post servira de bon rappel pour mon futur moi que les progrès peuvent ralentir parfois et que la croissance se produit souvent par à-coups.

Depuis mon dernier post sur la construction d'un chatbot auto-évaluant à la mi-avril, je me suis plongé dans quelques cours :

• React Basics par Meta sur Coursera
• React Advanced par Meta sur Coursera
• Framework web Django
• Le Full Stack

Pourquoi ces cours ?

Je veux partager mes expériences personnelles et le processus de réflexion derrière le choix de ces cours. Mon espoir est que cela puisse aider ceux d'entre vous qui sont (ou seront) dans un parcours similaire.

Devenir meilleur pour instruire la machine

Cela fait environ 10 mois que je me suis lancé dans le codage, tout en ayant un emploi à temps plein. (Tu peux en lire plus sur Comment j'ai construit mon propre chatbot sans expérience en codage : leçons apprises publié en octobre 2023 ici.)

Je ne pourrais définitivement PAS y arriver sans l'aide de l'IA générative (qu'il s'agisse de chatGPT, d'Anthropic Claude ou de Microsoft CoPilot dans Visual Studio Code.) Cependant, plus je code, plus je réalise que bien que ces modèles fondamentaux soient puissants, ils ressemblent encore à des stagiaires. Ils ne sont pas encore bons pour planifier ou résoudre des tâches ambiguës. Plus nos instructions sont spécifiques, meilleure est la sortie.

Cela signifie que je dois devenir de plus en plus précis dans mes instructions de codage. Mais comment ? Jusqu'à présent, je décrivais ce que je veux en langage naturel. Bien que cela fonctionne à un niveau basique, c'est insuffisant pour des tâches plus complexes.

Puis la prochaine question logique est quoi apprendre ?

Se concentrer sur les problèmes métier/utilisateur que j'essaie de résoudre

Mon chatbot (nom de code Sydney) pour ce site était (peut-être "est") lent. La lenteur se produit à la fois dans :

• Le temps de démarrage
• Et pendant la conversation

Le streaming n'est pas activé, donc les utilisateurs doivent attendre un temps relativement long pour voir la réponse complète.

Donc mon objectif était (est) simple : le rendre rapide et réactif.

Mon objectif est simple : le rendre rapide et réactif. Mais sans plus de connaissances fondamentales, il est difficile de décomposer cela en problèmes gérables à résoudre. C'est pourquoi j'ai décidé d'en apprendre davantage sur les frameworks frontend évolutifs, sécurisés et rapides, les frameworks backend et le full stack (y compris les bases de données).

Mes expériences avec React et Django jusqu'à présent

• React : React est relativement plus facile à apprendre et à déployer par rapport à Django. (Bien sûr !) Le frontend du chatbot actuel utilise React, et j'ai trouvé que Claude et ChatGPT peuvent gérer la plupart des tâches de codage sans problèmes. Le déploiement dans un environnement de production avec React était aussi assez simple, et la page du chatbot semble plus réactive pendant les conversations.
• Django : Django et Django Rest Framework (DRF) avaient une courbe d'apprentissage plus raide, notamment avec le déploiement impliquant une base de données Cloud SQL et la garantie de la sécurité. La nature complète de Django signifie que le déploiement avec le niveau de sécurité approprié a pris du temps. Cependant, je n'arrive toujours PAS à faire fonctionner les réponses HTML en streaming avec DRF dans un environnement de production ! Bien que je puisse le faire fonctionner en utilisant WebSockets, cette approche s'écarte significativement de DRF, donc je ne l'ai pas encore adoptée.

Donc si tu connais un framework ou une réponse sur comment faire fonctionner le streaming Langgraph avec un frontend simple, fais-le moi savoir !

Qu'en est-il du chatbot financier que j'ai mentionné en avril ?

La bonne nouvelle est que ce projet a suscité l'intérêt de beaucoup d'entre vous — j'ai reçu de nombreuses questions et commentaires. La mauvaise nouvelle ? Je suis loin de le compléter T.T Voici pourquoi :

1. Équilibrer la qualité de récupération, le coût mensuel du magasin vectoriel et le coût d'embedding

Comme mentionné dans le post d'avril, j'évalue le Weaviate Serverless Cloud Vector Store. Ça coûte de l'argent réel cependant. Pour ce projet, je regarde probablement :

• Volume de données : Plus de 10 millions, peut-être 12,5 - 15 millions d'objets de données.
• Estimation des coûts : Avec une dimension vectorielle de 512, le coût mensuel pourrait varier de 600 à 750 $.

Ce montant est gérable pour une entreprise dans un environnement de production, mais pourrait être trop élevé pour un projet parallèle comme celui-ci. J'ai donc besoin de trouver des moyens de réduire les coûts.

Selon le fonctionnement de la tarification de Weaviate, les deux leviers sont : réduire le nombre d'objets de données ou réduire la dimension vectorielle. Ces deux approches impliquent différents compromis.

Façons de réduire les objets de données

• Nettoyage agressif du texte : Réduire la taille globale du texte dans les déclarations 10K et 10Q pourrait aider, étant donné qu'on traite 500 entreprises du S&P 500, chacune avec plusieurs déclarations au cours des 10 dernières années. Je pense avoir épuisé cette option.
• Augmentation de la taille des chunks : En augmentant la taille des chunks de 256, à 512, à 1 000, à 2 000 ou 3 000, je peux réduire le nombre d'objets de données de 2x, 4x ou 10x. Cependant, cela peut réduire la qualité de récupération, car les chunks plus grands ont tendance à être moins précis.

Façons de réduire la dimension vectorielle

Réduire la dimension vectorielle semble directement corrélé à la qualité de récupération — plus la dimension est faible, plus la qualité de récupération est mauvaise. J'expérimente encore avec différents modèles d'embedding comme "text-embedding-3-small" et "text-embedding-3-large" d'OpenAI avec différentes dimensions. Si tu as de bonnes recommandations, partage-les !

Utiliser le modèle "text-embedding-3-large" d'OpenAI ajoute également au coût pendant la phase d'embedding. Par exemple, cela m'a coûté 4,5 $ pour générer des embeddings pour les déclarations 10K/10Q de 23 entreprises sur les 10 dernières années avec une dimension vectorielle de 1024. Cela signifie qu'il pourrait coûter plus de 100 $ pour l'ensemble du S&P 500. (Oui, je suis un peu radin. Tu ne le savais pas avant :P ?)

2. Latence pendant la traduction de requêtes, la structuration, la récupération

Plus la traduction et la structuration des requêtes sont élaborées, meilleurs sont les termes de recherche/termes de recherche de contenu que nous pouvons générer, conduisant à une récupération de meilleure qualité. Cependant, cela augmente également la latence.

• La traduction de requêtes est l'étape où nous demandons au modèle de traduire la question initiale de l'utilisateur en sous-questions qui sont meilleures pour la récupération. Par exemple, avec la question originale "Comment la marge opérationnelle d'Airbnb a-t-elle changé de 2020 à 2022 ?", le modèle peut générer des sous-questions comme :

[
"What was Airbnb's operating margin in the 10-K filing for the year 2020?",
"What was Airbnb's operating margin in the 10-K filing for the year 2021?",
"What was Airbnb's operating margin in the 10-K filing for the year 2022?"
]

• La structuration de requêtes est l'étape où nous demandons au modèle de transformer ces questions en requête de recherche ou en requête de recherche de contenu pour la récupération, avec les filtres pertinents. En utilisant l'exemple ci-dessus, pour la question 1, le modèle peut retourner :

\{
    "content_search": "What was Airbnb's operating margin in the 10-K filing for the year 2021?",
    "company_conformed_name": "Airbnb, Inc.",
    "form_type": "10-K",
    "conformed_period_of_report": "2021-12-31"
\}

Pour la récupération, plus on retourne de résultats, plus il faut de temps au modèle pour les traiter. Retourner moins de résultats signifie des temps de réponse plus rapides mais potentiellement des réponses de moindre qualité en raison d'un manque de contexte.

Pour conclure

Il y a plus sur quoi je travaille, mais comme ce post est déjà plus long que prévu, je vais m'arrêter ici.

Apprends-tu aussi à coder tout en travaillant à temps plein ? Comment décides-tu quoi apprendre ensuite quand tout semble également important ?

Cordialement,

Chandler