这些数据大多从未进过数据库：Chroma 战时 CTO 谈 RAG

Nathan Labenz 在 2023 年 10 月的这一期《认知革命》开场，请回了 Chroma 联合创始人兼 CTO Anton Troynikov。他们第一次对话是第 5 期，发布于 3 月初，那时还没有 GPT-4。此后八个月里，检索增强生成已经超过智能体，成为最热门的应用趋势：各家公司纷纷搭起以文档为基础的机器人来省人力，而数量几乎一样多的公司首次部署了向量数据库。Labenz 把上一次录制当作嵌入和潜在空间的入门课；这次他想听的是所有变化，包括 Chroma 作为一门生意的变化。

他一开始的疑问是：既然老牌数据库厂商都在抢着推出自家向量存储，Chroma 和其他向量数据库创业公司会不会很难成长。Labenz 说，Troynikov 很好地提醒了他自己的一条座右铭：很可能每个人都还想得太小了。给他留下印象的观点是，存进 Chroma 的大部分数据以前从未进过数据库。这意味着，至少在一段时间里，基础设施层仍有很大的增长空间，哪怕许多老牌厂商都来入局。

公司的计划是把更多的检索栈收进数据库，直到使用它就像把文字丢进一个框里那么简单，这与人们已经在使用聊天机器人的方式并无二致。Labenz 把 Troynikov 描述为一位战时 CTO，也是真正的思想领袖，他对 LLM 推理的怀疑比 Labenz 还深。Labenz 建议把这一期发给软件或 AI 工程师。访谈开始时，第一个问题是 Troynikov 推特简介里的新词。

Labenz 注意到，Troynikov 的推特账号里，“wartime”现在和一面海盗旗并排放着。这面旗子原本就在，“wartime”是后来加的。Troynikov 说，这其中有一部分是品牌包装，但心态上的转变是真实的：Chroma 有了具体目标，并承担起他认为适合创业公司的风险水平。这与探索模式不同，后者还在摸索人们到底想要什么。

这个使命已经公开到可以大声说出来。在 Chroma 的向量搜索与存储引擎之上，构建一个可水平扩展的系统，然后以云服务的形式交付，这是用户提出最多的需求。他说，团队自 3 月以来扩大了不少；他们清楚产品的形态、质量标准和差异化所在。剩下的是执行风险：他们究竟能把它做到什么程度。

Labenz 承认，差异化仍然模糊，因为他还分不清各家向量数据库厂商。Troynikov 把这看作采用曲线的产物。他估计，将来会做出“AI 在回路中”应用的人里，有 99% 还根本没有碰过它。Chroma 的用户从黑客松的新手（他们需要有人告诉他们，可以把信息注入模型），到生产团队（他们在问如何把人工反馈和评测写回数据层）。后一类团队要少得多，中间还有一个步骤：成功的实验必须以正确的方式扩展。

上手门槛是刻意设计的：pip install chromadb，或在命令行里运行 chroma run，默认设置合理，不需要选择嵌入函数，把文字丢进去就能用，这也是 Chroma 成为许多框架默认选项的原因。一台内存很大的单节点，就已经能跑数万到数十万个集合，每个集合有数百万个向量。接下来的问题是架构。大多数向量产品是为前 AI 时代的搜索场景做的索引，比如 Pinterest 式的相似图片：数据基本静态，很少删除，所有人共用一个索引。应用数据库则恰恰相反：每个用户空间一个索引，各自独立更新。他说，Chroma Cloud 会用弹性伸缩把这些隐藏起来，按查询次数加存储量收费，用户不必考虑 pod 或分片。

赞助广告过后，Labenz 问大家实际用什么来做嵌入。Troynikov 说，大多数用户对开源模型已经很满意；sentence transformer 在本地运行很简单，效果往往已经接近 OpenAI 的 Ada。如果数据已经存放在 Azure 上，Ada 仍然有优势，因为它的端点可以避免出站流量（egress），也省去了自己大规模运行模型的成本。他看到的更深层偏好不只是价格。团队希望尽可能把数据和 RAG 闭环都留在内部：不只是嵌入，还包括用为任务微调过的 Mistral 或 Llama 2 替换掉 GPT-4 的调用，这样数据就不必通过网络发送出去。他把这称为对“一个模型统治一切”叙事的拐点，并指出，反正语言模型调用才是昂贵的部分。

Labenz 自己的第一条建议是：检索的记录数不要省，把上下文窗口用起来。Troynikov 提出了异议。这已经是流行的说法，最近的研究也用实证表明：上下文窗口里的干扰信息会明显拖垮整个应用的表现，而且很难归因。你要的是每一条相关结果，同时没有一条无关的意外。这取决于对任务而言在语义上有意义的切分，而切分又取决于嵌入模型；这些环节彼此牵连。Labenz 见过 Claude 2 在满 10 万 Token 时乱了套，而在 5 万 Token 时表现正常。他的 Athena 应用，从两三个切片增加到十个，因为他更信任 GPT-4 或 Claude 2 去挑出正确段落，而不信任检索只能拿出三个。

Troynikov 会退得更远一些。先要从两个地方得到一个可靠的效果衡量：对结果做离线评测，以及在应用内收集人工反馈。只有这样，才能去拧那些老旋钮。他的经验法则是：尽可能多地放入相关信息，尽可能少地混入无关信息。没有这个衡量，他的意思是，后面的调优就只能靠猜。

Labenz 一直在试验一个介于用户查询和数据库内积运算之间的适配器。Troynikov 说，已经有人证明，仿射变换（挤压、拉伸和旋转空间）就足以把一个嵌入空间映射到另一个上。它真正做的，是放大向量的某些维度，同时压缩另一些维度。你可以重新计算每一个已存储的嵌入，也可以只计算前向变换，并只把它应用到查询上。第二条路径才有意思：同一个存储可以服务不同的应用，甚至不同的用户，每个人都有一套学习出来的变换，而无需修改任何一个已存储的向量。坐在这个数据库上的每个应用所产生的反馈，还能反向传播到一个共享的嵌入模型微调中。Chroma 打算两条路都提供。

就实际做法而言，Labenz 目前还没有微调任何东西。他用语言模型做文字到文字的转换：先生成答案可能的样子，留出占位符，再用这份假想文档去搜索。这种技术叫假设性文档嵌入（HyDE）。查询一位客户孩子的生日，作为问题效果很差，但改写成“孩子 A 生于这个日期”这样的陈述，效果就好得多。Troynikov 指出，通用嵌入模型本来就经过训练，使查询落在答案附近；HyDE 是人工提供模型或许已经具备的性质，代价是每次查询多一次调用。如果划算，就用它。长远来看，他认为直接微调嵌入空间更便宜。

生日也指向他希望开发者认真对待的一种区分。数值事实、人名和事件，往往应当放在一张 SQL 表里，只要模型知道表结构，就可以直接查询，而不必通过有损的嵌入搜索。嵌入是给非结构化数据用的。Chroma 本来就用关系型存储来保存文档和元数据，这就是关键词过滤开箱即用的原因。把视野放大一点，问题不在于选哪种表征。关键是确保模型拥有完成任务所需的信息，并且藏在同一个接口后面，这样应用开发者就不用亲手把 HyDE 和三个数据库拼接在一起。

他喜欢打的比方是：如今的 AI 开发者相当于拿到了 Postgres 的存储引擎，然后自己去写查询规划器、SQL 解释器和块存储算法。花在这些管道工程上的时间，就是没有花在产品上的时间。Chroma 想为 AI 应用提供统一的数据接口，按需接入其他数据源的适配器，并把更多智能放进数据层，包括一个本地模型，它把“给定这个查询，找到正确的数据”当作一个强化学习里常见的决策问题来处理。针对用户指定的表格生成 SQL，显然是下一步。

Labenz 担心的是每个 AI 细分市场都有的问题：价值究竟会多大程度上流向创业公司，又会流向老牌厂商。他认为，在 Salesforce 推出自己的 AI 层之前，没有人会去重建 Salesforce；而要把已经部署好的数据库从中期开发者手里拿走，也非常困难。Troynikov 的回应正是 Labenz 之前预告过的那一点：很多情况下，进入 Chroma 的数据从未进过数据库。它们一直待在供人阅读的文档存储里。模型现在能推理大量自然语言，而计算机以前只能推理结构化表格。他不需要说服人们拆掉已经在用的数据库，只需要告诉他们，终于可以处理其余那部分数据了。

之所以谈到 Salesforce，是因为他刚读完《Softwar》，那是一本讲 Larry Ellison 的传记。Marc Benioff 曾是甲骨文的高管；Ellison 则是 Salesforce 的早期投资人。Salesforce 所做的，是围绕客户漏斗（即客户信息最早进入公司的那个节点）统一组织数据，然后在其上搭建应用平台。Troynikov 认为 Chroma 也会走类似的路，不过他承认这只是推测。公司当下的任务，是通过交付市场想要的产品，赢得在那张桌子旁的一个座位。他认为 Chroma 与众多老牌存储之间是互补关系，就像 Salesforce 和甲骨文的合作一样，前提是接口要允许人们在其上构建应用。

如今的新存量是文档，因为 GPT 是通用的文本模型。明天——他几乎是字面意义地说，“大约一周之后”——就会出现能解读图像和声音的模型，包括人们想要提炼成可操作内容的 PowerPoint 幻灯片。按纯粹的字节数计算，他认为这堆数据可以与关系型表格里的数据分庭抗礼。Labenz 自己的 Athena 工作，已经处在这股浪潮中比较乏味的那一侧：一个内部工具，用 chatbase.co 搭建，覆盖约 400 份政策文件，服务一千名行政助理。过去他们每天要收到数百个问题，现在有相当一部分可以由模型立即回答。Troynikov 说，检索和模型质量之间是一个良性循环，这也是他很高兴 Chroma 专注于这一组件、而非去训练下一个基础模型的原因。

他把组织分为三类。第一类是传统企业，把既有流程改造为适应 AI；有些会成功，并击败失败的同行。第二类是构建工具的公司，没有模型，这些工具就不会存在。第三类是正在兴起的企业：它们服务的客户与老牌厂商相同，但从一开始就围绕 AI 优先的流程来构建——他认为，最先做成的那几家会非常成功。他首先想到的垂直领域是房地产：大量依赖人力、要处理五花八门格式文档的业务。筛选的标准是分发能力。去那些你能足够快地获得分发的地方，让 AI 带来的效率真正有价值。他不会以“你用 AI，他们不用”为理由去和可口可乐竞争。

Troynikov 说，增长仍然主要来自采用曲线的前端，但用户会逐渐成熟，而 Chroma 已经在同一个产品上同时拥有生产环境中的企业、增长迅速的创业公司，以及黑客松的新手。他最自豪的一个用例，是他起初并不知道的：来自英伟达 Jim Fan 团队的 Voyager 论文，那是一个玩 Minecraft 的智能体，没有经过任何训练。他看了代码库，发现 Chroma 被用作记忆引擎。技能被存入，需要时被检索出来，不想要某种行为时还可以删除。在他看来，这正是检索作为一个完整 AI 系统的妙处，比起那些无法编辑的权重来说更胜一筹。

他也不认同智能体与 RAG 是先后出现的两股时尚。它们并不互相正交。智能体会用到检索，把检索做得更好，智能体也会开箱即用地更好。他已经在和智能体开发公司谈这件事。“好的检索，是我们让好的智能体运转起来所需要的很大一部分。”

Labenz 此前给他发过笔记，里面提到微调无法植入事实。Troynikov 粗略的心智模型是：微调决定的是你希望任务以什么样的风格、什么样的方式完成，比如该关注什么，如何归纳结论；而检索提供的才是真正的数据。他说，最新的检索增强预训练与微调论文表明，这两个旋钮是互补的：微调帮助模型利用检索带回来的内容。规模曲线依然成立。如果你没有足够多的 Token 去过拟合事实，那么通用模型加检索，就会比调参带来更多收获。这又引出了一个更大的市场问题：一个“死星”式的大模型，还是许多更小的、面向任务的模型，同时也决定了算力究竟住在 Azure 的数据中心里，还是在你自己的网络上。

在保留原始通用能力的同时，你能从模型里挤出多少知识？他目前的看法是：你要让模型看到具体的推理示例，它才能模拟推理；并不存在一个可以拿来训练的抽象推理语料库。没人知道如何把抽象的部分保留下来，同时不带上事实。他称 Anthropic 近期的电路研究是一项了不起的突破，尽管规模还很小，他也并不相信“从这里起就只剩工程问题了”。Dan Hendrycks、Zico Kolter、Andy Zou 等人推动的表征工程，是他一直在倡导的另一条路线。对他来说，理想的状态是一台 IQ 140 的机器：在你告诉它之前，对世界一无所知；然后只用你提供的那些信息进行推理，并且可以一直检查到神经元。

Labenz 问，存储和检索的对象会在多大程度上偏离人类可读的文本。Troynikov 首先听出的是安全问题，而他喜欢这个问题所暗含的控制性。商业利益与 AI 安全在这里是一致的：商业部署不会想要一个无法预测的系统。模型可能学会隐写术，或者几个模型可能通过共享存储合作，但这比把知识藏在权重里要难得多。如果存储对象本来应该是人类可以理解的文本，而他看不懂，他的本能反应是把它删掉。

Labenz 真正想问的其实更克制：与其嵌入文本、检索文档、再把它塞进上下文窗口，何不直接存向量，把数字注入模型？Troynikov 回答 100%，完全同意。返回文档、解码嵌入、再把它重新编码到另一个空间里，这是一条愚蠢而有损的路径。把向量直接送入你关心的那个空间。他不认为这会破坏可解释性，因为你依然知道每个向量来自哪里，以及它对应哪些输入和输出。

可控性依然重要。一道关口是可解码性：如果一个嵌入超出了你能解码的范围，就把它当作垃圾，删掉，或者禁止潜在空间的那一块区域。他还想打破一个观念：一串数字向量天然就是我们看不懂的东西。没有人用英文写客机的操作说明；我们之所以知道飞机会怎么飞，是因为工具跟得上。按公司的历史，Chroma 的第一个产品是一个潜在空间可视化工具。绕了一圈，他们需要把这种工具重新做进产品里，因为你没法像在 SQL 里那样，用眼睛扫一眼这个数据库的前几行。他认为，AI 领域正在消失的门槛在于：一个用自然语言交流的普通人，已经能做过去被视为高级研究的事情。他把这种威力与可及性的结合，比作早期的互联网，以及随之而来的寒武纪大爆发。

回到 Labenz 正在经历的那些实际的 RAG 问题，Troynikov 的第一步产品动作，是把 Chroma 接入合作伙伴已经在开发的评测工具。评测只有在你能据此采取行动时才有用。Chroma 正在开发一个反馈端点：连接 LangSmith 或其他评测产品，按一个按钮，就能根据这些分数自动调整嵌入空间。接下来，在整个语料库被嵌入之前，先对用户数据做子采样，并选择嵌入模型，同时利用 Chroma 已经理解的几何信息（潜在空间中的密度与分布），以及相似任务的评测结果。Labenz 的 Athena 聊天界面上，每条检索片段都有一个点赞或点踩，这正是他们想要的信号。

需要多少带标注的检索数据？至少要足够密集地构造出那个仿射变换，而这取决于嵌入的维度。高维空间可能更有代表性；低维空间则更容易用较少的数据进行微调。即便是 Ada-2 嵌入，也并非总是以满秩使用：某个语料库位于一个流形上，Chroma 可以投影到低维，在那里微调，并在数据变化时保留全维度的副本。这个投影本身也是一种学习出来的变换。为了解决这类问题，他们正在招聘一位研究负责人，其中包括把嵌入直接推入推理层这一长期设想。

还有一大堆便利性工作会改变质量。如果十二份文档彼此相邻，而检索把它们全部返回，那你什么新东西都没有拿到；最大边际相关（maximal marginal relevance）是避免重复的常用启发式方法。模型可以做得更好：根据用户真正想完成的事情，生成一份条件摘要，把冗余的那组内容压缩成一个数据点。Labenz 一直在考虑：在“检索十条”和“塞满上下文”之间，加一道更便宜的 Claude Instant 过滤器，从而节省 GPT-4 的 Token 和延迟。Troynikov 的观点是，你永远不该看到那一层，就像你不会去想 Postgres 为某个网页应用生成的查询计划一样。轻量的开源模型，运行在与嵌入函数相同的推理硬件上，是很自然的选择。

拥有这个闭环，也就意味着拥有数据飞轮：一个持续适应你的业务、而不是某个通用平均值的模型。对大多数人而言，Troynikov 同意 Labenz 的建议：从第一天起就开始收集反馈。在线微调可以等一等；大多数团队永远不会有足够的数据来持续地做这件事。但数据仍然必须留在日志里。

Troynikov 反复回到的那个观点，正是这一期的开场。人们习惯把数据看成某个时间点上静止地存放在某处的东西。他把它看作一个回路，几乎就是一个控制系统的回路：数据是一台引擎，通过计算与外部世界互动，不断地自我适应和改进。即使今天你不做微调，也要为这个回路把可用的接口留出来。

在云服务发布前后，他希望推出 Chroma Datasets：英文维基百科、彭博社、实时新闻等语料，目前每个人都在自己嵌入这些内容。调用一个端点，付几美分，就能拿到文档或向量。一旦许多应用查询同一个公共集合，Chroma 就能知道数据被送进了哪个模型、用于什么任务，于是可以为这个用途微调表征，而不是提供一个通用的嵌入。他把这些称为“活的数据集”。如果你在写新闻，那么你为彭博社数据选择的嵌入空间，不会是你为人口统计数据选择的那个，也很可能不是你为约会应用（无论高端还是普通）选择的那个。

保持真实数据行的新鲜，是与搜索索引世界截然不同的问题。在网络规模的索引中，更新和插入很少发生；而在应用里，它们随时都在以交互的方式发生。一批流式与同步工具正在兴起，把外部事件灌入存储，Chroma 一直在与 Unstructured 等公司交流，并计划支持它们。Labenz 在 Athena 上的实际烦恼更像是写日记：聊天记录应该与权威的客户档案放在一起吗？如果某个档案被更新了，是否要保留旧版本？他发现自己对人类记忆的优雅之处又有了新的敬佩。

近期，Troynikov 会用 Chroma 已经具备的启发式方法：在元数据中放入时间戳，并按日期过滤。长远来看，他希望把时间本身作为嵌入空间的一个维度，让关于过去的陈述随时间衰减，检索器在需要历史时对这条轴加权。如果你想要全部，就把时间投射成整体；如果你只想要某个时刻，就切出来。嵌入模型应当理解时间，不过并非每一个事实都适合放进向量存储——有些仍然需要一张 SQL 表。一篇来自 Max Tegmark 团队的论文发现，语言模型能表征经纬度和时间线，这并没有让他感到惊讶。对比式预训练只编码相似与差异；在层级的顶端没有第三个参照点，因此方向可以漂浮，而在较低的层里，结构则被强制地体现在较近的点之间。这也是他认为最高阶的概念会出现在网络中间层的原因。

Labenz 希望有一个数字，能在有人说近似最近邻那一步“吃掉了”某个结果时拿来引用。Troynikov 的回答是：几乎所有的失误都来自表征。ANN 在召回率与速度之间的权衡已经被充分理解，并且完全可以调节；每种算法实现的曲线都是公开的。当你的结果与那些曲线不一致时，问题出在表征上。在默认设置下，他会猜测大约是百万分之一的量级，当然还要加上常见的说明：这取决于数据分布。一个病态的 HNSW 图，如果把同一条目当作不同的行反复塞入，就会损坏索引。反正延迟主要来自模型推理，所以多花一点搜索时间去换取召回率，成本很低。在小规模场景下，你可以干脆跳过索引；Chroma 已经会自动切换到暴力搜索结构。

在合作关系上，他乐于广泛合作：LLM API 实验室，因为更好的模型让检索更有用，反之亦然；应用框架，原因相同；评测平台，通过反馈端点对接；非结构化数据的 ETL。他说，Chroma 的任务边界划得很清楚，公司已经走出了产品的最初探索阶段。

OpenAI 会不会自己做数据库？它们已经聘请了检索方面的人，开发者大会前后的预告暗示至少会有一个轻量的内部系统。他认为，它们不太可能推出像 Chroma 正在做的那种面向开发者的产品，检索引擎的基础零件也不在它们的主线上，即便检索本身对通用人工智能很重要。OpenAI 一直在较早地做企业级交易，并与检索厂商一同进入市场；Troynikov 认为这表明它们希望客户为 GPT 付费，而不是拥有存储。谷歌已经把 Chroma 列为 PaLM 2 公共 API 的首发合作伙伴，他部分归因于其开发者工具的易用性。Anthropic 提及得较少。他一直在试用 Claude 2 的长上下文和 PDF 导入功能，认为这家实验室更像一个研究试验场。训练数据的检索看起来像是老式的搜索索引场景，人们目前使用的是很难扩展的 FAISS，他预计 Chroma 会随着时间填补这一空白。

Labenz 问，Troynikov 在 AI Engineer 大会上流传的一张幻灯片之后，是否更新了他的末日概率。Troynikov 觉得这个问题几乎很好笑：说什么数字都不会有后果，所以人们就随口说些有趣的东西。他已经不再争论末日了。他真正关心的问题是，这条技术路径究竟能不能产生一个推理系统。

这个实验是从国际象棋开始的。当 GPT 从随机局面出发下得很差时，有人说它是在模仿水平差的棋手——Troynikov 觉得这个说法强得离谱，因为它意味着模型既知道规则，又知道最优解，还能以弱对手为条件行动。他于是寻找这个说法最弱的版本：康威的生命游戏。要求 GPT 给出规则，它能背出来。给它一道文字题：n 个活细胞、k 个死细胞、中心细胞是活的，问中心细胞的下一个状态——它的正确率是 100%。这至少说明它内部有一种规则的表征。然后把同样的信息以 512 种状态转移的网格形式呈现，它能背出规则，但答案却算错了，哪怕每个细胞都是一个独立的 Token。

对错已经不是重点。如果模型有规则，那么这些规则应当能跨表征适用。他给它喂了随机的 10×10 棋盘，要求只迭代一步，然后测量一致性：对于同样的局部转移，它的做法是否相同；这些做法是否与它在 512 个单独案例上执行的规则相符？在网格表征内部，它基本是一致的。但它并没有把一种表征中陈述的规则应用到另一种表征中。在他看来，这指向的是世界模型的缺失——这是一条证据、一个切入角度，而不是一个完成的论证。还有一个细节：一次转移的随机程度，取决于该状态在统计上出现的频率。越罕见的状态，输出越随机。他把这当作对它的又一记反面证据。

实际的结论并不是这项技术毫无用处。在依赖人类解读而非精确结果的领域，它已经创造了价值。如果真正强大的能力到来，那将是一台通用计算机器，而他认为我们还没有到那一步。Labenz 的第一反应是，这听起来更像一个不完整的世界模型，而不是没有世界模型，眼下的关键问题是，“通用”的程度究竟有多大。Troynikov 让他去看那条推文串。他已经不再争论末日，转而开始问更务实的问题了。