El retrieval de herramientas de agente falla en silencio cuando el usuario parafrasea
Un experimento con BM25 sobre 100 herramientas sinteticas mide el recall del shortlist que genera la carga diferida: 97% si el usuario usa el vocabulario de la descripcion, 5% si lo reformula.
Cargar herramientas a demanda suena a ahorro de contexto hasta que el shortlist no trae la herramienta correcta. Un eval reproducible sobre cien herramientas sinteticas encuentra que el recall@5 llega al 97% cuando el usuario emplea el vocabulario de la descripcion y se hunde al 5% cuando lo parafrasea. La correccion que propone cuesta 13,4 tokens por herramienta.
El diseno del experimento salio de un lector, que planteo la seleccion de herramientas como un sistema de dos fases: primero el recall, si la herramienta correcta entra en el shortlist que produce la recuperacion; despues la seleccion, si el modelo la elige de ahi. Su observacion es la que ordena todo lo demas: un contexto barato con la herramienta correcta ausente es el peor resultado posible, porque falla en silencio. El modelo no da error, improvisa con lo que tiene.
El banco de pruebas usa cien herramientas empresariales sinteticas (search_invoice, approve_claim y similares) en tres niveles de descripcion: telegrafica, realista y verbosa. La recuperacion es BM25 sobre la definicion serializada de cada herramienta, con shortlist de cinco. Las doscientas tareas van por pares, una por herramienta: unas repiten el vocabulario del dominio y otras dicen lo mismo como lo diria alguien que no ha leido nunca la documentacion de la API. Mismo intento, mismo identificador, ni una palabra de contenido en comun.
| Descripciones | Vocabulario | Parafrasis |
|---|---|---|
| Telegrafica | 100% | 5% |
| Realista | 97% | 5% |
| Verbosa | 97% | 4% |
El primer resultado es comodo: cuando el usuario habla el idioma de la herramienta, la recuperacion esta practicamente resuelta. El segundo no lo es. Al parafrasear, el recall se derrumba, y la capa verbosa no aporta nada: cuesta 208 tokens por herramienta, casi el doble que la realista, y su recall es estadisticamente identico. Son las mismas palabras repetidas. Mas prosa no es mas superficie de recuperacion si sigue tirando del mismo vocabulario.
Alargar el shortlist no arregla nada
El reflejo obvio es ensanchar la lista. El barrido de tamanos, con el contador de tokens del mismo autor, da esto: shortlist de tres, unos 362 tokens por llamada y 3% de recall en parafrasis; de cinco, unos 542 tokens y 5%; de diez, 1.040 tokens y 10%. Duplicar el precio sube el recall del cinco al diez por ciento. Extrapolando, vuelves a mandar las cien herramientas, que es justo la situacion que la carga diferida existia para evitar.
Trece tokens de vocabulario ajeno
Si el recall es cobertura de vocabulario, se anade vocabulario. El autor pega una frase de sinonimos al final de cada descripcion realista, del tipo "Users may also say 'sign off on' or 'damage report'", y repite la medida: 100% de recall en parafrasis con 124 tokens por herramienta. Trece tokens de las palabras correctas baten a noventa y siete de ceremonia. La regla de presupuesto queda clara: los tokens de descripcion van a desambiguacion y al vocabulario del propio usuario.
Dos salvedades que el autor pone sobre la mesa. La primera: sus frases de alias contienen los mismos sinonimos que usan las tareas de parafrasis, asi que ese 100% es el caso techo y demuestra el mecanismo, no una garantia en produccion. Ahi los alias salen de la telemetria de confusiones, de cada recuperacion fallida y cada reformulacion, que son muestras de vocabulario del usuario que no tenias al disenar. La segunda: BM25 es lexico y un retriever con embeddings maneja mejor los sinonimos de fabrica, pero eso suaviza el acantilado sin derogar el mecanismo, porque cualquier retriever solo puede casar contra la superficie que expone la descripcion. El harness del autor deja el retriever como una clase intercambiable, asi que la comparacion con embeddings queda como experimento pendiente, y el repositorio la incluye en measure/, junto al contador de tokens.
Para quien escribe manifiestos de herramientas para agentes, la conclusion es operativa: antes de recortar descripciones para ahorrar contexto, mide que proporcion de las peticiones reales usa palabras que no aparecen en ellas. El fallo no se ve en los logs como error, se ve como un agente que hace algo plausible y equivocado.
