RAG 真是一个特别糟糕的概念

推荐语

Chroma创始人Jeff Huber犀利批判RAG概念，揭示AI应用构建的真正关键——Context Engineering。

核心内容：
1. Chroma的创业理念与现代化AI搜索基础设施定位
2. RAG概念的缺陷与Context Engineering的重要性
3. AI应用从Demo到生产级系统的实践方法论

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

知名科技播客 Latent Space  昨天采访了 Chroma 的创始人 Jeff Huber。AI 开发者应该熟悉 Chroma，它是一款全新的 AI 原生开源嵌入式向量数据库。

在这次访谈中， Jeff Huber 详细分享了他们的创业理念，并批判了当下时髦的概念 RAG，它认为 RAG 的概念很糟糕，让人们忽略了应用构建过程中最关键的问题是什么。

他很推崇 Context Engineering，并认为，目前做得比较好的 AI 初创公司真正擅长、最核心的一件事就是 Context Engineering。这让我想起了 Manus 之前的一些分享。确实，Context Engineering 越来越重要。

这篇采访信息密度很高，推荐做 AI 应用的朋友精读。下面是全文翻译。虽然有 GPT 的帮助，但翻译一篇这样的文章，仍然需要 3 个小时。所以一个小小请求，欢迎大家关注我们的公众号。

Jeff Huber：这是个好问题。其实介绍产品时总要根据听众调整表达。

我觉得 Chroma 创立的原因，是因为我们在应用机器学习领域工作了很多年，发现做一个 Demo 很容易，但要把它变成真正可靠的生产系统却极其困难。Demo 和生产之间的差距，完全不像是正常的工程问题。

当时感觉更像是在玩炼金术，就像漫画里的梗：一个人站在一堆冒着热气的垃圾上，另一个人问，这就是你的数据系统？他说，是的。对方接着问，你怎么知道它好不好？要怎么让它更好？回答是，你就随便搅一搅，然后看看会不会变好。

这种状态本质上是错的。我们在 2021、2022 年时就在讨论这些问题。

我们一直想做的是帮助开发者用 AI 构建生产级应用，让从 Demo 到生产的过程更像工程，而不是像炼金术。做数据库并不是支线任务，而是主线任务的一部分。

在这个过程中，我们意识到搜索其实是构建 AI 应用的关键工作负载之一。它不是唯一的负载，但绝对是非常重要的负载。

而且你要先把某一件事做到世界级水平，才有资格去做更多事情，这需要疯狂的专注。所以这就是过去几年我们真正专注在做的事。

这可能是个有点冗长的介绍，不过总结一下，如果有人问今天 Chroma 在做什么，我们就是在为 AI 应用构建检索引擎，搭建现代化的 AI 搜索基础设施。

主持人：我想追问一下，在你看来，信息检索和搜索是一回事吗？还是稍微有点区别？我只是想澄清一下术语。

Jeff Huber：是的，我觉得可以稍微拆开解释一下“现代 AI 搜索基础设施”。

现代相对的是传统，主要是指现代分布式系统。在过去五到十年里，出现了一些新的原语和构建分布式系统的方法，而这些显然不存在于更老的技术中。

比如读写分离、存储和计算分离。Chroma 是用 Rust 编写的，采用租户架构。我们在 Chroma Cloud 的分布式版本里，也把对象存储作为关键的持久层和数据层。这就是“现代 AI 搜索基础设施”中现代的意思。

而 AI 的话，我觉得有四个层面的不同。

第一，用来做搜索的工具和技术不同于传统搜索系统。第二，工作负载也和传统搜索系统不同。第三，开发者群体也不同。第四，消费搜索结果的用户群体，同样和传统搜索系统不一样。

想想传统的搜索系统。最后一步是由人来完成的，你要判断哪些结果相关，点开新标签，自己总结，等等。以前这是人来做的，但现在是语言模型来做。

人类只能消化十个蓝色链接，而语言模型可以消化数量级更多的信息。这些差异都会影响系统的设计方式和定位。

Jeff Huber：创业的方法有很多，不同的人有不同的流派。一种创业流派，就是不停观察用户的反应，哪里有需求就往哪里靠，像是一步步跟着用户的偏好走，这就是典型的精益创业方法。

但我对这种方法的批评是，如果完全照着它走，你最后大概率会做出一款给初中生用的约会软件，因为这就是人类最底层的需求体现。在 AI 领域里，对应的可能就是老虎机式的应用。

而另一种创业流派，是坚持一个非常坚定的观点，往往是逆势的，或者是别人还没意识到的秘密，然后疯狂专注地去做。我们一直选择的是第二种方式。

当时也有另一种选择，比如说单机版 Chroma 已经做得很好，有大量流量，很明显用户也想要托管服务。我们完全可以快速上线一个产品，但我们觉得这样做达不到我们对开发者体验的标准。

我们希望 Chroma 的品牌是和卓越的开发体验绑定在一起的，我们希望大家一提到 Chroma，就会联想到精致、优秀的产品。

如果只是把单机版作为托管服务推出，那根本达不到我们心目中的标准。所以我们决定，宁可花时间，也要去构建我们认为正确的东西。

这过程非常难，花了很久，但我很自豪的是今天它终于存在，并且正在服务数十万开发者，他们也真的很喜欢它。

主持人：但走到这一步确实不容易。在组建团队时，你是怎么传递这种愿景的？比如说一年前，如果有人要加入 Chroma，他们也可以去很多其他公司。

外部环境里，还有 PgVector 这种现成的东西，或者各种热门的新工具。你觉得坚持愿景，反而能吸引那些更认同公司使命的人吗？能不能聊聊在早期招人的一些经验？

Jeff Huber：我觉得这是康威定律的一个上游版本。公司组织架构其实是公司文化的产物，你的组织架构是文化的下游体现。我们一直非常重视团队里的人，重视他们和公司文化的契合。

我认为未来增长的曲线，完全取决于现在在办公室里的这些人。这有可能意味着增长归零，也可能是线性增长，或者是超级线性增长、指数式增长。所以我们决定非常慢地招人，而且极度挑剔。

我也不敢说这一定是对的，但我之前参与过几次创业，这次我更在乎的一点是，我想和那些我真心喜欢共事的人一起工作，愿意和他们在战壕里并肩作战。

同时，他们还能独立做到我们欠开发者的那种工艺水准和质量。这就是我们选择的做法。

Jeff Huber：没错，Chroma 一直是因为开发者体验好而出名的。我不确定我们是不是第一个做到的，但至少在 Chroma 这里，你只需要 pip install chromadb，然后就能直接用。

主持人：一开始就是内存里的数据库，对吧？我记得后来好像能持久化。

Jeff Huber：我们是第一个能直接通过 pip 安装的数据库。

主持人：严格来说，SQLite 的一些封装也能 pip 安装啦。

Jeff Huber：但 NoSQL 数据库以前都不是这样，到现在很多也不是。这种方式给新用户带来了非常顺滑的上手体验。因为他们只要敲一行命令，就能直接用。

我们当时做了大量工作，确保无论你在什么架构或环境里部署，它都能跑起来。

早期有些用户甚至把它跑在 Arduino、PowerPC 这种小众架构上，我们都会尽力去支持，确保它在任何环境下都能正常运行。这就是单机版 Chroma 的特点。

所以我们在做云产品时，也希望开发者体验能保持一致。就像你用 pip 装好 ChromaDB，5 秒钟就能跑起来，不用学习一堆复杂的抽象和 API，云端也应该做到同样的体验。

我们不想让用户被迫去考虑要多少节点、节点大小、分片策略、备份策略、数据分层等等。这些都不该让开发者操心。

它必须是零配置，始终快速，始终成本可控，始终数据实时，不论你的流量和数据规模怎么变化，用户都不用去操心。这就是我们当初的设计标准。

另一个重要点是按使用量计费，这特别公平。我们只收取你实际用到的那部分最小计算资源，多一分都不会收。

不是所有无服务器数据库都能做到这一点，但在 Chroma 里，我们确实只收取你真实消耗的部分。这也是我们设计时确立的标准之一。

主持人：这实际上意味着，你们也在构建一个无服务器计算平台。

Jeff Huber：对，没错，这也是我们设计 Chroma 分布式架构时的核心动机。Chroma Distributed 和单机版在同一个代码仓库里，完全开源，用的是 Apache 2 协议。

控制平面和数据平面也是完全开源的。Chroma Cloud 就是基于 Chroma Distributed 搭建的服务。

用户注册后，30 秒内就能建库、导入数据并开始查询。在录制这个节目的时候，新用户还能拿到 5 美元的免费额度，这足够你导入 10 万份文档并查询 10 万次。

对很多用例来说，这甚至意味着可以免费用上几年。要做到这一点，我们做了大量底层的艰苦工作。

主持人：我觉得以后每个博客都应该有语义索引。比如你把个人博客放在 Chroma 上，为什么不呢？

Jeff Hube：是啊，毕竟“组织全世界信息”的使命到现在还没有真正被解决。哈哈哈哈。

Jeff Hube：我觉得在一个新市场刚刚出现的时候，最重要的就是要有好的抽象和原语，让人们能用这些抽象去理解和思考这个东西。

AI 在这波热潮里，出现了太多被随意抛出来的抽象和概念，结果让很多开发者反而没法清晰思考：这到底是什么？该怎么组合？能解决什么问题？什么才是真正重要的？我应该把时间花在哪？比如 RAG 这个词，我们从来不用。

主持人：我其实很讨厌 RAG 这个词。我能说我之所以不再用 RAG，部分是受你影响。

Jeff Huber：谢谢。我觉得 RAG 本质上只是检索。它把检索、生成、结合三个不同的概念硬拼在一起，结果特别让人困惑。而且 RAG 后来在市场上被包装成拿 Embedding 做一次向量搜索，这其实是误解，也很肤浅。

我之所以特别兴奋，是因为 Context Engineering 这个概念，算是 AI 工程学的一部分。Context Engineering 的任务，就是在每一步生成时，决定上下文窗口里应该放什么。

这里有两个循环：一个是内循环，决定这一次上下文里该放哪些内容；另一个是外循环，随着时间积累，逐渐学会如何越来越好地选择信息，只放最相关的。

我们最近发布了一份关于 Context 的技术报告，报告里面比较详细地讨论了这样一个现象：LLM 的性能会随着使用的 Token 数量变化而变化。

当使用越来越多的 Token 时，模型能够关注的信息就会减少，推理能力也会变弱。我觉得这很好地说明了问题所在。因为存在 Context Rot（上下文腐烂），所以我们需要 Context Engineering（上下文工程）。

坦白讲，现在所有你能想到的，做得比较好的 AI 初创公司，他们真正擅长、最核心的一件事就是 Context Engineering。

主持人：我感觉很多文章在讨论 Agent 和非 Agent 的区别，好像 Context Engineering 更适合和 Agent 结合。你会去做这样的区分吗？还是你就是单纯从 Context Engineering 的角度去看？

Jeff Huber：关于 Agent 确实有一些有趣的推论，比如 Agent 能不能从交互中学习。但这在一些静态的知识库类场景里（比如聊天、文档）可能就不太相关。

不过另一方面，我觉得即使是聊天或文档的场景，也应该能通过更多交互而得到改进。

我个人不会去刻意区分 Agent 和非 Agent。说实话，我到现在也不知道 Agent 这个词究竟意味着什么。不过这些原始的抽象和词语确实很重要。只是我真的不清楚，这个词到底指的是什么。

主持人：我也不知道？外面确实有很多不同的定义，我也尝试过去理解。

Jeff Huber：大多数可以被随便解释的词，其实只是人们投射自己希望和恐惧的载体。我觉得 Agent 这个词完全也是如此。

主持人：那我们也许应该在 Context Engineering 上更简洁、更精确一点，让它真正有意义，并且能被大家拿来使用。我特别想提一下 Context Engineering，或者说 Context Rot 这个话题。

我发现很多模型的营销都在强调关键信息检索测试，几乎每个前沿模型一出来，就会放出那种全绿，完美的图表，展示在一百万个 Token 范围内的完全利用率。我想知道你们怎么看这种营销手法？

Jeff Huber：那我稍微往前说一点，我们之所以开始做这方面研究，其实是从 Agent 学习入手的。我们很好奇，能不能让 Agent 获取之前的成功经验或失败经验？如果能做到，那是否会提升 Agent 的表现？

我们当时研究了几个不同的数据集，包括 SWE-Bench。在多轮 Agent 交互中，我们发现了一些有趣的现象：当我们把完整的对话窗口提供给模型时，Token 数量会急剧膨胀，结果导致一些明明写在里面的指令被忽视，根本没有被执行。

我们当时就觉得，这明显是个问题。其实这在业内人士之间已经成了一种共识的黑化，大家都知道。但研究社区之外的人并不清楚。

所以当我们发 Context 技术报告时，很多研究人员的反应是：对啊，我们早就知道了，这没问题。但其他人完全不知情。如果能把今天能做到什么，不能做到什么讲清楚，帮助大家去构建东西，那不是挺好吗？

我也不责怪这些实验室。毕竟模型研发竞争太激烈了，大家一定会挑自己最擅长的基准来训练，然后再用这些结果去做宣传。很少有人愿意主动站出来说这是我们模型的优点，那是缺点。

我能理解为什么这些问题没被公开报道。但确实，当时那种宣传暗示就是：看，我们的模型在这个任务上是完美的。

在关键信息检索测试里，大家给出的暗示就是：既然模型能做到这个，那上下文窗口你可以随便用。可现实情况是，现在根本不是这样。我当然希望有一天能变成那样，但今天还远远不行。

主持人：对，在 YouTube 视频里，有人放了你们《Context Rot》报告里的图表。

在我看来，如果用曲线下面积来衡量整体表现，Sonnet 4 是最好的，其次是 Qwen3，而 GPT-4.1 和 Gemini Flash 在上下文长度增加时衰减得更快。

Jeff Huber：我没什么特别的评论，那就是我们在这个具体任务上的发现。至于它在真实世界的实际任务中会不会也一样，那是另一回事。比如开发者对 Claude 的喜爱程度很高，或许这两者之间也存在某种关联。

主持人：是的，如果结果确实如此，那可能就很好地解释了为什么会这样。

Jeff Huber：其实就是，大模型能不能遵循指令，这是不是人们真正想要的一个清晰基准？

主持人：我觉得这里没有完全回答清楚，不过我也有一个猜想：推理模型在上下文利用上可能更好，因为它们能回溯。

而普通的自回归模型只是从左到右依次生成，推理模型理论上则能回头去找之前遗漏的，需要联系起来的信息。

Jeff Huber：不过今天刚好有一篇论文，结果好像正好相反。后面我发给你。

Jeff Huber：我觉得现在还很早期。很多人其实什么都没做，更多人还是把所有东西一股脑塞进上下文窗口，这是目前最流行的做法。

他们会把模型已经处理过的代码片段或上下文缓存起来，下次用的时候直接取结果，不用重新跑模型。这样能节省计算成本、提升响应速度。

但缓存只能解决效率问题，没法解决质量问题。上下文窗口太大，模型注意力分散，推理能力下降，这是缓存解决不了的。

问题本质上其实很简单：假如你有 n 个候选片段，但上下文窗口里只有 y 个位置，你需要从一万个、十万个甚至一百万个候选片段里挑出二十个最重要的。

这其实就是一个经典的优化问题，在很多应用和行业里都存在过。当然，用什么工具去解决，这方面现在还很早，很难下定论。但我可以说说目前看到的一些模式。

有一种常见的方法叫第一阶段检索。思路很简单，就是先用一些筛选手段，把候选范围快速缩小。比如可以用向量搜索（看语义相似度）、全文搜索（关键词匹配）、或者元数据过滤（按照时间、作者、标签之类的条件）。

这样一来，如果你原本有一万个候选片段，可以先过滤到三百个。然后再让大模型对这三百个片段重新打分、排序，最后挑出大概三十个最相关的。

我看到很多团队现在都在用这种方式，效果比大家想象的更好，而且成本很低。有些人自己跑模型，一百万个输入Token 的成本才一分钱，输出 Token 基本不花钱，因为用的都是最简单的模型。

主持人：这些是专门的小模型吧？不是完整的大模型？

Jeff Huber：其实他们就是直接用大模型来做 re-rank。当然，也有专门的小型 re-rank 模型，理论上更便宜也更快，因为体量小。但我看到的趋势是，很多开发者已经会写 Prompt，他们干脆把这个能力用在重排上。我觉得这会成为主流做法。

我甚至觉得，专门的 re-rank 模型未来会慢慢边缘化。它们不会消失，但只会在极端规模、极端成本场景下才需要。就像硬件一样，大部分时候 CPU 或 GPU 就够了，只有极少数情况才会考虑 ASIC 或 FPGA。

re-rank 也是同样的道理。随着大模型便宜上百倍、上千倍，人们就会直接用大模型来做重排，暴力筛选会变得特别普遍。

当然，今天如果要并行跑三百个大模型调用，即便成本不高，也会遇到尾延迟和 API 稳定性的问题，所以现在在生产里还不太现实。但这些障碍会随着时间逐渐消失。

我觉得这是过去几个月才刚刚冒头的新趋势，目前只是在最前沿的开发者里流行，但它会很快成为主导性的范式。

主持人：我们之前也聊过代码索引的问题。其实刚才说的这些方法也能用在各种上下文场景上，只不过代码算是一种比较特殊的语料，需要做索引。

我们做过几期节目，Claude Code  的同学提到过，他们不会对代码库做 Embedding 或索引，而是直接提供工具，用工具来做代码搜索。

我也在想，Agent 的上下文检索该怎么设计：是让一个 Agent 调用很多子 Agent（做递归的重排和总结），还是把工具都塞到一个 Agent 里？你怎么看？

Jeff Huber：索引本质上就是一种取舍：当我们建立索引时，其实是用写入性能换取查询性能。写入会变慢，但查询会更快，尤其在数据集变大的时候很重要。

比如我只是在搜一个小代码库，十几个文件，那完全可以不用建索引。但如果要搜索整个项目的所有依赖，就得靠索引。否则你在 VS Code 或 Cursor 里搜 node_modules 文件夹，会非常慢。索引就是通过这种取舍来换效率。

Embedding 一般用来做语义相似度。但其实，Embedding 就是一种信息压缩的通用方式，可以用在很多地方。我觉得代码里的 Embedding 还处在很早期，也被低估了。

与此同时，正则表达式依然是很有价值的工具。我们在 Chroma 里（无论是单机还是分布式）都原生支持正则搜索，因为它对代码搜索特别好用。我们还专门做了索引优化，让正则搜索在大数据量下也能跑得很快。

另外，我们还给 Chroma 加了“forking”功能。你可以在一百毫秒内复制一个已有索引，几乎不花钱。然后只需要把改动过的文件更新到新的索引里，就能保持数据集的最新状态。

主持人：所以结果就是非常快速的重新索引。

Jeff Huber：没错。这样的话，不同的提交、分支、版本标签都能很快很便宜地搜索。这就是我对正则、索引和 Embedding 的看法。说到底，它们都是工具，边界一直在变化。如果有人告诉你他已经有最终答案了，那最好别信。

技术的边界还在不断推进。我觉得任何声称自己有最终答案的人，都不要听他们的。

主持人：当你说代码 Embedding 被低估时，你是怎么想的？

Jeff Huber：大多数人只是拿一些在互联网上训练的通用 Embedding 模型来用在代码上。它在某些场景下效果还行，但在所有场景下都表现得很好吗？我不这么认为。

另一种思考这些不同基本工具的方式是理解它们各自擅长什么。从根本上讲，我们要做的就是从噪音里找到真正有价值的信息。

比如我在 Google Drive 里找一份投资人名单的表格，因为我知道它的名字就叫 cap table，所以我直接搜“cap table”就能找到。像这种情况，全文搜索就很完美。

但如果换作你来找，你可能会输入“有所有投资人名单的表格”。这时候就得靠语义搜索，embedding 才能帮你在语义空间里匹配到目标。

所以我觉得，这些只是不同的工具。要看是谁在写查询、他们对数据的熟悉程度，来决定哪种工具组合才是最合适的。

拿代码来说，我估计今天大概 85% 到 90% 的查询用正则就够了。谷歌代码搜索、GitHub 代码搜索的主力模式都是正则。

但在此之外，用 Embedding 还能多榨出 5% 到 15% 的改进。很多成熟团队都会在代码搜索的技术栈里加上 Embedding。

而且别以为他们是在乱花钱。他们能从中得到额外的价值。要做到行业顶尖、服务好用户，这就是差别所在。

AI 里，做到 80% 的效果很容易，但从 80% 提升到 100%，所有的难度和工作量都在这里。每提升一个百分点，都是用户真正关心的，也是你在竞争中加分的地方。

Jeff Huber：我觉得这里面确实有点直觉。我们今天做事的方式，在五到十年后回头看，可能会觉得非常粗糙。为什么我们不直接回到自然语言？为什么我们不把 Embedding 直接传给模型，让它们直接在潜在空间里工作呢？

主持人：对啊，只要有一个很薄的中间层就行了。

Jeff Huber：所以我觉得未来的检索系统可能会有几个特点：

第一，它们会一直停留在潜在空间里，而不是再回到自然语言。第二，以前的模式是“一次检索对应一次生成”，你先检索一遍，然后模型再生成一段输出。

但为什么不能边生成边检索，根据需要随时去查？这其实已经开始出现一些研究了，挺让人兴奋。比如前阵子 GitHub 上有篇论文叫 RAGAR（名字不太好听），他们就尝试教模型自己学会在内部推理时随时检索。

主持人：这其实就是所谓的检索增强语言模型（retrieval augmented language models），但不知为什么，这些工作好像都没那么受欢迎。

Jeff Huber：是啊，我也不太清楚为什么。这类方法经常有一个问题，要么检索器要被冻结，要么语言模型不能更新，语料库也就不能改动。这对大多数开发者来说，体验太差了。

主持人：我觉得如果提升真的足够大，我们还是会去做的。

Jeff Huber：不过实验室并不希望这么做，我也不太确定。

主持人：因为实验室有很大的影响力。

Jeff Huber：对，影响力很大。我觉得还有一点，就是做这些事并不会带来成绩，也没人会在意，也不会因为解决了这个问题就奖励你。

所以我觉得有两个方向值得关注。

第一是持续检索，如果它能真正出现，会很有意思。第二是停留在 Embedding 空间里，也会非常有价值。

还有一些和 GPU 有关的东西，比如怎么把信息分页放进 GPU 内存里，我觉得未来可以做得更高效。这大概是 5 到 10 年之后的事。但我相信回过头来看，我们今天的做法会显得特别粗糙，甚至有点好笑。

你之前说过，记忆其实就是 Context Engineering 带来的结果。我记得你在 X 上提过，不要把记忆搞得太复杂。那你是怎么理解记忆的？

Jeff Huber：我觉得记忆这个词很好，大家一听就能明白。这其实就是继续把 LLM 拟人化的一种方式。

我们人类很清楚自己是怎么用记忆的。很多人很擅长利用记忆来学习，然后还能把学到的知识灵活应用到新环境。

想象一下，我们能和一个 AI 并排坐下，花十分钟或者几个小时告诉它我们想让它做什么。它先做了一遍，我们说下次改成这样。就像我们教一个人一样，最后 AI 就能学会了，而且可靠性和人差不多。

这是一个非常吸引人、令人兴奋的愿景。我相信这会实现。

而且记忆是一个人人都能理解的词，我们的母亲也能理解。记忆的好处也非常有吸引力。但记忆的本质是什么，还是Context Engineering，说到底就是如何把合适的信息放进上下文窗口。

所以可以把记忆看作一种好处，而Context Engineering是带来这种好处的工具。当然可能还有别的方式，比如通过强化学习结合数据改进模型。所以我不是说 Context Engineering 是唯一能提升表现的工具，但它确实是非常重要的一部分。

主持人：你觉得模型的生成式记忆（Synthesizing the memory，比如模型根据对话自动归纳用户偏好）和提示式记忆（开发者显式告诉模型要记住哪些信息）有很大区别吗？

Jeff Huber：我觉得它们背后依赖的都是同样的数据。同样的反馈信号既能告诉你该怎么更好地检索，也能告诉你该记住什么。所以这其实不是两个不同的问题，而是同一个问题。

主持人：我更困惑的是记忆的结构到底该是什么样的。很多人会拿人类作比方，比如长期记忆、短期记忆，甚至有人想借用睡眠的概念。

我觉得模型可能确实需要某种批处理周期，或者垃圾回收周期，就像是让它“睡一觉”。但我不确定哪种方式合理。

我们现在做的很多类比，其实都是按照人类的认知来想的，但 AI 可能完全不是这样。你有没有看到什么真正有效的做法？

Jeff Huber：我一直会有点担心，因为一旦我们开始创造新的概念和缩写，不久就会有人画出一张信息图，上面写着十种记忆类型。可问题是，仔细一看，它们其实差不多，只是硬被区分开了。

主持人：但有时候还是得让人眼前一亮啊。

Jeff Huber：我觉得没必要硬去造新词。相比之下，压缩这种概念才是真的有用，而且一直以来都证明了它的价值。

主持人：数据库里也有。

Jeff Huber：对啊，在你电脑的数据库里也是。我们都记得在 Windows 98 年代跑磁盘碎片整理。所以离线处理显然是有用的，我认为在这个场景下也同样有价值。

就像我们之前说的，索引的目标就是用写入时的性能去换查询时的性能。压缩也是工具箱里的一个方法，它同样属于写入优化，你其实是在重新整理数据。

主持人：这听起来不像索引，但其实也算是一种索引。

Jeff Huber：可以理解成再索引。你会重新处理数据，比如把两个数据点合并，或者拆开，或者重写，或者从中提取新的元数据。

我们要观察应用的反馈信号，判断模型是不是在记住正确的东西。背后的理念是，会有大量的离线计算和推理在后台运行，帮助 AI 系统不断自我优化。

主持人：我们之前聊过所谓的“睡眠时间计算”，其中一个想法就是让模型在空闲时提前计算答案。基于现有的数据，预测用户可能会问的问题，然后把这些答案提前准备好。

Jeff Huber：三个月前我们发布了一份技术报告，名字叫《生成式基准测试》。核心观点是，建立一个黄金数据集非常有价值。所谓黄金数据集，就是一组查询和对应的正确片段。

有了它，你就能对比不同的检索策略，比如某个策略能覆盖 80% 的片段，而换个 Embedding 模型可能能做到 90%。这样你就知道后者更好。

当然，在做工程决策时，还要考虑成本、速度、API 的稳定性等因素。但至少你能有数据来衡量系统的变化。

我们发现开发者往往有数据、有片段、有答案，但缺少查询。所以我们写了一整份报告，研究如何教大模型根据片段生成合适的查询。因为你需要的是片段和查询成对的数据。

如果你只有片段，还需要相应的查询。人类当然可以做一些标注，但人工往往不一致、容易偷懒，QA 也很难。所以我们尝试让大模型来做这件事，并验证了一种可行的策略。

我认为生成问答对对检索系统的基准测试非常重要。而且在很多情况下，这套黄金数据集也能直接用来做微调。所以我觉得这方面的价值一直被低估了。

主持人：是啊，我也很认同。我觉得虽然最近大家都在关注那篇关于上下文的论文，但对我来说，生成式基准测试才是真正让我眼前一亮的东西，因为我之前从来没接触过这个概念。

而且我觉得更多人可以把它应用到自己的实际场景里。相比之下，上下文腐烂的问题更多是提醒大家不要太迷信模型，但除了做好上下文工程之外，你也没太多办法。

而生成式基准测试不一样，它是在告诉你要自己生成评测数据。这样你自然会需要数据集，也会自然而然去遵循业内倡导的最佳实践。我觉得这是很棒的工作。

Jeff Huber：我在做机器学习开发工具这条路上已经十年了，有一点特别深的体会：小而高质量的标注数据集回报特别高。大家总觉得必须要有上百万条数据，其实不需要。就算只有几百条高质量的样本，也能带来非常大的价值。

我常跟客户说，你完全可以定个计划，周四晚上团队全员到会议室点个披萨，搞一场数据标注派对，几个小时就能完成一批高质量数据。

我经常跟客户说，我们应该对自己的团队说，周四晚上大家都到会议室来，我们点些披萨，开一个数据标注派对，干上几个小时。

主持人：就靠这个就能启动了。谷歌在做，OpenAI 在做，Anthropic 也在做。你们也该做这个，不要觉得自己高人一等。

Jeff Huber：对，没错。归根结底就是要看你的数据，重点是要做好标注。

Jeff Huber：对啊，多到数不过来。说起来可能有点老套，但要做到真正自省、诚实面对自己其实挺难的。

我觉得人生很短暂，就像风中的一缕烟雾，所以只去做自己真正热爱的事，只和自己喜欢的人一起工作，只去服务自己真心想服务的客户，这对我来说就是一颗北极星。

当然，这可能不是那种能让你快速赚大钱的北极星。也许还有更快的办法能让你骗来五百万美元之类的。但如果回头看我的经历，我总是在做取舍：和同事之间的取舍，和客户之间的取舍，和技术之间的取舍，包括我对它的自豪感。

可能跟年龄也有关系吧，但随着时间推移，我越来越想把工作做到最好。我希望这份工作不仅本身很好，还能被尽可能多的人看到，因为那才是真正的影响力。

影响力不是你发明了个了不起的东西却没人用，而是你发明的东西被尽可能多的人使用。

主持人：你的这些想法，会不会和宗教，尤其是基督教有关？如果这个问题太敏感，我们可以跳过。我之所以问，是因为我觉得你是硅谷里为数不多的公开表达信仰的人之一。我自己不是很虔诚，但我很好奇这是不是影响了你怎么看待影响力、怎么看待自己的选择。我刚才听你说话时，感觉里面有一点信仰的影子，所以想追问一下。

Jeff Huber：我觉得现代社会越来越虚无主义了，什么都不重要，一切都显得荒诞，像是一场闹剧。

主持人：对啊，一切都在权力的逻辑里运转，一切都像是一场闹剧，这已经成了普遍的主题。

Jeff Huber：没错。现在很少有人会真心去思考人类的繁荣究竟是什么样子。更少有人愿意为此做出真正的牺牲，去推动一些自己可能一生都看不到完成的事业。过去，人们还会发起一些要耗费几个世纪才能完成的工程，而如今，这样的事已经越来越少了。

主持人：我想到的就是巴塞罗那的圣家堂，大概三百年前就开始修建，而到明年终于要完工了。

Jeff Huber：是啊，我之前去的时候还在施工，我也很期待明年能看到它完工。

主持人：不管怎样，我觉得你是我认识的少数公开表达信仰的人之一。而且我认为你们做的事情是有益的，我也希望能看到更多这样的力量。

我觉得人应该去相信一些比自己更大的东西，去种一些树，即使自己一辈子都坐不到树荫下。我是不是把这句话说错了？它其实是圣经里的话吗？

Jeff Huber：我觉得不一定出自圣经，但我喜欢这句话，我完全同意。

主持人：我真的觉得，当社会沦落到人人只为自己而活的时候，那才是彻底的崩塌。

Jeff Huber：这是文化的一部分。我觉得所有的价值观最终都会体现在这些细节里。这和康威定律类似，从某种意义上说，创始人最在意的东西，往往会成为公司做到极致的部分。

我本人对这方面特别在意，所以在一定程度上，这确实来自我。但我不能把所有功劳都揽到自己身上，我们也有机会和非常有才华的设计师合作，而且我们还在招聘。如果有人听到这段对话有兴趣，可以来申请。

我觉得，这有点像老生常谈，引用 Patrick Collison（Stripe 联合创始人兼 CEO）的话，他说：你做一件事的方式，其实就是你做所有事的方式。我不确定这是不是他的原话，更像是一句广为流传的格言。

这句话的意思是，你要确保在各个环节都能保持一致的体验。就像你刚才说的，如果你来到我们的办公室，你会感受到一切是用心和有意图的；你打开我们的网站，你会有同样的感受；你使用我们的 API，或者经历一次面试流程，也能感受到同样的风格。

这种一致性很容易丢失，一不小心就会消失。而保持它的唯一方法就是坚持把标准守住。我觉得这也是我作为创始人能为公司做的最重要的事之一。

虽然这么说有点别扭，但创始人确实需要成为公司的品味把关人。这并不是说所有东西都要经过我审批才能发布，而是至少要确保不会出现风格分裂。

否则，就会变成每个人都有自己对好的理解，各自放大，结果品牌变得支离破碎。

主持人：你有一个很强大的能力，就是能把原则、价值观和思考方式表达得非常直接而清晰。我觉得你做的每件事里都有这种特质。我已经关注你的工作一段时间了，一直很佩服。

Jeff Huber：谢谢。