整理自Chroma公司CEO Jeff Huber的访谈，使用了AI进行部分润色

行业现状

当前 AI 开发领域正面临一个显著的挑战：从演示 Demo 到实际产品之间存在着难以逾越的鸿沟。

如下图，许多时候，AI 开发更像是一种依赖偶然性的 “炼金术”—— 开发者在大量数据中反复尝试，寄希望于从中 “搅拌” 出理想的结果，而非基于严谨工程学的系统性构建。

这种现状的根源在于，AI 开发尤其是机器学习领域充满了不确定性，使得构建稳定可靠的工程应用远比搭建一个演示原型复杂得多。

更值得关注的是 “上下文腐烂” 现象 —— 一个反直觉的发现是，模型学习的信息越多，其性能反而可能下降。这揭示了一个核心问题：上下文的质量远比数量重要。

即便模型拥有超长的上下文窗口，若缺乏有效的信息筛选与组织，大量无关或冗余的 token 不仅无法提升性能，反而可能导致模型忽略关键指令、削弱推理能力。

因此，如何解决上下文工程问题，即在每次生成过程中精准选择应纳入的信息，成为 AI 应用落地的关键。

上下文工程

上下文工程包含两个核心循环：内循环聚焦于单次生成时的信息筛选，外循环则致力于让系统持续学习优化信息选择的策略。

在这些环节中，检索技术扮演着不可或缺的角色，它构成了 AI 工程学的重要组成部分。传统的关键词匹配技术已无法满足 AI 原生应用的需求，现代检索系统需要基于向量匹配与语义理解，具备高频次检索能力和开箱即用的特性，以适配大语言模型（LLM）数量级差异带来的挑战。

向量数据库的兴起，正是 AI 原生应用对检索技术升级需求的直接体现。这类数据库以向量匹配和语义理解为核心，能够精准捕捉数据背后的语义关联，完美适配 LLM 对深度语义检索的需求，同时支持高频次检索调用，从技术底层解决了传统关键词搜索无法满足的 AI 场景痛点 —— 这恰好回应了上下文工程中对 “精准筛选有效信息” 的核心诉求。

而随着 AI 应用的规模化落地，向量数据库的部署模式也逐渐向云端迁移。对于大多数开发者和中小型企业而言，自建、维护一套本地向量数据库系统不仅需要高昂的硬件成本，还需投入大量精力应对扩容、运维等问题，与 AI 开发追求高效、灵活的目标相悖。他们更需要的是开箱即用的云服务，能够快速集成到现有开发流程中，无需关注底层基础设施的搭建与管理。

正是基于这一需求，以 Chroma 为代表的工具通过现代化技术栈构建系统，推出了云上无服务器的向量数据库服务。这种服务模式让开发者尽量摆脱基础设施运维的负担，只需通过简单的调用即可享受稳定、可扩展的向量检索能力。

值得注意的是，作为新一代检索系统的推动者，Chroma 等工具对 “RAG”（检索增强生成） 这一术语始终持保留态度。核心原因在于，传统 RAG 技术常常将检索、信息整合、AI 投喂等不同环节强行打包，简化为 “密集向量搜索 + 直接投喂 AI” 的单一流程，完全忽略了上下文工程中 “如何动态筛选信息”“如何优化信息组合” 的复杂性，与向量数据库所支撑的精细化检索逻辑相悖。

为应对上下文工程的挑战，主流方案逐渐转向两阶段检索模式：

1. 通过检索结果初筛提升召回率，确保潜在相关信息被纳入候选池；
2. 借助大模型自身的判断能力进行精选，精准定位最有价值的内容。

随着大模型速度提升与成本降低，这种模式的可行性与效率正不断提高。

在代码检索这种高逻辑性的场景中，也应该引入更精确的检索方案（比如正则表达式匹配）。此外，代码检索场景下也有更新的“索引分叉” 技术，允许开发者在毫秒级时间内为每个应用分支创建可检索的副本，进一步增强了系统的灵活性。

关于LLM的记忆能力：在LLM的长期发展中，“记忆” 本质上是上下文工程的自然结果，而这一结果与检索系统的设计深度绑定。

为了量化评估检索系统的效能，“生成式基准测试”（Generative benchmarking）方法应运而生：不是由人手工构造数据集，而是让 AI 阅读相关文档后自动生成大量（问题，答案）对，以此构建数据集，进而为检索系统的优化提供可量化的依据。