小红书精读：Enrich-Retrieve-Rank: Scaling Capability Discovery Beyond In-Context Routing

N=7278，LLM选工具崩了？换检索！

📌 各位算法同学们，当注册表里有7278个能力时，让LLM自己看清单选工具的准确率直接从0.85暴跌到0.12，而换一种思路只降到0.39。这篇工作把能力发现重新建模成搜索问题，对做agent平台的人有参考价值。

📄 Enrich-Retrieve-Rank: Scaling Capability Discovery Beyond In-Context Routing

🔧 离线富化：注册时用LLM把稀疏的name和描述改写成结构化profile（摘要、关键词、正反例），一次注册付一次钱，查询时不再调用。🧩 在线两段式：先BM25加向量检索捞top-k，再用LLM rerank打成短列表，全程不对候选做在线invoke，省掉试错成本。⚙️ 拆解指标：把端到端性能拆成检索recall和rerank条件准确率，发现大注册表下约70%的失败来自检索，rerank在规模变大后依然稳坐在0.70到0.87。

📊 从N=10到7278，in-context routing的Match@1从0.85崩到0.12，检索加重排从0.81缓降到0.39。📈 在Nova Micro上，交叉点在N约等于500，小于500直接全量塞上下文反而更划算。✅ 全规模时Match@1比Search&Pick高6.5个百分点，token成本约一半，比Full-Ctx便宜70倍。📉 重排器条件准确率保持在0.70到0.87，说明只要检索能捞到正确项，重排基本能把它放第一。

💡 对工具或Agent注册表超过500的平台，把上下文路由换成检索加重排是明确的升级方向，但别盲目补离线富化——在公共数据集上富化几乎没增益甚至掉点，它只对脏元数据有用。要盯的指标是Match@1和检索recall，下一步大概率得在召回上下功夫。

原文：AlphaXiv