Travaux

Systèmes, expériences et preuves

Une sélection de travaux publics avec des sources vérifiables, des affirmations circonscrites et des limites explicites. Chaque cas présente le problème, la limite du système, ce que j’ai construit, comment cela a été évalué et où s’arrêtent les preuves.

• Engineering the Agentic Stack

  Problème : La fiabilité des agents est souvent traitée comme un problème de choix du modèle, même lorsque les défaillances concernent le raisonnement, la mémoire, les outils, les permissions, le runtime et le contrôle des mises en production.

  Contribution : J’ai développé une architecture de production en six parties et l’implémentation de référence Market Analyst Agent qui relie ces couches.

  Preuves : Lire la série · Consulter le code source

  Décision : Traiter le harness et ses contrôles indépendants comme une partie du produit, puis faire en sorte que chaque contrôle ajouté justifie son coût par une ablation.

  Limite : Il s’agit d’un système de référence et d’une méthode d’ingénierie, et non d’un benchmark de production publié.

• Des traces aux suites de tests

  Problème : L’évaluation de la seule réponse finale ne détecte pas les outils ignorés, les arguments dangereux, les boucles et les déclarations prématurées de réussite.

  Contribution : J’ai décrit une méthode permettant de transformer les traces en régressions pour les agents en production et construit un harness exécutable d’évaluation RAG couvrant le retrieval, les filtres, le reranking, la génération, les juges et la latence.

  Preuves : Lire la méthode d’évaluation des agents · Exécuter l’évaluateur RAG

  Décision : Versionner les traces d’échec comme cas de test et combiner des contrôles déterministes de trajectoire avec des juges calibrés uniquement lorsqu’une interprétation est nécessaire.

  Limite : L’évaluateur public utilise SciFact et des exemples circonscrits ; ses résultats ne sont pas automatiquement transférables à un autre corpus ou modèle.

• TypeScript Agent Service

  Problème : Les ingénieurs ML Python doivent pouvoir livrer et examiner des services d’agents TypeScript proches de la production sans réapprendre l’ingénierie backend depuis zéro.

  Contribution : J’ai construit un monorepo pnpm avec une API Hono en streaming, une boucle d’outils validée, un stockage Drizzle, un worker, un serveur MCP, de l’observabilité et 40 tests.

  Preuves : Lire le guide d’implémentation · Consulter le code source

  Décision : Faire correspondre les limites familières des services — Pydantic, FastAPI, files d’attente, stockage — à leurs équivalents TypeScript tout en maintenant des schémas stricts à chaque limite d’outil.

  Limite : Il s’agit d’un service de référence local, et non d’un produit hébergé ou d’une affirmation concernant le système d’un employeur précis.

• Stack de classement de recherche

  Problème : Les stacks de retrieval masquent souvent quelle étape améliore la pertinence et laquelle ne fait qu’ajouter des coûts.

  Contribution : J’ai construit une démonstration en cinq étapes couvrant BM25, le retrieval dense, la fusion Reciprocal Rank, le reranking par cross-encoder et le classement listwise par LLM sur un échantillon des données Amazon ESCI.

  Preuves : Lire l’analyse par étapes · Exécuter le code source

  Décision : Mesurer chaque étape indépendamment et ne la conserver que lorsque le gain de pertinence justifie la latence et le coût d’exploitation.

  Limite : Le corpus est un échantillon et l’article signale la ligne LLM obsolète comme non probante.

Consultez directement les preuves : exécutez un lab ou parcourez le Blog par systèmes d’agents, retrieval et langage, ou ingénierie des modèles.