- 楼主 编辑于
【dsh-gitea-search】发布了 1.2.0 支持了 macos 脚本安装和零起步（不依赖 gitea）
https://github.com/offzen/dsh-gitea-search
下面的功能还没加入，有点复杂。
准备先朝其他方向演进，向量化就先自用了
有兴趣的可以看 这里 跟火山的对比
昨天炫了一把速度 😄 https://sb.sb/t/12731/✅ embedding 已于 2026-10-24 全量部署并上线
组件 状态 Embedding 模型 ✅ bge-small-zh-v1.5（ONNX，512 维，183MB），TEI cpu-1.5 容器运行推理服务 ✅ pack 常驻容器 tei-query，另有 gate2/gate1/dev2/ams2 四台 worker 兜底向量库 ✅ Qdrant gitorca_docs_v1，93,050 chunks，覆盖 16,123 篇文档MCP 工具 ✅ search_gitorca_semantic+search_gitorca_hybrid（FTS5 + 向量 + RRF 融合）已上线刚才那次实测调用正常返回了带 score 的语义命中结果，证明整条链路（查询→TEI 向量化→Qdrant 相似度检索）是活着的。
它同时承担两种角色，这是标准 RAG 双链路架构：
语料侧（离线批处理，非实时）：文档向量是预先算好的。由
fleet-embed-index.py分布式批量生成（4 worker 并行，全量 16.3 分钟），之后靠 cron（每小时 20 分）做增量——用 chunk 内容 sha1 比对，只重算新增 / 变更部分，无变化时 12.7 秒即跳过。查询侧（实时处理）：每次您发起语义检索时，查询文本会实时向量化——走 pack 本机常驻的
tei-query容器，实测延迟 114–143ms（比早期 ssh worker 方案的 2483ms 快 17 倍）；本机 TEI 挂掉时自动兜底切到远程 worker。语义检索速度 经 21 条真实 query 实测：单 FTS5 命中 95.2%、单向量 90.5%、RRF 融合 100%
收藏支持反对打赏
为了跑语义小模型，把小鸡们都叫起来干活了😄
实际不用这么多，2-3C 的 epyc milan 就够在 2 小时内跑完。我准备了 24 核心以上搞这个架构，以后还可以跑别的。
牛啊兄弟
关键成本启示：谁才是真正的 “吞金兽”？
很多人直觉认为 “模型思考与生成文字单价最高，所以推理输出最贵”。但从这次实测数据可以看出：
* 推理生成只占 2.5%：虽然生成单价是输入的 2~4 倍，但因为整个会话生成量只有 53k tokens，总支出仅一毛钱出头。 * 上下文冷输入占了 75% 的绝对大头：在会话后期，单步上下文已膨胀到 150k。 一旦发生模型切换、网络超时重试、或者工具返回大块输出导致服务端 Prompt Cache 失效，只要有 1 次“全量冷输入重算”， 单步就要吞掉 150k 全价 Token（相当于模型生成 75,000 字的费用）！ * 结论： 控制上下文膨胀与及时切新会话，比节约输出字数重要 30 倍。 任务阶段性闭环后，立即将结论落盘推仓并新开轻量会话，是性价比最高的工程实践。支持 bd
厉害呀- 该用户已被禁言，内容已隐藏
