基准测试与案例

本页刻意保持克制。

它不试图证明 indexbind 赢下所有搜索基准，只想展示：

• 当前可复现的本地基线长什么样
• 当前文档语料的规模
• 哪些自用模式已经依赖 indexbind

本地参考基线

以下数据在本地 Darwin x86_64 开发机上，使用当前 docs/site 语料与 hashing 嵌入后端采集。

请把它们当作参考值而不是普适结论。硬件、Rust target 缓存状态、文档形态、嵌入后端与重排选择都会影响数字。

文档站点基线

语料形态：

• 14 个 markdown 文档
• 74 个分块
• hashing 后端
• 原生 SQLite 工件

本地观测基线：

这是项目自身文档集当前的「小型真实语料」基线。

回归 Fixture 基线

内置回归 fixture 刻意极小，应把它读作正确性基线，而不是吞吐基准。

Fixture 形态：

• 3 个文档
• 6 个分块
• 固定查询集位于 fixtures/benchmark/basic/queries.json

本地观测基线：

该 fixture 适用于回归检测、CI 信心与发布检查。它不代表大规模语料的性能结论。

当前自用案例

当前使用仍以第一方为主。在这个阶段这很正常，但值得直说。

文档站点

indexbind 支撑着它自己的文档场景：

• 文档是固定的 markdown 语料
• 语料可在发布时构建为检索工件
• 宿主站点仍拥有导航、渲染与信息架构

这是文档站点 / 浏览器 bundle 路径最清晰的公开示例。

博客与发布流程

indexbind 也用于一个博客式发布流程，宿主系统拥有：

• frontmatter 与规范 URL 决策
• 内容路由
• 产品级排序策略

这是编程式构建路径最清晰的自用示例。

本地知识库与工作区搜索

该项目还被用于工作区式本地知识库场景：

• 增量更新很重要
• 智能体或钩子触发的刷新很重要
• 宿主想要本地检索层，而不是完整的可变本地存储产品

这是「增量缓存 + 本地 Node 工件」路径最清晰的自用示例。

如何解读这些结果

• 基准部分是本地基线，不是普适承诺。
• 案例部分展示的是 indexbind 优化的产品边界。
• 当前最有说服力的故事仍是「为宿主可控系统提供内嵌检索」，而不是「在任何环境即插即用的搜索」。

想看具体的接线示例，继续看采用示例。