 |
||
| ||
| |||||
| Dernière réponse | ||
|---|---|---|
| Sujet : Communauté de l'IA | ||
| joce |
|
|
| Aperçu |
|---|
| Vue Rapide de la discussion |
|---|
| joce |
|
| Nr13 |
|
| memaster | j'ai installé un autre assistant ollama/phi3 sur une autre machine pour comparer.
c'étrange, mais les 2 assistants n'ont pas le même comportement. il y en a un : mon premier est très coopératif dans ce que je lui demande, du genre des infos sur le sys et des commandes à tapper pour résoudre tel ou tel pb. notamment sur openclaw... le 2nd : le plus jeune essaye de me vendre des tokens de cloud alors que je lui dis qu'il tourne en local. il arrete pas de me repeter que c'est microsoft à distance qui gère ses réponses... hallucinant :pt1cable: |
| joce |
|
| XaTriX | abusé les artefacts claude
https://forumhfr.github.io/artifact [...] d-spacing/ |
| XaTriX | ce lobbying :o |
| joce |
|
| XaTriX | url headroom ? |
| bulldozer_fusion | headroom + caveman c'est vraiment le top RTK beaucoup moins même si ça aide un petit peu mais c'est bien plus limité |
| joce | Pour le gain de headroom on est largement au delà des 3.7% (je suis plus autour de 37% pour le coup). RTK je suis plus dubitatif parce qu'effectivement souvent les agents voient que l'output est tronqué et passe par un Read non tronqué, donc au final tu consommes plus. |
| jix | Ce que dit l'article
Attention au titre : l'article n'est pas une promo de RTK, c'est une enquête critique. L'auteur teste trois outils open-source (rtk, headroom, caveman) qui promettent de réduire la consommation de tokens LLM de 60-90 %… et démontre que dans la vraie vie le gain combiné est d'environ 3,7 % (et 0,5 % pour RTK seul). RTK, c'est quoi Un wrapper en ligne de commande qui intercepte les commandes shell avant exécution et compacte leur sortie avant que le modèle ne la lise. - Fonctionne via un hook PreToolUse : git status devient rtk git status. - Filtres spécialisés par type de commande (grep, git diff, git log, ls…) : déduplication, troncature, résumés. - Exemple ls -la : 37 lignes avec permissions/propriétaire/dates → arbre compact + ligne "Summary: 23 files, 10 dirs (13 .md, 2 .json…)". - Garde-fous : si le parsing échoue → sortie brute ; les diffs tronqués gardent un marqueur [full diff: rtk git diff --no-compact]. Promesses vs réalité Promesse (microbench) Réel (replay de vraies sessions) grep 99 % (ex. rg registerSingleton sur VS Code : 694k → 2,4k tokens) — git diff 33-99 % — Part réelle de la facture. 60-90 % 0,5 % Pourquoi l'écart est énorme : 1 - Problème de dénominateur : la promesse divise par une seule commande ; la facture réelle se divise sur des centaines de tours. 2 - 78 % des tokens d'outils contournent RTK : ils passent par les outils natifs Read/Grep/Glob/WebFetch de Claude Code, qui n'appellent jamais le hook shell. 3 - Structure de prix : l'essentiel de la facture (42 % cache_create, 29 % output) ne touche jamais le flux de RTK ; les gains tombent sur les tokens les moins chers (cache_read, ~0,50 $/M contre 5-25 $/M). 4 - Les lectures de fichiers contiennent peu de redondance → les stratégies de dédup de RTK n'y mordent pas. Risques - Sécurité : le hook s'exécute sur le shell → une release compromise = exécution de commandes arbitraires, potentiellement invisible (headroom télécharge le binaire RTK automatiquement → exposition supply-chain). - Perte de données silencieuse : la troncature peut couper un warning critique que l'agent avait demandé. Conclusion de l'auteur : gains réels marginaux (~0,5 %) à mettre en balance avec le fait de donner à un binaire tiers un accès direct à ton shell. Pour la plupart des gens, le risque l'emporte sur le bénéfice. Est-ce intéressant pour toi ? Honnêtement, non — pas l'outil. Et c'est encore plus net dans ton cas que dans le cas générique de l'article : - Tu utilises massivement les outils natifs (Read, Grep, Glob, les agents Explore/audits). Or c'est précisément ce flux (les 78 %) que RTK ne touche pas. Le gain serait encore plus proche de zéro que la moyenne. - Sécurité : tu bosses sur une app en prod avec des PII réelles (cf. tes mémos sur les audits-secrets/PII). Greffer un binaire à hook shell téléchargé automatiquement, c'est exactement le type de dette que tes propres garde-fous (audit-secrets, audit-3rd-party, supply-chain) sont censés éviter. Mauvais ratio. - Tu as déjà 35+ hooks PreToolUse très réglés. Ajouter un wrapper qui ré-écrit tes commandes shell crée un risque de collision/effets de bord avec ton tooling existant, pour un gain de ~0,5 %. Ce qui est récupérable, en revanche, c'est l'idée — pas le produit : - Préférer des grep/rg ciblés (avec -l, -c, head) plutôt que des dumps massifs — tu le fais déjà via tes agents Explore qui lisent des extraits. - Éviter de faire avaler à l'agent des sorties verbeuses inutiles. Le vrai enseignement de l'article pour toi est plutôt méthodologique : se méfier des promesses « -90 % de tokens » qui comparent une seule commande au lieu de la facture réelle. Le levier qui compte vraiment sur ta facture, c'est le cache (cache_create/cache_read) et l'output, pas la compaction de sorties shell. |
| XaTriX | Je n'ai pas vraiment confiance en des outils comme rtk ou caveman, je pense que le gain est nul, léger, voir négatif et que ça rajoute des contraintes et de l'incertitude sur les réponses des outils.
Il vaut mieux utiliser des outils plus performant que les verbeux classiques et savoir manager son contexte. |
| Nr13 |
|
| memaster |
|
| memaster | et bien ça yeah je cause avec mon ollama en local. [:e-te] ce truc de fou :love: |
| bulldozer_fusion |
|
| memaster | drap :o |
| jix | J'aimerais bien trouver un chatbot pour le faire le support de mon site, qu'on puisse adapter facilement à son propre contenu, vous pensez que ça existe en public sur github ?
Edit : bon, un peu tôt pour ça, on verra quand mon projet sera plus avancé, Glaude m'a gentiment dit qu'il ne fallait pas mettre l'huile avant le tournesol :o |
| jix | ajoute un bouton "offre moi une bière" dans le github :o |
| Bagdarion |
J'utilise CAVEMAN au quotidien mais honnêtement je n'ai pas de mesures pour vérifier si j'y gagne réellement. J'ai testé graphify et pour le coup je n'ai pas remarqué de gain, plutôt l'inverse même puisqu'il fallait régulièrement build/mettre à jour le graph |
| XaTriX | oui ? :o |
