谷歌索引的十分之一，99.9% 的召回率：20 个人如何做出 Brave Search

Nathan Labenz 一开场就说明，这是节目里第一期有赞助商的节目。Brave 已经赞助了好几个月，但他录制时依然照常，做产品的深度解析，并认为这次对话也符合节目一贯的标准。Brave 的搜索负责人 Josep M. Pujol 对索引和基础设施是怎么搭起来的，讲得格外坦率，包括团队为了保护用户隐私而接受的种种取舍。规模已经很可观：每小时超过 100 万次搜索，大约每秒 300 次。

Labenz 觉得最有用的，并不是一个年轻创业公司的故事。在真实流量之下，Brave 的习惯是不走回头路。每一代都会加入新的模型和技术，让集成系统更有效，也更复杂。评估依然没有能完全替代人类判断的自动化方案。录制结束后，Labenz 为自己的公司 Waymark 继续测试 Brave Search API，与谷歌和必应做对比。Waymark 是一款帮小企业制作主页的工具，目前主要依赖抓取。他发现 Brave 明显更好，于是把它推荐给了产品团队，并预计会用它来补充、而非取代现有流程：返回更快，覆盖抓取器漏掉的网址，还能从讨论和评价网站获得额外的背景信息。他还发布了一个 Colab 笔记本，同时调用这三家的 API，让听众也能跑一遍同样的对比。

Pujol 大约三年半前加入 Brave。此前他在 Clicks 工作，那是一家搜索创业公司，因为缺乏资金，加上赶上疫情时期，最后倒闭了。团队当时还有其他 offer，最后选择 Brave，是因为价值观契合：做注重隐私的软件，拥有一整套自主的技术体系，不必向大型科技公司租用技术栈。公司由 Brian Bondy 和 Brendan Eich 创办。现在的产品线包括浏览器、VPN、广告网络、Leo 聊天机器人，以及一个独立的搜索引擎。Brave 整体约 100 人，搜索的核心团队（工程师加上质量评估员）约 20 人。

最有特色的数据通道始于 Clicks，之后延续为 Brave 的网页发现计划（Web Discovery Project）。选择加入的用户会发送浏览信号，听上去很危险，直到收集方案的设计摆到台面上。Pujol 反对把数据和隐私对立起来的说法。危险不在于数据本身，而在于数据的用途和方法。贡献者不上传浏览历史或搜索历史，只发送一个个匿名的元素：某人访问了这个网站，并且参与到这种程度。Brave 无从得知两个元素是不是来自同一个人，所以它没法了解到关于你的任何信息。它只知道：某个页面很受欢迎，或者某个页面是在某个查询之后被点击的。

这套机制的设计目标，是让这一说法在遭受攻击时依然成立。没有用户 ID，无论显式还是隐式。消息会经过混合网络，以去除网络指纹，并被同质化处理，而且必须通过法定人数（quorum）门槛：必须有超过 N 个人发送相同的数据，Brave 才会接收。结果是记录之间无法关联。Pujol 说，即便最坏的情况下数据被整体交给黑客或政府机构，也没有人能识别或画像某一个具体的人。代价是这些数据无法再被复用。谷歌和微软也在收集类似的信号；问题在于，那些数据集被设计成能回答所有问题，无论正当与否。Brave 则是每一类问题只收集一个元素。画像数据要有用得多，但它恰恰也是会话被去匿名化的途径。

索引也不只来自这些访问。能够通过法定人数门槛的网址，足够公开，可以去抓取；Brave 不接受用户提供的页面内容，因为内容里可能含有隐私信息。团队做的大部分工作是有针对性地抓取，而不是盲目地爬取整个网络。Pujol 说，盲爬会让你淹没在噪声里：至少有十个 GitHub 克隆、Knuth 克隆，以及把索引放大十倍的副本。降噪是你唯一必须做到极致的事，因为噪声会同时影响模型质量、可扩展性和成本。他们的索引规模相对谷歌只有十分之一。在此基础上，他宣称召回率为 99.9%。Labenz 称这是幂律在起作用。

Labenz 假设 PageRank 仍会从链接图中贡献一些权威性。Pujol 不这么看：“PageRank 是个神话。”谷歌出现的时候，他已经是成年人，几乎要开始读博士了，在它还挂在斯坦福网址上时，他就在用。谷歌发布过两篇论文：一篇是 PageRank 的学术论文，另一篇是技术报告《The Anatomy of a Large-Scale Hypertextual Web Search Engine》，在他看来后者才是真正的干货。PageRank 是一个管用的噱头，也让记者有了可以讲的故事：一个改变一切的算法，从发明到胜利是一条直线。事情并非如此。

Larry Page 和 Sergey Brin 借助斯坦福的资源，率先用蛮力抓取了整个网络。那些硬盘堆在乐高积木上的照片之所以存在，是因为他们买了太多硬盘，没有铁架，只好用砖块来搭架子。抓取所有内容，就意味着要处理反向链接，而反向链接携带的是锚文本：别人对你网站的描述，而不是网站管理员自己写的简介（AltaVista 用的正是后者）。这又是降噪的问题：网页自己的文字，和其他一千个人对它的概括，哪一个更干净？从邻接矩阵可以算出特征向量，并写出一篇关于随机游走的漂亮论文。那只是锦上添花。真正的干货在于：在一台文件系统上完成全网抓取，并意识到你手里已经有了一种比网页原文更干净的页面表示。

Brave 仍然有权威性的概念，但 Pujol 说，他们是从受欢迎程度和流量出发来驱动它的，可能只做一两跳的计算，只占很小的一部分。锚文本真正对应的是查询日志：别人的查询，就是对一个页面在讲什么的描述。Brave Search 最初是一个推荐系统。日志不断积累，然后你可以在不同查询之间做语义扩展。你从没见过“Lady Gaga 的年龄是多少”这个查询，但你见过“Lady Gaga's age”，所以对其中一个管用的结果，对另一个也可能管用。查询相似度系统保存了超过 90 亿个不同的查询，对于一个新查询，它能在 20 毫秒内返回一组历史上的近邻，同时使用嵌入和查询的 n-gram。再往后才是合成查询，即一个页面可能回答的问题；然后才是对页面内容做传统的 n-gram 索引。后者成本更高，只有作为下一步的增量才说得通。这个故事很平淡：每次进步 1%，直到奏效。

硬件让其中一些步骤得以实现。在 Clicks，一个内存映射的推荐系统需要把整个缓存都装进 RAM。服务器内存最多只能到 16 GB；2 TB 就意味着要几千台机器，延迟也根本无法接受。后来亚马逊推出了内存为 1 TB 的实例，四台机器组成的集群让设计变得轻松许多。Pujol 说，没有 NVMe，Brave Search 就不会是一款有成本效益的产品。机械硬盘根本不可行；普通闪存跟内存相比，仍然慢了一个数量级。100 TB 或 1 PB 的 NVMe 会改变架构。Brave Search 的搭建方式，是在每个时刻都采用世界恰好能提供的东西。

Lady Gaga 的例子本身就是语义匹配。Brave 在 2019 年就用 StarSpace 嵌入起步：200 维，每维 2 字节，在人们把它叫作向量搜索之前，就已经在做最近邻搜索了。无论当时还是现在，单靠语义都不够。有些查询本身没有语义，比如产品型号、堆栈报错或某个名字。Pujol 的名字是 Josep Pujol，而不是 José；在任何语义模型里，西班牙语与加泰罗尼亚语的名字都靠得很近，但那是两个不同的人。他会给出的建议是：没有银弹。一个值得解决的问题，总是多种技术和模型的组合，上面再加一层集成。

对于页面内容，他们两种都用。类 BERT 的 Transformer 生成的稠密嵌入是 384 维，每维 2 字节，每个页面 1 到 5 个向量，用于语义匹配。稀疏嵌入是 16,000 维，每维 1 比特，用于字面匹配。搜索两者都用。搜索“Trump Tower”时，你要的是 Trump Tower，而不是“Trump”加上别的东西。很多人的直觉是：拿 OpenAI 的嵌入，扔进向量数据库，就完事了。这种做法只在狭窄的垂直领域才管用。嵌入也并非毫无错误。如果每 10,000 条出一次错，一个 10 万篇文档的库看起来好极了。到了 200 亿篇文档，这些错误会淹没召回集：2,000 个候选里有 10% 是噪声，除非其他模型能把噪声剔除，否则你就是盲的。

他们以艰难的方式学到了垂直领域的教训。早期人手不多，他们尝试把搜索拆成一百个垂直领域：天气、城市、名人、汽车。每个垂直领域都运行得很完美，却无法把它们拼在一起。他们把真正的问题推给了未来某个混合模块。在电影这个垂直领域，“Ted”只有一个含义；但在整个网络上，它可以是一部电影、一个人、一场会议，也可以是一个零件。通用搜索之所以难，就是因为这种噪声。Labenz 做的一个管件目录项目（老旧的纸质零件手册，编号没有语义）也正在走到同样的结论上：混合搜索，让精确匹配与通用嵌入并存，而不是直接跳到微调。Pujol 的工程准则是：爱上问题，而不是爱上某个框架。

这个集成是学习出来的，而不是一堆启发式规则。各种嵌入之间的距离会变成特征。在他们不同阶段运行的各个引擎之间，这可能意味着有 200 到 300 个特征，输入给 GBDT 做最终排序。Labenz 问，这是不是混合专家（MoE）的做法？Pujol 说，思路是一样的，只不过是“一个很糟糕的混合专家”：也是集成，但 MoE 通常一次从八个专家中挑选两个。对于正在选嵌入的开发者，他会建议尝试五到十个互不相关的模型，有的偏语义，有的偏字面，有的多语言，有的只支持英语，而不是去寻找一个完美的向量。相关的模型没有增益。不相关的距离就是额外的特征，而额外的特征正是排序得以提升的途径。

升级方式取决于组件。AI 摘要器，也就是 Brave 对约 25% 至 30% 的查询展示的 RAG 答案，是最容易的情况。团队十分重视片段的选择，会在这些片段上运行较窄的问答模型，然后再把提示词发送给大语言模型。摘要器 v1 大约在录制前一年用 Flan-T5 起步，之后换过其他模型，在几个月内经历了三次变更，其中包括一次微调。第二版用 Mixtral 上线；两周后 Llama 3 发布，测试表明它在更少资源下质量相当，他们用了一周就切换了过去。只要有一套测试集，再加上管道里一个无状态的部件，就足够了。

嵌入则恰恰相反。2019 年的 StarSpace 查询嵌入至今仍在生产环境中使用，Pujol 说，它们永远不会被替换。来自类 BERT Transformer 的内容嵌入，大约每秒处理 500 个页面，即在单块 GPU 上、经过充分优化，每页 2 毫秒，这在批量跑过 Transformer 的人看来已经很快了。即便如此，整个数据集仍然要花大约一年半。你只做一次，然后在这些输出之上构建更窄的模型和启发式规则。你不能每个季度都重做一遍。你能做的，是把嵌入 v1、v2、v3 都留在组合里。添加从来不是问题：每一个新的向量族，都只是 GBDT 的又一组距离。替换才是灾难，因为你会丢掉一个已经花钱获得的、与其他信号不相关的信号。

Labenz 追问“永远”这个词：世界在变，新的发展当然需要新的模型。Pujol 的观点是，你添加新模型，这样就能有两组查询与文档之间的距离，而不是一组。重新做一遍新嵌入，可能要动用许多 GPU 跑上一个月，花费不菲，这不是一个季度一次的节奏；也可能要再等一年。他指出，在 1,000 篇文档和 100 万篇文档的情况下，约束条件是不同的。一个管件目录重新嵌入起来不太费事。但在搜索引擎的规模上，凡是和数据绑定的东西都不要动。任何无状态的东西，比如负责摘要或改写的大语言模型，你可以从今天换到明天。

换模型很容易，但知道它更好就不容易了。Brave 有一支人工评估团队，占搜索工作的相当一部分，但不是大多数，对摘要、排序和准确性采用统一的方法论。人工标注的量有限，质量才是基准真相。查询日志，包括网页发现计划的流量，使他们能用 NDCG 与结果集交集度，和谷歌、必应以及 Yandex 做比较。当某类查询与谷歌的结果出现分歧时，他们会抽样并人工判断：是我们错了，还是我们的标准不同？搜索引擎最终会彼此相似，因为它们会互相参照。随着时间推移，测试集会增长到数万条高质量人工标注，以及数十万到数百万条自动标注。有些查询只由质量团队掌握，工程师无法针对它们过拟合，包括调超参数时那种悄无声息的过拟合。发布规则是尽力而为：如果质量和性能都没有变差，就发布；如果性能变差了，那就需要判断：是先发布、以后再优化，还是取消这次发布。

Labenz 问，摘要器有没有类似 OpenAI 模型规范（model spec）那样的东西，一套关于长度、语气和品味的宪法。“有，但这是只有一个人的宪法”：就是负责它的那位同事，外加一些常识性的指导原则：不要有偏见，尽可能简洁。他们没有时间去写一份完整的护栏文档。定期用团队认为非常好的结果做微调，就是风格应该传递的方式。Pujol 说，这里没有编辑立场，没有政治，也没有审查；品味仍然属于为结果打分的人，和其他任何产品一样。Llama 3 比 Mixtral 更啰嗦，所以切换后 Brave 的摘要变长了。他们可以把它稍微压下来一点。有些行为是工具本身固有的。如果你不知道正确的做法是什么，诚实的做法是：在拿到更多数据和评估能力之前什么都不做，而不是因为推特上有人抱怨，就去乱改模型。

Labenz 作为重度用户，会对查询做分流：最短的答案用 Perplexity，两页一千字的简报用 You.com 的研究模式，中间的用 Brave。Pujol 对这种当作常态的用法泼了冷水。搜索是一站式的服务。人们手上有个问题要解决，没打算去发现什么。他们要的是 Hotmail，或者因为此刻正在调 Mojito，所以想要一份 Mojito 配方。他们不想要两页 Mojito 的历史。因为 Brave 在许多国家是浏览器的默认搜索引擎，它必须服务于最大公约数。花哨的实验在没有流量的时候更容易做。用户不会因为体验好而奖励你，他们会因为体验差而惩罚你。你不会再去那家曾经让你受过一次气的店。谷歌拥有源源不断的流量，创新的空间反而比 You.com、Perplexity 或 Kagi 要小。Brave 大约 30% 的用户在美国；欧洲是下一个大市场。搜索团队本身全部在欧洲，还有几个人在非洲，都在同一个时区，尽管 Brave 是一家美国公司。

关于“食谱网站都以一段日记开头”这件事，在他看来是 SEO（搜索引擎优化）：一次碰巧奏效的随机游走，然后大家跟着照抄。不要低估偶然性。一个包含好信息、但格式让谷歌解析器不喜欢的页面，收录效果会比一个信息更差、但纯文本、解析器肯定能读懂的页面更差。优化者会针对一种可能缺乏强理由的算法，把许多格式都试一遍：某个结构因为解析得不好而被惩罚，某个增益恰好落在两个栈之间。根据泄露出来的谷歌文件，该公司每个页面有 14,000 个特征。Pujol 觉得这有点多，但 Brave 自己也有几百个，所以上千个也不会让他吃惊。没有人能说清楚每一个特征为什么存在。

被问到 LLM 垃圾内容增多、训练数据周围的围墙越来越高，网络会怎样改变时，Pujol 略带悲观。激励机制已经变化了很长时间：先是广告，然后是广告拦截。如果 AI 答案同时拿走了访问的经济收益和声誉，那么生产内容的动力就会变薄。他年纪够大，所以更喜欢 YouTube 而不是 Netflix，更喜欢 Myspace 而不是 Facebook，因为他喜欢多样性，宝石与垃圾混在一起。他说，AI 不会是杀死网络的那个东西，但它是离他成长时那个网络又远了一步。便利总是有代价的。答案不是知识；问题才是知识，答案只是答案。一个什么问题都能回答的神谕，就是一个其他一切都不存在的世界。

正是这种便利，迫使谷歌推出 AI 答案，也让 Brave 感受到同样的压力。这并不便宜。他们每天服务约 2,700 万至 3,000 万次查询，其中 10% 至 30% 经过大语言模型。一次摘要通常最多占用 4,000 个 token 的上下文窗口。一切都是自托管的，既是为了独立，也是因为第三方大语言模型的账单会贵到无法承受。目前，大模型部署在亚马逊的 28 块 H100 上，另外还有更多 GPU 用于更小的问答模型和分类器。他说，规模很大，但没有人们想象的那么夸张，而且还没有贵到需要改变商业模式。为运行大语言模型而把搜索基础设施翻倍，没有宣传所说的那么新奇：搜索引擎从来就不便宜。谷歌承受得起。更难的问题是，大多数搜索用户是否真的想要一个聊天机器人挡在前面。一旦你要为大众提供“自来水”式的服务，你就不能像面对小规模、自我筛选的受众那样随意实验了。

Search API 的出现，是因为 Brave 终于不再需要必应了。在发布之初，搜索引擎可以独立回答 87% 的查询，其余的交给必应。这个比例逐步提高到 90%、92%、93%、94%，再往后又高了一点，在本期节目录制前一年多，他们才完全离开了必应。只有到那时，他们才能出售 API，因为必应的条款不允许转售。Pujol 数了一下，公开的选择有：谷歌的 Custom Search（每天上限 1 万次查询，用于站内搜索，不适用于生产环境），以及微软的付费 API。Brave 的差异化在于：公开的、按量付费的 API；更宽松的条款（不要求署名，结果可以随意混合）；以及更多的返回内容。Labenz 的 Colab 对比发现，对于一个要求十条结果的查询，Brave 返回的原始字符数，往往是谷歌或必应的好几倍，因为多了额外的片段和结构化数据。他真正会用的摘要级别，是每千次查询 9 美元，而可比的必应级别是 25 美元，便宜了 60% 以上。

Brave 这么做，并不是为了单纯地堆出数据量。数据里不能有噪声，这才是约束。动态片段生成本来就会产出多个候选，由问答模型打分；超过某个阈值之后，Pujol 问：为什么还要扣下不给？额外的片段让开发者可以自己选择、填充提示词，或者挑拣内容。真正的秘诀不在大语言模型，而在这种挑选：他们把 Mixtral 换成 Llama 3 几乎转眼之间就完成了，而时间都花在了如何把不重复、不矛盾的信息喂给提示词上。他不会点名客户。在竞争激烈的市场里，大多数客户都禁止这样做；也有一些大公司用这个索引来训练基础模型。他喜欢的一种模式是 grounding（基础化）：把大语言模型的输出切分开，再拿回搜索中去验证其中的论断是否站得住。他向开发者推荐的演示，是一个用 LangChain、Brave 和 Groq 拼起来的 YouTube 与 GitHub 版 Perplexity 克隆。他说，目标很简单，就是让人多一个搜索 API 可以选。