Remplacer les pipelines de récupération complexes par des commandes git simples pour les agents IA

D'un pipeline complexe à des commandes git simples

Un développeur créant DiffMem, un système de mémoire basé sur git pour les agents IA, a découvert que sa couche de récupération était inutilement complexe. Il utilisait sentence-transformers pour le calcul de similarité cosinus, rank-bm25 pour la recherche par mots-clés, un pipeline LLM en deux passes pour affiner les requêtes et synthétiser les résultats, ainsi que scikit-learn et numpy comme dépendances. Cela a abouti à une image Docker de 3 Go (sentence-transformers entraînant tout PyTorch), des délais d'attente pour les utilisateurs intensifs environ 10 % du temps, et un démarrage à froid qui reconstruisait un index BM25 en mémoire à chaque fois.

La prise de conscience : les LLM connaissent déjà git

L'idée clé est venue de la reconnaissance que les commandes Unix sont le modèle d'utilisation d'outils le plus dense dans les données d'entraînement de tout LLM. Des milliards de fichiers README, de scripts CI et de réponses Stack Overflow sont remplis de commandes grep, git log et cat. Le LLM n'a pas besoin d'un pipeline de récupération personnalisé construit autour de lui—il parle déjà le langage des commandes shell.

La solution à un seul outil

Ils ont remplacé tout le système complexe par un seul outil :

{
  "name": "run",
  "description": "Exécute une commande en lecture seule dans le référentiel de mémoire",
  "parameters": {
    "command": "Commande shell (prend en charge l'enchaînement avec |, &&, ||, ;)"
  }
}

C'est tout. Une seule fonction. L'agent écrit des commandes shell, connaissant déjà grep, git diff, head et d'autres utilitaires Unix sans avoir besoin d'être formé.

Comment fonctionne l'agent

L'agent suit un protocole fixe à travers ses tours :

• Lire le manifeste de l'entité
• Exécuter une sonde temporelle contre le journal des commits
• Regrouper son investigation en un seul appel d'outil
• Produire un plan de récupération
• S'arrêter

L'agent retourne des pointeurs, pas du contenu. Il lit des signaux légers pendant ses tours (head -30 pour la structure, grep -n pour les mots-clés, git diff HEAD~3.. pour les changements récents), puis indique au code quoi récupérer. Le code résout les pointeurs, gardant le contexte de l'agent léger.

Exemple concret

Lorsqu'un utilisateur a envoyé un message d'anniversaire sur le sentiment d'isolement avec la pression du travail, l'agent a exécuté :

git log --format='%h %ad' --date=relative --name-only -15

Cela a révélé que wife.md et company.md ont été modifiés dans la même session, et qu'un collègue clé est apparu dans 2 des 3 dernières sessions. Le message de l'utilisateur ne disait rien sur le travail—BM25 n'aurait jamais trouvé company.md, et la similarité sémantique sur "se sentir isolé pour mon anniversaire" n'y serait pas parvenue non plus. Mais la co-occurrence dans l'historique des commits a révélé la connexion qui comptait réellement.

Au tour 3, l'agent a composé un appel d'outil avec neuf commandes enchaînées par des points-virgules :

git diff HEAD~2.. -- memories/people/wife.md; git log --stat -5 -- memories/people/wife.md; head -30 memories/people/wife.md; grep -n "birthday|surgery|stress" memories/people/wife.md; tail -50 timeline/2026-03.md; git diff HEAD~3.. -- timeline/2026-03.md; grep -n "project|deliverable" memories/contexts/company.md; git diff HEAD~2.. -- memories/contexts/company.md; git diff HEAD~1.. -- memories/people/colleague.md

Le résultat final était un plan de récupération JSON avec des diffs git spécifiques, des niveaux de priorité et des estimations de tokens—pas du contenu, mais des pointeurs. Le code a ensuite exécuté les commandes et assemblé le contexte selon le budget de tokens.

Résultats

Cette approche leur a permis de supprimer rank-bm25, sentence-transformers, scikit-learn et numpy. L'image Docker a été réduite d'environ 3 Go. Le serveur démarre plus vite, utilise une fraction de la mémoire et n'a plus d'index BM25 au démarrage à froid. Le taux de délai d'attente de 10 % a disparu. Sur Cloud Run avec une charge réelle d'utilisateurs, ce n'était pas une amélioration marginale mais une classe de déploiement différente.

Ce qui reste : requests, openai, gitpython.