grep 找代码要百万 token，Semble 只用两千就够了

一个 AI 代理打开陌生仓库多半是先 grep 出一批文件名再逐个 read 读内容100k token 的窗口填进去也不一定能找到真正有用的那几行。这不是操作习惯的问题方法本身就有这个毛病——把整个仓库喂给模型是一种赌博赌模型恰好能在几万行代码里定位到答案而大多数时候代理会把时间和钱花在阅读注释、空行和与问题无关的兼容层上。Semble 是一个专门给 AI 代理用的代码搜索库逻辑只有一句话只返回代理真正需要的代码片段。检索走两条路。语义层靠 potion-code-16M一个代码专用的静态嵌入模型把自然语言查询翻译成向量找语义相近的块词法层靠 BM25处理函数名、类名这类精确匹配的需求。两路结果通过 Reciprocal Rank Fusion 融合再叠上五个重排序信号——定义符号class 和 def 的块优先于只是引用的块标识符词干匹配同文件多块命中时整体提升测试文件和兼容层降权。这套组合跑过一份覆盖 1250 个查询、63 个仓库、19 种编程语言的基准。Semble 的 NDCG10 是 0.854同类最强的 CodeRankEmbed Hybrid 是 0.862两者质量几乎持平但 CodeRankEmbed 是 137M 参数的大模型索引一次要 57 秒查询延迟 16 毫秒。Semble 索引 263 毫秒查询 1.5 毫秒全程 CPU不要 GPU不要 API Key不要外部服务。2k token 预算Semble 能达到 94% 的召回率grepread 要填满 100k token 上下文才到 85%。这是架构层的选择。potion-code-16M 出自 Model2Vec 的蒸馏方案参数已经压进静态向量查询时没有 Transformer 前向推断没有矩阵乘法于是 1.5 毫秒而非 16 毫秒。工程调优买不来这一步。对已经在用 Claude Code、Cursor 或 Codex 的人Semble 可以 MCP Server 的形式接入仓库自动克隆并索引本地路径监听文件变化实时更新。它同时提供 CLI 和 Python API后者能拿到每个结果块的文件路径和起始行号方便进一步集成。代码搜索在 AI 编程工具里向来是被忽视的一层。大家盯着模型能不能写对代码却很少问代理知道从哪里开始找吗一个五万行的陌生仓库grep 给出文件名单read 给出行内容模型要先用相当多的 token 来判断哪些是相关的这个过滤本身是有代价的。Semble 把这个工作从模型层挪到检索层token 省了速度快了道理并不复杂。https://github.com/MinishLab/semble你在实际的 AI 编码工作流里有没有遇到类似的上下文爆炸问题欢迎在评论区聊聊具体的场景。