Chroma CTO 谈 RAG：进库的数据大多头一回进数据库，检索出错九成怪向量表示

2023 年 10 月的 Cognitive Revolution 节目，请回了 Chroma 联合创始人兼 CTO 安东·特罗伊尼科夫（Anton Troynikov）。他上一次做客是 3 月初，GPT-4 还没发布。这八个月里，RAG（检索增强生成）超过智能体，成了大模型第一个真正跑通的商业应用，一大批公司头一回给项目装上向量数据库。

主持人 Nathan Labenz 是带着疑问来的：老牌数据库厂商全在补向量检索功能，Chroma 这类创业公司还有多少空间？聊到最后他被说服了，关键是一句很朴素的观察：

进 Chroma 的数据，很多是生平第一次进数据库。

这句话背后是一整套增量市场的判断。这期节目还聊了检索调优的具体手法、数据层的终局想象，以及一场拿 GPT 做康威生命游戏的实验。下面拆开讲。

战时 CTO，和一条不再摇摆的路线图

Anton 的推特签名今年多了「wartime」这个词。他自己解释，一半是品牌动作，一半是心态变了：Chroma 现在目标极其明确，把向量检索和存储引擎做成可横向扩展的系统，以云服务交付，这是用户呼声最高的一件事。探索期结束了，剩下的全是执行风险。

用户结构能说明这个阶段的特点。他给了一个估计：未来会做 AI 应用的人里，99% 到今天还没动过手。Chroma 的用户，从黑客松上第一次听说 RAG 的新手，到把核心链路跑在生产环境、追问「怎么把人类反馈写回数据层」的企业，横跨整条采用曲线。

新手端拼零门槛。pip install chromadb，或者命令行敲一句 chroma run，服务就起来了，连嵌入函数都不用选，扔文本进去就能用。这也是它成了不少框架默认选项的原因。企业端拼规模：单机大内存的 Chroma 实例，开箱就能跑几万到几十万个集合，每个集合装百万级向量。再往上，全公司不同团队共用一个数据层，就得横向扩多节点。

这里有个容易被忽略的技术判断。市面上多数向量检索产品，两三年前是按搜索引擎索引设计的，服务的是 Pinterest 相似图片、网页级推荐系统这类场景。搜索索引的假设是：数据基本静态，每天新增占比很小，删除和修改很罕见，所有用户共享同一个全量索引。应用数据库完全两样：每个用户一个索引空间，各自独立扩缩，数据被交互式地频繁增删改。拿搜索索引的架构去撑应用数据库，扩不动。所以 Chroma Cloud 的形态是彻底弹性：按查询次数加存储量计费，用户不用碰服务器和分片这些概念。

检索质量：先建评测，再调旋钮

Nathan 自己就在做 RAG。他在给一家叫 Athena 的公司做顾问，这家公司有一千名高管助理，服务一千位高管客户。团队用 RAG 做了个客户档案应用，更早还用 chatbase.co 搭了个内部工具：四百份文档，每天几百个政策类提问，相当一部分现在直接由 AI 答掉。就是在这个项目里，他被检索质量反复折磨。

Anton 给的第一条建议很硬：先把评测建起来，再去调任何参数。评测有两个来源，离线跑结果，加上应用内用户点赞点踩。没有可靠的度量，后面所有调优都是盲调。

第二条建议关于上下文。Nathan 的做法是把检索结果从两三条加到十条，让 GPT-4 或 Claude 2 自己在结果里挑。Anton 提醒了一个流传已久、最近才被研究实证的事实：混进上下文的无关信息，会实打实地拉低整个应用的表现。麻烦在于这个问题很难单独归因，检索结果取决于切块策略，切块策略又取决于嵌入模型，环环相扣。Nathan 的经验是 Claude 2 塞满 10 万 token 会跑偏，5 万 token 表现正常。Anton 的原则一句话：尽可能多装相关信息，尽可能少装无关信息。

具体技巧上，Nathan 在用 HyDE（假设性文档嵌入）：让模型先编一段「答案大概长什么样」，拿这段编造的文本去查库。查客户家孩子的生日，直接问命中率一般，改成「孩子A出生于某年某月某日」这种陈述句，目标文档更容易跳到最前面。Anton 补了个冷静的判断：通用嵌入模型训练时本来就是「问题落在答案附近」的方向，HyDE 等于手动补了模型可能已经具备的能力，每次查询还多一次模型调用。短期划算，长期看微调嵌入空间更便宜。

还有一类数据干脆别走向量这条路。生日、数字、事件这类结构化事实，放 SQL 表里更好，模型知道表结构就能直接生成查询，省掉有损的语义检索。Chroma 内部的文档存储和元数据存储本来就是关系型数据库，所以关键词过滤是开箱即用的。

更进一步的玩法是仿射变换。已有工作证明，用一个仿射变换，对空间做挤压、拉伸、旋转，就足以把一个嵌入空间映射到另一个。算出正向变换后只作用在查询上，库里向量一个都不用动。同一个库，不同应用、不同用户可以各自学各自的变换，等于按用户微调检索，不用重算任何嵌入。Chroma 计划把这套东西做成产品：接上 LangSmith 这类评测工具，按一个按钮，根据评测结果自动调整你的嵌入空间；再往前，是用数据子采样自动帮你选嵌入模型，自动去重，自动生成「条件摘要」，把十二份互相重复的文档压成一份，只留你关心的信息。Nathan 想在检索十条和塞进上下文之间再加一层便宜的小模型过滤，省钱省延迟，Anton 说这正是轻量开源模型的用武之地。

Nathan 还问了一个具体的锅该谁背：检索漏了东西，怪向量表示，还是怪近似最近邻搜索？Anton 的答案很干脆：几乎全怪表示。近似最近邻的召回率和速度是可调参数，各实现的基准曲线都是公开的，结果偏离曲线，就是表示的锅。默认设置下漏检大约百万分之一量级，前提是数据分布正常，往 HNSW 图里反复塞同一条重复数据，能把索引彻底搞坏。反正延迟大头在模型推理，多花一点延迟换召回是划算的。数据量小的话直接全量暴力搜索，Chroma 在小数据时自动走这条路，规模上来才切索引结构。

微调和检索的关系，他的划分很清楚：微调改变的是完成任务的风格和方式，检索提供的是事实本身，两者互补。但扩展曲线是真实存在的，数据量不足以让模型把事实过拟合进去时，微调基本白费，不如用通用模型加检索。最新的检索增强预训练论文也显示，微调能让模型更好地利用检索回来的内容。

这一切的终点，他打了个很直白的比方：现在的 AI 开发者拿到的是「Postgres 存储引擎」，查询规划器、SQL 解释器、块存储算法全得自己写，时间都耗在管道上，没空做真正的应用。Chroma 要做的是给 AI 应用一个统一的数据接口，把切块、选模型、调变换这些事全部收进数据库里。

商业格局：增量市场，加上 Salesforce 的影子

Nathan 的担心很有代表性：老牌厂商全在补向量功能，没人会在 Salesforce 补上 AI 层之前重建一个 Salesforce。Anton 拿甲骨文传记《Softwar》里的故事回应。Salesforce 当年的做法，是把企业数据围绕客户漏斗统一起来，客户信息最早从哪里进入组织，就在哪里建平台，再在上面长出一堆应用。他希望 Chroma 走类似的路径，而且Chroma 和现有数据库的关系更像互补，抢的是增量。

增量从哪来？他的观察是，过去计算机只能处理结构化数据，所有能进数据库的信息都得先掰成表格。大模型第一次让自然语言文档变成可计算的对象，所以现在涌进 Chroma 的文档、笔记、客户资料，很多从来没有以可计算的形式存在过。今天是大模型能读文档，按他的说法，再过一星期就有能读图片和声音的模型，那些躺在 PowerPoint 里的信息也会进来。论体积，这部分数据和关系型数据库里的存量是一个量级。

他给想做 AI 原生生意的人分了三类：给现有流程加装 AI 的传统公司，做纯 AI 工具的新公司，还有第三类，服务同一批客户、但从第一天就按 AI 流程搭建的公司，头几家跑通的会赢得很夸张。他点名的方向是房地产：流程里全是异构格式的文档处理，纯靠人力堆出来的行当。筛选标准也简单：哪里能最快拿到分发，AI 带来的效率优势才在哪里成立。靠「我们用了 AI」去打可口可乐，没有胜算。

至于大厂会不会亲自下场，他判断 OpenAI 招了检索的人，开发者大会的风声也暗示有个轻量检索系统，但OpenAI 更可能继续拉着检索厂商一起做企业单，让客户为 GPT 付更多钱，自己不造数据库。Google 已经把 Chroma 列为 PaLM 2 公开 API 的发布合作方。对 Anthropic，他提到 Claude 2 的定位更像研究试验台，训练数据检索那种场景目前大家用 FAISS，而 FAISS 很难扩，他认为 Chroma 有机会补位。

还有一个判断值得单独记：RAG 和智能体其实在同一条赛道上。智能体要调用检索，检索好了，智能体开箱就更好用。英伟达 Jim Fan 团队的 Voyager 论文，那个玩 Minecraft 的智能体，记忆引擎用的就是 Chroma，全程没有训练，技能存进去、需要时取出来，还能删掉不想要的行为。

顺带一提行业里悬而未决的分歧：一个通吃一切的大模型，还是一堆任务专用的小模型各管一摊。Anton 观察到越来越多团队想把整条 RAG 链路搬回自己手里，模型用 Mistral、Llama 2 微调，嵌入自己跑，数据不出门。这个答案决定算力住在云机房还是你自己的机器上，也决定这个市场的资本门槛。

把数据当引擎，别当仓库

节目开头 Anton 说过一段话，值得整段抄下来：

我们习惯把数据当成静态的东西，放在某个地方，对应某个时间点。我更愿意把它看成一个回路，接近控制系统的回路。数据是一台引擎，通过计算和外部世界交互，不断自我调整、自我改进。

落到操作上，他给开发者的建议是：从第一天就开始记录用户反馈数据，在线微调可以不急，数据不能不攒。攒下来的就是数据飞轮，模型会持续适配你自己的业务场景，通用模型给不了这种贴合度。

Chroma 自己也在往这个方向铺。他们计划上线 Chroma datasets：维基百科、彭博这类公共数据源，统一嵌好，用户按次付费直接查，没人需要自己重复嵌入一遍英文维基。更有意思的是后手：当一堆应用查同一份数据，Chroma 就知道这份数据被喂给了什么模型、用来干什么任务，可以按任务微调表示，给每个应用「刚好合用」的版本。彭博数据被用来做新闻应用和做人口统计应用，需要的嵌入空间并不相同，用得越多，这份数据的表示就越贴合用途。他管这个叫「活的数据集」。

数据更新是另一件搜索索引时代不用操心的事。应用里数据被交互式地改来改去，社区里已经出现一批做数据流同步的工具，把外部事件持续灌进库，Chroma 打算直接支持。

Nathan 在这里抛出了自己的真实困扰：Athena 聊天应用里的历史对话要不要存？客户档案更新了，旧版本留不留？他感叹自己头一回体会到人类记忆的优雅。Anton 给了两层答案。近期用启发式：时间写进元数据，查询时按日期过滤。远期方案是把时间作为嵌入空间里的一个维度，让嵌入模型自己理解时间，检索器按需给时间维度加权，要全部信息就把时间维度投影掉，要某个时间点就切一刀。当然，前提依然是想清楚什么数据该进向量库，结构清晰的数据留给 SQL。

顺带一提，MIT Tegmark 组那篇「语言模型表示空间和时间」的论文，发现模型内部隐含了经纬度和时间线。Anton 说不意外：对比预训练只编码相似和差异，层级最高处没有第三个参照物，方向可以随意漂，结构是在更低的层级、更近的点之间被迫长出来的。这也解释了为什么最高阶的概念出现在模型中间层。

怀疑派的生命游戏实验

Anton 是圈内出名的 LLM 怀疑派。主持人问他 p(doom)（灭亡概率）有没有更新，他说这个数字随便报，反正没有任何后果，他已经不吵这个了。他真正关心的问题是：这条技术路线到底能不能长出推理系统。

他做了一个很较真的实验。此前有人发现 GPT 下棋时会模仿差棋手的走法，他认为这是对模型内部表征的极强断言。于是他构造了一个最弱的版本：康威生命游戏。规则本身 GPT 背得出来，用文字题问它「N 个细胞存活，K 个死亡，中心细胞存活，中心细胞下一步什么状态」，答对率百分之百。把同样的信息换成网格，给出全部 512 种状态转移，它就开始出错，嘴上复述着规则，手上做错，哪怕每个格子用单独的 token 表示也没用。

他接着喂了随机的 10 乘 10 棋盘，只要求迭代一步，测的东西不问对错，只问一致性。结果：模型在网格这种表示内部是自洽的，但它不会把一种表示下说出的规则应用到另一种表示上。他的读法是这指向「没有世界模型」，同时强调这只是一条证据、一个攻击角度。还有个细节，状态在数据里出现得越少，模型转移时越随机，在他看来是又一条反证。Nathan 的回应是：与其说没有世界模型，不如说世界模型不完整，问题在于泛化边界在哪。

Anton 的结论很务实：今天的技术在「依赖人类解读」的领域已经能产生价值，碰到要精确结果的场景就不行。这项技术真正的威力，是成为一台通用的计算机器，现在还差得远。所以可解释性工作对他特别重要，Anthropic 用稀疏自编码器拆解模型特征的研究，他认为是重大突破，虽然规模还很小；Dan Hendrycks 等人的表征工程也是他长期呼吁的方向。理想形态是一台 140 智商、对世界一无所知的机器，你告诉它什么，它才能推理什么，每一步用了什么信息、在哪个神经元上组合的，全部可查。

顺着这个话题，Nathan 问：存储和检索的东西，会不会有一天脱离文本，直接把向量注进模型？Anton 说百分之百会，现在「取回文档、解码成文本、再编码进另一个嵌入空间」这条有损路径本来就很蠢。但他不担心可解释性：向量的来源都有记录，而且商业利益和安全利益在这里完全一致，一个行为无法预测的系统没有商业价值。可以用可解码性做闸门，超出范围的向量直接删。他打了个比方：设计客机时没人用英语写指令，全是数字和公式，但我们对它怎么飞一清二楚，因为工具跟得上。工具正是 Chroma 下一步要补的，公司历史上第一个产品就是潜在空间可视化器，现在要把它重新做进产品里。他把当下的氛围比作早期万维网，门槛低、能力强、人人可玩，这种组合历史上每次都引爆创新。

明天就能用的六件事

最后给一份可以直接抄作业的清单：

• 先建评测再调优：离线评测加应用内点赞点踩，没有度量，切块大小、检索条数全是盲调。
• 检索漏了东西，先怀疑表示和切块，近似搜索默认设置漏检约百万分之一，基本可以排除；小数据量直接全量搜索。
• 上下文宁缺毋滥：相关信息尽量多装，无关信息尽量剔除，重复文档先去重或做条件摘要。
• 生日、数字、事件这类事实放 SQL 表让模型直接查询，文档语义检索才交给向量库。
• 嵌入模型别迷信单一厂商，开源模型微调后往往够用；数据敏感或规模大时，把整条 RAG 链路留在自己手里，顺便攒下数据飞轮。
• 从第一天就记录用户反馈，微调可以晚做，数据不能不攒。

Nathan 把这期节目推荐给身边的软件和 AI 工程师。如果你正在搭第一个 RAG 应用，这期值得完整听一遍；Anton 那个生命游戏实验的推文也值得找来看，那里藏着他判断这条技术路线天花板的全部逻辑。