用 SQL 直接查询 500 TB 的互联网索引能比自然语言搜索更精准吗

把互联网索引直接开放成一个可运行 SQL 和 Datalog 的数据库，这种思路在 Scry 这款产品上实现了。它在 ClickHouse 里存了 500 TB 的 NVMe 索引，让用户能用类 SQL 的方式去检索信息，而不是像用 Google 或 Tavily 那样把请求丢进黑盒等结果。最核心的机制是引入了基于拥堵情况的微拍卖定价，当资源充足时，非商业用途是免费的。

为什么用 SQL 搜互联网比自然语言更高效

现在的搜索逻辑基本是「自然语言 → 黑盒算法 → 排序列表/总结」，用户对结果的控制力极低。Scry 的逻辑是把搜索回归到关系型数据库的检索，利用 OLAP 数据库的特性，配合 LLM 编写 SQL、Datalog 或向量查询，能实现极其精准的筛选。

传统的搜索 API（比如 Exa 或 Tavily）在处理 Agent 上下文映射到索引子集时，无论查询难度如何，用户支付的固定成本是一样的。这意味着当平台计算资源紧张时，用户得承受性能下降的后果。Scry 通过拥堵定价解决了资源竞争问题，让资源分配更透明。

这种可编程搜索的实操逻辑

如果你想通过 Scry 找一些极其前沿的 AI 开发者，传统的关键词搜索很难过滤噪音。但在 Scry 这种架构下，你可以通过组合词法分析（Lexical）和 Jev 算法的查询配方来精准定位，而这种「搜索配方」是可以被社区共享和改进的。

目前的实现细节包括：

• 存储底座： 500 TB NVMe 索引运行在 ClickHouse 上。
• 查询语言： 支持类任意只读 SQL 以及部分 Datalog。
• 定价机制： 采用 Congestion-based micro-auction pricing（基于拥堵的微拍卖定价）。
• 免费额度： 只要此时此刻没有资源冲突，非商业用途免费。

绕过 Text-to-SQL 的陷阱

很多搜索公司在 2024 年经历了一段痛苦的 Text-to-SQL 尝试期后，现在已经基本放弃了这条路。但 Scry 的方向不是让搜索公司去做转换，而是直接给用户提供一个可编程的接口。

这种范式的优势在于，它不再试图用一个模糊的自然语言接口去覆盖所有场景，而是允许开发者利用 LLM 编写出复杂的 SQL 或 Jev 查询语句，直接在海量数据上进行结构化筛选。

目前 Scry 还在尝试在差异化硬件上扩展数据规模，对于需要高精度、可重复且可编程检索的场景，这种「数据库化搜索」比传统的 API 检索要硬核得多。