linux.do

逆向复现augment ACE进展与求助！

如题，augemtn的AceTool 开始收费了。我查阅了一些已有的方法，以下是目前的一些拙见，我希望能和愿意动手的人一起，把它背后的思路拆开、跑通，最后做出一个可复现、可替代的开源方案。 我自己能力有限，看到这的佬们，如果有推荐算法、大模型岗位的经历，刚好也对代码检索/代码索引感兴趣，请私信我，一起把这件事推进下去。

以下是正文：
从augment的博文描述来看，它大概率用了自研的 embedding 模型，对代码的逻辑关系处理得更好。它的代码索引 API 几乎是瞬间返回，而且能细到行号级别，因此我推测它的做法是先把代码切chunk，再对 chunk 做 embedding 并建立索引。

但这条路线如果直接用通用 embedding 模型，几乎很难达到同样效果。
站内有佬复现了ace，[开源] ContextWeaver 本地代码库语义检索工具，目标是ace平替，基本上可以平替ace，但是搜索到的内容没有ace的精准，大部分命中的都是文档。我也试了 qdrant 的 MCP，用 all-MiniLM-L6-v2 去做 RAG，检索出来的文档而不是代码的内容，而且大多数是混乱不香干的。

博客里还提到他们做了量化，并在量化后的 embedding 上用 ANN 做近邻搜索，但没说明具体算法猜测可能是 HNSW。至于增量更新的方法，原文示意图如下

在缺少高质量 code embedding 模型的情况下，如果我们要给代码库建立索引，就需要把信息组织得更结构化，而不是只依赖向量相似度。

我目前想到一个相对可行的方案是：既然代码embedding的效果达不到闭源效果，那就让 LLM 来做分层摘要，用摘要来承载语义，结构承载关系。

具体做法为先对每个文件生成摘要，要求覆盖文件职责、关键函数/类、重要数据结构、对外接口、依赖关系等。然后从文件递归到根目录，每次把子节点摘要汇总到父节点，逐层形成目录树摘要。最终根目录摘要应包含整个仓库最重要的信息与入口。得到这棵树之后，检索时从根开始做深搜，每一层计算 top-k 节点的相似度，逐层往下。这样总体计算量约 d·k，不用对全量文件做相似度。当树检索把候选范围缩到 k 个或更少文件后，再对这些文件进行 chunk 化 RAG，或者直接让 LLM 在候选文件里定位具体行号。

假设一个 50k LOC ，500 文件的仓库，一行代码约 10 token，如果每个文件摘要要求覆盖到函数级信息，那么即便按输入 2k、输出 1k 来算，总消耗约是：3k token/文件 × 500 文件 ≈ 1.5M token，如果用 1 token 1刀的模型（大部分佬都有免费token），成本大约 1.5～2 美元，我觉得是可以接受的。

不过，对复杂的仓库，同一个功能往往跨越多个目录与层级：前端、后端、数据库、消息队列、配置、异步任务，语义搜索只能命中显性写出来的文件，它所调用的函数、隐藏的依赖就很难被一起带出来。因此我认为还需要将pub sub、http、import等关系提取出来，提取为有向无环图，再对涉及到的文件进行类似HNSW的广搜，得到N个文件，最终得到N+K个文件。

说在最后：我知道这篇文章里很多想法都很粗糙，但我依然想把它发出来，我相信这件事靠一个人很难做成，需要更多有经验的佬共创。

欢迎佬们给方向、指正错误！如果你做过向量检索、ANN/HNSW、代码分析、RAG/Agent、或者做过大型仓库的工程化落地、或者有逆向工程的经历，请私信我！我会持续的将开发的进展更新在L站。

21 posts - 20 participants

Read full topic

via LINUX DO - 热门话题 (author: yxp934)

Invalid media: image

34 views01:18