---
area: "tech-engineering"
category: technology
companies_orgs: []
date: '2025-08-27'
draft: true
guest: ''
insight: ''
layout: post.njk
products_models: []
project: []
series: ''
source: https://www.youtube.com/watch?v=L-9_A84twpw
speaker: Best Partners TV
status: evergreen
summary: Chroma创始人杰夫·哈伯剖析AI开发，强调从“炼金术”到“工程学”的转变。他指出“上下文腐烂”问题，倡导“上下文工程”，并提出两阶段检索和生成式基准测试等策略，以构建高质量AI应用。
tags:
- ai-development
- context-engineering
- developer-experience
- information
- performance
title: 人工智能开发的“炼金术”到“工程学”：Chroma与上下文工程的深刻洞察
---
### 从“炼金术”到“工程学”：AI开发的现状与挑战

一开始，我们聊一个在AI圈子里既核心又非常棘手的话题：你有没有觉得我们现在开发AI应用，特别像是在搞一场神秘的**炼金术**（Alchemy: 一种将普通物质转化为黄金的神秘实践，在此比喻AI开发中缺乏系统性和可预测性）？我们把各种数据和模型扔进一个黑箱，然后双手合十，期待它能炼出我们想要的“黄金”。有时候它确实能够惊艳到我们，但是更多时候，我们面对的是一堆无法解释、难以复现、更别提稳定运行的“废渣”。

这个比喻来自一位身处AI基础设施领域核心的创业者，Chroma的创始人杰夫·哈伯（Jeff Huber）。他认为，AI开发的现状是从“Demo演示”到“生产环境”之间横亘着一条巨大的鸿沟，而填平这条鸿沟靠的不是运气或者反复“搅拌锅里那堆神秘的玩意儿”，而是需要严谨的“工程学”。更关键的是，当我们所有人都在为大模型厂商宣传的百万、甚至千万级别的“超长上下文窗口”而欢呼时，他和他的团队却发布了一份报告，冷静地告诉大家一个残酷的现实，那就是“**上下文腐烂**”（Context Rot: 指大语言模型在接收过多上下文信息后，性能反而下降的现象）。你往模型的脑袋里塞的东西越多，它反而会变得越“笨”。这听起来是不是有点反直觉？今天，我们就来回顾一下杰夫·哈伯（Jeff Huber）在《Latent Space》播客节目的访谈，看看Chroma是如何试图将AI开发的“炼金术”转变为一门真正的“工程学”的。这不仅是一个关于技术的故事，更是一个在喧嚣的AI浪潮中如何保持专注、坚持信念和追求极致“技艺”（Craft）的故事。

### Chroma的创立原点：潜空间与生产级AI的追求

要理解Chroma，我们必须回到它创立的原点。时间拉回到2021年、2022年，当时大模型的热潮才刚刚开始酝酿。创始人杰夫和他的团队已经在应用机器学习领域摸爬滚打了许多年，他们反复经历了一个令人沮丧的循环：构建一个惊艳的演示Demo非常容易，但是要把它变成一个在生产环境中可靠、可维护的系统却异常艰难。

杰夫用了一个非常形象的比喻，它来自一个著名的XKCD漫画。漫画里，一个人站在一堆冒着热气的、像垃圾山一样的东西上，另一个人问他：“这就是你的机器学习系统吗？”他回答：“对呀！你把数据倒进这一大堆线性代数里，然后在另一边收集答案。”对方又问：“要是答案错了怎么办？”他回答：“哦，那你就搅一搅，直到答案看起来对为止。”这听起来很荒谬，但是它精准地描绘了当时很多AI应用开发的真实状态。整个过程充满了不确定性和偶然性，感觉不像是严谨的工程，更像是一种玄学或者说炼金术。

杰夫和他的团队觉得这从根本上就是错的。他们有一个核心的信念，那就是**潜空间**（Latent Space: 大语言模型理解和表示数据的内部方式，是模型看待世界的抽象表示）是一个极其重要但被严重低估的工具。它不仅是模型看待世界的方式，也应该成为我们人类理解模型、并与之协作的共享空间。这个信念成为了Chroma的起点。他们的使命就是要帮助开发者构建生产级别的AI应用，让这个过程从炼金术变成真正的工程学。

而在探索这条路的早期，他们很快意识到一个关键的**工作负载**（Workload: 指系统需要完成的特定任务或一系列操作）是**检索**（Retrieval: 在AI应用中，从海量信息中精准、高效地找到最相关内容的过程）。在AI应用中，如何从海量信息中精准、高效地找到最相关的内容喂给大模型，是决定应用质量的命根子。于是，Chroma决定将所有精力都聚焦在“检索”这个单点上。杰夫的逻辑很清晰，在一个领域，你必须先做到世界级的水平，才有资格去做更多的事情。这需要一种近乎“偏执狂”式的专注。

### 构建现代化的AI原生检索基础设施

所以，当我们今天问Chroma是做什么的时候，最精准的答案应该是：他们正在构建一个现代化的、**AI原生**（AI-Native: 专为AI应用设计和优化的系统或技术，与传统系统有本质区别）的检索基础设施。这听起来很简单，但是“现代化”和“AI原生”这两个定语背后却并不容易。

我们先说“现代化”。传统的搜索技术很多已经有几十年的历史了，而过去十年分布式系统领域诞生了许多新的设计原则和工具，比如读写分离、存算分离、Rust语言带来的高性能和内存安全、以及将对象存储作为核心持久化层等等。Chroma需要从零开始，用这些现代化的理念来构建整个系统。

而“AI原生”则意味着更深层次的变革。杰夫认为，这体现在四个方面：
1.  **使用的技术不同**：它不再仅仅是传统的关键词匹配，而是以**向量搜索**（Vector Search: 基于语义相似性而非关键词匹配的信息检索技术，通过比较数据点在向量空间中的距离来查找相似项）为代表的语义理解。
2.  **工作负载不同**：AI应用，尤其是**Agent**（AI Agent: 能够理解指令、规划行动、执行任务并从环境中学习的自主AI实体），可能会在一次任务中进行成百上千次的检索。这对系统的并发和延迟提出了全新的要求。
3.  **开发者不同**：构建AI应用的开发者可能并不是搜索领域的专家，他们需要的是一个API友好、开箱即用的工具，而不是一个需要配置无数参数的复杂系统。
4.  **最终的用户也不同了**：传统搜索引擎的最终用户是我们人类，一次大概只能提供10个链接；而AI应用的“用户”是大语言模型，模型可以“消化”成百上千条信息。这个数量级的差异从根本上改变了对检索系统的设计要求。

理解了这些，我们才能明白Chroma在做什么。他们不是简单地在已有的数据库上加一个向量搜索的功能，而是在从底层逻辑上重新思考和设计一个为AI时代而生的信息检索系统。

### Chroma的独特哲学：开发者体验与“慢就是快”

当然，有这样深刻思考的公司不止Chroma一家。时间回到2023年，**向量数据库**（Vector Database: 专门存储、管理和查询向量Embedding的数据库，常用于语义搜索和推荐系统）赛道可以说是AI领域最火热的“风口”之一。我们看到像Pinecone这样的公司完成了高达1亿美元的融资，估值飙升。一时间，各种新的向量数据库产品层出不穷。在这样的市场环境下，任何一个创业者都很难不焦虑。但是Chroma的选择却显得异常的“佛系”和“迟缓”。他们没有急于融资扩张，也没有匆忙推出一个看似完整的云产品去抢占市场。相反，他们花了很长的时间打磨那个最基础的开源、单机版产品。

为什么呢？这里就体现出了杰夫作为创始人的独特哲学。他认为，创业有两种路径：一种是**精益创业**（Lean Startup: 一种创业方法论，强调快速试错、迭代和验证市场需求）式的，不断寻找市场信号，就像做梯度下降一样，跟着用户的需求走。他对此的批判是，如果你完全遵循这条路，你最终可能会做出一个“给中学生用的约会App”，因为它似乎是人类最基础、最容易被满足的需求。另一种路径是创始人心中有一个非常强大、甚至有些逆向的观点，一个“秘密”，然后偏执地去实现它。显然，Chroma选择了后者。

在他们看来，最重要的品牌资产是**开发者体验**（Developer Experience, DX: 开发者在使用产品、工具或平台时的整体感受和效率）。他们希望Chroma这个品牌与“极致的技艺和工艺”（Craft）深度绑定。当他们的单机版产品只需要 `pip install ChromaDB` 这样一条命令就能在5秒内跑起来，并且在各种奇怪的操作系统甚至是树莓派上都能稳定运行的时候，他们本可以很快将它打包成一个云服务推向市场。但是他们没有。因为在杰夫看来，简单地把一个单机软件托管起来并不能满足他们对“伟大的开发者体验”的定义。那样的产品很快就会让开发者陷入到配置节点数量、选择机器规格、设计分片策略、担心备份和容灾的泥潭里，这违背了他们的初衷。

所以，他们宁愿花费更长的时间去构建一个真正理想中的云产品——Chroma Cloud。这个产品的设计目标就是要让开发者感觉和使用本地的 `pip install` 版本一样丝滑。它必须是零配置的，没有任何需要用户操心的选项。无论你的数据量和访问量如何波动，它都应该永远快速、永远高性价比、永远保持数据最新。为了实现这个目标，他们必须在底层做大量艰苦的工作，构建一个真正的**无服务器计算平台**（Serverless Computing Platform: 一种云计算执行模型，云提供商动态管理服务器资源，用户无需预置或管理服务器）。它的计费方式也必须是完全基于用量的，只为你使用的那“一小片”计算资源付费，不多收一分钱。这对于很多开发者，尤其是个人项目或者小型应用来说，可能意味着可以免费使用好几年的时间。

这种近乎“愚蠢”的坚持在那个资本狂热的年代显得格格不入。当外界在讨论“我为什么不用PGVector”或者其他替代方案的时候，Chroma内部依然在按照自己的节奏，慢慢地招聘那些真正认同他们愿景的人。杰夫有一个观点叫做“**康威定律**（Conway's Law: 指系统设计结构与创建该系统的组织沟通结构之间存在同构关系）的上游”，也就是说你的组织架构决定了你的产品形态，而你的公司文化则决定了你的组织架构。所以，最终你“交付”的其实是你的文化。因此，他坚持非常缓慢和挑剔地招聘，因为他认为公司未来增长的斜率完全取决于办公室里这些人的质量。他希望和一群自己真正热爱、愿意在战壕里并肩作战、并且能够独立交付出符合标准成果的人一起奋斗。

如今，Chroma的开源项目在GitHub上拥有超过两万颗星，每月有超过五百万的下载量，总下载量超过了七千万次。而他们精心打磨的Chroma Cloud也终于正式发布。这一切都证明了那种慢和坚持最终会构建起最坚固的护城河。

### RAG已死，上下文工程永存：对抗“上下文腐烂”

聊完Chroma的哲学和产品，我们现在要进入更核心的部分，也是我认为这次访谈最有价值的地方：他们对AI应用根本问题的思考。

杰夫在访谈中毫不客气地表达了他对一个术语的厌恶——**RAG**（Retrieval Augmented Generation: 检索增强生成，一种结合检索和生成技术以提高大模型回答准确性的方法，此处作者认为其定义过于模糊）。他说，Chroma内部从不使用这个词。为什么？因为RAG这个词把“检索”（Retrieval）、“增强”（Augmentation）和“生成”（Generation）这三个完全不同的概念强行打包在了一起，导致了极大的混乱。更糟糕的是，后来RAG几乎就等同于用简单的密集向量搜索，然后把结果塞给模型，这让整个技术栈显得非常的“愚蠢”和“廉价”。

为了打破这种思维定式，杰夫和社区里的一些人开始倡导一个更精确、也更有“地位”的词，那就是“**上下文工程**”（Context Engineering: 决定在大语言模型生成步骤中，应将哪些信息放入上下文窗口的工作）。什么是上下文工程？它的定义非常清晰，这项工作的目标就是决定在大语言模型的任意一次生成步骤中，到底应该把什么信息放入**上下文窗口**（Context Window: 大语言模型在一次处理中能够接收和处理的文本长度或Token数量）中。上下文工程包含了一个“内循环”和一个“外循环”。内循环是“这一次”我该放什么进去，外循环则是我的系统该如何通过不断的学习，让自己在未来能够更聪明地填充这个上下文窗口。

这个概念的提出可以说是恰逢其时，因为整个行业都正笼罩在一种对“超长上下文窗口”的盲目乐观之中。各大模型厂商纷纷发布“大海捞针”（Needle in a Haystack）测试的完美成绩单，暗示它们的模型可以在百万，甚至千万级别的上下文长度中精准无误地找到信息。这给开发者造成了一种假象，好像我们不再需要费心做信息筛选了，把所有东西都扔进去就行了。

然而，现实是残酷的。Chroma的团队在研究中发现了一个普遍存在、但是很少被公开讨论的问题，那就是“上下文腐烂”。他们发布了一份技术报告，用实验数据证明了大语言模型的性能并不是对上下文窗口中的**Token**（Token: 语言模型处理的最小文本单位，可以是单词、子词或字符）数量免疫的。随着你放入的Token越来越多，模型不仅会开始忽略一些指令，它进行有效推理的能力也会显著下降。

这个发现源于他们最初对Agent学习能力的研究。他们想看看如果让Agent能够记住之前的成功和失败经验，会不会提升它的表现。但是在实验中，他们发现随着对话轮次的增加，上下文窗口里的Token数量会呈爆炸式的增长，很快那些明明写在上下文里的清晰指令开始被模型所无视。于是，他们决定把这个“房间里的大象”揪出来。他们的报告中有一张非常著名的图表，对比了当时市面上主流模型在处理长上下文时的性能衰减情况。结果显示，像Anthropic的Claude 3 Sonnet表现最好，而GPT-4 Turbo和Gemini Flash的性能则随着上下文变长衰减得非常快。

这份报告并没有推销任何Chroma的产品，它只是纯粹地指出了这个问题。杰夫说，他并不责怪这些实验室，因为大模型开发的竞争极其激烈，大家自然都会选择在那些对自己有利的基准测试上进行优化和宣传，很少有人会主动站出来说：“这是我们产品的优点，以及，这是我们产品的缺点。”

这份“上下文腐烂”报告的意义在于，它像一盆冷水浇醒了那些对“无限上下文”抱有幻想的开发者。它明确地告诉我们，上下文窗口的长度（Quantity）远没有上下文内容的质量（Quality）重要。上下文工程因此从一个可有可无的优化项，变成了构建高质量AI应用的一个必选项。杰夫甚至断言，今天你所知道的任何一家成功的AI原生公司，它们最核心的竞争力就是“上下文工程”。

### 上下文工程的实践：两阶段检索与专业化应用

那么，问题来了，既然上下文工程如此重要，我们具体应该怎么做呢？目前，很多开发者还在使用最朴素的方法，也就是把所有可能相关的文档一股脑儿地塞进上下文窗口里，这显然会触发“上下文腐烂”的后果。而领先的团队已经开始采用更为精细化的策略。

杰夫观察到的一个主流模式是“**两阶段检索**”（Two-Stage Retrieval: 一种信息检索策略，首先进行粗略筛选以获取大量候选，然后进行精细化排序以选择最相关内容）。想象一下，你有一个包含数百万个文档“块”（Chunk）的知识库。当用户提出一个问题的时候：
1.  **第一阶段是“粗筛”**：你利用各种信号，比如向量搜索的语义相似性、传统的全文搜索的关键词匹配、以及元数据过滤的方式，从数百万个候选项中快速筛选出几百个高度相关的候选者。这个阶段追求的是“召回率”，宁可错杀一百，不能放过一个。
2.  **然后进入第二阶段，“精炼”**：这个阶段人们开始越来越多地使用一个强大的工具，也就是大模型本身，来做**重排序**（Re-ranking: 在检索结果初步筛选后，利用更复杂的模型或算法对结果进行二次排序，以提高相关性）。你可以把这几百个候选块连同原始问题一起丢给一个大语言模型，让它来判断哪些块对于回答这个问题是“最最最”相关的，并给它们打分排序。最终，你可能只需要选择得分最高的20或30个块，放入最终生成答案的那个大模型的上下文窗口里。

你可能会觉得调用几百次大模型听起来很昂贵、很慢。但是实际上，随着模型推理成本的急剧下降，这种“暴力美学”式的做法正在变得越来越可行。杰夫甚至大胆预测，随着大模型变得越来越快、越来越便宜，专门的重排序模型可能会在大多数场景下消失，就像今天我们很少会为了特定任务去设计专门的ASIC芯片一样，大家会直接用通用的大语言模型来完成这个任务。

这个范式在代码检索等更为专业的领域也同样适用。代码是一种结构化、逻辑性极强的文本，对它的检索不能只依赖模糊的语义。所以，除了向量搜索，像**正则表达式**（Regex, Regular Expression: 一种字符模式，用于在文本中进行搜索、匹配和替换操作）这样的精确匹配工具依然极其重要。Chroma就在他们的系统中原生支持了高速的Regex搜索。此外，他们还开发了一个很有意思的功能叫做“**索引分叉**”（Index Forking: 在毫秒级时间内为已有索引创建几乎零成本副本的功能）。开发者可以在毫秒级的时间内为一个已有的索引创建一个几乎零成本的副本。这意味着你可以为代码仓库的每一次提交（Commit）、每一个分支（Branch）都创建一个独立的、可供搜索的索引。这对于需要追溯代码历史、对比不同版本的功能来说，简直是一件神器。

在访谈的最后，杰夫还分享了他对AI系统“记忆”（Memory）的看法。我们经常听到各种关于长短期记忆、工作记忆的复杂理论。但是在杰夫看来，这些都是不必要的复杂化。他认为“记忆”就是“上下文工程”这棵树上结出的果实。换句话说，如果把记忆看作是一种收益，那么上下文工程就是实现这个收益的工具。一个好的记忆系统本质上就是一个好的上下文工程系统，它知道在用户说出“记住这个”的时候应该如何存储信息；也知道在后续的交互中如何精准地把这个“记忆”提取出来放入到上下文窗口中。

### 量化优化：生成式基准测试与数据标注

而如何让这个系统变得越来越好呢？Chroma又提出一个非常实用的方法论，并且为此发布了另一份技术报告，叫做“**生成式基准测试**”（Generative Benchmarking: 利用大语言模型反向生成问题和答案，以创建黄金数据集来评估系统性能的方法）。我们知道，要评估一个系统的好坏，你需要一个“**黄金数据集**”（Golden Dataset: 包含标准问题和对应标准答案的参考数据集，用于评估模型或系统的准确性），也就是一系列标准问题和对应的标准答案。但是对于自己的私有知识库，谁来出题，谁来写答案呢？这是一个非常耗时耗力的过程。

Chroma的方法是让大语言模型来帮你做这件事。你可以让模型读取你的文档，然后反向生成出可能的用户问题。这样你就可以快速地创建出大量的“问题-答案对”，从而形成你的黄金数据集。有了这个数据集，你就可以量化地评估你的检索系统了。比如，更换一个**Embedding模型**（Embedding Model: 将文本或其他数据转换为高维向量（Embedding）的模型，这些向量能捕捉数据的语义信息）后，我的检索准确率是从80%提升到了90%吗？增加一个重排序步骤对结果又有多大的改善呢？这样一来，所有的优化都变得有据可依，而不再是凭感觉“搅一搅”了。

杰夫还鼓励所有的团队都应该花一个下午，点上几个披萨，开一个“数据标注派对”，手动创建哪怕几百个高质量的标注数据。这个小小的投入，对系统性能的提升回报是极其巨大的。

### 文化与信念：构建坚固护城河的基石

这就是Chroma带给我们的思考：将AI开发从一门依赖直觉和运气的“炼金术”转变为一个可测量、可迭代、可优化的“工程学”过程。

说到这里，你可能会发现Chroma的成功，不仅仅是技术上的，更是一种文化的胜利。杰夫在分享他之前的创业经历时坦言自己过去常常在一些事情上做出妥协，比如和自己不那么契合的人共事，或者服务自己没有那么热爱的客户等等。但是现在，随着年龄的增长，他越来越清晰地认识到，生命短暂，应该只把时间花在自己真正热爱的工作上，与自己真正欣赏的人一起，为自己真正想服务的用户创造价值。这听起来有点理想主义，但也正是这种信念塑造了Chroma的气质。

他提到，如今的社会，特别是科技圈，弥漫着一种**虚无主义**（Nihilism: 一种哲学观点，认为生命没有内在意义、目的或价值）。但是在他看来，人需要有信念，需要去开启一些在自己有生之年都未必能看到最终结果的宏大工程，就像过去的人们建造一座需要数百年才能完工的大教堂一样。这种信念最终会体现在公司的每一个细节里。杰夫非常认同“如何做一件事，就是如何做所有事情”的信条。所以，你会看到Chroma的办公室设计、他们的网站、文档、甚至是周边T恤都透露出一种高度统一、深思熟虑的“设计感”和“品质感”。这种对于“技艺”（Craft）的极致追求与他们做产品的理念一脉相承。在他看来，创始人就是一个公司的“品味策展人”。当这种对品质的坚持从创始人传递给每一个员工，最终就会内化为公司的文化，并且外显为你所看到的产品和品牌。

好了，今天关于Chroma的故事就聊到这里。从“炼金术”到“工程学”，从“上下文腐烂”到“上下文工程”，从“无限上下文”的迷思到“黄金数据集”的实践，Chroma带给我们的不仅仅是一个好用的工具，更是一种在AI时代如何进行严肃、严谨的系统构建的思考方式和哲学。希望今天的分享能够对正在AI领域探索的你有所启发。感谢收看本期视频，我们下期再见。