问题描述：

本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容：

• 我的帖子已经打上 开源推广 标签： 是
• 我的开源项目完整开源，无未开源部分： 是
• 我的开源项目已链接认可 LINUX DO 社区： 是
• 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是
• 以上选择我承诺是永久有效的，接受社区和佬友监督： 是

背景：

这个项目主要是为了验证我的偶尔冒出的想法，方法上与现有绝大数向量搜索有点点区别。项目原先集成在CCW(claude-code-workflow)中，在CCW(7.X)版本后独立出来，并做了方法精简和重构，方便大家使用。

特点：

• 支持本地模型和api接口
• 支持冷启动快速搜索
• 支持MCP协议

项目地址:

catlog22/codexlens-search: Lightweight semantic code search engine — 2-stage vector + FTS + RRF fusion + MCP server for Claude Code

主要方法:

多通道并行检索 + 融合 + 重排序。

Query → 意图检测 → 查询扩展(仅NL) ├─ Binary粗筛 (Hamming) → ANN精排 (cosine) → 交集 → vector结果 ├─ FTS精确 (BM25) + FTS模糊 (prefix*) ├─ 符号图搜索 (seeded from vector/FTS top results) └─ Ripgrep正则 (auto模式) └─ RRF加权融合 → Cross-Encoder重排序 → top-k

---

检索通道

通道	原理	作用
Binary粗筛	float32→符号位量化→XOR+popcount Hamming距离	O(N)位运算快速缩小候选到 top-200
ANN精排	HNSW图 cosine近邻(USearch/FAISS/hnswlib)	从 top-200 候选中精排 top-50
FTS	SQLite FTS5, Porter stemming, BM25 + prefix*	关键词精确/模糊匹配
符号图	沿 import/call/inherit/type_ref 边双向遍历	发现结构相关但语义不相似的代码
Ripgrep	实时正则匹配	精确 pattern 搜索，无需索引

---

安装:

# Minimal — CPU inference (fastembed bundles onnxruntime CPU) pip install codexlens-search # Windows GPU — DirectML, any DirectX 12 GPU (NVIDIA/AMD/Intel) pip install codexlens-search[directml] # Linux/Windows NVIDIA GPU — CUDA (requires CUDA + cuDNN) pip install codexlens-search[cuda] # Auto-select — DirectML on Windows, CPU elsewhere pip install codexlens-search[all]

模型下载(推荐384维度模型，有较好的体验或者有高质量的api接口)

# 查看已知模型及缓存状态 codexlens-search list-models # 下载默认的 embed + reranker 模型 codexlens-search download-models # 下载默认但指定 embed 模型 codexlens-search download-models --embed-model BAAI/bge-base-en-v1.5 # 下载任意单个模型（按 HuggingFace 名称） codexlens-search download-model BAAI/bge-large-en-v1.5 # 删除缓存的模型 codexlens-search delete-model BAAI/bge-small-en-v1.5

#MCp配置

{ "mcpServers": { "codexlens": { "command": "codexlens-mcp", "env": { "CODEXLENS_EMBED_MODEL": "BAAI/bge-small-en-v1.5", "CODEXLENS_EMBED_DIM": "384", "CODEXLENS_DEVICE": "directml" } } } }

基于本地模型 BGE-small-en-v1.5 (384维度)VS ACE实测报告

一、总体结果

指标	ACE	Codexlens	差值	胜出
平均召回率 Recall@10	1.0000	0.8917	-0.1083	ACE
平均 MRR	0.9167	0.9667	+0.0500	CL
平均 NDCG@5	0.9363	0.8935	-0.0428	ACE
Top-3 命中率	1.0000	1.0000	0.0000	平局
零召回查询数	0	0	0	平局

逐查询胜负：ACE 胜 5 项，平局 15 项

---

二、分类维度分析

2.1 按查询类型

查询类型	查询数	ACE 召回率	CL 召回率	ACE MRR	CL MRR	分析
跨模块架构 (cross-module)	3	1.000	0.556	0.833	1.000	ACE 召回领先，CL 排序更优
抽象行为 (behavioral)	4	1.000	1.000	0.708	0.833	召回持平，CL 排序更优
异常降级 (negative)	2	1.000	1.000	1.000	1.000	完全平局
实现细节 (impl-detail)	5	1.000	1.000	1.000	1.000	完全平局
端到端集成 (integration)	6	1.000	0.861	1.000	1.000	ACE 在多模块流程中覆盖更全

2.2 按查询难度

难度	查询数	ACE 召回率	CL 召回率	ACE MRR	CL MRR
中等 (medium)	10	1.000	0.950	0.950	1.000
困难 (hard)	10	1.000	0.833	0.883	0.933

困难查询中 ACE 召回率优势为 +16.7%，但 Codexlens MRR 在两个难度级别均高于 ACE。

---

三、逐查询详情

编号	类型	难度	ACE 召回	CL 召回	ACE MRR	CL MRR	胜出	说明
CQ1	跨模块	困难	1.00	0.50	1.000	1.000	ACE	全流程 pipeline→fusion→binary→index，CL 找到 2/4
CQ2	跨模块	困难	1.00	0.67	0.500	1.000	ACE	抽象基类模式，CL 找到 2/3 base.py
CQ3	跨模块	中等	1.00	0.50	1.000	1.000	ACE	分片 LRU 管理，CL 只找到 shard_manager 漏了 shard
CQ4	行为	困难	1.00	1.00	0.333	0.333	平局	两者均完美召回，排序相同
CQ5	行为	中等	1.00	1.00	1.000	1.000	平局	防抖机制
CQ6	行为	中等	1.00	1.00	1.000	1.000	平局	检测机器生成代码
CQ7	行为	中等	1.00	1.00	1.000	1.000	平局	代码感知分块
CQ8	异常	困难	1.00	1.00	1.000	1.000	平局	空索引降级处理
CQ9	异常	中等	1.00	1.00	1.000	1.000	平局	API 重试逻辑
CQ10	细节	困难	1.00	1.00	1.000	1.000	平局	自适应融合权重
CQ11	细节	中等	1.00	1.00	1.000	1.000	平局	上下文头部注入
CQ12	细节	困难	1.00	1.00	1.000	1.000	平局	符号引用图构建
CQ13	细节	中等	1.00	1.00	1.000	1.000	平局	HF 镜像和模型缓存
CQ14	细节	中等	1.00	1.00	1.000	1.000	平局	二值量化
CQ15	集成	困难	1.00	1.00	1.000	1.000	平局	环境变量配置级联
CQ16	集成	中等	1.00	1.00	1.000	1.000	平局	MCP 懒加载管线
CQ17	集成	中等	1.00	1.00	1.000	1.000	平局	并行索引工作池
CQ18	集成	困难	1.00	0.50	1.000	1.000	ACE	图遍历扩展，CL 只找到 graph.py 漏了 pipeline.py
CQ19	集成	困难	1.00	0.67	1.000	1.000	ACE	增量同步，CL 漏了 indexing/pipeline.py
CQ20	集成	困难	1.00	1.00	1.000	1.000	平局	多端点负载均衡

---

四、关键发现

4.1 ACE 的优势

1. 完美召回率（1.0）：20 项查询无一遗漏

2. 跨模块查询领先：跨模块类 CL 召回率 55.6%，ACE 为 100%，差距最大

3. 多跳集成流完整覆盖：CQ18（图遍历搜索）和 CQ19（增量同步）等涉及 3+ 模块的端到端流，ACE 能找全所有关键组件

4.2 Codexlens 的优势

1. 排序质量更高：MRR 0.967 > ACE 0.917，命中时将最相关文件排在更靠前位置

2. 实现细节和异常类查询完美：这两类 Recall=1.0、MRR=1.0，与 ACE 完全持平

3. 本地推理速度：20 项查询 ~24 秒（本地 BGE-small 模型 + USearch ANN），无需网络

4.3 剩余差距分析

未完全召回项	召回率	缺失文件	原因
CQ1	0.50	core/binary.py, core/index.py	查询描述与底层存储模块词汇差异大
CQ2	0.67	rerank/base.py	“plugin architecture” 未关联到 rerank 包
CQ3	0.50	core/shard.py	shard_manager 命中但 shard 本体被其他结果挤出
CQ18	0.50	search/pipeline.py	图搜索种子来自初始搜索，种子不全则扩展受限
CQ19	0.67	indexing/pipeline.py	查询扩展词将目标文件挤出 top 结果

---

五、测试方法

• 真值标注：基于源码人工审查确定每项查询的预期文件列表
• 评估指标：Recall@10（Top-10 召回率）、MRR（首个相关结果排名倒数）、NDCG@5（位置感知排序质量）、Top-3 命中率
• Codexlens 配置：Python API 直接调用 SearchPipeline.search(query, top_k=20)，BGE-small-en-v1.5 嵌入 + FAISS 二值索引 + USearch ANN + FTS5 全文搜索 + RRF 融合 + 交叉编码器重排序 + Two-Hop 查询扩展
• ACE 配置：MCP 工具 search_context，云端专有检索模型
• 胜负判定：加权综合分 = 0.5×Recall + 0.3×MRR + 0.2×NDCG@5，±0.01 容差内判为平局

---

六、结论

ACE 在召回率上保持领先（1.000 vs 0.892），尤其在跨模块查询中优势明显。Codexlens 在排序质量上超越 ACE（MRR 0.967 vs 0.917），在单模块聚焦查询上与 ACE 持平，且具备本地离线推理优势。

网友解答：

---

--【壹】--：

deepwiki 索引完大家就能来研究了

image1060×544 34 KB

---

--【贰】--：

前排支持哇

---

--【叁】--：

我觉得慢无所谓 用的是千问开源的那个8b模型 不是那个硅基免费的

---

--【肆】--：

我还是感觉效率优先，最终还是是靠llm分析的，当前只是缺一个快速定位的工具

---

--【伍】--：

前排支持

---

--【陆】--：

其实还好
主要是会变成你除了主功能，又得维护基础设施
我觉得会增加无谓的工作量 (麻烦 )

---

--【柒】--：

测的是哪个项目

---

--【捌】--：

我不懂 不知道哪个体验更好 我接的是硅基流动的模型

---

--【玖】--：

GitHub - hsingjui/ContextWeaver: ContextWeaver 是一个基于 MCP 协议、利用 Tree-sitter 和向量搜索为大语言模型提供本地代码库智能上下文编织与检索的工具。 · GitHub 大佬与这个项目有什么区别呢

---

--【拾】--：

收藏了，谢谢佬

---

--【拾壹】--：

蹲个测评，看看效果

---

--【拾贰】--：

主要是方法不一样,支持本地模型

---

--【拾叁】--：

感谢大佬！

---

--【拾肆】--：

能不能来个测评的

---

--【拾伍】--：

是这样的，还是考虑速度，应该要慢1倍左右，，

---

--【拾陆】--：

@apparition 我来邀请一个专家进行测试

---

--【拾柒】--：

可以对比测试一下，我用的硅基免费的很慢，本地要比硅基快10X倍以上

---

--【拾捌】--：

我觉得把 cuda 这些从项目中拆分出来可能比较好
大家应该比较倾向用 API 或 ollama 跑 (?

---

--【拾玖】--：

ollama 太慢了