介绍
以下是我们实现 Awesome Repositories 背后的 AI 搜索算法的方式。该网站帮助访问者通过通俗语言查询（如“self-hosted feature flags”或“terminal UI for git”）找到开源 GitHub 仓库。它返回排名结果，且每个匹配项都包含书面理由。结果在四秒内送达，AI 费用约为十分之一美分。
难题在于相关性。搜索查询描述了某人需要什么。仓库页面通常描述实现细节、项目历史、安装步骤和 API 行为。直接匹配词汇会失效。对于“kubernetes gitops”，关键词引擎会将一个 430k Star 的链接集合排在第一位，因为该页面比任何真正的工具都更频繁地提到这两个词。
我们通过在搜索之前进行深度思考解决了这个问题。我们追踪了 5,000 多个有前途的开源仓库。一个 AI 代理会提前一次性研究每个仓库，并将项目记录为带有证据的组织目录中的标签。当搜索到来时，模型会将查询翻译成要查找的标签。简单的数据库数学运算将这些标签转化为仓库的排名列表。
读取仓库
当一个仓库进入我们的索引时，分析运行会像细心的工程师一样阅读其文档。代理的一部分会规划哪些页面值得阅读。工作代理读取这些页面并做笔记。最后一步将笔记转化为结构化记录。
文档差异很大。命令行工具可能只有一个 README，而平台可能有数百页。我们对每次运行设置了 1 美元的上限，因此拥有 600 页文档站点的项目不会耗尽预算。它只是被阅读得不那么彻底。
输出是一组标签，每个标签带有两个字段：一个 0-100 的分数，表示该仓库属于该标签的程度，以及一个用通俗语言解释该仓库为何获得该标签的书面理由。
书面理由是产品的一部分，也是我们调试它的方式。当搜索结果看起来错误时，我们检查每个标签背后的证据，而不是盯着一个不透明的相似度分数。AI 做出的每一个判断，我们以后都可以审计。
代理还会记录它刚刚读取的仓库类型。精选链接列表与工具、教程或项目模板不同。将格式标记为自己的标签，可以让搜索引擎稍后排除整个组，因此搜索工具会返回工具，而不是关于工具的链接列表。
到目前为止，已经有一千多个仓库经过了这种深度分析。这是设计上的昂贵部分。我们每个仓库花费一次美元，而不是每次搜索花费几美分。
目录
所有仓库判断都落入一个树状结构：22 个顶级类别下的 32,419 个已批准标签。该树为系统提供了共享语言。没有它，两次分析可能会用略有不同的词描述同一个想法，或者更糟的是，对不同的想法使用同一个词。
我们使用像图书管理员一样工作的 AI 代理来维护目录。它调查一个部分，决定合并、移动或解散什么，通过小型单用途操作执行，并将该部分标记为已审查。目录中没有任何内容会在该审查循环之外更改。
目录有两条规则使其保持有用。首先，一个类别最多有大约 15 个子项。任何更详细的内容都会深入一级，而不是让一级变得更宽。拥有数十个条目的类别比更窄、更深的树更难扫描和维护。该规则对模型和我们都有帮助，因为在 15 个相关概念中进行选择比从长长的扁平列表中选择更可靠。
其次，每个标签都有一个基于实际归档在其中的仓库的描述，绝不是从名称中猜测出来的。每个清理决策都会首先检查该证据。当我们尝试合并共享相同名称的标签时，这条规则证明了其价值。一个读取底层仓库的验证器拒绝了大约 60% 的合并。名称相同，概念不同，这种情况比我们预期的要多。
目录还为搜索提供了意义层。每个标签都有一个嵌入（Embedding）：一个数字列表，将其意义放置在地图上，相似的想法在地图上靠得很近。“Container orchestration”和“Kubernetes”在地图上靠得很近，即使它们没有共享任何词汇。我们存档了大约 43,000 个嵌入。
处理搜索
每次搜索都使用模型来理解查询并命名需求。数据库负责检索和排名。
- 模型在检索开始前读取查询。产品名称通常暗示类别。“posthog alternative”实际上是一个产品分析问题，即使查询中没有说“analytics”。模糊的查询会保留所有合理的解读，而不是过早地押注于某一个。
- 模型生成两组标签：结果必须匹配的标签，以及取消其资格的标签。负面列表很重要。“Lightweight kubernetes dashboard”应该将重量级平台推向排名下方。仅靠必须具备的列表无法表达这一点。排除项让系统能够说明结果应该避免什么，而不仅仅是它应该包含什么。
- 每个所需概念同时与目录进行两次匹配。经典关键词搜索查找确切词汇。嵌入搜索在地图上查找附近的意义。两个排名列表被合并，在任一路径上得分高的条目都会上升到顶部。第三个信号将查询与每个仓库的整体重心进行比较：其所有标签在意义地图上的平均位置。这可以捕捉到那些即使没有直接命中单个标签，但整体形状符合的项目。
- 找到候选标签后，格式标签会删除查询未要求的仓库。这就是链接集合离开工具搜索的地方。搜索“best git TUI”应该返回 git 的终端界面，而不是 git 工具列表。
- 最终排序计算每个仓库的标签与需求的重叠程度，并根据仓库拥有的标签数量进行调整。此步骤中没有 AI 运行。当标签被写入时，判断就已经完成了。
端到端，搜索大约需要 3.7 秒，成本为 0.001 美元。重复搜索几乎是免费的。当一个新的查询在意义地图上足够接近我们之前回答过的查询（例如“best git TUI”与“good terminal UI for git”）时，存储的解释会被重用，而无需调用模型。
我们保留的想法
在记录时进行一次昂贵的思考，并保持读取的廉价。我们花费美元分析每个仓库一次，然后在此之后的每次搜索中只花费几分之一美分。我们将检索保留在我们已经运行的数据库中。我们为每个 AI 判断附加一个分数和书面理由，因为第一个看起来错误的排名需要的是证据，而不是感觉。