构建 GitHub 代码搜索的经验教训 [视频]

代码搜索的登录要求

• 许多参与者询问为什么公共代码搜索现在需要登录。
• 提出的解释包括：
  • 产品/指标：提升“活跃用户”数字，并将人们引入 GitHub 的生态系统。
  • 成本/性能与反滥用：高级搜索计算开销很大，而且是机器人的主要目标；登录可启用速率限制和 DDoS 防护。
  • 竞争/数据策略：登录墙可能妨碍竞争对手从 GitHub 数据中挖掘信息，同时最大化 GitHub 从他人那里挖掘数据的能力。
• 关于匿名用户价值的分歧：
  • 一些人认为他们是占用计算资源的低价值“白嫖者”。
  • 另一些人认为他们是未来的客户和贡献者；增加摩擦会削弱开放性，以及 GitHub 在开源生态中的角色。

开放性 vs. 围墙花园

• 一些评论者认为登录墙是更大趋势的一部分（类似 Twitter/Reddit），即将原本开放的功能封闭化并货币化。
• 批评者认为这会侵蚀信任，并推动项目/用户寻找替代方案或本地工作流（clone + grep）。
• 支持者强调 GitHub 并不“欠”任何人免费的计算资源，必须在使命与可持续性之间取得平衡。

搜索功能、排名与缺失结果

• 许多人高度认可新引擎的能力：正则表达式、精确匹配、fork 索引、更好的导航、更少的超时，以及扩展到海量仓库。
• 令人沮丧的问题包括：
  • 移除了“按最近排序”，该功能用于追踪新的使用模式和错误；一些用户依赖此功能。
  • GitHub 工程师解释说，按最近排序在技术上已变得非常复杂（持续重建索引、去重、Git 的历史模型），并且被抓取器严重滥用；团队优先处理了其他功能。
  • 排名经常显示大量几乎重复的 fork 结果；用户希望默认排除 forks。
  • 还有人抱怨搜索有时会漏掉已知匹配项；工程师表示，大多数情况是因为相关仓库尚未索引或触及了文档化限制，并同意关于索引状态和排除项的可见性很差。

性能和 UI 回归

• 多个反馈指出 GitHub 的网页 UI 变得迟缓或不稳定，尤其是在以下场景：
  • 带语法高亮的大文件。
  • 基于 React 的新界面和客户端渲染。
  • 移动端/Android 浏览器，页面或系统 UI 可能崩溃。
• 由于前端性能问题，一些用户转而克隆仓库，或查看本地镜像/替代托管平台。

替代方案与变通方法

• 经常被提到的替代方案包括：grep.app、sourcegraph、Debian code search、本地工具（ripgrep、The Silver Searcher）、github.dev 的类 VS Code 搜索。
• 一些组织认为商业搜索定价过高，更倾向于自己搭建代码索引，或者等待未来的 AI 工具。

演讲内容与相关技术

• 观众称赞这场演讲以及新系统背后的工程设计（例如，自定义索引器 “Blackbird”、三元组分词、去重、几何 XOR filters、基于 Tree-sitter 的语义分析）。
• 大家对未来发布数据结构和实现细节很感兴趣；有些人已经在根据 GitHub 的语法构建自己的查询语言。