Trois CLI de code, un workflow – mais l’axe de routage, ce sont les modèles, pas les outils. Comment je choisis d’abord le modèle – Claude Opus 5 vs. Sonnet 5, Gemini 3.1 Pro et ses 2M de contexte, Gemini 3 Flash pour la vision, le DeepSeek-V4-Pro ouvert, un Qwen3-32B local (IQ3_M) – puis le bon harnais. Avec configuration shell et un petit script de routage.
Le context engineering en pratique : comment des métadonnées de frontmatter structurées issues des content collections Astro deviennent une source de contexte précise et budgétée pour un LLM – avec des exemples TypeScript plutôt qu'une recherche plein texte naïve.
Comment savoir si IQ3_M est encore assez bon ? Mesurer la perte de qualité d'une quantisation – avec llama-perplexity, la divergence KL par rapport au modèle de base et une petite éval de tâches maison.
Comment j'ai quantisé Qwen3-32B avec llama.cpp et une matrice d'importance pour le faire tourner sur un GPU de 16 Go : conversion GGUF, imatrix, niveaux de quantisation comparés, budget VRAM et offload de couches.
La recherche vectorielle est le défaut du RAG – mais pour mon wiki personnel, un retrieval structuré sur métadonnées et texte intégral était le meilleur choix. Là où les embeddings échouent, avec des exemples SQL et de prompts.
Un système maison avec une vraie profondeur technique : event sourcing, cache de graphe, LLM locaux et un modèle d’agents inspiré des aires cérébrales – entièrement hors cloud.
De la recherche à l’article publié en environ 7 minutes : un pipeline à deux modèles – Gemini 3 Pro rédige, Nano Banana illustre – avec un système de blog génératif et un frontend piloté par les données.
Le context engineering comme concept : un wiki personnel et évolutif comme source de contexte locale pour les requêtes LLM – structuré plutôt qu’une recherche vectorielle naïve.
Une méthode du machine learning et du traitement automatique du langage naturel (NLP) qui vise à amener les modèles à expliquer leurs étapes et leur raisonnement lorsqu’ils parviennent à une solution.
#react
