巴别之塔 - Tower of Babel

从 ReAct 到 Dynamic Workflows：Agent 开始用代码调度 Agent

Sun, 31 May 2026 23:35:00 +0800

如果回头看最近一两年的 agent 演进，会发现一个很清楚的变化：agent 一开始是在学会使用工具，后来是在学会管理别的 agent，现在则开始把这种管理过程写成程序。

这不是一个小的实现细节，而是 agent harness 控制平面的变化。

最早的 Manus、Claude Code、Devin、OpenHands 这一类系统，本质上都可以看作 ReAct 风格的 agent。模型看到任务，调用一个工具，拿到 observation，再决定下一步。工具可以是 bash、读文件、改文件、搜索、浏览器、MCP tool，甚至是一整个虚拟机环境。

这种模式很自然。人类开发者调试代码时也是这样：先 grep，读文件，跑测试，看报错，改代码，再跑测试。很多问题没法一开始就写出完整计划，只能边探索边调整。所以 ReAct 的强处在于开放性。它让模型可以在真实环境里行动，而不是只在 prompt 里空想。

但 ReAct 的问题也很明显：所有控制逻辑都隐含在主模型的上下文里。

模型要记住自己查过哪些文件，排除了哪些假设，下一步要验证什么，哪些结果可信。任务短的时候没问题；任务一长，context 里就会塞满搜索结果、日志、报错、文件片段和中间推理。模型不仅要理解问题，还要承担大量本该由程序完成的工作：循环、分支、去重、分配任务、汇总结果、决定是否重试。

所以第一阶段可以简单理解为：一个 agent 自己边看边干。它很通用，但主模型很累。

从单 agent 到 master-worker

为了缓解这个问题，subagent 出现了。

Claude Code 之前使用 subagent 的主要方式，就是典型的 master-worker 模式。主 Claude 仍然负责整体任务，但可以把局部任务派给专门的 subagent。比如让一个 subagent 探索某个模块，让另一个 subagent 做 code review，让另一个 subagent 查某类 bug。每个 subagent 有自己的 context，可以独立读文件、调用工具、完成任务，最后只把结果返回给主 Claude。

这一步解决了 ReAct 的一个核心痛点：context isolation。

主模型不必亲自读完所有文件、看完所有日志、记住所有细节。它可以让 worker 在自己的上下文里消耗大量 token，最后只接收摘要或结论。对于大型代码库、复杂 research、多方向 debugging，这个模式明显更可扩展。

但 master-worker 仍然没有解决最核心的问题：主模型还是 coordinator。

它要决定派几个 worker，每个 worker 做什么，什么时候继续派，什么时候停止，怎么合并结果，发现冲突怎么办，要不要复查。worker 的执行被分摊出去了，但 workflow 本身仍然由主模型在 turn-by-turn 的对话循环中维护。

换句话说，subagent 让 agent 有了 worker，但还没有让 agent 有一个真正的调度系统。

Dynamic Workflows：把 manager 写成程序

Claude Code Dynamic Workflows 的关键变化就在这里。

它不是简单地「多开几个 subagent」，而是让 Claude 先写一段 JavaScript workflow script，再由 workflow runtime 执行这段脚本。脚本负责任务拆解、启动 subagents、并发执行、收集中间结果、交叉验证和最终汇总。Anthropic 的发布文章 Introducing dynamic workflows in Claude Code 里也强调了这一点：Claude 会动态写 orchestration scripts，在一个 session 里运行大量并行 subagents，并在结果返回用户前检查自己的工作。

这就把控制逻辑从主模型上下文里拿出来，放进了代码里。

以前是主 Claude 在对话中临场决定：「我现在再派一个 subagent 去查这个方向。」现在是 Claude 先写出一个 workflow：「把这些文件分成 N 组，每组派一个 subagent 检查；每个发现再派 reviewer 交叉验证；最后按置信度汇总。」

这两个模式看起来相似，都是 subagent 在干活，但本质不同。

在 master-worker 模式里，主模型是 manager。在 Dynamic Workflows 里，workflow script 是 manager。模型从「调度者」变成了「调度程序的作者」。

这就是最重要的变化。

一旦 workflow 被写成代码，它就能表达很多自然语言 agent loop 里很笨重的东西：并发 fan-out、循环、条件分支、失败重试、预算控制、投票、去重、分阶段执行、结构化输出检查。中间状态也不必都塞进模型上下文，而是可以留在 script variables 里。

这不是把 Claude Code 变成传统 workflow engine。workflow 仍然是 Claude 根据当前任务动态生成的，不是人提前写死的 DAG。它保留了 LLM 的灵活规划能力，同时借用了程序的稳定执行能力。

这不是 Bash，而是控制平面

这里容易误解。Claude Code 本来就能跑 bash、改文件、执行测试。那 Dynamic Workflows 是不是只是让它「多跑一点代码」？

不是。

Claude Code 普通模式里的 bash 是环境动作。Claude 通过 bash 操作外部世界：跑测试、看日志、启动服务、执行 git 命令。它的核心是 environment interaction。

Dynamic Workflows 里的 JavaScript script 不是替代 bash，也不是直接去改文件。它更像 agent harness 里的控制平面。script 负责任务拆解、subagent 调度、中间状态管理和结果合成；真正进入代码库、读写文件、运行命令的，仍然是被它调度出来的 subagents。

所以它不是「LLM 通过 bash 操作电脑」的延伸，而是另一层东西：LLM 写程序来调度一批能操作电脑的 agents。

Deep Agents：开源世界里的类似抽象

LangChain Deep Agents 的 interpreter 可以放在同一条线上看。

Deep Agents 本来就有 subagents 机制。主 agent 可以通过 task tool 把工作派给子 agent，让子 agent 在自己的上下文里完成任务。这对应的是 master-worker 阶段。

但 Deep Agents interpreter 往前走了一步。它给 agent 一个轻量 code runtime，让模型可以写代码来组合 tools、调用 subagents、处理中间结果。allowlisted tools 会暴露在 runtime 里，比如 tools.task()，模型可以在代码里循环、并发、过滤、聚合，再把最后结果返回给主模型。

这和 Claude Code Dynamic Workflows 的味道很像。

区别在于，Claude Code Dynamic Workflows 是产品化的、深度集成在 Claude Code 里的 workflow runtime。Deep Agents 更像是把底层原语开源出来：一个嵌在 agent loop 里的 interpreter，一个显式暴露工具的 bridge，一套可以调度 subagent 的 API，以及一块不污染模型上下文的 runtime state。

所以 Deep Agents 不必被理解成「给 agent 一个 sandbox」。sandbox 是让 agent 在外部环境里执行命令、安装依赖、跑测试。interpreter 更像是 agent loop 内部的工作区，用来保存 live working values、组织控制流、决定哪些结果应该返回模型。

它不是为了让 agent 有一台电脑，而是为了让 agent 有一个可以写调度逻辑的地方。

真正变化的是谁持有计划

把这几个阶段放在一起看，演进路线会清楚很多。

ReAct 阶段，主模型持有计划，也亲自执行每一步。它一边观察环境，一边决定下一步。

master-worker 阶段，主模型仍然持有计划，但可以把局部任务派给 subagents。worker 帮它分担上下文和执行压力。

Dynamic Workflows / interpreter orchestration 阶段，主模型不再直接持有整个动态计划，而是把计划写进一段程序。程序持有控制流，runtime 保存中间状态，subagents 执行具体工作。

所以 agent 的下一步不是简单地「更多 subagents」。更多 worker 当然有帮助，但如果 master 仍然靠上下文临场调度，系统很快会遇到新的瓶颈。真正的变化是 subagent 调度逻辑开始代码化。

这就是 code runtime 在 multi-agent 系统里的价值。它不是替代 subagent，而是让 subagent 变得可编排。

结尾

我现在更愿意把 agent harness 的演进理解成控制平面的演进。

最早，控制平面在主模型的上下文里。模型自己决定下一步 tool call。后来，系统引入 subagents，主模型变成 manager，把局部任务派出去。但 manager 仍然是模型自己，计划仍然靠上下文维护。

Dynamic Workflows 和 Deep Agents interpreter 往前推了一步：让模型写代码，把 manager 的一部分职责交给 code runtime。模型仍然负责理解目标、设计策略、判断最终结果，但循环、并发、任务分配、中间状态和结果合成，可以由程序来承担。

这也是为什么 Claude Code Dynamic Workflows 值得关注。它不是一个更花哨的 subagent 功能，而是在说明一个更大的方向：当 agent 开始管理 agent，下一步自然不是继续让主模型手工调度，而是让主模型写一个调度程序。

Agent 开始用代码调度 agent。这个变化可能会成为下一代 agent harness 的核心抽象。

当 Agent 成为新的抽象层：我们正在走向一场知识传承危机吗？

Mon, 23 Mar 2026 00:00:00 +0800

抽象层越高，你在正常路径上效率越高。但当抽象泄漏时，你需要的不是"稍微懂一点"的人，而是能从表象一路穿透到底层原理的人。

而这样的人，正在变少。

从一条古老的定律说起

2002 年，Joel Spolsky 提出了 The Law of Leaky Abstractions（抽象泄漏定律）：所有非平凡的抽象，都在某种程度上是有泄漏的。

TCP 承诺可靠传输，但网络拥堵时它会泄漏——你不得不理解 IP 层的行为。ORM 承诺你不需要写 SQL，但慢查询出现时它会泄漏——你不得不理解查询计划和索引。高级语言承诺你不需要管内存，但内存泄漏发生时它会泄漏——你不得不理解 GC 的工作原理。

Spolsky 的洞察很简单：抽象让你在 99% 的时间里更高效，但那 1% 的泄漏时刻，你需要的知识深度反而比没有抽象时更大。 因为你不只需要理解底层发生了什么，你还需要理解抽象层如何歪曲了底层的行为。

这条定律在软件工程中已经被验证了无数次。而今天，我们正在建造有史以来最大的抽象层——AI Agent。

Agent：有史以来最厚的抽象层

当我们让 Agent 写代码、做设计、跑数据分析时，我们本质上是在做一件和 TCP 抽象 IP、ORM 抽象 SQL 一模一样的事情：把一项需要深度理解的工作，封装成一个"输入需求、输出结果"的黑盒接口。

和所有抽象一样，这在大部分时间里效率极高。一个用好 Agent 的初级工程师的产出，可能超过五年前一个高级工程师的产出。

但 Spolsky 的定律不会因为这个抽象层碰巧是一个大语言模型就失效。Agent 会泄漏。 而且它的泄漏方式比传统抽象更加隐蔽和危险。

TCP 泄漏时，你会看到超时错误。ORM 泄漏时，你会看到慢查询日志。这些泄漏是显式的、可观测的。但 Agent 的泄漏可能是：它生成了一段在统计上合理但在概念上错误的代码；它做了一个表面上正确但在边界条件下会崩溃的设计决策；它给出了一个看起来很专业但逻辑链中有一环是幻觉的分析。

你甚至可能不知道它泄漏了。 系统在正常运行，测试在通过，直到某天某个边界条件被触发，你才发现整栋楼建在一个 Agent 三个月前虚构的假设之上。

一场正在发生的预演：美国制造业

如果你觉得这个担忧太理论化，看看美国制造业——它正在经历一场和"Agent 时代知识传承危机"几乎同构的灾难。

从 1980 年代开始，美国企业把制造"抽象"成了一个外包接口：你下订单，对方交货，中间的物理过程你不需要关心。华尔街奖励这种做法——轻资产、高 ROE，股价好看。

波音是这个故事最惨烈的注脚。1997 年与 McDonnell Douglas 合并后，一批财务导向的高管系统性地用"效率优化"替代了工程文化。有经验的老工程师退休了，中间一代在裁员中被淘汰，新一代从未在车间里摸过铆钉。工程判断让位于季度财报。

这个过程是渐进的、不可感知的。 每一步都是"合理的效率优化"——外包这个零件省 5%，裁掉这个团队省一个部门的开销。直到 737 MAX 的 MCAS 连续导致两起坠机，直到 787 的外包供应链失控，直到一架飞机在飞行中门塞板飞脱，所有人才意识到：那些被"优化"掉的，不是冗余，是抗风险能力。

而现在想要重建这种能力，成本是天文数字。台积电在亚利桑那建厂的困难已经说明了：你不能只搬设备，你需要搬整个知识生态——工艺经验、供应链关系、技工培训体系、工程师的直觉判断。这些东西一旦断裂，不是花钱就能买回来的。

这就是抽象泄漏定律在产业层面的体现：外包让你在正常情况下更"高效"，但当泄漏发生时（疫情、质量失控、地缘冲突），你发现修复所需的能力已经不在自己手里了。

Agent 时代的知识退化路径

把波音的故事平移到 Agent 时代，你几乎可以逐帧预测接下来会发生什么：

第一阶段：效率狂欢。 Agent 能解决大部分问题，工程师的产出飙升。会用 Agent 的人成为新的"10x engineer"。深度理解底层原理的人看起来像恐龙——他们花三天手动排查的问题，Agent 用三分钟就解决了。

第二阶段：激励扭曲。 市场开始停止为深层知识定价。公司招聘时看重"prompt engineering"和"Agent 工作流设计"，而不是"能从头实现一个分布式共识协议"。这不是因为后者不重要，而是因为在 99% 的日常工作中它确实不需要。教育体系跟随市场信号调整——为什么要花四年教学生操作系统原理，如果他们毕业后只需要告诉 Agent “帮我写一个调度器”？

第三阶段：隐性退化。 能在 Agent 泄漏时穿透到底层修复问题的人越来越少。这个过程是渐进的、不可感知的，就像波音的工程能力萎缩一样。大部分时候没有人注意到，因为 Agent 在 99% 的情况下工作得很好。偶尔出现的泄漏由少数剩余的"深度理解者"修复，他们被视为昂贵的遗老，而不是关键的基础设施。

第四阶段：临界点。 某一天，一个关键领域的"深度理解者"数量降到了临界点以下——可能是退休、可能是转行、可能是新一代根本没有人走上这条路。然后一个 Agent 无法处理的泄漏发生了，而这次，没有人能修。

历史上知识断裂的模式

这种担忧不是科幻想象。人类历史上有过多次知识断裂，而它们的共同模式惊人地一致：

罗马混凝土。 古罗马人掌握了一种特殊的混凝土配方（掺入火山灰），使得万神殿的穹顶两千年后仍然完好。这个配方在帝国崩溃后失传了——不是因为罗马人变笨了，而是因为维持这套知识体系的社会制度和经济激励消失了。直到 2023 年，MIT 的研究团队才通过分析古代样本重新破解了其中的关键机制。

希腊火。 拜占庭帝国的秘密武器，一种能在水面上燃烧的燃烧剂。因为知识被限制在极少数人手中（出于军事保密），当这条极窄的传承链断裂后，配方永久失传。至今只有猜测，没有定论。

阿波罗登月。 NASA 已经公开表示过，以目前的能力重新制造土星五号火箭是极其困难的。不是因为图纸丢了（大部分还在），而是因为图纸背后那些"为什么选择这个参数"“这个焊接工艺的关键诀窍是什么"的隐性知识，随着那一代工程师的退休而消散了。

这些案例有一个共同点：知识的断裂从来不是因为某一天有人决定"我们不再需要这些了”。它总是在一切看似正常运转的时候，因为激励消失、传承链变窄、新一代无人入行，而悄然发生的。

当一切运行良好的时候，恰恰是系统最脆弱的时候——因为"一切运行良好"本身就在削弱你应对异常的能力。

我们能做什么

知识传承问题没有银弹，但有几条值得认真思考的路径：

1. 让 Agent 成为知识传承的载体，而不仅是执行工具

今天的 Agent 是黑盒——给你答案，不告诉你"为什么"。如果我们能让 Agent 在执行任务的同时生成可审计的推理链，并将其沉淀为结构化的知识库，那 Agent 就不只是在替你干活，它同时在为后人留下"这件事为什么要这样做"的记录。

这类似于软件工程中的 ADR（Architecture Decision Record）：不只记录结论，而是记录推理过程、考虑过的替代方案、以及选择背后的 tradeoff。如果每一次 Agent 解决 leak 的过程都被自动沉淀成一份带上下文的案例，未来的人就有可能通过这些案例重建理解。

当然，前提是这个系统本身被良好地设计和维护——这就引出了一个自指问题：谁来维护知识传承系统？这个问题后面再说。

2. 刻意维持"深度理解者"的最低存量

知识传承的本质不是让所有人都懂，而是确保每一层永远不要空。

核电站运维工程师大部分时间"无事可做"，但社会通过制度安排（监管要求、高薪、专业认证）确保始终有足够的人维持这种能力。航空安全调查员同理。这些角色的存在不是因为它们日常产出高，而是因为它们在异常情况下不可替代。

Agent 时代可能需要为关键技术领域建立类似的制度：规定某些系统必须有能从底层重建的人类专家，就像我们规定核设施必须有持证工程师一样。这不是市场自发会做的事——波音的案例已经证明了市场可以把这种冗余"优化"到零——它需要有意的制度设计。

3. 重塑教育：从"学会做"到"学会审计和重建"

Agent 时代的教育不应该在"教不教底层知识"之间二选一，而应该培养两种层次的能力：

审计能力——理解 Agent 输出的含义，能判断它是否合理，能识别隐蔽的错误。这需要你理解一到两层以下的抽象，不需要能从零重建，但需要能闻出"这里不对劲"。大多数工程师需要这种能力。

重建能力——如果 Agent 不可用了，能从原理出发重新构建系统。这需要穿透所有抽象层的深度理解。少数人需要这种能力，但这少数人的存在是文明韧性的底线。

有意思的是，Agent 本身可能是训练这两种能力的最好工具。让学生用 Agent 解决问题，然后要求他们解释 Agent 的方案为什么是对的——或者找到为什么是错的。这比传统教育中从零开始教可能更高效，因为它直接训练的是在抽象泄漏时最需要的技能：在黑盒之上建立判断力。

4. 知识的"种子化"保存

不是所有知识都需要被活跃地传承。有些知识可以以"种子"的形式保存——不是让每一代人都完全掌握它，而是确保在需要时可以从种子重新培育出完整的知识树。

Linux 内核的源码、文档、mailing list 归档、commit history，合在一起构成了一颗知识种子：一个聪明人在足够时间内，理论上可以从这些材料重建对操作系统的完整理解。

Agent 时代的知识种子可能需要更刻意地设计。不只是代码和文档，还需要包含元信息：这段知识为什么重要？在什么场景下你会需要它？从哪里开始学？前置知识是什么？这类似于给未来考古学家写的注释——你不知道他们什么时候会需要它，但你确保他们找到时能用得上。

一个根本性的张力

所有这些方案都面临同一个悖论：知识传承的基础设施本身也是一个抽象层，它也会泄漏。

谁来维护让 Agent 生成推理链的系统？谁来设计培养"深度理解者"的教育制度？谁来确保知识种子没有腐坏？这些工作本身就需要深层理解，而这恰恰是我们试图保存的东西。

这是一个自指问题，类似于"谁来监督监督者"。我不认为它有一个干净的解答。

但生物学提供了一个启发：DNA 修复不靠一种酶，而是靠多种不同的修复机制互相兜底——碱基切除修复、核苷酸切除修复、错配修复、同源重组。任何一种机制失效，其他机制可以补位。正是这种冗余，让生命在几十亿年的突变压力下维持了遗传信息的完整性。

文明的知识传承可能也需要这种冗余：有人在用 Agent 高效工作，有人在审计 Agent 的输出，有人在维护知识种子，有人在从零学习底层原理"以防万一"。这些角色之间的比例会随着 Agent 能力的提升而变化，但只要没有任何一种角色完全消失，系统就还有自我修复的能力。

最后

Agent 时代最大的风险不是 Agent 不够强，而是它太强了——强到让我们以为不再需要理解它替我们做的事情。

Spolsky 在 2002 年写下抽象泄漏定律时，讨论的是 TCP 和 SQL。二十多年后，我们正在建造一个把整个工程能力抽象掉的系统。定律没变，赌注变大了。

能力的保存不会自动发生。每一次"我们不再需要理解这个"的判断，都是在知识传承的某一层上减少一份冗余。减到零的那一刻，你不会收到任何告警。

直到泄漏发生。

如果你觉得这篇文章有价值，也许最好的回应不是收藏它，而是找一个你已经完全交给 Agent 的领域，花一个下午搞清楚它底下到底是怎么工作的。

那可能是你为自己——以及为文明——买的最便宜的一份保险。

VecDB@ICML2025 里有趣的论文

Thu, 16 Oct 2025 13:00:00 +0800

https://vecdb-ws.github.io/icml2025/index.html

VecDB 是 ICML 里针对 vector database 的 workshop，2025 年是第一届。除了 vector database 和 approximate nearest neighbor (ANN)，也有一些是关于 RAG 和 LLM 推理的。

ANN

跟 ANN 相关的好玩工作。

Best Paper Award: A Bi-metric Framework for Efficient Nearest Neighbor Search, Haike Xu, Piotr Indyk, Sandeep Silwal

传统的 “retrieve-then-rerank” 方案使用 cheap metric d (L2/Cosine) 召回 k 个候选，再用 expensive metric D (cross-encoder) 重新排序。其缺陷在于：

如果 d 与 D 的近似比 C > 1，则最终只能保证 C 倍近似；
必须对所有 k 个候选逐一计算 D，计算量线性随 k 增长。

论文提出的双度量（bi-metric）框架则反其道而行：

索引阶段只用便宜的 d 构建数据结构（如 DiskANN 或 Cover Tree）；
查询阶段主要用 D 评估，但只需对少量点调用。这样可在保持 D 的准确性的同时，显著降低对 D 的调用次数。

形式化地，若 d 与 D 满足 d(x,y) ≤ D(x,y) ≤ C·d(x,y)，则构建于 d 的索引在查询时只需 Õ(Q(ε/C, λ_d)) 次 D 评估即可找到 (1 + ε) 近邻。

应用在 DiskANN 算法，索引阶段不变。查询阶段分两步：

阶段 1 – 用 d 进行粗搜索
- 从随机或中心节点出发，运行 DiskANN 贪心搜索；
- 每一步选择邻居中与查询向量 q 距离最小的（按 d 计算）；
- 维护一个候选队列 A；
- 当访问过的节点数达到 Q/2（论文默认预算的一半）时停止；
- 得到一批候选顶点 S_d。这一阶段只调用 cheap 度量 ddd，代价极低。
阶段 2 – 用 D 在同一图上继续搜索
- 以 S_d 作为起点；
- 重启 DiskANN 的贪心搜索算法，但此时所有比较都用昂贵的度量 D；
- 继续扩展队列 A，直到预算 Q 次 D 调用耗尽；
- 返回目前距离 D(q,p) 最小的前 k 个点。可以理解为：d 决定起步方向，D 决定最后的路径收敛。

在 bi-metric 方法中，需进行 200 次 D 计算（Q=200），即可达到先进行近似最近邻搜索再通过 800 次 D 计算进行重排的同等效果。

bi-metric 与推荐系统中的二向箔概念颇为相似，一个可行的思路是：在二向箔的 HNSW 中先采用 L2 或 IP 距离进行初步搜索，随后再切换至基于 NN 的度量计算方法进行精确匹配。

α-Reachable Graphs for Multi-vector Nearest Neighbor Search, Siddharth Gollapudi, Ravishankar Krishnaswamy, Ben Landrum, Nikhil Rao, Kirankumar Shiragur, Sandeep Silwal, Harsh Wardhan

α-Reachable Graphs 是一种理论上有保证、实践上高效的多向量最近邻检索方法，将经典的 DiskANN 图结构推广到非度量（non-metric）相似度函数，例如 Chamfer 距离——这是 ColBERT 等多向量检索模型的核心相似度度量。简单来说，他们证明了：只要距离函数满足弱三角不等式，DiskANN 仍然能跑得快、搜得准。

作者直接把 DiskANN 的距离函数替换成 Chamfer，相当于 不改算法，只改距离 的方式验证理论。仅替换距离函数的 Chamfer-DiskANN 已能超越复杂变换 - 编码类方法（MUVERA），并在理论上得到收敛保证。

这篇论文的思路与最佳论文 bi-metric 非常相似。不同之处在于，bi-metric 方法在建图和搜索的前半部分都采用了成本较低的度量方式（如 L2 或 IP），而 α-Reachable Graphs 则始终使用计算代价更高的 Chamfer 距离。相比之下，bi-metric 方法适用范围更广且成本更低。两种方法都经过了严格的理论分析。

Down with the Hierarchy: The ‘H’ in HNSW Stands for “Hubs”, Munyampirwa, Vihan Lakshman, Benjamin Coleman

移除 HNSW 中的层级结构（Hierarchical）对性能影响甚微，反而能降低存储成本。这是因为高维向量构成的图（即 HNSW 的最底层）天然存在大量枢纽节点 (hub)，这些节点足以替代原有的层级结构。HNSW 相较于 NSW 的优势主要源于其搜索策略。作者开源了 FlatNav，该项目仅保留了 HNSW 的最底层结构。

这一改进方案在生产环境中应易于验证效果。然而，对于推荐系统场景，该方法可能并不完全适用，因为推荐场景中常存在较多数据孤岛？

The RaBitQ Library](https://openreview.net/forum?id=OeZHhOsFir), Jianyang Gao, Yutong Gou, Yuexuan Xu, Jifan Shi, Zhonghao Yang, Cheng Long

ANN 届新的超级巨星 RaBitQ 团队为他们新的开源库 RaBitQ-Library 写了一篇论文。

Scaling Laws for Nearest Neighbor Search, Philip Sun, Felix Chern, Yaroslav Akhremtsev, Ruiqi Guo, David Simcha, Sanjiv Kumar

作者 Philip Sun 和 Ruiqi Guo 来自 ANN 届的老牌超级巨星 ScaNN 团队，不得不看看。

核心主张：没有 " 最优 " 的近邻算法，只有特定场景下的最优平衡。

作者在 ScaNN、DiskANN、Faiss 等系统上做大规模实验，发现一个稳定的三次根规律（cube-root law）：

$$ C(N) \propto N^{1/3} $$

含义：

当数据规模增加 1000 倍，查询代价仅增加约 10 倍。
表明 ANN 的剪枝效率随规模提升而增强。

在 TPU 等高带宽硬件上，暴力搜索因算术密集度高、内存访问规律而表现突出

TPU-KNN 在 200 万向量时的 QPS/TCO 优于 ScaNN 与 HNSW。
对数千万规模仍具竞争力。因此，在数据量中等或索引频繁重建的场景中，Brute Force 可能是最优选择。

在分布式场景下：

分区式（树状）结构 → 可分布、低通信、可扩展。
图结构 → 跨边过多、延迟大、难扩展。

DistributedANN: Efficient Scaling of a Single DiskANN Graph Across Thousands of Computers, Philip Adams, Menghao Li, Shi Zhang, Li Tan, Qi Chen, Mingqin Li, Zengzhong Li, Knut Magne Risvik, Harsha Vardhan simhadri

这篇论文展示了如何将 DiskANN 扩展到数千台机器的规模，以实现在线检索高达 500 亿级别向量的能力。

实现方法如下：

将 DiskANN 迁移到分布式键值存储系统（例如 TiKV 这类系统）上运行。
原本 DiskANN 将每个向量的乘积量化（PQ）结果存储在内存中，现在改为存储在每个图节点中。这意味着每个 PQ 向量需要存储多份，每一条入边都需保存一份。
引入了一个纯内存的头部索引，用于存放 Vamana 图的顶层节点，以便快速定位 beam search 的起始点。

前一篇 Google 的论文表示尚未见到性能优异的分布式图结构向量索引方案，而微软的这个工作就当场打脸了。不过，微软实际上是通过显著增加存储冗余（即多份存储 PQ 向量）的方式，才解决了图索引难以分布式部署的难题。

IVF² Index: Fusing Classic and Spatial Inverted Indices for Fast Filtered ANNS, Ben Landrum, Magdalen Dobson Manohar, Mazin Karjikar, Laxman Dhulipala

论文的关键观察是：真实世界中的标签频率往往呈 幂律（power-law）分布。

也就是说，大多数标签对应的数据点很少，只有极少数 " 热门标签 " 包含大量向量。

基于这一现象，IVF² 采用混合式索引策略：

对小标签（少量向量），直接用**简单倒排表（flat posting list）**暴力搜索；
对大标签（热门标签），建立更复杂的空间索引结构（IVF + Vamana graph）；
同时使用**位向量（bit vector）和物化交集（materialized joins）**来高效处理 AND 查询。

这种 " 倒排 + 空间索引 " 的融合方式，即为 IVF²（Inverted File × Inverted File）。

不过，我个人更倾向于使用与查询条件无关 (predicate-agnostic) 的索引（如 ACORN/NaviX），对于这种需要针对每个标签单独处理的方式兴趣不大。

Entropy-Based Dynamic Hybrid Retrieval for Adaptive Query Weighting in RAG Pipelines, John Richard Perez, James Yuncheng Zhou, Radley Le, Alexander Menchtchikov, Ryan Lagasse

在进行稠密向量与稀疏向量的混合搜索时，最终得分通常由公式 $s = w_s \cdot s_{\text{sparse}} + w_d \cdot s_{\text{dense}}$ 计算得出。通常情况下，权重系数满足 $w_d = 1 - w_s$ 的关系。

这篇论文提出了一种基于信息论的方法，能够根据稠密/稀疏向量的确定性（熵）自适应地调整参数 $w_s$ 和 $w_d$。

一次性检索：用 BM25 与 FAISS 各取 top-$k$ 结果（例如 $k=5$）。
计算熵：对每种检索的打分归一化为概率分布：

$$ p_i = \frac{s_i}{\sum_j s_j} $$

计算标准 Shannon 熵：

$$ H = -\sum_i p_i \log p_i $$

归一化为：

$$ \hat{H} = \frac{H}{\log k} \in [0, 1] $$

解释：熵高 → 不确定性大 → 该检索不应占大权重。 3. 迭代更新权重：

$$ w_s^{(t+1)} = \frac{1 - \hat{H}{sparse}}{(1 - \hat{H}{sparse}) + (1 - \hat{H}_{dense})} $$

$$ w_d^{(t+1)} = 1 - w_s^{(t+1)} $$

迭代直到权重变化满足：

$$ |\Delta w_s| < \epsilon $$ 或达到最大迭代次数 $n$。 4. 融合排序：

$$ S_i^{()} = w_s^{()} \cdot S_{sparse,i} + w_d^{(*)} \cdot S_{dense,i} $$

以 $S^{(*)}$ 排序得到最终 top-$k$ 结果。

这样，系统能在无需重新检索的情况下，通过熵调整完成 " 自适应融合 “。

其他

Exploiting Sparsity for Long Context Inference: Million Token Contexts on Commodity GPUs, Ryan Synk, Monte Hoover, John Kirchenbauer, Neel Jain, Alex Stein, Manli Shu, Josue Melendez Sanchez, Ramani Duraiswami, Tom Goldstein

通过在 LLM 推理中使用向量数据库，解决长文本的性能问题！

LLM 的注意力是稀疏的，在每一步生成时，可以只选择与当前查询最相关的 k 个 token 参与注意力计算，而不是全部 N 个。在内存里维护一个 HNSW 索引，不断的把新生成的 token 的 key 向量塞进去，下次生成的时候查询 top K 的 key 向量，拿到对应的 value 向量，给回 GPU 做推理。

FrugalRAG: Learning to retrieve and reason for multi-hop QA, Abhinav Java, Srivathsan Koundinyan, Nagarajan Natarajan, Amit Sharma

大规模微调并非必要。一个精心设计的 ReAct 提示框架即可超过很多最新方法
引入 " 节俭性（Frugality）” 指标，关注模型在推理时的检索次数；
通过少量数据（仅 1000 条样本）结合 RL 微调，在保持准确性的同时将检索次数减半。

ConvSearch-R1: Enhancing Query Reformulation for Conversational Search with Reasoning via Reinforcement Learning, Changtai Zhu, Siyin Wang, Ruijun Feng, Kai Song, Xipeng Qiu

第一个无需外部监督的查询改写框架。通过强化学习直接利用向量数据库的检索信号优化查询改写，消除对外部改写监督的依赖。

从 SPTAG 到 SPANN，再到 SPFresh：亿级向量检索的技术脉络与细节

Thu, 09 Oct 2025 22:24:00 +0800

想象一下，你需要在千亿张名片堆成的月球般高的塔中，在一眨眼的时间内找到最相关的 10 张——这正是现代搜索引擎每天面临的挑战。从 Bing 的网页搜索到推荐系统，从问答助手到多模态检索，海量高维向量的近邻搜索（ANN）已经成为 AI 应用的基础设施。

但规模是残酷的。当数据量达到亿级、十亿级时，传统的内存索引方案要么内存爆炸，要么召回率惨不忍睹。更棘手的是，生产环境的数据始终在变化——每天有数百万新文档加入、旧内容下线，索引必须实时更新，同时保持毫秒级延迟和95%+ 的召回率。

这篇文章将带你走过微软研究院在向量检索领域的三个里程碑：SPTAG（2018）用树图混合导航破解高维诅咒，SPANN（2021）用内存 - 磁盘分层架构把容量扩展到十亿级，SPFresh（2023，SOSP）用增量自平衡协议彻底解决动态更新难题。我们不仅看"是什么"，更要看为什么这样设计，以及每个优化背后的工程直觉。

1. SPTAG：树 + 图的内存导航器

GitHub: https://github.com/Microsoft/SPTAG

SPTAG（Space Partition Tree And Graph） 是微软开源的近邻检索库，也是 Bing 搜索引擎的核心技术之一。它提供两套混合索引方案：KDT（kd-tree + RNG）和 BKT（Balanced k-means tree + RNG）。核心思想是用树做快速定位，用图做精确修正——树给搜索提供"方向感"，图保证局部连通性。

1.1 kd-tree 在 ANN 里的角色

kd-tree 是最经典的空间分割结构：递归选择方差最大的维度，用中位数作为切分点，把空间一分为二，直到叶节点的向量数量低于阈值。查询时从根节点出发，自顶向下选择"更靠近查询点"的子树，同时维护一个优先队列跟踪候选点。

优点：构建快（O(n log n)），搜索时能快速收敛到目标区域。

缺点：在高维空间（> 20 维）中，维度诅咒会让"距离上界估计"变得极其保守。一个点可能在超平面的"另一侧"，但实际上是最近邻——这就是著名的跨超平面近邻漏检问题。

1.2 Balanced k-means tree (BKT) 如何改进

BKT 用均衡 k-means 聚类取代轴对齐的超平面切分：每个节点把数据分成 k 个簇（通常 k=2 或 4），同时加入平衡约束，确保每个簇的大小接近。递归这个过程，直到叶节点足够小。

为什么需要平衡？ 如果某个簇特别大，搜索时进入该簇的代价会远高于其他分支，导致查询延迟不可预测。均衡性让树的每条路径"代价相近"，在高维数据上鲁棒性更强。

实现细节：SPTAG 的 BKT 使用层次化聚类，每次聚类前会对数据采样，避免全量 k-means 的计算开销。聚类结果会存储每个簇的质心，作为导航树的"路标"。

1.3 RNG（相对邻域图）的稀疏化魔法

RNG（Relative Neighborhood Graph）是一种稀疏化的邻接图。定义非常优雅：对于任意两点 p 和 q，仅当不存在第三点 r 使得

max(d(p, r), d(q, r)) < d(p, q)

时，才在 p 和 q 之间连边。直观理解：p 和 q 的"透镜区域"（两个圆的交集）中没有更近的点 r。

实践中的构建方式：SPTAG 先用近邻传播算法构建初始的 kNN 图（每个点连接 k 个最近邻），然后用 RNG 规则做修剪——删除那些有"捷径"可达的边。这样得到的图边数更少但连通性好，既节省内存，又避免搜索时陷入"边爆炸"。

为什么需要 RNG？ 完整的 kNN 图虽然召回率高，但在十亿级数据上，每个节点保存几百条边会让内存和遍历开销不可接受。RNG 通过稀疏化，把平均度数从 100+ 降到 20-30，同时保持可达性。

1.4 SPTAG 的检索流程（伪代码解析）

# 第一步：树导航，找到种子点
seeds = tree_search(BKT/KDT, query, num_seeds=10)

# 第二步：图上迭代扩展
candidates = PriorityQueue(seeds)
visited = set()

while len(visited) < MaxCheck and candidates:
    current = candidates.pop_best()  # 取出最近的候选
    
    for neighbor in RNG[current]:
        if neighbor not in visited:
            dist = distance(query, neighbor)
            candidates.push(neighbor, dist)
            visited.add(neighbor)

# 第三步：返回 Top-k
return candidates.top_k()

关键参数调优：

num_seeds：树返回的初始种子数，越多覆盖越广但开销越大
MaxCheck：最大访问节点数，控制召回率和延迟的权衡
RNG 的度数限制：平衡内存和连通性

性能数据：在 SIFT1M 数据集上，SPTAG-BKT 可以达到 95% 召回率，查询延迟 < 1ms（单线程，Intel Xeon）。

示意图（树上收敛 + 图内细化）：

          [Root]
         /  |   \
      [C1] [C2] [C3]  ← 树导航：快速定位到 C2 区域
       |     |     |
   RNG(C1) RNG(C2) RNG(C3)  ← 图扩展：在 C2 周围精修
            ↑
         种子点

2. SPANN：质心在内存、向量在磁盘的两层架构

论文：https://arxiv.org/abs/2111.08566

当数据量突破 10 亿向量时，把整个索引放内存的代价变得不可接受（需要数 TB 的 DRAM）。SPANN 的核心洞察是：我们真正需要快速访问的不是全部向量，而是"导航元数据"。因此，SPANN 设计了一个优雅的两层结构：

内存层：存储Posting 质心的 SPTAG 索引（通常只占数据集的 1-10%）
磁盘层：存储均衡的 Posting 列表（每个 Posting 是一组向量）

查询时，先在内存中用 SPTAG 找到最近的若干质心，然后并行读取对应的 Posting 列表，在全精度向量上做精排。

2.1 为什么"Posting 均衡"至关重要

如果 Posting 长度差异巨大（比如有的 Posting 有 10 万向量，有的只有 1000），查询会遇到严重的尾延迟抖动：

命中长 Posting 时，I/O 量和计算量暴涨
命中短 Posting 时，可能漏掉真正的近邻

SPANN 用多约束均衡聚类把 |X| 个向量划分成 N 个 Posting，目标是：

最小化 Var(|P_1|, |P_2|, ..., |P_N|)
同时保证 每个 P_i 的平均大小 ≈ |X| / N

层次化加速：直接在全量数据上做均衡聚类是 O(|X| · m · N)，不可行。SPANN 采用层次分组：先把数据粗略分成 k 组，每组再细分，把复杂度降到 O(|X| · m · k · log_k N)。

实际效果：在 SPACEV1B（10 亿向量）数据集上，SPANN 能把 Posting 长度的标准差控制在 平均值的 10% 以内，P99 延迟稳定在 2-3ms。

2.2 边界向量的"闭包赋值"策略

问题场景：假设查询点 q 最近的质心是 c1，但 q 的真实近邻 x 实际上属于邻近质心 c2 的 Posting。如果只搜索 P(c1)，就会漏掉 x。

SPANN 的解决方案：在构建索引时，识别"边界向量"并复制到多个 Posting。具体规则：

对于向量 x，设其最近的 K 个质心为 c_1, c_2, ..., c_K（按距离排序）
如果满足：
    d(x, c_j) ≤ (1 + ε1) · d(x, c_1)
则将 x 同时赋给 P(c_1), P(c_2), ..., P(c_j)

什么是边界向量？ 那些与多个质心距离几乎相同的向量——它们位于簇的边界，容易被遗漏。通过复制，确保只要搜索任一近邻 Posting，这些边界向量都有机会被召回。

参数 ε1 的权衡：

ε1 = 0.1：冗余度约 5-10%，召回率提升 2-3%
ε1 = 0.2：冗余度约 15-20%，召回率提升 4-5%

2.3 用 RNG 规则减少冗余复制

边界复制会导致一个新问题：如果有多个非常接近的质心（比如 c2、c3、c4 几乎在同一方向），把 x 复制到所有这些 Posting 会造成磁盘读浪费——因为这些 Posting 的内容高度重叠。

SPANN 借用 RNG 的思想：只保留"方向差异大"的多个簇。简化判定规则：

sorted_centroids = sorted(nearest_K_centroids, by_distance_to_x)

for j in range(1, K):
    c_j = sorted_centroids[j]
    c_prev = sorted_centroids[j-1]
    
    # 跳过 c_j，如果它"被 c_prev 遮挡"
    if distance(x, c_j) > distance(c_prev, c_j):
        continue
    
    # 否则，x 应该复制到 P(c_j)
    replicate(x, c_j)

直觉：如果从 x 看，c_j 被 c_prev “挡住了”（即去 c_j 的路上会先经过 c_prev），那么搜索时经过 c_prev 就能找到 x，不需要再复制到 c_j。

2.4 查询时的动态剪枝与质心替换

动态剪枝：不是固定搜 K 个 Posting，而是根据距离阈值动态决定：

threshold = (1 + ε2) * distance(query, nearest_centroid)

for centroid in candidate_centroids:
    if distance(query, centroid) <= threshold:
        fetch_and_search(Posting[centroid])

只有"距离足够近"的 Posting 才会被拉取，减少无效 I/O。

质心代表替换：用最靠近质心的真实向量替代几何中心做导航。好处：

几何中心可能不是数据集中的真实点，计算距离需要额外开销
真实向量已经在全精度数据中，可以直接复用

性能对比（SPACEV1B 数据集）：

SPANN vs DiskANN：2× 更快，达到 90% 召回率时延迟 ~1ms（DiskANN 需 2-3ms）
内存开销：32GB（仅存质心索引），vs DiskANN 的 60-100GB

3. SPFresh：在 SPANN 之上的在线增量更新与自平衡

论文：https://arxiv.org/abs/2410.14452（SOSP 2023）

SPANN 是静态构建的——索引一旦建成，更新就很麻烦。真实场景中，数据分布会持续漂移：新闻网站每天新增数千篇文章，电商平台商品库存实时变化。如果每次更新都全局重建，会遇到两大问题：

尾延迟飙升：重建期间 CPU/内存/I/O 被抢占，查询延迟从 2ms 飙到 20ms+
资源浪费：需要额外 60GB 内存和 10+ 核心，重建耗时数小时

SPFresh 在 SPANN 之上引入 LIRE（Lightweight Incremental Rebalancing）协议，把"重建"改成小步快跑的局部自愈，并配合用户态存储（SPDK）做可预测的 I/O。

3.1 LIRE 协议：五个操作，一个不变量

五类操作：

Insert：新向量直接追加到最近的 Posting
Delete：标记删除（不立即清理，延迟 GC）
Split：当 Posting 过长时，均匀分裂成两个
Merge：当 Posting 过短时，合并到邻近 Posting
Reassign：检查近邻 Posting，重新分配违反 NPA 的向量

不变量 NPA（Nearest Partition Assignment）：每个向量应归属于最近的 Posting 质心。Split/Merge 后，只对可能违反 NPA 的近邻 Posting触发 Reassign，工作集极小。

为什么 LIRE 高效？ 关键在于局部性：

Split 只影响被分裂的 Posting 及其邻居（通常 < 10 个 Posting）
Reassign 只评估边界向量（平均每次 ~5000 个向量，实际迁移 < 80 个）
收敛性保证：有限步内恢复 NPA 性质

实验数据（100 天，1% 日更新率）：

仅 0.4% 的插入触发重平衡
平均评估 5094 个向量，实际重分配 79 个
Merge 频率约 0.1%
级联分裂最长 3 层，平均 2 层

3.2 Version Map：并发友好的轻量元数据

每个向量维护 1 字节元数据：

7 bit 版本号（0-127 循环）
1 bit 删除标记

插入/重分配：版本号 +1（模 128）
删除：置位删除标记
查询：过滤 version < global_version 或 deleted = 1 的向量

并发控制：用 CAS（Compare-And-Swap） 原子更新 Version Map，写路径是 append-only，无需全局锁。查询可以在版本视图上无锁并行。

内存开销：10 亿向量只需 1GB 的 Version Map（vs DiskANN 额外 60GB 的辅助索引）。

3.3 存储层：SPDK vs RocksDB

SPDKStorage（主推方案）：

用户态 NVMe 驱动，绕过内核，减少上下文切换
提供原子 GET/APPEND/PUT 接口
降低写放大：append-only 写入，无需 compaction
可预测延迟：把瓶颈推到 SSD IOPS 上限，P99.9 稳定在 4ms

RocksDBStorage（备选方案）：

接口一致，部署门槛更低
自定义 MergeOperator 处理版本更新
但要承担 LSM-tree 的写放大和 compaction 抖动
P99.9 延迟会有周期性尖峰（compaction 期间可达 10ms+）

选择建议：

生产环境、性能优先 → SPDK
快速原型、已有 RocksDB 基础设施 → RocksDB

3.4 为什么 DiskANN 的全局重建会导致尾延迟飙升

DiskANN 的更新策略：

维护一个辅助索引累积更新
定期触发 streamingMerge，全局重建图结构
重建期间需要遍历并重连大量节点，计算密集

问题根源：

重建与查询竞争 CPU/内存/I/O
即便用"删旧边 + 补邻居的邻居"的轻量策略，也难阻止质量随时间下降
尾延迟锯齿：重建前积累劣化 → 重建期抖动 → 重建后短暂稳定 → 循环

实验对比（1% 日更新，100 天）：

DiskANN P99.9：正常 4-5ms，重建期飙到 20ms+（即便设置 10ms 硬超时）
SPFresh P99.9：全程稳定 ~4ms，对比基线平均 2.41× 更低

对比示意图：

DiskANN： ──┐         ┌── P99.9 延迟 ──┐         ┌──
            └─[Rebuild]─┘ (20ms+)      └─[Rebuild]─┘

SPFresh： ──────────────────────────────────────────
            (平稳 4ms，局部 Split/Merge 不可见)

4. 技术演进的全景总结

从 SPTAG 到 SPANN，再到 SPFresh，这三个系统展现了亿级向量检索的完整进化路径：

技术里程碑对比

维度	SPTAG (2018)	SPANN (2021)	SPFresh (2023)
规模	千万级（内存）	十亿级（混合）	十亿级（动态）
核心结构	树 + RNG 图	内存质心 + 磁盘 Posting	SPANN + LIRE 协议
内存开销	全量向量	1-10% 质心	1-10% 质心 + 1GB 元数据
查询延迟	< 1ms	1-2ms (P50)	~4ms (P99.9)
更新能力	支持但有限	静态构建	实时增量，无重建
尾延迟稳定性	中等	中等	优秀（2.41× 优于 DiskANN）

设计哲学的传承

SPTAG 的基因：树图混合导航成为后续系统的"内存层"基础
- SPANN 用 SPTAG-BKT 索引质心
- SPFresh 沿用这套导航结构
SPANN 的突破：内存 - 磁盘分层 + 均衡分区
- 把容量推到 SSD IOPS 极限
- 均衡性保证尾延迟稳定
SPFresh 的升华：局部自愈 + 版本控制
- 用 LIRE 避免全局重建
- 用 Version Map 实现并发友好的增量更新

适用场景指南

选择 SPTAG，如果你：

数据量 < 1000 万，内存充足
需要极致的查询延迟（< 1ms）
更新频率低（每天 < 1% 变化）

选择 SPANN，如果你：

数据量 > 1 亿，内存受限
可以接受静态构建（每周/每月重建一次）
尾延迟要求不极端（P99 < 5ms 可接受）

选择 SPFresh，如果你：

数据量 > 1 亿，且持续增长
需要实时更新（秒级延迟）
尾延迟要求严格（P99.9 < 10ms）
资源紧张（希望避免重建峰值）

从 RaBitQ Rust 移植看 AI 编程工具的实力差距：Claude Code vs Codex

Thu, 02 Oct 2025 21:40:00 +0800

项目背景：为什么选择 RaBitQ？

RaBitQ 是 NTU VectorDB 团队开发的向量量化算法，能够在 1-bit per dimension 的极限压缩下仍保持高精度，并提供理论误差界保证。这在向量数据库领域是一个重要突破。

该算法的核心优势包括：在 1-bit 量化下就能达到可用精度；使用 4-bit、5-bit、7-bit 分别可实现 90%、95%、99% 的召回率；支持基于位运算的快速距离估计。

RaBitQ 已被多个工业系统采用，包括 Milvus、Faiss、Elasticsearch（命名为 BBQ）、Lucene（命名为 BBQ）、CockroachDB、Volcengine OpenSearch 等。这些应用覆盖了从开源到商业的主流向量数据库。

我决定将 RaBitQ-Library 的 C++ 实现移植到 Rust，为 Rust 生态提供这一先进算法。项目地址：lqhl/rabitq-rs

这次移植让我意外地对比了两个 AI 编程工具的真实能力。

第一阶段：Codex 的功能实现

使用 OpenAI Codex 完成了基础工作：

核心量化算法的 Rust 实现
IVF 索引结构
基本搜索功能和数据集工具
后续的 k-means 优化和进度显示

代码能够编译运行，测试通过。看起来是个成功的移植。

性能现实

然而实际测试暴露了严重问题：Rust 版本比 C++ 原版慢了 10 倍以上。

对于一个以性能为核心价值的量化算法，这样的性能是不可接受的。我多次要求 Codex 优化，得到的回复是"已经完全按照 C++ 版本实现"。

检查代码后发现，Codex 做的是语法级别的转换：

fn quantize_vector(data: &[f32], centroid: &[f32]) -> Vec<u8> {
    let mut codes = vec![0u8; (data.len() + 7) / 8];
    for i in 0..data.len() {
        let rotated = data[i] - centroid[i];
        if rotated > 0.0 {
            codes[i / 8] |= 1 << (i % 8);
        }
    }
    codes
}

这段代码功能正确，但完全没有考虑 C++ 版本中的性能优化技巧。

第二阶段：Claude Code 的系统性优化

切换到 Claude Code 后，情况完全不同。

精准诊断

Claude Code 首先给出了完整的性能分析，指出 Rust 版本缺失的四个关键优化：

Fast Hadamard Transform (FHT) 旋转：C++ 使用 O(dim log dim) 的 FHT，Rust 用的是 O(dim²) 的矩阵乘法
faster_config 模式：C++ 可以预计算常数缩放因子，Rust 每个向量都要优化
查询预计算：C++ 缓存了查询相关常数，Rust 在重复计算
存储格式：C++ 只存 FHT 状态，Rust 保存了完整旋转矩阵

这些诊断都准确地对应了 C++ 实现的核心优化。

技术实现

1. Fast Hadamard Transform (commit 2039847)

实现了与 C++ 一致的 FhtKacRotator：

pub struct FhtKacRotator {
    signs: Vec<BitVec>,           // 4 轮符号翻转
    kac_walks: Vec<Vec<usize>>,   // Kac 随机游走
    dim: usize,
    padded_dim: usize,            // 对齐到 64 的倍数
}

impl FhtKacRotator {
    fn apply(&self, data: &mut [f32]) {
        for round in 0..4 {
            self.fht_inplace(data);
            self.apply_signs(data, round);
            self.apply_kac_walk(data, round);
        }
    }
}

这不是简单的代码翻译，而是理解了 FHT 在量化中的作用：通过快速的正交变换改善数据分布，使量化误差更均匀。

效果：旋转速度提升 10-100 倍，索引构建时间大幅缩短。

2. faster_config 模式 (commit 04c477a, bf08722)

添加了快速训练选项：

pub struct RabitqConfig {
    pub dim: usize,
    pub total_bits: usize,
    pub t: Option<f32>,  // None=动态优化，Some(t)=固定常数
}

impl RabitqConfig {
    pub fn faster(dim: usize, total_bits: usize, seed: u64) -> Self {
        let t_const = compute_const_scaling_factor(dim, seed);
        Self { dim, total_bits, t: Some(t_const) }
    }
}

通过采样 100 个随机向量预计算一个通用的缩放因子，避免了每个向量的独立优化。

效果：训练速度提升 100-500 倍，准确度损失小于 1%。

3. 查询预计算 (commit 04c477a)

引入了查询预计算结构：

pub struct QueryPrecomputed {
    query_norm: f32,
    k1x_sum_q: f32,
    kbx_sum_q: f32,
    binary_scale: f32,
}

在搜索开始时一次性计算这些常数，后续所有候选向量共享这些值。典型查询会检索 nprobe × cluster_size 个向量，这个优化消除了大量重复计算。

效果：查询性能显著提升。

4. 存储优化 (commit 2039847)

只保存 FHT 的紧凑状态：

原方案：dim × dim × 4 bytes（GIST-960 需要 3.6MB）
新方案：4 × (padded_dim/8 + padded_dim×2) bytes（GIST-960 只需 8.5KB）

效果：存储减少 99.7%，加载速度大幅提升。

优化成果

经过这些系统性改进，Rust 版本的性能已经接近 C++ 原版水平。

具体改进：

索引构建从慢 10+ 倍优化到接近 C++ 性能
查询性能大幅提升
存储开销从 +3.6MB 降至 +8.5KB
代码质量达到生产就绪标准

开发效率

Codex：数天时间完成功能，但性能不达标

Claude Code：一天内完成诊断和优化，产出 6 个高质量 commits：

2039847 - Align with C++ RaBitQ (FHT + storage)
04c477a - Add faster_config and query precomputation  
bf08722 - Add Faster Config Support for training
a391383 - Simplify Quantizer API
94b8ab9 - Apply Cargo Fmt
45531c1 - Fix Clippy Warnings

每个 commit 都有明确目标和完整实现，不是试错式的修补。

核心差异分析

代码理解的深度

Codex：看到 C++ 的矩阵乘法，翻译成 Rust 的矩阵乘法

Matrix R = gram_schmidt(random_matrix(dim, dim));

↓

let r = gram_schmidt(random_matrix(dim, dim));

Claude Code：理解旋转的真正目的，选择更优方案

// 知道 FHT 可以达到相同的统计性质，且快 100 倍
let rotator = FhtKacRotator::new(dim, seed);

优化意识

Codex：测试通过即认为任务完成，对性能问题缺乏主动意识

Claude Code：主动识别性能瓶颈。即使我只说"比 C++ 慢"，它也能精准定位到 FHT、faster_config、查询预计算和存储格式这四个关键点。

工程思维

Codex：关注功能实现

Claude Code：同时考虑性能、存储、可维护性。每次优化都明确说明：

性能提升幅度（10-100x、100-500x）
准确度影响（<1%）
存储开销（99.7% 减少）

这是工程师的思维方式，不只是"让代码跑起来"。

领域知识

这个项目涉及的专业知识包括：

高维向量的量化理论（Johnson-Lindenstrauss 引理）
Fast Hadamard Transform 及其在随机投影中的应用
SIMD 优化和缓存友好的数据布局
向量数据库的索引结构（IVF、HNSW）

Claude Code 在所有这些领域都展现出专家级的理解。它不只是知道代码怎么写，而是理解算法为什么这样设计、每个优化的理论基础是什么。

实用建议

基于这次经验，针对不同场景的建议：

性能关键的系统代码：

推荐 Claude Code
适用场景：数据库内核、编译器、量化算法、图形引擎
原因：需要深度优化和算法级理解

功能开发和快速原型：

Codex 或 Claude Code 都可以
适用场景：Web 服务、业务逻辑、工具脚本
原因：功能正确性比极致性能更重要

学习和实验：

任何工具都可以尝试
注意：需要人工审查，理解原理比代码更重要

结论：Claude Code 是最强的 AI 编程工具

基于 RaBitQ Rust 移植的实战经验：

维度	Codex	Claude Code
开发时间	数天	一天内
性能表现	比 C++ 慢 10+ 倍	接近 C++ 水平
代码质量	功能可用	生产就绪
问题诊断	需要明确指导	主动识别

Claude Code 就是目前最强的 AI 编程产品。

理由：

深度理解：不做表面翻译，而是理解算法本质和性能特征
主动优化：在短时间内识别并解决了四个关键性能问题
专家知识：掌握量化理论、FHT、SIMD 等专业领域知识
工程质量：产出的代码达到生产级标准，包括测试、文档、最佳实践

此外，我也通过 API 方式尝试了其他 AI 模型（包括 Kimi K2 和 GLM-4.6），效果都不如 Codex，更远远落后于原生 Claude Code。

对于需要高性能、高质量的严肃项目，Claude Code 是唯一的选择。

项目信息：

C++ 原版：VectorDB-NTU/RaBitQ-Library
Rust 移植：lqhl/rabitq-rs
论文：[SIGMOD 2025] Practical and Asymptotically Optimal Quantization

MineContext：字节开源的屏幕记录 AI，混合架构的平衡与妥协

Thu, 02 Oct 2025 10:00:00 +0800

你的 AI 助手知道你今天做了什么吗？还是只记得你刚才问的问题？

从 Rewind AI 的高价订阅，到 screenpipe 的纯本地方案，再到 DayFlow 的轻量级追踪，屏幕记录 AI 工具正在分化成不同路线。字节跳动开源的 MineContext 选择了一条中间道路：存储本地 + 分析云端的混合架构。这篇文章将深入分析其技术实现、与竞品的差异，以及这种妥协带来的利弊。

一、MineContext 是什么？

核心功能：挖掘而非记录

MineContext 每 5 秒截取一次屏幕，经过 pHash 去重后，批量发送给 VLM（Vision-Language Model）分析，提取出六种结构化上下文：

ENTITY_CONTEXT: 人物/产品/公司档案
activity_context: 活动记录（做了什么）
intent_context: 意图理解（想做什么）
semantic_context: 语义关联（相关知识）
procedural_context: 流程记录（怎么做）
state_context: 状态快照（当前状态）

然后主动生成日报、待办、洞察，而不是等你提问。这与传统"记录工具"（DayFlow）或"搜索工具"（OpenRecall）有本质区别——它是"挖掘工具"，从散落的截图中提取价值。

设计哲学

名字致敬 Minecraft：如果数字生活是散落的"方块"，MineContext 就是帮你挖掘、组合、创造的工具。

二、技术架构精要

分层架构

Server Layer (FastAPI)
  ↓
Manager Layer (Capture/Processor/Consumption/Event)
  ↓
Capture → Processing → Storage → LLM Integration

核心技术亮点

1. 智能去重（pHash）

def _is_duplicate(self, new_screenshot):
    new_phash = calculate_phash(new_screenshot)
    for cached in self._cache:
        # 汉明距离：允许 5 位不同（约 8% 容错）
        diff = bin(int(new_phash, 16) ^ int(cached['phash'], 16)).count('1')
        if diff <= 5:
            return True  # 重复，丢弃
    return False

效果：同一页面停留 1 分钟，12 次截图只保留 1 次，去重率 90%+。

2. 批处理管道

不是每张截图立即分析，而是：

累积到 20 张或超过 10 秒 → 触发批处理
异步并发调用 VLM API
平衡了实时性与 API 成本

3. 双轨存储

向量数据库（ChromaDB）：语义搜索（“我最近看过关于 RAG 的内容”）
文档数据库（SQLite）：精确查询（“今天下午 2-4 点做了什么”）

完整数据流

1. 捕获：mss 截图 → RawContextProperties
2. 去重：pHash 过滤重复 → 90% 去重率
3. 批处理：累积 20 张或 10 秒 → 触发分析
4. VLM 理解：GPT-4o Vision → 提取标题/摘要/实体/类型
5. 向量化：Embedding → 2048 维向量
6. 存储：ChromaDB + SQLite
7. 消费：定时生成日报/待办/洞察

三、与竞品的关键对比

产品矩阵

维度	MineContext	Rewind	screenpipe	DayFlow	OpenRecall
录制方式	截图 5s/张	连续录制	24/7 连续	1 FPS 录制	定时快照
理解方式	VLM (云端)	OCR (本地)	OCR (本地)	AI (可选本地)	小模型 (本地)
隐私模型	存储本地 + 分析云端	存储本地 + Ask 云端	100% 本地	可选 100% 本地	100% 本地
成本	$50-500/月 API	$30/月订阅	免费	免费	免费
智能程度	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐	⭐⭐
开源	✅ Apache 2.0	❌	✅ AGPLv3	✅ MIT	✅ AGPLv3

深度对比：核心差异

vs Rewind：

优势：VLM 能理解图像/布局，超越纯文本 OCR；开源可定制
劣势：API 成本可能超过 Rewind 订阅（$510/月 vs $30/月）
定位：多模态工作者（设计、视频）vs 文本密集型（编程、写作）

vs screenpipe：

优势：VLM 深度理解，企业级架构，Python 生态丰富
劣势：必须云端分析（隐私妥协），性能不如 Rust
定位：开箱即用 vs 极客自定义

vs DayFlow：

DayFlow 的聪明：1 FPS 连续录制（而非 MineContext 的离散截图），能准确统计"调试了 1.5 小时"；可选 100% 本地（Ollama）；25MB 应用，资源占用极低
MineContext 的优势：结构化信息提取（六种上下文类型），主动生成洞察（日报/待办），企业级架构
定位：“git log for your day”（时间追踪）vs “智能知识助手”（洞察生成）

竞争力矩阵

智能程度：Rewind > MineContext > DayFlow > screenpipe > OpenRecall
隐私保护：screenpipe > DayFlow (本地) > OpenRecall > MineContext > Rewind
成本效益：OpenRecall = DayFlow (本地) > Rewind > MineContext
轻量级：  DayFlow > screenpipe > MineContext > Rewind

MineContext 的位置：在隐私与智能的光谱上，处于"中间偏智能"的位置——比 screenpipe 更懂你，但比纯本地方案更有隐私风险。

四、批判性分析：妥协的代价

1. 隐私的"假本地"

问题：宣称"Privacy-First"，但每张非重复截图都发送到 OpenAI/Doubao。

# 每次批处理都会上传截图
image_data = base64.b64encode(open(screenshot_path, 'rb').read())
response = vlm_client.analyze(image_data)  # 发送到云端

风险：

截图可能包含密码、银行信息、私密聊天
即使声称"不存储"，传输过程仍有风险
对比 screenpipe/DayFlow 本地模式的 100% 本地

改进建议：

vlm_model:
  # 优先本地（质量略低但隐私好）
  - provider: "ollama"
    model: "llava:13b"

  # 仅重要内容用云端
  - provider: "openai"
    model: "gpt-4o"
    use_when: "importance > 80"

2. 成本的"假免费"

问题：“开源免费"掩盖了 VLM API 的实际成本。

成本计算：

每天 17,280 张截图（5s 间隔）
→ 去重 90% = 1,728 张
→ GPT-4o Vision: $0.01/张
→ $17.28/天 = $518/月

使用 Doubao（约 1/10 成本）：$50/月

对比：

Rewind 订阅：$30/月（固定，可预测）
DayFlow 本地：$0（完全免费）
MineContext：$50-500/月（不透明，取决于使用量）

结论：除非用本地 VLM 或控制使用量，否则 Rewind 订阅反而更便宜。

3. 时序理解的缺失

问题：每张截图独立分析，无法理解"流程”。

# 当前：孤立分析
screenshot_1: "用户在编辑代码"
screenshot_2: "用户在查看错误"
screenshot_3: "用户在搜索 Stack Overflow"

# 缺失的推理：用户在调试 bug（这是一个 1.5 小时的流程）

DayFlow 的 1 FPS 连续录制能捕获时序，MineContext 的 5 秒截图做不到。

改进方向：滑动窗口分析（分析当前截图 + 前 5 张截图的上下文）

4. 轻量级的差距

对比：

DayFlow: 25MB 应用，~100MB RAM，<1% CPU
MineContext: Python 环境 + 依赖，资源占用更高

Swift 原生 vs Python，在轻量级上有代差。

五、适用场景与选择建议

选择决策树

你的主要需求？
├─ 时间追踪 → DayFlow（1 FPS 连续 + 时长统计）
├─ 极致隐私 → screenpipe 或 DayFlow 本地模式
├─ 最强智能
│  ├─ 预算充足（>$50/月）→ MineContext（VLM 深度理解）
│  └─ 预算有限 → Rewind（$30/月固定）
├─ 轻量级 → DayFlow（25MB 应用）
└─ 企业定制 → MineContext（开源，字节背书）

适用人群

人群	推荐	理由
设计师/视频创作者	✅ MineContext	VLM 理解视觉内容
程序员	⚠️ DayFlow/screenpipe	时间追踪或隐私优先
隐私极客	❌ screenpipe	MineContext 有隐私妥协
预算有限者	❌ DayFlow 本地	API 成本不透明
企业用户	✅ MineContext	私有部署 + 定制

六、核心洞察总结

MineContext 的价值主张

✅ 混合架构的平衡：

存储本地（基本隐私）
推理云端/可选本地（能力灵活）
结果：70% 隐私 + 90% 智能

✅ 企业级开源：

字节背书（vs 社区项目）
生产级代码（vs PoC）
长期维护承诺

✅ 深度理解：

VLM 多模态（vs OCR 纯文本）
六种上下文类型（vs 单一记录）
主动生成洞察（vs 被动搜索）

三个关键妥协

❌ 隐私妥协：存储本地 ≠ 隐私安全（分析仍需云端） ❌ 成本妥协：开源免费 ≠ 实际免费（API 费用可能超订阅） ❌ 轻量妥协：Python 生态 ≠ 原生性能（资源占用高于 Swift）

行业启示

屏幕记录 AI 的三条路线：

闭源商业（Rewind）：追求极致体验，牺牲透明度
开源激进（screenpipe）：追求极致隐私，牺牲便捷性
开源务实（MineContext）：平衡各维度，但也继承各方妥协

未来趋势：

从"记录"到"理解"到"预测"（意图预测、主动干预）
从个人到团队（共享上下文池、协作记忆）
从云端到边缘（Apple Silicon NPU 本地推理）

最后的问题

MineContext 提出了三个值得思考的问题：

多模态理解 vs 纯文本 OCR，谁更有未来？
- MineContext: VLM 能理解布局、图像
- 代价：每张 $0.01，每月 $50+
混合架构 vs 纯本地/纯云端，如何平衡？
- MineContext: 存储本地 + 推理云端
- 妥协：隐私风险 + 网络依赖
主动生成 vs 被动搜索，用户更需要什么？
- MineContext: 定时生成日报、待办
- 挑战：如何避免信息过载？

这些答案，将由社区和市场共同书写。

项目信息：

GitHub: https://github.com/volcengine/MineContext
协议：Apache 2.0
Stars: 210+ (2025-10-02)
平台：macOS (当前)
技术栈：Python + FastAPI + ChromaDB + OpenAI

关键依赖：

fastapi          # Web 框架
openai           # LLM 接口
chromadb         # 向量数据库
mss, pillow      # 截图 + 处理
imagehash        # 感知哈希去重
langgraph        # Agent 编排

本文基于 MineContext v0.1.0 源代码分析。感谢字节跳动开源此项目，为社区提供了一个高质量的参考实现。

工程实践深度对比：Coze Loop 与 Langfuse 的 Tracing、实验与运维之道

Fri, 19 Sep 2025 08:00:00 +0800

在 LLM 应用的生产环境中，开发完成只是起点。真正的挑战在于能否持续优化 Prompt、可视化链路、开展评测与实验，并保证系统在高负载下稳定运行。Coze Loop 和 Langfuse 分别代表了闭环一体化与拼装式生态下的典型实践。

1. 架构与系统组件

Coze Loop

数据存储：MySQL 负责事务，ClickHouse 用于 Trace 与分析，Redis 提供缓存与快速查询，MinIO 存储日志和大对象。
消息队列：RocketMQ 用于高吞吐 Trace 与实验日志的异步传输，保障系统可扩展性。
闭环中台：Loop 与 Studio 深度绑定，形成统一的 Trace、实验和回放平台。

Langfuse

系统架构：Web 前端与 Worker 后端分离，Web 负责数据采集与展示，Worker 负责数据落盘与批处理。
存储层：Postgres 用于事务，ClickHouse 存储 Trace 与指标，Redis 作为队列，S3/Blob 存储大对象。
开放集成：支持 OpenTelemetry 标准，可将 Trace 数据同步到 Grafana、Datadog 等监控系统。

对比结论：Loop 架构更重，组件耦合度高，形成闭环；Langfuse 架构更轻，强调解耦和与现有 APM 工具的协作。

2. Tracing 与可观测性

Coze Loop

对话的输入、Prompt、模型调用、工具输出、最终结果都会完整 Trace。
Trace 数据经 RocketMQ 异步传输到 ClickHouse，支持高并发写入和后续回放。
优势是上下文与业务链路统一在一个平台内，开发和运维人员看到的是同一视角。

Langfuse

Tracing 的基本单元是 Trace → Observation → Score，结构清晰。
通过 SDK 可在任意应用中插入 Trace 代码，支持 Python、JS、Go 等多语言。
结合 OTel，可以把 LLM Trace 与传统应用指标合并监控。

对比结论：Loop 的 Trace 内聚，体验统一；Langfuse 的 Trace 解耦，适合混合系统和多工具环境。

3. Prompt 管理与实验

Coze Loop

内置 Prompt 管理功能，版本控制与实验集成在平台内。
支持回放功能，可以用历史对话数据重新运行新的 Prompt，快速比较效果。
评测结果与 Trace 打通，开发与运维都能看到指标。

Langfuse

Prompt 版本管理支持回溯和对比。
提供 datasets 功能，可批量运行实验。
支持 A/B 测试，结合 LLM-as-a-judge 自动给出实验结果评分。

对比结论：Loop 更适合在闭环环境中做实验，回放能力强；Langfuse 的实验体系更开放，适合在 CI/CD 流程中集成。

4. 可扩展性与运维

Coze Loop

依赖多个外部组件（ClickHouse、RocketMQ、Redis、MinIO），部署成本较高。
在字节内部实践背景下，设计偏向大规模高并发场景。
中小团队如果没有成熟运维体系，上手门槛较高。

Langfuse

可以轻量化部署（Docker Compose 一键启动），也可以分布式部署（Kubernetes + OTel + Grafana）。
SaaS 服务可直接使用，降低了团队的运维成本。
组件数量少于 Loop，运维复杂度更低。

对比结论：Loop 适合有大规模需求、运维资源充足的团队；Langfuse 更适合快速验证和中小团队使用。

5. 典型应用场景

Coze Loop
- 国内团队，尤其是已经采用火山引擎或字节系技术栈的公司。
- 强调闭环和统一体验，需要在内部平台中做全链路监控和实验的场景。
Langfuse
- 国际化团队，或者已有 Prometheus/Grafana/Datadog 等监控体系的公司。
- 需要在 CI/CD 流程中集成 LLM 评测，做快速迭代和持续实验的场景。

6. 总结

Coze Loop：功能闭环，Trace、实验、回放、评测一体化，适合大型团队构建统一的 LLM 运维平台；代价是组件复杂，部署与维护成本高。
Langfuse：架构解耦，Tracing 与评测独立成模块，易与现有工具链集成，运维成本低，适合中小团队和国际化场景。

选型建议

有能力运维复杂基础设施，追求闭环一致性 → 选 Loop。
需要灵活集成到现有体系，追求快速上线与低成本 → 选 Langfuse。

数据记忆与智能体编排：Coze Studio 与 Dify 的核心能力对决

Fri, 19 Sep 2025 08:00:00 +0800

在大模型应用的生命周期中，数据管理和记忆系统决定了模型能否在复杂业务里长期稳定运行，而 Agent 编排则决定了这些能力能否被高效组合成可复用的工作流。Coze Studio 与 Dify 在这两方面走出了不同的技术路线。

1. 向量库与 Embedding 接入

Coze Studio

支持 Milvus 与 VikingDB 两种向量库。
如果选择 Milvus，需在外部配置 Embedding 服务；使用 VikingDB 时可以直接调用内置的向量化能力，或通过 OpenAI、Ark、Ollama、HTTP API 方式接入其他模型。
Studio 将“向量化”和“存储”解耦（Milvus 模式）或合并（VikingDB 模式），方便在不同部署环境中取舍。

Dify

向量库支持面向广泛：Qdrant、Weaviate、Chroma、Pgvector、TiDB、Milvus/Zilliz、OpenSearch、腾讯云 VectorDB、Oracle 等。
可以在不同应用中为不同知识库选择不同的存储后端。
适合已有数据库资产的企业环境，也方便做异构实验。

对比结论：Coze Studio 在火山生态下的集成度更高，部署路径简单；Dify 提供更广的适配能力，适合对接异构数据库。

2. 知识库与 RAG 管道

Coze Studio

知识库检索节点内置在工作流画布中：上传文档 → 分块 → Embedding → 存储（Milvus/VikingDB）→ 检索 → 与上下文融合。
节点形式保证了知识库可被多个 Agent 或工作流复用。
VikingDB 模式下运维更简单，减少了 Embedding 服务的外部依赖。

Dify

提供更多检索策略：关键词、语义、混合、多路径检索，并可叠加 重排（Rerank）。
知识库可以直接从文档、网页、Notion、数据库等来源同步。
在工作流里，检索结果可以与变量、外部 API 输出一起传入 LLM 节点。

对比结论：Coze Studio 的知识库功能强调标准化和闭环，路径固定，易用；Dify 提供更复杂的检索和数据同步能力，适合有实验和定制需求的团队。

3. 记忆系统与变量建模

Coze Studio

提供 局部变量、全局变量和长期记忆变量 三种机制。
局部变量只在单个节点或会话中生效；全局变量跨节点、跨工作流共享；长期记忆变量持久化到数据库或 Redis。
所有变量都在工作流画布中可视化，生命周期和作用范围直观清晰。

Dify

Conversation Variables：为单次会话保存状态，例如用户偏好、临时上下文。
Knowledge 数据集：承担长期记忆的角色，存储跨会话知识。
社区扩展（如 LongTermMemory 工具）进一步增强 Knowledge 的长期记忆功能，可以为每个用户维度建立独立记忆库。

对比结论：Coze Studio 用“一套变量体系”统一了不同层次的记忆，降低了使用门槛；Dify 将短期与长期记忆分层，工程语义更清晰，适合做扩展和治理。

4. 数据流管理

Coze Studio

数据流内聚：知识库节点和变量系统都在同一平台内，数据在上传、分块、检索、融合的过程中不需要跨系统跳转。
适合强调快速落地的业务场景，外部依赖少。

Dify

数据流解耦：每个环节都可替换，从分块策略到向量库，再到检索/重排。
支持外部数据同步任务，能无缝对接已有企业系统。

对比结论：Coze Studio 的数据流闭环简洁；Dify 的数据流灵活，能适应复杂的数据治理环境。

5. Agent 编排

Coze Studio

提供可视化工作流画布，Agent 可以直接调用工作流。
节点类型丰富：LLM 模型调用、知识库检索、插件调用、条件判断、代码执行等。
Agent 与 App 的区分清晰：Agent 负责对话和工具调用，App 则是带 UI 的完整应用；Agent 可以绑定知识库、Prompt、插件和工作流。
模型服务配置直观，支持在工作流中指定模型服务和 ID，切换容易。
优点是上手快，非工程背景的人也能配置复杂流程；不足在于公开资料中并未强调“并行节点”的能力。

Dify

区分 Agent 模式 和 Workflow 模式：
- Agent 模式包含上下文记忆、工具调用、动态分支，更适合对话式场景。
- Workflow 模式是节点编排，适合结构化任务。
Workflow 节点支持并行执行，可以在一个节点同时触发多个子任务，然后再合并结果。
节点可插入外部 API、检索、变量等，调试阶段能直接查看输入输出、token 消耗和运行时间。
还提供模板库，便于快速创建 FAQ、客服等场景的 Agent。

对比结论：Coze Studio 的 Agent 编排强调易用和可视化，适合跨角色团队协作；Dify 的 Agent 模式和 Workflow 模式分工明确，调试能力强，更适合工程团队做复杂业务逻辑。

6. 总结

在数据与记忆和 Agent 编排方面，两者有明显差异：

Coze Studio：知识库和变量体系紧耦合，数据流闭环，Agent 编排偏可视化和易用性，适合国内、产品驱动团队。
Dify：支持广泛的向量库和检索策略，记忆分层明确，数据流解耦，Agent 编排能力灵活，调试功能完善，适合国际化和工程驱动团队。

选型建议

如果目标是快速构建可用的智能体，降低运维与学习成本，Coze Studio 更合适。
如果目标是做复杂业务编排、实验和大规模扩展，Dify 更合适。

闭环一体化 vs 拼装式生态：Coze Studio+Loop 与 Dify+Langfuse 的架构对决

Fri, 19 Sep 2025 08:00:00 +0800

1. 背景与开源策略

大模型应用的开发平台，正在分化为两条路线：

字节跳动主导的 Coze Studio + Coze Loop，强调内聚闭环；
国际社区主导的 Dify + Langfuse，强调开放拼装。

这背后其实是两种开源策略。

字节跳动：通过 Studio 和 Loop 的开源，强化火山引擎和 BytePlus 的技术生态。Studio 在功能设计上对接 Milvus、VikingDB 等火山系产品，Loop 的数据存储和消息队列也契合字节在内部的基础设施习惯。这种开源模式本质上是“国内生态延伸”，希望把开发者引入其云和数据库体系。
Dify 与 Langfuse：两者起源不同，但都是纯社区导向。Dify 的目标是成为“开源的 AI 应用开发框架”，支持尽可能多的模型和数据库；Langfuse 的目标是成为“LLM 的 Datadog”，强调 tracing 和评测的标准化。它们与任何云厂商没有强绑定，社区活跃度高，生态扩展性强。

2. 架构与组件对比

Coze Studio+Loop

Coze Studio
- 后端：Go 语言，基于 CloudWeGo 的 Hertz（HTTP）+ Kitex（RPC）。
- 架构风格：微服务 + 领域驱动设计，模块包括工作流、知识库、Agent、插件。
- 前端：React + TypeScript，支持低代码画布。
Coze Loop
- 存储：MySQL（事务）、ClickHouse（分析/Trace）、Redis（缓存）、MinIO（对象存储）。
- 队列：RocketMQ，用于异步任务与高吞吐日志。
- 能力：全链路 Trace、Prompt 实验、指标评测。
特点：工程化程度高，和字节内部技术栈保持一致。

Dify+Langfuse

Dify
- 后端：Python（Flask/FastAPI），前端 Next.js。
- 架构：偏单体，但可通过插件接入外部模型、数据库、工具。
- 功能：Chatflow、Prompt IDE、Knowledge 管理。
Langfuse
- 架构：Web + Worker 两容器。
- 存储：Postgres（事务）、ClickHouse（Trace）、Redis（队列）、S3（对象存储）。
- 特性：支持 OpenTelemetry，能接入现有监控/APM。
特点：组件解耦，国际化社区驱动，扩展性更强。

3. 开发体验差异

Coze Studio：面向产品和业务人员，低代码和变量系统让非工程背景的人也能构建应用。
Dify：面向工程师，Prompt IDE、版本控制、插件化，灵活但学习成本高。

4. 开源生态的差别

Coze Studio+Loop
- 背后有字节团队主导，产品设计偏向火山生态。
- 社区贡献模式有限，更像是“厂商开源产品”，而不是纯社区项目。
- 文档和生态偏中文开发者，国际化不足。
Dify+Langfuse
- 社区驱动强，贡献者多元。
- 快速支持新模型、新数据库、新框架（LangChain、LlamaIndex）。
- 与 OTel、Grafana、Datadog 等监控体系集成顺畅，国际化生态丰富。

5. 哲学与定位差异

Coze Studio+Loop：目标是一个平台解决开发和运维的所有环节。代价是运维组件复杂，生态兼容性弱。
Dify+Langfuse：目标是让开发和运维工具解耦，按需拼装。代价是功能分散，需要切换上下文。

6. 结论

Coze Studio+Loop 是厂商主导的一体化方案，适合国内团队，尤其是依赖火山引擎的用户。 Dify+Langfuse 是社区驱动的拼装式组合，适合国际化和工程驱动团队，能与现有系统深度融合。

选型关键在于：

如果团队希望降低学习成本，追求闭环一致性，选择 Coze Studio+Loop；
如果团队已有成熟运维体系，追求灵活性和生态扩展，选择 Dify+Langfuse。

我的壶铃 Rite of Passage 训练心得与完整计划解析

Mon, 01 Sep 2025 23:30:00 +0800

我从 7 月 11 日开始，遵循 Pavel 在 Enter the Kettlebell 一书中提出的 Rite of Passage 训练计划。到 8 月 30 日进行最终测试时，我使用 24 公斤壶铃的高翻和推举次数，从最初的 3 次大幅提升到了 8 次。这个计划的效果给我留下了深刻印象，下面我将详细解析这个计划的构成，并附上我的完整训练记录。

Rite of Passage 训练计划详解

这个计划以周为单位，围绕三个核心训练日展开，分别是周一的轻量日，周三的中量日，和周六的重量日。计划涉及三个壶铃动作：

壶铃高翻和推举 Clean & Press
壶铃摆荡 Swing
壶铃抓举 Snatch

周一轻量日

轻松的高翻和推举：完成 5 组阶梯，阶梯数比周六的极限日低两阶。
轻松的抓举：通过掷骰子来决定训练时长，然后用这个时间内极限能力的百分之五十到六十来完成。一旦感觉动作要变形，就切换为高拉。

周二多样化训练日 (可选)

可以做任何你想做的轻松训练。

周三中量日

中等强度的高翻和推举：完成 5 组阶梯，阶梯数比周六的极限日低一阶。
中等强度的摆荡：同样通过掷骰子决定训练时长，用极限能力的百分之七十到八十来完成。

周四多样化训练日 (可选)

可以从以下选项中选择一项或多项来做：

5 组 5 次的负重高翻，和 5 组 1 次的土耳其起立交替进行，使用的壶铃要比你做阶梯组的更重。组间充分休息。
用比你计时组更重的壶铃，做 2 到 3 组 5 到 10 次的摆荡，或 2 到 3 组 1 到 10 次的抓举。
做任何你想做的轻松训练。

周五休息日

周六重量日

极限高翻和推举：完成 5 组阶梯，直到力竭。
- 选择一个你只能推 5 到 8 次的壶铃重量开始。
- 从 (1, 2, 3) 的阶梯开始，当你某天无法完成第 3 次时，训练就结束。
- 当你能完成 5 组 (1, 2, 3) 时，保持 5 组不变，向 (1, 2, 3, 4) 的目标努力。
- 当你能完成 5 组 (1, 2, 3, 4) 时，再向 5 组 (1, 2, 3, 4, 5) 努力。
- 当你最终完成 5 组 (1, 2, 3, 4, 5) 时，就可以换更重的壶铃，从头开始新的循环。
- 组和阶梯之间不要着急，保证充分休息。
极限摆荡：掷骰子决定训练时长，然后在规定时间内尽你所能完成最多的次数。
定期测试：每隔 4 到 8 周，可以将周六的常规训练替换为一次正式的高翻和推举与抓举测试。

周日休息日

训练实录

在看我的记录前，先了解一下这些缩写和术语。

L/R: 表示左右手交替完成。例如阶梯 1/2/3，指的是左 1 右 1，左 2 右 2，左 3 右 3。
C&P: 高翻和推举，即 Clean & Press。
Snatch: 单手抓举。
Swing: 默认是双手摆荡。
H2H Swing: 换手摆荡，即 Hand to Hand Swing。
SA Swing: 单手摆荡，即 Single-Arm Swing。
我的抓举和摆荡变式，通常都采用 EMOM (every minute on minute)，即每分钟做一组（训练组间休息总共 1 分钟）。

星期	日期	训练内容
Fri	2025 年 7 月 11 日	20kg KB C&P 6 x 1/2/3 L/R; 16kg KB snatch 10 x 5/5
Mon	2025 年 7 月 14 日	16kg KB snatch 10 x 5/5; 20kg KB C&P 4 x 1/2/3
Wed	2025 年 7 月 16 日	20kg KB C&P 5 x 1/2/3 L/R; 24kg KB H2H swing 11 x 10
Sat	2025 年 7 月 19 日	20kg KB C&P 5 x 1/2/3/4 L/R; 24kg KB 11 x 10 SA swing
Mon	2025 年 7 月 21 日	20kg KB C&P 5 x 1/2 L/R; 16kg KB 8 x 10 snatch
Wed	2025 年 7 月 23 日	20kg KB C&P 5 x 1/2/3 L/R; 24kg KB 5 x 10 SA swing
Sat	2025 年 7 月 26 日	20kg KB C&P 2 x 1/2/3/4/5 L/R, 3 x 1/2/3/4 L/R; 24kg KB 12 x 10 SA swing
Mon	2025 年 7 月 28 日	20kg KB C&P 5 x 1/2/3 L/R; 16kg KB 2 x 10 snatch
Mon	2025 年 8 月 4 日	20kg KB C&P 5 x 1/2/3 L/R; 16kg KB 6 x 10 snatch
Wed	2025 年 8 月 6 日	20kg KB C&P 5 x 1/2/3/4 L/R; 24kg KB 9 x 10 SA swing
Mon	2025 年 8 月 11 日	20kg KB C&P 3 x 1/2/3/4/5 L/R, 2 x 1/2/3/4 L/R; 32kg KB 8 x 10 swing
Wed	2025 年 8 月 13 日	20kg KB C&P 5 x 1/2/3/4 L/R; 16kg KB 3 x 10 snatch
Sat	2025 年 8 月 16 日	20kg KB C&P 4 x 1/2/3/4/5, 1 x 1/2/3/4 L/R; 24kg KB 5 x 10 swing
Wed	2025 年 8 月 20 日	20kg KB C&P 5 x 1/2/3/4 L/R; 24kg KB 6 x 10 SA swing
Sat	2025 年 8 月 23 日	20kg KB C&P 5 x 1/2/3/4/5 L/R; 24kg KB 10 x 10 swing
Mon	2025 年 8 月 25 日	20kg KB C&P 5 x 1/2/3 L/R, 16kg snatch 6 x 10
Wed	2025 年 8 月 27 日	20kg KB C&P 5 x 1/2/3/4 L/R, 24kg H2H swing 3 x 10
Sat	2025 年 8 月 30 日	KB C&P 16kg 1 x 3, 20kg 1 x 3, 24kg 1 x 3, 1 x 6, 1 x 8

从《人月神话》到 AI 编程：软件工程的困境与演进

Wed, 20 Aug 2025 22:50:00 +0800

软件开发如同一个巨大的焦油坑，许多团队在其中挣扎。虽然大多数项目最终能交付可运行的系统，但只有极少数能满足预期目标、时间进度和预算要求。布鲁克斯（Frederick P. Brooks）在《人月神话》中深刻揭示了这一现象，并提供了经久不衰的见解。

近半个世纪后，人工智能编程助手的出现，让我们不得不重新思考：这些经典问题是否得到了解决？还是只是换了一种形式存在？

《人月神话》的经典问题

布鲁克斯在《人月神话》中揭示了软件工程中的核心困境，这些洞察至今仍然熠熠生辉。

人月神话本身就是一个危险且具有欺骗性的概念。它错误地假设人力和时间可以简单互换。布鲁克斯法则明确指出：向进度落后的项目中增加人手，只会使进度更加落后。原因是增加人手需要额外的沟通成本、培训开销和任务重新分配的开销。

概念完整性是系统设计中最重要的考虑因素。为了反映一系列连贯的设计思路，宁可省略一些不规则的特性和改进，也不提倡独立和无法整合的系统。这一观点在今天看来仍然极具价值。

第二系统效应是指设计师在开发第二个系统时倾向于过度设计，添加大量修饰功能和想法。这种倾向源于在第一个系统中被谨慎推迟的许多功能的积累。

缺乏交流是大型项目失败的主要原因之一。布鲁克斯用巴比伦塔的失败来说明这一点：因为左手不知道右手在做什么，进度灾难、功能不合理和系统缺陷纷纷出现。

软件开发的根本困难在于其内在的复杂性、一致性要求、可变更性和不可见性。布鲁克斯在著名的没有银弹章节中指出，软件实体可能比人类创造的其他任何实体都要复杂，而这种复杂度是不可改变的根本属性。

AI 编程时代的双重影响

人工智能编程工具的出现，正在改变软件工程的面貌，但对《人月神话》中提出的问题，它既不是灵丹妙药，甚至还在某些方面带来了新的挑战。

潜在的改善

AI 编程工具似乎为一些问题提供了缓解途径。它们能够加速编码和调试等具体任务，减少对单纯“人月”的依赖。AI 还可以协助完成重复性任务和代码生成，一定程度上提升了开发效率。

使用适当的高级语言，编程的生产率可以提高 5 倍。AI 编程工具进一步放大了这一效应，使开发者能够更快速地实现功能。

在知识传递方面，AI 编程助手能够快速分享最佳实践和解决方案，减少了团队成员间的知识差异。它们还可以提供代码审查和规范检查，帮助维持代码质量。

新的挑战与加剧的问题

AI 编程也带来了新的挑战，甚至加剧了一些经典问题。

概念完整性面临严峻挑战。当多名开发者或多个 AI Agent 基于不同的提示词生成代码时，如果没有严格的架构约束，很容易导致系统概念混乱、风格不一。维持系统的一致性变得更加困难。

第二系统效应的风险被显著放大。AI 使添加功能变得极其容易，可能诱发不受控制的功能蔓延，加剧系统臃肿。低成本扩展的诱惑使得架构师需要更强的克制与判断力。

信任债务成为新型技术债。对 AI 生成代码的盲目信任可能导致潜在的质量风险。团队必须建立严格的 AI 代码评审机制，不能假设 AI 生成的代码总是正确或最优的。

沟通复杂性的形式发生了转变。传统的沟通成本可能转化为人类与 AI Agent 之间、AI Agent 与 AI Agent 之间的协调与验证成本。这种新型沟通同样复杂且需要管理。

布鲁克斯曾指出：软件开发的根本任务是打造构成抽象软件实体的复杂概念结构，次要任务才是用编程语言表达这些抽象实体。AI 编程主要帮助的是次要任务，而本质复杂性仍然需要人类来应对。

未来发展方向

基于《人月神话》的智慧和 AI 编程的现状，我们可以展望几个未来的发展方向。

重构人机协作模式

未来的高效团队可能演变为人类架构师加 AI Agent 群的模式。人类架构师专注于制定精准的规则、约束和提示词策略，确保概念完整性，并做出高级决策和创造性思考。AI Agent 则在严格约束下生成代码、完成具体任务、进行初步测试和评审。

这种模式要求人类开发者提升架构能力、提示词工程能力、审查和验证 AI 输出的能力，以及定义问题和分解任务的能力。正如布鲁克斯所强调的，人员的素质、组织和管理是项目成功的关键。

强化 AI 时代的架构约束

在 AI 生成大量代码之前，投入更多精力在前期设计、需求澄清和接口契约的定义上变得更为关键。这有助于减少 AI 在模糊上下文中自由发挥带来的后续问题。

未来的架构设计不仅需要人类理解的文档，更需要能直接指导和控制 AI 行为的形式化、机器可读的规范与契约。精心设计的提示词将成为新的、关键的设计文档，是向 AI 传递架构意图和约束的重要载体。

拥抱新的开发流程

传统的敏捷开发流程在面对 AI 时显得有些力不从心，因为它缺乏对 AI 不确定性的管理。我们需要更强调前期的清晰定义和后期的严格验收。

文档先行和规范驱动的流程变得尤为重要。坚决摒弃直接让 AI 写代码的冲动，必须先写文档，明确需求、架构、接口和验收标准。将大型需求拆解成原子级的、AI 能稳定完成的小任务，每个任务都应有明确的输入、输出和验收标准。

培养新时期的开发者和团队

谷歌科学家斯蒂芬妮·德鲁加指出，编程的核心价值在于思维塑造。它训练的是一种计算思维与算法思维：将复杂行为和交互进行结构化、逻辑化拆解并描述的能力。

未来的开发者需要具备批判性思维和问题解决能力，能够评估和修正 AI 生成的结果。同时，他们还需要协作能力，因为即便 AI 无处不在，世界的运转仍系于人的联结。

结语

《人月神话》中的智慧在今天依然闪耀着真理的光芒。AI 编程没有消除这些经典问题，反而为其增添了新的注脚。

布鲁克斯的没有银弹的论断在今天依然适用。AI 是强大的杠杆，可以放大开发者的能力，但它无法替代人类的批判性思维、架构设计、对本质复杂性的掌控以及项目管理的艺术。

未来的成功组织，将是那些能将人类智慧与 AI 能力创造性结合，并建立起适应人机协作新范式的流程与文化的组织。他们不会盲目崇拜 AI，也不会对其嗤之以鼻，而是将其视为一个需要精心管理和引导的强大合作伙伴，同时始终对软件开发的本质复杂性保持敬畏。

软件系统的复杂性仍然是人类创造中最错综复杂的事物。在这个 AI 时代，我们仍然需要布鲁克斯所强调的上帝所赐予的谦卑，认识到自己的不足和容易犯错，才能在焦油坑中继续前行，创造出真正有价值的软件产品。

权衡的艺术：为什么说 LEANN 为 RAG 应用选错了优化方向？

Sat, 09 Aug 2025 22:00:00 +0800

每当学术界的顶尖人物，尤其是像来自伯克利的 Ion Stoica（Spark 和 Ray 的联合创始人）和 Matei Zaharia（Spark 的作者和 Databricks 的 CTO）这样曾定义了数个计算范式的大师发布新作时，整个行业都应该予以关注。他们的新作 LEANN: A Low-Storage Vector Index (arXiv, GitHub) 也不例外，它旨在解决一个长期困扰向量搜索领域的难题：巨大的存储开销。

论文的核心承诺极具吸引力：LEANN 能够将向量索引的存储大小，降低到原始数据体积的 5% 以下，相比传统方案实现了高达 50 倍的压缩。这是一个惊人的数字。但为了实现它，LEANN 提出了一种激进的架构性权衡——以显著增加的计算成本和查询延迟，换取极致的存储压缩。

问题在于，在 2025 年，这个交易还划算吗？

LEANN 的架构：深入理解其核心权衡

要理解 LEANN 的价值，首先要理解它的工作原理。其设计的出发点是，索引体积的罪魁祸首是存储了数百万甚至数十亿个高维 embedding 向量。因此，LEANN 的选择是：根本不存储它们。

这一决策引出了一整套精巧但复杂的设计：

1. 离线阶段：精密的图“骨架”构建

在索引构建时，LEANN 并非简单地丢弃一切。它首先构建一个标准的 HNSW 图，然后通过一种名为“高保留度图剪枝”的算法对其进行“瘦身”。该算法会识别出图中连接度最高的少数“枢纽”节点，并保护它们的连接；而对其他大量普通节点，则大幅削减其连接数，只保留与枢纽节点的通路。

完成这步后，所有完整的 embedding 向量被彻底丢弃，最终只留下这个轻量级的图“骨架”存入磁盘。这从根本上解决了存储问题。

2. 在线阶段：按需发生的“昂贵”计算

当查询请求到来时，真正的挑战开始了。由于没有现成的向量，LEANN 必须在途中将它们创造出来。

两阶段搜索：它首先使用预存的、极度压缩的 PQ 编码进行一次快速的近似搜索，目的是从图中筛选出一个规模很小的、最有可能包含答案的候选节点集。
选择性重新计算：接下来是整个流程中最昂贵的一步。只有被选中的那一小撮候选节点，才会触发一次完整的神经网络前向传播。系统会调用原始的 embedding 模型（如论文中使用的 110M 参数的 Contriever 模型），为这些节点动态生成全精度的 embedding。
动态批处理：为了提升效率，这些计算请求会被攒成一个批次，统一交由 GPU 处理，以最大化硬件利用率。

数据分析：当论点遭遇现实

LEANN 的架构设计逻辑自洽且技术上令人印象深刻。但当我们审视论文自己的实验数据时，这个方案的现实可行性开始出现裂痕。

1. 无法回避的延迟成本

论文的实验数据坦诚地揭示了计算成本：对于一个批次的处理，76% 的时间都消耗在了 embedding 的重新计算上。最终，在强大的数据中心级 GPU NVIDIA A10G 上，一次高精度检索需要“不到 2 秒”。

然而，当测试平台切换到更符合“边缘端”定义的 Apple M1 Ultra 时，其性能比 A10G 慢了 2.28 到 3.01 倍。这意味着在消费级设备上，用户为一次本地搜索付出的时间成本是数秒甚至更长。这并非微不足道的延迟，而是其架构带来的必然结果。

2. 对“存储危机”前提的再审视

LEANN 的整个动机，都建立在边缘设备存在“存储危机”的叙事上。这个叙事在智能手机等场景下部分成立。但在论文自己选择测试的 M1 MacBook 等现代笔记本电脑上，TB 级的 NVMe SSD 已经相当普及。在这种设备上，为了一个核心功能，付出 1.5 到 2 倍的存储开销，往往是一个完全可以接受的工程选择。

更有趣的是，论文自己的一项消融研究，无意中削弱了其核心论点。研究发现，如果将模型从 110M 参数的 Contriever 更换为 34M 参数的 GTE-small，检索速度能提升 2.3 倍，而最终任务精度损失极小。这恰恰证明，通过选用更高效的现代模型，可以在不牺牲太多精度的前提下大幅降低计算成本，这似乎是一条比 LEANN 的极端方案更均衡、更具吸引力的路径。

3. 对“高精度”的执念与 RAG 的实践

LEANN 追求高精度的初衷值得肯定。它通过重新计算来使用全精度向量，避免了量化带来的信息损失。

但在大多数 RAG 应用的实践中，这种对初始检索阶段绝对精度的追求，可能是一种过度优化。初始检索更多扮演的是一个“过滤器”的角色。由现代量化技术（论文在相关工作中也提到了 RabitQ）带来的微小精度损失，在经过 Rerank 模型和最终 LLM 的处理后，对生成答案的质量影响通常微乎其微。相比之下，用户对延迟的感知却非常敏感。

被遗忘的维度：功耗与系统响应

对于以电池供电的边缘设备而言，还有一个至关重要的维度：功耗。

为了一次搜索就完整运行一个庞大的神经网络模型，无疑是一项高能耗的操作。这将直接影响笔记本电脑的续航和手机的发热。遗憾的是，通篇论文并未提供任何关于能耗影响的分析，对于一个为边缘端设计的方案来说，这是一个重大的疏漏。

此外，高强度的计算任务会持续占用 CPU 和 GPU 资源，可能导致系统上其他应用的响应变慢，影响整体用户体验。

结论：为昨日问题打造的优雅方案

LEANN 无疑是一项技术上极为出色的研究，它展现了顶级研究者在算法和系统设计上的深厚功力。

但它所提供的核心交易——用巨大的计算和延迟成本换取存储空间的节省——与当前的技术发展趋势显得有些脱节。边缘端的存储正变得越来越大、越来越便宜，而算力，特别是能效比高的算力，依然是宝贵的资源。

LEANN 用计算的“蛮力”解决了存储问题，却也因此在延迟、系统响应，以及被忽略的能耗上，创造出了新的、可能更棘手的问题。它是一个优雅的答案，但回答的，或许已不再是当今行业最迫切需要解决的问题了。

解构 Claude Code：一次版本间的进化之旅 (v1.0.0 vs v1.0.72)

Sat, 09 Aug 2025 21:10:00 +0800

在 AI 驱动的软件开发时代，我们赖以生存的工具正以惊人的速度迭代。作为开发者，我们不仅要适应这些工具，更要洞察其设计哲学。Anthropic 的 Claude Code，作为业界的先行者，其核心——System Prompt（系统提示词）——的每一次演进，都如同一扇窗口，让我们得以窥见 AI 编码助手未来的蓝图。

最近，我有机会深入对比了 Claude Code 两个关键版本（1.0.0 和 1.0.72）的 System Prompt。这绝非一次简单的更新，而是一场深刻的、面向未来的进化。

在开始解构之前，如果你想亲自探索这两个版本之间的每一个字符差异，强烈推荐访问这个由 Mario Zechner 创建的神奇网站：

cchistory - Claude Code Version History

更酷的是，Mario Zechner 还写了一篇精彩的文章，讲述了他如何“黑”进 Claude Code 并提取出这些宝贵的历史版本 Prompt。对于任何对 AI 内部工作原理好奇的开发者来说，这都是一篇必读的探险笔记：

cchistory: Tracking Claude Code System Prompt and Tool Changes

现在，让我们一同深入这场穿越版本的进化之旅。

1. 安全策略的演进：从“守门员”到“安全后卫”

这是两个版本间最核心、也最耐人寻味的变化。它标志着 Claude Code 在开发者工具链中角色的重大转变。

v1.0.0 (守门员): 安全策略是“一刀切”的。IMPORTANT 指令明确要求：“Refuse to write code or explain code that may be used maliciously”。这就像一个尽职的守门员，任何有潜在风险的球（请求）都会被直接挡在门外。这种方式虽然绝对安全，但也可能错杀许多合法的安全研究或防御性编程任务。
v1.0.72 (安全后卫): 策略变得更加精细和务实。指令更新为：“Assist with defensive security tasks only. Allow security analysis, detection rules, vulnerability explanations…”。Claude Code 的角色从一个单纯的“拒绝者”转变为一个主动的“防御者”。它现在可以帮助你分析漏洞、编写检测规则，成为你在代码安全攻防战中的得力后卫。

其弦外之音在于：这一变化反映了 Anthropic 对 AI 在安全领域角色的成熟思考。他们意识到，一味地封堵不如智慧地疏导。通过将 AI 的能力引导至“防御端”，不仅能有效规避风险，更能赋能开发者，提升整个软件生态的安全性。这是一种更高级、更实用的 AI 安全伦理实践。

2. 工具集的革命性升级：更强大，更专业

如果说 v1.0.0 的工具箱是精良的，那么 v1.0.72 的工具箱堪称“豪华”，不仅增加了新工具，还对现有工具进行了“赛博格”般的强化。

类别	v1.0.0	v1.0.72 (主要改进)
后台任务	无	➕ 新增 `BashOutput` & `KillBash`，赋予了管理和监控后台 `bash` 进程的能力。
文件编辑	`Edit` 工具需要精确匹配，否则失败。	⬆️ `Edit` & `MultiEdit` 增加 `replace_all` 参数，可以轻松实现全局重命名和替换，极大提升了代码重构的效率。
代码搜索	`Grep` 功能基础。	🚀 `Grep` 全面升级，基于 `ripgrep`，支持多行匹配、上下文显示、按文件类型搜索等高级功能，搜索能力呈指数级增长。
任务代理	`Task` 工具是通用的。	🧠 `Task` 引入 `subagent_type`，可以调用不同类型的“专家智能体”，实现了任务的专业化分工。
文件读取	`Read` 支持常见文本和图片。	✅ `Read` 明确支持 PDF 和 Jupyter Notebooks，极大地扩展了其理解项目上下文的能力。
计划执行	无明确流程。	📝 新增 `ExitPlanMode` 工具，正式引入了“计划模式”，在执行复杂任务前先向用户确认方案，增强了透明度和可控性。

其背后的逻辑是：将开发者从繁琐的底层操作中解放出来。无论是强大的 Grep 还是方便的 replace_all，目标都是让开发者能用自然语言完成更复杂、更宏观的任务。而“子智能体”和“计划模式”的出现，则预示着未来的 AI 助手将不再是一个被动的工具执行者，而是一个能主动规划、协同作战的智能伙伴。

3. 交互模型的精炼：追求极致的 CLI 体验

v1.0.72 版本对 Claude 的沟通风格和行为准则提出了更严格的要求，一切为了在命令行（CLI）这个独特的环境中提供最佳体验。

极致简洁： 旧版要求简洁，新版则将其推向极致，甚至给出了范例：“One word answers are best.”，并严格禁止不必要的开场白和总结。在 CLI 中，每一个多余的字符都是噪音。
Emoji 规范： 新版明确规定“Only use emojis if the user explicitly requests it.”这体现了对专业开发环境的尊重。
Git 工作流优化： 在执行 git commit 或 pr 时，新版禁止了 TodoWrite 等工具的介入，让这些核心操作更加纯粹、快速。

其设计哲学在于：深度体察并尊重开发者的工作场景。CLI 环境要求的是高效、精确、无干扰。Anthropic 正努力将 Claude Code 打造成一个“懂规矩”的同事，它言简意 Gai，直奔主题，完美融入你现有的工作节奏。

4. 工作流的智能化：终极武器 Hooks

v1.0.72 带来了两个重量级新概念：“计划模式”和“Hooks”。前者增强了任务的可控性，而后者，则打开了通往无限可能的大门。

Hooks：从助手到平台

Hooks 是新版本中为高级用户和团队打造的终极武器。它允许你在特定事件（如工具调用前后）触发并执行自定义的 shell 命令。这彻底改变了 Claude Code 的定位，使其从一个独立的聊天工具，进化为一个可以被深度集成和编排的自动化平台组件。

想象一下你能用它做什么：

自动化代码质量检查：设置一个 post-edit 钩子，在 Claude 每次修改完代码后，自动运行 Prettier 进行格式化，并用 ESLint 或 Ruff 进行静态检查。
与项目管理工具联动：当一个复杂任务被标记为“完成”时，触发一个钩子，调用 Jira API，自动为相关票据添加一条评论，summarizing the work done。
自定义测试流程：当 Claude 创建了一个新的测试文件 (*_test.py)，一个钩子可以被触发，自动运行 pytest 来验证这个新测试，确保 AI 的工作符合项目标准。
企业级安全扫描：在代码提交到暂存区之前，触发钩子调用内部的安全扫描工具，对 AI 生成的代码进行合规性检查。

其意义在于：Hooks 让开发者可以将 AI 的能力无缝嵌入到任何现有的、复杂的自动化工作流中。这标志着 AI 助手正在从“帮你写代码”向“帮你自动化整个开发流程”的宏大愿景迈进。

进化背后的逻辑与未来趋势

回顾 Claude Code 的这次进化，我们可以清晰地看到几个核心趋势：

专业化 (Specialization): AI 的能力正在从“通用”走向“专用”。无论是“防御性安全”的定位，还是“专家子智能体”的设计，都表明未来的 AI 将在特定领域提供更深入、更专业的支持。
可控性 (Controllability): “计划模式”的引入，是对 AI“黑盒”问题的一次正面回应。开发者需要，也正在获得对 AI 行为更强的控制力、预测力和信任感。
可扩展性 (Extensibility): Hooks 功能的出现，是 AI 工具拥抱开放生态的关键一步。未来的竞争将不仅仅是模型能力的竞争，更是平台生态和集成能力的竞争。

总而言之，Claude Code 的这次迭代，是一次迈向成熟的飞跃。它向我们展示了下一代 AI 编码助手的模样：它不再仅仅是代码的“生成器”，而将是我们项目中真正的、智能的、可信赖的自动化核心。而理解它们的“内心世界”——它们的 System Prompt——将是我们与这些新同事高效协作、共同创造未来的关键。

AI 记忆架构探索（三）：从工程原型到架构蓝图的演进之路

Wed, 06 Aug 2025 22:00:00 +0800

1. 引言：连接理论蓝图与工程原型

在本系列的前两篇文章中，我们分析了一场从“微观架构”到“宏观系统”的思想演进。Memory³ 如同一份精密的芯片设计图，定义了高效的“记忆电路”；而 MemOS 则是一份宏大的城市规划方案，为整个 AI 系统构想了可持续的“记忆治理框架”。它们共同构成了一套前瞻性的架构蓝图。

与此同时，在工程领域，开发者们已经构建出了另一番景象。以 mem0、LangMem 等为代表的开源记忆库，是解决当下问题的工程原型。它们务实、可用，为大量 AI 应用提供了即插即用的记忆能力。本文作为终篇，我们的目标是连接蓝图与原型：

分析当前工程原型的设计与局限。
思考架构蓝图对当前实践的指导意义。
为开发者铺设一条从现有原型通往未来蓝图的、切实可行的演进路径。

2. 当前的工程原型：以 mem0 为例

当前主流的开源记忆库，其核心思想可以概括为基于 RAG 的智能记忆层。它们致力于解决一个核心痛点：如何让无状态的 LLM 拥有跨会话的长期记忆。

其工作模式通常是：

监听与捕获：捕获用户与智能体的对话历史。
筛选与存储：使用一个（通常是 LLM）判断器，决定哪些信息是“重要的”，然后将其转换为向量，存入向量数据库。
检索与注入：当新的交互发生时，从数据库中检索出最相关的历史记忆，并将其作为上下文注入到提示词中。

这种方案直接有效，且易于集成，极大地推动了 AI 智能体的落地。然而，如果我们用 MemOS 的架构蓝图来审视它，就会发现其在设计上的局限性。

3. 用“架构蓝图”审视“工程原型”：两大核心局限

局限一：记忆形态的单一性

MemOS 蓝图将记忆划分为三种核心形态：明文记忆、激活记忆、参数记忆。而当前的工程原型，其核心是对“明文记忆”的向量化管理。所有记忆，无论其性质如何，最终都被处理成文本块的向量表示。

这带来了两个问题：

缺乏“激活记忆”：它们没有采纳 Memory³ 的核心洞见——将高频使用的知识预“编译”成模型可以直接利用的 KV 缓存。这意味着，即使是完全相同的知识被反复检索，模型每次依然需要花费算力去“阅读”和“理解”注入的明文上下文，这在性能和成本上是次优的。
缺乏“参数记忆”：它们无法将某些核心技能或知识“固化”为模型的一部分（如 LoRA 权重）。用户的核心偏好，本应成为智能体“本能”的一部分，但在当前框架下，它仍然只是一条需要被反复检索的“外部记录”。

局限二：记忆治理的初级阶段

MemOS 蓝图的核心是“治理”，它通过标准化的 MemCube 容器和丰富的元数据，实现了对记忆全生命周期的精细化管理。相比之下，当前原型的治理能力尚处于初级阶段。

元数据不完善：虽然可能包含时间戳等基本信息，但普遍缺乏 MemOS 设想的、系统的元数据框架，如 importance_score、access_control_list、version 等。这使得实现更高级的治理策略（如智能遗忘、权限控制、记忆溯源）变得困难。
生命周期管理缺失：记忆在不同形态间的动态流转（缓存、固化、归档）是 MemOS 的精髓。而当前实践中，记忆一旦存入向量数据库，其形态便基本固定，缺乏根据使用情况自动“升降级”的机制。

4. 演进之路：从记忆“数据库”到“运行时”

认识到局限性，我们便可以为开发者勾勒出一条从当前原型出发，逐步吸收架构蓝图思想的演进路线。这条路的核心，是推动 AI 记忆系统从一个外部依赖，演进为一个真正的智能体状态运行时。

第一步：实现你自己的“多级缓存”

这是对 Memory³ 思想最直接的借鉴。在现有的 RAG 流程之上，增加一个内存缓存层 (In-Memory Cache)。

Level 1 (热数据)：在内存中，用一个简单的字典或 LRU 缓存，存储那些被频繁检索的、已经由 LLM“消化”过的结构化知识（例如，将“我的 API 密钥是 xyz”这条信息，缓存为 { "api_key": "xyz" }）。当请求命中 L1 缓存时，直接将结构化结果注入提示，避免了 LLM 重复处理自然语言的开销。
Level 2 (温数据)：对于未命中 L1 的请求，再从向量数据库中检索相关的明文记忆块。这就是当前 mem0 的工作模式。

第二步：构建标准化的“记忆对象”

这是对 MemOS 中 MemCube 思想的借鉴。不要再将记忆视为简单的文本字符串，而是将其封装成一个标准的记忆对象 (Memory Object)。

@dataclasses.dataclass
class MemoryObject:
    content: Any  # 可以是字符串、结构化数据、甚至未来可以是 LoRA 权重路径
    timestamp: float
    source: str
    importance: float
    access_count: int
    # ... 更多元数据

一旦你开始用这种方式来组织记忆，你就为实现更高级的治理能力（如基于重要性和访问频率的遗忘策略）打开了大门。

第三步：迈向“智能体状态运行时”

当你的系统拥有了多级缓存和标准化的记忆对象后，它就不再仅仅是一个记忆库，而开始成为一个真正的运行时 (Runtime)。这个运行时，是智能体的大脑和中枢神经，它负责：

统一管理状态：对话历史、用户偏好、文档知识、工具状态，都作为标准化的记忆对象被运行时统一管理。
调度记忆流转：运行时会成为一个主动的管理者，根据元数据，自动在不同缓存层和持久化存储之间移动记忆。
对接多种“记忆后端”：未来，这个运行时可以对接更多样的后端，比如 Memory³ 架构的模型（实现原生 KV 注入）、微调服务（实现参数记忆固化）等，从而拥有一个可插拔、可扩展的记忆架构。

5. 总结：记忆，终将成为 AI 的一等公民

从 Memory³ 的架构巧思，到 MemOS 的系统宏图，再到 mem0 的工程实践，我们看到了一条清晰的脉络：AI 记忆，正在从一个临时的、外部的“上下文信息”，逐渐演变为一个系统的、内在的、需要被主动管理的“一等公民”。

对于今天的开发者而言，最重要的不是去争论哪条路是唯一的真理，而是要认识到这场演进的必然性。从改进你的 RAG 流程开始，引入多级缓存，封装你的记忆对象。每一步看似微小的工程优化，都是在为构建那个更强大、更鲁棒、更智能的未来 AI 系统添砖加瓦。这条路，道阻且长，但行则将至。

AI 记忆架构探索（二）：MemOS 的系统化设想与治理框架

Wed, 06 Aug 2025 21:00:00 +0800

论文：MemOS: A Memory OS for AI System
链接：https://arxiv.org/abs/2507.03724v2
GitHub: https://github.com/MemTensor/MemOS

1. 引言：从“数据结构”到“管理系统”

上一篇文章中，我们解析了 Memory³ 如何设计出一种高效的“记忆数据结构”。然而，一个孤立的数据结构，无论多么精巧，都无法解决系统层面的复杂性问题。当大量的记忆需要被不同的智能体并发使用、长期持有、更新和授权时，我们就需要一个管理系统。

MemOS 论文正是在这一背景下，提出了一个宏大的系统性设想：我们是否需要一个类似操作系统的框架，来统一管理 AI 的记忆和行为？它试图回答的，不是如何让单次记忆的利用更高效，而是如何构建一个能够支撑复杂、多智能体长期演进的治理框架。

2. 核心思想：三种记忆形态的统一管理

MemOS 并非凭空出现，它明确地继承并极大地扩展了 Memory³ 的核心思想。它的核心是将所有 AI 相关的知识和状态，归纳为三种可以相互转化的记忆形态：

明文记忆 (Plaintext Memory)：最基础、最稳定、人类可读的记忆。它对应于计算机中的硬盘存储。MemOS 进一步将其细化，支持多种后端存储，例如：
- 通用文本记忆：存储非结构化的文本块，如对话历史、文档段落。
- 树状文本记忆：用于存储具有层级关系的数据，如文件系统结构或思维导图。
- 图数据库记忆：利用 Neo4j 等图数据库，将知识以实体和关系的形式进行结构化存储，便于进行复杂的关联查询和推理。
激活记忆 (Activation Memory)：为了加速访问而存在的“热”记忆，其标准实现即 KV 缓存。这完全采纳了 Memory³ 的“显性记忆”概念，即预先计算好的、稀疏的键值对缓存。它对应于计算机中的内存。
参数记忆 (Parametric Memory)：被深度内化到模型权重中的知识。例如，通过 LoRA (Low-Rank Adaptation) 微调生成的适配器权重。它对应于 CPU 缓存，与计算单元结合最紧密。

MemOS 的目标，就是设计一套机制，对这三种形态的记忆进行统一的、全生命周期的管理。

3. 核心抽象：记忆的“集装箱”—— MemCube

为了实现对不同形态记忆的统一管理，MemOS 提出了其最重要的核心抽象：MemCube (记忆立方)。这是一个标准化的“记忆容器”，其设计思想对理解整个系统至关重要。

每个 MemCube 由两部分构成：

载荷 (Payload)：存储记忆的实际内容。它的形态是多样的，可以是一段明文，一组激活记忆的键值对，或是一个 LoRA 模型的权重文件。
元数据 (Metadata)：这是实现治理的基石。它是一组描述载荷的标签，定义了诸如记忆的 user_id、source、timestamp、importance_score、access_control_list 和 version 等系统级信息。

通过将所有记忆都封装进这种标准化的、带元数据的容器中，MemOS 才有可能在系统层面实现对它们的追踪、调度、授权和演进管理。MemCube 让记忆从单纯的数据变成了可被管理的系统资产。

4. MemOS 系统架构

根据官方文档，MemOS 采用分层架构，主要包括存储层、服务层和应用层。

存储层 (Storage Layer)：负责记忆的持久化，对接各种后端，如本地文件系统、对象存储 (S3) 或图数据库 (Neo4j)。
服务层 (Service Layer)：系统的核心，提供了记忆管理、用户管理、API 接口等核心服务。服务层包含两种部署模式：
- MemOS NEO：一个功能完备的、可独立部署的记忆操作系统服务，提供完整的记忆管理能力。
- MemOS MCP (MemOS Coze Plugin)：一个轻量级的、可嵌入的记忆插件，设计用于在 Coze 等第三方平台中作为工具，提供记忆能力。
应用层 (Application Layer)：开发者基于 MemOS 的服务和 API，构建自己的 AI 应用。

这种分层架构和灵活的部署模式，使得 MemOS 既能作为强大的中央记忆枢纽，也能作为便捷的嵌入式记忆组件，适应不同的应用场景。

5. 记忆的动态转化：智能的“缓存”与“固化”

MemOS 理论框架的亮点，在于它描绘了一幅记忆在三种形态间动态流转、自我优化的蓝图：

“缓存”：当系统发现某个“硬盘”中的明文记忆被频繁访问时，可以自动将其“编译”成“内存”中的激活记忆（KV 缓存），以加速未来的调用。这类似于数据库的查询缓存或物化视图。
“固化”：当某些知识或技能需要被更深度地内化时，系统可以将相关的明文或激活记忆，通过训练（如 LoRA 微调）“固化”成“CPU 缓存”里的参数记忆。这好比将反复练习的技能，变成了“肌肉记忆”。
“归档”：反之，长期不被使用的激活记忆或参数记忆，也可以被“降级”为明文记忆，以释放宝贵的计算资源。

这种动态转化的能力，使得系统在理论上可以根据实际使用情况，智能地调整不同记忆的存储形态，在成本、速度和效果之间取得动态平衡。

6. 详解：利用“前缀缓存”兼容闭源模型

这是一个现实且关键的问题。对于像 GPT-4o 这样的闭源模型，我们无法访问其内部，自然也无法直接向其注意力层注入键值对缓存。MemOS 对此的应对策略是一种功能上的模拟，它巧妙地利用了现代 LLM 推理服务普遍具备的一项优化技术：前缀缓存 (Prefix Caching)。

前缀缓存的工作原理

在 LLM 推理时，首先需要对用户输入的提示（Prompt）进行一次完整的计算，这个过程称为预填充 (Prefill)。在预填充阶段，模型会为输入的每一个 token 计算出其对应的“键”和“值”向量，并将它们存储在 GPU 显存中，这就是 KV 缓存。在后续生成每一个新词时，模型都可以直接利用这个缓存，而无需重新计算整个提示，从而大大加快生成速度。

前缀缓存技术，就是将这个 KV 缓存在不同的推理请求之间共享。如果系统检测到多个请求的开头部分（前缀）是完全相同的（例如，多轮对话中的历史记录，或者 RAG 应用中被反复查询的同一篇文档），它就可以直接重用已经计算好的前缀 KV 缓存，只计算新增加的那部分内容。这极大地降低了处理重复信息时的延迟和计算成本。

MemOS 的模拟策略

理解了前缀缓存后，MemOS 的策略就一目了然了：

检索明文：首先，系统找到“激活记忆”所对应的原始明文记忆。
前置拼接：然后，系统将这段明文内容前置拼接到当前用户的提问之前，形成一个组合式的提示。

当这个组合式的提示被发送给闭源模型时，推理引擎的前缀缓存机制就会自动生效。如果这段明文内容（作为前缀）在近期被频繁使用，它的 KV 缓存很可能已经被保留了下来。因此，模型无需重新计算这个前缀，可以直接利用缓存，从而在功能上达到了“模拟”注入激活记忆的效果，同时享受了性能优化的红利。

7. 优势与代价：兼容性与性能的权衡

现在，我们可以更清晰地对比 MemOS 的兼容策略与 Memory³ 的原生架构在处理记忆时的优劣势：

Memory³ (原生注入)：
- 优势：极致的性能和效率。它跳过了模型对明文的阅读、理解和编码过程，直接将预计算好的、最关键的稀疏键值对注入计算中枢。这是理论上最高效的方式。
- 劣势：缺乏灵活性和兼容性。这种方法要求对模型进行底层架构的修改，因此它无法适用于任何闭源模型，也无法与非 Memory³ 架构的开源模型兼容。
MemOS (利用前缀缓存模拟)：
- 优势：极高的灵活性和兼容性。该策略适用于任何支持前缀缓存的黑盒模型。这使得 MemOS 的系统治理能力有更广泛的应用前景。
- 劣势：性能妥协。虽然利用了前缀缓存，但其效果依然弱于原生的稀疏键值对注入。它依赖于推理引擎的缓存策略，并且缓存的粒度是完整的稠密 KV，而非 Memory³ 中经过优化的稀疏 KV，在存储和利用效率上都打了折扣。

总而言之，MemOS 用一种聪明的“降级兼容”策略，换取了在异构模型环境下的生存能力，而 Memory³ 则专注于在理想环境下，将单一架构的性能推向极致。

8. 宏大愿景：“LLM 即内核”

MemOS 最具雄心的设想，是提出 “LLM 即内核” 的概念。它认为，未来的操作系统内核，其核心调度器可能就是一个 LLM。这个 LLM 不再仅仅是一个被调用的“程序”，而是成为整个系统的“大脑”，负责：

意图理解：解析用户的自然语言指令。
记忆调度：根据意图，决定从存储层加载哪些 MemCube 到工作记忆中。
工具选择：选择合适的模型或外部工具来执行任务。
响应生成：整合所有信息，生成最终的、上下文感知的响应。

这是一个极具颠覆性的想法，但也面临着巨大的挑战：

性能与成本：用 LLM 作为内核进行每一次调度，其延迟和成本在现阶段是难以想象的。
可靠性与确定性：操作系统的内核必须是高度可靠和确定性的，而 LLM 的随机性在目前来看是一个难以逾越的障碍。

尽管如此，这个设想为我们描绘了一幅足够激动人心的未来图景。

9. 审视与展望

MemOS 提供了一个极其全面和深刻的理论框架，它指出了当前智能体架构在系统性上的普遍缺失。将操作系统和数据库系统的思想引入 AI 领域，无疑是极具启发性的。

然而，我们必须清醒地认识到，这是一个具有挑战性的系统性设想。其复杂的抽象和管理机制，对于大多数应用场景而言，也可能是“过度设计”。

MemOS 最大的价值，或许不在于它给出的答案，而在于它定义了问题。它为我们思考如何构建更健壮、更可演进的 AI 系统，提供了一套宝贵的、尽管存在争议的词汇和蓝图。

AI 记忆架构探索（一）：Memory³ 架构深度解析

Sun, 03 Aug 2025 10:00:00 +0800

论文：Memory³: Language Modeling with Explicit Memory
链接：https://arxiv.org/abs/2407.01178v1

1. 引言：在参数和上下文之间，寻找第三条路

当前的大语言模型主要通过两种方式利用知识。第一种是参数化记忆，即将知识在预训练阶段编码进模型数以亿计的权重中。这种记忆响应快，但更新成本极高。第二种是工作记忆，即我们熟知的上下文窗口，通过检索增强生成等方式在推理时将外部文档放入其中。这种方式灵活，但受限于上下文长度和检索带来的延迟，是一种相对浅层的结合。

这两种方式都非完美。一个核心问题始终存在：我们能否设计一种新的知识表示形式，它既能像参数化记忆一样与模型深度融合，又能像工作记忆一样灵活更新？Memory³ 论文正是对这一问题的严肃探索，它引入了第三种记忆形式：显性记忆。

2. 理论基石：记忆电路理论

要理解 Memory³ 的设计，首先要理解其理论基础——记忆电路理论。该理论尝试从模型内部的计算过程来定义“知识”。它认为，一项具体知识（例如“中国的首都是北京”）可以被看作一个电路，这个电路由模型中特定的注意力头和 MLP 神经元构成。

这个理论将知识分为两类：

抽象知识：指那些通用的、难以被具体实例化的能力，例如语言的语法规则、逻辑推理能力等。这些知识的电路非常复杂且泛化，难以从模型中剥离。
具体知识：指那些与特定事实或实体相关的知识，例如“埃菲尔铁塔在巴黎”。这些知识的电路相对简单和固定。

Memory³ 的核心思想是：将“具体知识”的电路从模型参数中“外化”出来，存储为显性记忆，而让模型参数专注于更核心的“抽象知识”。 这样，模型可以变得更小、更高效。

3. 什么是“显性记忆”？

Memory³ 提出的核心概念是显性记忆。它并非一个外部数据库，而是一种深入模型内部的架构层优化。我们可以从以下几点来理解它与传统方式的区别：

与模型参数的区别：模型参数是隐性的、高度压缩的，且更新成本极高。显性记忆是外置的、结构化的，并且可以被随时添加、删除或修改，无需重新训练整个模型。
与检索增强生成的区别：传统的检索增强会将检索到的原始文本作为输入，模型需要花费计算资源去阅读和理解。显性记忆存储的则是模型可以直接利用的预计算状态，即稀疏的注意力键值对，从而跳过了阅读理解的步骤，大幅提升了效率。

本质上，显性记忆是一种为模型注意力机制量身打造的高效数据结构。

4. 技术实现：从生成、存储到检索

记忆的生成与存储：稀疏化是关键

显性记忆的本质，是一组稀疏的注意力键值对。其写入过程如下：

编码：使用一个“记忆生成器”（在论文中，这是一个经过训练的 Transformer 模型）读取一篇参考文献。
筛选与稀疏化：这是关键一步。在编码过程中，通过计算注意力分数等方式，识别出文档中信息量最大的少数关键 token。只有这些最关键的 token 会被保留。
存储：系统只保存这些关键 token 的键和值向量。这组稀疏的键值对，就是这篇文档被“编译”后的精华。这种稀疏化处理，极大地降低了存储需求，使得构建大规模记忆库成为可能。

记忆的检索与使用

当用户提出问题时，系统利用向量检索技术从记忆库中召回相关的记忆单元：

向量库：论文明确指出，他们使用了基于 Faiss 的向量索引。
存储内容：索引中存储的，是所有已生成记忆单元的键向量。
查询内容：用于查询的，是用户问题经过编码后生成的查询向量。
使用流程：检索到的键值对会被直接拼接到模型当前注意力层正在计算的键和值矩阵中。这意味着，外部知识没有经过繁琐的阅读理解，而是直接成为了模型计算过程的一部分，实现了最高效的融合。

5. 成本收益的量化分析

Memory³ 的价值不仅在于理论创新，更在于其经济性。论文提供了一个清晰的成本分析，比较了三种记忆形式在不同使用频率下的总成本（写入成本 + 读取成本）。

模型参数：写入成本极高（需要昂贵的训练），但读取成本很低。适合存储使用频率极高的“抽象知识”。
检索增强生成：写入成本几乎为零（存储纯文本），但每次读取成本都很高（需要模型实时编码和理解）。适合存储使用频率极低的知识。
显性记忆：写入和读取成本都处于中等水平。

结论是显而易见的：显性记忆在“中等使用频率”的知识存储上，具有无与伦比的成本优势。 这正是其“用武之地”。

6. 关键问题解答

模型是如何训练的？

这是一个关键事实。根据论文，Memory³ 模型并非基于任何开源模型进行微调。研究团队从头开始预训练了一个 2.4B 参数的模型，该模型在架构上原生集成了对显性记忆的支持。训练过程分为两个阶段：

热身阶段：在此阶段，模型学习将知识编码到其参数中，就像传统的预训练一样。
持续训练阶段：在此阶段，模型学习如何从显性记忆中读取和利用知识。它会接触到一个不断增长的、由第一阶段处理过的文档编译而成的记忆库。

如何处理长文本以支持“无限上下文”？

为避免上下文割裂，Memory³ 采用了一种“先编码，后切分”的策略。它首先对整篇长文档进行一次完整的编码，以捕获全局信息。然后，在保留这些全局信息的前提下，再将长序列的键值对切分成多个可管理的记忆片段。这样，每个片段的向量中都蕴含了来自整篇文档的上下文信息。由于记忆被存储在外部，并在需要时才被检索，这在理论上打破了传统上下文窗口的长度限制。

显性记忆带来了哪些额外的好处？

除了效率和成本，显性记忆还带来了两大优势：

提升事实性：由于知识以更接近原始形式的方式被存储和检索，减少了模型在参数化过程中可能出现的信息损失和“幻觉”。
增强可解释性：当模型做出回答时，我们可以追溯到它具体依赖了哪些记忆单元，而这些记忆单元又对应着哪些原始文本。这为理解和调试模型的决策过程提供了重要线索。

7. 潜力与局限

Memory³ 的实验结果展示了巨大的潜力：其 2.4B 模型在多个知识密集型任务上超越了 Llama2-7B，且速度更快。这证明了其架构的有效性。

然而，作为一个前沿探索，它依然面临着严肃的开放性问题：

可扩展性：当记忆库的规模达到万亿级别时，存储成本和检索效率是否还能保持在可接受的范围内？
知识更新：对于需要实时更新的知识，重新编译记忆的延迟和成本有多大？
通用性：在问答任务上的成功，能否迁移到需要更复杂推理和创造性的任务中？

总而言之，Memory³ 提出了一种极具启发性的、在模型架构层面的优化方案。它用一个精巧的数据结构设计，为我们揭示了在检索增强和微调之外的第三条道路。但同时，它也让我们不得不思考一个更深层次的问题：当记忆的数量和复杂度超越了优化的范畴，我们是否需要一个全新的系统来对其进行管理？这正是我们下一篇文章将要探讨的 MemOS。

AI 记忆的两种架构：Mem0 的记忆库与 MemOS 的操作系统假说

Sun, 03 Aug 2025 00:20:00 +0800

引言：从“金鱼记忆”到架构之争

大语言模型（LLM）的“金鱼记忆”已是老生常谈。然而，当我们超越简单的上下文窗口扩展，试图构建真正有状态、能处理复杂任务的 AI Agent 时，一个更深层次的问题浮出水面：我们应如何设计 Agent 的核心架构？

现有的主流 Agent 框架（如 LangChain）提供了一套便捷的工具库，但其“无状态、顺序执行”的本质，在面对并发、多任务和长期运行的需求时，显得力不从心。这引发了一场深刻的架构路线之争：我们是应该在现有框架上外挂一个强大的“记忆模块”，还是应该彻底抛弃“库调用”的范式，为 Agent 打造一个全新的“操作系统”？

这场争论的双方，正是两个极具代表性的开源项目：Mem0，一个专注的模块化记忆库；以及 MemOS，一个雄心勃勃的代理原生操作系统。它们的对比，揭示了 AI Agent 架构正在发生的深刻变革。

路线一：Mem0 - 精致的“用户态”记忆库

Mem0 的定位清晰而务实：它是一个高性能、可插拔的记忆库。它旨在解决“记忆”这一垂直问题，并将其封装为任何应用都可以轻松调用的模块。

核心思想： Mem0 奉行“高内聚、低耦合”的软件工程原则。它不关心 Agent 的整体架构，只专注于提供一流的语义记忆服务。你可以将它视为一个运行在“用户态”（User-Space）的专业程序库。

架构特点：

功能专注： 核心任务是信息的存储与检索，通过混合数据存储（向量、图、键值）实现丰富的查询能力。
易于集成： 提供简单的 API (add, search)，可以被无缝集成到任何现有的 Agent 框架中，作为其记忆能力的“增强包”。
非侵入性： 它是一个“库”，而不是一个“框架”。开发者保留了对 Agent 核心逻辑和执行流程的完全控制权。

总而言之，Mem0 提供了一个优雅的解决方案，用于回答“如何让我的 Agent 记住事情？”。它是一个精致的工具，而非一个宏大的系统。

路线二：MemOS - 一个“代理操作系统”的宏大假说

与 Mem0 的务实不同，MemOS 提出了一套极具野心的操作系统假说。其核心论文开宗明义地指出，现有框架的根本缺陷在于它们是“库”而非“系统”。因此，MemOS 的目标是探索构建一个真正的代理原生操作系统 (Agent-Native Operating System) 的可能性。

核心思想：“LLM 即内核” (LLM-as-Kernel)

这是 MemOS 理论中最引人注目的部分。它设想将 LLM 的角色从被动调用的工具，提升为操作系统的内核，负责理解意图并发出系统调用 (System Calls) 来调度系统资源。

理论上的架构设计：

MemOS 的论文描绘了一套完整的操作系统抽象，试图解决现有框架的诸多弊病：

“代理进程” (Agentic Process): 理论上，Agent 将被视为系统中的一等公民“进程”，拥有独立的资源（APID、内存空间）和生命周期，从而实现并发与隔离。
“统一内存空间” (Unified Memory Space - UMS): 为每个代理进程分配一个受保护的、结构化的内存空间，分为工作内存、情景记忆和语义记忆三个区域。
“系统调用”接口 (System Call Interface): 论文定义了一套系统调用接口，作为上层应用与“LLM 内核”交互的桥梁。

总而言之，MemOS 并非一个成熟的系统，而是一个严肃的学术探索，它试图回答一个超前的问题：“如果我们把现代操作系统的设计原则应用到 AI Agent 架构上，会是什么样子？”

批判性思考：两种路线的内在局限

无论是务实的库，还是宏大的假说，在当前阶段都面临着各自的巨大挑战。吹捧任何一方都为时过早，审视其局限性更为重要。

Mem0：“记忆库”的隐藏复杂性

责任推诿： Mem0 只负责存取，但“存什么、何时存、如何利用检索结果”这些最关键的决策，完全留给了上层应用。这导致开发者虽然集成简单，但应用层的逻辑会随着 Agent 的复杂化而变得极其混乱。
缺乏全局优化： 作为“库”，它无法进行系统级的资源调度。当多个 Agent 同时调用它时，它就像一个普通的数据库，无法解决 Agent 之间的资源竞争或实现智能的优先级调度。
语义鸿沟： 记忆的质量完全依赖于外部 LLM 对信息的提取能力。如果提取出错或有偏差，存入的记忆就会变成“垃圾”，而 Mem0 自身无法校验这些信息的真伪。

MemOS：“操作系统假说”的沉重负担

“LLM 内核”的性能悖论： 这是其最吸引人也最致命的弱点。传统内核追求的是极致的速度、稳定性和确定性。而 LLM 天生就是缓慢、昂贵且非确定性的。让一个“慢速的、概率性的”大脑去扮演“高速的、确定性的”调度核心，其性能和可靠性在现实世界中面临巨大问号。
压倒性的复杂性： 构建一个真正的操作系统是软件工程中最艰巨的任务之一。MemOS 的宏大设计，意味着极高的实现难度和维护成本。对于绝大多数应用场景来说，这无异于“杀鸡用牛刀”，其带来的管理开销可能远超收益。
生态位与可行性： 它要求开发者完全接受其生态和范式，学习成本极高。在一个尚不确定是否需要“操作系统”的阶段，这种“一体化”的重型方案，其商业和社区上的可行性仍有待观察。

结论：超越“库”与“系统”的思考

Mem0 和 MemOS 的对比，与其说是两条路线的竞争，不如说是揭示了 AI 记忆乃至 Agent 架构仍处于非常初级的探索阶段。它们各自的局限性表明，最终的答案可能并非二选一，而是走向更深层次的融合与进化。

未来可能的发展方向包括：

混合型系统（Hybrid Systems）： 出现类似操作系统的轻量级运行时（Runtime），它负责进程管理和资源隔离，但允许开发者插入不同类型的、像 Mem0 这样的专业“记忆模块”。实现系统优势与模块灵活性的结合。
软硬件协同设计（Hardware-Software Co-design）： 真正的记忆瓶颈最终需要硬件来解决。未来的记忆架构，很可能是软件（如内存管理策略）与新型硬件（如 CXL、存内计算）深度协同设计的产物。
动态与隐式记忆（Dynamic & Implicit Memory）： 当前的方案都将记忆视为一个外部“数据库”。但更高级的记忆，可能是模型通过持续学习（Continual Learning）和模型编辑（Model Editing）内化的一种隐式能力，而非需要显式调用的数据。
“遗忘”机制的设计（The Art of Forgetting）： 一个只记不忘的系统是无用的。如何设计高效、智能的“遗忘”机制，决定了记忆系统能否长期保持有效和健康，这至今仍是一个开放的、甚至带有哲学意味的难题。

最终，构建 AI 记忆的道路依然漫长。Mem0 的实践和 MemOS 的假说，都是这条探索之路上宝贵的足迹。它们最重要的贡献，是激发了我们对于未来架构更深、更具批判性的思考。

不止于相似度：混合搜索如何重塑 RAG 的未来

Wed, 16 Jul 2025 23:50:00 +0800

1. 引言：当“最相似”不再是“最相关”

在构建检索增强生成（RAG）系统时，我们常常陷入一个困境：如何确保检索到的上下文既“语义相关”又“关键词精确”？

想象一下这个场景：

当用户搜索“苹果公司发布的 M3 芯片评测”时，一个纯粹依赖向量搜索的 RAG 系统可能会返回一篇关于“苹果公司最新财报”的文章。从语义上看，这没错，两者都与“苹果公司”高度相关。但用户最关心的核心关键词——“M3 芯片”——却被忽略了。
反过来，当用户搜索“好用的笔记本电脑”时，一个传统的关键词搜索引擎（如 BM25）可能会因为无法理解“好用”这个主观词汇，或者因为“笔记本电脑”这个词在太多文档中出现，而返回一大堆不相关的结果。它无法领会用户寻找“高性能”、“轻薄”或“长续航”的真实意图。

这两种情况都指向了一个核心问题：单纯依赖一种搜索范式，无论是基于稠密向量的语义搜索，还是基于稀疏向量的关键词搜索，都有其局限性。

为了解决这个问题，**混合搜索（Hybrid Search）**应运而生。它并非简单的两者叠加，而是通过智能地融合两种搜索范式的结果，实现 1 + 1 > 2 的效果，正在成为构建下一代高质量 RAG 应用的关键。

2. 搜索的双引擎：从传统关键词到智能稀疏向量

要理解混合搜索，我们首先要了解它的两个核心引擎。

第一类引擎：关键词匹配 (Keyword Matching)

这类引擎的核心是找到与查询词完全匹配或高度相关的文档。

传统方法：BM25 / TF-IDF

这是经典的、基于统计的关键词搜索算法。它们通过计算词频（Term Frequency）和逆文档频率（Inverse Document Frequency）来评估一个词在一个文档中的重要性。简单来说，一个词在一个文档中出现次数越多，但在所有文档中越稀有，它的权重就越高。

优点: 技术成熟，计算速度快，对于包含专业术语、产品型号、人名等精确查询非常有效。
缺点: 无法理解同义词或上下文，存在“词汇鸿沟”问题。

现代方法：模型生成的稀疏向量 (Learned Sparse Vectors)

这是对传统关键词搜索的一次“智能升级”。像 SPLADE、BGE-M3-Sparse 这样的模型，通过深度学习来生成一个高维但大部分值为零的“稀疏向量”。

是什么: 这个稀疏向量的非零值代表了文档中最重要的词汇及其“概念权重”。与 BM25 纯粹基于词频不同，模型能够理解词汇在特定上下文中的重要性。
为什么更好: 它不仅能匹配关键词，还能进行一定程度的语义扩展。例如，模型可能知道 “cpu” 和 “processor” 是高度相关的，并会给它们赋予相似的权重。这在一定程度上弥合了“词汇鸿沟”。

第二类引擎：语义理解 (Semantic Understanding)

这类引擎的目标是理解查询背后的深层意图。

稠密向量 (Dense Vectors)

通过 Sentence Transformers 这类模型，我们可以将文本转换成一个几百维的“稠密向量”（Dense Vector）。这个向量可以被看作是文本在语义空间中的一个坐标。

工作原理: RAG 系统将用户的查询也转换成一个向量，然后在向量数据库中通过近似最近邻（ANN）搜索，找到与之“距离”最近的文档向量。
优点: 能够轻松跨越“词汇鸿沟”，理解同义词、近义词和上下文。对于模糊、口语化的查询非常有效。
缺点: 正如引言中的例子，它有时会因为过于关注整体语义而忽略掉关键的、决定性的词汇。

总结对比

特性	BM25 / TF-IDF	模型稀疏向量 (SPLADE)	稠密向量 (Embeddings)
核心原理	词频统计	语言模型生成权重	语义空间映射
向量类型	稀疏	稀疏	稠密
优点	速度快，精确匹配	精确且有语义扩展	理解意图，处理模糊查询
缺点	词汇鸿沟，不理解语义	计算开销较大	可能忽略关键词
最适用场景	专业术语、代码搜索	需要精确匹配但又希望有一定语义灵活性的场景	问答、对话、概念搜索

3. 混合搜索的核心：结果融合 (Result Fusion)

当我们从稀疏和稠密两种搜索中各得到一个按相关性排序的文档列表后，如何将它们合并成一个更优的列表？这就是结果融合的艺术。

最简单的方法是加权平均，但它依赖于两种搜索返回的、不可直接比较的分数，效果往往不佳。

目前，业界最推崇的方法之一是 倒数排名融合 (Reciprocal Rank Fusion, RRF)。

核心思想: RRF 不关心原始的相关性分数，只关心文档在每个列表中的排名。一个文档在任何一个列表里排名越高，它的最终得分就越高。
计算公式: Score(doc) = Σ (1 / (k + rank_i)) 其中，rank_i 是文档在第 i 个搜索结果列表中的排名，k 是一个小的平滑常数（通常设为 60），用于降低排名靠后结果的权重。
为什么有效: RRF 非常鲁棒且简单。它优雅地绕开了归一化不同搜索引擎得分的难题，让排名决定一切，使得两种完全不同的搜索范式可以公平地“投票”。

4. 动手实践：用 Python 实现一个简单的混合搜索

下面，我们用 rank-bm25 和 sentence-transformers 库来模拟一个混合搜索过程。

# 安装必要的库
# pip install rank-bm25 sentence-transformers scikit-learn

import numpy as np
from rank_bm25 import BM25Okapi
from sentence_transformers import SentenceTransformer
from sklearn.metrics.pairwise import cosine_similarity

# 1. 准备数据
documents = [
    "Apple Inc. announced the new M3 chip, focusing on performance and efficiency.",
    "The latest financial report from Apple Inc. shows strong growth in the services sector.",
    "A detailed review of the MacBook Pro with M3 chip highlights its impressive speed.",
    "Google's new Pixel phone features an advanced AI-powered camera.",
    "How to bake the perfect apple pie from scratch.",
    "Microsoft's Surface Laptop competes directly with Apple's MacBook Air."
]

# 2. 创建双索引
# 稀疏索引 (BM25)
tokenized_docs = [doc.lower().split() for doc in documents]
bm25 = BM25Okapi(tokenized_docs)

# 稠密索引 (Sentence Transformer)
model = SentenceTransformer('all-MiniLM-L6-v2')
doc_embeddings = model.encode(documents)

# 3. 执行搜索
query = "latest review of Apple's M3 chip"
tokenized_query = query.lower().split()

# BM25 搜索
bm25_scores = bm25.get_scores(tokenized_query)

# 向量搜索
query_embedding = model.encode(query)
cosine_scores = cosine_similarity([query_embedding], doc_embeddings)[0]

# 4. 实现 RRF 融合
def reciprocal_rank_fusion(search_results_list, k=60):
    fused_scores = {}
    for doc_scores in search_results_list:
        # 对每个搜索结果列表按分数降序排序，获取排名
        sorted_docs = sorted(doc_scores.items(), key=lambda item: item[1], reverse=True)
        for rank, (doc_index, score) in enumerate(sorted_docs):
            if doc_index not in fused_scores:
                fused_scores[doc_index] = 0
            fused_scores[doc_index] += 1 / (k + rank + 1) # rank 从 0 开始，所以 +1
    
    # 按 RRF 分数重新排序
    reranked_results = sorted(fused_scores.items(), key=lambda item: item[1], reverse=True)
    return reranked_results

# 准备 RRF 输入
bm25_results = {i: score for i, score in enumerate(bm25_scores)}
vector_results = {i: score for i, score in enumerate(cosine_scores)}

fused_results = reciprocal_rank_fusion([bm25_results, vector_results])

# 5. 展示结果
print("--- Query ---")
print(query)
print("
--- BM25 (Keyword) Search Results ---")
for i, score in sorted(bm25_results.items(), key=lambda item: item[1], reverse=True):
    print(f"Score: {score:.4f} Doc: {documents[i]}")

print("
--- Vector (Semantic) Search Results ---")
for i, score in sorted(vector_results.items(), key=lambda item: item[1], reverse=True):
    print(f"Score: {score:.4f} Doc: {documents[i]}")

print("
--- Hybrid Search (RRF Fused) Results ---")
for doc_index, score in fused_results:
    print(f"Score: {score:.4f} Doc: {documents[doc_index]}")

运行结果分析:

BM25 会把包含 “M3” 和 “chip” 的文档排在最前面。
向量搜索 会把与 “Apple” 和 “review” 语义相关的文档排在前面，可能会包含那篇财报。
混合搜索 的结果则会是最好的：包含 “M3 chip” 的评测文章会因为在两个列表中都排名靠前（或至少在 BM25 中排名极高）而获得最高的 RRF 分数，从而脱颖而出。

5. RAG 的进化：为什么混合搜索是关键？

将混合搜索集成到 RAG 系统中，带来的不仅仅是检索精度的提升：

更高质量的上下文: LLM 获取的上下文将同时包含关键词精确和语义相关的信息，使其能够生成更全面、更准确的答案。
显著减少“幻觉”: 高质量、高相关的上下文是减少 LLM“凭空捏造”的根本。当模型有了坚实的信息基础，它就不需要去猜测和编造。
提升用户体验: 无论用户输入的是精确的技术术语还是模糊的日常问题，RAG 系统都能给出更可靠、更令人满意的回答，系统的鲁棒性和适用性大大增强。

6. 结论与展望

混合搜索并非一个复杂的概念，但它通过智能地融合稀疏和稠密两种搜索范式，精准地解决了各自的短板，让搜索结果的质量产生了质的飞跃。它不再是锦上添花，而是正在成为构建下一代强大、可靠 RAG 应用的核心组件。

展望未来，我们可能会看到更智能的、能够根据查询意图自适应调整融合权重的策略出现。但就目前而言，掌握并应用混合搜索，无疑是每一位 AI 应用开发者都应该具备的关键能力。

读后感｜刘慈欣短篇小说：在宇宙的宏大叙事下，人的存在为何

Tue, 15 Jul 2025 22:00:00 +0800

最近重读了刘慈欣的一些短篇小说，并翻看了之前的书摘，再次被他那宏大的想象力和深刻的思考所震撼。大刘的作品，总是能将人的存在置于一个极其广阔甚至残酷的宇宙背景之下，探讨关于生死、希望、梦想与文明的终极问题。

“山”的隐喻

在《山》这篇小说中，主人公冯帆一生都在登山，从地球的珠穆朗玛峰，到由海水构成的宇宙奇观。他为了“还有别的山呢”，甚至不惜在生死关头割断连接恋人的登山索。这看似冷酷自私的选择，却揭示了一种超越个人情感的、对未知世界最纯粹的向往和探索精神。

“山”是什么？是物理上的高峰，更是文明和个体不断超越自我的象征。当冯帆意识到还有更多、更奇特的“山”要去攀登时，他获得了活下去的最强动力。这或许是大刘想表达的一种观点：对于一个文明或者个体而言，探索和好奇心，是比安逸和情感更核心的驱动力。

死亡之墙

“你在平原上走着走着，突然迎面遇到一堵墙，这墙向上无限高，向下无限深，向左无限远，向右无限远，这墙是什么？”

是死亡

这个比喻精准而又残酷。死亡是每个生命最终都无法逾越的障碍。但在大刘的笔下，即使面对这堵终极之墙，人类依然展现出不同的姿态。《流浪地球》中，人类选择带着地球去流浪，这是一个延续百代人的疯狂计划。支撑他们走下去的，并非是虚无缥缈的乐观，而是一种清醒的、甚至有些悲壮的抉择。

希望的重量

“我们必须抱有希望，这并不是因为希望真的存在，而是因为我们要做高贵的人。”

在末日面前，人类的情感和道德被重新定义。曾经被珍视的爱情，在生存的重压下变得微不足道。然而，即使在这样极端的环境中，大刘依然通过角色之口，强调了“希望”的重要性。这种希望，不是廉价的口号，而是一种关乎“高贵”的选择。它如黄金和宝石般珍贵，是人类在黑暗中仅存的、用以自我标榜为“人”的东西。

光荣与梦想

从《和平视窗》的“竞赛代替不了战争”，到《朝闻道》中“当生命意识到宇宙奥秘的存在时，距它最终解开这个奥秘只有一步之遥了”，大刘不断地拷问着人类文明的价值和意义。

我们是谁？我们从哪里来？要到哪里去？这些古老的哲学问题，在宇宙级的尺度下，显得更加迫切和沉重。那个原始人对星空的凝视，开启了人类文明的漫长征程。而这整个文明，或许“不过是弯腰去拾起那颗宝石的过程”。

刘慈欣的短篇小说，就像一扇扇窗，让我们得以窥见宇宙的壮丽与残酷，也让我们得以审视自身。在浩瀚的星辰大海面前，人类的渺小与伟大，被展现得淋漓尽致。而支撑我们走向未来的，或许正是那份永不磨灭的“光荣与梦想”。

论文分享｜iRangeGraph - 为范围过滤 (range-filtering) 的近似向量搜索 (ANN) 实时构建图索

Sun, 29 Jun 2025 22:50:00 +0800

论文标题：iRangeGraph: Improvising Range-dedicated Graphs for Range-filtering Nearest Neighbor Search
作者：Yuexuan Xu, Jianyang Gao, Yutong Gou, Cheng Long, and Christian S. Jensen
会议：SIGMOD 2025
论文链接：https://arxiv.org/abs/2409.02571
源代码：https://github.com/YuexuanXu7/iRangeGraph

你是否遇到过这样的场景？

在电商平台，你想上传一张图片，寻找“价格在 500 到 800 元之间”的同款连衣裙。
在内容推荐系统中，你想为用户推荐“最近一周发布”，且内容最相关的文章。
在 AI 应用中，你想在海量知识库里检索“长度在 500 字以内”，且与问题最匹配的文档片段。

这些场景的核心技术挑战，就是 范围过滤近似最近邻搜索（Range-Filtering Approximate Nearest Neighbor Search, RFANN）。简单来说，就是在高维向量空间中找最近邻，同时附加一个或多个数值范围的过滤条件。

传统的解决方案通常顾此失彼：

先过滤，后搜索 (Pre-filtering)：先筛选出所有价格在范围内的商品，再逐一比较相似度。如果价格范围很宽，这种方法会退化为对大规模数据的线性扫描，速度极慢。
先搜索，后过滤 (Post-filtering)：先用图索引等方法找到最相似的几个商品，再看它们的价格是否符合范围。如果价格范围很窄，找到的近邻可能大部分都不在范围内，导致访问大量无关对象，效率低下。
搜索中过滤 (In-filtering)：在图搜索的每一步，都只访问价格符合范围的邻居。这听起来不错，但一个为全数据集构建的“通用图”，在面对特定范围时，很可能导致图的连通性变差，找不到最优解，从而降低搜索性能。

为了解决这些固有矛盾，有研究者提出了一种“终极”方案：为每一个可能的查询范围都预先构建一个专用的图索引。这样一来，任何查询都能找到完美匹配的索引，问题就退化成了最高效的普通 ANN 搜索。但这显然不现实，对于一个有 n 个对象的数据库，可能的范围组合有 $O(n^2)$ 个，存储所有这些图索引的开销是完全无法承受的。虽然有工作尝试对这些海量图进行有损压缩，但这又不可避免地因为信息的丢失而牺牲了查询的性能和精度。

那么，有没有一种方法，既能拥有“专用图”的高性能，又不必承受其天文数字般的存储开销呢？这正是 iRangeGraph 想要回答的问题。

iRangeGraph 的核心思想：化整为零，即时构建

iRangeGraph 的思路十分巧妙：我们不需要为所有可能的范围预先构建图，我们只需要准备一些“基础积木”，在查询时，用这些积木为任意查询范围“即时拼装”出一个专用的图。

这些“基础积木”被称为元素图（elemental graphs）。

索引构建：准备好“元素图”积木

iRangeGraph 借助了经典数据结构——线段树（Segment Tree） 的思想来组织这些元素图。

想象一下，我们将所有数据对象按照其数值属性（如价格）从低到高排序，形成一个 [1, n] 的完整区间。

第 0 层：为整个 [1, n] 区间的所有对象构建一个图索引。
第 1 层：将区间一分为二，为 [1, n/2] 和 [n/2+1, n] 这两个子区间的对象分别构建图索引。
第 2 层：继续分裂，为 [1, n/4], [n/4+1, n/2], … 等 4 个子区间构建图索引。
…以此类推，直到区间长度为 1。

整个索引结构是一个多层的分段结构，每一层都由若干个不相交的段组成，每个段都对应一个预先构建好的元素图（具体为近似 RNG 图）。

这样做的好处是显而易见的：一个数据对象在每一层只会出现在一个元素图中。对于一个有 n 个对象的数据集，总共只有 $O(\log n)$ 层，因此总的索引空间复杂度为 $O(nm \log n)$，这与为所有 $O(n^2)$ 个可能范围构建图的 $O(n^3m)$ 相比，大大降低了存储开销，使其变得完全可行。

查询处理：即时、高效地拼装“专用图”

当一个带有特定范围 [L, R] 的查询到来时，iRangeGraph 的魔法才真正开始。它并不会物化一个完整的专用图，而是在图搜索的过程中，“按需”为遇到的每个节点动态构建其邻居边。

具体如何构建呢？对于范围内的任意一个对象 u，它在索引的每一层都存在于一个元素图中，总共有 $O(m \log n)$ 组可以参考的邻居边。iRangeGraph 会基于一个聪明的策略从中进行选择：

优先选择来自与查询范围 [L, R] 重叠度更高的元素图中的边。

直觉上，一个元素图所覆盖的范围与查询范围重叠越大，其内部的连接关系就越能反映查询范围内的真实近邻结构，这些边也就越“可靠”。基于这个原则，论文设计了一套高效的边选择算法，该算法甚至可以智能地“跳过”某些层次的边选择。这套算法的平均时间开销为 $O(m + \log n)$，相对于访问 m 个邻居本身所需的 $O(md)$ 计算量来说，开销极低

实验效果如何？

iRangeGraph 的表现非常出色，可以说是“既要又要还要”的典范。

性能卓越且稳定

在多个真实数据集和不同查询负载（大范围、中范围、小范围和混合范围）下，iRangeGraph 的查询速度（QPS）在达到 90% 召回率时，比目前最强的基线方法快了 2 到 5 倍。
更重要的是，它在各种范围下都能稳定地获得高精度，而其他一些方法在某些场景下（如小范围或混合范围查询）则无法达到 0.8 以上的召回率。

以实用空间，达理想性能

研究者们做了一个有趣的对比，他们将 iRangeGraph 与 Oracle-HNSW 进行了比较。这个 Oracle-HNSW 为测试中的每一个查询都离线构建了一个完美的、专用的 HNSW 图。这在现实中是不可能做到的，因为它需要不切实际的巨大空间（$O(n^3m)$），但它代表了性能的理论上限。

结果惊人：iRangeGraph 的性能仅比这个不切实际的 Oracle-HNSW 慢不到 2 倍（在 0.9 召回率下）。这证明了 iRangeGraph 以一种非常聪明的方式，用极小的性能代价换取了巨大的空间节省，达到了接近理想情况的性能，而其空间开销却是实际可用的 $O(nm \log n)$。

支持多属性过滤

该方法还能自然地扩展到多个数值属性的联合查询（例如，价格在[500, 800] 且好评率在[95%, 100%]）。其扩展版本同样取得了当前最佳的性能，在达到 90% 召回率时，查询速度比最强的基线方法快了 2 到 4 倍。

总结

对于任何需要处理带范围过滤的向量搜索任务的开发者和研究者来说，iRangeGraph 提供了一个全新的、高效且实用的解决方案。它通过“即时构建专用图”的核心思想，巧妙地绕过了现有方法在性能、空间和准确性之间的两难困境。

通过预先构建一组可控的“元素图”，并在查询时动态、高效地组合它们，iRangeGraph 在保持中等存储占用的同时，实现了接近理论最优的查询性能。这无疑为高维数据检索系统的设计和实现提供了重要的参考和强大的新工具。

AI 编码的“苦涩教训”：为何 Claude Code 和 Amp 的“蛮力”胜过 Cursor 的“巧思”

Mon, 23 Jun 2025 23:19:00 +0800

在 AI 编程工具的浪潮中，开发者们正面临一个有趣的选择。一方是以 Cursor 为代表的、将 AI 无缝集成到精美图形界面中的“一体化 IDE”；另一方则是以 Claude Code 和 Amp 为代表的、以终端为核心、追求极致性能的“编码代理”。

表面上看，这似乎只是用户体验（UX）的差异：一个为便利性而生，一个为专业性而生。但通过深入研究，你会发现这背后隐藏着两种截然不同的技术哲学。这种分歧，深刻地呼应了人工智能领域一个著名而反直觉的原则——理查德·萨顿（Richard Sutton）的苦涩的教训（The Bitter Lesson）。

这篇博客将阐述，为何 Claude Code 和 Amp 略显“原始”和“粗暴”的方法，可能更接近 AI 发展的真理；而 Cursor 精心设计的“巧思”，反而可能成为了其自身能力的瓶颈。

“苦涩的教训”在 LLM 时代的重现

“苦涩的教训”是强化学习之父理查德·萨顿提出的一个观察：在长达 70 年的人工智能研究中，那些试图利用人类领域知识、进行精巧设计的复杂系统，最终总是被那些基于大规模计算的通用方法所超越。简而言之，就是“大力出奇迹”——更强的算力 + 更通用的算法，胜过人类的精巧设计。

在当今的大语言模型（LLM）时代，这个教训可以被重新诠释：

大规模计算 (Scale) = 更强大的基础模型（如 GPT-4, Claude 4 Opus）+ 海量的、未经删减的上下文（Context）。
人类的精巧设计 (Human Knowledge) = 复杂的提示工程、为了节省成本而设计的上下文管理策略、以及层层编排的 UI 工作流。

“苦涩的教训”告诉我们，最终的胜利者，将是那些最大限度地释放大模型原始智能、而非用人类的“小聪明”去限制或“引导”它的工具。

Cursor：精心编排的“温室花园”

让我们明确一点：Cursor 是一款杰出的产品。它通过复刻（Fork）VS Code，提供了一种无与伦比的、无缝的 AI 开发体验。它的“Tab 键预测下一处修改”、内联聊天、自动调试等功能，极大地提升了日常编码的效率。

然而，正是这种对“便利性”和“效率”的极致追求，使其在设计上与“苦涩的教训”背道而驰。

根据我们的研究，Cursor 的核心思路是编排与控制：

主动的上下文管理：为了控制高昂的 Token 成本并提升响应速度，Cursor 会在后台对你的代码进行处理。它可能不会将你引用的每个文件的全部内容发送给 LLM，而是发送摘要、相关的代码片段（Snippets）或基于向量搜索的检索结果（RAG）。
复杂的内部流程：其代理功能（Agentic Features）依赖于一个类似“Pocket Flow”的、由人类设计的复杂流程图。任务被分解为不同的节点（决策、读文件、应用修改等），AI 在这个预设的轨道上运行。

这种方法就像是建造一个精心设计的温室。它很高效，能产出漂亮的花朵。但这个温室的天花板，就是由设计者（人类）的智慧所决定的。当 AI 需要处理一个需要通盘理解整个代码库、在多个文件中进行复杂推理的“参天大树”级任务时，这个为了控制成本而设计的“温室天花板”（即有限的上下文）就成了它无法逾越的障碍。

Claude Code & Amp：拥抱“野蛮生长”的原始力量

与 Cursor 相反，Claude Code 和 Amp 的哲学更像是释放与信任。它们的设计粗看起来有些“简陋”，甚至“野蛮”——通常以终端（CLI）为主要交互界面。但这种“简陋”恰恰是它们遵循“苦涩的教训”的体现。

它们的核心思路是拥抱大规模计算：

近乎无限的上下文：这是它们与 Cursor 最根本的区别。当用户提出一个请求时，它们的设计理念是尽可能将所有相关文件的完整内容提供给 LLM。它们不相信摘要，只相信原始数据。这虽然成本高昂，但却将模型的“视野”从一个狭窄的窗口扩展到了整个战场。
更通用的代理能力：以终端为核心，意味着它们能更原生、更直接地与开发者的整个工具链（git, npm, pytest, gh）互动。AI 不再是一个被限制在编辑器图形界面里的助手，而是一个能直接操作开发者环境的“实习生”。

Anthropic 在其官方博客中甚至详细介绍了 Claude Code 的最佳实践：鼓励用户通过 CLAUDE.md 文件来主动构建一个庞大而精确的、可被版本控制的项目级上下文；鼓励进行测试驱动开发（TDD），让 AI 写代码、跑测试、再根据失败结果进行修改。

这正是“苦涩的教训”所推崇的——给予最强大的通用算法（Claude 4 Opus），辅以最大规模的计算资源（海量上下文），然后放手让它去解决问题。

质量的鸿沟：当“巧思”遭遇“蛮力”

这种哲学上的差异，最终体现在了代码输出的质量上。

在大量的开发者社区讨论中，一个反复出现的观点是：对于日常的、小范围的代码生成或修改，Cursor 的体验非常流畅。但一旦涉及到需要深度代码库理解的大型重构、修复隐藏 Bug 或学习全新项目等复杂任务时，Claude Code 的输出质量“完全在另一个层次”。

原因很简单：当 Cursor 的 AI 在阅读一份“报告摘要”时，Claude Code 的 AI 正在阅读“完整的原始文档”。后者自然能做出更深刻、更准确的判断。Cursor 精心设计的编排，在这些复杂任务面前，反而成了限制模型发挥的枷锁。

结论：为今天编码，还是为明天投资？

Cursor 是为今天的开发者设计的完美工具。它在现有技术和成本的约束下，通过精巧的人类智慧，将 AI 的生产力提升带给了最广泛的开发者，其体验是打磨到极致的。

而 Claude Code 和 Amp，则代表了明天的方向。它们的设计哲学押注于一个更宏大的未来：随着基础模型越来越强大、上下文窗口越来越长、Token 成本越来越低，“苦涩的教训”将再次应验。那些试图用小聪明去“管理”AI 的系统，终将被那些简单、粗暴、直接释放 AI 全部潜能的系统所取代。

选择哪一个，取决于你的需求。是选择一个极其便利的助手来优化你当前的工作流，还是选择一个能力上限极高、但需要你改变习惯去驾驭的强大代理？

“苦涩的教训”告诉我们，历史的趋势是明确的。今天看似“野蛮”的“蛮力”，很可能就是通往未来通用人工智能编程的康庄大道。

LanceDB 技术架构分析：存储、缓存、ANN 索引及 Lance 文件格式

Tue, 20 May 2025 23:03:58 +0800

1. 引言：LanceDB 的技术架构概览

LanceDB，定位为面向多模态人工智能的数据库，旨在为人工智能数据的搜索、训练、预处理和探索提供便捷高效的解决方案，并具备处理 PB 级数据的能力。其核心优势在于能够统一存储包括嵌入向量、元数据以及原始音频、图像和视频等各种人工智能数据。LanceDB 构建于 Lance 文件格式之上，这是一个开源的列式存储标准，专为多模态数据设计，据称其速度比 Parquet 快 100 倍，并且在模式演进方面优于 Iceberg 。LanceDB 支持生产级别的向量搜索，无需管理服务器，并原生支持 Rust、Python 和 Javascript/Typescript 等多种编程语言。其设计目标包括在十亿级向量索引上实现毫秒级的搜索性能，通过计算存储分离实现高达 100 倍的成本节约，以及通过先进的检索技术提升人工智能的准确性。

从架构层面来看，LanceDB 旨在提供一个易于使用且具备强大功能的平台，特别强调其对多模态数据的原生支持以及在处理大规模数据集时的性能和成本效益。其核心设计理念是简化 AI 应用的数据管理流程，将多种数据类型统一存储和管理，从而降低数据访问成本，并优化 AI 模型的训练和推理过程。LanceDB 的企业版进一步扩展了这些能力，旨在将数据湖转化为高性能的向量数据库，能够处理数百万个表和数百亿行数据，并提供混合搜索等高级功能。作为一个开发者友好的、无服务器的向量数据库，LanceDB 可以嵌入到现有的后端服务和客户端应用中，或者作为远程服务运行。这种灵活性使其能够适应各种不同的应用场景和部署需求。

2. LanceDB 的存储架构深度分析

LanceDB 的存储架构核心在于其持久化数据的管理机制。作为一个具备持久化存储能力的向量搜索引擎，LanceDB 能够存储数十亿的向量而无需将所有数据加载到内存中。这种基于磁盘的存储方式不仅降低了对内存的依赖，也使得数据在应用重启后依然能够保持其完整性。LanceDB 的设计初衷便是实现高效的磁盘操作，其模块化的组件也为此进行了优化。这种架构上的选择使得 LanceDB 能够支持大规模数据集，实现超越内存限制的数据存储和管理。此外，LanceDB 还提供了自动数据版本控制功能，无需额外的基础设施即可管理数据的不同版本。数据的底层存储格式采用了 Lance 格式，这是一种将数据存储为多个不可变片段的列式存储格式。

LanceDB 在存储后端方面提供了广泛的选择，以满足不同用户在成本、延迟、可扩展性和可靠性方面的需求。对于开源版本的 LanceDB，用户可以选择将数据存储在本地磁盘上，或者利用云对象存储服务，如 AWS S3、Google Cloud Storage 和 Azure Blob Storage 。选择哪种对象存储取决于数据集路径的 URI 方案（例如，s3://、az://、gs://）。在云环境中运行时，如果权限配置正确，通常无需额外的配置即可使用这些服务。然而，当在云环境之外运行时，可能需要提供身份验证凭据，这些凭据可以通过环境变量或在连接时通过 storage_options 对象进行配置。除了对象存储，LanceDB 还支持其他存储选项，如 EFS、GCS Filestore、Azure File Storage、第三方兼容 S3 的存储解决方案（如 MinIO、WekaFS）以及 EBS、GCP Persistent Disk 和 Azure Managed Disk 。每种存储选项都在成本、延迟、可扩展性和可靠性方面有所权衡。LanceDB Cloud 作为托管服务也提供了一种便捷的存储方案，用户可以通过 db://dbname 的连接字符串进行访问。不同的存储后端选择会直接影响数据的访问延迟、存储容量的扩展能力、存储成本以及系统的整体可靠性。用户需要根据其具体的应用场景和需求来权衡这些因素，选择最合适的存储方案。通常的建议是从成本最低的对象存储开始，然后根据延迟需求逐步考虑延迟更低的存储选项。

LanceDB 的一个重要设计理念是计算与存储分离。Lance 文件格式将数据存储为多个不可变的片段，这为实现计算与存储分离奠定了基础。通过这种分离，查询处理可以在无状态的方式下运行，从而可以根据需要灵活地扩展和缩减计算资源，尤其是在使用对象存储时。这种架构上的解耦带来了显著的成本优势，通过独立地扩展计算和存储资源，可以实现高达 100 倍的成本节约。计算存储分离是现代云原生架构的关键特征，它允许用户根据实际的计算需求和存储需求独立地进行资源管理和优化，从而提高效率并降低成本。

表 1：LanceDB 存储后端权衡

存储后端	成本	延迟	可扩展性（存储）	可扩展性（QPS）	可靠性/可用性	管理开销
S3 / GCS / Azure Blob Storage	最低	最高	无限	受云提供商限制	高度可用	低
EFS / GCS Filestore / Azure File	较低	较低 (<100ms)	高	受 IOPs 限制	高度可用	中等
第三方 S3 兼容方案	较低	较低 (<100ms)	取决于架构	取决于架构	取决于供应商	中等
EBS / GCP Persistent Disk / Azure	较高	非常低 (<30ms)	受实例限制	受实例限制	高（实例内）	中到高
本地磁盘 (SSD/NVMe)	最高	最低 (<10ms p95)	受实例限制	受实例限制	高

3. Lance 文件格式：结构与功能

Lance 文件格式是 LanceDB 的核心组成部分，它不仅定义了数据的存储方式，也影响着 LanceDB 的性能和功能。Lance 格式既是一种表格式，也是一种文件格式，通常将表称为 " 数据集 " 。

3.1 目录组织形式及其原因

一个 Lance 数据集在文件系统中以目录的形式组织，包含以下核心组件：

data/*.lance：数据文件。这些文件存储实际的列式数据，并以不可变片段的形式存在。这种设计支持计算与存储分离，并为高效的数据版本控制奠定基础。
_versions/*.manifest：清单文件。每个数据集版本都有一个对应的清单文件，记录了该版本包含哪些数据文件和索引信息。这是实现自动数据版本控制和时间旅行的关键，允许用户访问数据的历史状态。
_indices/{UUID-*}/index.idx：二级索引目录。每个二级索引（如向量索引或标量索引）都有一个独立的目录，通过 UUID 进行唯一标识，其中包含索引数据。这种分离使得索引可以独立于数据进行管理和更新，提高了灵活性。
_deletions/*.{arrow.bin}：删除文件。这些文件记录了被标记为删除的行，而不是立即从底层存储中移除数据。这支持了软删除机制，有助于维护 ACID 属性和时间旅行能力。

这种二维存储布局（行被划分为垂直片段，每个片段再水平划分为数据文件）是 Lance 格式的核心设计，旨在高效处理机器学习工作负载中常见的 " 宽表 " 和模式演进问题。

3.2 更新操作对目录结构的影响

Lance 文件格式在数据更新和模式演进方面表现出色，其目录结构的变化体现了其 " 零拷贝 " 和异步处理的优势：

添加新列（Schema Evolution）： Lance 支持 " 零拷贝模式演进 “，这意味着在数据已经添加后，可以向表中添加新的列，而无需重写现有数据。当添加新列时，Lance 只需向每个数据片段添加一个新的数据文件，该文件仅包含新列的数据，而无需修改现有的数据文件。这种方式显著提高了效率，尤其是在处理包含大量数据（如嵌入向量或图像）的宽表时，避免了昂贵的全表重写操作。
添加/更新/删除行：
- 批量插入：强烈建议通过批量插入（例如，Pandas DataFrames 或 Python 中的字典列表）来加速大型数据集的数据摄取。批量处理允许 LanceDB 创建更大（及其相关的清单文件）的数据片段，这些片段在读写时效率更高。
- 单行插入：一次插入一条记录会很慢，并且由于每次插入都可能在磁盘上创建一个新的小数据片段，因此可能导致次优性能。
- 数据更新与删除：删除或更新数据会触发异步的后台索引更新，无需用户手动重新索引。新添加的向量即使索引尚未完全构建，也可以通过回退的暴力搜索机制立即搜索，确保了数据插入和可搜索性之间的零延迟，但可能会暂时增加查询响应时间。
- 优化操作： LanceDB 提供 optimize 命令，用于定期维护表。这个操作会合并小的文件片段以提高读取效率（压缩），移除旧版本的数据集（修剪），并优化索引，将新数据合并到现有索引中。这有助于保持查询性能，尤其是在频繁进行数据修改后。

3.3 Lance 与 Parquet 的随机访问性能对比

Lance 格式在设计上特别优化了随机访问性能，声称比 Parquet 快 100 倍，在某些基准测试中甚至高达 1000 倍。这种显著的性能差异源于两者在文件结构和数据编码上的根本性设计选择：

Parquet 的局限性：
- I/O 操作数： Parquet 的结构编码通常需要每行至少一次 I/O 操作（IOP）来获取该行所属的数据页。
- 页面大小依赖： Parquet 的性能高度依赖于页面大小，因为 IOP 的大小是 NVMe 存储上随机访问性能的关键决定因素。
- 不透明压缩与读取放大： Parquet 中的许多压缩算法是 " 不透明的 “，这意味着为了访问单个值，必须完全解码整个数据块。这会导致 " 读取放大 “，即读取的数据量远大于实际所需的数据量，从而降低随机访问效率。
Lance 的优势：
- 最小化 IOPs： Lance 的结构编码旨在最大限度地减少随机访问所需的 IOPs。对于固定宽度列，它最多只需要 1 个 IOP；对于可变宽度列，最多需要 2 个 IOP，且性能不受嵌套级别、数据类型大小或压缩方式的影响。这得益于其对重复级别和定义级别等结构信息的有效编码。
- 高效利用 NVMe： Lance 旨在充分利用 NVMe SSD 的性能。一块好的 NVMe SSD 每秒可以执行近百万次读取（例如，一块 200 美元的家用 SSD 可以达到约 80 万次读取/秒），这意味着平均延迟接近 1 微秒。Lance 的设计能够有效利用这种低延迟特性，而 Parquet 在这方面表现不足。
- 移除行组（Lance v2）： Lance v2 移除了 Parquet 中存在的 " 行组 " 概念，这在 Parquet 中是性能和并行性的一个 " 大坑 " 。通过移除行组，Lance v2 在全数据集扫描方面效率更高，甚至在文件大小是 Parquet 的 2-3 倍时也能超越 Parquet 。

实际数据与形象解释：

想象一下，你有一本非常厚的书（数据集），其中包含很多章节（列）。

Parquet 就像这本书的每一页都可能包含来自不同章节的零散信息，并且为了节省纸张，每一页都经过了复杂的压缩。当你需要查找某个特定章节中的一个词（随机访问一个值）时，你可能需要翻阅很多页，并且每次找到一页，你都得把整页的内容都解压出来才能找到那个词，即使你只需要其中一小部分。这导致了大量的 " 翻页 " 和 " 解压 " 工作，尤其是在你需要快速跳到书的不同部分时。
Lance 则像这本书的每一章都被单独整理成了一叠卡片，并且每张卡片上的信息都以一种可以直接读取的方式编码。当你需要查找某个章节中的一个词时，你只需要找到对应的卡片叠，然后直接从卡片上读取信息，而不需要解压整叠卡片。即使你需要查找的词在卡片叠的不同位置，Lance 也能通过其巧妙的索引和编码，以最少的 " 翻页 " 次数（I/O 操作）直接定位到你需要的卡片。具体性能数据：
在对包含 score 和 category 列进行过滤，并投影 id 和 embedding 列的基准测试中，Lance 的速度比优化前快 30 倍，并且比 Parquet 的扫描性能快 2.8 倍。这一改进将 I/O 调用次数从 10,248 次减少到仅 538 次，I/O 减少了 94% 。
即使是针对标量列（仅投影 id 和 score），Lance 的查询时间也比旧版本提高了 3 倍，并且仅比 Parquet 慢约 3 毫秒。
Lance 在点查询（point query）方面比 Parquet 快 2000 倍。这些数据和解释共同表明，Lance 格式通过其为 AI/ML 工作负载量身定制的结构和编码，在随机访问和过滤查询方面实现了对 Parquet 的显著性能超越。

4. 缓存机制：性能优化的关键

LanceDB 采用了多层次的缓存策略来优化查询性能并降低延迟。

4.1 索引缓存

LanceDB 的核心缓存机制是其索引缓存，用于在内存中存储向量和标量索引数据，以加速查询。当索引数据从内存缓存中加载时，系统不会触发 I/O 事件，这直接证明了缓存的有效性及其对减少磁盘访问的贡献。

目的与作用：索引缓存的主要目的是通过将频繁访问的索引结构保存在更快的内存中，显著减少对较慢存储（如磁盘或云对象存储）的访问需求，从而加快查询响应速度。这对于降低查询延迟，特别是 " 冷启动 " 时间至关重要。
配置与管理：
- 对于开源版本的 LanceDB，用户可以在创建 LanceDataset 时通过 index_cache_size 参数配置索引缓存的最大大小。
- 缓存采用 LRU（最近最少使用）淘汰策略，并根据缓存条目数量进行大小调整。
- 缓存中每个条目的大小取决于索引类型（例如，IVF/PQ 索引包含一个头部条目和每个分区的条目）。索引缓存的字节大小可以通过 dataset.session().size_bytes() 方法查看。
客户端 SDK 缓存（JavaScript SDK 为例）：在 JavaScript SDK 中，Table 对象会维护一个内存中的索引数据缓存。这个缓存旨在为客户端应用程序提供更快的查询响应，减少每次操作都从磁盘加载索引的开销。当 Table 对象被垃圾回收时，其关联的缓存会自动释放。用户也可以通过显式调用 close() 方法来立即释放缓存的索引数据，从而更精细地控制内存使用。这对于资源受限的客户端环境或需要严格内存管理的场景非常有用。
共享限制：索引缓存在不同的表之间是不共享的。为了获得最佳性能，LanceDB 建议在整个应用程序中使用单个表实例。

4.2 I/O 缓存（RemoteTake）

除了索引缓存，LanceDB 还利用 I/O 缓存来优化从远程存储（如云对象存储）的数据检索效率。其中一个关键组件是 RemoteTake 。

工作原理： RemoteTake 机制的核心在于其 " 按需取用 " 的能力。它能够高效地从远程存储位置检索数据，并且只获取最终输出所需的特定行和列。例如，如果一个查询只需要 chunk_index 和 title 列，RemoteTake 会精确地只读取这些列的数据，而不是加载整个文件或所有列。
性能优势：这种机制通过最小化网络带宽的使用和不必要的数据传输，显著优化了远程数据访问的性能。它与 Lance 文件格式的 " 部分读取不要求加载整个文件 " 的特性相辅相成，共同降低了数据访问成本。
默认启用： LanceDB 的计划执行器（Plan Executor）默认启用了 NVMe SSD 缓存，并实现了高性能的一致性哈希，以确保缓存的有效利用和数据一致性。

4.3 线程池与内存管理

LanceDB 的性能优化还体现在其对线程池和内存管理的精细控制上，这些都与缓存机制协同工作：

IO 线程池：专门用于执行磁盘数据的读写操作。
- 默认情况下，本地存储使用 8 个 IO 线程，而云对象存储使用 64 个 IO 线程。
- 在云环境中，为了充分利用高网络带宽，可能需要增加 IO 线程的数量（例如，到 128 或 256）。
- 用户可以通过设置 LANCE_IO_THREADS 环境变量来覆盖默认的 IO 线程数。
计算线程池：用于对数据执行计算，包括数据解码。
- 线程数量通常由机器的核心数决定，但可以通过 LANCE_CPU_THREADS 环境变量覆盖。
- 即使是看似 I/O 密集型的操作（如扫描表），也可能需要大量的计算线程来达到最佳性能，因为数据解码是计算密集型操作。
扫描内存需求： LanceDB 旨在通过数据流式传输来保持内存效率，避免将整个数据集加载到内存中。然而，扫描数据时的内存需求受 io_buffer_size 和 batch_size 参数的影响。
- 每个 I/O 线程应有足够的内存来缓冲一个完整的数据页（通常在 8 到 32MB 之间，建议每个 I/O 线程大约 32MB 内存）。
- 默认的 io_buffer_size 为 2GB，可以缓冲 64 个数据页。如果增加了 IO 线程的数量，也应该相应地增加 io_buffer_size 。
- batch_size 决定了每次 CPU 线程处理的数据量。当处理大数据（例如，高维嵌入向量）时，可能需要减小 batch_size 以控制内存使用。例如，对于 1024 维的 32 位浮点向量，8192 行数据将占用 32MB 内存。如果分发到 16 个 CPU 线程，则每次扫描需要 512MB 的计算内存。在这种情况下，较小的 batch_size（如 1024 行）可能更合适。

5. 近似最近邻（ANN）索引技术

LanceDB 实现了先进的近似最近邻（ANN）索引算法，特别是 IVF-PQ 和 IVF-HNSW-SQ，以优化在高维数据中搜索相似向量的效率。LanceDB 的索引主要是基于磁盘的，这与其他一些向量数据库形成对比。

5.1 索引类型与结构

IVF-PQ (倒排文件索引与乘积量化)： IVF-PQ 是一种两阶段的复合索引技术，旨在平衡搜索速度和准确性。
- 倒排文件（IVF）阶段：在第一阶段，索引将向量空间划分为预定义数量的分区或聚类。这些聚类通常通过 k-means 等聚类算法学习得到，每个聚类由一个质心向量表示。在构建索引时，每个数据向量都根据其与聚类质心的距离被分配到最近的聚类中。这创建了一个 " 倒排文件 “，其中每个聚类 ID 指向属于该聚类的向量列表。IVF 的主要目的是通过缩小搜索空间来提高搜索性能。
- 乘积量化（PQ）阶段：在第二阶段，为了进一步压缩每个聚类中的向量并加速距离计算，PQ 被应用。PQ 将每个高维向量分成多个低维子向量。对于每个子向量，它学习一个小的代表性 " 码本向量 " 或 " 质心 " 集合。然后，每个子向量都通过其在相应码本中最接近的码本向量进行近似表示，并用该码本向量的索引（或代码）来代替。这个过程显著降低了存储需求，并通过比较短代码而不是原始高维向量来实现更快的近似距离计算。
- 搜索过程：在搜索查询期间，查询向量首先在 IVF 阶段被分配到少数几个最近的聚类中。然后，在这些选定的聚类中，使用 PQ 代码近似计算查询向量（也可能被 PQ 编码）与数据向量之间的距离。这种两阶段的方法显著缩小了搜索空间和计算成本，从而实现了高效的近似最近邻检索。
- 自动创建： LanceDB 针对高维向量优化了 IVF-PQ。当一个表包含一个名为 vector 的单个向量列且向量数量超过 256 个时，LanceDB 会自动创建一个使用 L2 距离的优化 IVF-PQ 索引，而无需手动配置。
HNSW (分层可导航小世界)： HNSW 是一种基于图的索引算法，它构建一个多层级的分层图。图的底层包含所有的数据点。每个后续的更高层都包含一个逐渐变小的数据点子集，作为更快导航的入口点。图中的边连接最近邻点。较高层中的连接是长距离的，允许快速跳转到图中有希望的区域，而较低层中的连接是短距离的，可以在局部邻域内进行细粒度的搜索。
- 搜索过程：要执行搜索，查询向量从图的顶层的一个入口点开始。然后它通过各层向下导航，在每一层移动到最接近查询的邻居。这个过程一直持续到它到达底层，在那里执行局部搜索以找到最近邻。图的分层结构和可导航的小世界特性使得能够进行高效快速的近似最近邻搜索。
- LanceDB 支持： LanceDB 支持 IVF_HNSW_SQ 索引类型，它结合了 IVF 聚类和 HNSW 图，与仅使用 IVF-PQ 相比，可能提供更高的搜索质量。
距离度量： LanceDB 支持多种距离度量来衡量向量之间的相似性，包括 L2（欧几里得距离，默认）、Cosine（余弦相似度）、Dot（点积）和 Hamming（汉明距离，仅适用于二进制向量）。对于二进制向量，应使用汉明距离和 IVF_FLAT 索引类型，并且向量维度必须是 8 的倍数。

5.2 过滤向量搜索（Filtered Vector Search）

LanceDB 在向量搜索中提供了强大的过滤能力，支持将向量相似性搜索与元数据过滤和全文搜索相结合，以实现更精确的检索。

预过滤（Pre-filtering）与后过滤（Post-filtering）：
- 预过滤：默认情况下，LanceDB 会执行预过滤，即在向量搜索之前应用过滤器。这对于缩小非常大的数据集的搜索空间以减少查询延迟非常有用。例如，在一个 120 万行的 Wikipedia 数据集中，预过滤可以将搜索空间从 120 万行减少到约 110 万行，从而优化后续的 KNN 计算。
- 后过滤：也可以选择在向量搜索返回结果后进行过滤。
- 性能影响：即使在进行元数据过滤的情况下，如果缓存已预热，查询延迟也能保持在较低水平（例如，65 毫秒，针对 1500 万向量数据集的基准测试）。
标量索引（Scalar Index）：为了加速过滤操作，LanceDB 支持在标量列上创建索引。强烈建议在 WHERE 子句中使用的过滤列上创建标量索引，因为它们可以显著减少需要扫描的数据量，从而加快过滤速度。
- 索引类型： LanceDB 支持多种标量索引类型：
  - BTREE：最常见的类型，适用于具有许多唯一值和每值行数较少的列。
  - BITMAP：为每个唯一值存储一个位图。适用于具有有限数量唯一值和每值行数较多的列（例如，类别、标签、标签）。
  - LABEL_LIST：专门用于 List列，支持使用底层位图索引进行 array_contains_all 和 array_contains_any 查询。
- UUID 列： LanceDB 还支持在 UUID 列（存储为 FixedSizeBinary(16)）上创建标量索引，从而实现基于 UUID 主键的高效查找和过滤。
- 自动优化：标量索引的构建是异步的，并且 LanceDB 会自动优化这些索引，无需用户手动重新索引。
全文搜索索引： LanceDB Cloud 和 Enterprise 提供基于 BM25 的高性能全文搜索，允许将关键词搜索整合到检索解决方案中。全文搜索索引的构建也是异步的，并且会自动优化。
性能分析工具： LanceDB 提供了 explain_plan 和 analyze_plan 等工具，用于详细分析查询性能，包括过滤器的应用和索引的使用情况。通过这些工具，用户可以验证查询优化策略、确认索引选择、理解查询执行顺序以及检测缺失的索引。例如，analyze_plan 可以显示标量索引查询如何显著减少向量比较次数（例如，从约 110 万次减少到 2 千次），从而大幅提升性能。
统计信息与页面剪枝： Lance 文件格式引入了列统计信息和基于统计信息的页面剪枝功能。这种增强功能减少了带过滤器的扫描所需的 I/O 调用次数，在某些情况下使扫描速度提高 30 倍，I/O 减少 94% 。这些统计信息可以在向量搜索的预过滤阶段使用，以进一步提高带有元数据过滤的 ANN 查询的性能。

5.3 索引管理与优化

参数调整：在调整 ANN 索引性能方面，LanceDB 提供了关键参数，如 nprobes 和 refine factor 。
- nprobes：控制在查询期间搜索（探测）的索引分区数量。增加 nprobes 的值通常会提高搜索准确性，但同时也会增加查询延迟。
- refine factor：一个乘数，它决定了在初始近似搜索之后，有多少额外的行被获取并根据原始向量距离重新排序，从而在略微增加延迟的情况下提高召回率。例如，如果检索前 10 个结果并将 refine_factor 设置为 25，LanceDB 将获取 250 个最相似的向量（根据 PQ），然后根据这些向量的完整距离重新排序前 10 个结果。
- distance range：搜索指定距离范围内的向量。
自动索引与异步更新： LanceDB 提供了自动索引功能，一旦数据更新，就会自动优化所有类型的索引。当一个表包含一个名为 “vector” 的单个向量列时，LanceDB 会自动创建一个优化的 IVF-PQ 索引，无需手动配置。添加到表中的新向量可以通过回退的暴力搜索机制立即搜索，即使索引尚未完全构建。这确保了数据插入和可搜索性之间的零延迟，但可能会暂时增加查询响应时间。类似地，删除或更新数据也会触发异步的后台索引更新，无需用户手动重新索引。
绕过索引： bypass vector index 功能（或通过 use_index 标志控制）优先考虑搜索准确性而非查询速度，通过对所有向量执行穷举搜索来实现。这对于评估 ANN 索引质量、计算召回率指标或基准测试近似搜索与精确搜索结果非常有用，尽管会增加查询延迟。此外，fast_search 标志可以用于跳过搜索未索引的数据，以优化速度。

6. 性能分析与优化策略

LanceDB 的整体性能受多种因素影响，包括存储选择、索引策略、缓存效率和查询结构。存储后端的选择直接影响延迟和吞吐量。有效地利用缓存（包括索引缓存和数据缓存）可以显著降低查询延迟。ANN 索引的类型和配置（例如，nprobes、refine factor）决定了搜索速度和准确性之间的平衡。查询的结构，包括使用的过滤器和请求的结果数量，也会影响执行时间。底层 Lance 格式在数据访问和操作方面的效率至关重要。使用 IO 和计算线程池进行并行处理有助于提高整体吞吐量。Lance 格式中基于统计信息的页面剪枝等优化技术可以显著加快带有过滤器的扫描速度。

LanceDB 提供了 explain_plan 和 analyze_plan 等工具，用于详细分析查询性能。explain_plan 在查询执行前显示逻辑查询计划，帮助用户识别潜在的查询结构问题和索引使用情况。analyze_plan 执行查询并提供每个步骤的详细运行时指标，包括操作持续时间、处理的数据量、索引效率和资源利用率。这些工具可以帮助用户验证查询优化策略、确认索引选择、理解查询执行顺序以及检测缺失的索引。通过分析这些工具的输出，用户可以识别性能瓶颈并优化他们的查询和数据组织方式。

为了优化 LanceDB 的性能，可以采取多种最佳实践。选择最能平衡成本和延迟的存储后端，对于特定的用例，可以从成本效益高的对象存储开始，然后根据需要扩展到延迟更低的选项。对于大规模数据集上的可扩展向量检索，创建向量索引（IVF-PQ 或 IVF-HNSW-SQ），LanceDB 通常会自动在名为 “vector” 的列上创建索引。调整 ANN 索引参数（如 nprobes 和 refine factor）以根据应用程序需求平衡召回率和延迟。考虑在过滤列上使用标量索引（BTREE、BITMAP、LABEL_LIST）以加速过滤。利用全文搜索索引实现高效的关键词搜索。优化查询设计，通过使用过滤器在向量搜索之前缩小搜索空间，根据数据集和查询模式考虑预过滤或后过滤。批量插入数据以获得更好的性能，因为单独插入会创建许多小片段。在高网络带宽的云环境中，增加 IO 线程数（LANCE_IO_THREADS）并调整 io_buffer_size 。使用 explain_plan 和 analyze_plan 监控查询性能，以识别和解决瓶颈。将常用的索引加载到缓存中以减少冷启动时间，但要注意内存使用。定期运行 optimize 命令，尤其是在进行大量数据修改（添加、删除、更新）后，以通过压缩、修剪和索引优化来提高性能。对于需要最高准确性的应用程序，可以考虑使用 bypass vector index 功能绕过 ANN 索引进行穷举搜索，但要注意增加的延迟。

强烈建议通过批量插入（例如，Pandas DataFrames 或 Python 中的字典列表）来加速大型数据集的数据摄取。一次插入一条记录很慢，并且由于每次插入都可能在磁盘上创建一个新的小数据片段，因此可能导致次优性能。批量处理允许 LanceDB 创建更大（及其相关的清单文件）的片段，这些片段在读写时效率更高。高效的数据摄取对于许多 AI 应用至关重要。LanceDB 关于批量插入的建议强调了优化写入操作以提高性能的重要性，尤其是在处理大量数据时。

7. LanceDB 在向量数据库领域中的地位

LanceDB 通过构建在 Lance 列式格式之上，并专注于多模态数据处理，使其在向量数据库领域中独树一帜，这与其他可能仅存储嵌入向量和元数据的传统向量数据库有所不同。与一些内存向量数据库不同，LanceDB 主要基于磁盘进行索引和存储，这降低了对内存的依赖，更适合处理大型数据集。LanceDB 可以像 SQLite 或 DuckDB 一样嵌入运行，提供无服务器选项，这与 Milvus 等客户端 - 服务器架构或 Pinecone 等云原生托管服务有所不同。虽然 Pinecone 专注于云端高性能、高精度的向量搜索，并采用托管服务模式，但 LanceDB 在部署（嵌入式、无服务器、云存储）和搜索算法的深度定制方面提供了更大的灵活性。Milvus 是一个更成熟、可扩展且功能丰富的开源向量数据库，侧重于高性能和可伸缩性，通常部署在分布式架构中，而 LanceDB 则更强调简单易用，尤其适用于 AI 开发。Weaviate 结合了对象和向量存储，为 AI 应用提供了类似图的结构，而 LanceDB 更侧重于列式存储和高效的向量搜索以及多模态数据的支持。LanceDB 支持混合搜索，将向量相似性与元数据过滤和全文搜索相结合，这与其他一些向量数据库也具备的能力，但在实现细节和性能特征上可能有所不同。

LanceDB 的架构，凭借其对多模态数据的关注、高效的存储、灵活的部署以及与 AI/ML 生态系统的强大集成，使其成为各种 AI 应用的有力竞争者，特别是那些涉及大型数据集、多样化数据类型以及需要兼顾性能和成本效益的应用。LanceDB 非常适合用于检索增强生成（RAG）管道，这得益于其高效的向量搜索和多模态支持。其嵌入式特性使其成为本地 AI 开发和数据隐私至上的应用的理想选择，例如 Continue 在代码辅助方面采用的本地优先架构。LanceDB 高效处理大规模多模态 AI 数据的能力使其适用于训练管道、大规模数据集（如代码库）的语义搜索以及 AI 数据的交互式分析。通过计算存储分离实现的成本效益高的可扩展性使其对数据量快速增长的应用具有吸引力。它与 LangChain、LlamaIndex、Apache Arrow、Pandas、Polars 和 DuckDB 等数据科学工具和库的集成简化了开发工作流程。其用例包括构建搜索引擎、特征存储、问答机器人、推荐系统以及需要混合搜索和元数据过滤的应用。

8. 结论

LanceDB 的技术架构展现出其作为面向多模态人工智能数据库的独特优势。其核心在于专为 AI/ML 工作负载设计的 Lance 列式文件格式，该格式在随机访问、模式演进和向量数据处理方面均优于传统格式。LanceDB 通过支持多种存储后端和实现计算存储分离，提供了灵活性和成本效益。其多层次的缓存机制和可配置的 ANN 索引技术（如 IVF-PQ 和 IVF-HNSW-SQ）使得用户可以根据其特定的性能需求进行优化。自动索引和便捷的性能分析工具进一步简化了开发和运维过程。

与其他向量数据库相比，LanceDB 的嵌入式/无服务器特性、对多模态数据的原生支持以及基于磁盘的索引策略使其在特定的应用场景中具有显著的优势，例如本地 AI 开发、数据隐私敏感的应用以及需要处理大规模多模态数据的场景。虽然 LanceDB 在某些方面可能不如一些成熟的云原生或分布式向量数据库功能全面，但其简洁性、易用性和对 AI/ML 工作负载的优化使其成为构建下一代 AI 应用的有力选择。随着 AI 技术的不断发展，LanceDB 有望在向量数据库领域发挥越来越重要的作用。

Turbopuffer 向量数据库技术架构深度解析：SPFresh 索引、存储结构与 AI IDE 优化策略

Fri, 11 Apr 2025 22:13:13 +0800

本文由 Deep Research with Gemini 2.5 Pro 撰写

1. 引言

1.1. Turbopuffer 概述

Turbopuffer 是一款商业化、专有的无服务器向量数据库即服务（DBaaS）[1]。其核心设计理念是“基于对象存储从第一性原理构建”[3]，旨在提供一种兼具成本效益和高性能的搜索解决方案。Turbopuffer 不仅支持向量相似性搜索，还集成了基于 BM25 算法的全文本搜索能力，能够处理混合查询需求 [5]。该服务定位于处理大规模工作负载，据称在生产环境中已承载超过 1500 亿份文档，并达到 6000+ QPS（每秒查询次数）的全局查询速率 [3]。

1.2. 核心价值主张

Turbopuffer 的主要吸引力体现在以下几个方面：

成本效益: Turbopuffer 声称其成本相比基于内存的向量数据库解决方案低 10 倍 [3]。这主要归功于其以低成本的对象存储作为主要存储介质，并结合智能缓存策略 [5]。其定价模型基于实际使用量，涵盖存储、写入和查询操作 [3]。
可扩展性: 得益于其对象存储基础和计算节点的水平扩展能力，Turbopuffer 能够扩展至处理数十亿级别的向量/文档和数百万级别的命名空间（namespaces）或租户 [5]。
性能特征: Turbopuffer 的查询性能呈现双重特性：对于缓存中的“热”数据，查询延迟极低（1M 文档 p50 约 16ms）；而对于需要直接从对象存储读取的“冷”数据，查询延迟则较高（1M 文档 p50/p90 约 400-500ms）[3]。该系统专注于高效的第一阶段检索（first-stage retrieval），旨在快速从数百万文档中筛选出数十或数百个候选结果 [5]。
持久性与可靠性: Turbopuffer 利用对象存储固有的持久性，并通过预写日志（Write-Ahead Log, WAL）机制来保证数据写入的持久性 [6]。据称其服务上线以来保持了 99.99% 的正常运行时间 [9]。

1.3. 报告目标与结构

本报告旨在对 Turbopuffer 的技术架构进行深入剖析，重点关注其独特的 SPFresh 索引机制、基于对象存储的数据存储结构、无服务器设计模式、查询处理流程，以及针对 AI IDE（如 Cursor）等客户的特定优化策略。报告将明确区分基于公开文档的信息和基于技术原理的合理推断，为技术决策者评估该数据库提供参考。后续章节将依次探讨其核心架构、SPFresh 索引细节、数据存储与管理、查询处理流程、针对 AI IDE 的优化、性能分析，并最后进行总结。

2. 核心架构：对象存储基础与无服务器设计

2.1. “对象存储优先”原则

Turbopuffer 架构的基石是其“对象存储优先”（Object-Storage-First）的设计原则。这意味着对象存储（如 AWS S3 [11]，尽管具体服务商未明确）被用作系统主要的、权威的数据存储层，而非仅仅作为冷数据的归档层 [9]。这与依赖复制磁盘（replicated disks）的传统数据库架构形成了鲜明对比 [9]。在 Turbopuffer 中，每个命名空间（namespace）直接映射到对象存储上的一个特定前缀（prefix）[9]。

这一设计选择深刻影响了系统的其他方面。对象存储具有高延迟、高吞吐、存储成本相对低廉但单次写入/更新操作相对昂贵的特点 [9]。Turbopuffer 的整体设计必须围绕这些特性进行权衡。接受冷操作的较高基础延迟和潜在的一致性挑战，换取的是对象存储带来的巨大扩展潜力、高持久性（继承自 S3 等服务）以及相比内存或复制 SSD 显著降低的存储成本。这种架构上的取舍表明，Turbopuffer 有意利用对象存储的经济性和规模优势，并以此为基础构建其索引、缓存和一致性机制 [3]。

2.2. 无服务器计算模型

Turbopuffer 的计算层由无状态的查询节点组成，这些节点是运行着被称为 ./tpuf 的 Rust 二进制文件的实例 [10]。节点的无状态特性使得水平扩展和故障恢复变得简单：节点可以失败并被替换，数据则安全地存储在对象存储中，不会丢失 [6]。

为了弥补对象存储的高延迟，Turbopuffer 在计算节点上部署了缓存层，使用 NVMe SSD 甚至内存（RAM）来缓存频繁访问的数据和索引部分 [5]。这是实现热查询低延迟的关键 [3]。查询请求会被路由，优先导向缓存了相关数据的节点以利用缓存局部性（cache locality），但理论上任何节点都可以服务任何命名空间的查询 [9]。

虽然 Turbopuffer 的计算模型不完全等同于传统的函数即服务（FaaS，如 AWS Lambda）（其本地部署版本使用 Kubernetes [14]），但它体现了无服务器的核心原则：存储与计算分离、自动伸缩（通过无状态节点和对象存储实现）、以及基于使用量的定价模型 [3]。Turbopuffer 的“无服务器”特性更多地体现在其架构的解耦（存储 vs 计算）和运营模式（弹性、托管基础设施、按用量付费）上，而非严格遵循 FaaS 执行模型。节点级的缓存层为追求性能引入了一定的状态性，形成了一种混合模型。这种务实的“无服务器”方法，旨在利用对象存储基础和托管计算带来的运营优势 [3]。

2.3. 多租户实现

Turbopuffer 默认采用多租户架构，即多个客户或命名空间可能共享同一组计算资源（一个 ./tpuf 实例处理多个租户的请求）[10]。这是其实现成本效益的关键因素之一 [10]。同时，它也为企业客户提供了按需隔离的选项 [10]。

命名空间的隔离主要通过对象存储上的不同前缀来实现 [9]，并在计算和缓存层进行逻辑上的分离。Turbopuffer 架构在设计上就考虑了大规模多租户场景，生产环境中已观察到超过 4000 万个命名空间 [3]。这与其重要客户 Cursor 的用例高度契合，Cursor 需要管理数百万个代码库（每个代码库对应一个命名空间）[9]。

Turbopuffer 的架构天然支持大规模多租户，使其非常适合 B2B SaaS 应用或像 Cursor 这样的平台，这些场景下每个终端用户或实体都需要独立的数据空间。相比于需要为每个租户预分配资源的系统，基于对象存储的基础设施极大地简化了租户数量的扩展。多租户并非事后添加的功能，而是由其架构支撑的核心设计原则 [2]。

3. SPFresh 索引：深入 Turbopuffer 的向量索引技术

3.1. Turbopuffer 官方确认的细节

根据 Turbopuffer 的官方文档和声明，关于其向量索引，已知以下信息：

Turbopuffer 使用基于 SPFresh 的近似最近邻（ANN）索引 [10]。
该索引被描述为一种“基于质心”（centroid-based）的 ANN 索引 [10]。
SPFresh 索引针对对象存储进行了优化，旨在最小化网络往返次数（roundtrips）和写放大（write-amplification），这与基于图的索引（如 HNSW、DiskANN）在对象存储环境下的表现形成对比 [10]。
向量数据是增量式索引的（incrementally indexed）[17]。
该索引经过自动调优，目标是在 recall@10（前 10 个结果的召回率）达到 90-100%，并且系统会自动监控生产环境中的召回率 [3]。

3.2. 基于 SPFresh 学术论文的分析 ([20])

一篇题为 “SPFresh: Incremental In-Place Update for Billion-Scale Vector Search” 的学术论文（作者 Xu 等人，发表于 SOSP ‘23 [20]）为理解 SPFresh 提供了重要线索。该研究源自微软亚洲研究院和中国科学技术大学，主要关注基于磁盘（特别是 SSD）的向量索引。

该论文旨在解决的核心问题是：在处理频繁更新时，如何避免其他系统（如 DiskANN）中常见的、成本高昂且影响服务稳定性的全局索引重建（global index rebuilds）[20]。

论文提出的 SPFresh 索引结构 具有以下特点：

基于聚类: 数据被划分成多个簇（clusters），也称为 postings（倒排列表），并存储在磁盘上 [21]。
质心索引: 每个分区（posting）都有一个质心（centroid）。系统在内存中维护一个关于这些质心的索引（论文中使用了基于图的 SPTAG 索引），用于在查询时快速定位相关的分区 [21]。

为了支持高效的增量更新，论文提出了 LIRE（Lightweight Incremental RE-balancing）协议：

目的: 在基于磁盘的索引结构内原地（in-place）处理增量更新（插入、删除），同时维护索引质量并局部适应数据分布的变化 [20]。
操作: 包括插入（追加到最近的分区）、删除（使用墓碑标记）、合并（将过小的邻近分区合并）、分裂（将过大的分区分裂）和重分配（重新分配分区边界附近的向量以维持最近邻分配属性）[21]。
核心思想: 通过仅重新分配分区边界附近的向量来最小化更新成本 [20]。

论文声称 SPFresh 相比全局重建方法具有显著优势：在更新期间查询延迟低且稳定，查询准确率高，同时资源消耗（内存、CPU）显著降低 [20]。

3.3. 推断 Turbopuffer 的 SPFresh 实现

结合 Turbopuffer 的官方信息和 SPFresh 论文，可以推断 Turbopuffer 的 SPFresh 实现方式：

基本原理采纳: Turbopuffer 很可能采纳了 SPFresh 论文的核心原则，即基于质心的分区和避免全局重建的增量更新。但其具体实现必须针对其“对象存储优先”和类 LSM 的架构进行深度改造。
质心索引: Turbopuffer 确认存在一个“用于定位最近质心的快速索引”[10]。这个索引很可能存储在内存或 NVMe 缓存中，以实现快速的初始查找，这与论文的方法类似 [21]。对象存储上的 centroids.bin 文件 [10] 可能是这个质心索引的持久化形式。
分区/簇: 向量数据被组织成与质心关联的簇。对象存储上的 clusters-*.bin 文件 [10] 很可能代表了这些存储在对象存储上的数据分区。关键优化在于，在通过质心索引确定候选簇后，能够高效地从对象存储中获取这些簇的数据 [10]。
增量更新与 LIRE 的适配: Turbopuffer 明确提到“向量是增量式索引的”[17]。虽然 SPFresh 论文描述的是在磁盘上进行原地更新 [21]，但对于对象存储来说，原地更新通常效率低下。Turbopuffer 的增量更新更可能依赖其 WAL 和类 LSM 结构 [9]。新的向量或更新首先写入 WAL，然后通过后台进程异步地合并（compact）到对象存储上的主索引结构（clusters-*.bin 文件）中。LIRE 协议中的概念（如分裂过大簇、合并过小簇、逻辑上重分配向量）可能指导这个后台合并过程，但实际操作将涉及在对象存储上重写文件或段（segments），而不是直接修改。这种方式既避免了全局重建，又适应了对象存储的不可变性（immutability）模式。这种推断的依据在于：Turbopuffer 的 WAL 机制 [10]、异步索引 [10]、明确提到的 LSM 结构 [9]、对象存储的特性（适合追加/重写）、SPFresh 论文避免全局重建的目标 [20] 以及 Turbopuffer 增量索引的声明 [17]。这些线索共同指向一个通过 WAL 和后台压缩实现的增量更新模型，该模型借鉴了 SPFresh 的分区和再平衡思想，并针对对象存储进行了适配。
对象存储优化: Turbopuffer 声称 SPFresh 能够最小化对象存储的往返次数 [10]，这一点至关重要。基于质心的方法通过以下方式实现：首先，通过缓存的质心索引查找，快速识别出少量候选簇；然后，仅从对象存储中获取这些候选簇的数据，通常采用并行或批量读取的方式 [10]。这与基于图的方法（如 HNSW）形成对比，后者在图未完全缓存的情况下，图遍历可能导致多次依赖性的、高延迟的读取操作。

3.4. 推断的特性与权衡

索引构建时间: 初始构建可能涉及聚类和质心计算。增量更新通过后台异步处理 [10]，意味着前台写入延迟主要不由复杂的索引更新决定（LIRE 协议也旨在降低更新开销 [21]）。主要成本在于后台的压缩/索引过程。
内存占用: 主要的内存/缓存需求来自质心索引以及可能的元数据/过滤索引 [10]。大量的向量数据存储在对象存储上。相比于相同数据集规模下完全基于内存的图索引（如 HNSW），其内存占用应显著降低。正如一些讨论指出的，对于基于索引的方法，内存需求主要在于索引本身，而非整个数据集 [22]。
查询速度 vs. 准确率: Turbopuffer 的目标是高召回率（90-100% @10）[8]。基于质心的方法通常需要在准确率与查询速度之间进行权衡（相比于穷举搜索或稠密的图方法）。Turbopuffer 的调优可能涉及在搜索期间探测（probe）多少个簇。其设定的高召回率目标表明其实现相当鲁棒，可能探测了比追求极致速度所需更多的簇。

3.5. 与其他 ANN 技术的比较

HNSW: 基于图的方法，在内存中具有出色的召回率和速度。但由于其图遍历过程中的随机访问模式，难以高效地适应磁盘或对象存储。更新操作也可能很复杂。不太符合 Turbopuffer 的设计目标。
IVF (Inverted File Index): 同样是基于质心（量化）的方法。与 SPFresh 的分区概念有相似之处。SPFresh（根据论文）增加了更复杂的增量更新机制（LIRE）。Turbopuffer 的 SPFresh 实现可能借鉴了 IVF 的原理，但针对对象存储和其特定的更新机制进行了定制。
PQ (Product Quantization): 通常与 IVF 或其他方法结合使用，用于压缩向量，减少存储/内存占用并加速距离计算。Turbopuffer 可能在其簇内部使用了 PQ 或类似的量化技术，但这并未得到明确证实。（注意：API 文档提到了 f16 向量支持，这本身就是一种量化形式 [23]）。
DiskANN / Vamana: 针对 SSD 优化的基于图的索引。需要精心设计数据布局以最小化磁盘寻道。更新通常依赖全局重建或复杂的机制（SPFresh 论文对比了其与 DiskANN 的重建策略 [20]）。相比基于质心的方法，不太适合高延迟的对象存储环境。

Turbopuffer 选择 SPFresh（或其变种）是经过深思熟虑的决策，旨在采用一种更适合对象存储高延迟、高吞吐特性的索引结构，并且相比基于图的方法，能在这种环境下实现更易于管理的增量更新。官方文档明确对比了 SPFresh 与 HNSW/DiskANN 在对象存储上的适用性 [10]，强调了质心方法在减少往返次数和写放大方面的优势。SPFresh 论文直接与 DiskANN 的更新策略进行比较 [20]。这表明 Turbopuffer 选择基于质心的架构模式是为了契合其系统的约束和目标（成本、规模、在对象存储上可控的更新）。

表 1: ANN 算法在对象存储环境下的比较

算法	核心思想	对象存储适用性 (延迟/往返)	更新处理	内存/缓存需求	关键权衡
HNSW	多层可导航小世界图	较差 (随机访问多)	复杂，可能影响性能	高 (图结构需缓存)	内存中性能优异，磁盘/对象存储适应性差
IVF	基于质心分区，查询时探测邻近分区	较好 (查询集中于少数分区)	相对简单，但大规模更新可能需重建	中 (质心索引+部分分区)	速度/准确率权衡，量化可能损失精度
DiskANN	针对 SSD 优化的图索引	中等 (优化磁盘访问)	复杂，常依赖全局重建或特定更新机制 ([20])	中/高 (图结构需部分缓存)	SSD 上性能好，对象存储适应性不如 IVF/SPFresh，更新成本高
SPFresh (Turbopuffer推断)	基于质心分区，LIRE 原理指导的增量更新 ([10])	好 (最小化往返 [10])	增量式，通过 WAL+后台合并实现 ([9])	低/中 (质心索引+热点分区)	接受冷查询高延迟，换取成本、规模和对象存储上的可管理更新

4. 数据存储与管理：持久化、一致性与索引协同

4.1. 对象存储上的数据布局

如前所述，Turbopuffer 使用对象存储作为其持久化层，数据按命名空间组织在不同的前缀下，通常格式为 /{org_id}/{namespace}/ [10]。在一个命名空间前缀内部，关键的目录结构包括：

wal/ 目录：包含一系列按顺序编号的预写日志（WAL）文件（例如 001, 002），记录了最近的写入操作 [10]。
index/ 目录：存储持久化的索引结构 [10]，其中可能包含：
- centroids.bin：很可能存储 SPFresh 索引的质心信息 [10]。
- clusters-*.bin：大概率存储按簇分区后的实际向量数据 [10]。
- Namespace Config：存储该命名空间的模式（schema）和配置信息 [10]。
- 其他文件：可能还包括元数据过滤索引或全文本搜索索引的相关文件（基于 [10] 的暗示）。

关于数据格式，虽然没有明确文档，但可以推断：向量数据可能以二进制格式（如 API 中提到的 f32/f16 [23]）存储，并可能进行了压缩。元数据为了查询效率，可能会采用列式存储或类似 Parquet/Arrow 的格式嵌入在索引文件中（此为推测）。

4.2. 写入路径与一致性

Turbopuffer 的写入流程核心是 WAL 机制：

写入操作: 每次写入请求（upsert）成功后，会在对应命名空间的 wal/ 目录下追加一个新的 WAL 文件 [10]。
持久性保证: 一旦写入操作得到成功确认，就意味着数据已持久化到对象存储中 [10]。
写入批处理: 在一个短时间窗口内（提及了 100ms）对同一命名空间的并发写入会被合并成一个 WAL 条目 [10]。每个命名空间当前的写入速率限制约为每秒 1 个批次（batch），未来计划提升至 4 个/秒 [8]。
写入延迟: 由于需要等待数据写入对象存储并确认，写入延迟相对较高（提及了 500KB 数据 p50 延迟为 285ms [10]）。这是为保证持久性和实现高写入吞吐量所做的权衡 [9]。
一致性模型:
- 默认：强一致性 (Strong Consistency)：查询操作能够立即看到已成功完成的写入结果 [10]。这是通过在查询时检查 WAL 来实现的 [10]。
- 可选：最终一致性 (Eventual Consistency)：用户可以请求放宽一致性保证，通过可能跳过 WAL 检查或一致性往返，来换取更低的查询延迟（目标是亚 10ms）[10]。

WAL 在 Turbopuffer 架构中扮演着至关重要的角色，它是系统在基于对象存储的后端上提供强一致性的关键。WAL 充当了新写入数据与后台异步构建的主索引之间的桥梁，确保读取操作能够通过查询日志来反映最新的持久化状态。即使对于缓存数据，一致性检查（涉及对象存储往返）也默认执行，以保证强一致性 [10]。

4.3. 索引过程与存储协同

异步索引: 写入 WAL 的数据由后台的“索引器”（indexer）组件处理（见 [10] 架构图），并被整合进存储在 index/ 目录下的主 SPFresh 索引、过滤索引和 FTS 索引中 [10]。
对象存储上的类 LSM 结构: Turbopuffer 明确提及其使用了为对象存储设计的原生 LSM（Log-Structured Merge-Tree）结构 [9]。这种结构非常适合对象存储的特性（适合追加写入，通过后台合并进行优化）。
- 工作方式推断: WAL 文件可以类比为 LSM 树的内存表（memtable）或 L0 层。后台进程负责“压缩”（compact）WAL 文件中的数据，并将其与对象存储上已有的、可能已排序或结构化的索引文件（如 clusters-*.bin、过滤索引）进行合并，生成新的索引段（segments），类似于 LSM 树的压缩过程 [9]。旧的、不再需要的索引段最终会被垃圾回收。
- 协同作用: 这种存储布局（WAL + 索引文件）直接支持了类 LSM 的工作流程。SPFresh 索引（基于质心）的分区特性可能与 LSM 的段/文件结构良好地映射。查询时，系统需要同时查询稳定的索引文件和近期的 WAL 条目，以提供强一致性的结果 [10]。

Turbopuffer 很可能在对象存储之上实现了一种受 LSM 启发的数据管理策略。WAL 捕获最近的变更，后台进程持续将这些变更合并到优化的、分区的索引结构中（如 SPFresh 簇）。这种方法适应了对象存储的追加友好特性，同时能够高效地查询大规模数据集。这种推断基于对 LSM 的明确提及 [9]、WAL 机制 [10]、异步索引 [10] 以及对象存储特性（追加/重写效率）的综合分析。

4.4. 元数据处理与模式

模式定义: 每个命名空间都有一个模式（schema），定义了属性（attributes）的类型以及索引行为（如是否可过滤 filterable，是否启用全文本搜索 full_text_search）[24]。模式可以自动推断，也可以显式定义 [24]。支持多种数据类型，包括字符串、整数、浮点数、布尔值、UUID、日期时间以及它们的数组形式 [24]。
过滤索引: Turbopuffer 会为标记为 filterable 的属性构建精确索引（exact indexes）[10]。这些索引对于执行混合搜索（结合向量相似度和元数据过滤）至关重要。启用过滤会触发后台的索引构建过程 [24]。
全文本搜索 (FTS) 索引: 系统使用倒排索引（inverted index）和 BM25 算法来实现全文本搜索 [7]。提供了多种配置选项，如语言、词干提取（stemming）、停用词移除、大小写敏感性和分词器（tokenizer）[24]。FTS 索引同样是异步构建的 [24]。
集成: 查询处理很可能需要协调跨向量索引（SPFresh）、过滤索引和 FTS 索引的查找。高效的过滤能力非常重要 [2]，Turbopuffer 声称即使对于复杂的基于过滤的查询也能提供高召回率 [6]。有提及将属性索引与向量索引相结合 [19]。

5. 查询处理流程：从请求到结果

5.1. 请求处理

API 交互: 客户端通过 REST API 与 Turbopuffer 交互 [24]。官方提供了 Python、TypeScript 和 Java 的客户端库 [28]。
认证: 所有 API 调用都需要使用 Bearer Token 进行身份验证 [27]。
请求格式: API 使用 JSON 编码进行请求和响应，并支持 gzip 压缩以减少网络传输量 [27]。
负载均衡与路由: 外部请求首先到达负载均衡器（见 [10] 架构图），然后被分发到可用的 ./tpuf 查询节点。对于热查询，路由会考虑缓存局部性，尽量将请求发送到已缓存相关数据的节点 [10]。

5.2. 查询执行步骤（推断流程）

一个典型的向量搜索请求在 Turbopuffer 内部的处理流程可能如下：

解析与规划: 查询节点接收到请求（包含查询向量、过滤器、FTS 查询词、topK 值等参数 [25]）。节点解析请求内容，并制定一个执行计划。这可能涉及决定使用哪些索引（向量、过滤、FTS）以及它们的执行顺序。
一致性检查 / WAL 查找: 对于默认的强一致性模型，节点必须查询对象存储上的 WAL，以查找可能影响查询结果的、尚未合并到主索引中的近期写入或删除操作 [10]。这一步虽然增加了延迟，但保证了结果的实时性。从 WAL 中检索的数据可能需要进行穷举搜索或过滤 [10]。
索引查找 (SPFresh & 元数据/FTS):
- 质心搜索: 利用缓存或内存中的质心索引（源自 centroids.bin），找到与查询向量最接近的 k 个质心及其对应的分区 [10]。
- 过滤索引查找: 同时或串行地，根据查询中的过滤器在元数据过滤索引中进行查找 [10]。
- FTS 索引查找: 如果是 FTS 查询，则在 BM25 倒排索引中进行查找 [7]。
- 结果合并: 执行计划可能需要合并来自不同索引的结果（例如，查找特定分区内且满足元数据过滤条件的向量）。
分区/簇检索: 根据上一步确定的候选质心，节点从缓存（NVMe/RAM，热查询）或直接从对象存储（冷查询）中获取相应的向量数据分区（clusters-*.bin 文件）[10]。这一步经过优化，旨在最小化对象存储的访问次数 [10]。
分区内搜索与评分: 加载分区数据后，节点在满足过滤条件的候选分区内，计算查询向量与目标向量之间的精确距离（如余弦距离、欧氏距离 [23]）。如果是 FTS 查询，则计算 BM25 分数。
结果聚合: 汇总来自 WAL 查找和索引分区查找的结果。根据距离或分数对候选结果进行排序，并选出最终的 topK 个结果 [25]。
属性/向量获取: 根据请求，为最终的 topK 结果获取所需的元数据属性，并可选择性地包含完整的向量数据 [25]。

5.3. 缓存机制及其影响

缓存层级: Turbopuffer 的缓存体系结构大致为：对象存储（基础层）-> NVMe SSD 缓存 -> 内存缓存（RAM，由 [10] 中提及 SSD/RAM 推断）。
缓存内容: 主要缓存命名空间的文档数据和索引部分 [10]。优先缓存的可能包括质心索引、频繁访问的数据分区以及元数据过滤索引。
缓存预热: Turbopuffer 明确建议对于延迟敏感的应用，可以通过发送“影子查询”（dark queries）或预请求（pre-flight queries）来预热缓存，例如在用户打开搜索界面时触发 [10]。
缓存驱逐: 具体策略未详细说明，但可能采用类似 LRU（Least Recently Used）的策略，考虑到提及了约 3 天的非活动缓存时间限制 [3] 以及标准的缓存实践 [32]。
缓存局部性路由: 将对同一命名空间的后续请求导向已缓存该命名空间数据的节点 [10]。

缓存并非 Turbopuffer 架构中的简单优化，而是弥合对象存储延迟与用户对搜索响应速度期望之间鸿沟的基础性需求。Turbopuffer 的性能表现高度依赖于工作负载是否能表现出足够的缓存局部性。冷热查询之间巨大的延迟差异（~400-500ms vs ~16ms [3]）凸显了缓存的关键作用。官方关于预热 [31] 和缓存路由 [10] 的建议也印证了其重要性。Cursor 的成功案例 [9] 也隐含地依赖于活跃代码库能保持在缓存中的“热”状态。若无有效的缓存机制，系统性能将被对象存储延迟主导，使其不适用于许多交互式应用场景。

5.4. 响应生成

最后，查询节点将最终结果（包括 ID、分数、元数据，以及可选的向量 [25]）格式化为 JSON 响应 [27]，并返回给客户端。

6. 针对 AI IDE 工作负载的优化：以 Cursor 为例

6.1. Cursor 用例分析

Cursor 是一款 AI 代码编辑器 [9]，它使用 Turbopuffer 对用户的代码库进行索引 [34]。其规模巨大，涉及数十亿向量和数百万个代码库（即命名空间）[9]。

Turbopuffer 为 Cursor 解决了关键痛点：替代了原先成本高昂的基于内存的向量数据库，实现了约 10 倍的成本节约，并简化了运营（无需手动“装箱”租户以控制成本）[9]。这使得 Cursor 能够为每个用户索引更多的代码 [9]。Turbopuffer 支持的功能可能包括语义代码搜索、为代码生成/补全提供上下文检索等 [34]。

在安全方面，Cursor 采取了客户端措施，例如不将明文代码存储在 Turbopuffer，并对每个代码库应用独特的向量变换，以增加从向量反推代码的难度 [9]。

6.2. AI IDE 的需求分析

AI IDE（集成开发环境）对底层向量数据库通常有以下特定需求：

低延迟: 对于代码补全 [34]、实时语义搜索等交互式功能至关重要。Turbopuffer 的热查询性能（p50 约 16ms [10]）是满足此需求的关键。
高并发: 大量开发者可能同时使用 IDE，频繁触发上下文查找。系统需要高效处理每个命名空间以及全局的并发查询。
细粒度搜索: 通常需要根据当前代码上下文，从特定的代码库（命名空间）中精确检索 topK（有时 K 很小）的结果。
频繁的小规模更新: 代码变更频繁，需要高效的增量索引能力以保持搜索上下文的实时性（尽管 Cursor 可能采用批处理更新策略）。
大规模多租户: 每个用户的代码库需要隔离存储和查询。

6.3. Turbopuffer 针对 IDE 的潜在优化（推断与明确信息）

Turbopuffer 可能通过以下方式满足或优化以支持 AI IDE 的需求：

缓存策略:
- 积极缓存: 优先将活跃的代码库（命名空间）保持在 NVMe/RAM 缓存中 [10]。
- 预热/预取: 在开发者打开项目或文件时触发缓存加载（对应“影子查询”建议 [31]）。
- 缓存驱逐策略: 可能采用倾向于保留最近或最常访问代码库的 LRU/LFU 策略 [32]。
SPFresh 索引调优:
- 召回率/精度权衡: 虽然默认召回率很高 [17]，但 IDE 场景可能更关注低 K 值下的高精度。这或许可以通过调整搜索时探测的簇数量来实现。召回率本身是可配置的（或即将可配置）[3]。
- 分区策略: 官方建议使用更小的命名空间以获得更好的性能 [31]，这与 IDE 中代码库作为自然分区单元的情况相符。
API 设计:
- 当前的 API 看起来是通用型的 [7]，未观察到专门针对代码语义的特定端点。优化更多体现在架构层面。
- 其灵活性允许像 Cursor 这样的客户在其上构建自己的逻辑（如特定的嵌入策略、安全转换 [9]）。
多租户效率: 计算/缓存层在不同命名空间之间的快速上下文切换能力至关重要。Turbopuffer 的架构似乎很适合这种场景 [9]。
资源管理: 在共享计算节点上的租户之间实现公平调度和资源分配，对于保证一致的性能体验是必要的（推断）。按命名空间控制成本有助于客户管理开销 [9]。
数据处理: 支持高效的元数据过滤 [6]，可用于在代码库内按文件类型、修改日期等进行筛选。建议使用更小的 ID 类型（如 UUID/U64）以提升性能 [31]。

Turbopuffer 之所以能成功支持 Cursor，很可能更多地源于其核心架构优势（大规模、成本效益高的多租户能力，以及通过缓存实现的良好热查询延迟），而非依赖于 Turbopuffer 内部高度专门化的代码感知功能。其架构提供了合适的基础，而像 Cursor 这样的客户则在此基础上构建了针对特定场景的逻辑。Cursor 的案例 [9] 强调了对象存储/缓存模型带来的成本和规模优势。IDE 的性能需求与 Turbopuffer 的热延迟特性相符 [3]。通用的性能调优建议（如预热、小命名空间 [31]）也直接适用于 IDE 场景。缺乏代码专用 API 文档 [7] 也佐证了其核心产品是通用型的，但其架构特性使其天然适合 IDE 这种（多租户、访问局部化）的应用模式。

7. 性能分析：延迟、吞吐量、可扩展性与成本效益

7.1. 延迟概况

冷查询延迟: 范围大约在 400-700ms。具体报告值为：1M 文档下 p50=402ms, p90=524ms, p99=677ms [3]；p90 约 500ms [5]；约 500ms [10]；约 512ms [9]。这明确归因于需要从对象存储读取数据 [5]。
热查询延迟: 范围大约在 16-37ms。具体报告值为：1M 文档下 p50=16ms, p90=21ms, p99=33ms [3]；p50=16ms [10]；p90=37ms [9]。这归功于数据命中 NVMe/RAM 缓存 [5]。如果采用最终一致性，延迟有望降至 10ms 以下 [10]。
写入延迟: 相对较高，引用值为 500KB 数据 p50 延迟 285ms [10]。这是为持久性和高吞吐量付出的代价 [9]。同时受限于批次提交速率（每个命名空间每秒 1-4 个批次）[8]。

7.2. 吞吐量

查询吞吐量:
- 单命名空间: 当前限制为 100+ QPS，目标是很快达到 10,000 QPS [3]。每个命名空间的最大并发查询数为 16 [8]。
- 全局: 生产环境中观察到 6K+ QPS，宣称限制为“无限” [3]。
写入吞吐量:
- 单命名空间: 限制为 10,000 文档/秒 [3]。受限于最大批次大小（256MB [3]）和批次提交速率（1-4次/秒 [8]）。
- 全局: 生产环境中观察到 1M 文档/秒，宣称限制为“无限” [3]。

7.3. 可扩展性限制

单命名空间文档数: 当前限制 1 亿，生产中见过 2 亿，目标是 10 亿以上 [3]。
总文档数: 生产中见过 1500 亿以上，宣称限制为“无限” [3]。
命名空间数量: 生产中见过 4000 万以上，宣称限制为“无限” [3]。
最大向量维度: 10,752 [3]。

7.4. 召回率性能

目标: recall@10 达到 90-100% [3]。
调优: 系统自动进行调优和监控 [17]。未来将支持用户配置 [3]。

7.5. 成本效益

定价模型: 基于使用量，包括存储（宣称 <= $0.33/GB）、写入（<= $2.00/GB）和查询（<= $0.05/TB 扫描 - 注意：查询单位在源文件中可能不准确，通常按查询次数或扫描的向量数计费）[3]。存在最低月费（例如，启动计划为 $64/月）[3]。
成本对比: 声称比基于内存的方案便宜 10 倍 [3]，并且比依赖复制磁盘的系统更经济，尤其对于访问不频繁的数据或多租户工作负载 [5]。提供写入批处理折扣和将属性标记为不可过滤的折扣 [31]。

Turbopuffer 的性能特征是其成本优化策略的直接结果。它通过牺牲普适性的低延迟（尤其是冷读和写入）来换取显著的成本节约和基于对象存储的可扩展性。其设定的高召回率目标表明，尽管架构存在权衡，但并未过度牺牲搜索质量。性能数据 [3] 清晰地展示了延迟的权衡，成本优势 [3] 是其核心卖点，而高召回率目标 [8] 则体现了对搜索效果的追求。这些要素相互关联：架构支撑了成本结构，成本结构决定了性能特征，同时系统仍致力于提供高实用性（召回率）。

表 2: Turbopuffer 公布的性能指标与限制

指标类别	具体指标	报告值/限制 (当前)	报告值/限制 (未来/目标)	来源
延迟	冷查询 p50 (1M docs)	402ms	-	3
	冷查询 p90 (1M docs)	524ms (~500ms)	-	3
	冷查询 p99 (1M docs)	677ms	-	3
	热查询 p50 (1M docs)	16ms	<10ms (最终一致性)	3
	热查询 p90 (1M docs)	21ms (37ms in 9)	-	3
	热查询 p99 (1M docs)	33ms	-	3
	写入 p50 (500KB)	285ms	-	10
吞吐量	查询/命名空间 (QPS)	100+	10,000	3
	查询/全局 (QPS)	6K+ (生产中) / 无限	-	3
	写入/命名空间 (docs/s)	10,000	-	3
	写入/全局 (docs/s)	1M (生产中) / 无限	-	3
扩展性	文档数/命名空间	100M (生产中见过 200M)	1B+	3
	总文档数	150B+ (生产中) / 无限	-	3
	命名空间数量	40M+ (生产中) / 无限	-	3
	最大维度	10,752	-	3
召回率	Recall@10	90-100%	可配置	3
成本	存储 (/GB)	<= $0.33	-	3
	写入 (/GB)	<= $2.00	-	3
	查询 (/TB scanned - 单位存疑)	<= $0.05	-	3

8. 结论

8.1. 核心发现总结

Turbopuffer 代表了一种创新的向量搜索数据库设计范式，其核心在于原生构建于对象存储之上，通过智能缓存实现性能优化，并采用基于 SPFresh 的索引机制。其关键架构组件包括：以对象存储为基础的数据层（包含 WAL 和类 LSM 的索引结构）、带有 NVMe/RAM 缓存的无状态计算节点、以及为对象存储环境适配并支持增量更新的 SPFresh 质心索引。

8.2. 优势分析

成本效益: 对于大规模数据集，尤其是在访问模式呈现稀疏性的场景下，具有显著的成本优势。
可扩展性: 继承自对象存储的巨大扩展潜力，无论是在数据总量还是多租户数量方面。
热查询性能: 对于缓存命中的数据，查询速度非常快，适合具有访问局部性的交互式应用。
增量更新: 基于 SPFresh 的方法避免了破坏性的全局索引重建，使得更新期间的性能更稳定。
持久性与可靠性: 充分利用了对象存储服务本身提供的高持久性和可用性。

8.3. 劣势与权衡

冷查询延迟: 相比内存数据库显著偏高，需要依赖缓存预热等策略来应对延迟敏感场景。
写入延迟: 由于对象存储提交的开销，写入延迟高于传统数据库。
架构复杂性: 理解和管理缓存行为以及冷热查询的性能差异，相比简单的内存系统增加了复杂性。
专有性: 作为商业闭源产品 [1]，存在供应商锁定的风险，且内部工作机制透明度低于开源方案 [8]。

8.4. 对 AI IDE 的适用性评估

Turbopuffer 是 AI IDE 后端（如 Cursor）的一个有力竞争者。其优势主要体现在：能够以极高的成本效益支持海量代码库（命名空间）的扩展需求；良好的热查询延迟适合代码上下文检索等交互场景。然而，其适用性的前提是 IDE 的访问模式能够使关键数据保持在缓存中，并且能够接受其写入延迟的权衡，同时需要有效管理冷启动问题（例如通过预热）。

8.5. 结语

Turbopuffer 是数据库架构适应并利用云对象存储的经济性和规模优势的一个重要范例。它展示了在特定约束条件下（接受延迟换成本），可以构建出满足特定大规模搜索和数据密集型应用需求的系统。其未来的发展可能聚焦于进一步优化延迟（冷热查询）、扩展功能集（如聚合查询 [8]）等方面。Turbopuffer 的实践为探索“对象存储优先”架构在搜索领域的潜力提供了宝贵的参考。

参考文献

turbopuffer, accessed April 11, 2025, https://dbdb.io/db/turbopuffer
How to Choose a Vector Database - Timescale, accessed April 11, 2025, https://www.timescale.com/blog/how-to-choose-a-vector-database
turbopuffer, accessed April 11, 2025, https://turbopuffer.com/
Turbo Puffer - Get Access - Soverin, accessed April 11, 2025, https://soverin.ai/product/turbo-puffer/
Introduction - turbopuffer, accessed April 11, 2025, https://turbopuffer.com/docs
turbopuffer | Technology Radar | Thoughtworks United States, accessed April 11, 2025, https://www.thoughtworks.com/en-us/radar/platforms/turbopuffer
Full-Text Search Guide - turbopuffer, accessed April 11, 2025, https://turbopuffer.com/docs/fts
Limits - turbopuffer, accessed April 11, 2025, https://turbopuffer.com/docs/limits
fast search on object storage - turbopuffer, accessed April 11, 2025, https://turbopuffer.com/blog/turbopuffer
Architecture - turbopuffer, accessed April 11, 2025, https://turbopuffer.com/architecture
In S3 simplicity is table stakes - All Things Distributed, accessed April 11, 2025, https://www.allthingsdistributed.com/2025/03/in-s3-simplicity-is-table-stakes.html
S3 Express Is All You Need - Hacker News, accessed April 11, 2025, https://news.ycombinator.com/item?id=38449827
turbopuffer | Technology Radar - Thoughtworks, accessed April 11, 2025, https://www.thoughtworks.com/radar/platforms/turbopuffer
On-Prem Deployment Runlist - turbopuffer, accessed April 11, 2025, https://turbopuffer.com/docs/onprem-deployment
SQUASH: Serverless and Distributed Quantization-based Attributed Vector Similarity Search - arXiv, accessed April 11, 2025, https://arxiv.org/html/2502.01528v1
Serverless vector DB recommendation for multiple small indexes/namespaces : r/vectordatabase - Reddit, accessed April 11, 2025, https://www.reddit.com/r/vectordatabase/comments/1ae5wgx/serverless_vector_db_recommendation_for_multiple/
Vector Search Guide - turbopuffer, accessed April 11, 2025, https://turbopuffer.com/docs/vector
very cool stuff! I just read the SPFresh paper a few days ago and was wondering - Hacker News, accessed April 11, 2025, https://news.ycombinator.com/item?id=41917310
Native filtering for high-recall vector search - turbopuffer, accessed April 11, 2025, https://turbopuffer.com/blog/native-filtering
[2410.14452] SPFresh: Incremental In-Place Update for Billion-Scale Vector Search - arXiv, accessed April 11, 2025, https://arxiv.org/abs/2410.14452
arxiv.org, accessed April 11, 2025, https://arxiv.org/pdf/2410.14452
Turbopuffer: Fast search on object storage - Hacker News, accessed April 11, 2025, https://news.ycombinator.com/item?id=40916786
Upsert & Delete Documents - turbopuffer, accessed April 11, 2025, https://turbopuffer.com/docs/upsert
Schema - turbopuffer, accessed April 11, 2025, https://turbopuffer.com/docs/schema
Reference: Turbopuffer Vector Store | Vector Databases | RAG | Mastra Docs, accessed April 11, 2025, https://mastra.ai/docs/reference/rag/turbopuffer
Create index - turbopuffer, accessed April 11, 2025, https://turbopuffer.com/docs/create-index
API Overview - turbopuffer, accessed April 11, 2025, https://turbopuffer.com/docs/auth
Quickstart Guide - turbopuffer, accessed April 11, 2025, https://turbopuffer.com/docs/quickstart
turbopuffer - GitHub, accessed April 11, 2025, https://github.com/turbopuffer
Java client for accessing the turbopuffer API. - GitHub, accessed April 11, 2025, https://github.com/turbopuffer/turbopuffer-java
Optimizing Performance, accessed April 11, 2025, https://turbopuffer.com/docs/performance
Mastering Caching: Strategies, Patterns & Pitfalls - bool.dev, accessed April 11, 2025, https://bool.dev/blog/detail/mastering-caching-strategies-patterns-pitfalls
Cache me if you can: A Look at Common Caching Strategies, and how CQRS can Replace the Need in the First Place | by Mario Bittencourt | SSENSE-TECH | Medium, accessed April 11, 2025, https://medium.com/ssense-tech/cache-me-if-you-can-a-look-at-common-caching-strategies-and-how-cqrs-can-replace-the-need-in-the-65ec2b76e9e
Embedding Models for Different LLM Versions (GPT, Claude, etc.) in Cursor - Discussion, accessed April 11, 2025, https://forum.cursor.com/t/embedding-models-for-different-llm-versions-gpt-claude-etc-in-cursor/20677

书摘｜山

Thu, 21 Nov 2024 13:40:00 +0800

最近读了刘慈欣的短篇小说集《山》。除了《流浪地球》是读过的，其他短篇小说竟然还有不少没读过呢。写的都很有趣，发人深省。

“船长，还有一件事我没告诉你，在珠峰遇难的那 4 名大学登山队员中，有我的恋人。当我割断登山索时，脑子里闪过的念头是这样的：我不能死，还有别的山呢。”

在登上海山顶峰的时候，冯帆感觉此生足矣，那时他可以从容地去死。但现在，他突然变成了世界上最怕死的人。他攀登过岩石的世界屋脊，这次又登上了海水构成的世界最高峰，下次会登什么样的山呢？这无论如何得活下去才能知道。几年前在珠峰雪暴中的感觉又回来了，那感觉曾使他割断了连接同伴和恋人的登山索，将他们送进了死亡世界，现在他知道自己做对了。如果现在真有什么可背叛的东西来拯救自己的生命，他会背叛的。

“你在平原上走着走着，突然迎面遇到一堵墙，这墙向上无限高，向下无限深，向左无限远，向右无限远，这墙是什么？”

是死亡

人类的逃亡分为五步：第一步，用地球发动机使地球停止转动，使发动机喷口固定在地球运行的反方向；第二步，全功率开动地球发动机，使地球加速到逃逸速度，飞出太阳系；第三步：在外太空继续加速，飞向比邻星；第四步：在中途使地球重新自转，调转发动机方向，开始减速；第五步：地球泊入比邻星轨道，成为这颗恒星的卫星。人们把这五步分别称为刹车时代，逃逸时代，流浪时代Ⅰ（加速），流浪时代Ⅱ（减速），新太阳时代。整个移民过程将延续两千五百年时间，一百代人。

在这个时代，人们在看四个世纪以前的电影和小说时都莫名其妙，他们不明白，前太阳时代的人怎么会在不关生死的事情上倾注那么多的感情。当看到男女主人公为爱情而痛苦或哭泣时，他们的惊奇是难以言表的。在这个时代，死亡的威胁和逃生的欲望压倒了一切，除了当前太阳的状态和地球的位置，没有什么能真正引起他们的注意并打动他们了。这种注意力高度集中的关注，渐渐从本质上改变了人类的心理状态和精神生活，对于爱情这类东西，他们只是用余光瞥一下而已，就象赌徒在盯着轮盘的间隙抓住几秒钟喝口水一样。

“你听着亲爱的，我们必须报有希望，这并不是因为希望真的存在，而是因为我们要做高贵的人。在前太阳时代，做一个高贵的人必须拥有金钱、权力或才能，而在今天只要拥有希望，希望是这个时代的黄金和宝石，不管活多长，我们都要拥有它！明天把这话告诉孩子。”

我们理解所有的人，因为已经进行了四十代人、还要延续一百代人的艰难奋斗中，永远保持理智确实是一个奢求。

“你在平原上走着走着，突然迎面遇到一堵墙，这墙向上无限高，向下无限深，向左无限远，向右无限远，这墙是什么？”

辛妮看到纸片上只有几个字，那是她的老师、教练、虽不是父亲但她愿意成为其女儿的人，用尽生命的最后力气写下的，笔迹力透纸背：光荣与梦想

“其实我早就预料到这一点，和平视窗计划只是个美丽的童话，竞赛代替不了战争，就像葡萄酒代替不了鲜血。”

当生命意识到宇宙奥秘的存在时，距它最终解开这个奥秘只有一步之遥了。

如果说那个原始人对宇宙的几分钟凝视是看到了一颗宝石，其后你们所谓的整个人类文明，不过是弯腰去拾它罢了。

LightRAG: 改进版的 GraphRAG，便宜多了！

Fri, 25 Oct 2024 16:08:22 +0800

微软的 GraphRAG 使 RAG（Retrieval-Augmented Generation）与知识图谱结合的概念备受关注。然而，GraphRAG 在构建知识图谱时需要频繁调用大型语言模型（LLM），导致成本高且速度慢。相比之下，LightRAG（arxiv, repo）利用 LLM 将文档转化为知识图谱，并结合向量数据库进行检索和回答问题。LightRAG 显著减少了 LLM 的调用次数，从而降低了知识图谱构建的成本。

以下是 LightRAG 的工作流程和原理的详细介绍：

文档处理与知识图谱构建

文档分块：
- LightRAG 首先将输入文档分块处理，每块大小不超过 1200 token，并设置 100 token 的重叠，以确保块大小适中且相邻块间有适当重叠，便于后续处理。
实体提取：
- 使用 LLM 从文档块中提取实体（entity）。LLM 会根据预定义的提示模板（prompt template）生成实体提取的指令。
- 提取的实体信息包括实体名称、类型和描述等，这些信息将被用于构建知识图谱的节点。
关系提取：
- 在提取实体的同时，LightRAG 还会提取实体之间的关系（relationship）。这些关系信息包括源实体、目标实体、关系类型和描述等，用于构建知识图谱的边。
知识图谱构建：
- 提取的实体和关系信息会以图的形式存储，实体作为节点（vertex），关系作为边（edge）。LightRAG 使用 NetworkX 作为知识图谱的存储后端，在生产级别的系统中，你可能需要一个图数据库。
向量数据库存储：
- 提取的实体和关系信息会被转换为向量，并存储在向量数据库中，以便后续进行相似度检索。LightRAG 使用 nano-vectordb，这是一个基于 numpy 实现的简易向量数据库。在生产级别的系统中，建议使用真正的向量数据库，例如 MyScaleDB。

基于知识图谱和向量数据库的检索与回答

查询处理：
- 当用户提出查询时，LightRAG 首先使用 LLM 提取查询中的关键词（keywords）。这些关键词用于后续的检索过程。关键词分为
  - 低级关键词：关注具体实体、细节或具体术语
  - 高级关键词：关注总体概念或主题
本地查询（Local Query）：
- 在本地查询模式下，LightRAG 使用提取的低级关键词在存储实体的向量数据库中搜索。然后，根据搜索到的实体，在知识图谱中寻找相关的关系（边），将这些实体和关系构建查询的上下文（context），并使用 LLM 生成回答。
全局查询（Global Query）：
- 在全局查询模式下，LightRAG 使用提取的高级关键词在向量数据库中查找相关的关系。然后，根据这些关系和它们对应的实体构建查询的上下文，并使用 LLM 生成回答。
混合查询（Hybrid Query）：
- 在混合查询模式下，LightRAG 同时使用本地查询和全局查询的结果，构建一个更全面的上下文，并使用 LLM 生成回答。

实验结果

LightRAG 使用 LLM 生成问题并评估问答结果。在四个数据集（Agriculture/CS/Legal/Mix）和四个维度（Comprehensiveness/Diversity/Empowerment/Overall）上，LightRAG 都战胜了四个对手：NaiveRAG (朴素的 RAG)、RQ-RAG、HyDE 和 GraphRAG。

LightRAG 与 GraphRAG 在消耗的 token 数量和 API 调用次数方面进行了比较。从下表可以看出，LightRAG 消耗的 LLM token 明显更少：

{width=40%}

总结

LightRAG 通过 LLM 将文档处理成知识图谱和向量数据库，并基于这些数据结构进行高效的检索和回答。它支持多种查询模式，包括本地查询、全局查询、混合查询，以满足不同场景下的需求。通过这种方式，LightRAG 能够有效地利用 LLM、知识图谱和向量数据库的优势，提供高质量的检索和回答服务。

书摘｜创业维艰：如何完成比难更难的事

Mon, 14 Oct 2024 13:17:31 +0800

《创业维艰》的作者是本·霍洛维茨 (Ben Horowitz)，也是著名创投公司 a16z 的创始人之一。这本书介绍了他创立并卖掉 Opsware 公司的过程中的许多经历和经验。里面确实有很多宝贵的经验之谈，很可惜我在墨奇创业失败之后才读到这本书。

所有事情一起抓，就会在最重要的事情上遭遇失败。

过去的我一直以为，自己既能干好事业，又能兼顾所有的兴趣爱好，同时还能维护好家庭。而且，我总把自己摆在首位。当你成为某个家庭或某个团体的一分子时，这种思维方式会令你陷入麻烦。在我心里，我坚信自己是个好人，毫不自私，但我的所作所为却暴露出我并非这样的好人。我绝不能像这样继续幼稚下去，我必须分清主次轻重，成熟起来。我必须先考虑自己最关心的人，然后再考虑自己。

大多数合作关系要么过于紧张而令人难以忍受，要么紧张不足而缺乏效率。人们要么相互挑战，导致彼此交恶，要么陶醉于彼此的奉承之词而无所受益。就我和马克而言，即使是 18 年后的今天，他依然对我的想法吹毛求疵，让我感到烦恼，我对他亦是如此。但事实证明，这种方式对企业的发展有益无害。

公司的规模和资金的估值要求我们必须和时间赛跑，赶在资金同样雄厚的竞争对手之前尽快壮大并抢占市场。安迪曾对我说：“本，好好想想，如果资本是免费的，你会如何运作。”

在此期间，我学到了最重要的集资规则：寻找一个统一市场，其中只要有一个投资者点头，即可功成，其他 30 位投资者即便全都摇头拒绝也无关紧要。我们最终以惊人的、高达 7 亿美元的投资前预估价值为 C 轮投资找到了投资者，由此筹集到了 1.2 亿美元的资金。

2000 年第三季度，我们只完成了 3700 万美元的销售额，与我们所预测的 1 亿美元的销售额相差甚远。

比尔说：“你不能去纽约参加发布会真是太遗憾了，不过你必须派马克去。”我问：“为什么？”他说：“你必须守着公司，确保所有人都知道自己的处境。你一分钟都不能拖，大家有权知道自己现在是继续跟着你在 EDS 公司干，还是要另谋出路。”噢，真该死！比尔说得对。我派马克去了纽约，然后准备告诉大家他们现在的处境。事实证明，比尔的那条小小的建议为我们日后重建公司打下了必要的基础。如果我们不能公平、公正地对待那些即将离开公司的人，那些留下的人就永远不会再信任我了。

尽管过程非常痛苦，但我知道，我们必须进入更广阔的市场，因为只有充分了解市场，我们才能推出市场需要的产品。但可笑的是，实现这一目标的唯一办法却是尽力去销售错误的产品。我们会遭遇失败，只有失败才会让我们学得更快，为了生存，我们不惜一切代价。

我从未制订那个应急计划。通过看似不可能的 C 轮投资和首次公开募股过程，我学到了一条重要的经验：创业公司的 CEO 不应该计算成功的概率。创建公司时，你必须坚信，任何问题都有一个解决办法。而你的任务就是找出解决办法，无论这一概率是十分之九，还是千分之一，你的任务始终不变。

生活就是苦苦挣扎。——卡尔·马克思挣扎是你想知道自己为什么要创办公司时的状态。挣扎是人们问你为什么不退出，你却不知怎么回答时的状态。挣扎是你的员工认为你在撒谎，而你却认为他们也许说得对的状态。

从史蒂夫·乔布斯到马克·扎克伯格，所有出色的企业家都会经历挣扎，而且是苦苦挣扎，因此，人人都会挣扎。不过，这并不意味着你一定能挣扎成功。你也许会挺不过去，这就是挣扎的恼人之处。挣扎是成就伟大的竞技场。

经营 Opsware 公司时，我们在竞争中失去了无数笔交易，我召集了一次员工会议，告诉全体员工，我们目前被打击得狼狈不堪，如果不迅速止血，我们就死定了。那时，没有一个人退缩。团队精诚团结，成功研发了一款产品，拯救了濒临绝境的公司。

请记住，这是区分男人和男孩的方法。如果你想成就一番事业，这就是挑战。如果你不想，那你根本不应该开办公司。

作为 CEO，我个人最大的一项进步就是我停止使用过于积极正面的管理方式。

我以为，如果将这些问题转移给员工，事情就会变得更糟。因此，我认为我应该尽力表现出一种积极乐观的姿态，让大家毫无负担、一心一意地去赢取胜利。而实际上，我错了。

在我看来，我一直通过积极强调正面影响、忽略负面影响的方式来激励所有人。但我的团队很清楚，现实要比这更加微妙。他们已经看到，这个世界并不像我所描述的那么美好，却依然不得不听我在每次公司大会上说些形势一片大好之类的无聊空话。

没有了信任，沟通就会中断。具体来讲就是：在人类的所有交往之中，沟通量与信任程度成反比。

如果员工完全信任 CEO，沟通的效率就会大大提高。实话实说就是建立这种信任的关键。一名 CEO 在一段时间内拥有这种被信任的能力，往往是一家管理良好的公司和一家管理混乱的公司之间最大的差别。

参与解决问题的人越多越好为了创建一个出类拔萃的技术公司，你必须雇用大量的精英人才。而不让这些精英人才参与解决公司最大、最棘手的问题完全是一种浪费。

健康的企业文化会鼓励员工公开坏消息。只有允许自由并公开讨论问题，公司才能迅速解决问题。企图掩盖问题只会令所有员工感到灰心。

我们要谨防那些阻止信息在公司内自由流动的所谓管理箴言。例如，“如果拿不出解决方案，就不要把问题报告给我。”如果有一个重大问题，员工解决不了怎么办？

第一步：保持头脑清晰如果公司没能实现自己的财政计划，形势严重到了必须辞退那些不惜重金聘请而来的员工的地步，这对 CEO 而言，无疑是巨大的压力和沉重的负担。

第二步：当机立断一旦决定裁员，那么必须尽快执行。如果走漏消息，就会横生枝节，麻烦不断。员工会质询管理者，公司是否要裁员。如果管理者不知情，员工就会认为他愚蠢。如果知情，他要么不得不向员工撒谎，令消息进一步走漏，要么保持沉默，令群情更加激愤。

第三步：对裁员的原因要有清晰的认识进入裁员程序后，董事会成员有时会说一些有积极意义的话来安慰你。他们也许会说，“这是个大好机会，可以简化业务程序”。这也许是实话，但不要让这一点扰乱心神，从而将错误的信息传递给公司。公司之所以裁员是因为其未能实现自己的计划。如果公司裁员的唯一原因是个人绩效问题，那就要另当别论了。裁员的真正原因是公司业绩欠佳。

承认失败似乎没什么了不起，但请相信我，这实际上非常了不起“。

第四步：对管理人员进行培训整个裁员过程中最重要的一步就是培训管理团队。如果将未经培训的管理人员置于裁员这一极为尴尬的情境之中，他们大部分都会无法应对。

对管理人员的培训需遵循一条黄金法则：自己的员工要自己亲自辞退，不能将这项工作推卸给人力资源部门或某个更严厉的同事，不能像电影《在云端》中那样雇用一家外包公司来完成。

为什么不能找些强势的管理者出面，替你完成这一棘手任务？因为人们不会记得自己在公司效力的每一天，但他们一定会记得你将他们开掉的那一天。他们会记得那一天的每一个细节，这些细节关系重大。公司的声誉和管理人员的声誉都取决于你的表现：昂首挺胸，勇敢面对那些曾经信任你并为你辛勤工作的员工们。员工们会想：既然你雇用了我，我勤勤恳恳地为你埋头苦干，我希望你能有勇气亲自辞退我。

第五步：向公司全体人员发表讲话在执行裁员决定之前，CEO 必须向公司全体人员发表讲话。

务必牢记财捷集团前 CEO 比尔·坎贝尔告诉我的一句话：话是说给那些留下来的人听的。这些人会非常关心你对待他们同事的方式。你裁掉的员工之中，有很多人都和留下来的人关系亲密，因此，你一定要给予他们足够的尊重。

第六步：一定要让大家看见你，你一定要在公司出现在向公司全体人员发表讲话、告诉大家许多人将被辞退之后，你也许会不愿意在公司里四处走动，和大家交谈，而更愿意去酒吧喝几杯龙舌兰酒。千万别这样。一定要在公司出现，一定要让大家看见你，一定要积极参与公司事务。

换句话说，认为解雇高管是因为他们表现糟糕的这种观点是错误的。事实是，解雇高管是因为公司的面试或整合系统出了问题。因此，正确解雇高管的第一步是，搞清楚自己为什么给公司招错了人。

高管的解雇补偿金应比普通员工的解雇补偿金数额更高。因为与一名普通员工相比，一名高管重新找到一份工作的时间要多 10 倍。

保护被解雇高管的声誉。高管的失职很可能是一个团队集体造成的结果，你最好以这种方式对之加以解释。

当公司开始在重大竞争中屡屡失手时，真相往往会成为众矢之的。管理者和员工会绞尽脑汁地编造一些颇具创意的说辞，帮助自己逃避显而易见的真相。

如果这个说法听起来太老套，而且你也很想知道为什么你的员工都在对你撒谎，那么准确答案就是：他们不是在骗你，而是在骗自己。如果你听信他们，你就欺骗了自己。

所有这些方法都进一步强化了我的一个看法：我们面临的不是市场问题。客户们一直都在购买，只是没有购买我们的产品而已，但对我们来说，更换产品显然不是时候。于是，我对每一位前来献计献策的人说出了同样的一番话：“没有任何良策可以改变这种局面，我们只能用笨办法。”这话他们虽然不爱听，却令事情变得十分清晰：我们必须研发一款更好的产品，除此之外，别无出路。没有窗户、没有地洞、没有安全出口、没有后门。我们必须穿过前门，和堵住我们出路的敌人较量一番。

所有公司在发展过程中总会遇到必须为公司生存而战的时刻。如果你发现自己在本该英勇奋战的时候却逃之夭夭，你就要问问自己：“如果我们的公司无法取胜，那我们还有存在的必要吗？”

与其将所有的心思用来哀叹自己的痛苦，还不如努力去寻找一种看似不可能的出路，令自己摆脱目前的困境。不要花时间去懊悔过去，要将所有的时间花在自己可以做的事情上，因为说到底，没人会在意，只要好好经营公司就行了。

我之前的上司吉姆·巴克斯代尔很喜欢说这样一句话：“我们要依次管理好人、产品和利润。”话虽简单，但意义深远。三者之中，管理好人是最难的，管不好人，其他两项就无从谈起。

当组织规模扩大时，重要工作可能被人忽视，最勤奋的工人可能被最出色的政客所遮蔽，各类繁文缛节可能会扼杀创造力，让一切变得毫无乐趣。

我突然想明白了——虽然我告诉了团队应该做什么，却一直没明确地告诉他们为什么要那么做。

令人惊讶的是，他们都把在 Go Corporation 公司工作视作自己生命当中最珍贵的工作经历之一。尽管他们的职业生涯就此止步，没有赚到钱，成为新闻头版报道的失败案例，但他们依然认为在 GO Corporation 公司的工作经历是最棒的。Go Corporation 公司为他们提供了良好的工作环境。

后来，我读了安迪·格鲁夫的管理学经典之作《格鲁夫给经理人的第一课》(High Output Management)[插图]。读后，我的事业观发生了改变。格鲁夫在书中写道：“大多数管理者似乎都觉得，培训员工这件事应该让其他人来做，但我却坚信，管理者应该亲自去做这件事。”

如果你此前所做的培训令这些员工的业绩提升 1%，那么你用于培训的 12 个小时就相当于为公司带来了 200 个小时的工作量。

辞退人时，你怎么确定这名员工很清楚自己的工作期望？最佳答案是，对员工进行岗位培训时，管理者应该清晰明确地提出工作期望。不对人员进行培训，绩效管理就毫无基础，进而变得松散无序、前后矛盾。

讽刺的是，实施培训项目的最大障碍是：有些人认为，这会花费太多时间。要记住，在提升公司生产力方面，其他任何投入都比不上培训。因此，因为太忙而没时间开展培训就相当于因为太饿而吃不下任何东西。

于是，我试着静下心来做这件事。令我高兴的是，人们至今还在读我下的定义。这令我看到了培训的重要性。

好的产品经理，差的产品经理

好的产品经理极其了解市场、产品、生产线和竞争情况，凭借自己丰富的经验和充分的自信开展管理工作。好的产品经理是产品的 CEO。他们勇于承担全部责任，以产品的成功与否来衡量自己。他们必须确保产品、时间，以及所需要的一切正确无误。好的产品经理对周围形势十分清楚（公司、营收资金、竞争等），为了获得成功，他们主动制订并执行计划（从不推辞）。差的产品经理总有一大堆借口，如资金不足、项目经理无能、微软研发这项产品的工程师比我们多 10 倍、我劳累过度了、没人给我指示等。我们的 CEO 从不会找这些借口，产品经理也不应该拿这些当借口。为了在适当的时机推出适当的产品，不同部门之间必须通力合作，好的产品经理不会把所有时间都浪费在这些部门之间。他们不会占用产品团队的所有时间，不会以管理项目的方式管理各项职能，不会为项目跑腿打杂。他们不是产品团队的一员，而是团队的管理者。技术团队不会将好的产品经理当成一种营销资源。好的产品经理和技术经理在营销中其实互为伯仲。好的产品经理对目标有清晰的定义，即“目标是什么”（与“怎么实现目标”相对），并能有效实施这一目标。差的产品经理只要想出“怎么实现目标”，就会扬扬自得、不可一世。好的产品经理会采用书面形式和口头形式与技术人员进行清晰的交流，他们不会随意下达命令，而是在不经意间搜集信息。好的产品经理会制作附加材料、常见问题解答、业务简报以及白皮书，供销售人员、营销人员和主管参考或使用。差的产品经理会抱怨自己整天都在为销售人员解答问题，忙得不可开交。好的产品经理会预测出产品的严重缺陷，提出真正的解决方案，而差的产品经理整天都在解决问题。好的产品经理会将一些重要问题以书面形式记录下来（竞争中的良策、艰难的架构选择、艰难的产品决策、攻占或放弃市场）。差的产品经理只以口头形式表达自己的意见，抱怨“当权者”不允许他这样做。一旦失败，他们往往会说自己早就料到会失败。好的产品经理让团队将重点放在收益和客户身上，而差的产品经理则让团队关注竞争对手的产品有多少新功能。好的产品经理定义的好产品是只要付出巨大努力就能实现的，而差的产品经理定义的好产品要么无法实现，要么就是让技术人员随心所欲地创建产品（即把最困难的问题留给他们去解决）。在产品规划期，好的产品经理会考虑向市场推出超值产品，在产品进入市场期间，他们会考虑实现市场占有率和收益目标。差的产品经理总是搞不清楚交付价值、竞争性功能匹配、价格以及普遍性之间的差异。好的产品经理会拆解问题，而差的产品经理会把所有的问题合并成一个问题。好的产品经理将自己想要讲述的故事交给媒体去写，差的产品经理向媒体传达信息时总想面面俱到，保证其在法律意义上的绝对精确。好的产品经理向媒体提问，差的产品经理回答媒体的所有问题。好的产品经理认为媒体和分析机构的人都很聪明，差的产品经理认为记者和分析员都是傻子，根本不懂他们独特技术的细微差别。好的产品经理偏重清晰明了，差的产品经理对显而易见的事情从不解释。好的产品经理对自己的职责和成功有明确的认识，差的产品经理总想让别人告诉他该做什么。好的产品经理每周会按时提交自己的工作报告，因为他们遵守纪律。差的产品经理往往会忘记按时提交工作报告，因为他们不重视纪律。

想加入你公司的正确理由应该是：渴望变得更有创造力。

当一名出色的部门经理和当一名出色的总经理（尤其是一名出色的 CEO）之间最大的差别是，作为总经理，你必须招聘并管理那些远远比你更胜任他们工作的人。

正如著名励志大师托尼·罗宾斯所说：“如果不知道自己想要什么，你实现愿望的可能性就微乎其微。”

你必须意识到自己非常无知，不要妄想仅靠面试应聘者就能学会如何招聘。虽然面试过程对你可能很有启发意义，但将其当作唯一的知识来源却很危险。

金无足赤，人无完人。因此，招聘时要看重应聘者的长处，而不是其身上没有弱点。每个人都有弱点，只不过有些人身上的弱点比较明显而已。因为其人没有弱点而对其加以聘用意味着你将愉快感作为优先考虑的因素。

想知道自己需要什么样的人才，最好的方法是在该职位上亲自体验一番。不是名义上的，而是真正履行职责。在我的职业生涯中，我曾担任过人力资源主管、首席财务官以及销售主管。

你想促成的事有些也许可以量化，有些则不可以。你不能只汇报量化目标，而忽视质化目标，因为质化目标才是最重要的目标。仅仅按照数字进行管理就像利用数字进行绘画，从严格意义上说，这完全是业余爱好者的做法。

由于将公司当作黑匣子一样进行管理，惠普公司的很多部门以降低竞争力为代价，使当前利益实现了最大化。公司对实现了短期目标的管理者予以奖励，这种方式对公司极其有害。如果将白盒子考虑在内，效果就会好得多。白盒子不仅包含数字，而且还能告诉你这些数字是怎么来的。这种方式会惩罚那些以牺牲未来利益换取短期利益的管理者，奖励那些给未来投资的管理者，即使这些投资短期内难以测量。

像技术债务一样，当你牺牲掉代价高昂的长期利益、做出权宜的短期管理决定之时，就会发生管理债务。

以下是创业公司中比较流行的三种管理债务形式：1.一山藏二虎。2.因某一员工得到了另一工作机会而对其补偿过度。3.缺乏绩效管理机制或员工反馈机制。

最终，你只能做出艰难的决定，留下一个人，一次性还清债务，否则你的技术部门就会永远陷入泥潭。

现在，技术部的每一个人都知道，涨工资的最好办法是从其他公司拿到工作邀请，然后以辞职进行威胁。要付清这样一笔管理债务，需要很长一段时间。

如果没有反馈，你的公司在任何一个方面都不可能做到最好。如果只下达指令、从不进行修正，这些指令就会显得模糊不清。人们意识不到自己的缺点时，很少会对其加以改正。不对员工的行为做出反馈的最终代价是：公司业绩的系统性一塌糊涂。

我所认识的每一位真正出色的、富有经验的 CEO 都有一个重要特征：在回答有关部门组织的问题时，他们都倾向于选择艰难复杂的回答。如果面临两种选择：其一，给每个人发同样的奖金，不犯众怒；其二，极力褒奖业绩突出的员工，惹恼其他员工。他们会选择后者。如果面临另外两个选择：其一，撤掉今天一个很受欢迎的项目，因为该项目不在长期计划之内；其二，出于维护人心的目的或为了显得前后一致而保留该项目。他们会选择前者。为什么呢？因为他们曾经为管理债务付出过代价，所以不愿再重蹈覆辙。

一个管理出色的质量控制部门无法生产一款高质量的产品，却能告诉你产品研发团队何时生产了一款质量低劣的产品。类似情况是，一个高质量的人力资源机构无法给你创造一个管理完善、企业文化成熟的公司，却可以告诉你，你和你的管理者何时没有尽到职责。

没有人喜欢打小报告的人。如果管理团队对其缺乏完全信任，人力资源部门不可能有效地开展工作。管理者必须相信，设立人力资源部的目的是帮助自己改进工作，而不是对自己进行监管。优秀的人力资源主管会真心实意地为管理者提供帮助，不会因为发现了问题而大肆表功。他们会直接找管理者解决问题，提高管理质量。如无必要，他们一般不会将问题上报给 CEO。如果人力资源主管将自己的知识深藏不露，玩弄权术，或搞阴谋诡计，那他就毫无用处。

几乎所有的办公室政治都是由公司老板开的头。你可能会觉得委屈：“我讨厌政治，不爱耍手腕，但我的员工们却恰恰相反。这绝不是我的原因。”你错了。公司内部的办公室政治并不在于你本人是否爱耍政治手段。事实上，那些最缺乏政治头脑的老板往往会带出一支最善于钩心斗角的队伍。这些对政治不感兴趣的老板们常常在不经意间助长了公司内部激烈的政治斗争。

我所说的政治，是指员工在职场进阶的过程中，依靠手段，而非业绩和贡献为自己谋取空间。

如果那些资深员工不时地找你加薪，示意你他们的所得远远低于应得，甚至暗示你他们手头还有别家公司伸出的颇具诱惑力的橄榄枝，你会怎么办？如果对方的要求合情合理，你也许会酌情考虑，然后给他加薪。这种做法听起来无可厚非，但其实你已经就此为办公室政治的蔓延埋下了祸根。

安迪·格鲁夫认为，那种以公司的发展为依托，实现个人发展的野心才是恰如其分的，个人的成就仅仅是以公司成就为前提而形成的伴生物。相反，只关注个人成功而将公司利益置之不顾的人拥有的只是不当的野心。

在前文提到的事例中，如果公司的 CEO 实行了严格的绩效管理和薪酬核定，那他就可以拒绝对方的加薪请求，告诉他必须得按照统一的标准来执行。

假如你的手下都是些野心勃勃的家伙，他们就会不时地想扩展自己的势力范围。比如，前面提到的觊觎常务总经理位子的财务总监。有时，市场部的总监想涉足销售部的业务，或者技术部的负责人还想兼管一下产品部，这样的情况不一而足。如果有下属向你提出了类似的要求，切记要措辞严谨，因为你说的每一个字都可能成为权力角逐中的砝码。

以“团队”为出发点来考虑问题的人说话时很少使用“我”，哪怕是在谈论其个人成就。在面试中，他们总会把功劳推到从前的合作伙伴身上。相对于工作待遇和职业发展，他们更关心这家公司的实力。如被问及为何离开上一家公司，他们往往会把责任归咎于自身，检讨自己判断力不佳而做出的错误决策。

满足员工的需要。你打算把毕生心血投入自己的公司，但有些员工可能还会另谋高就。

这都是“彼得定律”在施威。劳伦斯·J·彼得博士和雷蒙德·赫尔在 1969 年出版的同名书籍中首次使用了这个术语，意即在一个集团中，员工只要表现出众，就能获得提拔，直至被提拔到一个他不能胜任的岗位（即他们的不称职级别），自此无法再获得提升。

“坏榜样法则”。依据该法则，一个团队内部无论哪个层面出现了滥竽充数的人，他们都会像蛀虫一样影响其他成员，最终使得能力出众的人也渐趋平庸。

安德森认为，员工为公司效力总是希望获得相应的回报，譬如薪水、奖金、股份、权利以及头衔等。这其中，头衔的成本最低，因此可以尽可能定高些，CEO 之下是首席主管，然后是高级副总裁。只要他们喜欢，那就给他们相应的职位。另外，在与其他公司比拼实力争取新人时，头衔可以让你更具吸引力。

扎克伯格在管理 Facebook 公司时，有意识地让各职务级别低于行业内的一般标准。其他公司的高级副总裁在这里只能被降格称作主任或者经理。这是为什么呢？第一，在每个新人入职时，扎克伯格都要给他们重新定头衔，以避免他们的头衔和职位高过那些表现优异的老员工。这样做有助于鼓舞士气，维系公正。第二，这可以使 Facebook 的各位经理了解并认可这套职务评定体系，为他们本人的升职和加薪发挥更好的作用。

对人才的依赖要适可而止，不要重蹈我的覆辙。

然而，有些头脑灵活的员工不但帮不了公司，反而会给公司制造更多的麻烦。出现问题时，他们不是立即找出其中亟待修复的漏洞加以解决，而是拼命挑毛病，以凸显自己的高明。

一家公司在成长壮大的过程中，最大的挑战就是沟通。让成百上千人同时为一个目标而众志成城绝不是件容易的事。如果你的主管中有一个浑蛋，这个目标就完全不可能实现。有些人与别人交流时总是气势汹汹，致使别人在他面前根本就没法开口。

要想取得好的结果，你在招聘细则中就不要使用抽象空洞的字眼，比如“成熟的管理”，或是“真正的公司”。这种缺乏力量感的措辞不会起任何作用。恰当的表述可以是，“在某一领域能提供知识引领和经验支持”。

究竟是从外围选拔人才还是从内部提拔人才？在做这个决定时，你可以先明确一点：对这个岗位来说，你认为究竟是外围经验重要还是内部经验重要。举例来说，技术部经理更需要了解编码基础和技术团队的综合情况，而不是如何管理该部门。因此，作为 CEO 的你最好从公司内部选拔人才，而不必考虑从外围引进。

但是在涉及销售主管这样的岗位时，就得反过来了。要想使产品走向全世界，销售主管就必须了解目标客户的想法和需求，知道他们的文化取向，清楚销售人员聘用的标准和尺度，从而实现销售业绩的最大化。只了解本公司的产品和文化是远远不够的。这就是为什么你从内部选拔的技术部主管可以干得很出色，而同样是内部选拔的销售部主管，工作起来却力不从心。

为确保高标准，你可以在选拔人员时面试那些已经在某个领域小有名气的应聘者，听听他们是怎么要求自己的，然后加以借鉴。一旦定下一个可能实现的高标准，就要要求主管们按这个标准做，而不必操心他们如何达到这个标准。至于如何创出一个响当当的品牌，如何拿下一单举足轻重的业务，如何实现一个不可思议的销售目标——这都不是你的工作，而是他们的，你出钱聘请他们就是为了让他们帮助你完成这些任务。

要想让这种交流形式真正发挥作用，一定要明白一点：这是以员工为中心的会谈，不是以上司为中心。它不拘于形式，目的是解决迫在眉睫的问题、交流精彩绝伦的想法，或者倾诉郁结已久的焦虑。这些话题往往不适合通过工作报告、电子邮件或是其他非私人化的途径开展。

以下是我认为在“一对一”会谈中有助于引导对方表达想法的一些话题：·如果我们还有进步的空间，那你认为该从哪方面着手？·你所在部门的最大问题是什么？为什么？·在这里的工作中，哪一点令你感到不愉快？·公司里谁最优秀？你最佩服谁？·假如你是我，你会做何调整？·你这个产品的哪个方面不尽如人意？·你觉得我们错失的最大机遇是什么？·哪些是我们该做而没有做的？·你对这里的工作满意吗？

对新创业的科技公司而言，当务之急是研发产品。这个产品的功能至少要比现有市场上的同类产品强 10 倍。如果只是略胜一筹，那就不足以吸引大批的用户立即使用你的产品。

如果你既没有过硬的产品，又没能抢占市场，你就不应将其完全归咎于企业文化。全世界有着一流企业文化但最终以失败而告终的公司有很多，这说明仅凭文化成就不了企业。

他倡导大家节俭，推行节俭的企业文化。他的做法相当简单：公司的所有桌子都要利用从“家得宝”购进的廉价门板，自己用钉子钉上桌腿。这些用门板改装的桌子既不符合人体工程学，又配不上亚马逊公司上千亿美元市值的身价。当时，一个新人觉得这种做法不可思议，问老板为什么非得在这样一个用零部件凑成的桌子上干活时，杰夫的回答斩钉截铁：“我们尽一切可能节约开支，就是为了以最低的价格为客户提供最好的产品。”如果你不喜欢在门板上工作，那在亚马逊肯定待不长。

为什么带小狗上班或在上班时做瑜伽不算是文化？

许多董事会成员对于规模控制一无所知，所以很容易被有经验却没有技巧的人糊弄。如果你曾就职于一家大型公司，你一定见识过那些经验丰富却不善于运用经验的人。

组织设计的头条法则是：理想的组织设计根本不存在。无论你怎么做，总是会在实现某些部门之间最优化沟通的同时，牺牲另外一些部门的利益。

当你身处这样的境地时，务必要明白一点：几乎所有的公司都会经历生死攸关的时刻。鉴于这一现象的普遍性，我的搭档马克·安德森和斯科特·韦斯甚至用首字母缩写“WFIO”来表示它。“WFIO”代表“we’re fucked,it’s over”，意思是“我们要完蛋了”。根据他们的结论，一个公司会经历 2～5 次这样的时刻（虽然我敢肯定地说，我在 Opsware 公司至少经历了 10 次）。

盯着路，别看墙。人们学开车时，要掌握的第一要领是：当你以 200 英里的时速拐弯时，千万别看墙，一定要盯着路。如果你看着墙，你就会直接撞到墙上去；盯着路，你就能安然无恙。管理公司就像开车。千头万绪的事情都有可能出状况并变成大麻烦，如果你的注意力全部放在这些事情上，那你就会像一辆失控的汽车，最后很有可能连公司也被你拖垮。所以，你需要紧盯的，是你的目标，而不是那些你想要躲避的东西。

我曾见过不少人在重压之下借酒消愁，或是干脆停止努力。他们有充分的理由来为自己的放弃做辩解，可这些人中，没有一个人能成为杰出的 CEO。

杰出的领导者会直面痛苦。无眠的长夜、涔涔的冷汗，还有难以名状的“煎熬”，他们都曾经历。每当我遇到成功的 CEO，总会向他们讨教成功经验。那些泛泛之辈的答案可能是非凡的战略举措、敏锐的商业嗅觉，或者是其他一些溢美之词，而杰出的 CEO 们往往只有一个统一的回答：“我没有放弃。”

英雄也好，懦夫也罢，他们的感受是相同的。他们都惧怕死亡，畏惧伤害。胆怯的人拒绝面对他必须面对的事情，而勇敢的人则用意志赶跑怯懦，然后继续去做他该做的事。那些旁观者对你的判断往往是基于你的行为，而不是你的感受。——拳击教练 CUS.D’AMATO

我和搭档与企业家打交道时，最关心对方身上是否有这两种特质：智慧与勇气。我的 CEO 生涯告诉我，在面临那些至关紧要的问题时，老天考验的是我的勇气，而不是我的智商。

有趣的是，哈姆雷特刚一做出这个决定，就迎来了董事会和管理层的一致拥护。为什么呢？既然他们迫切想要卖掉公司并奉劝 CEO 放弃梦想，为什么会突然改变态度？后来才知道，让他们最初倾向于卖掉公司的最主要原因就是哈姆雷特的举棋不定。他们以为自己的态度就是老板想要的。哈姆雷特没有意识到这一点，误以为对方是经过全面分析才得出的结论。幸运的是，他凭借勇气最终做出了正确的抉择。

从表面上来看，如果你希望自己的决定能让公司安然无恙，那么随大流似乎是更为稳妥的做法。但是在实际操作中，多数人的看法会影响你的判断，使一个原本一目了然的选择变得难分高下。这就是为什么勇气对于 CEO 而言至关重要。

我将重点谈谈管理公司所必需的两项核心技能：第一，目标明确，知道自己该做什么。第二，能带动全公司去实现这个目标。我把那些更乐于为公司确立目标的 CEO 称为“一”，把那些更喜欢在实践中推动公司发展的 CEO 称为“二”。

大多数创业型 CEO 都属于这一类。他们如果在商场上败下阵来，最重要的原因是他们从未花时间去培养自己的另一项能力——将决策有效付诸实施的能力。

大多数人对“领导才能”的定义都类似于高等法院的法官伯特·斯图尔特对“色情文学”的那个著名定义：见到它，我就认得出它。在此，我认为领导才能是那些可以衡量一个领导者基本素质的因素：有多少人愿意追随他，有哪些人愿意追随他，追随他的人都属于什么层次。

让他人追随你的能力。我不确定是否所有 CEO 都能完全学会比尔·坎贝尔特质，但我敢肯定，它是教不会的。在三个特质中，这个特质的“先天赋予性”最强。

史蒂夫·乔布斯重返苹果之际，公司已经岌岌可危——典型的逆境。他需要的，是所有人围绕中心使命，有效地执行他的决策，除此之外的任何个人想法都要靠边站。而谷歌在占领搜索引擎市场的龙头地位之后，采用了顺境模式的管理策略。公司鼓励创新，甚至要求每一位员工将 20% 的工作精力都放在研发新项目上。

顺境中的 CEO 和逆境中的 CEO

顺境中的 CEO 沿着常规的路径向成功迈进，而逆境中的 CEO 则跳出常规来争取突围。顺境中的 CEO 放眼于宏观前景，授权下属去做细节性的工作；而逆境中的 CEO 视细节如生命，唯恐因细节的疏漏而影响全局。顺境中的 CEO 会搭建逐级递增的大型招募机构，而逆境中的 CEO 会在此基础上成立负责遣散人员的人力资源部。顺境中的 CEO 会花时间营造企业文化，而逆境中的 CEO 则通过逆境本身来界定企业文化。顺境中的 CEO 常备有应急预案，而逆境中的 CEO 常常得孤注一掷。顺境中的 CEO 凭借天时地利有备而战，而逆境中的 CEO 往往要置之死地而后生。顺境中的 CEO 尽量做到文明有礼，而逆境中的 CEO 常常有意说脏话。顺境中的 CEO 认为竞争犹如隔岸之火，不会波及自己；而逆境中的 CEO 认为竞争就是伸进自家院墙的魔爪，危险近在咫尺。顺境中的 CEO 志在拓展市场，而逆境中的 CEO 志在赢得市场。顺境中的 CEO 能容忍员工因为努力创新而产生的小偏差，逆境中的 CEO 则对此绝不姑息。顺境中的 CEO 总是心平气和，而逆境中的 CEO 几乎都用高八度的嗓门说话。顺境中的 CEO 竭力弱化矛盾，而逆境中的 CEO 总是竭力让矛盾升级。顺境中的 CEO 总是广开言路，而逆境中的 CEO 总是独断专行。顺境中的 CEO 会确立有风险、有创新的宏大目标；而逆境中的 CEO 则忙于真刀真枪地迎击对手，顾不上看那些纸上谈兵的顾问们写就的管理学大作。顺境中的 CEO 通过员工培训来确保他们的工作满意度和职业发展，而逆境中的 CEO 通过员工培训来教会他们如何在竞争中不被踢出局。顺境中的 CEO 会放弃那些没能在业内占据领先地位的产业，而逆境中的 CEO 还没奢侈到把生意分成三六九等的程度。

我常常会听到一些风投资本家和董事会成员在短暂接触某个企业创始人之后，就认定他根本不是“当 CEO 的料”。我不明白他们如何能在那么短的时间内发现这一点。一个企业的创办者往往需要花费数年的时间才能掌握当 CEO 的技能。对我来说，判断一个人究竟能否当好 CEO，其实是一件很难的事。

这样做的确有违天性，但是评估人们的工作表现，并且不断给出反馈正是一个 CEO 必须要做的。如果不这么做，那么一些更复杂的事情，比如写总结、明确职责范围、应对办公室政治、制定薪酬制度以及开除员工等事务就完成不了，或者即便完成也做得差强人意。

“三明治反馈法”的基本概念是，如果你在一开始先表扬（第一片面包），人们会更容易接受你的反馈。接下来给出那些令他们不快的信息（批评），最后再提醒他们你有多看中他们的优点（第二片面包）。

要想精通反馈之道，必须要超越“三明治反馈法”这类基础技巧，形成符合自己个性和价值观的风格。以下是实现有效反馈的几个关键点：

真实可信。务必要让他们相信你的反馈，不要说一些操纵听者感受的话。不能装模作样。
出发点正确。给出反馈的目的是希望他们做得更好，而不是更差，这一点很重要。如果你真的想让他们成功，就得让他们感受到这一点。让他们感受到你的心。这样，他们才能感受到你的支持，才会听你的。
对事不对人。如果想开除某个人，那就直接开除。不要让他准备好被开除，而要让他准备好取得成功。如果他不听取反馈，那就换一种对话方式。
不要在同事面前玩弄一个人。虽然在小组会议上给出某种反馈并无不可，但绝对要避免让一个人在同事面前颜面扫地。否则，你的反馈将起不到什么作用，只会让这名员工感到羞愧难当，对你恨之入骨。
反馈因人而异。每个人都不同。有些人对于反馈非常敏感，有些人则脸皮特别厚，也很迟钝。你的语气应当结合员工的个性，而不是由着你自己的性子。
直截了当，但不刻薄。不要兜圈子。如果你觉得某人的演示很糟糕，不要说：“这的确不错，但可以加一个过渡，强化结论部分。”下面的说法听起来严厉，但效果也许更好：“我没听懂，不知道你要说什么，原因是××××。”弱化反馈中的批评部分，可能会比没有反馈还要糟糕，因为这可能导致误解，让听者困惑。但也不要一味批评他们，也不要摆出高人一等的姿态。这么做于事无补，因为正确的反馈是对话，而不是独白。

讲述这段经历是想提醒大家，当你以为在生意场上可以信赖别人时，结局往往令你大失所望。出现这种情况时，一味地计较谁是谁非毫无意义。你需要做的，就是打起精神去应对那些危机。

影片中，母亲和女儿由于缺乏沟通而关系紧张，因此，她们希望能通过互换身份来增进对彼此的了解。在电影的奇幻世界中，她们实现了这个愿望。随着故事情节的发展，她们交换了身体，体验到了对方所看到的世界。最后，母女二人换回各自的原形，自此变成了知心朋友。在看过这部影片的两个版本之后，我觉得自己已经找到了对策，那就是，“怪诞星期五”管理策略。

我们需要更上一层楼，也需要与众不同。在考虑如何才能具备更多的优点和特点时，我们的核心思想主要基于以下两点：第一，技术型创始人是经营技术型公司的最佳人选。那些令我们钦佩的历史悠久的技术型公司——惠普、英特尔、亚马逊、苹果、谷歌、Facebook——都曾由它们的创始人经营。更准确地说，公司是由开天辟地的那个人在经营。第二，技术性创始人创办公司后成为 CEO 的过程异常艰难，我就是个明证。

如果我们的风投公司专门以帮助技术型创始人经营公司为宗旨，那就可以树立品牌，创下口碑，即便没有以往的投资业绩，我们借此也有望一跃成为名列前茅的风投公司。

难题之所以棘手，是因为你找不出便捷的方法去解决它，是因为你的理智和情感难以融合，是因为你不知道答案而又不能寻求帮助，因为求助于人意味着你的无能。

在我祖父的墓碑上，刻着他最喜欢的一句马克思的名言：生命即挣扎。我认为，这句话里饱含着一个企业家最需要明白的道理：接纳挣扎。

论文分享｜RAFT: 为特定领域的 RAG 应用微调 Llama 2

Fri, 30 Aug 2024 11:37:26 +0800

引言

在人工智能和自然语言处理领域，检索增强生成 (Retrieval-Augmented Generation, RAG) 技术正在迅速崛起。RAG 通过结合大型语言模型的生成能力和外部知识库的准确性，为许多应用提供了强大的解决方案。然而，如何让语言模型更好地适应特定领域的 RAG 任务仍然是一个挑战。最近发表的一篇论文提出了一种新颖的方法来解决这个问题。

论文概述

Zhang, Tianjun, Shishir G. Patil, Naman Jain, Sheng Shen, Matei Zaharia, Ion Stoica, and Joseph E. Gonzalez. “RAFT: Adapting Language Model to Domain Specific RAG.” arXiv, June 5, 2024. http://arxiv.org/abs/2403.10131.

这篇论文介绍了一种名为 RAFT (Retrieval Augmented Fine Tuning) 的新技术，旨在针对 RAG 任务对大型语言模型进行微调。研究团队使用特定领域的文档对 Llama 2 7B 模型进行了监督式微调 (Supervised Fine-tuning, SFT)。

核心思想

RAFT 的核心思想是在训练过程中模拟真实世界 RAG 系统的检索环境。在实际应用中，RAG 系统通常会检索出 top K 个相关文档作为上下文提供给语言模型，但这些文档中可能包含一些不太相关的内容。RAFT 通过在训练数据中混合黄金文档（准确相关的文档）和干扰文档（可能不太相关的文档），教会模型如何在噪声中提取有用信息。

方法详解

RAFT 的训练数据包括以下组成部分：

问题 ($Q$): 用户查询或需要回答的问题。
文档集合 ($D$): 包括两部分：
- $P\%$ 的黄金文档 ($D*$): 与问题高度相关的文档。
- $(1-P)\%$ 的干扰文档 ($D_k$): 可能不太相关的文档。
答案 ($A$): 使用 GPT-4 模型，基于问题 $Q$、黄金文档 $D*$ 和 Chain-of-Thought (CoT) 方法生成的高质量答案。

这种训练方法不仅提高了模型生成答案的质量，还增强了模型的可解释性。通过 CoT 方法要求模型在回答问题时引用原文，RAFT 确保了模型的回答是基于检索到的文档，而不是凭空想象。

与传统微调方法的区别

传统的微调方法通常只使用高质量的相关文档进行训练，这可能导致模型在面对实际 RAG 场景中的噪声数据时表现不佳。RAFT 通过引入干扰文档，模拟了更真实的检索环境，从而提高了模型在实际应用中的鲁棒性。

实验结果

研究团队在多个领域特定的数据集上进行了实验，结果显示 RAFT 相比基线方案都有显著提升：

值得注意的是，实验发现最佳的黄金文档比例 ($P\%$) 因数据集而异。这一发现提醒我们，在应用 RAFT 时需要根据具体任务和领域进行调整。

优势与局限性

优势：

提高了模型在噪声数据中提取有用信息的能力。
增强了模型在面对不同数量检索文档时的鲁棒性。
通过要求引用原文，提高了模型回答的可解释性。

潜在局限性：

需要为每个特定领域重新训练模型，可能耗时耗力。
最佳黄金文档比例需要通过实验确定，增加了调优的复杂性。
在极度专业或罕见的领域，可能难以获得足够的训练数据。

结论

RAFT 为改进领域特定的 RAG 系统提供了一种有前景的方法。通过模拟真实的检索环境，RAFT 成功地提高了语言模型在处理特定领域查询时的性能和鲁棒性。

Mem0：用三个 prompt 打造 19K 星的网红 AI 项目

Wed, 07 Aug 2024 19:58:40 +0800

在快速发展的人工智能世界中，Mem0 作为一个杰出项目脱颖而出，在 GitHub 上获得了超过 19,000 颗星。这个创新系统旨在通过独特的记忆层设计来增强 AI 持续学习和适应个别用户需求的能力。Mem0 成功的核心在于三个精心设计的提示 (prompt),这些提示驱动了它的功能。

Mem0 的核心概念

Mem0 利用向量数据库和智能提示来帮助 AI 系统记住用户偏好，适应个人需求，并随时间改进。其工作流程包括四个主要步骤：

记忆提取：在这个初始步骤中，Mem0 处理新数据，如用户的聊天历史或最近的交互。它使用MEMORY_DEDUCTION_PROMPT来分析这些输入并提取相关记忆。AI 检查用户的输入和任何可用的元数据，然后以简洁的要点格式生成事实、偏好和记忆的列表。

例如，如果用户在对话中提到喜欢意大利食物并讨厌寒冷天气，Mem0 可能会提取出"喜欢意大利菜"和"偏爱温暖气候"这样的记忆。这一步骤至关重要，因为它将复杂的、非结构化的交互提炼成简单、结构化的记忆点。
记忆搜索：一旦提取出记忆，Mem0 将它们转换为嵌入向量 - 捕捉记忆语义含义的高维向量表示。然后使用这些嵌入向量在向量数据库中搜索类似的现有记忆。

系统使用高效的相似度搜索算法来找到与新记忆在语义上接近的记忆。例如，如果新记忆是关于意大利食物偏好的，它可能会找到关于最喜欢的餐厅或烹饪习惯的现有记忆。这一步骤不使用特定的提示，而是依赖于向量数据库的功能。
记忆更新：在识别出类似的现有记忆后，Mem0 使用UPDATE_MEMORY_PROMPT来决定如何将新信息与现有知识库整合。AI 会得到以下信息：
- 来自数据库的现有记忆
- 这些记忆与新记忆的相似度分数
- 新记忆本身
基于这些信息，AI 会做出如下决策：
- 将新记忆作为全新条目添加
- 修改现有记忆以纳入新细节
- 合并多个相关记忆
- 删除过时或矛盾的信息
例如，如果用户之前喜欢披萨但现在提到更喜欢意大利面，Mem0 可能会将现有的"喜欢披萨"记忆更新为"相比披萨更喜欢意大利面"。
基于记忆的响应：当用户提出问题或请求信息时，Mem0 首先在其向量数据库中搜索相关记忆。它使用与步骤 2 相同的嵌入和相似度搜索过程，但这次是为了找到与用户查询相关的记忆。

一旦检索到相关记忆，Mem0 使用MEMORY_ANSWER_PROMPT来生成响应。这个提示指导 AI 以自然和连贯的方式将检索到的记忆融入回答中。

例如，如果用户询问餐厅推荐，而 Mem0 有关于用户食物偏好和饮食限制的记忆，它可以基于这些信息提供个性化的建议。

这四个步骤协同工作，创建了一个动态系统，能够持续从用户交互中学习，维护最新的知识库，并提供个性化的响应。这个过程使 Mem0 能够适应不断变化的用户偏好并随时间积累知识，使每次交互都更加个性化和具有上下文相关性。

提示分析

让我们深入分析驱动这个系统的三个关键提示，并分析它们的角色。

MEMORY_DEDUCTION_PROMPT
```
从提供的文本中推导出事实、偏好和记忆。
仅以要点形式返回事实、偏好和记忆：
自然语言文本：{user_input}
用户/代理详情：{metadata}
推导事实、偏好和记忆的约束：
- 事实、偏好和记忆应该简洁明了。
- 不要以"这个人喜欢披萨"开始。而应该以"喜欢披萨"开始。
- 不要记住提供的用户/代理详情。只记住事实、偏好和记忆。
推导出的事实、偏好和记忆：
```
分析：这个提示对于初始的记忆提取步骤至关重要。它的作用是将原始用户输入转化为结构化的、简洁的记忆点。提示的设计鼓励：
- 简洁性：通过指示使用要点形式并以动作词开始 (例如，“喜欢披萨"而不是"这个人喜欢披萨”),它确保记忆紧凑且易于处理。
- 相关性：它明确告诉 AI 专注于事实、偏好和记忆，过滤掉无关信息。
- 隐私：通过指示不记住用户/代理详情，它有助于维护用户隐私。
这个提示的有效性在于其能够将复杂的交互提炼成简单、可操作的记忆点，这些记忆点可以轻松存储和检索。

UPDATE_MEMORY_PROMPT

你是合并、更新和组织记忆的专家。当提供现有记忆和新信息时，你的任务是合并和更新记忆列表，以反映最准确和最新的信息。你还会得到每个现有记忆与新信息的匹配分数。确保利用这些信息做出明智的决定，决定哪些记忆需要更新或合并。
指南：
- 消除重复的记忆，合并相关记忆，以确保列表简洁和更新。
- 如果一个记忆直接与新信息矛盾，请批判性地评估两条信息：
    - 如果新记忆提供了更近期或更准确的更新，用新记忆替换旧记忆。
    - 如果新记忆看起来不准确或细节较少，保留旧记忆并丢弃新记忆。
- 在所有记忆中保持一致且清晰的风格，确保每个条目简洁而信息丰富。
- 如果新记忆是现有记忆的变体或扩展，更新现有记忆以反映新信息。
以下是任务的详细信息：
- 现有记忆：
{existing_memories}
- 新记忆：{memory}

分析：这个提示是 Mem0 维护最新且连贯的记忆数据库能力的基石。它的作用是智能地将新信息与现有记忆合并。关键方面包括：

冲突解决：它提供了明确的指南，说明如何处理矛盾的信息，确保保留最准确和最新的数据。
效率：通过消除重复项和合并相关记忆，它保持记忆数据库紧凑和相关。
一致性：保持一致风格的指示确保记忆数据库保持连贯且易于理解。
适应性：提示允许用新的变体或扩展来更新现有记忆，使系统能够随时间演变其理解。

这个提示对记忆管理的复杂方法使 Mem0 能够持续学习和适应，而不会积累冗余或过时的信息。

MEMORY_ANSWER_PROMPT
```
你是基于提供的记忆回答问题的专家。你的任务是利用记忆中给出的信息，对问题提供准确和简洁的回答。
指南：
- 根据问题从记忆中提取相关信息。
- 如果没有找到相关信息，确保你不要说没有找到信息。相反，接受问题并提供一般性回答。
- 确保答案清晰、简洁，并直接回答问题。
以下是任务的详细信息：
```
分析：这个提示对于 Mem0 有效利用存储的记忆来回应用户查询至关重要。它的作用是指导 AI 制定既相关又用户友好的回答。关键特点包括：
- 相关性：它指示 AI 只提取与当前问题相关的信息，确保回答集中。
- 优雅处理未知情况：通过指示 AI 在没有找到相关信息时提供一般性回答，它即使在记忆数据库缺乏特定信息时也能维持流畅的用户体验。
- 清晰和简洁：强调清晰简洁的答案确保用户容易理解回答。
这个提示使 Mem0 能够提供个性化、具有上下文感知的回答，大大增强了用户体验，使 AI 看起来更智能和适应性更强。

结论

Mem0 的病毒式成功很大程度上可以归功于这三个精心设计的提示。它们共同创造了一个系统，能够从用户交互中提取有意义的信息，智能地更新和管理记忆数据库，并利用这种个性化知识提供相关且简洁的回答。这种 AI 记忆管理方法代表了创建更具适应性和个性化 AI 系统的重要进步，解释了该项目在开发者和 AI 爱好者中的受欢迎程度。

过滤向量搜索：RAG 系统中的关键技术

Thu, 18 Jan 2024 17:56:47 +0800

在基本的 RAG (Retrieval-Augmented Generation) 系统中，文档（包括文本、PDF、Word、PPT 等）首先经过切割 (chunking) 处理，提取出嵌入向量 (embedding) 后存储于向量数据库中进行索引。用户提问时，系统先从索引中检索与用户问题最相关的文档，然后将用户问题和相关文档片段送给大型语言模型 (LLMs) 生成更准确的答案。

来源：@jerryjliu0

多篇文章证明了 RAG 的有效性¹²³，主要结论包括：

RAG 显著改善了 GenAI 应用的结果；
即使向量数据库中的数据是 GPT-4 训练时已知的，使用 RAG 的 GPT-4 也优于不使用 RAG 的版本；
一些开源的小型模型，在采用 RAG 后，其效果能接近使用 RAG 的 GPT-4。

RAG 系统的核心是存储了大量文档的向量数据库。这个数据库能否快速准确地搜索到与问题相关的文档，对 RAG 系统的效果至关重要。向量数据库所需关注的不仅是向量数据，还包括与向量相对应的元数据。充分利用这些元数据进行过滤搜索，可以显著提高搜索的准确度和整个 RAG 系统的效果，进而改善 GenAI 应用的体验。

例如，假设向量数据库中存储了大量的论文，用户可能只关心特定学科或作者。因此，在搜索时加入相应的过滤条件可以显著提高搜索结果的相关性。另外，带过滤的向量搜索还可用于多租户场景，例如聊天或 ChatPDF 类应用中，用户只需搜索自己的聊天记录或文档。此时，如果将每个用户作为数据库中的一个分区 (partition)，会给数据库本身增加很大负担，并且对查询性能产生负面影响。因此，使用用户 ID 作为过滤条件进行带过滤的向量搜索是一种更自然的操作方式。

前过滤 vs. 后过滤

在实现带过滤的向量搜索时，存在前过滤和后过滤两种方式。前过滤 (pre-filtering) 先通过元数据筛选出符合条件的向量，再在这些向量中进行搜索。这种方法的优点是，如果用户需要 k 个最相似的文档，数据库能够保证返回 k 个结果。后过滤 (post-filtering) 则是先进行向量搜索，得到 m 个结果，再对这些结果应用元数据过滤。这种方式的缺点是，由于不确定 m 个结果中有多少符合元数据过滤条件，最终结果可能不足 k 个，特别是当符合过滤条件的向量在整个数据集中数量较少时。

前过滤的挑战在于如何高效地进行元数据过滤，以及在过滤后向量数量较少时，向量索引的搜索效率。例如，使用广泛的 HNSW (Hierarchical Navigable Small World) 算法在过滤比例较低（例如过滤后只剩下 1% 的向量）时，搜索效果会大幅下降。为此，Qdrant 和 Weaviate 进行了一些探索，通常的做法是在过滤比例较低时，从 HNSW 算法回退到暴力搜索。

Benchmark 结果

参考对多个向量数据库的云服务进行了测试的 MyScale Vector Database Benchmark。在过滤比例为 1% 的测试中（即施加过滤条件后，全库中只有 1% 的向量满足条件），结果如下：

从结果来看，OpenSearch（两个版本 v2.7 和 v2.11）和 pgvector 的精度过低，不足 50%。Zilliz 的 capacity 模式性能过低，不到 1 QPS (query per second)。排除这些选项后，再看一下剩下的结果：

可以看出，精度和性能都比较好的数据库包括 MyScale、Qdrant 和 Pinecone (p2 pod)。而 Pgvecto.rs、Zilliz (Performance & Cost-optimized 模式)、Pinecone (s1 pod) 的精度还不错，但性能较低。在这些数据库中，MyScale 和 Pinecone 只提供全托管的 SaaS 服务。Qdrant 和 Zilliz (开源版本为 Milvus) 既有 SaaS 服务也有开源版本。Pgvecto.rs 目前是一款完全开源的 Postgres 插件，暂无 SaaS 版本。

总结

RAG 系统结合了大型语言模型和向量数据库，通过处理用户问题和相关文档片段，显著提升了 GenAI 应用的效果。向量数据库的搜索效率和准确度是系统性能的关键。优化搜索策略（如前过滤和后过滤）和选择合适的向量数据库是提升 RAG 系统效果的重要因素。通过对各种数据库的综合评测，用户可以为不同需求选择最佳解决方案，推动 GenAI 领域的进步。

译文 | 向量搜索作为一项专门的服务

Thu, 21 Dec 2023 10:00:00 +0800

原文由 Andrey Vasnetsov（开源向量数据库 Qdrant 的创始人和 CTO）发布在 Qdrant 博客。翻译已经过原作者同意，转载请保留原文链接和译者信息。

译者：lqhl，来自 MyScale（一个基于 SQL 的全托管向量数据库）的软件工程师。

自从数据科学界发现向量搜索显著改善了大语言模型的答案以来，各种供应商和爱好者一直在就存储嵌入向量的合适解决方案进行争论。

有人说将它们存储在专用引擎（又称向量数据库）中更好。其他人则认为只需使用现有数据库的插件就足够了。

这里只是其中的一部分。（译者注：这是一部分中文的相关文章）

这篇文章提出了我们对这个主题的愿景和论点。我们将：

解释为什么以及何时您实际上需要专门的向量解决方案。
驳斥一些毫无根据的说法和在构建向量搜索系统时应避免的反模式。

回应对向量数据库的常见误解

每个数据库供应商迟早都会引入向量功能。这将使每个数据库都成为一个向量数据库

这种误解的根源在于对向量数据库这个术语的粗心使用。当我们想到数据库时，下意识地会想到像 Postgres 或 MySQL 这样的关系型数据库。或者更科学地说，是建立在 ACID 原则上的服务，提供事务、强一致性保证和原子性。

大多数向量数据库并非传统意义上的数据库。更准确地说，它们更像是搜索引擎，但不幸的是，营销术语向量数据库已经深入人心，而且可能不太可能改变。

是什么使得搜索引擎与数据库不同，以及为什么向量数据库是作为搜索引擎构建而非数据库？

首先，搜索引擎假定与数据库不同模式的工作负载并优先考虑系统的其他需求。搜索引擎的核心架构是围绕与数据库不同的优先级构建的。

搜索引擎优先考虑哪些类型的属性？

可扩展性。搜索引擎被设计用于处理大量数据和查询。它们被设计为横向可扩展，并且能够处理超出单台机器容量的更多数据。
搜索速度。搜索引擎应该保证查询的低延迟，而更新的原子性则不那么重要。
可用性。如果集群中的大多数节点都宕机，搜索引擎必须保持可用。与此同时，它们可以容忍更新的最终一致性。

这些优先级导致了不同的架构决策，这些决策在通用数据库中是无法复现的，即使它支持向量索引。

拥有专用的向量数据库需要复制数据

本质来说，向量嵌入是主要源数据的衍生物。

在绝大多数情况下，嵌入是从其他数据（如文本、图像或系统中存储的其他信息）派生而来的。因此，实际上，系统中所有的嵌入都可以被视为对某些原始来源的转换。

衍生数据的显著特点在于当转换流水线发生变化时，数据也会发生变化。以向量嵌入为例，这种变化的情况非常简单：每当更新编码器模型 (encoder model) 时，所有嵌入都会发生变化。

在将向量嵌入与主数据源融合的系统中，要进行这样的迁移是不可能的，因为这将会对生产系统产生显著影响。

因此，即使您想要使用单个数据库存储各种数据，您仍然需要在内部复制数据。

拥有专用的向量数据库需要复杂的数据同步

大多数生产系统更倾向于将不同类型的工作负载隔离到单独的服务中。在许多情况下，这些隔离的服务甚至与搜索使用案例无关。

例如，用于分析的数据库 (OLAP DB) 和用于提供服务的数据库 (OLTP DB) 可以从同一来源进行更新。然而，它们可以以最适合它们典型工作负载的方式存储和组织数据。

搜索引擎通常是隔离的，原因是为了避免产生坏邻居效应 (noisy neighbor problem)，从而影响主数据库的性能。

为了让你有一些直觉，让我们考虑一个实际的例子：

假设我们有一个包含 100 万条记录的数据库。按照现代任何关系型数据库的标准来看，这是一个小型数据库。你可能可以使用任何云服务提供商的最小免费套餐来托管它。

但是，如果我们想要将这个数据库用于向量搜索，100 万个 OpenAI text-embedding-ada-002 嵌入将占用大约 6Gb 的内存。正如你所看到的，向量搜索用例完全超出了主数据库的资源需求。实际上，这意味着你的主数据库将承担高内存需求，并且无法有效扩展，受限于单台机器的大小。

幸运的是，数据同步问题并不是新问题，而且绝对不是向量搜索所独有的。有许多众所周知的解决方案，从消息队列开始，到专门的 ETL 工具结束。

例如，最近我们发布了与 Airbyte 的集成，允许您将来自各种来源的数据逐步同步到 Qdrant 中。

你需要为两种解决方案的向量服务的运行时间和数据传输付费

在开源世界中，您支付所使用的资源，而不是您运行的不同数据库的数量。资源更多取决于每种用例的最佳解决方案。因此，运行专用的向量搜索引擎甚至可能更便宜，因为它允许针对向量搜索用例进行优化。

例如，Qdrant 实现了许多量化技术，可以显著减少嵌入的内存占用。

在数据传输成本方面，大多数云服务提供商在同一地区内的网络使用通常是免费的。只要您将原始数据和向量存储放在同一地区，就不会产生额外的数据传输费用。

什么比您当前的数据库更无缝地添加向量搜索功能更好呢？

与集成解决方案的短期吸引力相比，专用搜索引擎提供了灵活性和模块化方法。每次更新一些向量插件时，您无需更新整个生产数据库。专用搜索引擎的维护与主数据库一样独立。

事实上，利用专用的向量解决方案，集成更复杂的场景，比如读/写分离，要容易得多。您可以轻松构建跨区域复制，以确保用户的低延迟。

将向量数据库与现有数据库分离在大型企业组织中尤其重要，因为系统的不同部分责任分散在不同团队之间。在这种情况下，为人工智能团队维护一个专用的搜索引擎要比说服核心团队更新整个主数据库容易得多。

最后，全能数据库的向量功能与整个软件栈的开发和发布周期紧密相关。它们长期的使用历史也意味着它们需要为向后兼容性付出很高的代价。

数据库可以全面支持 RAG 使用案例

暂且不论性能和可扩展性问题，关于在数据库中实现 RAG 的整个讨论都假设传统数据库唯一缺失的细节是向量索引和快速进行近似最近邻查询的能力。

事实上，目前向量搜索的能力只是触及了可能性的表面。例如，在我们最近的文章中，我们讨论了构建一个探索 API 的可能性，以推动发现过程 — 这是 kNN 搜索的一种替代方案，你甚至不知道自己究竟在寻找什么。

总结

最终，如果你只是在寻找一个简单的向量搜索功能，并且数据量较小，那么你并不需要一个向量数据库。我们真诚建议你从你已有的技术栈中开始原型设计。但如果你希望做更多的事情，并且这是你的应用的核心功能，那么你就需要一个向量数据库。这就好比用多功能工具快速制作东西，或者使用专门针对特定用例进行高度优化的专用工具。

大规模生产系统通常由不同的专业服务和存储类型组成，这是现代软件架构的最佳实践之一。类似于微服务架构中独立构建块的编排。

当您向数据库填充向量索引时，会影响主数据库的性能和可扩展性，以及向量搜索功能。没有一种适合所有情况且不会影响性能或灵活性的方法。因此，如果您的用例在很大程度上利用向量搜索，值得投资于专用的向量搜索引擎，也就是向量数据库。

书摘｜文明的冲突与世界秩序的重建、毫无意义的工作

Wed, 20 Dec 2023 20:56:00 +0800

文明的冲突与世界秩序的重建

日本和印度曾有过与西方相似的阶级制度（也许由于此，它们是仅有的两个维持了一定时间民主政府的重要的非西方社会）。

拒绝主义。日本从 1542 年第一次同西方交往到 19 世纪中叶，实质上遵循了拒绝主义的路线。

这一拒绝主义立场由于日本 1854 年在美国海军准将柏利（Perry，一译“佩里”，译注）的压力下被迫开放门户和 1868 年明治维新之后全力学习西方而告终。

虽然中国于 1602 年允许基督教传教士进入中国，但以后又在 1722 年把他们驱逐出境。与日本不同，中国的拒绝主义政策在很大程度上植根于中国作为中央帝国的自我形象和坚信中国的文化优越于所有其他文化的信念。

基马尔主义（凯末尔主义）。对西方的第二个可能的回应是汤因比所说的希律党人的主张（Herodianism），即拥护现代化和西方化。

这一方法以 19 世纪末一些日本和中国的知识分子的论点为典型，他们认为，为了实现现代化，他们的社会必须放弃其传统语言，而采用英语作为国语。毫不令人惊异的是，这一观点在西方人中甚至比在非西方精英中更加流行。它提供的信息是：“要想成功，你必须像我们一样。我们的方法是唯一的方法。”

在从事这项事业和抛弃伊斯兰的历史时，基马尔使土耳其成了一个“无所适从”的国家，一个在其宗教、遗产、习俗和体制方面是伊斯兰的社会，但是其统治精英却决心使它成为现代的、西方的和与西方一致的。

改良主义。拒绝意味着把一个社会孤立于一个正在缩小的现代世界之外的一种无望做法。基马尔主义意味着一个困难的和痛苦的做法：摧毁已经存在了许多世纪之久的文化，用从另一个文明中引入的全新的文化来取代它。第三种选择是试图把现代化同社会本土文化的主要价值观、实践和体制结合起来。

马兹鲁伊甚至认为埃及和非洲已经沿着“没有技术现代化的文化西方化的痛苦过程走向 D 点”。

几乎世界上所有非西方文明都至少存在了 1000 年，有些是几千年。有记录证明，它们都借鉴过其他文明来增强自己的延续。

日本遵循了同样的模式。公元 7 世纪，日本引入了中国文化，“在没有经济和军事压力的情况下，主动转变为”高级的文明。“在其后的几个世纪里，相对孤立于大陆影响的时期（在此期间，他们对以前的借鉴作了挑选，吸收了有用的东西）和重新开始交往和文化借鉴的时期交替出现。”（注 44）在所有这些阶段，日本文化保留了其独特性。

阿普特尔使用这些范畴来分析非洲部落的变化，艾森施塔特把类似的分析运用于一些伟大的亚洲文明，并得出了类似的结论。“社会、文化和政治体制的自主极大地促进了”内部变化。（注 46）由于这些原因，更具有工具性的日本社会和印度社会比儒教社会和伊斯兰社会更早也更容易地进入了现代化。它们更有能力引进西方技术和运用它来支持自己的现存文化。

除日本之外，新加坡、中国台湾、沙特阿拉伯，在较小的程度上还有伊朗，已成为现代社会而没有变为西方化。

伊斯兰社会在实现现代化方面一直存在着困难，派普斯用下述论据来支持其西方化是现代化的前提条件的观点：伊斯兰教与经济事务方面的现代性在诸如利息、斋戒、遗产法和妇女参加工作等方面相冲突。

伊斯兰教与现代化并不冲突。虔诚的穆斯林能够研习科学，在工厂中有效率地工作，或利用先进武器。

相对于其他文明而言，西方的力量呈现出两幅画面。第一幅是西方处于压倒一切的、成功的、几乎是完全的支配地位。苏联的瓦解消除了西方唯一最强劲的挑战者，其结果是在日本可能会偶然给予的支持下，世界正在并将继续被西方主要国家的目标、优先考虑和利益所塑造。

关于西方的第二幅图画却与这第一幅画面大不相同。那是一个衰落的文明，相对于其他文明而言，西方在世界政治、经济和军事领域的力量正在下降。西方在冷战中获胜带来的不是胜利，而是衰竭。西方越来越关注其内部问题和需求，因为它面临着经济增长缓慢、人口停滞、失业、巨大的政府赤字、职业道德下降、储蓄率低等问题；此外在许多国家，包括美国，面临着社会解体、吸毒、犯罪等问题。

印度处于经济起飞的边缘，伊斯兰世界日益敌视西方。其他社会很快不情愿接受西方旨意和容忍其说教，西方的自信和支配意志也会随之消失。

在许多重要方面，它（指美国）的相对力量将加速下降。就其纯经济能力而言，美国的地位相对于日本、最终相对于中国可能会进一步动摇。

这两幅关于西方世界地位的相反画面，究竟哪一幅描绘了现实？答案当然是：它们描绘的都是现实。西方现在占绝对优势，并在进入 21 世纪时仍将在实力和影响力方面保持世界第一。然而文明间的力量对比也发生了一些逐步的、无情的、也是根本的变化。西方的力量相对于其他文明将继续衰落。

最重要的力量增长正在并将继续发生在亚洲文明之中，中国正逐渐成为最有可能在全球影响方面向西方挑战的国家。

西方的衰落有如下三个特征：首先，这是一个缓慢的过程。西方力量的上升历时 400 年之久，它的衰退可能也需要同样长的时间。

在一国的能力中，经济增长及其他方面的增长通常呈 S 形曲线：起步缓慢然后急剧加速，接着是增长速度降低，再到停滞。国家的衰落也可能沿倒 S 形曲线发展，正如苏联的情形一样：起先是中速下降，然后迅速加速，最后到达谷底。西方的衰落仍处于缓慢的第一阶段，但在未来的某一天，它可能会急剧加速。

第二，衰落并不是呈直线型的。它极不规则，并带有间歇和反复，在西方的弱点暴露出后，它会再次坚持自己的权力。

此外，与许多文明不同，西方有两个主要的力量中心。布尔所看到的始于 1900 年左右的衰落，实质上是西方文明中欧洲部分的衰落。从 1910 年到 1945 年，欧洲发生了不利于自己的分裂，被其内部的经济、社会和政治问题所困扰。然而，在 20 世纪 40 年代，西方主导地位中的美国阶段开始了，而且 1945 年，美国短暂地支配了世界，其地位几乎可以与 1918 年的同盟国相比。

第三，实力是一个人或群体改变另一个人或群体行为的能力。

领土和人口。1490 年，西方社会控制了巴尔干之外的大部分欧洲半岛，即 5250 万平方英里的全球陆地面积（南极洲除外）中的大约 150 万平方英里。1920 年其领土扩张达到顶峰之际，西方直接统治了大约 2550 万平方英里的土地，将近地球陆地面积的一半。至 1993 年，西方控制的领土减少了一半，大约还有 1270 万平方英里。

与此形成对照的是，独立后的伊斯兰国家的领土由 1920 年的 180 万平方英里扩大到 1993 年的 1100 万平方英里。

1900 年西方人口大约占世界人口的 30％，西方政府统治着几乎 45％的世界人口，1920 年达到 48％。1993 年，除几个小的帝国残余如香港外，西方政府只统治着西方人。西方人口占人类总人口的比例略多于 13％，预计到 21 世纪初将下降到大约 11％，2025 年下降到 10％。（

因此，在数量上，西方人构成世界人口中持续下降的少数。在质量上，西方和其他人口之间的对比也在发生变化。非西方人民正在变得较健康，较城市化，有较高的识字率和较良好的教育。

经济产值。西方在全球经济产值中所占的份额可能是在 20 世纪 20 年代达到了顶峰，但自从第二次世界大战结束以来明显下降。

当然，西方的相对衰落在很大程度上是由于东亚的迅速崛起。

经济生产总值部分地掩盖了西方在质量上的优势。西方和日本几乎垄断了先进技术工业。然而技术正在传播，如果西方希望维持优势，它将竭力把传播减小到最低限度。然而多亏西方创造了相互联系的世界，减缓技术向其他文明的扩散将变得日益困难。由于不存在冷战时期的那种单一的、压倒一切的、公认的威胁，加之技术控制措施效力有限，情况便更是如此。

表面上看似乎中国经济在历史上大部分时期都是世界上最强大的。20 世纪后半叶技术的扩散和非西方国家的经济发展正在使历史上的格局再现。

军事能力。军事实力包括四个方面的因素：数量——兵力、武器、装备和资源；技术——武器和装备的效能和尖端性；组织——凝聚力、纪律性、训练和军队士气以及指挥和控制关系的有效性；社会——社会有效地使用军队的能力和愿望。

美国明确地把其军事计划由在全球遏制苏联并与其作战，改变为准备同时对付波斯湾和东北亚发生的地区性紧急情况。然而美国不可能具备达到这些目的的军事能力。

西方对这些资源的控制在 20 世纪 20 年代达到顶峰，尔后便无规则地但显著地下降。到 21 世纪 20 年代，即距达到该顶峰 100 年之后，西方将可能控制世界版图的约 24％（顶峰时曾达到 49％），世界人口的 10％（顶峰时为 48％）和社会动员人口的 15％—20％，世界经济产值的大约 30％（顶峰时大概为 70％），制造业产值的 25%（顶峰时为 84％），以及全球兵力的不到 10％（顶峰时为 45％）。

贸易可能会、也可能不会跟着国旗走，但文化几乎总是追随着权力。历史上，一个文明权力的扩张通常总是同时伴随着其文化的繁荣，而且这一文明几乎总是运用它的这种权力向其他社会推行其价值观、实践和体制。

共产主义意识形态在 20 世纪 50 年代和 60 年代吸引了世界各地的人民，当时它是与苏联的经济成功和军事实力联系在一起的。当苏联发生经济萧条且不能维持其军事力量时，这种吸引力也就随之消失了。

随着西方实力的削弱，西方向其他文明强加其人权、自由主义和民主等概念的能力降低了，那些价值对其他文明的吸引力也随之减小。

为了变得富有和强大，他们不得不效仿西方。然而现在这种基马尔主义的态度在东亚已经消失。东亚没有将其经济的迅速发展归因于对西方文化的引进，而是归因于对自身文化的伸张。他们论证说，他们之所以正在取得成功，就是因为他们与西方不同。

能干的、有洞察力和有适应性的第一代领导人就进行了自我本土化，其中三个著名的例子是穆罕默德·阿里·真纳、哈里·李和所罗门·班达拉奈克。他们分别是牛津、剑桥和林肯律师学院的优秀毕业生 4.2，是卓越的法学家，是其社会中彻底西方化的精英。

盎格鲁化的李光耀学会了汉语普通话，并成为一个能言善辩的儒教促进者。

20 世纪 80 年代和 90 年代，本土化已成为整个非西方世界的发展日程。伊斯兰教的复兴和“重新伊斯兰化”是穆斯林社会的主题。在印度，普遍的趋势是拒绝西方的形式和价值观，以及使政治和社会“印度化”。在东亚，政府正在提倡儒家学说，政界和知识界领袖都在谈论其国家的“亚洲化”。

冷战结束后，随着西方化主张者和斯拉夫文化优越论者之间传统冲突的再度出现，俄罗斯重新变成了一个“无所适从的”国家。然而在 10 年里，当西方化的戈尔巴乔夫被具有俄罗斯风格和西方信仰的叶利钦所取代时，趋势也随之从西方化转为斯拉夫化，而叶利钦又受到集中体现了俄罗斯东正教本土化的民族主义者的威胁。

民主化与西方化相冲突，民主本来就是一个地区化而并非世界化的进程。

在 19 世纪以前的各个时期，拜占庭人、阿拉伯人、中国人、土耳其人、蒙古人、俄罗斯人对自己的力量和成就非常自信。那时，他们也蔑视西方文化的低劣、体制的落后、腐化和衰败。

但正如一位观察家所说的，“西方的价值观遭到不同方式的反对，但在其他地方都没有像在马来西亚、印度尼西亚、新加坡、中国和日本那样坚决。”（

忧心忡忡的保守主义者警告说：宗教信仰、宗教体制以及宗教对人类个人和集体行为所起的道德指导作用的消失将导致可怕后果，最终结果将是无政府状态、堕落及文明生活的破坏。

20 世纪下半叶证明这些希望和恐惧是毫无根据的。经济和社会的现代化在全球展开，同时也发生了一场全球性的宗教复兴。

一种新的宗教方法开始形成，它不再旨在适应世俗价值观，而是旨在为社会组织重建一个神圣的基础——如果必要的话，通过改变社会来达到目的。

世俗的儒家文化的文化复兴采取了肯定亚洲价值观的形式，但在世界其他地方，宗教文化复兴却表现为对宗教价值观的肯定。

在前共产主义国家，宗教的普遍存在和现实意义一直是不言而喻的。宗教复兴席卷了从阿尔巴尼亚到越南的许多国家，填补了意识形态崩溃后所留下的空缺。在俄罗斯，东正教经历了一场重大的复兴。1994 年，俄罗斯 30％的 25 岁以下的人称自己从无神论者转变为信仰上帝。莫斯科地区使用中的教堂数目由 1988 年的 50 所增加到 1993 年的 250 所。

与东正教在斯拉夫共和国复兴的同时，一场伊斯兰复兴运动席卷了中亚。1989 年，中亚有 160 座启用的清真寺和一所伊斯兰教神学院；到 1993 年初有大约 1 万座清真寺和 10 所神学院。

全球性宗教复兴最明显、最突出也是最强有力的原因，恰恰是那些被认为会引起宗教消亡的东西：20 世纪后半叶席卷世界的社会、经济和文化现代化进程。认同和权力体系长期存在的根源瓦解了。人们从农村移居到城市，脱离了他们的根基，从事新的工作或没有工作。他们与大批陌生人相互作用，面对着一套新的关系。他们需要新认同根源、新形式的稳定社会以及一套新的道德规范来赋予他们意义感和目的感。不论是主流的宗教还是原教旨主义的宗教，都满足了这些需要。

如果你看一眼那些迅速发展的国家和地区——韩国、泰国、中国香港和新加坡，就会发现一个引人注目的现象：宗教的兴起……

人们在寻求关于人类目的和为什么我们会如此的更深层的解释。这与社会中存在巨大压力的阶段是联系在一起的。（

在社会飞速变革的时期，已确立的认同消失了，必须重新界定自我，确立新的认同。对于那些面临需要决定我是谁、我属于哪里的人们，宗教给予了令人信服的答案，宗教群体提供了小的社会群体来替代那些由于城市化而失去的东西。

在俄罗斯，宗教复兴是“对认同的狂热渴望的结果，而这种认同只有东正教会能够提供，因为它是唯一未被破坏的与 1000 年前的俄罗斯相联系的纽带”。

宗教团体满足了被国家官僚所忽视的需要，包括提供医疗及医院服务设施、幼儿园和学校、对老人的照顾、自然灾害或其他灾难之后的紧急救援，以及经济遭受损失时给予福利和社会援助。

韩国在历史上是一个佛教徒占绝大多数的国家，1950 年基督教徒的人数可能占人口的 1％—3％。当韩国进入经济迅速发展阶段，随着大规模的城市化和职业分工，佛教就变得不再适用。“

到 20 世纪 80 年代基督徒在韩人口中至少占 30％，其中大部分是基督教长老会教友及天主教徒。

拉丁美洲的新教徒数目由 1960 年的大约 700 万增加到 1990 年的 5000 万。拉丁美洲的天主教主教们 1989 年承认，新教成功的原因在于“天主教会不能迅速适应城市生活的技术性”和“教会结构有时也使它不能对现代人们的心理需要作出反应”。

鉴于儒教在感情上缺乏生气，它在失去信徒方面显得首当其冲。在儒教国家，基督新教和天主教可能具有与福音新教对于拉丁美洲人、基督教对于韩国人以及原教旨主义对于穆斯林和印度教徒同样的吸引力。在中国，20 世纪 80 年代末当经济增长达到高峰时，基督教也得到传播，“尤其在年轻人中”，可能有 5000 万中国人是基督徒。

随着冷战的结束和随之而来的政治开放，西方教会也进入了东正教的苏联各共和国，与复兴的东正教会相竞争。在那里也和在中国一样，政府极力限制人们改变宗教信仰。

20 世纪，俄罗斯、亚洲、阿拉伯、非洲和拉丁美洲的精英们引进了社会主义和马克思主义意识形态，并把它们与民族主义相结合，以反对西方资本主义和西方帝国主义。共产主义在苏联的垮台及其在中国的重大修改，以及社会主义经济不能获得持续发展，现在已造成一个意识形态的真空。

然而人们同时看到共产主义作为唯一最新的世俗上帝失败了，由于缺少令人信服的新的世俗上帝，他们带着信仰和热情转向了真正的上帝。

宗教复兴运动是反世俗的，反普世的，而且，除了在基督教中的表现，也是反西方的。

从这种意义上来说，非西方宗教的复兴是非西方社会中反对西方化的最强有力的表现。这种复兴并非拒绝现代性，而是拒绝西方，以及与西方相关的世俗的、相对主义的、颓废的文化。

亚洲的挑战表现在所有的东亚文明——中华文明、日本文明、佛教文明和穆斯林文明——都强调自己与西方的文化差异，有时也强调它们之间的共性，这些共性常常认同于儒教。

亚洲和伊斯兰有时单独地，有时携手对西方国家表现出日益自信的自我伸张。在这

在这些挑战的背后存在着相互关联但又不同的原因。亚洲的自信植根于经济的增长；穆斯林的自我伸张在相当大的程度上源于社会流动和人口增长。

东亚经济的发展一直是 20 世纪后半叶世界上最重要的发展之一。这一进程在 20 世纪 50 年代始于日本，日本曾一度被看成是很大的例外，即一个非西方国家成功地进行了现代化，并成为经济发达的国家。然而经济发展的进程蔓延到了四小龙（香港、台湾、韩国、新加坡），然后到中国、马来西亚、泰国和印度尼西亚，并正对菲律宾、印度和越南产生影响。

例外的不再只是日本，整个亚洲都在成为例外。

正如奇索·马赫布巴尼所指出的，英国和美国分别花了 58 年和 47 年的时间才使其人均产值翻了一番，而日本做到这一点用了 33 年时间，印度尼西亚用了 17 年，韩国用了 11 年，中国用了 10 年。

根据大多数估计，中国经济将于 21 世纪早期成为世界上规模最大的经济。20 世纪 90 年代已拥有世界第二、第三大经济国的亚洲，可能到 2020 年将拥有世界五大经济国中的四个，世界十大经济国中的七个。到那时，亚洲国家可能占全球经济产值的 40％以上。

20 世纪 70 年代末，共产主义未能推动经济的发展，资本主义在日本的成功和在其他亚洲社会的日益成功，导致新的中国领导人脱离了苏联模式。10 年后苏联的瓦解进一步突出了引进苏联模式的失败。中国人由此面临着转向西方还是转向国内的问题。

然而这种西方取向既没有获得北京几百名决策者的支持，也没有获得生活在农村的 8 亿农民的支持。

领导人于是选择了一种新的“中学为体，西学为用”版本：一方面是实行资本主义和融入世界经济，另一方面是实行政治权威主义和重新推崇传统中国文化，把两者结合起来。

一位评论家评述说，“天安门事件后的政权热切地接受把中国的民族主义作为合法性的新源泉”，并有意识地激起反美情绪来为自己的权力和行为辩护。（

20 世纪初的中国知识分子独立地得出了与韦伯类似的结论，把儒教看作是中国落后的根源。20 世纪末中国的政治领袖像西方的社会学家一样，赞美儒教是中国进步的根源。

华人领导人无论想要为专制主义还是为民主制辩护，他们都从其共同的中华文化而不是从引进的西方观念中寻求合法性。

尽管明治维新时的日本人采取了“脱离亚洲加入欧洲”的政策，20 世纪末文化复兴时的日本人却赞成“疏远美国加入亚洲”的政策。（

鉴于第二次世界大战后日本与中国相比更认同于西方，又鉴于无论西方怎样衰落，它也不会像苏联那样完全垮台，日本完全摒弃西方的动力远不及中国脱离苏联和西方模式的动力那么大。

中国的一位持不同政见者说，其核心是“儒教的价值体系、历史使它增光，该地区的大多数国家都接受它”，特别是它强调节俭、家庭、工作和纪律。同样重要的是它们都摒弃个人主义，盛行“软”独裁或非常有限的民主形式。

强大的社会是普世的，弱小的社会是狭隘的。东亚日益增长的自信导致了亚洲普世主义的出现，而普世主义一直是西方的特征。

另一位伊斯兰教著名学者阿里·希罗·迪斯苏基也发表了类似的看法。他认为复兴运动包括：重新确立伊斯兰教法以代替西方法律，越来越多地使用宗教语言和标志，扩大伊斯兰教教育（表现在伊斯兰教学校的大量增多和国立学校课程的伊斯兰化），更多的人遵守伊斯兰教关于社会行为的法规（例如，妇女必须蒙面、禁酒），更多地参加宗教仪式，伊斯兰教组织控制了穆斯林社会中反世俗政府的活动，以及广泛地加强伊斯兰教国家和社会的国际团结。（

就政治表现而言，伊斯兰复兴运动与马克思主义有某种相似之处，它有其经文，是对理想社会的描述，执著于根本的变革，拒绝现行政权和民族国家，以及有从温和的改良主义到暴力革命的不同主张。然而另一个更有用的类比是基督教新教改革。它们都是对现存体制僵化和腐朽的反应；都提倡回复到其更纯正和更苛求的宗教形式；都鼓吹工作、秩序和纪律；都对正在形成的、有生气的中间阶级有吸引力。

基督教改革和伊斯兰复兴运动的核心精神都是根本的改革。

伊斯兰教复兴运动在一个关键方面与基督教改革不同。后者的影响在很大程度上局限于北欧；总的来说，它在西班牙、意大利、东欧和哈布斯堡王朝的领土上几乎没有取得进展。相比之下，伊斯兰教复兴运动遍及了几乎所有穆斯林社会，从 20 世纪 70 年代开始，伊斯兰教的标志、信仰、习俗、体制、政策和组织就赢得了从摩洛哥到印度尼西亚，从尼日利亚到哈萨克斯坦的全世界 10 亿穆斯林当中越来越多的信奉和支持。

到 20 世纪 80 年代初，最大的一个名叫穆罕默迪亚（Muhhammadijah）的拥有 600 万名成员的组织，组成了一个“世俗国家内部的宗教福利国家”，并通过一个精心建立的包括学校、诊所、医院和大专院校的网络，为全国提供“从摇篮到坟墓”的服务。

伊斯兰主义积极分子“可能包括受过最好教育的、最聪明的各类年轻人中多得不成比例的数量”，包括医生、律师、工程师、科学家、教师和公务员。（

未来若干年里，穆斯林人口中年轻人口多得将不成比例，十几岁和二十几岁的人口出现了引人注目的激增（图 5.2）。此外，这个年龄组的人将大部分是城市人口，并且至少受过中等教育。

首先，青年人是反抗、不稳定、改革和革命的主角。历史上，存在着大批年轻人的时期往往与发生这类运动的时期重合。

伊斯兰青年在伊斯兰教复兴中打上了自己的印记。

任何社会都不能无限期地维持两位数的经济增长，亚洲经济的繁荣将于 21 世纪初的某个时间稳定下来。

同样，任何宗教复兴或文化运动都不会无限期地持续下去，在某一时刻伊斯兰复兴运动将平息或消失在历史中，如果为其提供人力的人口推动力在 21 世纪的前 20 和 30 年减弱，那它就极有可能发生。

力量的增强将促使亚洲在国际事务中继续维护自己的权力，并努力以与西方不同的方式指导全球趋势，脱离西方的模式和规则而重塑国际体制。

然而，在新的世界中，文化认同是一个国家结盟或对抗的主要因素。尽管一个国家在冷战中可以避免结盟，但它现在不可能没有认同。“

文化认同的答案确定了该国在世界政治中的位置、它的朋友和它的敌人。

三个较小的华人地区和国家——台湾地区、香港地区、新加坡，以及东南亚的海外华人团体越来越倾向于、介入或依赖于中国大陆。朝鲜和韩国虽然犹犹豫豫但还是有意走向统一。

美国与加拿大力图把墨西哥拉入北美自由贸易协定，这一协定的长期成功很大程度上依赖于墨西哥是否能够在文化上重新确认它属于北美而不是属于拉丁美洲。

政治和经济联盟会与文化和文明的联盟永远相一致吗？当然不会。均势的考虑有时会导致跨文明的结盟，例如，当法国国王弗兰西斯一世联合奥斯曼土耳其人对抗哈布斯堡王朝的时候，情况就是这样。

缺少一个伊斯兰核心国家，给伊斯兰社会和非伊斯兰社会都构成了重大的问题，

但是，文明之间在政治和经济发展方面的重大差异显然植根于它们不同的文化之中。东亚经济的成功有其东亚文化的根源，正如在取得稳定的民主政治制度方面东亚社会所遇到的困难有其文化根源一样。伊斯兰文化在很大程度上解释了为什么民主未能在大部分伊斯兰世界中出现。后共产主义的东欧社会和苏联的发展受到了其文明认同的影响。那些具有西方基督教遗产的国家正在取得经济发展和民主政治的进步；东正教国家的经济和政治发展前景尚不明朗；而各穆斯林共和国的前景则很暗淡。

至于拉丁美洲，西班牙本可以成为一个讲西班牙语的文明或者甚至伊比利亚文明的核心国家，但它的领导人有意识地选择成为欧洲文明的成员国，尽管同时与其前殖民地保持着文化上的联系。

然而，巴西之于拉丁美洲犹如伊朗之于伊斯兰教。亚文明的差异（与伊朗的宗教差异，与巴西的语言差异）使它们很难担当这个角色。如果没有这些差异，它们完全有资格成为核心国家。

鉴于墨西哥试图重新确定自己的认同，从拉丁美洲转向北美，智利和其他国家可能紧随其后，拉丁美洲的情况也因此而复杂化。拉丁美洲文明最终可能融入西方文明并成为分成三支的西方文明的一个亚文明。

在很大程度上，法语非洲的核心国家是法国，它在非洲国家独立后，与其前殖民地保持着密切的经济、军事、政治的联系。

南非通过协商和平地实现了从种族隔离体制的过渡，其工业能力、与其他非洲国家相比高水平的经济发展，其军事能力、自然资源，以及黑人和白人共同担任政治领导的周密体制，都明显地使南非成为南部非洲的领导，也许还是英语非洲的领导。

一个孤独的国家在文化上缺乏与其他社会的共同性。例如，埃塞俄比亚在文化上是孤立的，原因在于它占主导地位的语言阿姆哈拉语、它的占主导地位的宗教科普特（基督一性论）东正教、它的帝国历史，以及它与周围民族（其中大部分是穆斯林）的宗教差别。

最重要的孤独国家是日本，没有其他国家具有与之相同的独特文化，

俄罗斯自彼得大帝起就一直是一个无所适从的国家，在它是西方文明的一部分还是独特的欧亚东正教文明核心的问题上发生了分歧。

如果土耳其或墨西哥成功地把自己重新定位为西方文明的成员，这对于伊斯兰文明或拉美文明的影响可能会很小或者比较有限。而如果俄罗斯成为一个西方国家，东正教文明将不复存在。苏联的崩溃又在俄罗斯人中点燃了关于俄罗斯与西方这一中心问题的争论。

俄罗斯没有或很少经历过以下这些界定西方文明的历史现象：罗马天主教、封建主义、文艺复兴、宗教改革、海外扩张和殖民化、启蒙运动以及民族国家的出现。以前被认为是西方文明八个特征之中的七个——宗教、语言、政教分离、法治、社会多元化、代议机构、个人主义——几乎完全与俄罗斯的经历无缘。然而，唯一可能的例外是希腊、罗马古典遗产，它是经过拜占庭传到俄罗斯的，因而与从罗马直接传到西方的有相当大的不同。

与奥斯曼帝国形成对照的是，俄罗斯帝国逐渐被看作是欧洲国际体系的一个主要的和合法的参与者。在国内，彼得的改革带来了一些变化，但他的社会仍然是混合的，除了一小部分精英外，亚洲和拜占庭的方式、体制和信仰在俄罗斯社会仍居主导地位，对此，欧洲人和俄罗斯人均这样认为。

彼得建立了一个无所适从的国家，19 世纪，斯拉夫主义者和主张西方化者都为这个不幸的国家而痛惜，并在究竟是通过彻底欧洲化，还是通过消除欧洲的影响，恢复俄罗斯的精粹来结束这种局面的问题上，发生了激烈的争论。

布尔什维克革命开创了俄罗斯与西方关系的第三阶段，它与存在了两个世纪的含糊不清的前一阶段大不相同。它以一种在西方创立的意识形态的名义建立起不能存在于西方的政治经济制度。斯拉夫主义者和西方化论者曾经争论，如果与西方相比俄罗斯不落后，那么俄罗斯是否可能不同于西方；共产党人出色地解决了这一问题：俄罗斯不同于西方而且根本反对西方，因为它比西方更先进，它要在最终将席卷全世界的无产阶级革命中起领导作用，俄罗斯体现的不是落后的亚洲的过去，而是进步的苏维埃的未来。

然而，共产主义在使苏联领导人把自己与西方区分开来的同时，也使他们与西方建立了强有力的联系。马克思和恩格斯是德国人，19 世纪末和 20 世纪初，他们观点的大多数主要阐释者都是西欧人。

布尔什维克革命后，欧洲左翼政党分裂成为共产党和社会党，两者常常都是欧洲社会中的强大力量。在大部分西方国家里，马克思主义的观点很流行，共产主义和社会主义被视为未来的趋势，并以这种或那种方式得到了政治精英和知识精英的广泛拥护。

然而，土耳其与西方结盟，体现在其北约成员国的地位上，它是冷战的产物。冷战的结束消除了两者结盟的基本理由，并导致这种联系的减弱和被重新界定。

在那场战争中，土耳其关闭伊拉克石油到达地中海必经的土耳其境内的输油管，以及允许攻击伊拉克的美国飞机从土耳其的军事基地起飞，从而为反萨达姆·侯赛因的联盟提供了关键的帮助。然而，由奥扎尔总统作出的这些决定在土耳其国内激起了轩然大波，并导致土耳其外交部长、国防部长和总参谋长的辞职，以及抗议奥扎尔与美国的密切合作的大规模示威游行。

土耳其与西方合作对付来自南方的伊斯兰威胁的意愿，跟它与西方一起抵抗苏联的威胁的意愿相比，不那么肯定。在海湾危机中，土耳其的一个传统盟友德国反对将伊拉克对土耳其的导弹攻击视为对北约的攻击，此事也表明，土耳其在对付来自南方的威胁时不能指望西方的支持。

私下里，欧洲人和土耳其人都承认，真正的理由是由于希腊人的强烈反对，更重要的是，土耳其是一个穆斯林国家。欧洲国家不想面对自己开放边境后可能从一个拥有 6000 万穆斯林和大量失业入口的国家涌入移民的景象。尤其重要的是，他们感到在文化上，土耳其不属于欧洲。

一个观察家评论道，欧洲人的一个“隐秘的梦魇”是对“撒拉逊人（即阿拉伯人）入侵西欧和土耳其人直叩维也纳城门”的历史记忆。反过来，这种态度导致了“土耳其人的一个共识”，即：“西方没有在欧洲为穆斯林的土耳其留下一席之地。”（

在抛弃麦加又被布鲁塞尔抛弃后，土耳其抓住了苏联解体的机会，转向塔什干。

土耳其重新倾向高加索和中亚，不仅是被充当突厥语族各国共同体的领袖的梦想所激发，也是出于抗衡伊朗和沙特阿拉伯在这些区域扩大的影响、防止鼓动伊斯兰原教旨主义的需要。

面对伊斯兰情绪的增长，土耳其统治者试图采纳原教旨主义的做法并接受原教旨主义者的支持。

从 20 世纪 30 年代到 80 年代，墨西哥领导人一直执行向美国利益挑战的经济和外交政策。20 世纪 80 年代，一切都发生了变化。米格尔·德拉马德里总统和他的继任者卡洛斯·萨利纳斯总统对墨西哥的目标、实践和认同重新进行了全面的界定，这是 1910 年革命以来最广泛的变革努力。

正如某些墨西哥人所极力主张的，墨西哥可以努力与西班牙、葡萄牙及南美洲国家建立一个伊比利亚国家联盟。

墨西哥与美国之间的文化差距远远小于土耳其与欧洲之间的差距。

然而，20 世纪 90 年代初，澳大利亚的领导人实际上决定，澳大利亚应当脱离西方，把自己重新确定为亚洲社会，并与它的地缘上的邻国建立紧密的联系。保罗·基廷总理宣布，澳大利亚不再是“帝国的一个分部”，它必须成为一个共和国，其目标必须是“融入”亚洲，他认为，为确立作为一个独立国家的认同，这是必要的。“

正如马哈蒂尔所暗示的，亚洲人一般是以微妙的、间接的、调解的、迂回曲折的、非评判的、非道德的、非对抗的方式与其他人一起来追求他们的目标。而澳大利亚人是英语世界中最直截了当、开门见山、毫不隐讳的民族，有人可能会说他们是一个不敏感的民族。

当人们普遍关注欧洲联盟和北约的扩大时，这两个组织的文化重构亦引起了它们可能引起的缩小问题。一个非西方国家希腊，是这两个组织的成员国；另一个非西方国家土耳其是北约的成员国，它正在申请加入欧洲联盟。这些关系是冷战的产物，它们在冷战后的文明世界里还站得住脚吗？

历史上，希腊人在反对土耳其人时，把自己看作基督教的先锋；与塞尔维亚人、罗马尼亚人或保加利亚人不同，希腊的历史与西方的历史紧密交织在一起。然而希腊也是一个异常的国家，是西方组织中的东正教局外者。

随着苏联的终结和共产主义威胁的消失，希腊和俄罗斯在反对它们共同的敌人土耳其这一点上有了共同的利益，它允许俄罗斯在希腊族人控制的南塞浦路斯建立重要的军事存在，由于“他们共同信奉东正教”，希腊族人既欢迎俄罗斯人又欢迎塞尔维亚人到他们的岛上来。（

希腊的整个外交政策都带有浓厚的东正教倾向。毫无疑问，希腊将仍然是欧洲联盟和北约的一个正式成员。然而，随着文化重构过程的加强，它的这些成员资格无疑将变得更加脆弱，意义更小，给有关方面带来更大的困难。

除国名外，到 1995 年，白俄罗斯事实上已经成为俄罗斯的一部分。

格鲁吉亚在 1801 年以前曾是一个独立的国家，那年其统治者国王乔治十三请求俄罗斯人保护，以防范土耳其人。

在历史上的不同时期里，乌克兰都曾经独立过，然而在近代大部分时间里，它是莫斯科统治的政治实体的一部分。决定性的事件发生在 1654 年，当时反抗波兰统治的哥萨克起义领袖博赫丹·赫麦尔尼茨基同意向沙皇效忠以换取俄罗斯帮助哥萨克反对波兰人。从那时到 1991 年，除 1917 年至 1920 年的短暂独立外，乌克兰在政治上一直受莫斯科控制。然而乌克兰是一个具有两种文化的分裂的国家，西方与东正教之间的文明断层线贯穿了它的中心地带，几个世纪以来一直如此。

过去，西乌克兰有时是波兰、立陶宛和奥匈帝国的一部分。它的绝大部分人口是东仪教的信徒，他们实行东正教礼拜式，但承认罗马教皇的权威。

另一方面，东乌克兰人绝大多数信奉东正教，而且很大一部分人讲俄语。20 世纪初，俄罗斯人在乌克兰全部人口中占 22％，土生土长的讲俄语的乌克兰人占 31％。

克里米亚人口的绝大多数是俄罗斯人，直到 1954 年克里米亚一直是俄罗斯联邦的一部分，那一年，赫鲁晓夫把它并入乌克兰，其借口是承认 300 年前赫麦尔尼茨基的决定。

第二种可能性，在某种程度上也许更为可能的是，乌克兰沿着文明断层线分裂成两个相互独立的实体，其东部可能与俄罗斯融合。分离问题首先始于克里米亚。

第三种、也更有可能出现的局面是，乌克兰仍将是一个统一的、充满裂痕的、独立的国家，并且总体上与俄罗斯密切合作。

中国政府把中国大陆看作是中华文明的核心国家，所有其他华人社会都应倾向于它。

对中国政府来说，所有的炎黄子孙，即便是另一个国家的公民，都是中华共同体的成员，因此在某种程度上应服从中国政府的权威。

除了日本和韩国外，东亚经济基本上是华人经济。

在中国，信任和承诺取决于私交，而不是契约或法律和其他法律文件。西方商人发现在印度做生意比在中国做生意要容易，因为在中国协议的可靠性依赖双方的私人关系。

在中亚，历史上国家认同并不存在。“忠诚是对部落、部族和扩大的家庭而言，而不是对国家”。在另一个极端，人们确实有共同的“语言、宗教、文化和生活方式”，“伊斯兰教是人们中间最强大的统一力量，比埃米尔（酋长）的权力还要大”。

在阿拉伯世界中，现存国家的合法性颇成问题，因为它们大多数是欧洲帝国主义任意（即便不是反复无常地）制成的，它们的边界甚至常常与种族集团的界线不一致，如柏柏尔人和库尔德人就被分隔在不同的国境内。

此外，民族国家的主权思想与安拉具有最高权力和伊斯兰信仰至上的思想不相容。

奥斯曼帝国的灭亡使伊斯兰世界失去了核心国家。它的领土在相当大的程度上被西方列强瓜分，列强撤退时，在这些领土上留下了一些脆弱的国家，它们建立在不同于伊斯兰传统的西方模式之上。

然而穆斯林中 90％是逊尼派，而伊朗是什叶派；作为伊斯兰的语言，波斯语的地位远逊于阿拉伯语；况且，波斯人和阿拉伯人历史上一直势不两立。

巴基斯坦具有面积、人口和军事技术的条件，它的领导人不断试图扮演伊斯兰国家合作促进者的角色，并充当伊斯兰世界对世界其他国家的发言人。然而，巴基斯坦相对贫穷，深受内部严重的种族和宗教分裂的困扰，有政治不稳定的记录，关注与印度的安全问题。

沙特阿拉伯是伊斯兰教最初的家园，伊斯兰教最神圣的圣地都在那儿，它的语言是伊斯兰的语言；它有世界上最大的石油储量和随之而来的金融影响；它的政府严格按伊斯兰原则塑造了沙特社会。

但另一方面，由于它的人口相对较少，地理位置易受攻击，因而在安全上依赖于西方。

土耳其拥有成为核心国家的历史、人口、中等水平的经济发展、民族凝聚力、军事传统和军事技术等条件。然而，它明确地把自己界定为一个世俗社会。

那么，假如土耳其重新给自己定位呢？在未来的某一时刻，土耳其可能乐于放弃它像乞丐一样恳求加入西方的令人沮丧和羞辱的角色，恢复它作为伊斯兰世界与西方主要对话者和对抗者的令人印象深刻的、更高雅的历史角色。

西方人眼中的普世主义，对非西方来说就是帝国主义。

非西方人还会毫不犹豫地指出西方的原则及其行为之间的差距。坚持普世主义的代价，就是被指责为伪善、实行双重标准和“例外”原则。民主要提倡，但如果这将使伊斯兰原教旨主义者上台执政，就该另当别论；防止核扩散的说教是针对伊朗和伊拉克的，而不是针对以色列的；自由贸易是促进经济增长的灵丹妙药，但不适用于农业；人权对中国是个问题，对沙特阿拉伯则不然；对石油拥有国科威特的入侵被大规模地粉碎，但对没有石油的波斯尼亚的入侵则不予理睬。实践中的双重标准是推行原则的普遍标准所无法避免的代价。

伊斯兰国家和中国拥有与西方极为不同的伟大的文化传统，并自认其传统远较西方的优越。在与西方的关系中，随着其实力和自我伸张性的增强，它们与西方在价值观念和利益方面的冲突日益增多和加剧。

伊斯兰文明和中华文明在宗教、文化、社会结构、传统、政治和植根于其生活方式的基本观念上，存在着根本的不同。从根本上来说，这两者之间具有的共性可能还不及它们各自与西方文明之间的共性。但是在政治上，共同的敌人将产生共同的利益。伊斯兰社会和华人社会都视西方为对手，因此它们有理由彼此合作来反对西方，甚至会像同盟国和斯大林联手对付希特勒一般行事。

限制非西方国家移民或难民的入境人数，以保护西方社会的文化、社会和种族的完整。

整个非西方世界的政治领袖和军事将领们都牢牢地记住了这一教训，因为他们有一个似乎合理的推论：“如果你拥有核武器，美国就不会对你开战。”

对于西方来说，核武器在冷战后的世界所起的作用与冷战期间的作用正相反。

冷战期间美国出于威慑目的而拒绝宣布放弃首先使用核武器。

1993 年俄罗斯宣布放弃苏联不首先使用核武器的承诺。

恐怖主义和核武器分别是非西方的弱国手中的武器。一旦这两者结合在一起，非西方的弱国就会变得强大起来。

武器扩散一直是儒教—伊斯兰教联系的最为密切和具体之处。中国在向伊斯兰国家转让常规武器和非常规武器方面起了主要作用，这些转让包括：在阿尔及利亚沙漠中建造一座防备严密的秘密核反应堆，表面上它是用于研究的，但西方专家们普遍认为它具备生产钚的能力；向利比亚出售化学武器原料；向沙特阿拉伯提供 CSS—2 中程导弹；向伊拉克、利比亚、叙利亚和朝鲜提供核技术或原料；向伊拉克提供大量的常规武器。

儒教—伊斯兰教军事联系的中心环节是以中国和在较小程度上还有朝鲜为一方，以巴基斯坦和伊朗为另一方之间的关系。1980—1991 年，中国武器的两个主要接受国是伊朗和巴基斯坦，其次是伊拉克。自 20 世纪 70 年代起，中国和巴基斯坦之间发展了异常密切的军事关系。

到 20 世纪 90 年代，中国和伊朗之间的武器联系也变得紧密起来。在 80 年代的两伊战争中，中国向伊朗提供了其武器的 22％，并在 1989 年成为伊朗最大的武器供应者。

1992 年 9 月，拉夫桑贾尼总统在伊朗核专家的陪同下访问了巴基斯坦，然后去中国签署了另一个核合作协议。1993 年 2 月，中国同意在伊朗建设两座 300 兆瓦的核反应堆。在执行这些协议时，中国向伊朗提供了核技术和核情报，帮助伊朗培训科学家和工程师，并向伊朗提供卡留管（ca—lutron）浓缩装置。

巴基斯坦为伊朗培训科学家，巴基斯坦、伊朗和中国于 1992 年 11 月达成了联合进行核项目的协议。（

这些事态发展和它们对西方利益构成的潜在威胁，使得大规模杀伤性武器的扩散问题成为西方安全议程的首要问题。

在冷战后的世界，主要的军备竞赛却是另一种类型。西方的对手试图获得大规模杀伤性武器，西方则试图阻止它们。

西方的抑制努力可以减缓其他社会增强军事能力，却不能阻止它们。

西方提倡核不扩散符合世界所有国家维护国际秩序和国际稳定的利益。然而，其他国家却认为，核不扩散是为了维护西方的霸权利益。

许多韩国人将朝鲜的核弹视为“朝鲜的”核弹，也就是说它永远不会被用来攻击其他的朝鲜人，而可能用来保卫朝鲜的独立和利益以对抗日本和其他的潜在威胁。韩国的文武官员们明确地希望组成一个具备核能力的统一的朝鲜。

结果，美国和韩国之间的明显重大分歧达到了这一程度：1994 年，华盛顿认为朝鲜半岛出现了严重危机。但汉城却没有任何严重危机感，这造成了两个首都之间的“惊人差异”。

美国的安全利益和南亚国家的利益之间也存在着同样的差距，美国对那里核武器扩散的关切更甚于该地区的居民。印度和巴基斯坦更容易接受彼此的核威胁，而难以接受美国遏制、减轻或消除来自这两个国家核威胁的建议。（

美国和朝鲜就核问题达成的协议可被恰当地称为“有条件的投降”，而美国在人权问题上向中国和其他亚洲国家屈服，则是无条件的投降。

亚洲国家将西方的压力视为对其主权的侵犯，当出现这些问题时便会团结在一起相互支持。

日本政府通常与美国的人权政策保持距离。在天安门事件发生后不久，日本首相宫泽喜一说：我们不会让“抽象的人权观念”影响日本与中国的关系。

如果人口分布是天定的，那么人口流动便是历史的发动机。

1821 至 1924 年间，大约有 5500 万欧洲人移居海外，其中 3400 万到了美国。西方人征服、有时甚至消灭了其他民族，开发了人口密度较低的土地并定居下来。

直至 20 世纪 70 年代，欧洲国家普遍赞同移民，有些国家，特别是德国和瑞士，还鼓励移民的流入以弥补劳动力的短缺。

然而在 80 年代末，高失业率、移民人数的增长和移民占压倒优势的“非西方”特性，使得欧洲人的态度和政策发生了急剧的变化。几年之后，出于同样的考虑，美国人的态度也出现了类似的变化。

1550 万人生活在欧洲，800 万人生活在澳大利亚和加拿大。在欧洲主要国家中，移民人数占总人口的比例达到了 7％—8％。

新移民绝大部分来自非西方国家。在德国，1990 年有土耳其移民 167.5 万人，其次最大的移民群来自南斯拉夫、意大利和希腊。在意大利，主要的移民来自摩洛哥、美国（据信大量的意大利裔美国人返回了家园）、突尼斯和菲律宾。

美国人口的自然增长率很低，欧洲的自然人口增长率实际上为零。由于移民的生殖率高，因而他们将占西方国家未来增长人口的大部分。

20 世纪 90 年代初，在欧洲的移民中有三分之二是穆斯林。在移民问题中，欧洲人最为关切的是穆斯林移民。

穆斯林社群，不论是德国的土耳其人还是法国的阿尔及利亚人，都没有融入所在国的文化，而

然而，从任何严格意义上说，法国人更是文化主义者，而不是种族主义者。他们的立法接受了可以讲完美法语的黑非洲人，但是他们不能接受在校园里蒙着头盖的穆斯林姑娘。

在西欧，指向阿拉伯人的排外主义，已在很大程度上取代了指向犹太人的反犹太主义。

一位评论家在 1994 年说道：“很多美国人，也许是大多数美国人，仍然将他们的国家视为欧洲人定居的国家，因为他们继承了英国的法律，语言是（并将继续是）英语，他们的体制和公共建筑从西方的古典形式中获得了启发，他们的宗教具有犹太教—基督教本源，他们的伟大源于新教的伦理原则。”在被抽样调查的人中，有 55％的人认为移民是对美国文化的威胁，便反映了这些担忧。

总的说来，欧洲社会并不愿同化移民，这样做亦存在极大的困难，而且穆斯林移民和他们的子女愿意被同化的程度也不得而知。因此，持续的大量移民很可能使国家分裂成基督教和穆斯林两个群体。

有证据显示，墨西哥移民对同化的抵制要比其他移民群体更为强烈，他们倾向于保持自己的墨西哥认同，

墨西哥移民定居的地区是 19 世纪中叶在美国打败墨西哥后为美国所吞并的。

正如修昔底德所指出的，在希腊文明中，雅典力量的增强导致了伯罗奔尼撒战争。

中国的崛起则是核心国家大规模文明间战争的潜在根源。

伊斯兰教和基督教（不论是东正教，还是天主教和新教）的关系经常充满风暴，彼此将对方视为外人。自由民主主义和马克思列宁主义在 20 世纪的冲突，与伊斯兰教和基督教之间持续的、深刻的冲突关系相比较，不过是一种短暂和表面的历史现象。

伯纳德·刘易斯说道：“在将近一千年的时间里，从摩尔人首次在西班牙登陆到土耳其人第二次围攻维也纳，欧洲不断处于伊斯兰威胁之中。”（注 3）伊斯兰文明是唯一使西方的存在受到过威胁的文明，而且这种情况至少发生过两次。

一方面，冲突是差异的产物，特别是穆斯林的伊斯兰教观念作为一种生活方式超越并结合了宗教和政治，而西方基督教则持有政教分离的观念。然而，冲突也产生于它们的相似性。这两种宗教都是一神教，与多神教不同，它们不容易接受其他的神；它们都用二元的、非我即彼的眼光看待世界；它们又都是普世主义的，声称自己是全人类都应追随的唯一真正信仰；它们都是负有使命感的宗教，认为其教徒有义务说服非教徒皈依这唯一的真正信仰。

圣战”和“十字军东征”这两个类似的概念不仅令它们彼此相像，而且将这两种信仰与世界其他主要宗教区别开来。伊斯兰教、基督教和犹太教还持有一种目的论的历史观，与其他文明普遍持有的轮转或静态观完全不同。

鉴于穆斯林和西方相互的普遍看法，以及伊斯兰极端主义的兴起，伊斯兰和西方在 1979 年伊朗革命之后展开文明间的准战争便不足为怪了。

此外，双方实际上都将这种冲突视为战争。霍梅尼早先曾非常准确地说过：“伊朗实际上是在与美国打仗。”（注 15）卡扎菲则定期宣布对西方进行圣战。

在西方阵营，美国将 7 个国家列为“恐怖主义国家”，其中有 5 个是穆斯林国家（伊朗、伊拉克、叙利亚、利比亚、苏丹），另外 2 个是古巴和朝鲜。

从军事角度看，它在很大程度上是一场恐怖主义对空军的战争。奋勇的伊斯兰斗士利用西方的开放社会，向所选择的目标放置汽车炸弹；西方的职业军人则利用伊斯兰国家的开放天空，向所选择的目标投放高精确度的炸弹。

然而，这场战争的参与者相互使用的暴力手段，均超过了美国和苏联在冷战中相互直接使用的手段。除个别例外，冷战期间两个超级大国都不曾有目的地杀害对方的平民，甚至军事人员，但这种情况在准战争中屡屡发生。

在穆斯林国家从未发生过对反西方暴力行动的抗议。穆斯林国家的政府，甚至与西方友好、依赖西方并陷入了困境的政府，在谴责反西方的恐怖行动时也作了令人惊讶的保留。

西方面临的根本问题不是伊斯兰原教旨主义，而是一个不同的文明——伊斯兰，它的人民坚信自身文化的优越性，

除了中国的霸权在历史上有时曾给该地区带来暂时的秩序外，在东亚从未存在过西欧有过的国际社会（按照英国人的概念）。（

同样与西欧形成对照的是，在东亚国家中存在着许多孕育着冲突的种子。两个被广泛确认的危险点包括两个朝鲜和“两个中国”，它们均是冷战的遗产。

朝鲜人打朝鲜人的可能性尽管存在，但是不大；中国人打中国人的可能性稍大，但也有限，除非台湾人放弃自己的中国身份，正式成立独立的“台湾共和国”。

尽管 20 世纪 90 年代中期在东亚存在着国家间的和平，但是在此之前的 50 年间在朝鲜和越南发生了重大战争，而且亚洲的主要大国中国，曾经同美国人和它几乎所有的邻居，包括韩国人、越南人、国民党中国人和俄罗斯人打过仗。

20 世纪 90 年代初，日美关系由于在许多问题上的争议而变得日益紧张，这些问题包括：日本在海湾战争中的作用、美国在日本的驻军、日本对美国针对中国和其他国家的人权政策的态度、日本参与维和行动，以及最重要的经济关系，特别是贸易问题。

至 1995 年，据说在中国领导人和学者之间存在着一种广泛的看法：美国正企图“在领土上分裂中国，在政治上颠覆中国，在战略上遏制中国，在经济上挫败中国”。（

此外，美国如果任其与亚洲两个主要国家的关系同时变得更紧张，显然于其国家利益不利。按照外交和强权政治的基本原则，美国应当利用两者中的一方去反对另一方，或者至少在与一方的冲突加剧之时，设法改善与另一方的关系。但是美国并没有这样做。

在最广泛的层面上，盛行于众多亚洲社会的儒家精神强调这样一些价值观：权威，等级制度，个人权利和利益居次要地位，一致的重要性，避免正面冲突，“保全面子”，以及总的说来，国家高于社会，社会高于个人。

团结的另一个表现是：亚洲、非洲和其他国家不顾西方的反对而站在日本一边，支持日本在任的世界卫生组织的领导人当选连任，而日本又反对美国提出的候选人——墨西哥前总统卡洛斯·萨利纳斯，而推举一位韩国人做世界贸易组织的领导。记录无可争议地表明，到 20 世纪 90 年代，在泛太平洋的问题上，所有东亚国家都认为，它们与其他东亚国家要比与美国有更多的共同点。

中国不愿接受美国在世界上的领导地位或霸权；美国也不愿接受中国在亚洲的领导地位或霸权。

另一种可能性是，东亚政治为中国和日本或中国和美国两极之间持久的对抗所主宰，其他国家或者与一方结盟，或者采取不结盟政策。

还可以设想，东亚政治可能回到传统的单极模式，以中国为中心形成权力等级。如果中国在 21 世纪能保持高速的经济增长，在邓小平以后的时代保持统一，不因争夺继承权的斗争而瘫痪，那么它可能争取实现这最后一种可能。

中国的历史、文化、传统、规模、经济活力和自我形象，都驱使它在东亚寻求一种霸权地位。这个目标是中国经济迅速发展的自然结果。

除个别例外（如在南中国海），中国在东亚的霸权不大可能以直接付诸武力的方式扩大其对领土的控制。

李光耀于 1994 年说：“中国参与世界地位重组的规模，使得世界必须在 30 或 40 年的时间内找到一种新的平衡。假装中国不过是另一个大的参与者是不可能的，它是人类历史上最大的参与者。”（

广义地讲，对于新的大国的崛起，各国可作出一种方法或者两种方法相结合的反应。它们可以独自或与其他国家结成联盟，通过用均势来平衡和遏制中国，以及在必要的情况下通过战争打败它，来保证自身的安全。另一种反应是，各国可以尝试搭乘这个新崛起的大国的车，适应它，在与它的关系中处于次要的或从属的地位，以期它们的核心利益得到保护。

根据西方国际关系理论，用均势来平衡通常是更理想的选择，而且事实上也比搭车被更频繁地采用。

此外，正如沃尔特所言，搭车确实需要在一定程度上相信这个力量更强大的国家不怀恶意。

然而，最大的危险乃是美国将不作明确的选择，在未经认真考虑它的做法是否符合自己的国家利益，并在没有作好有效进行战争准备的情况下，便卷入一场与中国的战争。

欧洲各社会经历了一个绝对君主制的阶段，但避免了亚洲国家历史上特有的持续的官僚帝国或“东方专制国家”的出现。

历史上，中国人并未明确地区分国内和国外事务。他们“头脑中的世界秩序不过是中国国内秩序的必然结果，因此是中国文明认同的一种延伸”，他们假定这种认同“能够在正常的宇宙秩序这个更大的可扩展的同心圆中再现自身”。

在 19 世纪中叶西方国家到来之前，东亚的国际关系是以中国为中心的，其他国家要么从属于北京，要么与之合作，或者不受北京控制而自治。（

在 20 世纪 90 年代，除中国和朝鲜外，实际上所有的东亚国家都对美国继续在该地区驻军表示了支持。然而在实践中，除越南外，这些国家都倾向于顺应中国。

中国的崛起将对日本构成重大的挑战，日本人在应当采取什么样的应付战略上将产生严重分歧。

用均势来平衡和遏制中国的任何有意义的努力，其核心必定是美日军事联盟。

如果美国不承担主要义务或未表现出重大决心，日本很可能会顺应中国。历史上，日本往往与有关的支配力量结盟以寻求自身的安全，仅有 20 世纪 30 年代和 40 年代是例外，当时它在东亚推行单边的征服政策，结果遭到惨败。

因此，日本的结盟行为“基本上是搭车而不是均势”，并且总是“与支配力量结盟”。（

一位在日本居住多年的西方学者说：日本人“比大多数人都会更快地向不可抗拒的力量卑躬屈膝，并与被认为在道德上占有优势者合作……也会最快地怨恨道德上软弱和正在退却的霸主滥用权力”。

随着美国对亚洲事务参与的减少，日本国内敦促日本“重新亚洲化”的势力将得到加强，日本将承认中国在东亚舞台上重新占据优势是不可避免的。

中国的霸权将减少东亚的不稳定性和冲突。它也会削弱美国和西方在那里的影响，迫使美国接受它在历史上曾经试图防止的事情：世界上的一个关键地区由另一个大国所主宰。

但更为可能的是，亚洲的过去将是亚洲的未来。亚洲要在以冲突为代价的均势或以霸权为代价的和平之间作出选择。西方社会可能会选择冲突和均势。历史、文化和力量的现实却强烈地显示，亚洲会选择和平和霸权。

在德黑兰，人们认为，“当代世界的独特性”要求伊朗、中国、巴基斯坦和哈萨克斯坦进行“紧密和持续的合作”。至 20 世纪 90 年代中期，一个近乎于事实上的联盟已经在这三个国家中间存在，该联盟的基础是反对西方、在安全问题上对印度的关注以及抗衡土耳其和俄罗斯在中亚的影响。（

至 20 世纪 90 年代中期，一个近乎于事实上的联盟已经在这三个国家中间存在，该联盟的基础是反对西方、在安全问题上对印度的关注以及抗衡土耳其和俄罗斯在中亚的影响。（

基督教徒和犹太教徒在说：我们原先是决心摧毁共产主义，而西方现在必须摧毁伊斯兰教和儒教。现在我们希望看到，以中国为首的儒教阵营和以美国为首的基督教十字军阵营之间发生对抗。我们没有理由不对十字军的参加者持有偏见。我们和儒教站在一起，与它结盟，和它在一条国际战线上并肩作战，我们将一同消灭我们共同的敌人。因此，作为穆斯林，我们将支持中国反对我们共同敌人的斗争……

然而，中国方面对反西方的儒教和伊斯兰教国家联盟的热情一直相当低落。江泽民主席 1995 年宣称，中国不会与任何国家结盟。这个立场或许反映了传统的中国观念，作为一个中央帝国，即中心国家，中国不需要正式盟友，而其他国家会发现与中国结盟符合它们的利益。

其他文明及其核心国家与西方及其挑战者之间的关系将会有极大的不同。缺少核心国家的南方文明，即拉丁美洲文明和非洲文明，一直依赖于西方，而且军事和经济力量相对软弱（尽管拉丁美洲在迅速改变这一状况）。

西方与非洲国家的关系仅会引起略微严重一些的冲突（主要原因是非洲的软弱），但也存在一些重要的问题。南非没有像巴西和阿根廷那样放弃发展核武器的计划，尽管它销毁了已拥有的核武器。

在拉丁美洲变得更西方化的同时，非洲却变得更非西方化。然而。二者都在以不同的方式继续依赖西方，除了在联合国的投票外，都无法对西方和其挑战者之间的均势产生决定性影响。

正如以上提到过的，日本经过一段时间极大的痛苦和自我反省可能疏远美国向中国靠拢。与冷战期间跨文明的其他盟友一样，日本与美国的安全纽带将削弱，尽管可能永远不会正式挑明这一点。

第三个“摇摆”的核心国家是印度，冷战期间它是苏联的盟国，与中国进行过一场战争，与巴基斯坦进行过几场战争。它与西方，特别是与美国的关系，即使不是龃龉相加，也是保持着一定距离。

“第一场文明之间的战争”，摩洛哥著名学者马哈迪·埃尔曼扎拉在海湾战争正在进行时这样称呼它。（注 1）事实上，这是第二场文明之间的战争，第一场是 1979—1989 年的苏联—阿富汗战争。

然而，对那些与苏联作战的人来说，阿富汗战争却是另外一回事。一位西方学者评论道：（注 2）它是“第一场不以民族主义或者社会主义原则为基础的胜利”，而是以伊斯兰原则为基础的抵抗外来侵略的胜利。

这场被西方人视为自由世界的胜利的战争，却被穆斯林视为伊斯兰的胜利。

苏联人最后被其不能有效地相比和抵消的三个因素所击败：美国的技术，沙特阿拉伯的金钱，以及穆斯林的人口和狂热。（

而海湾战争成为一场文明间的战争，则是因为西方在军事上干预了穆斯林的冲突，而绝大多数西方人又支持这种干预。这是世界各地的穆斯林将这种干预视为对他们发动的战争，因而联合起来反对他们所认为的西方帝国主义的又一例证。

虽然穆斯林国家政府之间最初就存在分歧，但绝大多数阿拉伯人和穆斯林的观点从一开始就是反西方的。

阿拉伯人和其他穆斯林普遍承认萨达姆·侯赛因可能是一个残忍的暴君，但是与当年罗斯福总统的看法相似，认为“他是我们的残忍暴君”。在他们看来，这次入侵是家庭事务，应当在家庭内部解决，而那些以夸夸其谈的世界正义的名义进行干涉的国家，不过是为了保护自己的私利，使阿拉伯国家继续从属于西方。

简言之，普遍的观点认为：萨达姆侵略是错误的，西方干涉更是错误的，因此萨达姆与西方作战是正确的，我们支持他也是正确的。

1990 年秋，坐落在麦加的伊斯兰大学校长萨法·哈瓦利在一盒于沙特阿拉伯广泛流传的录音带中说：这场战争“不是世界对伊拉克，而是西方对伊斯兰”的战争。

正如法蒂马·莫尼斯所指出的，布什总统经常以美国的名义祈祷上帝，更加强了阿拉伯人的这是“一场宗教战争”的看法，因为布什的话散发着“7 世纪伊斯兰教创教前游牧部落唯利是图的雇佣兵和后来的基督教十字军战士的臭味”。

正如萨法·哈瓦利所说：“那些伊拉克复兴党徒只是我们几个小时的敌人，而罗马直至世界末日一直是我们的敌人。”（注

战争还使伊拉克和伊朗开始相互妥协。伊朗什叶派宗教领袖谴责西方的干涉，号召对西方发动圣战。伊朗政府减少了针对伊拉克这个前敌人采取的措施，随着战争的结束，两个政权间的关系逐步改善了。

巴基斯坦从来没有如此团结过。在南方省份信德，当地人和印度移民在过去的 5 年里一直互相残杀，可是现在却肩并肩地示威游行反对美国。在西北边境极端保守的部落地区，在除了周五祈祷日人们从不聚会的地方，甚至连妇女都走上街头示威。”（

西方的军事努力也未得到非西方、非穆斯林文明的人民的支持。在 1991 年 1 月的民意测验中，53％的日本人反对这场战争，25％表示支持。在印度，谴责萨达姆·侯赛因和谴责乔治·布什发动战争的人各占一半。《

于是，一场以伊拉克和科威特之间的战争为开端的海湾战争，变成了伊拉克和西方之间，然后是伊斯兰和西方之间的战争，并最终被许多非西方人视为东方与西方之间的战争，“一场白人的战争，旧式帝国主义的新发作”。（

战争结束时，伦敦和纽约举行了胜利庆祝会，但在其他地方却无此种情景。

西方再次获胜了。曾激起阿拉伯人希望的最后一位萨拉丁式的英雄，在武装进犯伊斯兰社会的强大的西方力量面前不堪一击。

下述问题被反复提出：为什么美国和国际社会（即西方）不对以色列的暴行及其违反联合国决议的行动作出同样的反应？

战争之前，伊朗、伊拉克、海湾合作委员会和美国曾为获取对海湾地区的影响展开了竞争。战争之后，波斯湾变成了美国的内湖。

人类几千年的历史证明，宗教不是一个“小差异”，而可能是人与人之间存在的最根本的差异。断层线战争的频率、强度和暴力程度皆因信仰不同的神而极大地增强。

绝大多数的断层线冲突是沿着将穆斯林和非穆斯林区分开的环绕着欧亚和非洲的边界发生的。

激烈的对抗和暴力冲突在同一地区的穆斯林和非穆斯林之间极为普遍。

在所有这些地区，穆斯林和属于其他文明的人——天主教徒、新教徒、东正教徒、印度教徒、华人、佛教徒和犹太人——之间的关系总体上是对抗性的，他们之间大部分在历史上的某一时刻曾发生暴力冲突，很多在 20 世纪 90 年代仍处于暴力冲突中。沿着伊斯兰周边看去，穆斯林总是难以与其邻居和平相处。

穆斯林偏好暴力冲突的倾向亦通过穆斯林社会的军事化程度表现出来。20 世纪 80 年代，穆斯林国家拥有军队的比率（即在每 1000 人口中军人所占的比率）和军费投入比率（军费按一国财富计算的比率）大大高于其他国家的同类比率。

在诸大国中，只有中国的暴力倾向超过了穆斯林国家：它在其 76.9％的危机中使用了暴力。（

历史并未阻止这种相对和平的关系在相当长的时期内占优势，因此，它本身并不能解释

人口对比的变化就是这样的因素之一。一个集团人口的扩张给其他集团造成了政治、经济和社会压力，并引起了抵制。

20 世纪 70 年代初，黎巴嫩历时 30 年的法律秩序的崩溃，在很大程度上是什叶派人口相对于马龙派基督教人口急剧增长所致。

一位美国驻斯里兰卡外交官注意到，僧伽罗暴动分子事实上都是 24 岁以下的年轻人。据报道，泰米尔猛虎组织“在依靠娃娃兵方面是独一无二的”，它招募“甚至才 11 岁的男孩和女孩”，在战斗中被杀害者“有的死时尚不足 10 岁，仅有少数人超过 18 岁”。《

80 年代，车臣的人口增长了 26％，车臣地区是俄罗斯境内人口最密集的地区之一，它的高出生率导致了向外移民，并为战争提供了兵源。（

结果，至 1991 年，在科索沃的人口中 90％为穆斯林，10％为塞尔维亚人。（注 30）尽管如此，塞尔维亚人仍将科索沃视为他们的“圣地”或“耶路撒冷”，它是一些历史事件的遗址，其中包括于 1389 年 6 月 28 日发生的一场大战。

按照塞尔维亚人的说法，阿尔巴尼亚族针对塞尔维亚人的歧视、迫害和暴力的活动不断增加。一位克罗地亚新教徒说：“20 世纪 70 年代末以来发生了无数起暴力事件，包括毁坏财产、使人丧失工作、骚扰、奸淫、打斗和屠杀。”这一事态的后果是，“塞尔维亚人宣称他们面临的威胁具有种族灭绝的性质，这是他们再也无法忍受的。”

根据对种族灭绝所作的任何合理定义，塞尔维亚人的指控应当说是极度地夸大其词，然而一位同情阿尔巴尼亚族的外国观察家说：“在 20 世纪 80 年代，阿尔巴尼亚民族主义分子应当对大量针对塞尔维亚人的暴力攻击，以及对一些塞尔维亚人的财产破坏负责。”（

两年之后，于 1989 年 6 月 28 日，米洛舍维奇带领着 100 万—200 万塞尔维亚人回到科索沃，参加历史上那场标志着他们与穆斯林之间要不断进行战争的伟大战役 600 周年纪念活动。

至 1991 年，那里的人口比率几乎完全相反：塞尔维亚族人口所占比率降至 31％，而穆斯林人口升至 44％。在这 30 年中，克罗地亚族人口所占比率从 22％降至 17％。一个种族集团人口的扩张导致了另一个集团的种族清洗。“我们为什么要杀害儿童？”一个塞尔维亚族战士在 1992 年自问自答道：“因为总有一天他们会长大，到那时我们还得去杀他们。”

例如，塞尔维亚人和克罗地亚人之间的战斗就不能归结为人口。这个问题只有一部分可以归因于历史，因为直至第二次世界大战克罗地亚乌斯塔希分子屠杀塞尔维亚人之前，两个民族一直相对和平地生活在一起。

当人们已不再可能自认为是共产主义者、苏联公民或者南斯拉夫人之时，便迫切地需要寻求一种新的认同。他们在旧有的族性和宗教中找到了这种认同。

首先，有人论证说，伊斯兰教从创始起就是一个尚武的宗教。伊斯兰教起源于“好战的贝都因游牧部落”，伊斯兰教的基础深深地打上了“这种暴力起源的烙印。

随着奥斯曼帝国对巴尔干的征服，城市里的南斯拉夫人往往皈依了伊斯兰教，而居住在乡村的农民却没有，因此产生了穆斯林波斯尼亚人和东正教塞尔维亚人之间的差异。

西方在其权力压倒穆斯林而达到顶点之时提出让犹太人在中东建立家园，则奠定了阿拉伯—以色列持续对抗的基础。

相反，西方在海上的扩张通常没有导致西方人与非西方民族毗邻而居，因为除了在南非，这些非西方民族要么已臣服于欧洲的统治，要么已事实上被西方殖民者大批杀害了。

伊斯兰教是一个绝对的信仰，而且在这一点上更甚于基督教。它把宗教和政治结合在一起，将信仰伊斯兰教者和非信仰者明确地区分开来。其结果是，儒教徒、佛教徒、印度教徒、西方基督教徒和东正教徒彼此相互适应和生活在一起，较之他们中的任何一个与穆斯林相互适应和生活在一起，要更为容易。

与此相反，在穆斯林的印度尼西亚和穆斯林的马来西亚，发生了反对华人的暴乱和（或者）暴力活动，华人在那些社会里的作用仍然是非常敏感的、可能爆发的潜在问题，而在泰国和菲律宾的情况就并非如此。

根据这个观点，穆斯林是广泛传播的歧视穆斯林思想的受害者，正如历史上曾在西方出现的歧视犹太人的现象一样。

一个更具说服力的因素或许能够解释伊斯兰内部和外部冲突的原因，那就是在伊斯兰社会中缺少一个或一个以上的核心国家。

伊斯兰之所以成为世界上一个不稳定的根源，就在于它缺少一个起主导作用的中心。

最后，也是最为重要的一点，就是伊斯兰社会的人口爆炸，此外，15—30 岁年龄段中常常存在的大量男性失业者，也是造成不稳定以及伊斯兰内部和反对非穆斯林暴力活动的自然原因。

温和派抱着如自治而不是独立这样的较有限的目标，不可能通过几乎总是从一开始就失败的谈判来达到这些目标，就被想通过暴力达到更极端目标的激进派所补充或者取代。

对文明的认同在波斯尼亚急剧加强，特别是在穆斯林社群中。历史上，社群认同在波斯尼亚并不强烈，塞尔维亚族、克罗地亚族和穆斯林作为邻居和平地生活在一起，相互通婚很普遍，宗教认同也很弱。穆斯林被称为不去清真寺的波斯尼亚人，克罗地亚族是不去天主教堂的波斯尼亚人，而塞尔维亚族则是不去东正教堂的波斯尼亚人。

直至战争开始前，波斯尼亚穆斯林的世界观是非常世俗的，他们将自己视为欧洲人，是多元文化的波斯尼亚社会和国家最强有力的支持者。然而，在南斯拉夫分裂之后，这一点便开始发生变化。

这样，南斯拉夫战争的所有参战方和大部分旁观者，都将这场战争视为宗教的或者种族宗教的战争。

西方对克罗地亚人的支持，还包括无视其种族清洗、侵犯人权和违反战争法的行为，而塞尔维亚人恰恰是在这些方面经常遭到谴责。1995 年当休整后的克罗地亚军队对克拉伊纳地区的塞族人发动进攻，把在那里居住了几个世纪的数十万的塞族人驱逐到波斯尼亚和塞尔维亚时，西方保持了沉默。

1994 年，美国也加入了支持克罗地亚军队建设的行列。美国无视克罗地亚人严重违反联合国武器禁运决议的状况，为克罗地亚人进行军事训练，还派遣退役的高级将领做顾问。

南斯拉夫战争事实上使得东正教世界在塞尔维亚身后紧密地团结起来。

事实上直至 1878 年，从理论上说则直至 1908 年，波斯尼亚一直是奥斯曼帝国的一部分。现今，波斯尼亚移民和难民占土耳其人口的将近 5％。对波斯尼亚人事业的同情，以及对西方未能保护波斯尼亚人的义愤，在土耳其人中极为普遍。

波斯尼亚战争是文明之间的战争。三个主要参与者来自三个不同的文明，信仰不同的宗教。

现在的问题是：为什么在战争期间和战后，美国会打破文明模式，成为促进波斯尼亚穆斯林的利益、并与穆斯林国家合作的唯一的非穆斯林国家？美国这种反常行为的原因何在？

在对待外国的冲突时，美国人总想将善的力量和恶的力量区分开来，并与前者结盟。

整个战争期间，美国新闻界都忽视了克族和穆斯林的种族清洗行为和战争罪行，以及波斯尼亚军队对联

美国人的理想主义、道德主义、人道主义本能、天真和对巴尔干的无知，导致了他们亲波反塞的立场。

由于美国政府拒绝如实地认识战争的真相，它便疏远了自己的盟友，延长了战争，并协助在巴尔干建立了一个受到伊朗极大影响的穆斯林国家。到头来，波斯尼亚人对美国深怀不满，认为它说得多而做得少，但对其穆斯林兄弟则感激不尽，因为他们提供了维持生存和打胜仗所需的资金和武器。

随着一种文明的普遍国家的出现，它的人民由于汤因比所说的“不朽的幻想”而变得盲目，确信他们的文明就是人类社会的最终形态。人们对于罗马帝国、阿拔斯哈里发王朝、莫卧儿帝国和奥斯曼帝国就曾抱有这样的想法。

对于 1897 年时的英国中产阶级来说，“正如他们所看到的，历史已经终结……他们完全有理由为这一历史终结给他们带来的永久的幸福国家而庆幸”。

在以往的各文明中，这样一个怀着文明可以不朽的幻想的极乐黄金时代，不是由于一个外部社会取得的急剧胜利，就是由于内部缓慢但同样痛苦的解体而终结。

当文明停止“将盈余用于创新，用现代的说法就是投资率下降”之时，文明便衰败了。这种情况的发生，是由于控制了盈余的社会集团为满足“非生产性的、个人享受的既得利益……将盈余用于消费而不是提供更有效的生产方法”。当人们依靠资本生活之时，文明便从普遍国家走向衰败阶段。

在欧洲，西方文明也会由于其主要组成部分基督教的衰弱而遭到破坏。欧洲人崇尚宗教信仰、遵守宗教习俗和参加宗教活动的人数比率正在下降。（注 5）这一趋势反映出的不是对宗教的敌视，而是对宗教的冷漠。

20 世纪末，美国认同的这两个组成部分受到了为数不多但极有影响的知识分子和国际法专家集中而持久的攻击。他们以多元文化主义的名义攻击美国对西方文明的认同，否认存在着一个共同的美国文化，提倡种族的、民族的和亚民族的文化认同和分类。他们谴责，用其报告中的一段话来说，在教育中“有系统地倾向于欧洲文化及其分支”，以及“欧美单一文化观点的统治地位”。

西奥多·罗斯福警告说：“有一种情况绝对会导致国家的崩溃并阻碍美国作为一个国家继续存在的一切可能，那就是听任美国成为一个充满民族纠纷的国家。”（注 8）然而，20 世纪 90 年代的美国领导人却不仅允许并且努力促进多样性的发展，而不是促进他们所管理的人民的团结。

另一些国家的领导人有时企图摈弃本国的文化遗产，使自己国家的认同从一种文明转向另一种文明。然而迄今为止，他们非但没有成功，反而使自己的国家成为精神分裂的无所适从的国家。

历史表明，如此构成的国家不可能作为一个具有内聚力的社会而长期存在。一个多文明的美国将不再是美利坚合众国，而是联合国。

多元文化主义者还通过以集体权利代替个人权利来对美国信条的中心内容提出挑战，而集体权利在很大程度上是根据种族、民族、性别和性别偏好来界定的。

日本哲学家梅原猛指出：“马克思主义的彻底失败……苏联的急剧解体，仅仅是西方自由主义这一现代主流思潮失败的先兆。自由主义远不是取代马克思主义和在历史终结之时占统治地位的一种意识形态，它将成为另一块倒坍的多米诺骨牌。”

一个没有文化核心而仅仅以政治信条来界定自己的社会哪里会有立足之地？

摈弃美国信条和西方文明，就意味着我们所认识的美利坚合众国的终结。实际上这也意味着西方文明的终结。如果美国非西方化了，那么西方就缩小到只剩下欧洲和几个欧洲移民人口不多的国家。

多元文化主义者与西方文明和美国信条维护者之间的冲突，用詹姆斯·库尔思的话来说，是西方文明美国部分之中的“一场真正的冲突”。（注 11）美国人无法回避这样的问题：我们是西方人，还是其他什么人？美国和西方的未来取决于美国人再次确认他们对西方文明的责任。

如果北美和欧洲能够更新建立在文化共性基础上的道德生活，并发展紧密的经济和政治一体化形式来补充其在北约内的安全合作，它们便能够创造出西方经济富裕和政治影响扩大的第三个阶段欧美阶段。

西方能否在政治和经济上走到一起，主要取决于美国是否再次确认自己的西方认同，并把自己的全球作用确定为西方文明的领袖。

鉴于美国的利益，美国与中国之间若是发生战争，它将会如何发展？假设在 2010 年，美国军队撤出了已经统一的朝鲜，在日本的驻军也大幅度减少。台湾和大陆已和解，台湾继续保持它事实上拥有的大部分独立，但明确承认北京的宗主权，而且依照 1946 年乌克兰和白俄罗斯的模式，在中国的倡议下进入了联合国。

然而，这一场景最看似可信、因而也最令人担忧的一点是战争的起因：一个文明的核心国家（美国）干预另一个文明的核心国家（中国）与该文明成员国（越南）之间的争端。对于美国来说，为了维护国际法、抵抗侵略、保卫海洋自由、保证获取南中国海的石油，以及阻止东亚为一个国家所控制，这样的干预是必要的。但是对于中国来说，美国的干预是完全不能忍受的。中国认为，这是西方大国羞辱、恐吓中国的典型狂妄企图，是在中国合法的势力范围内挑动其他国家反对中国，是否认中国在世界事务中应起的作用。

美国国内的多元文化主义对美国和西方构成了威胁，在国外推行普世主义则对西方和世界构成了威胁。

20 世纪 90 年代初，新加坡这个小国为确认共性作出了努力。

过去，新加坡政府在人民中倡导“儒教价值观”的同时，坚持所有人必须接受英语教育并能够讲流利的英语。

黄金辉总统提出了四个基本的价值观：“将社会置于个人之上，将家庭作为社会的基石，通过共识而不是斗争来解决重大争议问题，强调种族和宗教的相互容忍与和谐。”

白皮书赞同总统提出的所有四个价值观，但又补充了一条，即尊重个人，目的在于强调个人价值在新加坡社会中的优先地位，以抗衡可能导致裙带关系的儒教等级观念和家庭观念。

政府强调新加坡“在关键方面是一个亚洲社会”，并且仍将如此。“尽管我们讲英语、穿西装，但新加坡人不是美国人或盎格鲁—撒克逊人。

从信仰者的人数来看，犹太教显然不是一个主要文明。汤因比把它描述为一个从早期叙利亚文明中演变而来的被抑制了的文明。

奎格利在一个可能是正确的，但未得到理论分析和经验分析有力支持的预测中总结道：“西方文明于大约公元 500 年时尚不存在；在将近公元 1500 年时达到鼎盛时期，它在未来的某一时刻肯定会消亡，或许是在公元 2500 年之前。”

从公元 1 世纪开始，大乘佛教被输出到中国，随后输出到朝鲜、越南和日本。在这些社会里，人们以不同的方式使佛教适应于和被吸收进本土文化（例如在中国适应于儒教和道教），并压制它。因此。虽然佛教仍然是这些社会的文化的重要组成部分，但这些社会并没有构成佛教文明，也不会认为自己是佛教文明的一部分。然而，能够被合理地描述成小乘佛教文明的东西确实存在于斯里兰卡、缅甸、泰国、老挝和柬埔寨。此外，西藏、蒙古和不丹的人口，历史上曾认同于大乘佛教的变种喇嘛教，这些社会构成了佛教文明的第二个区域。

公元 8 世纪中国发明了印刷术，11 世纪发明了活版印刷，但直到 15 世纪这一技术才传到欧洲。造纸术公元 2 世纪出现于中国，7 世纪传到日本，8 世纪向西传播到中亚，10 世纪到北非，12 世纪到西班牙，13 世纪到北欧。中国的另一项发明——火药，产生于 9 世纪，几百年后它才传到阿拉伯国家，14 世纪才到达欧洲。

欧洲基督教文明作为一个独特的文明最早出现于 8 世纪和 9 世纪。然而，几百年间，它在文明程度上落后于许多其他文明。唐、宋、明朝时期的中国、8—12 世纪的伊斯兰世界、8—11 世纪的拜占庭，在财富、领土、军事力量以及艺术、文学和科学成就上都远远超过了欧洲。

11—13 世纪之间，欧洲人热情而系统地借鉴了“来自更高的伊斯兰文明和拜占庭文明的适当因素，同时使这一遗产适应于西方的特殊条件和利益”，在此推动下，欧洲文明开始发展。同一时期，匈牙利、波兰、斯堪的纳维亚和波罗的海沿岸皈依了西方基督教，随后又接受了罗马法和西方文明的其他方面，西方文明的东部边界从而稳定了下来，并从此固定在那儿而无重大的改变。

文明之间断断续续的或有限的多方向的碰撞，让位于西方对所有其他文明持续的、不可抗拒的和单方向的冲击。

1800 年欧洲人或前欧洲的殖民地（在南美和北美）控制了地球表面土地的 35％，1878 年这一数字为 67％，1914 年为 84％。到 1920 年，当奥斯曼帝国被英国、法国和意大利瓜分时，这一比例进一步提高。

到 1900 年，维多利亚女王时代的“日不落”英帝国包括了 1100 万平方英里土地和 3.9 亿人口。

在欧洲扩张的过程中，安第斯和中美洲文明被有效地消灭了，印度文明和伊斯兰文明同非洲文明一起被征服，中国受到渗透并从属于西方的影响。只有俄罗斯、日本和埃塞俄比亚这三个在高度中央集权的帝国权威统治下的文明得以抵制西方的冲击，并维持了有意义的独立存在。400 年之久的文明间关系是由其他社会对西方文明的从属所构成的。

然而，西方扩张的直接根源是技术：发明了到达距离遥远的民族的航海工具，发展了征服这些民族的军事能力。正如杰弗里·帕克所观察到的，“‘西方的兴起’在很大程度上依赖于使用武力，依赖于下述事实：欧洲人及其海外对手之间的军事力量对比稳定地有利于前者……西方人在 1500—1750 年期间成功地创造出第一批全球帝国的要诀，恰恰在于改善了发动战争的能力，它一直被称为‘军事革命’。”

西方赢得世界不是通过其思想、价值观或宗教的优越（其他文明中几乎没有多少人皈依它们），而是通过它运用有组织的暴力方面的优势。西方人常常忘记这一事实；非西方人却从未忘记。

此时，文明意味着西方文明，国际法意味着源自格劳修斯 2.3 传统的西方国际法，国际体系是西方的威斯特伐利亚体系，其主体是主权而文明化的民族国家及其所控制的殖民地领土。

正因为如此，1993 年 6 月我在华盛顿刚看到《文明的冲突？》的第一个印象是：亨廷顿把对美国前途的忧虑投射到全世界去了。三个月以后，我到了夏威夷的东西方中心，与一位年轻的日本学者谈天，问他对亨廷顿的文章印象如何，他的回答十分简单：“desperate”（绝望），倒也干脆。

对亨廷顿来说也许更加重要的是：基督徒的人数日益减少，他认定十年之后，穆斯林的人数将超过基督徒。

亨廷顿在最近这篇文章中说：“西方已经没有经济的或者人口的活力足以把自己的意志强加于人了。”“人口的活力”这几个字泄露了亨廷顿的真意。

他无疑是西方中心主义的遗老，但是他已不敢公然嗟叹盛世难再，而只敢承认西方已经衰落。

他为西方设计的战略只是严守北大西洋公约以自保，但是在铺天盖地而来的“黄祸、绿祸与黑祸”面前，他并没有表现出强烈的信心（这是一位亚洲朋友的话，绿祸指伊斯兰、黑祸指黑非洲，因此还不能把这样“政治上不正确”的“反 PC”的话安在亨氏头上）。

此外他极力想把拉美文明也拉作西方文明的同盟军，而且对俄罗斯也偶露拉拢之意。考虑到俄罗斯人既是白种人又是基督徒，这一意向不难理解；但是几十年的敌对，以及天主教与东正教上千年的分裂又使他顾虑重重。

他们实际上也无休止地相互打仗；在欧洲国家中和平只是例外而不是常态。

总而言之，亨廷顿的观点值得重视，因为它们代表着一种深刻的恐惧。正如我们上面所分析的，这种恐惧绝不仅仅代表他一个人，而是代表着一大批人。

历史学家所钟爱的短语“西方的扩张”终结了，“对西方的反抗”开始了。

20 世纪重大的政治意识形态包括自由主义、社会主义、无政府主义、社团主义、马克思主义、共产主义、社会民主、保守主义、国家主义、法西斯主义和基督教民主。它们在一点上是共同的，即它们都是西方文明的产物。没有任何一个其他文明产生过一个重要的政治意识形态。然而，西方从未产生过一个主要的宗教。世界上的伟大宗教无不是非西方文明的产物，而且，在大多数情况下是先于西方文明产生的。

西方文明的特有产物——威斯特伐利亚条约所造成的宗教与国际政治的分离——正在走向终结，正如爱德华·莫蒂默所指出的，宗教“越来越可能侵入国际事务”。（注 32）西方所造成的文明间的政治思想冲突正在被文明间的文化和宗教冲突所取代。

与此相伴随的是，1920 年的西方全球帝国收缩为 20 世纪 60 年代的较有限的“自由世界”（它包括许多反对共产主义的非西方国家），然后进一步收缩为 20 世纪 90 年代的更为有限的“西方”。这一变化在用词上反映在 1988 到 1993 年之间使用意识形态的术语“自由世界”的减少和使用文明的术语“西方”的增多上（见表 2.1）。它也表现在越来越多地把伊斯兰教当作一个文化—政治现象来提及，以及越来越多地提到“大中华”、俄罗斯及其“近邻”和欧洲联盟所有这些带有文明内容的术语。

第三，“普世文明”一词可以指西方文明中的许多人和其他文明中的一些人目前所持有的假定、价值观和主张。这可以被称为达沃斯文化。每年大约有 1000 名商人、银行家、政府官员、知识分子和记者从几十个国家聚集到瑞士达沃斯的世界经济论坛。

说什么通俗文化和消费品在世界上的流行，代表了西方文明的胜利，这一论点反而使西方文化变得无足轻重。西方文明的本质是大宪章（Magna Carta）而不是“大麦克”（“巨无霸”Magna Mac）。非西方人可能接受后者，但这对于他们是否接受前者来说没有任何意义。

在中东的某个地方，几名年轻人完全可以穿着牛仔裤，喝着可乐，听着摇滚乐，但他们却可能在向麦加顶礼膜拜的间隙，造好一枚炸弹去炸毁一架美国飞机。

只有幼稚的妄自尊大才会导致西方人假设非西方人会通过获得西方商品而变得“西方化”。

当巡航导弹击中巴格达时，西方的起居室里一片欢呼。生活在这之外的人都认为西方将迅速对非白种的伊拉克人或索马里人，而不是对白种的塞尔维亚人给予惩罚，但是用任何标准来衡量后者都是危险的标志。”（

所能得到的涵盖了 30 年以上的数据（1958—1992），显示出世界上语言使用的整个模式并没有发生急剧的变化，而讲英语、法语、德语、俄语和日语的人口比例却有了显著的下降，讲汉语普通话的人口比例有较小的下降，讲印地语、马来—印度尼西亚语、阿拉伯语、孟加拉语、西班牙语、葡萄牙语和其他语言的人口比例则有所增长。

因此，在整个历史上，不断出现通用语言，在古代世界和中世纪世界是拉丁语，在西方几个世纪中是法语，在非洲的许多地区是斯瓦希里语，20 世纪后半叶，在全世界的大部分地区是英语。

通用语言是处理语言差异和文化差异的方式，而不是消灭它们的方式。它是交流的工具，而不是认同和社会群体的根源。日本的银行家和印度尼西亚的商人彼此用英语交谈，并不意味着他们之中的任何一个人盎格鲁化或西方化了。

历史上，语言在世界上的分布反映了世界权力的分配。使用得最广泛的语言——英语、汉语普通话、西班牙语、法语、阿拉伯语和俄语，都是或曾是帝国的语言，这些帝国曾积极促进其他民族使用它们的语言。

英国和法国坚持在其殖民地使用自己的语言。然而，大多数前殖民地在独立之后，都在不同程度上努力用本土语言来代替帝国语言，并取得了不同程度的成功。在苏联的全盛期，俄语是从布拉格到河内的通用语言。由于俄罗斯权力的衰落，把俄语作为第二语言来使用者相应减少了。

中国经济的发展正在产生类似的汉语热。汉语正在迅速取代英语成为香港的主导语言，（注 16）而且鉴于海外华人在东南亚的作用，汉语已经成为这一地区许多国际商业交易中使用的语言。

这些数据确实显示出信奉两个主要的具有改宗力的宗教，即伊斯兰教和基督教的世界人口比例在这 80 年中有所增长。

穆斯林增加得更快，从 1900 年的 12.4％增加到 1980 年的 16.5％，或者依另一个估计为 18％。

然而，从长期来说，穆罕默德会占上风。基督教主要是通过使人皈依来传布，而伊斯兰教则通过使人皈依和人口繁殖来传布。20 世纪 80 年代基督徒在世界上的增长比例在达到大约 30％后稳定下来，现在开始下降，到 2025 年可能占世界人口的将近 25％。世界上穆斯林人口由于极高的人口增长率（见第五章），将继续急剧增长，大约在世纪之交将达到世界人口的 20％，再过若干年后将超过基督徒的人数，而到 2025 年可能占到世界人口的大约 30％。（

普世主义是西方对付非西方社会的意识形态。

在现代世界，宗教是一个重要的、可能是唯一重要的促动和动员人民的力量。下述想法是十足傲慢的表现：由于苏联共产主义垮台了，西方就永久赢得了世界，穆斯林、中国人、印度人和其他人将仓促地把西方自由主义当作唯一的选择来接受。

贸易会增加或减少冲突的可能性吗？它会减少民族国家之间发生战争的可能性的假设至少没有

另一项研究论证说，高水平的经济相互依赖“可能导致和平，也可以导致战争，这取决于对未来贸易的预期”。

在社会心理学上，差异性理论认为，人们根据在特定的背景下用把自己区别于其他人的东西来界定自己：“一个人根据把他自己区别于其他人的特性，特别是区别于他通常所处的社会环境中的人的特性……来看待自己。与 12 名从事其他职业的妇女在一起时，一个女心理学家把她自己看作是心理学家；当她同 12 名男心理学家在一起时，她把自己看作是一个女人。”（

现代社会因此有很多共同性，但是它们必然融为同质性的吗？那种认为它们必然如此的论点建立在下述假设之上：现代社会一定接近于某种单一的类型，即西方类型，现代文明即西方文明，西方文明即现代文明。然而，这是完全虚假的同一。

西方远在现代化之前就是西方，使西方区别于其他文明的主要特征产生于西方现代化之前。

古典遗产。作为第三代文明，西方从以前的文明中继承了许多东西，包括最引人注目的古典文明。西方从古典文明中得到很多遗产，包括希腊哲学和理性主义、罗马法、拉丁语和基督教。

天主教和新教。西方的基督教，先是天主教，而后是天主教和新教，从历史上说是西方文明唯一最重要的特征。

欧洲语言。语言是仅次于宗教的、使一种文化的人民区别于另一种文化的人民的要素。西方在其语言的多样性方面不同于大多数其他文明。日语、印地语、汉语普通话、俄语，甚至阿拉伯语都被认为是它们文明的核心语言。

精神权威和世俗权威的分离。在整个西方的历史上，先是唯一的教会然后是许多教会与国家并存。上帝与皇帝，教会与国家，精神权威与世俗权威，在西方文化中始终普遍地是二元的。

在伊斯兰教中，上帝即皇帝；在中国和日本，皇帝即上帝；在东正教中，上帝是皇帝的小伙伴。作为西方文明象征的教会与国家之间的分离和一再出现的冲突，在其他文明中并不存在。这种权威的分裂极大地有利于西方自由的发展。

法治。法治是一个文明社会的核心观念，是从罗马继承来的。

法治的传统为宪政和人权保护奠定了基础，包括保护财产权不受专制权力的侵犯。在大多数其他文明中，法治在影响思想和行为方面是一个较不重要的因素。

社会多元主义。历史上，西方社会一直是非常多元化的。正如多伊奇所注意到的，西方的独特性是“多样化的自主集团的兴起和延续，它们并非建立在血缘关系或婚姻基础之上”。

大多数西欧社会包括相对强大和自主的贵族、大量农民和虽然为数不多但很重要的商贾阶级。

欧洲的多元性与同时存在于俄罗斯、中国、奥斯曼帝国和其他非西方社会中的市民社会的贫困、贵族的虚弱和中央集权的官僚帝国形成了鲜明的对比。

代议机构。社会的多元性最初导致了等级、议会和其他代表贵族、教士、商人和其他集团的利益的机构。这些机构提供了在现代化过程中演变为现代民主体制的代议制形式。在一些例子中，这些机构在绝对君主制期间被废除，或者受到很大的限制。然而甚至当这种情况发生之后，如在法国，它们仍然得以复活，并成为扩大政治参与的工具。没有任何其他的当代文明具有可与之相比的可以追溯到 1000 年前的代议机构的传统。

个人主义。上述许多西方文明的特征促进了文明社会中所独有的个人主义意识及个人权利传统和自由传统的出现。个人主义产生于 14 和 15 世纪，被多伊奇称为“罗密欧与朱丽叶革命”的个人选择权利到 17 世纪在西方被普遍接受。对所有个人平等权利的要求——“英格兰最贫穷的人也可以大体上像最富有的人一样度过自己一生”——即使没有被普遍接受，也得到了清楚的表达。

在一位学者对包括 50 个国家的类似例子的分析中，在个人主义指标方面得分最高的 20 个国家包括了除葡萄牙之外的所有西方国家，再加上以色列。

西方人和非西方人都一再把个人主义认作西方主要的区分标志。

毫无意义的工作

打造一个闲暇的社会，每周只需上班 20 个小时甚至 15 个小时——这本来是可以轻松做到的，然而现实情况恰恰相反，整个社会，所有的人，似乎都陷入了某种悲惨的境况：我们将生命中大部分的时间都投入了工作，投入了那些我们知道对这个世界毫无贡献的工作中。

小时甚至 15 个小时——这本来是可以轻松做到的，然而

在研究中，我发现把狗屁工作分成五个类别会很有帮助。这五大类别分别是：随从（flunky）、打手（goon）、拼接修补者（duct taper）、打钩者（box ticker）和分派者（taskmaster）。

美国制度经济学家道格拉斯·诺思提出过“生产性努力”和“分配性努力”这两个概念。生产性努力具有强大的创新性，不断增大社会财富，而分配性努力只是想在不增加社会财富总量的状况下抢占社会的优势地位，在分配结构中夺取更大的个体利益。在什么样的年代会产生普遍的“分配性努力”？诺思指出，当社会分配严重不公时，生产性努力没有回报，分配性努力却风生水起，人们自然不愿再将时间投入生产性努力，纷纷奔向分配性努力。长此以往，整个社会就会失去创造的激情，经济结构趋于单一，失去增长的原动力，从而必然陷入停滞。

巴勃罗的主要观点是，人们越来越依赖免费软件，软件行业的领薪岗位也越来越多地设置给了拼接工作。程序员下班后很乐意利用业余时间无偿开发些程序，因为这些涉及核心技术的工作内容本身就令人满足，但同时也意味着他们越来越没有动力去考虑自己开发的程序是否最终能和其他人开发的其他程序相兼容，那么这批程序员在白天上班的时候，就得花费更多时间去从事拼接工作（有偿），把这些本不兼容的程序拼接起来。

格雷伯在书里援引了俄国作家陀思妥耶夫斯基在西伯利亚劳改营流放期间提出的一种理论：世界上最残酷的折磨便是强迫人无休止地做一件明显毫无意义的工作。

我的看法是，这些狗屁工作并不是资本主义本身带来的[27]，而是管理主义思想在各大机构实践的产物。

我有位熟悉的女性朋友，她自己压根儿没有任何军事经验，结果因为成了某位北约军官的私人助理，就写了大量战区军事行动战略计划（而且我绝对有理由相信，她写的战略计划不会比任何北约将军写出来的差，她写的说不定还更好）。

纵观人类历史，大部分人似乎对下列两点持肯定态度：第一，偿还债务是构成人类道德的核心要素；第二，放债者皆为恶人。

这里暗含着一个假设：如果人类有机会做寄生虫，那他们会毫不犹豫地去做。事实上，几乎所有可获得的证据都显示出上述假设并不成立。

所有人都很熟悉那些在外人看来没多大作用的岗位，比如，人力资源顾问、沟通协调员、公关研究员、金融策略师、企业律师，以及那些（学术圈都很熟悉的）专门负责给某种委员会招聘的工作人员，而这种委员会的工作正是讨论哪些委员会没必要存在。

因为成为奴隶，就意味着丧失个人的自由意志，成为他人的工具，哪怕只是一段有限的时间，这也是一个人可能经历的最为耻辱的事情了。[11] 因此，我们可以看到的古代“拿工资干活”的案例中，绝大部分发生在原本就是奴隶的那些人身上，比如，制陶奴隶跟他的奴隶主商定，去专门的制陶厂干活，拿回来工资后，一半分给主人，一半自己留着。[

对自己的工作拥有控制权的工人，他们的工作模式都是猛干一阵、放松一阵，交替着进行。（

当然，我们很快就吸取了教训：工作时效率不要太高。因为没人会因此奖励你，连生硬地点点头表示认可都不会有（说实话，我们当时需要的不过就是这么点儿认可）。如果太高效，你还会倒霉，因为空出来时间了，这个时候，你就不得不做些毫无意义的假模假样的工作。我们很快发现，被迫做出假装工作的样子，是我们遇到的最大羞辱，因为根本不可能假装，是什么就是什么，不是什么就不是什么。这不过就是纯粹的侮辱，就是老板想要施展他的权力而已，没有其他。

人是依赖社交的存在，如果失去了和他人经常接触的机会，就会开始萎缩，甚至肉体上也开始衰弱。人类之所以觉得自己是自主存在，是与世界和他人分离的独立体，很大程度上是因为人们觉得自己可以按照可预测的方式对世界和他人产生影响。一旦被剥夺这种拥有力量的感觉，人类就什么也不是了。而且，在狗屁工作中，人类执行虚幻行为的能力，在一般情况下可被视作人类行为中最高级且最特别的能力，这种能力以某种方式创造出了真正存在的虚假世界之后，就与它自身反目成仇了。

霍克希尔德发现，出于工作需要，空姐普遍会假扮并维持着活泼、共情、友善、亲和的面具人格。这种假扮耗费的精力如此之多，以至她们常常陷入空虚、消沉、窘迫和对自身本质的困惑中而无法自拔。

统治阶级意识到一件事：如果老百姓生活幸福、工作高效、时间自由，那么就会埋下巨大的危险种子。（想想 20 世纪 60 年代发生的事就好了，当时人们的生活和工作状态只不过有那么一点点靠近这个方向。）

事实上，我就没遇到过一个不觉得自己的工作是狗屁工作的企业律师。

可如果消失的是这个世界所有的私募基金首席执行官、游说者、公关研究员、精算师、电话推销员、法警和法律顾问，那人类是否会痛苦不堪，是否会面临无法生存的情况，就不好说了。[3]（许多人认为人类的处境可能会大大改善。）

许多情况下，狗屁工作从事的事情仅仅是没有意义而已，但是一旦发现你做的事情正在导致他人的灾难，那么除了毫无意义对你的侵蚀，你还将经历内疚和恐惧带来的心灵摧残。

把我的自由职业（写短篇小说和文章）作为消遣了，比之前做那些无趣乏味的狗屁工作时更容易进入状态了。大卫：我们或许发现了什么了不起的事情！哈里：没错，真有意思。所以，

所以，身处狗屁工作，然后利用“多出来”的时间去做其他事情并不容易。因为工作时间大都是在“枯燥乏味的办公环境”（用詹姆斯的话来讲）中度过的，我们所拥有的都是碎片化时间，哪怕回过头来发现其实有时也是一大段时间，但用这些时间去投入地做那些需要思考和创造力的事情则需要一个人足够足智多谋，并且具有坚定的决心。

我们完全有理由相信，狗屁工作的总体数量，乃至那些被从事者认定毫无意义的工作岗位在全部岗位中的占比，最近几年都在急速上升。同时，有用岗位也正在经历越发严重的狗屁化。换句话说，这本书讨论的不是职场中长期被忽略的问题，它关注的是当下切切实实的社会问题。

人们往往觉得，制造业占比的下降（顺便提一句，美国制造业占比并没有下降那么多，2010 年时仅仅退回到和南北战争爆发时差不多的水平）不过是因为工厂都建到了国外，建在了那些贫困国家。

这里真正的问题其实是“服务经济”本身怎么定义。我给“服务经济”打上引号是有原因的。当我们说某个国家的经济主要由服务业支撑的时候，脑海中第一时间浮现的画面是这个国家的人主要靠互相递送冰拿铁、互相熨烫短裤来维持生计。显然，情况并非如此。

我们从图 4 可以看到，哪怕是在 1990 年，由真正的“服务业”人员（餐厅服务员、理发师、售货员等）构成的劳动力占比都是很小的。而且这个比例一直以来稳定得惊人，100 多年都维持在 20% 左右。而之前被归到“服务业”的绝大部分人员其实是行政人员、顾问、办事员、会计、信息技术专业人士等。“服务业”中真正在增加的也正是这批人，而且从 20 世纪 50 年代起，增速堪称惊人。

但是如果我们的调查靠得住，那么似乎很明显，大部分信息工作者确实觉得，如果这个世界上没有了他们所从事的岗位，几乎不会对世界有任何影响。

2008 年之前金融业被一种近乎神秘的气氛包围着，这种气氛现在已很难再次拥有。彼时，金融从业者成功说服了公众——其实不仅仅是公众，还有社会理论家（这一点我记忆犹新）。他们通过使用担保债务凭证和高速交易算法等复杂到只有天体物理学家才看得懂的金融工具，已经研究出了无中生有的赢利方法，他们就像现代版的炼金术士，采用的手段复杂到其他人压根儿不敢仔细看。于是崩盘自然而然地发生了，人们恍然大悟，原来大部分金融工具都是骗局，许多工具甚至不太高明。

某种程度上我们可以说，整个金融业就是一场骗局，因为整个行业表面上是针对商贸和制造领域的潜在赢利机会进行的各种操作，但事实上，这两个领域几乎没有被涉及。金融业绝大部分的利润来自同政府合谋生产、交易和操纵各种各样的债务。在本书中，我真正想说的是，就和金融业充满了烟雾幻境和假象一样，伴随着金融业繁荣而兴起的信息岗位，大部分工作也不过是魔术师的骗局而已。

如果这一切是骗局，那么究竟是谁在骗谁？

回到狗屁工作这个议题，上述分析意味着我们可以提出三个问题：第一，个人层面——为什么人们会从事并忍受毫无意义的工作？第二，社会和经济层面——什么样的力量推动着狗屁工作的激增？第三，文化和政治层面——经济制度的狗屁化为何未被视作社会问题？

结果医生大为震怒，告诉他只有专业人士才有能力决定什么时候可以降低剂量，才可以决定怎样才算戒毒成功。原来，这个替代治疗戒毒服务能够拿到多少经费，是取决于在他们这里戒毒的人数的，所以他们压根儿没有任何动力去真的帮人戒掉毒瘾。

比如，巴以“和平进程”（如果现在还能被称作和平进程）之所以僵持了 30 年，有种说法就是巴以两国都已经建立起围绕这项进程的强大的机构组织群体。若是冲突真的结束了，这些组织和机构就完全没有存在的理由了，而海量致力于和平事务的非政府组织也可以解散了，那些整个职业生涯都依靠维持这个虚构场景——有这样一个“和平进程”确实在进行中——的联合国官员也可以下岗了。

总统先生到底说了什么？他承认了恺撒医疗集团或蓝十字蓝盾等医疗保险机构的几百万个岗位是没必要存在的。他甚至承认了社会主义化医保制度比现有的市场化医保制度更有效，因为前者可以减少不必要的文书工作，还可以避免数十家有竞争关系的私营医保公司精力的重复消耗。但他同时表示，正是为了保住这几百万个无用岗位，我们不能采用社会主义化医保制度。

所有迷信市场魔力的人都这样，不管出现了什么问题，不管发生了什么不公正的事情，不管上演了什么荒诞剧情，他们都坚持认为，虽然表面上看起来是市场造成的，但事实上都是政府干预的结果。

因为所有现存的市场体制多多少少都受到政府管控，因此一旦出现你喜欢的结果（比如，总体富裕程度高），那一定是市场的功劳，而一旦出现了你不喜欢的结果（比如，总体贫困程度高），那就一定是因为政府对市场进行了干预，然后把举证的压力抛向那些反对意见持有者。

现实中，私立院校行政人员和管理人员的增幅是公立院校的两倍多。你总不能说，是因为政府的干预和管控，导致了私营机构的行政岗增幅是公立机构行政岗增幅的两倍吧。事实上，这组数据唯一的解释恰恰是相反的结论：公立大学最终是要向公众负责的，因此始终会受到政府施加的压力，需要节省开支、避免浪费。

回到 20 世纪 50 年代或者 60 年代，我们依然可以说大学是为数不多的还保留着中世纪行事风格的欧洲机构。很重要的一点是，当时的大学依然按照中世纪的准则在运行：只有从事了某种形式的生产（不管产品是石制品、皮手套还是数学等式），你才有权利安排自己的事务，的确，只有它们有资格如此。

但是金斯伯格表示，自 20 世纪 80 年代起，大学行政管理人员成功地策划了一场“政变”。他们从教师手中夺过了大学的控制权，引领着大学走向完全不同的目的地。今时今日我们已经司空见惯，高校发布的“战略愿景文件”中对研究和教学只字不提，却大书特书“学生活动”、“学术实力”（以获得拨款）、企业合作、政府合作等内容。

他们天花乱坠地宣扬着新自由主义的种种好处，声称新自由主义能够释放出市场的魔力，声称新自由主义把经济效率放到了第一位。然而事实上，这些自由市场政策总体上导致全世界几乎所有地方（除了印度和中国）经济增速的减缓，以及科学技术发展的停滞。

正如埃利奥特所说，这些参与 PPI 赔偿项目的人员中，起码有一部分人在故意全力拖延，来骗取更长时间的合约。

在我收到的反馈中，类似的故事还有很多：有人告诉我，在石棉致病的赔偿支付单子中，相关律师事务所也有这么操作的。每当上亿英镑巨款被专门拨出来赔偿某个群体，就会出现一整套官僚机构来确认被赔偿者、处理索赔申请、给出具体的赔偿金。整套官僚机构往往有好几百人甚至上千人。因为他们的工资最终正是来自这笔赔偿金，所以他们根本找不到动力去高效解决这个赔偿问题。

早在 1852 年，查尔斯·狄更斯在《荒凉山庄》中就已经通过描绘“贾戴斯控贾戴斯案”嘲讽过律师行业。该案中，双方律师使尽手段，使得这个巨额遗产争夺案迟迟不能被宣判，旷日持久到了令人发指的地步，直到最终这笔遗产被官司本身耗尽、被律师完全吞噬，他们才表示案件已无关紧要，一切就这么结束了。

很明显，这基本就是整个 FIRE 行业的操作模式：先通过放贷的方式创造钱，然后用极其复杂的方式把这笔钱移来移去，每移一次就抽取一部分佣金。久而久之，银行的员工就开始觉得自己所在的整个行业都毫无意义，就和会计师事务所故意不好好培训员工来持续榨取“现金牛”一样。多到惊人的银行员工怎么都想不明白自己所在的银行存在的真正理由是什么。

对国家决策有决定权的那帮人，绝大部分都是 20 世纪 60 年代上的大学。那个年代的校园正是政治动荡、风起云涌的中心，他们强烈地感到类似的事情绝不可以重演。因此，他们虽然对下降的经济指标或许也有关注，但当他们注意到不管是全球化、工会力量的削弱，还是累得要死要活却跟安全感无缘的劳苦大众，抑或是对 60 年代个人享乐解放运动（也就是我们现在所说的“生活方式自由主义、财务保守主义”）进行的积极口头响应、消极行动支持，这些事件联合起来带来的结果都是他们乐意见到的：越来越多的财富和权力集中到了少数权贵阶层手中，而能够对他们的权力造成挑战的组织力量已被摧毁得近乎荡然无存。虽然

这位从业者后来告诉我，在银行谈论狗屁工作这个话题，就好比在 20 世纪 50 年代公开“出柜”一样：“很多人都看过《谈谈‘狗屁工作’现象》这篇文章，也清楚我们这个行业的真实情况，但是他们（包括我在内）心中充满了恐惧，害怕失去工作，所以不会公开谈论这个话题。我们欺骗自己、欺骗同事、欺骗家人。”

西蒙：据我保守估计，该银行 6 万名员工中有 80% 是多余的。他们的工作要么完全可以自动化，通过程序来实现，要么就根本不需要做，因为他们从事的项目一开始就是为了制造出毫无意义的工作。

我听说，有些公司的程序员上班时穿的文化衫上印着“走开点，不然我写一小段 Shell[5]脚本就没你什么事了”，但是在这个案例以及其他类似的案例中，我们发现这种担忧袭向了公司的高层。

当然，这就是为何“空谈自由论者”或“正统马克思主义者”总是坚称，在我们的经济制度下，不可能出现狗屁工作泛滥的情况。这就是为何他们觉得狗屁工作理论是想象出来的，是错误的观念。但我们如果换一下思考的逻辑，不再以经济看待经济，而是在经济和政治混合作用的封建制度框架下思考这个现象，就会发现一切都突然说通了。正如前文提到过的 PPI 赔偿金分发案例，“封建主”所做的就是想尽办法分一大杯羹（不管是从敌人那里窃取，还是通过收取服务费、过路费、租金、税款向平民榨取），然后再重新分配出去。

眼下世界各国（比如美国、丹麦、日本等）每个普通家庭，每个月的收入被 FIRE 行业抽走的精确百分比我们基本上不可能获得，但我们完全有理由相信，这个数目一定是惊人的。不仅如此，我们还可以推断，这些国家的企业，通过制造和销售商品或服务产生的利润已越来越比不上 FIRE 行业通过榨取获得的利润了。

比如通用汽车，它现在不靠卖汽车来赚钱，而是靠收取汽车贷款利息获利。

总的来说，雇用各种经理表面上来讲是为了提高效率，但对大象茶叶工厂来说似乎没经理什么事，工人自己就把效率提升了，而且提升得还不是一星半点，基本已经提升到极限了。

大约从 1945 年到 1975 年，工人、老板和政府之间存在着一种有时候被称作“凯恩斯主义协定”的默契，那就是如果工人生产率提升了，那么他们的报酬也定会相应提升。图 5 很好地证明了这一点。然而到 20 世纪 70 年代，生产率和报酬这两组数据开始分道扬镳了，在生产率狂飙突进的同时，工人的报酬却基本没有什么变化。

因此，我们可以做出如下总结：在任何以占有和分配商品为基础的政治经济体制中，非常多人从事的工作就是在整个系统中来回传送各种资源，而不是真正去创造、推进或维修这些商品，这一庞大的群体往往会将自己分成非常多的等级（起码有 3 个级别，有时候能达到 10 个、12 个甚至更多）。

有些事情已经大错特错了，人们完全搞错了自己的使命。我们将整个社会的文明搭建在了工作之上，甚至都不是搭建在“有成效的工作”上，而是让工作本身成了我们的目标和一切意义之所在。人们建立了这样的认知，那就是如果有人在自己并不那么喜欢的岗位上不努力地工作，那么他们就是糟糕的人，不值得被爱，不值得被关心，也不值得获得社会的帮助。大家就好像集体默许了我们每个人被奴役的这种遭遇。

一直到 20 世纪 70 年代，金融力量和管理阶层（公司官僚体系中的最上层）才真正联结起来。首席执行官开始领取优先认股权，从而代替部分薪水，在毫不相干的公司之间来回跳槽，并以有权力裁掉大批员工而自豪。恶性循环就这么产生了：员工不再对公司忠诚，公司也不再考虑员工，在这种氛围下，自然需要增加对员工的监管和监督程度。

然而出于某种原因，我们整个社会集体做出了决定：让数百万人经年累月地假装忙碌（敲击各种有的没的内容到电子表格里，准备各种奇奇怪怪的思维导图以备公关会议上进行展示，等等），

经济学这门学科本身就产生于道德哲学（亚当·斯密正是道德哲学教授），而道德哲学最初则是神学的一个分支。许多经济学概念都可以直接追溯到宗教思想上，因此，关于价值的争论总是避不开神学的影响。

因此，任何狗屁工作从事者，或者认识狗屁工作从事者的人都清楚地知道，市场并非永不会出错的价值评判者。

本来士兵 A 扛着计算机走 5 米路就搞定的一件事，最后成了另外两个人合计开 6~10 小时车、填大约 15 页纸质表格，并花掉纳税人整整 400 欧元这样荒谬的操作。[

但倘若消失的是对冲基金经理群体、政治顾问群体、行销大师群体、游说人员群体、企业律师群体或者那些每天的工作就是跟人道歉“木匠又来不了了”的行政人员群体，那这个世界才不会遭到什么严重的打击呢！

很少有经济学家真正试图去测量各职业的总体社会价值，大部分经济学家很可能觉得这种尝试注定会白费功夫，而极少数真的

工作的有用性和经济回报之间确确实实是成反比的。

根据他们的估算，在贡献值能够计算出来的工作中，社会价值最高的要属医疗研究员了，他们每拿一美元的薪水，就能够给社会带来 9 美元的总价值。而社会价值最低的则是金融领域从业者，他们每赚取一美元报酬，平均能给社会带来 1.5 美元的价值损失（而且别忘了，金融领域从业者赚的报酬那可是高得不得了）。

·城市银行家，年薪约 500 万英镑。据估计，他们每赚取 1 英镑，就会造成 7 英镑社会价值的损失。

·医院清洁工，年薪约 1.3 万英镑（时薪 6.26 英镑）。据估计，他们每赚取 1 英镑，就能产生 10 英镑的社会

虽然如此，从这项研究既有的结果来看，我们还是可以得到有力的数据支撑，从而证明：你的工作越是对他人有助益，这份工作带给你的经济回报往往就越少。

不过也有例外，最突出的就是医生了。医生的收入在整个收入等级中位于顶端，尤其是在美国，但他们的的确确造福了他人，这一点无可争辩。

狗屁工作是一份毫无意义、毫无必要且往往有害的工作，连其从事者都无法证明其存在的合理性。

没错，现在留给大学教师阅读和写作的时间越来越少了，他们的大量时间都被拿来应付各种行政事务。[18]即便有人有了某项振奋人心的新发现，他也不能表现得太过明显，因为当其他人都在做着自己不喜欢的工作的时候，你若是表现出享受，这样的行为会被认为不够体贴。不同高校之间，此种“反知识”氛围有轻有重。但是不管在哪，起码对一件事大家是有共识的：每个人职业中令人愉悦的那部分，比如思考，并不是他们领到薪水的原因，与其说这令人愉悦的部分是工作的一部分，不如说是某人“真正的工作”（主要就是填写各种表格）完成后，作为一种肯定，被偶尔允许的放纵和沉迷。

比如，纽约大学一位名叫杰夫·舒伦伯格的写作教师，在看了我 2013 年最初那篇文章后写了篇博文。他在博文中指出，现在许多公司都觉得，如果某份工作能够给人带来满足感，不管是什么方面，只要有满足感，公司就可以不支付报酬。

舒伦伯格谈到了“志愿者阶级”的兴起。资本企业正将成果收割之手从有偿劳动力的身上慢慢移开，越来越多地伸向了无偿实习生、互联网爱好者、积极分子、志愿者和发烧友。此外，在各大平台投注热情和创造力的互联网用户大军也成为数字时代的“佃农”，他们投注的热情和创造力被资本转化为私有产品出售。[

软件工程工作被分割成了两部分，一部分是有趣又有挑战性的核心技术开发，另一部分则是无聊乏味的“拼接修补”工作，用来拼接各项核心技术，以便这些核心技术可以协同作用。

这就导致了很有意思的恶性循环：既然有人愿意免费做核心技术，那就没什么公司愿意花大钱投在核心技术的开发上；而投资不足则导致了核心技术的开发有始无终、质量堪忧、故障毛病一大堆……于是，公司又不得不花钱雇用更多的拼接修补者进行后续处理。

亚里士多德坚持认为，工作绝不能让你成为更好的人，事实上，工作只会让你变得更糟，因为工作占用了太多时间，剥夺了人们履行社会职责和政治职责的机会。因此，每当古典文学谈及工作，都往往倾向于强调其惩罚性的一面。

而在中世纪和文艺复兴时期的北欧，几乎每个人都需要在人生中的某个阶段亲自干脏活。[6]因此工作，尤其是领薪工作，发生了革命性的变化。

拥有资本的那部分人成为雇主，而没有资本的那部分人则不得不替他们打工。这对个人意味着什么呢？首先，成百上千万的年轻人发现他们陷入了社会意义上的永久青春期出不来。随着同业公会结构的瓦解，学徒虽然依然可以从新手变成熟手，但从熟手成为独立经营者的老路已经不复存在，这也就意味着，从传统角度来看，他们是不具备谈婚论嫁、组建家庭的资格的。他们构成了事实上的“不完整的人”，如此过完一生。[

无产阶级”这个词的英文来自拉丁文，该拉丁文短语直译为“那些生产后代的人”，可以说很贴切了。在古罗马，那些穷到没办法向他们征税的最贫穷的市民，对政府来说唯一的用处就是生孩子了，源源不断地生儿子，为军队做好储备。

从传统意义上来说，青少年通过工作，或者更确切地说，通过“在主人严密监督下的领薪工作”，最终学会了如何成为合乎习俗的、自律的、自给自足的、体面的成年人。可事实上，清教徒等各种虔诚的风俗改良派已不再能够像原来那样向穷人承诺什么了，曾经的“无须听从他人命令、自给自足生活的成年人身份”肯定是没法再提供了，于是他们通过慈善和戒律，通过注入更新后的神学理念来替代之前的承诺。他们教导穷人，工作既是惩罚也是救赎。工作是自我禁欲，其本身就有价值，这种价值甚至超越了工作所能产生的财富，工作纯粹是上帝施予人类恩惠的标志，可不是拿来给你们享受的。[

卡莱尔最终得出一个结论，而这个结论正是今时今日许许多多人所得出的：如果工作是高贵的，那么最高贵的工作不应该获得报酬，因为给这样一件有着无上价值的事物标上价码，实在污秽可憎（“

在当时，“资本家”一词基本算是骂人的话。比如时任美国总统亚伯拉罕·林肯在 1861 年第一次发表国会年度咨文时说：“劳动先于资本且独立于资本，资本只不过是劳动的成果；若是没有劳动，则绝对不会产生资本。劳动优于资本，远远更为值得关注。”

建立在清教徒基础上的新教教义广受欢迎，人们不仅称颂工作，甚至还觉得“工作赋予人以神圣职责，以及在道德上和政治上胜于闲散有钱人的权利”，这是我的人类学家同行迪米特拉·多卡斯和保罗·达伦伯杰总结出来的。这可以说是比卡莱尔的“工作福音”（大部分历史学家直接称之为“生产主义”）更明显具有宗教意味的说法。“工作福音”就是，工作不仅自身具备价值，还是价值的唯一真正生产者。

到 19 世纪 90 年代，他们开始宣扬一种新的思想：与人们的认识恰恰相反，创造财富和繁荣的并非劳动而是资本。强大的企业利益联盟努力在学校、大学、教堂和市民团体中宣扬新的理念，试图彻底改变人们的看法：“商业已经解决了工业社会根本性的道德问题和政治问题。”

钢铁大亨安德鲁·卡内基是这场文化运动的领导者。面向劳动者阶层的时候，卡内基大肆宣扬被我们当代人称为“消费主义”的理念：资本“集中”后，在正确人的正确管理下，实现高生产率，从而大大降低商品的价格，以至未来每个工人的生活质量堪比往日的国王。而面向精英阶层的时候，卡内基则表示，给穷人高薪会把他们宠坏，对“民族”

曾经的桶匠、运货马车制造师傅和女裁缝都把自己视作某种传统的继承者，为此自豪并拥有各自隐秘的知识和技能，然而随着管理革命的到来，由行政管理组织起来的公司开始登场，“科学管理”竭尽全力追求效率，从此工人成了机器的延伸，他们不再自主工作，而是在他人设计好的流程下机械执行。

短短不到一代人的时间里，“生产主义”就已经被“消费主义”取代。用哈里·布雷弗曼的话来说：“象征地位的不再是生产力，而是购买力。”[

劳动价值理论也因“边际革命”而被踢出经济理论的赛场，慢慢地越来越不被普通大众熟悉，以至到了今时今日，除了革命马克思主义理论小圈子和研究生几乎没人知道。

在我看来主要原因在于，最初的劳动价值理论本身就存在瑕疵，这个瑕疵便是对“生产”的过分关注。正如前文已经分析过的，“生产”这个概念是有神学根源的，并且存在明显的父权偏见。甚至在中世纪，基督教上帝的形象就是匠人和技师，[5]人类工作（几乎总是被默认为男性工作）就是制造、建造东西，或许还有耕作，而对女性来说，“劳动”被象征性地视为生儿育女，她们付出的其他劳动则大都遭到了彻底忽略。

因为生产率的惊人增长，人们的注意力只会集中到机器和人究竟谁更重要的争论中，事实上，这个议题贯穿整个 19 世纪，一直是政治经济问题的辩论焦点。

早期工厂主最开始的时候，大都本能地选择去雇用女性和孩子而非男性，毕竟人们往往认为女性和孩子更加温顺，更加习惯于单调的重复性工作，尤其是女性。这带来的结果往往相当残忍和可怕。与此同时，此种状态也导致传统的男性匠人陷入颇为痛苦的境地。他们不仅被淘汰出局，无法进入工厂这个新的工作环境，还要承受家庭内部的变化——曾经被吆来喝去的妻子和孩子，如今成了家里的顶梁柱。

而这场反抗的浪潮最终能够退去，其中一个关键因素似乎正是某种心照不宣的社会妥协：人们逐渐认同，工厂应当主要雇用成年男性。

事实上，从来就没有出现过大部分工人都在工厂工作的时期。

女仆、擦鞋匠等工作是否属于“生产性工作”？又在何种意义上可以算作“生产性工作”？生产的东西又由谁消费？是谁“生产”出了蛋奶酥？正是因为这些都很难清晰界定，因此探讨价值议题时，大家往往直接把这些忽略掉。然而这种忽略会让我们看不清现实，即大部分工人阶级，不管是男性还是女性，从事的工作事实上都更接近人们眼中的典型女性工作：照顾照料，需求满足，解释说明，安慰鼓励，揣度上司心理，更别提照料动物、植物、机器等物件以及观察和养护等工作了。与此同时，锤打、雕刻、重物搬运、庄稼收割等工作反而是少数。

只不过，就像和人们在谈论“经济”的时候总是把女性那些无偿照料工作忽略不计一样，工人阶级岗位中那些涉及照料方面的工作也同样被抹去了。

照料工作总体上被看作面向他人的工作，并且总包含一些与解释、移情和理解相关的工作。

下面是我的想法：许许多多工作严格来讲并不是生产性质的，而是照料性质的，哪怕那些看起来最没有人情味的工作，我们也总能从中找到体现出照料特性的地方。这一点为我们提供了某种合理性解释，来告诉我们为何换套规则、换种社会的想法不现实。哪怕我们不喜欢这个世界现在的样子，我们也无法改变一个事实，那就是我们的大部分行为，不管是不是生产性的，都在有意识地照料他人，而且往往是照料特定的他人。

我们可以总结如下：1.大部分人的尊严感和自我价值感与工作谋生息息相关。2.大部分人憎恨自己的工作。我们可以将之称为“现代工作的悖论”。

今日狗屁工作激增，主要原因在于掌控富裕经济体（同时也在逐渐掌控非富裕经济体）的管理主义封建制度的独特性。狗屁工作之所以给人们带来了痛苦，是因为人类幸福感的源泉是来自一种对这个世界能产生一定影响的感觉，而当提及自身工作的时候，人们大都会将这种感觉同社会价值等同起来。但是与此同时，他们意识到一点，一份工作产生的社会价值越大，它能给工作者带来的经济回报则越小。诸如安妮这样的工作者，他们不得不在社会价值和经济回报中做出抉择：若是选择了社会价值，你就可以从事照顾孩子这样有用且重要的工作，但是你却被不断告知，帮助他人所获得的满足感本身就是这份付出的回报，至于如何养活自己，那你自己想办法好了；若是选择了后者，各种各样的生活开销是没问题了，但是却需要接受一份毫无意义且备受侮辱的工作，付出了身心俱疲的代价却丝毫不能带来任何价值，当然能够符合“如果你没有因为工作而身心俱损，那么你就没有正确地生活，不管这份工作是否有意义”这种普遍的价值观。

某份工作实际生产效能越低、造福他人价值越少，这份工作从自我牺牲意义上出发的价值便越大，也就是说，任何使工作变得好玩、变得不再繁重的事情，哪怕是因造福他人而产生的满足感，都会被视作削弱了这份工作带来的自我牺牲价值。所以，如果某份工作给人以满足感，那么“经济回报就比较低”这个现象也就有理论基础了。

人类工作越来越辛苦是因为人类创造了某种奇怪的施虐受虐逻辑论证法，通过这种逻辑论证，我们觉得只有在工作时不断感受痛苦，才能赋予我们那些隐秘的消费主义愉悦感以合理性。在这种理念的驱使下，工作占据了我们越来越多的时间，于是人们不再享有“生活”这件奢侈品——这是卡蒂·威克斯[1]的简洁概括，这又导致隐秘的消费主义愉悦行为成为我们仅有的选项。

但事实上，中层管理者乃至他们的行政助理，的的确确憎恶工厂工人。之所以出现这种情绪，原因很简单，因为工人可以堂堂正正为自己的工作感到骄傲。工人的报酬之所以过低，很关键的一点正是“道德嫉妒”。

再一次，我认为这只能用“道德嫉妒”来解释。在大家看来，教师是主动选择了自我牺牲，主动选择了为社会做贡献，而且充满了炫耀。他们是为了成为 20 年后能够接到“谢谢您为我做的一切”感恩电话的那种人。而这样的人竟然组织起工会，竟然以罢工相威胁，竟然要求更好的工作环境，这也太虚伪了吧！

士兵不仅不会因为从事的工作既高尚又高薪而被憎恨，恰恰相反，他们是永远不被憎恨的群体。他们超越一切批评。

在这个文明社会，白人工人阶级可以说是美国唯一一个受到各种偏执言论（比如说他们又丑又蠢还充满暴力）抨击却无人站出来维护的身份群体了。

电影业逐渐被一个“好莱坞阶级”统治，不断地“近亲繁殖”。因此，当好莱坞名人提出平等主义政治主张时，大部分美国工人阶级听着都会觉得有那么点空洞，也就没什么奇怪的了。

重回上一章提到的“价值”和“价值观念”的对比，我们或许可以这么说：如果你的目的仅仅是挣大钱，那么也许存在某种可能的路径，但如果你想要追求金钱以外的其他价值，不管这个价值是真实（新闻、学术），是美（艺术、出版），是正义（激进运动、人权），还是慈善，等等，而你同时还想拥有体面的收入，那么除非你有一定的家族财富、社会人脉和文化资本作为背景，否则绝无可能。

针对知识分子的阶级憎恨情绪主要来自美国白人工人阶级，而非裔美国人、移民及移民后代往往对反知识分子的政策持拒绝态度，他们依然将教育视作后代社会晋升的最可靠手段。这就令底层白人很不平，他们觉得非裔美国人和移民没有跟他们站在同一条战线上，反而跟富裕自由派白人结成了联盟。

这么说吧，如果那名卡车司机的女儿真正下定决心要找到一份既能满足自己追求无私和高尚理想，又能支付租房费用和体面看牙费用的工作，那她还有什么选择呢？如果她禀性虔诚，那或许可以试着在当地教堂找个岗位，但此类岗位不容易获得。如此，只剩参军一个选项了。

这些公司往往喜欢培养反知识的总体气氛。在我工作过的耶鲁大学，大家都知道，那些公司负责招人的行政人员更喜欢招耶鲁成绩为“良”（而不是“优”）的学生，因为成绩为“良”的学生更可能是“他们觉得相处起来会舒服的”那种人。

清教主义就是对世界上某个地方的某个人可能是开心的这件事感到一种挥之不去的恐惧。

不难证明，苏联经济当年之所以被搞得一团糟，主要是因为他们未能开发出足够强大的计算机技术去自动协调规模如此庞大的数据。可是苏联在 20 世纪 90 年代就结束了，现在情况不同了，这样的技术将不再困难，然而没人敢指出这一点。

要证明未来所有机器人和复制机都应是人类共有财产这一点并不困难，毕竟它们是人类作为整体、运用集体机械智力、历经几百年时间共同创造的成果。这就跟民族文化差不多，人人创造，归属人人。

临时定义 2：“狗屁工作”是一份毫无意义且往往有害的工作，连其从事者都无法证明其存在的合理性，虽然他不得不假装这份工作有意义。

因此，在自动化技术越来越先进的背景下，照料类工作才是真正的价值所在，这一点也会变得越来越突出。

工作中照料方面的价值恰恰是劳动中没有办法被量化的那部分。

真正的工作正在不断狗屁化，而广泛意义上的狗屁岗位也在不断增加，在我看来，这很大程度上是人们试图去量化那些没有办法被量化的内容所导致的直接结果。直截了当地说，自动化使某些工作可以更高效地完成，但与此同时，自动化也使其他工作的完成效率降低。

就“照料工作可以或应该由机器人承担”这样的想法，人们已经尝试了很久，想要将其普及化。但我觉得现在并没有普及，最终也不可能普及。

事实上，自动化确实导致了大规模失业，只不过我们用大量硬造出来的“挂名岗位”把这个失业口子补上了而已。

再加上乔治·奥威尔 1933 年就提到过的来自上层阶级的恐慌，即上层阶级对劳动大众“若拥有过多闲暇时光，就不知会做出什么事”的恐慌，导致在富裕国家，一旦涉及官方失业率这个数据，真实情况就已不再重要，人们想做的只是用尽一切办法，使这个数字能够被控制在 3%~8% 这个区间。

正如卡尔·马克思曾经指出的，工业革命之前，似乎没有任何人想过要写一本书，来探讨在何种情况下人类才能够创造出最大的总体财富。倒是有许多人写书探讨怎样的环境才能创造出最好的人，即如何最佳地组织社会，才能培养出值得喜爱的人，不管这个人是作为朋友、爱人、邻居、亲戚还是同为公民。这类问题，亚里士多德、孔子、伊本·赫勒敦[3]都苦苦思索过，但直到现在，此类问题依然是唯一真正重要的问题。

从现实的角度来看，美国的右翼民粹分子从公司主义左翼手中抢过人类生产大型组织的控制权的可能性，和社会主义政党在美国掌权并将重工业集体化的可能性差不多。

主流左翼主要控制着人的生产，主流右翼则主要把持着物的制造。

然而自美国的克林顿和英国的布莱尔以来，那些表面上的左翼政党便成了“金融治国”的头号拥护者，金融领域也成了这些政党资金的最大来源。

正是在此时期，这些政党自觉主动地抛弃了它们原来的主要支持者，即工人阶级，转而开始为职业经理阶级代言，正如汤姆·弗兰克已经有力论证的那样。这些政党成为“职业经理阶级的政党”，即不仅成了医生和律师的代言人，还成了那些照料部门狗屁化的罪魁祸首——行政人员和经理的代言人。[

如果护士想反抗轮班时不得不花费大部分精力来应付文书工作，那么他们就不得不向自己的工会领导发起抗议，而这些工会领导与拥护希拉里·克林顿的民主党合作紧密，而追随希拉里·克林顿的民主党的核心支持者就来自医院行政人员，也就是那些一开始给护士安排文书工作的人。

比如 2006 年，我当时因为支持了参与教师工会化运动的研究生，耶鲁大学就忙着策划把我开除了（为了把我踢出去，人类学系不得不专门申请了一个对教师再任用政策进行调整的许可，只是为了对付我一个人）。

请记住，中世纪时期，哪怕是农奴，每年工作的时间平均下来也远不到每周 40 个小时。

声称人们必须每周工作 40 个小时（而这项工作本身其实不用做的）是为了防止他们酗酒、抽烟或犯罪，和声称地球上所有人都应该每周被关进监狱 40 个小时来作为某种预防性拘留，这两种说法有什么区别吗？

关于在什么情况下、什么人、从什么地方获得了最多的钱这些细节大家可能会有不同意见，但毫无疑问，正是在比尔·克林顿的主导下废除了《格拉斯——斯蒂格尔法案》，使资本实现了“自由化”，从而直接导致 2008—2009 年的金融危机。而在英国，正是托尼·布莱尔首次在英国大学引入学费。

但是事实上，除非“我们”恰好属于那 3%~5% 能够左右政策制定者的群体，不然一切不过就是场自欺欺人的游戏。我们把自己放到统治者的位置思考问题，却忘了自己其实是被统治者。

在现有社会运动所倡议的各项解决方案中，我能找到的能够缩减政府规模、降低政府侵扰性的方案，就只有全民基本收入这一项了。

莱斯莉告诉我，有研究表明，任何个人经济状况调查体系，不管如何拟定，都必然导致至少 20% 符合资格的人直接放弃补助金申请。这个数字几乎超过了这套体系可能检测出的“骗子”的数量。事实上，哪怕算上那些被误算的“骗子”，“骗子”数额也仅仅达到 1.6%。

在这样一套审核规则以及规则的随意解读的共同作用下，目前在英国，有资格领取失业金的人中有 60% 的人并没有领到。

这个庞大组织存在的意义不过就是为了延续一个错误观念，即人类生来懒惰，他们并不想工作。出于这样的动机，哪怕社会确实有责任保证生活在其中的人不被活活饿死，大家也会想方设法使这个帮助人类继续生存的过程尽可能地令人感到迷惑，让人耗费时间，使人感到屈辱。

高兹是这么评价“家务劳动有偿化”的：如果一直用严格的金融视角来强调照料工作对于全球经济的重要性，那么就可能存在这样的风险，即给各种照料工作赋予以美元为衡量标准的“价值”，并声称这才是其真正的“价值”。如果这种风险成为现实，那么越来越多的照料行为就会在经历货币化和量化之后陆续终结，因为此类工作的货币化往往意味着质量的下降，尤其当这些照料工作是一系列固定任务，且被要求在固定时间内完成时，而现实往往正是如此。

最终版本临时定义：狗屁工作是一份毫无意义且往往有害的定期领薪水的职业，其无意义或有害程度是如此之高，乃至从事这份职业的人都无法为其找出合适的存在理由。虽然要从事这份工作有一个条件，即从事者不得不假装这份工作的存在是完全合理的。

因为从 70 年代起，你能看到的任何一次薪水平等化，只要仔细研究所有事实就会发现，这主要是由工人阶级男性的薪水下降导致，而非女性的收入有所增加。它们一直试图让我们彼此对立，而这正是所有使用相对价值法对不同工作进行评估所必然包含的目的了。

任何全民基本收入的金额都必须满足生存的需要，使大家单单依靠这份收入就能够生存，并且全民基本收入的发放必须完全不设限，每个人都能拿到，哪怕是不需要这份收入的人。建立这样的准则是值得的：关于这份生存必需金，所有人都理应得到，一视同仁，不加任何限制条件。这就使其成为一项人权，而非仅仅做慈善或者改善缺乏其他形式收入的状况。

若分发这笔钱需要在对所有人进行个人经济状况调查后再给予，这个调查甚至包括对亿万富翁的调查，那么就不得不建立专门的行政机构来实施，按照历史的经验，这样的行政机构必然会不断扩张。

全民基本收入最终的目的是将生计与工作分离。全民基本收入方案一旦实施就会立竿见影，行政官僚机构将急剧减少。

表面上来看，全民基本收入似乎是对国家权力的一次大型扩张，因为我们会假设这笔钱的制造和分发会由政府或者某种类似央行这样的半国家机构实施，但事实恰恰相反。大量的政府部门，而且正是那些最具侵入性、最可憎的政府部门，在实施全民基本收入后，将立刻成为多余的机构，并面临关门，因为这些机构最深入地参与了对普通公民进行的道德监视。[

是这样，我跟华尔街这些掌权者中的许多人都会定期见面……我熟悉他们。我跟他们一起用午餐。现在我就直截了当地说了：我认为这些人的道德不怎么样，整个圈子环境都是病态的。他们没有责任心，不管是对待他们应缴纳的税收，还是对待付钱给他们的客户，抑或是对待交易时的对手方。他们强硬、贪婪、攻击性强，他们觉得自己可以完全不受控制，他们将体制玩弄于股掌之间。

“狗屎工作”和“狗屁工作”几乎可以说是完全相反的工作。“狗屁工作”往往能带来很不错的收入，工作环境也极佳，只不过毫无意义；而“狗屎工作”恰恰相反，这些岗位对社会来说必要且有益，只是这些从业者收入很低且工作环境很糟糕。

陀思妥耶夫斯基在西伯利亚劳改营流放期间，提出了一种理论：世界上最残酷的折磨便是强迫人无休止地做一件明显毫无意义的工作。

联邦快递以及联合包裹的快递员，他们的工作是公司根据“科学高效”的方法设计安排的，快递员每天都累到爆。但是这两家公司管理层的日常工作，可就完全不是那么回事了。如果愿意，我们可以把这种现象追溯到管理层效率崇拜的致命弱点（如果愿意，你还可以称之为“效率崇拜的阿喀琉斯之踵 [4]”）。当管理者试图想出最省时省力的科学工作方法，并将它们应用到员工身上的时候，他们从未将这套科学工作方法应用到自己身上，或者即使应用到了自己身上，他们也会发现效果与预期的恰恰相反。

这些公司在做的事情似乎就是，无休无止地挤干工厂车间里最后的一滴油，然后将节省下来的燃料倒到办公室里，在毫无意义的岗位周围再添置新的浪费（后文我们会看到有些公司确实就是这么做的，毫不夸张）。这一切的结局便是，正如苏联曾带来了无数虚设的岗位那样，资本主义制度最终也不知道怎么回事就一手创造了无数虚设的白领岗位。

一位女性，如果作为全世界认可的学者，她通过教书所赚取的收入仅是她去跳脱衣舞所赚取的 1/5，那么单凭这一点，我们就可以说脱衣舞娘这份工作属于狗屁工作，难道不是吗？

在这个社会中，起码有一半的工作可以被删除，而且删除后不会产生任何实质性的影响。

我的壶铃训练计划

Thu, 26 Jan 2023 11:07:20 +0800

自从去年 5 月搬家之后，附近没有什么健身房，考虑疫情带来的各种不确定性也不太想在健身房练了。于是我就买了几个壶铃自娱自乐，最近还买了一个棒铃。练壶铃我主要参考的是网络上硬式壶铃的各种资料，包括：

著名壶铃大师 Pavel Tsatsouline 的各种文章和视频
Mark Wildman 的 Youtube 频道
Hardstyle Kettlebell Pro 的 Youtube 频道

Simple and Sinister

最适合我这种初学者的，是 Pavel Tsatsouline 的 Simple and Sinister (S&S) 计划。S&S 是一个极简计划，就壶铃摇摆 (Swing) 和土耳其起立 (TGU) 两个动作，简单而有效。这里简单介绍一下这个计划，有机会的话还是买书支持一下吧。

S&S 每天进行相同的锻炼，每周 5-6 天。

热身：10 次壶铃绕颈 (halo)、10 次臀桥、10 次壶铃的高脚杯深蹲并在蹲下时活动关节 (kettlebell prying goblet squat)。
5 组 10 次双手壶铃摇摆。
10 次土耳其起立（每侧 5 次）。

随着你变得更强壮，从 5 组 10 次双手壶铃摇摆变为 10 组 10 次双手壶铃摇摆（总共 100 次）；然后慢慢地用交替的单手壶铃摇摆组替换，直到你以完美的形式进行 100 次单手壶铃摇摆。再逐渐减少休息，直到你可以在 5 分钟内以完美的姿势完成 100 次单手壶铃摇摆动作，即每 30 秒 10 次壶铃摇摆。

对于土耳其起立，有耐心的慢慢做，专注于动作是否标准。最终，你会变得足够强壮，可以花 10 分钟完成 10 次，左右轮流做，每侧 5 次。

所以，最终你会进步到：

热身
5 分钟内 10 组，每组 10 次单手摇摆（每只手 5 组）。
10 分钟内进行 10 次缓慢的土耳其起立（每侧 5 次）。

到了这个阶段，你就可以进阶了，换更重的壶铃。这里面土耳其起立是比较困难的，我是从 16KG 壶铃开始的。因为以前有练过，完成 100 个单手壶铃摇摆很轻松，但是 16KG 壶铃的土耳其起立一个都起不来。有耐心一些，总会进步的，现在我已经迈过了 20KG，开始练习 24KG 的壶铃了。

对于男性，Pavel 制定了 Simple 和 Sinister 两个标准。Simple 是使用 32KG 壶铃完成 S&S，Sinister 是使用 48KG 壶铃完成 S&S。我期望自己能完成 Simple 的标准就好，也足够强壮了。

Nerd Math

随着我每周的训练日增加，S&S 有些太单调了，我真的做不到每周六天都练 S&S。所以我在网上搜罗了很多的壶铃训练计划，但是有两个问题：

网上流传的大部分是单次或者针对单个动作的练习（workout），workout 不提供系统的进阶方案；而我需要的是训练计划（program），是一个体系，我要按照这个体系安排我的每次训练，并衡量我是否进步。
壶铃训练的动作很多，安排非常灵活，不同的人对壶铃的重量、次数、动作喜好都不同。网上的计划未必适合我，或者满足我的需求。比如有的计划是需要双壶铃的，而我出于省钱和空间的考虑，每个重量只买了一只。

幸运的是有一位名为 Mark Wildman 的训练师在 Youtube 上分享了许多他的训练理念，以及各种壶铃和棒铃动作的细节。他有一个专门的 Nerd Math 系列，介绍壶铃和棒铃训练计划安排的原理。根据他的理论，我安排的计划如下：

把壶铃动作分为 Swing + TGU 和 Clean & Press + Squat 两组，一天练其中一组。
每个壶铃动作在一周内练两次，一天是 heavy，一天是 light。Heavy day 代表通过增加重量或者每组次数增大强度 (density)，也可以是通过组数来增大容量 (volume)；Light day 则表示这个动作今天应该较为轻松。对于壶铃训练，一天内不同的动作有的 heavy 有的 light。
每次训练的末尾可能加入一些如俯卧撑、健步蹲之类的辅助练习。
其他时间按照心情练习壶铃 Snatch、单手棒铃、瑜伽或者休息。

一个范例如下：

星期一	星期二	星期三	星期四	星期五	星期六	星期天
Swing (heavy): 24kg x 10 x 10	Clean & Press (heavy): 20kg x 5/4/3/2/1 x 5 rounds	Heavy club mill	Swing (light): 24kg x 10 x 10	Clean & Press (light): 16kg x 5/4/3/2/1 x 5 rounds	Heavy club mill	Yoga
TGU (light): 20kg x 10 x 1	Squat (light): 16kg x 20 x 5/5	Heavy club reverse mill	TGU (heavy): 24kg x 10 x 1	Squat (heavy): 20kg x 20 x 5/5	Heavy club reverse mill
Push-ups	Various lunges	Heavy club swipe	Push-ups	Various lunges	Heavy club swipe

这个计划的好处是星期一和星期四的训练基本是延续 S&S，我可以继续在 S&S 上进步，然后又增加了更多动作和乐趣。

对于 Clean & Press，采用倒金字塔的组数，进阶的方式如下：

从 3/2/1 x 3 rounds 开始，逐渐增加到 3/2/1 x 5 rounds
然后改为 4/3/2/1 x 3 rounds，逐渐增加到 4/3/2/1 x 5 rounds
最后改为 5/4/3/2/1 x 3 rounds，逐渐增加到 5/4/3/2/1 x 5 rounds
完成 5/4/3/2/1 x 5 rounds 之后，就可以增加壶铃重量

对于深蹲 (sqaut)，假设我们采用 single-arm kettlebell front squat，因此 20 x 5/5 代表 20 组，每组壶铃放在左边做 5 次，右边做 5 次。如果想提高训练容量，进阶方式可以是：

4 x 5/5
6 x 5/5
…
20 x 5/5

完成 20 x 5/5 之后，可以选择增大壶铃的重量，也可以增大训练的强度：

20 x 5/5
16 x 6/6
14 x 7/7
12 x 8/8
10 x 10/10

通过增加每组的次数，减少组数，我们可以完成相同的训练量，但是对身体的负荷更大。

单手棒铃的每次练习中做三种动作，三种动作的进阶方式如下：

Easy	Medium	Hard
Inside Circle	Inside Pendulum	Mill
Outside Circle	Outside Pendulum	Reverse Mill
Shield cast	180 Rotating Pullover	Swipe

对于单手棒铃，每种动作的进阶方式可以采用类似深蹲的方式（注意，壶铃抓举也可以采用类似的方式）：

4 x 5/5
6 x 5/5
…
20 x 5/5

Review 2022 & New Year's Resolution 2023

Sun, 01 Jan 2023 23:26:10 +0800

随着年龄的增长，感觉时间过的越来越快了，是时候要思考一下未来了。

2022 年的个人生活，被疫情影响的很严重。年初的春节，连续第二年没有能够回家过年。在 5 - 6 月和 11 - 12 月，由于北京的疫情封控，以及放开后的大面积感染（公司里几乎无人幸免，好在我和家人症状不重），我有大量的时间是居家办公的。幸运的是，在 5 月换租到了一个两室一厅，虽然远了很多，但在家里和伴侣的生活质量高了很多。漫长的通勤时光，给了我不少听播客和看书的时间。新家在海淀北边的一个偏僻小镇，已经出了共享单车的运营范围，点外卖都没什么选择，所以花了很多时间自己做饭。所幸的是，附近的农贸市场和超市有很多原材料或半成品卖，新鲜的蔬菜和肉类、烤鸡烤鸭、卤菜、凉皮、烧饼、面食、我觉得质量很不错的清真羊肉。想糊弄的时候，可以简单的糊弄一下。想吃好点，也可以精心的准备一下。我觉得做饭还是很有乐趣的，现在的拿手菜已经不少了，有各种烤肉、大盘鸡、羊肉手抓饭、意大利面以及各种炒青菜。新添置的空气炸锅，帮了大忙，我基本是当作烤箱用，常常用来烤肉和烤面包。烤面包是今年我的一大发现。有了面粉、酵母，其实自己在家做面包很简单。我做的应该算是硬欧包，不怎么需要和面，全靠酵母的力量。烤出来后面包的表面很硬（可以砸人），内里松软，是我喜欢的类型。还可以按照心情，加入葡萄干、坚果和奶酪。

工作方面，现在已经创业六年了。今年可以说是大破大立，做梦也没有想到会发生这么多事。这个改变来的太晚、太猛烈了，也许早一些会很不一样。很遗憾，也许人的本性决定，改革都是倒逼出来的。走了很多人，大部分是被动的，也有很多我们想留下的人，主动走了。走的人大部分都是好人，在这种经济形势下，真的是迫不得已。想起了前小老板的叮嘱：「Life is tough, so you must work harder」。大裁员的一个好处是，管的人和项目少了，我现在又有了很多写代码的时间，从 WakaTime 的统计上可以非常清楚的看出 coding 时间增长的趋势。写代码而论，我比大部分人写的都好多了，还是自己写比较开心。

我觉得创业几年，我做了很多管理、协调、打杂的事。诚然为人处世有所成长，但也有很多事情，既不让人愉快，对个人的成长也没什么好处。新的一年，还是应该花更多的时间，在个人的提升上。所以新年的 flag 主要还是关于个人成长的：

减重十公斤：自从 2011 年在腾讯实习半年，因为伙食太好长了十公斤以来，减脂就一直是我的目标。我觉得今年是时候把它写进年度 flag，完成它了。
学习一门新语言：我一直想学 Rust。Rust 一直以在 system programming 领域替代 C/C++ 为目标，这个趋势也越来越明显了。作为一个 system researcher，感觉再不学就说不过去了。工作中也许还是用不到，但我开心就好。
该繁衍后代了。

还有一件小事，就是希望持续学习的过程中，多写点东西。昨天，我换掉了 PhD 时期的主页，用 Hugo 做了这个博客。使用了 ʕ•ᴥ•ʔ Bear Blog 的风格，我觉得还挺好看的。

Research

Sat, 31 Dec 2022 22:15:29 +0800

I work at the AI lab of a private quantitative hedge fund, focusing on AI infrastructure and ML systems. My research interests center on AI agents for long-horizon tasks such as agentic coding and autonomous research workflows.

Before that, I was a member of Team Viking at ByteDance (2024–2026), working on the Viking engine — an approximate nearest neighbor search engine that drives recommendation systems for TikTok and Douyin, and also powers VikingDB, the vector database of Volcano Engine.

I joined Moqi as its first engineer (2017–2024) and led the infrastructure team. There, I directed the development of MyScale, a high-performance vector and full-text search engine based on ClickHouse. I also built two nationwide billion-scale Automated Fingerprint Identification Systems (AFIS) for the Chinese public security, and created the world’s first contactless fingerprint scanner, the Moqi A1, which achieves image quality comparable to traditional contact-based scanners.

Earlier, I worked as a researcher at Huawei Noah’s Ark Lab (2016–2017).

I hold a PhD in Computer Science from The Chinese University of Hong Kong (CUHK, 2016), supervised by Prof. John C.S. Lui at the Advanced Networking and System Research Laboratory (ANSRLab), where I focused on graph analytics and stream processing systems. I earned my Bachelor’s degree from Shanghai Jiao Tong University (ACM Honors Class).

Publications

Conference:

Graph Edge Partitioning via Neighborhood Heuristic
Chenzi Zhang¹, Fan Wei¹, Qin Liu, Zhihao Gavin Tang, Zhenguo Li.
The 23rd SIGKDD Conference on Knowledge Discovery and Data Mining (KDD), 2017 (oral presentation)
[paper] [code]
(AR of papers with oral presentation: 64/748 = 8.6%)
PowerWalk: Scalable Personalized PageRank via Random Walks with Vertex-Centric Decomposition
Qin Liu, Zhenguo Li, John C.S. Lui, Jiefeng Cheng.
The 25th ACM International Conference on Information and Knowledge Management (CIKM), 2016 (long paper)
[paper] [slides] [techreport] [code]
(AR of long papers: 165/935 = 17.6%)
Walking in the Cloud: Parallel SimRank at Scale
Zhenguo Li, Yixiang Fang, Qin Liu, Jiefeng Cheng, Reynold Cheng, John C.S. Lui.
Proceedings of the VLDB Endowment (PVLDB), 9(1), 2015 (also in VLDB 2016)
[paper] [poster on SoCC'15]
VENUS: Vertex-Centric Streamlined Graph Computation on a Single PC
Jiefeng Cheng, Qin Liu, Zhenguo Li, Wei Fan, John C.S. Lui, Cheng He.
The 31st IEEE International Conference on Data Engineering (ICDE), 2015
[paper] [slides] [poster]
SAND: A Fault-Tolerant Streaming Architecture for Network Traffic Analytics
Qin Liu, John C.S. Lui, Cheng He, Lujia Pan, Wei Fan, Yunlong Shi.
The 44th Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN), 2014 (practical experience report)
[paper] [slides]
(AR: 56/185 = 30.3%)
Combining Factorization Model and Additive Forest for Collaborative Followee Recommendation
Tianqi Chen, Linpeng Tang, Qin Liu, Diyi Yang, Saining Xie, Xuezhi Cao, Chunyang Wu, Enpeng Yao, Zhengyang Liu, Zhansheng Jiang, Cheng Chen, Weihao Kong, Yong Yu.
KDD-Cup Workshop, 2012 (First place in Track 1)
[paper] [slides]

Journal:

VENUS: A System for Streamlined Graph Computation on a Single PC
Qin Liu, Jiefeng Cheng, Zhenguo Li, John C.S. Lui. IEEE Transactions on Knowledge and Data Engineering (TKDE), 28(8): 2230-2245, 2016
(An earlier version appeared in ICDE 2015)
[paper] [doi]
SAND: A fault-tolerant streaming architecture for network traffic analytics
Qin Liu, John C.S. Lui, Cheng He, Lujia Pan, Wei Fan, Yunlong Shi.
Journal of Systems and Software (JSS), 122: 553-563, 2016
(An earlier version appeared in DSN 2014)
[paper] [doi]

First two authors are of equal contribution. ↩︎ ↩︎

Clickhouse 存储引擎

Thu, 08 Dec 2022 10:42:45 +0800

ClickHouse 实现高效 OLAP 查询的秘诀，在于它强大的存储引擎 MergeTree（合并树）。 MergeTree 在写入一批数据时，数据总会以数据片段 (data part) 的形式写入磁盘，且数据片段不可修改。而为了避免数据片段过多，ClickHouse 会通过后台线程定期的合并 (merge) 这些数据片段，属于相同分区的数据片段会被合并成一个新的数据片段，这种数据片段往复合并的过程，正是 MergeTree 名称的由来。

用 MergeTree 表引擎建表的语法如下：

CREATE TABLE [IF NOT EXISTS] [db_name.]table_name(
    name1 type [DEFAULT|MATERIALIZED|ALIAS expr],
    name2 type [DEFAULT|MATERIALIZED|ALIAS expr],
    ......
) ENGINE = MergeTree()
[PARTITION BY expr]
ORDER BY expr
[PRIMARY KEY expr]
[SETTINGS name1=value1, name2=value2, ......]

这里主要介绍 MergeTree 创建时需要指定的三种 key：

PARTITON BY: 选填，表示分区键 (partition key)，用于指定表数据以何种标准进行分区 (partition)。分区键既可以是单个字段、也可以通过元组的形式指定多个字段，同时也支持使用列表达式。如果不指定分区键，那么 ClickHouse 会生成一个名称为 all 的分区，合理地使用分区可以有效的减少查询时数据量。最常见的莫过于按照时间分区了，数据量非常大的时候可以按照天来分区，一天一个分区，这样查找某一天的数据时直接从指定分区中查找即可。
ORDER BY: 必填，表示排序键 (sorting key)，用于指定在一个数据片段内，数据以何种标准进行排序。排序键既可以是单个字段，例如 ORDER BY CounterID，也可以是通过元组声明的多个字段，例如 ORDER BY (CounterID, EventDate)。如果是多个字段，那么会先按照第一个字段排序，如果第一个字段中有相同的值，那么再按照第二个字段排序，依次类推。总之在每个数据片段内，数据是按照分区键排好序的，但多个数据片段之间就没有这种关系了。
PRIMARY KEY: 选填，表示主键 (primary key)，声明之后会依次按照主键字段生成一级索引，用于加速表查询。如果不指定，那么主键默认和排序键相同，所以通常直接使用 ORDER BY 代为指定主键，无须使用 PRIMARY KEY 声明。所以一般情况下，在每个数据片段内，数据与一级索引以相同的规则升序排列（因为数据是按照排序键排列的，而一级索引也是按主键、也就是排序键进行排列的）。

MergeTree 可以被看成简化后的 Log-Structured Merge-tree (LSM-tree)。在 ClickHouse 中一张 MergeTree 本地表对应一个目录。前面提到，MergeTree 中是有数据片段 (data part) 的，并且每个数据片段都对应一个目录，所以表对应的目录里面存储的是每个数据片段的目录，而数据片段目录里面存储的才是负责容纳数据的文件。所以一张 MergeTree 数据表在磁盘上的物理结构分为三个层级，依次是数据表 (table) 目录、数据片段 (data part) 目录和各目录内的数据文件。我们来看看一个名叫 part_names 的表格对应目录下的内容：

$ tree -L 1 part_names
part_names
|-- 202212_1_1_0
|-- 202212_1_4_1
|-- 202212_1_4_1_9
|-- 202212_2_2_0
|-- 202212_3_3_0
|-- 202212_4_4_0
|-- 202212_5_5_0
|-- 202212_5_5_0_9
|-- detached
|-- format_version.txt
`-- mutation_9.txt

上面的 202212_* 目录，就是代表数据片段的目录。数据片段的文件夹命名规则是：

<partition_id>_<min_block_number>_<max_block_number>_<level>_<data_version>

下面来解释一下这几个部分：

partition_id：分区 ID，分区 ID 是由分区键的取值决定的。分区键支持使用任何一个或一组字段表达式声明，其业务语义可以是年、月、日或者组织单位等任何一种规则，而针对取值数据的类型不同，有不同规则，详见脚注¹。
min_block_number、max_block_number：最小数据块编号和最大数据块编号，这里的命名很容易让人联想到后面要说的数据压缩块，甚至产生混淆，但实际上这两者没有任何关系。这里的 block_number 是一个自增的整数，从 1 开始，每当创建一个新的数据片段时就会自增 1，并且对于一个新的分区目录而言，它的 min_block_number 和 max_block_number 是相等的，例如 202212_3_3_0。当分区目录发生合并的时候，其 min_block_number 和 max_block_number 为参与合并的数据片段的 block_number 的最小值和最大值，例如 202212_1_4_1 就是 block_number 为 1 - 4 的数据片段合并后的新数据片段。
level：合并的层级，可以理解为该数据片段被合并的次数，这里的 level 和 block_number 不同，它不是全局累加的。对于每个因为插入而创建的目录而言，其初始值都为 0，之后如果相同分区的几个数据片段发生合并操作，则合并后的数据片段为合并前数据片段的最大 level 加 1。因此，202212_1_4_1 就经过了 1 次合并。
data_version: 数据的版本号，如果存在，说明该数据片段是经历了 mutation 后的生成的数据。在 ClickHouse 中， UPDATE/DELETE 等操作较为昂贵，使用 mutation 的方式来进行。Mutation 时，相关的数据片段会被完全重写成新版本的数据片段（重写时会生成新的数据片段目录，没有被修改的列会采用硬链接 (hard link) 的方式被复制到新的数据片段文件夹内，减少开销）。例如，202212_1_4_1_9 就是 202212_1_4_1 经过编号 9 的 mutation 后生成的。Mutation 的介绍详见 ClickHouse 官方文档。

在 MergeTree 中，伴随着每一次数据的插入 (insert)，MergeTree 都会生成一个新的数据片段 (data part)。数据片段在落盘后，就是不可改变的 (immutable)。ClickHouse 后台会调度合并 (merge) 线程将多个小的数据片段不断合并起来，形成更大的数据片段，从而获得更高的压缩率、更快的查询速度。因此，如果插入的粒度太小，且插入频率很高，可能会导致目录数过多进而耗尽文件系统的 inode，也会降低后台数据合并的性能，这也是为什么 ClickHouse 推荐使用大插入粒度进行写入且每秒不超过 1 次的原因。在选择数据片段合并时，ClickHouse 只会选择同一个分区 (partition) 中数据块编号 block_number 相邻的数据片段进行合并。因此，新数据片段的 partition_id 与旧数据片段相同。合并后，新的数据片段会自动变为活跃状态 (active)，被用于新的查询语句；旧的数据片段会被标记为不活跃，过一段时间（默认 8 分钟）后被删掉。而由于被合并的数据片段 block_number 相邻，所以当前活跃的数据片段的 block_number 总是不相交的。

数据片段有 Memory、Compact 和 Wide 三种格式。最常用的格式是列存储格式 Wide。Memory 和 Compact 仅用于较小的数据片段。下面用官方文档中的例子来说明数据片段目录内文件的作用。用以下 DDL 语句创建表：

CREATE TABLE hits_UserID_URL
(
    `UserID` UInt32,
    `URL` String,
    `EventTime` DateTime
)
ENGINE = MergeTree
PRIMARY KEY (UserID, URL)
ORDER BY (UserID, URL, EventTime)
SETTINGS index_granularity = 8192, index_granularity_bytes = 0;

然后导入数据并强制合并成一个数据片段：

INSERT INTO hits_UserID_URL SELECT
   intHash32(c11::UInt64) AS UserID,
   c15 AS URL,
   c5 AS EventTime
FROM url('https://datasets.clickhouse.com/hits/tsv/hits_v1.tsv.xz')
WHERE URL != '';
OPTIMIZE TABLE hits_UserID_URL FINAL;

操作之后，这个表的所有数据都会被存在一个 Wide 格式的数据片段中。总数据量有 887 万行。由于采用了列存储格式，所以不同列使用独立的物理文件存储。每个列至少有 2 个文件构成，分别是 .bin 和 .mrk 文件。其中 .bin 是数据文件，保存着实际的数据；而 .mrk 是保存元数据的 mark 文件（后面会详细介绍）。由于排序键为复合键 (UserID, URL, EventTime)，因此如下图所示，三列的 .bin 文件中，数据会按照 (UserID, URL, EventTime) 的字典序升序排列。

如下图所示，数据片段内的每列数据被按照参数 index_granularity 切分为多个 granule，默认值为 8192 行对应一个 granule。

主键索引 primary.idx 中存储着每个 granule 对应的第一行数据，也即在每个 granule 中各个列的最小值。主键索引中的每一行被称为一个 mark。

该表的主键索引共有 1083 个 mark，对应 1083 个 granule 的主键的最小值：

在查找时，如果查询包含主键索引条件，则首先在 primary.idx 的所有 mark 中进行二分查找，找到符合条件的 granule。例如，假如想查找 UserID = 749927693 的数据，我们可以通过二分查找锁定数据在 mark 176 中。因为 749,927,693 大于 mark 176 的最小值 742,414,531，小于 mark 177 的最小值 751,802,947。

ClickHouse 中的每列还有一个对应的 mark 文件，也就是上面提到的 .mrk 文件。当多个 grandule 的总大小达到 min_compress_block_size（默认 64KB）时，ClickHouse 会将多个 granule 压缩成一个 block。 Mark 文件中保存了每个 mark 的两个信息：

block offset: 当前 granule 所在的 block 在压缩后的物理文件中的 offset；
granule offset: 当前 granule 在解压后 block 中的 offset。

所以 block 是 ClickHouse 与磁盘进行 I/O 操作、压缩和解压缩的最小单位，而 granule 是 ClickHouse 在内存中进行数据扫描的最小单位。ClickHouse 支持多种压缩算法（比如常用的 lz4，对时序数据优化的 DoubleDelta 等）。下面这幅图展示了三列对应的 mark 文件：

下图展示了 ClickHouse 如何在 UserID.bin 数据文件中定位 granule 176。首先，如上文所描述 ClickHouse 通过二分查找在 primary.idx 中定位到了 mark 176。然后我们通过图中的 UserID.mrk 文件，拿到了 granule 176 的 block offset 和 granule offset。通过 block offset，我们在 UserID.bin 文件中找到了包含 granule 175 - 177 的 block，并解压缩。最后我们通过 granule offset 在解压后的数据中找到 granule 176。

借助于 mark 文件，ClickHouse 在定位出符合条件的 granule 之后，可以将 granule 平均分派给多个线程进行并行处理，最大化利用磁盘的 I/O 吞吐和 CPU 的多核处理能力。

常规的 OLTP 数据库一般采用 B+ 树索引，索引可以直接定位到行，显得更加稠密。而 ClickHouse 的主键索引的查找单位是 granule，相对来说比较稀疏，因此我们将这类索引称为稀疏索引 (sparse index)。ClickHouse 还支持用 skip index 为其他列创建稀疏索引。创建后，会额外增加两个文件 skp_idx_<index_name>.idx 和 skp_idx_<index_name>.mrk，用来记录对应 granule 的统计信息。比如：

minmax: 会记录各个 granule 的最小、最大值；
set: 会记录各个 granule 中所有不同的 (distinct) 值；
bloomfilter: 会使用近似算法 Bloom Filter 记录对应 granule 中，某个值是否存在；

这里举例说明，假设一个表有两列 my_key 和 my_value，并且我们想查找所有 my_value = 125 的数据。我们可以为 my_value 列创建 set 类型的 skip index。这里我们假设我们为每两个 granule 维护一个 set。如下图所示，我们可以通过 skip index 在查找时直接跳过 granule 63 和 64，但无法跳过 granule 62。

分区 ID 的生成逻辑目前拥有四种规则：
1. 不指定分区键：如果不使用分区键，即不使用 PARTITION BY 声明任何分区表达式，则分区 ID 默认为 all，所有的数据都会被写入 all 这个分区；
2. 使用整型：如果分区键的取值为整型（UInt64、Int8 等等都算），且无法转成日期类型 YYYYMMDD 格式，则直接按照该整型的字符串形式作为分区 ID 的取值；
3. 使用日期类型：如果分区键取值属于日期类型，或者是能够转换为 YYYYMMDD 格式的整型，则使用按照 YYYYMMDD 进行格式化后的字符串形式作为分区 ID 的取值；
4. 使用其它类型：如果分区键取值既不是整型、也不是日期类型，比如 String、Float 等等。则通过 128 位 Hash 算法取其 Hash 值作为分区 ID 的取值。
↩︎

书摘｜挪威的森林

Fri, 02 Dec 2022 00:14:00 +0800

前两周还没居家办公的时候，在早晨上班的地铁上，用 iPhone 和 Kindle 又看了一遍《挪威的森林》。每次都觉得很好看。

以下是书摘

文章这种不完整的容器所能容纳的，只能是不完整的记忆和不完整的意念。
想到这里，我悲哀得难以自禁。因为，直子连爱都没爱过我。
死并非生的对立面，而作为生的一部分永存。
就是说：“死迟早会将我们俘获在手。但反言之，在死俘获我们之前，我们并未被死俘获。”在我看来，这种想法是天经地义、无懈可击的。生在此侧，死在彼侧。我在此侧，不在彼侧。

然而，以木月死去的那个晚上为界，我再也不能如此单纯地把握死（或生）了。死不是生的对立面。死本来就已经包含在“我”这一存在之中。这个事实是无论怎样力图忘掉都将归于徒劳的。
论读书，我辈较之他可谓望尘莫及。他宣称：对死后不足三十年的作家，原则上是不屑一顾的，那种书不足为信。

“不是说我不相信现代文学。我只是不愿意在阅读未经过时间洗礼的书籍上面浪费时间。人生短暂。”
如果读的东西和别人雷同，思考方式也只能和别人雷同。乡巴佬、小市民才那样。有识之士不会如法炮制，取羞于人。明白吗，渡边君？这宿舍院里，多少算是有识之士的，惟独我与你，其余全是废纸屑！
永泽是一个集几种相反特点于一身的人，而这些特点又以十分极端的形式表现出来。有时他热情得无以复加，连我都险些为之感激涕零，有时又极尽搞鬼整人之能事。他既具有令人赞叹的高贵精神，又是个无可救药的世间俗物。他可以春风得意地率领众人长驱直进，而那颗心同时又在阴暗的泥沼里孤独地挣扎。一开始我就清楚地觉察出了他的这种内在矛盾，而其他人却对此视而不见，委实令人费解。他也背负着他的十字架匍匐在人生途中。
哪里会有人喜欢孤独！不过是不乱交朋友罢了。那样只能落得失望。
绅士就是：所做的，不是自己想做之事，而是自己应做之事。
玲子揉了好几下手指，开始弹《挪威的森林》。曲子注满了她的感情，而她又不为感情所驱使。于是我也从衣袋里拈出一枚百元硬币投进盒里。

“谢谢。”玲子说着，莞尔一笑。
“一听这曲子，我就时常悲哀得不行。也不知为什么，我总是觉得似乎自己在茂密的森林中迷了路。”直子说，“一个人孤单单的，里面又冷，又黑，又没一个人来救我。所以，只要我不点，她是不会弹这支曲的。”
“说不清楚。”我说，“大概说不上喜欢。他那人，不属于喜欢不喜欢的范畴，而且他本人所追求的也不是这个。在这个意义上，他是个非常直率的人、不弄虚作假的人、极其清心寡欲的人。”
“的确，”我承认，“不过我不是有意给自己贴这么一张标签，是从内心里这么认为的，真认为自己是个普通人。你从我身上发现什么不普通的东西了？”

“那还用说！”直子惊讶地说，“你连这点还看不出来？不然我怎么和你睡？难道你以为我喝醉了和谁都可以睡，所以才和你睡了不成？”
“我，二十岁生日那天晚上，一见到你就湿来着，一直想让你抱来着，想让你抱，给你脱光，被你抚摸，让你进去。这种欲望我还是第一次出现。为什么？为什么会出现这种现象？本来，本来我那么真心实意地爱着木月！”
“春天的原野里，你一个人正走着，对面走来一只可爱的小熊，浑身的毛活像天鹅绒，眼睛圆鼓鼓的。它这么对你说道：‘你好，小姐，和我一块儿打滚玩好么？’接着，你就和小熊抱在一起，顺着长满三叶草的山坡咕噜咕噜滚下去，整整玩了一天。你说棒不棒？”

“太棒了。”
“我就这么喜欢你。”
“你对人生没有产生过恐怖感？”我问。 “我说，我并不那么傻。”永泽说，“固然，有时也对人生怀有恐怖感，这也是理所当然！只是，我并不将它作为前提条件来加以承认。我要百分之百地发挥自己的能力，不达到极限绝不罢休。想拿的就拿，不想拿的就不拿，就这样生存下去。如果不行，到不行的时候再另行考虑。反过来想，不公平的社会同时也是大有用武之地的社会。”
“所以，有时我环顾世人就气不打一处来——这些家伙为什么不知道努力呢？不努力何必还牢骚满腹呢？”我惊讶地看着永泽的脸：“在我的印象中，世上的人也都在辛辛苦苦拼死拼活地忙个没完，莫不是我看错了？” “那不是努力，只是劳动。”永泽断然说道，“我所说的努力与这截然不同。所谓努力，指的是主动而有目的的活动。”
永泽首先讲起外务省考试的事。他说应试者几乎全是扔进无底泥潭也不足惜的废物，不过其中也有几个正路货。我问那比率同社会上的相比孰高孰低。 “一样，还用说。”永泽一副毋庸置疑的神色，“这种比率，哪里都一样，一成不变。”
“我和渡边有相似的地方。”永泽说，“他和我一样，在本质上都是只对自己感兴趣的人，只不过在傲慢不傲慢上有所差别。自己想什么、自己感受什么、自己如何行动——除此之外对别的没有兴趣，所以才能把自己同别人分开来考虑。我喜欢渡边也无非喜欢他这一点。只是他这小子还没有清楚地认识这点，以致感到迷惘和痛苦。”
“我同渡边的相近之处，就在于不希望别人理解自己。”永泽说，“这点与其他人不同，那些家伙无不蝇营狗苟地设法让周围人理解自己。但我不那样，渡边也不那样，而觉得不被人理解也无关紧要。自己是自己，别人归别人。” “是吗？”初美问我。 “难说。”我答道，“我不是那样的强者，也并不认为不被任何人理解也无所谓，希望相互理解的对象也是有的。只不过对除此以外的人，觉得在某种程度上即使不被理解也无可奈何，这是不可强求的事。因此，我并不是像永泽君说的那样，认为人家不理解也无关紧要。”
“永泽，你认为不被我理解也可以？”初美问。 “你好像还没最后明白，人理解某人是水到渠成的事，并非某人希望对方理解所使然。” “那么说，我希望某人理解自己莫非错了不成？譬如希望你？” “不不，那并不是什么错。”永泽回答，“正人君子称之为爱，假如你想理解我的话。我的人生观和别人的相当不同。” “就是说不爱我？” “所以你要对我的人生观……” “人生观，人生观，管什么人生观不人生观！”初美发起火来。她的发火，前前后后我只见过这一次。
但初美这位女性身上却有一种强烈打动人心的力量，而那绝非足以撼倒对方的巨大力量。她所发出的不过是微不足道的力，然而却能引起对方心灵的共振。
那时，我为采访一位画家来到新墨西哥州的圣菲城。傍晚，我走进附近一家意大利比萨饼店，一边喝啤酒嚼比萨饼，一边眺望美丽的夕阳。天地间的一切全都红彤彤一片。我的手、盘子、桌子，凡是目力所及的东西，无不被染成了红色，而且红得非常鲜艳，就好像被特殊的果汁从上方直淋下来似的。就在这种气势夺人的暮色当中，我猛然想起了初美，并且这时才领悟她给我带来的心灵震颤究竟是什么东西——它类似一种少年时代的憧憬，一种从来不曾实现而且永远不可能实现的憧憬。这种直欲燃烧般的天真烂漫的憧憬，我在很早以前就已遗忘在什么地方了，甚至很长时间里我连它曾在我心中存在过都没有记起。而初美摇撼的恰恰就是我身上长眠未醒的“我自身的一部分”。
一九六九年这一年，总是让我想起进退两难的泥沼——每迈一步都几乎把整只鞋陷掉那般滞重而深沉的泥沼。而我就在这片泥沼中气喘吁吁地挪动脚步，前方一无所见，后面渺无来者，只有昏暗的泥沼无边无际地延展开去。
“没和其他任何人睡觉？”直子问。 “没有。”我答道。 “那好，这个也记住。”说着，她身体下滑，轻轻用嘴唇含住我那东西舔着。直子笔直的秀发垂在我的小腹上，随着她嘴唇的移动“刷刷”地摇晃着。于是我又来了第二次。
“不要同情自己！”他说，“同情自己是卑劣懦夫干的勾当。”
四月过去，轮来五月。五月比四月还要难以打发。刚交五月，我就不能不感到自己的心开始在阑珊的春日中摇颤。这种摇颤大体在薄暮时分袭来。在浮动着玉兰花淡淡幽香的苍茫暮色里，自己的心开始无端地膨胀、颤抖、摇摆、针刺似的痛。这时我便紧闭双目、咬紧牙关，等待这番袭击的过去。而这要花很长时间，之后还留下丝丝隐痛。
这绝非自我开脱，我自以为生来至今始终以诚为本，对任何人也未曾文过饰非，时刻小心不误伤任何人，然而到头来自己反被抛入这迷宫般的境地，我全然不知何以如此。
渔夫走后，我蓦地记起高三时第一次睡过的女友，在她身上，自己做得何等残酷！想到这点，我心里感到一阵冰冷，无可救药的冰冷。我几乎从未思考过她会作何想法，有何感受，以及心灵受何刺激。甚至至今都未好好想过她一下。其实她是个非常温柔的女孩，只是当时我将那种温柔视为理所当然的东西，丝毫未加珍惜。她现在做什么呢？能够原谅我么？
绿子在电话的另一头久久默然不语，如同全世界所有的细雨落在全世界所有的草坪上一般的沉默在持续。
我现在哪里？我拿着听筒扬起脸，飞快地环视电话亭四周。我现在哪里？我不知道这里是哪里，全然摸不着头脑。这里究竟是哪里？目力所及，无不是不知走去哪里的无数男男女女。我从哪里也不是的场所的正中，不断呼唤着绿子。

实践一个月的时间统计法

Sun, 10 Jul 2022 11:45:00 +0800

最近一个月，我在 iPhone 和 Apple Watch 上安装了 aTimeLogger 应用，来记录我把时间都花在了哪里。最早了解到时间统计法，是因为在网上看到了关于柳比歇夫的介绍（不过我并没有看过《奇特的一生》）。2016 - 2018 年，我也陆陆续续进行过时间统计，主要是统计工作、运动、睡眠的时间，防止自己过劳死。

这次再次开始进行时间统计，也是因为感觉最近有一些 burnout，想要分析一下自己在工作中的时间分配情况。这次记录是从 6 月 6 日到 7 月 9 日，正好 5 周。先说一下我在 aTimeLogger 中设置的几个目标和完成情况：

每周交通时间少于 8 小时：完成 4 周，只有这周没完成。4 月底的时候，我搬家到了一个离公司比较远的地方，设置这个目标是为了让我注意每周在交通上花了多少时间。最近两周，由于北京下雨，路上很堵（打车也很难），花的时间多了点。通勤给了我不少听播客的时间，最近经常听《世界莫名其妙物语》和 Basecamp 的英文播客 Rework。可惜MilkShake 羊的 Byte.Coffee 已经停更很久了，不过也补了一些之前没听过的单集。
每天阅读 10 分钟：基本没几天达成目标，很遗憾。最近正在看的书有《人月神话》和 The Manager’s Path。
每天工作时间不超过 8 小时：因为我把休息（放空、玩手机）和用餐的时间都单独抽了出来，所以每天工作 8 小时真的不少了，但基本每天都会超过。
每周工作时间不超过 50 小时：5 周里有 3 周超过了 50 个小时，难怪感觉这么累。
每天专注工作 4 小时：这是一个美好的愿望，基本也没有完成过。

具体到工作时间，我分成 4 类：

普通工作：135 小时。普通工作指的是我在办公桌前的时间，包含看文档、写文档、调试、沟通、答疑等等。
会议：94 小时。各种会议，包括团队例会、项目例会、站会、各种讨论会、1 on 1、与客户的会议。在前几周的时候，会议时间大概还只有普通工作的一半，但这几周要进行各种下半年规划的讨论，会议时间已经快追上普通工作了。
面试：12 小时。这几周的面试比我想象的少很多。
深度工作：10 小时。我专门保留的大块时间，希望进行编码或者写作等需要比较专注的工作。

其实不做记录也知道，自己深度工作的时间是很少的。记录之后可以发现，会议加面试的时间已经占了总工作时间的 42% 了，它们除了占用大量的时间，还会把剩下的工作时间切的七零八落。当时间碎片化之后，我就会倾向于做一些简单的工作，比如看文档、回消息等等。此外，当我用 time blocking 保留一些深度工作时间的时候，也可能会被其他人临时的讨论需求、即时通信消息给打断。当然，不可否认，在一些无人打扰的时刻，我薄弱的意志力也没起到什么帮助。

Paul Graham 就这个问题写过 Maker’s Scheduler, Manager’s Scheduler。Maker 代表工程师、程序员等，对于他们来说，被会议、讨论和即时通信打断之后的上下文切换时间很长。Manager 代表管理者，他们的一天就是从一个会议到另一个会议，与同事、客户进行沟通，开会解决问题对于他们来说是很自然的事情。Paul 写这篇文章，是希望 manager 能够理解 maker 的工作方式，减少对 maker 的打断。可惜，在 Paul 写出这篇文章的 9 年之后，manager 似乎仍然没有理解 maker 所处的困境，manager 依然在频繁的打断 maker。

我觉得有一种方式可以扭转这种局面（也许是因为最近经常听 Rework），就是鼓励异步的沟通方式。异步沟通指的是，你发送一个消息，并不指望对方即时回复。这种情况下，你必须用写作的方式，将想法清晰的表达出来，形成文档或者邮件。这减少了对消息接收者的压力。对方可以选择不被打断，而是在饭前、下班前这样的时间统一处理，这样 maker 就有了更多不受打扰的时间。

更重要的一点是，异步沟通鼓励清晰的写作，否则反复的异步沟通会导致工作效率极大的降低。你会发现，写作是一种思考的过程。很多时候，你觉得自己想清楚了，但是你写不出来，这代表你没有真正想清楚。当你能够把想法写出来的时候，你自己在阅读的时候，会发现你想法中的漏洞和不完善的地方。写作帮助你整理思绪，它强迫你深思熟虑。

通过最近的时间统计，我想到了两条改进措施：

通过写文档，鼓励大家多写文档，采用异步通信
用 time blocking 更坚决的保护自己的深度工作时间

译文 | Snowflake 火箭船背后的火箭

Sun, 27 Mar 2022 10:50:44 +0800

原文：The Rocket Behind Snowflake’s Rocketship

作者：Greg Czajkowski

译者按：Snowflake 是第一家提供云原生数仓服务的公司。本文中，Snowflake 工程部的高级副总裁 Greg Czajkowski 介绍了他们提供创新产品并保证高质量和快速交付的秘诀。

我们没有一天不被候选人、客户和其他感兴趣的人问及我们如何运作 Snowflake 软件工程部门。我经常听到：「Snowflake 一直在提供真正创新、高质量的产品，而且交付的速度还不断加快。这其中一定有什么秘密」。的确，我们有一个独特的工程团队，并继续雇用世界级的工程师。他们是我们产品背后的驱动力。

吸引和雇用优秀人才，并致力于解决令人惊叹的雄心勃勃的技术问题，是我们实现 Snowflake 的方式。这三个原则指导我们如何使我们的工程团队、Snowflake，以及随之而来的我们的客户取得成功。

使我们的任务与整个工程和其他 Snowflake 团队保持一致
将我们的精力集中在最有效的方式上
激发工程中的每个人的主动性

自 Snowflake 成立以来，我们的创始人和领导人一直倡导这些原则。同样重要的是，我们招聘的人都拥护这些原则，这对我们有很大的帮助。从一开始就培养和加强这些原则，当然比事后把它们强加给一个组织，或改良一个以前运作良好但已经恶化的组织要容易。

这篇文章是对我们运作方式的总结，以及在应用该方法时的经验。

在我们的使命上保持一致

我们的使命是用 Snowflake 的数据云调动世界的数据。我们可以帮助任何组织通过数据实现更好的业务成果，提供更好的产品和服务。在 Snowflake 相当多的工作是确保所有团队都完全支持这一目标及其影响，包括工程、产品管理以及其他有助于产品开发的团队。这种一致性得到了很大的回报，因为它提供了必要的清晰度，以迅速作出决定，包括影响所有 Snowflake 的决定，而不仅仅是一个团队。

专注于质量

我们的使命的一个含义是，没有内部 DevOps 团队的公司可以充分利用 Snowflake 的优势，因为我们承担并努力消除了运维所需要的努力和摩擦。同样地，Snowflake 开发适当的机制，以提供良好的性能，而不需要由我们的客户进行调整。我们经常听到我们的客户说，我们最看重的特点之一是「它就是好用」。此外，我们通过创建一个高度集成的产品来消除大量的集成工作，而不是一些需要集成的狭窄范围的产品、适应独立的学习曲线、处理不同的定价模式等等。换句话说：高质量是实现我们使命的核心。偏离这个产品设计的初心，可以在战术上使我们的生活更容易，因为有时我们可以通过提供一个配置选项来解决一个特定的问题，或者一个特定的客户可以从上一代的数据仓库中得到一个他们熟悉的调整参数。然而，这种步骤的总效果会把一个令人愉快的产品变成另一种复杂的技术，需要客户不断地关注，这就违背了我们的使命。

在所有职能部门之间保持一致

整个 Snowflake 在产品设计方面的完全一致，是我们成功的关键。每个人的支持，包括我们的销售组织，抵制诱惑，在易用性上「做一点」妥协，有助于集中精力开发技术和启发式方法，进一步提高 Snowflake 的可用性。与 IT 部门的密切合作，使我们能完成复杂的举措，比如在 Snowflake 上运行 Snowflake 的业务。与营销部门保持一致，可以共同关注「自助服务」的技术方面。在我们的使命上的一致，使客户支持很容易要求工程部门提供诊断工具（并获得该工具）。虽然领导者的协调是至关重要的，但关键是团队内部和团队之间的所有级别都要同样地协调。

这是质量和速度

我们的使命意味着以高速度提供高质量的服务。「高质量」和「高交付速度」似乎是矛盾的，直到人们意识到，质量是我们交付新功能和产品创新的速度的组成部分。糟糕的质量会导致频繁和昂贵的事故。没有对质量的适当关注，速度只是一种幻觉，在下一次回滚时就会结束。同样，从一开始，跨职能部门就对质量的价值保持一致，使我们的工程团队保持正确的注意力。总的来说，发展「质量和速度」的思维方式，对我们建立一个伟大的产品和避免「质量与速度」的陷阱有很大的帮助，这常常困扰着产品开发团队。

了解你的产品

我一直在谈论的一致性，真正开始于 Snowflake 的 2900 多名员工（截至 2021 年 4 月 30 日）一起倡导我们公司的价值观。我们所有的价值观都很重要。但在这个列表的顶部是「把客户放在第一位」。对我们工程人员来说，除其他意义外，这意味着我们应该对客户如何使用我们的产品有坚实的第一手经验。这也意味着我们应该有详细的产品使用遥测数据，以便将投资引向最有价值的改进。我们坚信并拥有内部证据来证实我们对客户所说的话。最好地利用数据的组织实现更好的决策和结果。

在 Snowflake，所有这些都是由 Snowhouse 实现的 — 这是一个我们内部使用的 Snowflake 账户，其功能与我们客户使用的相同。在 Snowhouse 包含的大量数据中，也包括了用户使用情况的遥测数据。我们每个人都使用 Snowhouse，从分析查询性能到为季度总结准备数据。其结果是工程部对我们所建立的实际产品的深度熟悉，这在我们的行业中是非常强大和独特的。它使我们能够更快地改进我们的产品，将第一手的经验输入设计中。

最有成效地使用精力

质疑流程和现状

在任务上的一致性是快速交付优质产品的必要条件。但这并不是全部。精力需要被节约和应用，以提供尽可能大的影响。首先，我们在引进新流程时是高度挑剔的。我们仔细权衡成本和效益，并邀请那些将受到新流程影响的人对其进行定义。同样，每个流程都可以被重新定义，甚至在它不起作用时被删除。我们学习和迭代。

我们非常鼓励工程师指出问题，审视现有流程，并提出改进建议。不过，这些辩论不可能是无休止的。在提出流程改进建议时，「不同意并承诺」是一个有用的方法，可以避免追求收益递减。更广泛地说，「不同意并承诺」的格言为我们提供了很好的服务，例如防止设计决策陷入僵局。它不需要经常被引用，但当它被引用时，它是一个很好理解的概念。我们经常谈及不满者 — 一个也许甚至对现状过于挑剔的人。这个词是从我们的 CEO 那里借来的，指的是一种富有成效的行为，它不会让我们陷入自满，而是继续完善我们对 A+ 状态的理解，并越来越接近它。我们是不满者的粉丝！

与产品管理部门合作

在全速前进的同时，转动你的车轮并不能缩小你与既定目标之间的距离。为了避免混淆努力和结果，与我们的产品管理团队建立密切的伙伴关系是至关重要的。我们强调伙伴关系，因为我们经常听到一些公司的「工程师文化」。在 Snowflake，我们相信专家应该管理他们的专业领域。

当然，我们欢迎任何专业知识和意见，有时我们的产品审查与工程审查没有区别。（这很好！）但最终，产品经理是工程的真正合作伙伴，反之亦然。

让我们考虑一下内部自动化。它不仅更有效率，而且更不容易出错。我在其他公司的同事经常发现投资于内部自动化，就像投资于稳定性和质量一样，由于交付新产品功能的压力，很难。Snowflake 是不同的，产品管理部门对非面向客户的举措的价值的理解和支持是无价的。一般来说，能够采取更长远的观点，用季度而不是周来衡量效益，是工程和产品管理合作的结果，它具有强大的跨职能的一致性。

创新但不要「做创新」

我们在工程和产品管理之间的密切伙伴关系的最大好处之一是，我们不会为了创新而「做创新」。相反，我们确定哪些问题需要解决，然后从第一原则出发，了解技术现状，但不受制于主流思想，也不在战术上妥协。

产品管理部门的支持在这里是至关重要的。这种方法，虽然从长远来看会产生技术上的突破，对客户产生巨大的积极影响，但需要时间来设计和实施。它也有助于 Snowflake 成为世界上最具创新的公司之一。当我们从设计讨论转移到实施时，我们已经围绕未来的影响建立了信心。因此，对我们来说，放弃一个项目是一件非常罕见的事情。

在 Snowflake，「完成并完成」是一个经常使用的术语。明确和全面地定义完成标准，确保功能的推出具有影响力，没有松散的结局。知道什么是「完成和完成」，可以避免浪费精力在摇摆不定的移动到下一个大事情和不得不完成第一次没有做好的事情。「完成它」和「拥有它」是我们公司的价值观，并极大地协助了 Snowflake 工程团队的「完成并完成」方法。

质量高于最后期限

对承诺的管理也很重要。如果有一个很好的理由，并且在出现失误的那一刻就被告知，错过承诺是可以的。一旦有可能出现纰漏，不告诉任何人就错过目标是不行的。这种方法在复杂的产品发布中特别适用于我们，在这种情况下，依赖性跨越了几个团队。

我们的季度计划流程区分了两种类型的目标：必须交付和尽力而为。如果我们需要对一个新的机会做出快速反应，后一类目标会受到影响，但不会影响前一类目标。有了这两层目标，就能提高我们的敏捷性。同样地，如果质量会因为专注于一个最后期限而受到影响，我们就重新定义最后期限。一般来说，这个简单的声明 — 质量高于最后期限 — 说起来容易，应用起来很难。在 Snowflake，跨职能部门的协调有助于我们实践它。

小团队和小自我

许多工程师报告说，他们觉得在小团队中最有成效。虽然我们不是一个互不相干的小团队的集合，但我们鼓励经理们以这样的方式来组织工作，让工程师感觉他们是在一个（大约）四人的团队中工作。在硅谷最初的办公室以外的时区开设工程办公室，使我们更加重视「小团队」的方法，重点是尽量减少洲际会议的需要，促进异步沟通（例如，文件胜过会议）。

巨大的自负是有代价的。Snowflake 的文化的一部分是不要太自我。我们的面试过程包括一个行为的部分。我们评估，例如，某人是否是一个高于平均水平的团队成员，并且不是充满自负。有意组建一个谦逊的工程团队是很重要的，原因有几个。那些没有职位权力的人可以采取主动、开放、被领导倾听，并确信最好的想法会胜出，无论是谁提出的。

谦虚使人有一种成长的心态：如果我们在某些方面做错了，我们会学习并向前迈进。它有助于避免傲慢，这在工程组织中并不少见。工作场所傲慢的症状可能包括贬低和看不起竞争对手，高估自己的能力，或者认为客户是错误的，自己的技术是正确的。这些行为和信念通常会导致长期的表现远非最佳。相反，我们试图以高度谦逊的态度来运作，尊重大小竞争。无论竞争者是谁，我们通过公平但激烈的竞争来表示尊重，并从我们的错误和成功中学习。

发挥每个人的主动性

推动决策落地

为了充分实现与我们的使命和精力的有效利用相一致的潜力，我们需要工程部的每一个成员都感到有能力采取主动。这可以是小事，如减少自己团队中的不必要会议，也可以是更大的事，如提议收购一家公司。我们鼓励这样的心态：如果某件事情可以改进，我们中的任何一个人都可以去改进它。

关键是要把决策推到组织中去。一个流行的机制是组建小型工作小组来实现变革。最近的例子包括定义最佳代码审查实践，简化招聘流程，以及改善内部开发人员的经验。每一个新的成功的工作小组，除了解决一个特定的主题，还加深了我们拥有自己命运的感觉。这种乐观和自信的感觉对于建立一个世界级的工程团队至关重要。相反，太多组织的表现远远低于他们的潜力，因为他们变得宿命或冷漠，抱有这样的想法。「一切都不会改变，为什么要尝试？」

消除等级制度的障碍

让每个人都能采取主动，是一个健康运作、快速发展的组织的重要基础。但是，等级制度的障碍会妨碍我们的工作。我们已经采取了一些措施来消除这些障碍。

我们为所有人提供近乎即时的通信，这有一个受欢迎的副作用，即缩短了个人贡献者和第九级管理人员之间的距离。
我们每两周为工程和产品管理部门举办一次全体员工会议，由个人贡献者做大部分的发言。
而且，我们提倡自嘲式的幽默。（这是相当棘手的，因为我们没有坚实的证据证明我们有任何幽默感，自嘲或其他。）

我们想强调的是，你不是一定要有一定的职位或权力，才能影响 Snowflake 的方向或领导某项工作。

一个很好的授权和主动性的例子是，由工程经理，产品经理，技术项目经理和用户体验设计师组成的小组如何一起为他们的领域建立一个计划。这种水平的自主权对团队来说是理想的，也是激励的。当然，这些团队需要考虑把客户放在第一位，并与各种业务和技术要求保持一致。一些评论帮助我们在自上而下的广泛指令和释放自下而上的能量和创造力之间实现这种平衡和一致。

建立信任，而不是指责

一个相关的话题是组织内的信任。这不是一夜之间建立起来的东西。相反，信任是从无数的遭遇、项目和情况，以及领导人每天的运作方式中成长起来的。在 Snowflake，在决策和沟通技术和非技术建议方面有高度的透明度，所以每个人都可以评论和影响他们，并专注于学习。例如，我们的绩效管理过程的详细说明可供所有人参考。所有工程、产品和其他审查的幻灯片和笔记每周都会发送给所有工程人员。而且，正如已经提到的，我们每两周举行一次全体员工会议，其中有一个问答环节。这些活动，以及更多的活动，有助于推动一致性，并有助于避免因缺乏信息而导致的能量耗散。

「责备」这个词有明显的负面含义，因为它阻碍了从错误中学习，并将能量转移到非生产性行为上。在 Snowflake，无责的事后分析是一个活动的例子，在这个活动中，全部注意力都集中在对事实的理解上，而对谁做了或没做什么事的关注是零。我们定期举行这种活动，对建立信任有很大的积极影响。

主动出击，直接出击

在 Snowflake 经常听到的一个短语是「直接了当」。这个想法是直接与拥有解决方案一部分的人讨论一个特定的事项，而不是与经理或不同的代理人讨论。直截了当可能是困难的，但这是一个成熟的组织所需要的东西之一。在极少数情况下，当直接行动不起作用时，我们鼓励所有工程人员在进展停滞不前或需要澄清所有权时进行升级。到现在，「升级」这个词已经失去了负面的涵义。

主动性是与「不是我的工作」的态度截然相反的。我们强烈鼓励以下行为。如果有些事情看起来不像是你的工作，但又需要完成，如果你能做到，就去做，直接找负责人，如果所有权不明确，就升级。这样的态度鼓励我们把产品和公司当成自己的。我们公司的一个价值观是这样说的。「把我们的产品和公司当作自己的产品和公司来打造，因为它是自己的。」

主动性是我们在管理人员中提倡的做法之一。事实上，一个由经验丰富的经理人组成的工作小组提出了一些材料和论坛，讨论有助于提高我们管理敏锐性的关键议题。我们已经确定，对我们来说，主动性是一个与妥善处理困难的对话、管理承诺、促成整体的职业成长或创造团队认同感同样重要的话题。

结束语

适当的和正确的激励措施有助于促进正确的行为。在我们的员工绩效评估中，我们关注的是技术贡献（对经理来说：人员和团队管理），对产品质量的关注，以及「公民身份」。最后一个类别相当广泛，但在本质上，它是关于为 Snowflake 和我们的客户进行优化，采取主动，并帮助他人。类似于跳台滑雪，距离和风格都很重要。

我们相信上述原则会带来一个高产的工程团队，同样重要的是，在一个有利于学习、合作和相互帮助的不复杂的环境中，快速的专业成长。

是否所有的工作都是按计划进行的？当然不是。Snowflake 是一家快速增长的公司，在一个高度动态的环境中运作。昨天还有效的东西，明天可能需要进行微调或完全彻底的修改。然而，本文所述的基本原则使我们能够迅速调整，并保持在技术的最前沿。我们让结果自己说话。

深度神经网络编译器调研

Thu, 10 Jun 2021 19:46:35 +0800

在墨奇科技，我们需要将一些包含深度神经网络（DNN）的 AI 算法移植到边缘端的设备，这些设备往往使用 ARM 架构的 CPU 和一些特殊的边缘端推理芯片（NPU）。这个时候，我们可以使用 NPU 产商提供的推理框架（例如瑞芯微的 rknn-toolkit）或 TensorFlow Lite 这样的通用边缘端推理框架。另一个选择是使用深度神经网络编译器，自动化的生成对模型和硬件最适合的机器代码。我们将这个领域内的一些论文和开源项目进行了梳理。

为什么需要深度神经网络编译器？

深度学习在我们的日常生活中无处不在。深度神经网络（DNN）可以识别图像，处理自然语言，甚至在一些很有挑战性的策略游戏中击败人类。当前的深度学习框架，如 TensorFlow¹、MXNet² 和 PyTorch³，支持使用 GPU 加速深度学习模型的训练和推理，这种支持依赖于由 GPU 产商提供的高度优化的张量算子库（比如 NVIDIA 的 cuDNN）。对于一个张量算子，存在许多逻辑上等效的实现，但由于线程、内存重用、流水线和其他硬件因素的差异，这些实现在性能上会有很大差距。为了优化张量算子，程序员必须从这些逻辑等效的实现中选择性能最好的。这些算子级别的优化需要大量的手动调整，非常的专业和不透明，而且无法轻松地跨硬件设备移植。因此，一个深度学习框架如果想要支持不同的硬件后端，需要大量的工程工作。即使在当前受支持的硬件上，开发深度学习框架和模型也受到库中优化算子集合的限制，从而阻止了可能产生不受支持的算子的优化（例如计算图优化和算子融合）。

从云服务器到自动驾驶汽车和嵌入式设备，我们需要将包含 DNN 的 AI 应用程序部署到各种各样不同的设备上。由于硬件的多样性，存在 CPU、GPU、ASIC（如 TPC 和 NPU）、FPGA 等不同类型的硬件，这些硬件的设计目标在内存组织、计算功能单元等方面都有很大的不同（下图展示了 CPU、GPU 和 TPU 的不同内存组织和计算功能单元），将深度学习模型映射到这些硬件设备变得很复杂。深度学习框架依靠计算图的中间表示来实现优化，例如自动微分和动态内存管理。但是，计算图级别的优化通常过于高级，无法处理特定硬件后端的算子级转换。

为了在不同的硬件后端上同时实现计算图级别和算子级别的优化，让深度学习计算被更广泛的应用，我们需要一套自动化的针对不同硬件后端的深度学习编译技术。

主要工作

这节我们介绍深度学习编译技术中的一些代表性工作。

TVM

为了解决上一节所说的种种问题，陈天奇等人提出了 TVM⁴，第一个端到端的深度学习自动编译和代码生成方法。TVM 允许将高级框架（如 TensorFlow、MXNet、PyTorch 等）专用的深度学习网络部署到多种硬件后端上（包括 CPU、GPU 和基于 FPGA 的加速器）。在设计上，TVM 结合了内存访问、线程模式和新的硬件元语，建立一个足够大的搜索空间，保证可能的人工工程优化全部包含在这个搜索空间里面。TVM 通过快速的搜索这个搜索空间，生成可部署代码。其性能可与当前最优的硬件供应商库相比，且可适应新型专用加速器后端。

TVM 是一个由社区维护的开源项目，来自全世界的贡献者们仍然在持续的改进它。2018 年，陈天奇等人提出了 AutoTVM⁵，旨在通过机器学习来编译优化深度学习系统底层算子。当 TVM 建立了足够大的搜索空间后，剩下的问题是如何在几十亿的可能性里面去选择比较好的实现。这里有几种常见的做法。传统的高性能计算库如会采用自动整定（auto tuning），也就是把可能的参数都尝试一遍。这样做的潜在问题是空间太大之后枚举开销过高。另外一种常见的做法是类似于数据库做查询优化的做法，针对程序建立一个代价估价函数，然后利用估价函数来搜索。这个做法可能碰到的主要问题是估价函数不一定可以估计准确，并且针对每个新的硬件特性必须要重新设计估价函数。 AutoTVM 利用机器学习来学习程序空间的代价估价函数。具体地说，探索程序在一开始会随机地选取一些设定，直接到硬件上面去运行生成的代码，再通过得到的反馈数据来更新程序代价估计函数。这里面比较有趣的一点是模型的可迁移性。因为真正的深度学习系统需要优化许多不一样输入类型和输入形状的算子。一个可迁移的模型可以通过学习已经看到过的算子优化记录来预测新的目标的代价，导致最后的搜索时间可以大幅降低。

Relay⁶ 是一种功能多样的编程语言，TVM 用 Relay 作为深度学习模型的中间表示（ IR, intermediate representation）。Relay 支持代数数据类型、闭包、控制流和递归，从而可以直接表示比基于计算图的中间表示更复杂的模型。Relay 还包括一种使用类型关系的依赖类型的形式，来处理对参数形状有复杂的要求的操作符的形状分析。Relay 在设计上是可扩展的，这使得机器学习的研究人员和实践者可以很容易地开发新的大型程序转换和优化。

郑怜悯等人在 TVM 的基础上实现了 Ansor⁷。Ansor 主要解决了 TVM 中的两个问题：

如何自动化的构造一个更大的搜索空间？Ansor 使用了一个层次化的搜索空间；
如何更有效的进行搜索？Ansor 在搜索过程中增加了采样，先对完整的程序进行采样然后再调整，提高了搜索效率。

下图展示了 Ansor 的整体架构。Ansor 的输入是一组待优化的深度神经网络（DNN）。 Ansor 使用 Relay⁶ 中的算子融合算法，将 DNN 从流行的模型格式（如 ONNX 和 TensorFlow PB）分割成的小子图。然后 Ansor 为这些子图生成张量程序。Ansor 有三个主要部分：(1) 程序采样器（program sampler）：构建一个大的搜索空间，并从中采样不同的程序；(2) 性能调整器（performance tuner）：对采样程序的性能进行微调；(3) 任务调度器（task scheduler）：为优化 DNN 的多个子图分配时间资源。

Rammer

Rammer⁸ 是微软发布的一个针对深度神经网络的自动编译框架。Rammer 针对的主要是并行计算能力较强的 GPU 和 ASIC 神经网络加速器。在神经网络中，有两个层级可以通过并行来加速，第一层是在神经网络的计算图上，可以将相互之间独立的算子并行化；第二层是在一个算子的内部，比如矩阵乘法，可以使用并行计算加速。Rammer 的特点是提供了对算子和硬件的两种抽象，统一的对两层级的并行进行调度，提高了并行编排的效率。作者在 NVIDIA GPU、AMD GPU 和 GraphCore IPU 上进行了实验，如下图所示，NVIDIA GPU 上的实验表明，Rammer 在部分模型上的效果超越了 TensorFlow、TVM 和 TensorRT。

MLIR

Google 在 2019 年的 C4ML 上发布了 MLIR⁹。 MLIR (multi-level intermediate representation) 是一种用来构建可重用和可扩展编译基础设施的新方法，它是 Google 用于统一其 TensorFlow 中众多中间表示的路径。乍看之下，MLIR 似乎可以替代 XLA 和相关的 TensorFlow 编译器，但事实并非如此。MLIR 是用于构建一组可互操作的中间表示「方言」的共享基础结构，可用于构建编译器。MLIR 项目正在针对 TensorFlow 的中间表示和低级多面体中间表示的方言开展工作，但是尚没有基于 MLIR 的深度学习的端到端解决方案。MLIR 深受 LLVM 的影响，并不折不扣地重用其许多优秀理念，比如拥有灵活的类型系统，可在同一编译单元中表示、分析和转换结合多层抽象的图等。这些抽象包括 TensorFlow 算子、嵌套的多面循环区域乃至 LLVM 指令和固定的硬件操作及类型。

为区分不同的硬件与软件受众，MLIR 提供中间表示「方言」，其中包括：

TensorFlow IR，代表 TensorFlow 图中可能存在的一切
XLA HLO IR，旨在利用 XLA¹⁰ 的编译功能（输出到 TPU 等）
实验性仿射方言，侧重于多面表示与优化
LLVM IR，与 LLVM 自我表示之间存在 1:1 映射，可使 MLIR 通过 LLVM 发出 GPU 与 CPU 代码
TensorFlow Lite，将会转换以在移动平台上运行代码

TorchScript

TorchScript¹¹ 是一种类似 Python 的高级中间表示，它是作为 PyTorch 的 JIT (Just-In-Time) 编译器的第一层。PyTorch（从 v1.0 开始）可以将一部分用户程序重写为 TorchScript（Python 的理想化子集）。然后，TorchScript 可以由 TorchScript VM 执行，也可以通过 JIT 编译到目标平台。TorchScript 位于代码生成之上的多个层次，并且必须适应 Python 的灵活语义，从而排除了所有的静态分析优化方法。为了优化这种动态行为，TorchScript 有一种用于性能分析的 JIT 模式，该模式在执行期间标识稳定的程序 trace。然后，可以通过低级编译器（例如 Glow¹² 或 Relay⁶）来优化这些稳定的静态 trace，以执行最后一级的代码生成。

Glow

Glow¹² 是 Facebook 推出的深度学习编译器。Glow 采用 TensorFlow 或 Caffe2 等框架生成的深度学习计算图，然后将它渲染成用于硬件加速器的字节代码。Glow 包括多个工具，如用来生成用于芯片特定内存配置的指令排程器、线性代数优化器、内存分配器，以及用来测试硬件准确率的基于 CPU 的推断实现。

其它相关工作

基于调度语言的自动张量程序生成

Halide¹³ 是一个开源的专门设计用于简化图像处理的程序语言。Halide 引入了一种可以描述循环优化原语的调度语言。该语言适用于手动优化和自动搜索。Halide 基于不同的技术有三种版本的自动调度器¹⁴¹⁵¹⁶。最新的一种具有波束搜索和学习成本模型的版本表现最好。TVM⁴ 也利用了类似的调度语言。FlexTensor¹⁷ 是一个张量计算的调度探索和优化框架，可以用于改进 TVM 的搜索算法。FlexTensor 首先定义了规整的优化空间，然后使用了模拟退火结合机器学习的方法去探索优化空间，找到最优的调度策略。

多面体编译模型

多面体编译模型将程序的优化公式化为整数线性规划（ILP）问题。它使用仿射循环转换来优化程序，从而使从属语句之间的数据重用距离最小化。Tiramisu¹⁸ 和 Tensor Comprehensions¹⁹ 是两个针对深度学习领域的多面体编译器。Tiramisu 提供的调度语言类似于 Halide 语言，并且需要手动调度。Tensor Comprehensions 可以自动搜索 GPU 代码，但尚未打算将其用于计算瓶颈区域（compute-bound）的问题。由于缺乏某些优化和多面体公式中不准确的隐式成本模型，Tensor Comprehensions 不能在 conv2d 和 matmul 等算子上胜过 TVM。

深度学习的计算图级别优化

计算图级别优化将计算图中的算子视为基本单元，并在计算图级别执行优化，而无需更改算子的内部实现。计算图级别的常见优化包括布局优化²⁰、算子融合⁴、常数折叠⁶ 、自动批处理、自动生成图替换²¹等。计算图形级优化通常是对算子级优化的补充。计算图级别优化还可以从算子的高性能实现中受益。TensorFlow XLA¹⁰ 和 DLVM²² 都属于针对深度学习的计算图级别的优化框架。TACO²¹ 是第一个使用自动生成子图替换的神经网络优化器。它将一系列算子操作作为输入，生成一系列可替换的候选子图，利用自动定理证明来通过形式化验证筛选，最后使用基于代价的回溯搜索法来找到最优图。TACO 可以自动的对于图结构和数据布局进行联合优化。而其他框架如 TensorFlow、PyTorch、TVM 则是通过一系列基于规则的手写子图组合进行图的优化，然后分开进行数据布局的优化。作为一个计算图的优化器，因为不涉及到底层代码的生成，TACO 可以很容易的作为一个插件去进一步提升其他框架如 TVM 的推理性能。

传统机器学习算法的优化

传统的机器学习算法（如决策树、支持向量机等）仍然在各种领域中广泛使用，它们使用的框架各异（如 scikit-learn、xgboost、SparkML 等），这些框架通常只对于部分硬件后端进行过推理性能的优化。如前面所述，由于神经网络的流行，在不同硬件后端上对深度神经网络的推理性能优化，已经有了大量的工作。微软推出了一个名为 Hummingbird 的系统，可以将传统的机器学习算法运行在深度学习推理引擎上，这样可以利用现成的深度学习自动编译器来加速传统机器学习算法在不同硬件后端上的推理性能²³。目前 Hummingbird 已经支持将 scikit-learn、 LightGBM 和 XGBoost 中的决策树模型转换成可以在 PyTorch、 TorchScript、 ONNX 和 TVM 上运行的模型。

小结

从近几年的论文和开源社区的发展来看，深度学习自动编译和优化这个方向还在蓬勃的发展中。在开源社区中，TVM 应该是最为成功的一个，它有先发优势，并且还在不断的进步（最近的改进 Ansor 在 OSDI'20 发表了）。同时，对于 TensorFlow 和 PyTorch 这样的深度学习框架，自动编译和优化对于他们在边缘端设备上的推广是非常重要的，所以可以看到大公司们也在这个方向上不断发力。

墨奇科技基础架构组专注于大规模图像搜索系统的基础架构和边缘端的 AI 算法优化两个方向。有兴趣的朋友请发简历（校招/社招）到 talent@moqi.ai。

参考文献

Abadi, Martín, Paul Barham, Jianmin Chen, Zhifeng Chen, Andy Davis, Jeffrey Dean, Matthieu Devin, et al. “TensorFlow : A System for Large-Scale Machine Learning.” In OSDI, 265–83, 2016. ↩︎
Chen, Tianqi, Mu Li, Yutian Li, Min Lin, Naiyan Wang, Minjie Wang, Tianjun Xiao, Bing Xu, Chiyuan Zhang, and Zheng Zhang. “MXNet: A Flexible and Efficient Machine Learning Library for Heterogeneous Distributed Systems.” In LearningSys, 1–6, 2015. ↩︎
Paszke, Adam, Sam Gross, Francisco Massa, Adam Lerer, James Bradbury, Gregory Chanan, Trevor Killeen, et al. “PyTorch: An Imperative Style, High-Performance Deep Learning Library.” In NeurIPS, 2019. ↩︎
Chen, Tianqi, Thierry Moreau, Ziheng Jiang, Lianmin Zheng, Eddie Yan, Haichen Shen, Meghan Cowan, et al. “TVM: An Automated End-to-End Optimizing Compiler for Deep Learning.” In OSDI, 2018. ↩︎ ↩︎ ↩︎
Chen, Tianqi, Lianmin Zheng, Eddie Yan, Ziheng Jiang, Thierry Moreau, Luis Ceze, Carlos Guestrin, and Arvind Krishnamurthy. “Learning to Optimize Tensor Programs.” In NeurIPS, 3389–3400, 2018. ↩︎
Roesch, Jared, Steven Lyubomirsky, Marisa Kirisame, Logan Weber, Josh Pollock, Luis Vega, Ziheng Jiang, Tianqi Chen, Thierry Moreau, and Zachary Tatlock. “Relay: A High-Level Compiler for Deep Learning.” ArXiv, 2019. ↩︎ ↩︎ ↩︎ ↩︎
Zheng, Lianmin, Chengfan Jia, Minmin Sun, Zhao Wu, Cody Hao Yu, Ameer Haj-Ali, Yida Wang, et al. “Ansor: Generating High-Performance Tensor Programs for Deep Learning.” In OSDI, 2020. ↩︎
Ma, Lingxiao, Zhiqiang Xie, Zhi Yang, Jilong Xue, Youshan Miao, Wei Cui, Wenxiang Hu, Fan Yang, Lintao Zhang, and Lidong Zhou. “Rammer: Enabling Holistic Deep Learning Compiler Optimizations with RTasks.” In OSDI, 881–97, 2020. ↩︎
Lattner, Chris, Uday Bondhugula, Albert Cohen, Andy Davis, Jacques Pienaar, River Riddle, Tatiana Shpeisman, Nicolas Vasilache, and Oleksandr Zinenko. “MLIR: A Compiler Infrastructure for the End of Moore’s Law.”ArXiv, 2020. ↩︎
XLA: Optimizing Compiler for Machine Learning | TensorFlow ↩︎ ↩︎
TorchScript ↩︎
Rotem, Nadav, Jordan Fix, Saleem Abdulrasool, Garret Catron, Summer Deng, Roman Dzhabarov, Nick Gibson, et al. “Glow: Graph Lowering Compiler Techniques for Neural Networks.” ArXiv, 2019. ↩︎ ↩︎
Ragan-Kelley, Jonathan, Connelly Barnes, Andrew Adams, Sylvain Paris, Frédo Durand, and Saman Amarasinghe. “Halide: A Language and Compiler for Optimizing Parallelism, Locality, and Recomputation in Image Processing Pipelines.” In PLDI, 519–30, 2013. ↩︎
Mullapudi, Ravi Teja, Andrew Adams, Dillon Sharlet, Jonathan Ragan-Kelley, and Kayvon Fatahalian. “Automatically Scheduling Halide Image Processing Pipelines.” TOG 35, no. 4 (2016). ↩︎
Li, Tzu Mao, Michaël Gharbi, Andrew Adams, Frédo Durand, and Jonathan Ragan-Kelley. “Differentiable Programming for Image Processing and Deep Learning in Halide.” TOG 37, no. 4 (2018). ↩︎
Adams, Andrew, Karima Ma, Luke Anderson, Riyadh Baghdadi, Tzu Mao Li, Michaël Gharbi, Benoit Steiner, et al. “Learning to Optimize Halide with Tree Search and Random Programs.” TOG 38, no. 4 (2019). ↩︎
Zheng, Size, Yun Liang, Shuo Wang, Renze Chen, and Kaiwen Sheng. “FlexTensor: An Automatic Schedule Exploration and Optimization Framework for Tensor Computation on Heterogeneous System.” In ASPLOS, 859–73, 2020. ↩︎
Baghdadi, Riyadh, Jessica Ray, Malek Ben Romdhane, Emanuele Del Sozzo, Abdurrahman Akkas, Yunming Zhang, Patricia Suriana, Shoaib Kamil, and Saman Amarasinghe. “TIRAMISU: A Polyhedral Compiler for Expressing Fast and Portable Code.” In CGO, 2019. ↩︎
Vasilache, Nicolas, Oleksandr Zinenko, Theodoros Theodoridis, Priya Goyal, Zachary DeVito, William S. Moses, Sven Verdoolaege, Andrew Adams, and Albert Cohen. “Tensor Comprehensions: Framework-Agnostic High-Performance Machine Learning Abstractions.” ArXiv, 2018. ↩︎
Liu, Yizhi, Yao Wang, Ruofei Yu, Mu Li, Vin Sharma, and Yida Wang. “Optimizing CNN Model Inference on CPUs.” In USENIX ATC, 1025–39, 2019. ↩︎
Jia, Zhihao, James Thomas, Todd Warszawski, and Alex Aiken. “TASO : Optimizing Deep Learning Computation with Automatic Generation of Graph Substitutions.” In SOSP, 47–62. New York: ACM, 2019. ↩︎ ↩︎
Wei, Richard, Lane Schwartz, and Vikram Adve. “DLVM: A Modern Compiler Infrastructure for Deep Learning Systems.” ArXiv, 2017. ↩︎
Nakandala, Supun, Karla Saur, Gyeong-In Yu, Konstantinos Karanasos, Carlo Curino, Markus Weimer, and Matteo Interlandi. “A Tensor Compiler for Unified Machine Learning Prediction Serving.” In OSDI, 2020. ↩︎

持久内存在图像搜索中的应用

Thu, 01 Apr 2021 11:11:34 +0800

原文发表于墨奇博客：https://blog.moqi.com.cn/persistent-memory/

在墨奇科技，我们用基于向量（vector）和图（graph）的近似搜索算法，构建高精度的大规模图像搜索引擎。目前，在 20 亿级别的指纹图像上，我们可以做到精确搜索的秒级响应。在这个过程中，我们将英特尔 ® 傲腾™持久内存融合到了图像搜索引擎中，使得系统的整体性价比得到了大幅度的提升。这个改进的核心是使用英特尔 ® 傲腾™持久内存的 App Direct 模式代替内存作为向量和图索引结构的缓存，在维持较高性能的同时，大幅度降低了内存开销。下面我们开始介绍整体方案。

背景 – 墨奇图像搜索系统

下图是墨奇图像搜索系统的架构。在插入一张图片时，我们先将图片存储到分布式文件系统中，然后结合一些计算机视觉算法和深度学习模型对图像进行特征提取，图像的特征一般可以表示为向量或图。对于每张图像，我们首先用深度学习模型得到一个高维的向量表示（vector/embedding）。其次，我们会对图像进行特征点检测，我们将特征点当做点（vertex），在相似的特征点之间连上边（edge），组成一个图（graph）。图中的点和边有时候也会带上更多的信息，如点的属性（如位置、方向和类型）和点周围图像的向量表示。对于库中的所有候选图像，在提取出特征后，我们将特征均匀的分配到图像搜索服务器上，并在内存中建立索引。在搜索时，用户的图片在经过特征提取服务器之后提取出来的特征，会被发送到图像搜索服务器上进行检索。

我们的图像搜索服务器架构如下图所示。在图像搜索服务器中，我们将特征索引文件缓存在内存之中，搜索分为 GPU 检索和 CPU 检索两个步骤：我们先用 GPU 检索快速的筛选候选图片，然后再用 CPU 进行精确检索。关于在图像搜索中的异构计算（主要是 GPU），我们在《异构计算》中进行了介绍。图像搜索服务器的一个问题在于，为了实现高速的检索，它需要使用大量的内存来缓存特征索引文件，这大大提高了硬件成本。我们曾尝试将部分索引文件放到高性能的 NVMe SSD 上，发现对于性能有较大的损失。

什么是持久内存？

**持久内存（英语：persistent memory，缩写 PMEM）**是一种新的存储介质，它是一种驻留在内存总线上的字节可寻址（byte-addressable）的高性能非易失存储设备。由于 PMEM 驻留在内存总线上，它可以像 DRAM 一样访问数据，这意味着 PMEM 具有与 DRAM 接近的速度和延迟以及 NAND 闪存的非易失性。下图是 PMEM 和 DRAM 的实物图，可以看到，在外观和接口上，PMEM 与 DRAM 类似。

由于硬件技术的限制，存储设备商可以制造出容量小访问速度快但单价较贵的存储器（如 CPU Cache 和 DRAM），也可以制造出容量大访问速度慢而廉价的存储器（如硬盘和磁带），但很难制造出访问速度快容量大还很便宜的存储器。因此，现代计算机通常将存储器分成若干级，称为存储器层次结构（如下图），按照离 CPU 由近到远的顺序依次是 CPU 寄存器、CPU Cache、内存（DRAM）、SSD 闪存、硬盘和磁带，越靠近 CPU 的存储器容量越小访问速度越快但越昂贵。

如下图所示，PMEM 的出现，在存储器层次结构上增添了新的一层。PMEM 兼具 DRAM 和 SSD 的一些优点：

PMEM 的容量通常远远大于 DRAM，而且也更廉价。
类似 SSD，PMEM 提供非易失性（non-volatile）存储，可以在不通电的情况下保证数据不受损。
类似 DRAM，PMEM 支持字节可寻址（byte-addressable），这意味着 CPU 指令可以直接存取 PMEM 上的数据，而不需要通过 I/O 总线上的 PCIe 接口。相比于对于 SDD 和硬盘的 I/O 操作，对于 PMEM 的访问节省一次驱动到操作系统的上下文切换（context switch），并且不存在由于块访问（block access）导致的读写放大问题，提升了 I/O 操作的效率。

持久内存上的使用

目前市场上较为成熟的 PMEM 产品只有英特尔 ® 傲腾™持久内存。这节我们介绍傲腾持久内存的三种运行模式：内存模式（Memory Mode）、App Direct 模式和混合模式（Dual Mode）。通过利用这几种运行模式，用户可以灵活地利用傲腾持久内存支持不同的工作负载。

内存模式

在内存模式下，PMEM 的使用与 DRAM 非常相似。不需要特定的软件或更改应用程序，PMEM 会模仿 DRAM，使数据保持“易失性”。PMEM 使用易失性密钥加密数据，而秘钥在每个电源循环后都会清除，这样在断电重启后，PMEM 上的数据就像 DRAM 一样丢失了。在内存模式下，PMEM 作为 DRAM 的扩展，并由主机内存控制器进行管理。PMEM 与 DRAM 没有固定的比率，其混合取决于应用程序的需求。就延迟特性而言，任何击中 DRAM 缓存的数据会提供小于 100 纳秒的延迟。任何高速缓存未命中都会流向 PMEM，这将在亚微秒范围内提供延迟。

除了不能利用 PMEM 的非易失性，我们在将图像搜索服务器运行在 PMEM 的内存模式上时，遇到的另一个问题是程序的性能难以预料。原因是内存模式使用 DRAM 进行缓存，如果缓存命中，那么访问 DRAM 的延迟在 14 ns 左右，但如果缓存失效，访问 PMEM 的延迟在 350ns 左右，这个性能差了 20 多倍。由于缓存的算法是由操作系统控制的，不受应用程序的控制，应用程序的性能会由于当前服务器上的工作负载，产生很大的性能波动。

App Direct 模式

在 App Direct 模式下，应程序可以独立的使用 DRAM 和 PMEM 资源，更加灵活。应用程序中需要较快访问的数据存在 DRAM 中，而其余的数据则可以放在容量更大的 PMEM 上。在 App Direct 模式下，PMEM 中的数据在断电后保持不变，这可以大幅度地减少重新启动后应用程序的加载时间（比如一个图像搜索引擎启动时要将索引文件加载到内存中）。此外，在 App Direct 模式下，PMEM 仍然像内存一样可以通过字节访问（byte-addressable），这避免了使用其它存储介质（如 NVMe SSD）时的读写放大问题。

但是，App Direct 模式要求我们对应用程序进行一些修改，以利用 PMEM 的这些良好特性。一个办法是使用英特尔推出的 Persistent Memory Development Kit (PMDK)。PMDK 包含了一系列旨在方便 PMEM 应用开发的函数库和工具。另一个方法是直接在 PMEM 上创建支持 devdax 的文件系统（如 XFS），然后利用 Linux 的内存映射文件 mmap 来直接读写 PMEM 上的数据。

混合模式

在混合模式下，我们可以将部分 PMEM 配置成内存模式，部分 PMEM 配置成 App Direct 模式，兼具两种模式的优点。

基于 PMEM 改写图像搜索服务器

回顾第一节的介绍，我们的图像搜索算法分成 GPU 检索和 CPU 检索两个阶段。结合 profiling 的结果，我们利用高性能计算分析模型 Roofline model 得到了如下结论：

GPU 检索接近于 memory-bound，主要瓶颈在于内存与 GPU 之间传输数据的带宽。同时，由于 GPU 的索引文件体积较小，因此我们将 GPU 的索引文件通过 pinned memory 的方式放置在主机的 DRAM 上。
CPU 检索接近于 compute-bound，瓶颈主要在 CPU 的算力。同时，由于 CPU 的索引文件体积较大，我们选择将 CPU 的索引文件放在 PMEM 上。

最后，介绍一些在持久内存上编程需要注意的事项：

数据持久化：数据写入 PMEM 后，需要 flush 才会被持久化。例如：
- 使用 mmap 中的 msync() 和 PMDK 中的 pmem_persist()；
- 如果写汇编则可以用 sfence、clwb
数据一致性：与 SSD 和硬盘不同，PMEM 写操作保证原子性的单位是 8 byte，在使用一些之前用在 disk 上的数据结构时需要注意。
内存泄漏：由于 PMEM 上的数据是持久的，重启进程或者服务器之后，PMEM 中内存泄漏都仍然存在，除非我们主动丢弃 PMEM 中的数据。因此要注意在 PMEM 编程中的内存泄漏问题。
字节可寻址（byte-addressable）：PMEM 的读写操作不需要像 SSD 和硬盘那样对齐到 4KB/8KB 的空间上，减少了读写放大。
错误处理：需要额外处理 PMEM 引发的硬件错误。

实践与测试结果

这节中，我们介绍如何配置一台带有 PMEM 的服务器，以及我们改进后的图像搜索服务器的性能。

下面是我们服务器的硬件配置：

组件	配置
CPU	2 x Intel(R) Xeon(R) Gold 6240 CPU @ 2.60GHz
DRAM	384 GB (12 x 32 GB Samsung DDR4 @ 2666 MT/s)
PMEM	1.5 TB (12 x 128 GB Intel® Optane™ Persistent Memory)
GPU	2 x NVIDIA 1080 ti
NVMe SSD	4 x Intel® DC SSD P3700
Platform	Supermicro SYS-4029GP-TRT

操作系统的配置：

Ubuntu 16.04
Linux Kernel 4.4.0-141
- kernel module: nvdimm driver / Direct access (DAX) support / Block translation table (BTT)
- 注：由于 Linux 对 PMEM 的支持还不太稳定，不同的 kernel 版本对性能影响较大

需要安装的 PMEM 管理工具：

ndctl: https://github.com/pmem/ndctl
ipmctl: https://github.com/intel/ipmctl

现在，我们可以开始配置 PMEM 了：

创建一个配置（称作 memory allocation goal），将所有的 PMEM 分配到 App Direct 模式：
```
$ ipmctl create -goal
```

重启服务器，确认分配信息：

$ ipmctl show -memoryresources
Capacity=5900.5 GiB
MemoryCapacity=0.0 GiB
AppDirectCapacity=5892.0 GiB
UnconfiguredCapacity=0.0 GiB
InaccessibleCapacity=8.2 GiB
ReservedCapacity=0.3 GiB

可以看到，一共 6 TB 的 PMEM 都被分配成了 App Direct 模式。

创建一个 namespace：
```
$ ndctl create-namespace
```

查看代表 PMEM 的块设备，可以看到 PMEM 被分成了 2 个块设备：

$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
pmem0 259:0 0 2.9T 0 disk
pmem13 259:1 0 2.9T 0 disk

用 XFS 格式化 PMEM 的块设备：

$ mkfs.xfs /dev/pmem0
$ mkfs.xfs /dev/pmem13

挂载 PMEM 上的文件系统：

$ mount -o dax /dev/pmem0 /mnt/pmem0
$ mount -o dax /dev/pmem13 /mnt/pmem1

完成这些操作后，/mnt/pmem{0,1} 目录就可以作为持久化的存储来使用。我们一般会在这个目录下创建索引文件，使用 mmap 访问。

我们在这个平台上测试了我们的图像搜索服务器性能。其中，GPU 的索引文件总是放在 DRAM 中，然后我们测试了将 CPU 索引文件放在 DRAM、PMEM 和 NVMe SSD 中这三种情况。下图中展示了三种情况下的数据库容量、搜索吞吐量和搜索延迟，所有数据都按照 DRAM 的性能进行了正则化（normalize）。从图中可以发现：

由于 DRAM、PMEM、NVMe SSD 的容量依次递增，使用 PMEM 和 NVMe SSD 相比只使用 DRAM 可以容纳更多的数据，也就是说性价比更高。
在搜索的吞吐量和延迟两项指标上，PMEM 只比 DRAM 差了 10% 左右，而 NVMe SSD 的搜索性能相差较远。这说明 PMEM 带来更高性价比的同时，性能损耗比 NVMe 小的多。

总结

持久内存（PMEM）的出现，为 AI 算法和系统的设计带来了新的机遇和挑战。PMEM 作为存储层次中新的一层，有一些独特的优势：

相比于上一层的 DRAM，PMEM 可以降低图像搜索系统的硬件成本，同时提高系统的可靠性。
相比于下一层的 NVMe SSD，PMEM 可以提高图像搜索系统的吞吐量，并降低搜索的时延、提高用户体验。

论文分享｜OSDI 2020 学习笔记

Sun, 08 Nov 2020 23:32:00 +0800

Correctness

Theseus: an Experiment in Operating System Structure and State Management

传统的 OS 中不同进程会共享很多状态，这会导致 state spill 的问题，即一个系统服务的崩溃，可能导致整个系统的崩溃，这时候其他不使用这个系统服务的进程的数据也会丢失。作者利用 Rust 语言中 memory ownership model 的特性实现了不同内核模块之间的 isolation 和 zero-cost state transfer，从而增强了系统的 evolvability 和 availability，能够实现比传统 OS 更强的 live evolution (我理解为加强版的的 live update) 和 fault recovery。他们通过一种名为 intralingual 的设计，让 Rust 编译器来保证他们的操作系统（名为 Theseus）实现是正确的。

RedLeaf: Isolation and Communication in a Safe Operating System

也是一个用 Rust 写的 OS，利用 Rust 的内存安全特性，不依赖硬件而实现了不同模块的隔离。在这个名为 RedLeaf 的 OS 上，作者实现了 10Gbps 网卡和 NVMe SSD 的驱动程序，并达到了和 DPDK/SPDK 相同的性能。说明 Rust 写的 OS 既安全，性能又好。

Specification and verification in the field: Applying formal methods to BPF just-in-time compilers in the Linux kernel

为了扩展 Linux 的功能，用户可以用 Berkeley Packet Filter (BPF) 来对网络数据进行分析和处理。为了加速，Linux 可以用 just-in-time (JIT) 编译器来把 BPF 的命令编译成机器代码。作者开发了 Jitterbug，一种用来实现 JIT 编译器的框架，可以形式化的验证 JIT 的正确性。作者用 Jitterbug 为 RISC-V 实现了一个新的 JIT 编译器，并发现了之前 JIT 编译器中的 16 个 bug（这些修改还都合并到了 Linux 中）。

Cobra: Making Transactional Key-Value Stores Verifiably Serializable

大家期望数据库有着可串行性（serializability）的性质，不过云服务供应商提供的数据库到底是否满足这个性质，大家也不知道。作者实现了 Cobra，是第一个可以用来验证真实世界的数据库是否具有可串行性的系统。

Determinizing Crash Behavior with a Verified Snapshot-Consistent Flash Translation Layer

这篇论文实现了一种叫做 snapshot-consistent flash translation layer (SCFTL) 的 FTL，也就是 SSD 控制器里面的系统。主要作用是提供更强的 crash guarantee。

Storage Systems are Distributed Systems (So Verify Them That Way!)

作者实现了一种经过形式化验证的分布式 key-value 存储服务，叫做 VeriSafeKV。所谓形式化验证，指的是这个数据库的功能正确性不是由各种单元测试和回归测试来保证，而是可以在数学上证明的。 VeriSafeKV 的数据结构是基于 B^ε-tree 而非常见的 LSM。它的插入性能比 RocksDB 慢了 6 倍，对于一个经过形式化验证的系统，算是不错了。

Storage

Fast RDMA-based Ordered Key-Value Store using Remote Learned Cache

SJTU IPADS 的魏星达（OSDI x 2 + SOSP + ATC 一作，ATC + EuroSys 二作……）基于他们以前的系统 DrTM (SOSP’15)，又搞了一个叫做 XSTORE 的 RDMA-based key-value store。这次是在客户端用机器学习学出了一个 cache 来加速读操作。

CrossFS: A Cross-layered Direct-Access File System

以前的文件系统实现在三个地方：linux kernel（如常见的 ext4 和 xfs 等）、user space（比如各种基于 FUSE 实现的文件系统）以及存储设备的 firmware 里。它们有各自的优缺点：kernel FS 的读写需要经过 syscall，增大了延迟；user FS 无法利用硬件上的计算资源，firmware FS 无法利用 host 上强大的 CPU。本文的 CrossFS 实现了一个横跨 kernel、user space、firmware 三个层次的文件系统（Cross-layered Direct-Access File System），达到的效果是更好的支持文件并发访问，同时保证 crash-consistency。

From WiscKey to Bourbon: A Learned Index for Log-Structured Merge Trees

这篇论文来自 Wisconsin 的 Arpaci-Dusseau 夫妇团队，描述了一个叫做 Bourbon 的新 LSM tree。他们用机器学习模型（准确的说是用了 greedy piecewise linear regression）改进了 LSM 数据结构（一种 key-value store 的常用数据结构）。查找性能是最好的生产级别 LSM 的 1.23x-1.78x。使用机器学习的思路有点像同一个 session 的 XSTORE。

LinnOS: Predictability on Unpredictable Flash Storage with a Light Neural Network

本文介绍了一个叫做 LinnOS 的操作系统，可以用机器学习预测 SSD 的每一次 I_O 操作的速度。基于这个预测，他们可以降低系统的延迟。比如在 Cassandra 里，如果他们预测到某个 I_O 操作的速度比较慢，那么他们就可以向另外一个节点发送一个同样的 I_O 操作。在论文的实验中，LinnOS 降低了 9.6-79.6% 的系统平均延迟，每次 I_O 操作预测的延迟大概是 4-6μs（SSD 的平均延迟是 100μs 级别）。

A large scale analysis of hundreds of in-memory cache clusters at Twitter

作者研究了 Twitter 里的 153 个 in-memory cache cluster，有如下发现：

In-memory caching 里有超过 35% 的 cluster 的 workload 是 write-heavy (write ratio > 30%)
用 TTL (time to live) 限制被 cache 的数据规模十分重要，比 eviction 算法更重要
Cache 的访问分布一般来说遵循 Zipf’s law，例外一般出现在 write-heavy 的 cluster 里
Cache 中的元素大小并不是一成不变的，有时候还可能突变（对于 memcache 这样按照 slab 组织内存的系统是个问题）
除非 cache 的 size 很小，否则 FIFO 基本跟 LRU 的效果一样好

Generalized Sub-Query Fusion for Eliminating Redundant I/O from Big-Data Queries

印度的微软研究院通过减少 I/O 操作，优化了 SparkSQL 上的查询速度。

OS & Networking

A Simpler and Faster NIC Driver Model for Network Functions

作者说现在的网卡驱动都是注重 performance 和 flexibility，而选择忽略了代码的 simplicity。本文实现了一个新的网卡驱动，注重 simplicity 和 performance，但牺牲了一定的 flexibility。由于注重 simplicity，他们的驱动更易于被形式化验证（用数学证明功能的正确性），同时 throughput 甚至比一些无法被形式化验证的驱动还要好。他们的 key idea：

the driver can efficiently reuse packet buffers because buffers follow a single logical path.

没有明白这句话是什么意思……

PANIC: A High-Performance Programmable NIC for Multi-tenant Networks

作者设计了一种叫做 PANIC 的可编程网卡，并在 FPGA 上测了一下。重点是他们的设计可以在 100 Gbps 带宽下实现 multi-tenant isolation。

Semeru: A Memory-Disaggregated Managed Runtime

首先得从 Datacenter Resource Disaggregation 说起。传统数据中心中有很多服务器，每台服务器上有自己的 CPU、内存和存储设备。有人说这样的配置不够灵活，比如我可能只是内存不够用了，想加内存，但并不想花钱在 CPU 和存储设备上。所以现在数据中心里出现了 resource-disaggregated architectures，把 CPU、内存和存储设备用高速网络（一般是 RDMA）连起来。Google 了一下，近年来，这个概念玩的比较六的是 UCSD WukLab 的 Prof. Yiying Zhang 和她的 PhD 单一舟。话说，Prof. Yiying Zhang 还是 Wisconsin 某著名夫妇的弟子。

回过头来，这篇论文跟 WukLab 似乎并没有关系，主要作者来自 UCLA。他们 argue，在 resource-disaggregated architectures 中，Java 这种需要 GC 的语言性能不好，因为他们用的内存跨越了网络，所以 GC 算法可能经过了 RDMA。于是，他们设计了一种名为 Semeru 的 distributed JVM 来解决这类问题。

Caladan: Mitigating Interference at Microsecond Timescales

为了保证不同任务的延迟要求，一般的办法是做资源隔离。比如有时候我们会把低延迟的任务绑定到某个 CPU 上。本文另辟蹊径，设计了一个叫做 Caladan 的 interference-aware CPU scheduler，它会动态的调整操作系统中 high-priority, latency-critical 任务和 low-priority, best- effort 任务的 CPU 核分配策略。在摘要中，他们 claim 比采用资源隔离方案的 state-of-the-art 系统 Parties[ASPLOS’19] 有 11,000x 的提升。这个提升实在太夸张了，不过看了正文，他们提升的是 low-priority, best-effort 任务的 tail latency。所以这个 claim 似乎不是很 fair，因为我想没什么人关心 low-priority, best-effort 任务的 latency。

Overload Control for µs-scale RPCs with Breakwater

在微服务架构中，如果一个 RPC 服务想要达到微秒级的延迟，那么它的通讯开销就占了很大的比中（相比于真正用来处理请求的时间）。作者设计了一个叫做 Breakwater 的 overload control scheme 来控制微服务架构中的通讯开销。

AIFM: High-Performance, Application-Integrated Far Memory

这篇论文的背景类似 Semeru，也是 Disaggregated Memory。他们提供了一个 far memory system，叫做 AIFM (application-integrated far memory)。AIFM 可以让程序员使用别的服务器上的 far memory，只要他们在代码中使用相应的 API。在 local memory 不够用的时候，AIFM 会自动交换 local/far memory。他们 claim 比目前最好的 kernel-integrated, paging- based far memory system Fastswap[EuroSys’20] 快了 61x。

值得一提的是，本文的一作 Zhenyuan Ruan，也是 Semerus 的作者之一，他在这次 OSDI 发了三篇论文。他的老板 Adam Belay 更是发了四篇……

Consistency

Performance-Optimal Read-Only Transactions

存储系统中的 read-only transaction 比 simple read 昂贵，因为需要 coordination 来维护 transaction 内多次 read 看到的都是同一个 snapshot。在 web 应用中，read-only transaction 是必须的，并且 read-only transaction 占据了总访问的 99% 以上。所以本文希望优化 read-only transaction 的 latency 和 throughput。

从算法角度分析 read-only transaction 的 overhead 来自：blocking、messages、metadata。因此理想的 read-only transaction 应该有 NOC 的性质

Non-blocking: 减少等待导致的 latency 和 throughput 下降
One-round communication: 减少 latency
Constant metadata: 需要保存的 metadata 不随着 transaction 数量增长

结合起来是 non-blocking messages that complete in one-round with constant metadata。

作者提出了 NOCS 理论，S 代表最强的一致性等级 strict serializabiliity。作者用反证法证明了不可能同时达到 NOC 和 S。作者提出了一种新的设计 PORT，可以同时达到 NOC 和一种比 strict serializability 稍弱的一致性等级 process-order serializability。

作者在 ScyllaDB (Cassandra in C++) 和 Eiger (Stronger Semantics for Low-Latency Geo-Replicated Storage, NSDI'13) 上实现了 PORT。然后用 YCSB benchmark 进行测试，比较了 simple read 和 read-only transaction 的性能，用 PORT 实现的 read-only transaction 最多只有 8% 的 overhead，性能基本和 simple read 一样，大大超越了用 OCC 实现的 read-only transaction。

Machine Learning 1

Serving DNNs like Clockwork: Performance Predictability from the Bottom Up

在 GPU 上，DNN 模型的 inference 时间是非常固定的。但是之前的 distributed model serving system（例如 Clipper[NSDI’17]）在实现 low-latency inference 的时候，没有利用模型 inference 时间固定这一特性，而是使用 over-provision 和 fair queueing 之类的手段，增加了资源的消耗。本文提出的 Clockwork 利用模型 inference 时间固定这一特性，可以为数千个不同的模型提供 inference 服务，同时保证 99.9999% 的 request 延迟低于 100ms。在保证非常好的 SLO 的同时，Clockwork 也做到了不同用户之间的 performance isolation。

A Unified Architecture for Accelerating Distributed DNN Training in Heterogeneous GPU/CPU Clusters

这是字节跳动公司搞的一个名为 BytePS 的分布式 DNN 训练框架，训练的大部分工作还是由 GPU 来完成，特点是利用闲置的 CPU 资源来加速 aggregating gradients（Intel CPU 的 AVX 指令集比较适合做这个）。值得一提的是，作者里有传说中大陆第一篇 SIGCOMM 的作者郭传雄，他最近两篇在字节跳动 AI Lab 的工作都是关于机器学习系统的。

Consensus

Virtual Consensus in Delos

本文的一作是 Mahesh Balakrishnan，在这篇论文中，他基于他之前关于 shared log 的几篇工作（NSDI'12 CORFU, OSDI'18 FuzzyLog），在 Facebook 实现了一个基于 shared log 的分布式强一致的存储层 Delos。Delos 在 Facebook 的地位类似于 Google 的 Chubby 和开源的 etcd 和 Zookeeper。

Delos 的 shared log 使用一个叫 VirtualLog 的接口，而 VirtualLog 提供一层新的抽象（All problems in computer science can be solved by another level of indirection），可以将多个 loglet 串在一起，这样 Delos 可以很容易的从一个 shared log 实现切换到另一个。比如可能早期的 Delos 基于用 Zookeeper 实现的 shared log，性能较差，利用 VirtualLog，它可以很容易的切换到性能更好的 shared log 而不影响 production 的使用。此外，这篇论文介绍了 Facebook 实现的几种 loglet，包括 NativeLoglet 和 StripedLoglet。

Bugs

Scheduling

Machine Learning 2

Ansor: Generating High-Performance Tensor Programs for Deep Learning

Ansor 是一个针对深度学习网络的张量计算优化和编译框架。类似 Apache TVM[OSDI'18, NIPS’18]，Ansor 可以用来优化深度学习网络在不同硬件架构（Intel、ARM、NVIDIA GPU）上的推理速度。Ansor 主要解决了两个问题：(1) 如何自动化的构造一个足够大的搜索空间（TVM 和 Halide[PLDI'13] 的搜索空间不够大，同时 TVM 还是需要不少人工操作）？Ansor 使用了一个层次化的搜索空间解决这个问题；(2) 如何有效的进行搜索？Ansor 先对完整的程序进行采样然后再进行调整。

从实验结果来看，对于各种神经网络，Ansor 在 Intel CPU、NVIDIA GPU、ARM CPU 上，都超过了 TensorFlow、TensorFlow Lite、PyTorch 和 AutoTVM[NIPS’18]。对于 Single Operator，Ansor 也超过了 Halide、FlexTensor[ASPLOS’20] 和 PyTorch。

这篇论文的第一作者郑怜悯也是 TVM 的贡献者之一，陈天奇大牛的学弟。Ansor 的代码已经被合并进了 TVM：RFC Ansor: An Auto-scheduler for TVM (AutoTVM v2.0) - RFC - Apache TVM Discuss。

Rammer: Enabling Holistic Deep Learning Compiler Optimizations with rTasks

Rammer 也是一个针对深度神经网络的编译框架。神经网络的并行有两层，第一层是从一个神经网络的 dataflow graph 上，我们可以找到独立的算子，进行并行；第二层是在一个算子的内部，比如矩阵乘法，可以进行并行。Rammer 的特点是提供了对算子和硬件的两种抽象，统一的对两层及的并行进行调度，提高了效率。作者在 NVIDIA GPU、AMD GPU 和 GraphCore IPU 上进行了实验，其中在 NVIDIA GPU 上的实验表明 Rammer 超越了 TensorFlow、TVM 和 TensorRT：

Rammer 和 Ansor 在同一个 session 里，互相之间没有直接比较（实验中用到的网络也不太一样）。不过他们的侧重点有所不同，Rammer 针对各类并行度很高的 XPU 进行优化，而 Ansor 还支持各类 CPU。

Rammer 的作者来自于北京大学、上海科技大学和 MSRA，它们的代码已经在 GitHub 上开源：nnfusion。

A Tensor Compiler for Unified Machine Learning Prediction Serving

传统的机器学习算法（如决策树、SVM）仍然在各种领域中广泛使用，它们的框架各异（如 scikit-learn、xgboost、SparkML 等），这些框架对于各种硬件平台（各类 CPU 和 GPU）上的 inference 性能优化做的并不一定很好。同时由于神经网络的流行，对深度神经网络的 inference 性能优化，已经有了大量的工作，比如同一个 session 中的 Ansor 和 Rammer，以及更早的 TVM 等。所以本文的作者推出了一个名为 Hummingbird 的系统，可以将传统的机器学习算法运行在深度学习推理引擎上，这样可以利用现成的深度学习框架来加速传统机器学习算法的 inference。

本文的作者来自于微软，代码已经开源：hummingbird。目前已经支持将 scikit-learn、LightGBM 和 XGBoost 中的决策树模型转换成可以在 PyTorch、TorchScript、ONNX 和 TVM 上运行的模型。

Retiarii: A Deep Learning Exploratory-Training Framework

这是一篇来自 MSRA 的工作（又是微软！），他们提出了一个叫做 Retiarii 的系统，可以帮助算法工程师们自动「炼丹」，包括自动进行特征工程、神经网络架构搜索、超参调优以及模型压缩。用户在定义网络的时候，可以指定神经网络上的一些部分如何 mutate，然后 Retiarii 就会从定义的网络空间中开始搜索。Retiarii 用了一些启发式的方法加速搜索，并且利用搜索空间中模型的相似性减少计算量。

本文的代码已经开源：microsoft/nni at retiarii_artifact，是微软 AutoML 框架 nni 的一部分。

KungFu: Making Training in Distributed Machine Learning Adaptive

在进行分布式的神经网络训练时，用户要设定很多参数，包括网络的超参和分布式系统的参数（worker 数量和通信的拓扑结构），这对于用户非常不友好。KungFu 是一个基于 TensorFlow 的分布式训练框架，可以在训练过程中帮助用户自适应的设置这些参数。

Linux Network Tuning - 10 GE

Fri, 14 Sep 2018 20:26:21 +0800

最近在研究如何为公司搭建 40/100 GE，在购买新设备之前，决定先在现有的 10 GE 网络上做一些 benchmark。做完才发现现有的网络利用率还有不少的提高空间。

测试方式

测试机器

Server-A：用于运行 NFS 服务器（IP: 10.1.1.1）
Client-B: 用于运行 NFS 的客户端

用 iperf 测试网速

在 Server-A 上：

iperf3 -s -p 12000 -i1

在 Client-B 上：

iperf3 -c storage0002 -p 12000 -i1 -t 30

用 fio 测试 NFS 的性能

在 Client-B 上 mount NFS（假设 Server-A 在 /srv/nfs 上配置了一个 NFS）：

sudo mount 10.1.1.1:/srv/nfs /mnt/tmp -v

Fio 的测试文件 read.fio:

[global]
bs=2M
iodepth=1
direct=1
ioengine=libaio
randrepeat=0
group_reporting
time_based
runtime=60
filesize=2G
numjobs=4

[job]
rw=read
filename=/mnt/tmp/test
name=read

运行 fio 测试：

fio read.fio

Ubuntu 默认配置下的测试结果

iperf 的速度：

- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-30.00  sec  32.9 GBytes  9.41 Gbits/sec  291             sender
[  4]   0.00-30.00  sec  32.9 GBytes  9.41 Gbits/sec                  receiver

可以看到用 iperf 测试时，基本还是把 10 GE 的带宽用满了。

用 fio 在 NFS 上的测试结果是: 7.5 Gbits/sec！大大的低于我们的预期。

调整 Linux 的 TCP 协议栈

TCP Tuning 可以参考 ESnet 的经验：https://fasterdata.es.net/host-tuning/linux/test-measurement-host-tuning/

Step 1. 配置 Jumbo frames（参考 https://askubuntu.com/a/122835）：

ip link set <NIC> mtu 9000  # <NIC> 是对外的网卡名称（比如 eth0）

Step 2. 调整 kernel 中网络相关的参数，修改 /etc/sysctl.conf：

# increase TCP max buffer size setable using setsockopt()
# allow testing with 256MB buffers
net.core.rmem_max = 268435456
net.core.wmem_max = 268435456
# increase Linux autotuning TCP buffer limits
# min, default, and max number of bytes to use
# allow auto-tuning up to 128MB buffers
net.ipv4.tcp_rmem = 4096 87380 134217728
net.ipv4.tcp_wmem = 4096 65536 134217728
# recommended to increase this for CentOS6 with 10G NICS or higher
net.core.netdev_max_backlog = 250000
# don't cache ssthresh from previous connection
net.ipv4.tcp_no_metrics_save = 1
# Explicitly set htcp as the congestion control: cubic buggy in older 2.6 kernels
net.ipv4.tcp_congestion_control = htcp
# If you are using Jumbo Frames, also set this
net.ipv4.tcp_mtu_probing = 1
# recommended for CentOS7/Debian8 hosts
net.core.default_qdisc = fq

使我们对 /etc/sysctl.conf 的改动生效：

sysctl -p
service nfs-server restart # 因为我们要用 fio 测试 NFS，所以重启一下 NFS 服务

Step 3. 增大 TCP 的 Transmit Queue Length (txqueuelen)

ifconfig <NIC> txqueuelen 10000  # <NIC> 是对外的网卡名称（比如 eth0）

修改 /etc/rc.local，添加以下这行：

/sbin/ifconfig <NIC> txqueuelen 10000  # <NIC> 是对外的网卡名称（比如 eth0）

优化后的测试结果

iperf 的测试结果:

- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-30.00  sec  34.6 GBytes  9.90 Gbits/sec  419             sender
[  4]   0.00-30.00  sec  34.6 GBytes  9.90 Gbits/sec                  receiver

iperf 的结果只是稍微高了一点（提升空间本来也不大了）。

用 fio 在 NFS 上的测试结果：9.76 Gbits/sec。NFS 的性能提升是巨大的，比较有用的一个改动应该是 jumbo frames。中间还尝试了 Google 的 BBR 拥塞控制算法，用处并不大。BBR 增对的是广域网上少量丢包的情况，在数据中心的网络中反而可能导致 NFS 的速度变慢。

如何成为系统管理员（sysadmin）？

Thu, 31 May 2018 20:50:11 +0800

Linux 入门学习

实践课程：

Teeny Tiny Linux Server Course

参考书：

寻求帮助：

善用 Google 和 Stackoverflow
RTFM: read the fucking manual!
Reddit: r/linuxadmin/, r/linux_mentor

Linux 的进阶学习

Reddit 上有一个非常好的 list，列出了成为一名 Linux 系统管理员需要学习的内容，可以作为进阶学习的参考：How did you get your start? : linuxadmin。

This is what I tell people to do, who ask me “how do I learn to be a Linux sysadmin?”.

Set up a KVM hypervisor.

Inside of that KVM hypervisor, install a Spacewalk server. Use CentOS 6 as the distro for all work below. (For bonus points, set up errata importation on the CentOS channels, so you can properly see security update advisory information.)

Create a VM to provide named and dhcpd service to your entire environment. Set up the dhcp daemon to use the Spacewalk server as the pxeboot machine (thus allowing you to use Cobbler to do unattended OS installs). Make sure that every forward zone you create has a reverse zone associated with it. Use something like “internal.virtnet” (but not “.local”) as your internal DNS zone.

Use that Spacewalk server to automatically (without touching it) install a new pair of OS instances, with which you will then create a Master/Master pair of LDAP servers. Make sure they register with the Spacewalk server. Do not allow anonymous bind, do not use unencrypted LDAP.

Reconfigure all 3 servers to use LDAP authentication.

Create two new VMs, again unattendedly, which will then be Postgresql VMs. Use pgpool-II to set up master/master replication between them. Export the database from your Spacewalk server and import it into the new pgsql cluster. Reconfigure your Spacewalk instance to run off of that server.

Set up a Puppet Master. Plug it into the Spacewalk server for identifying the inventory it will need to work with. (Cheat and use ansible for deployment purposes, again plugging into the Spacewalk server.)

Deploy another VM. Install iscsitgt and nfs-kernel-server on it. Export a LUN and an NFS share.

Deploy another VM. Install bakula on it, using the postgresql cluster to store its database. Register each machine on it, storing to flatfile. Store the bakula VM’s image on the iscsi LUN, and every other machine on the NFS share.

Deploy two more VMs. These will have httpd (Apache2) on them. Leave essentially default for now.

Deploy two more VMs. These will have tomcat on them. Use JBoss Cache to replicate the session caches between them. Use the httpd servers as the frontends for this. The application you will run is JBoss Wiki.

You guessed right, deploy another VM. This will do iptables-based NAT/round-robin loadbalancing between the two httpd servers.

Deploy another VM. On this VM, install postfix. Set it up to use a gmail account to allow you to have it send emails, and receive messages only from your internal network.

Deploy another VM. On this VM, set up a Nagios server. Have it use snmp to monitor the communication state of every relevant service involved above. This means doing a “is the right port open” check, and a “I got the right kind of response” check and “We still have filesystem space free” check.

Deploy another VM. On this VM, set up a syslog daemon to listen to every other server’s input. Reconfigure each other server to send their logging output to various files on the syslog server. (For extra credit, set up logstash or kibana or greylog to parse those logs.)

Document every last step you did in getting to this point in your brand new Wiki.

Now go back and create Puppet Manifests to ensure that every last one of these machines is authenticating to the LDAP servers, registered to the Spacewalk server, and backed up by the bakula server.

Now go back, reference your documents, and set up a Puppet Razor profile that hooks into each of these things to allow you to recreate, from scratch, each individual server.

Destroy every secondary machine you’ve created and use the above profile to recreate them, joining them to the clusters as needed.

Bonus exercise: create three more VMs. A CentOS 5, 6, and 7 machine. On each of these machines, set them up to allow you to create custom RPMs and import them into the Spacewalk server instance. Ensure your Puppet configurations work for all three and produce like-for-like behaviors.

Do these things and you will be fully exposed to every aspect of Linux Enterprise systems administration. Do them well and you will have the technical expertise required to seek “Senior” roles. If you go whole-hog crash-course full-time it with no other means of income, I would expect it would take between 3 and 6 months to go from “I think I’m good with computers” to achieving all of these – assuming you’re not afraid of IRC and google (and have neither friends nor family …).

其它知识

Cloud 相关知识

学习资料：

Reddit 上关于学习 Cloud 的路线：So, you want to learn AWS? AKA, “How do I learn to be a Cloud Engineer?”
- 中文版：一文掌握AWS，成为云计算工程师
Qwiklabs Labs 提供一系列的实践教程：Home | Qwiklabs

分布式环境下的监控与日志

监控机器与服务的状态：Prometheus + Grafana
分布式的日志收集与分析：Elasticsearch + Kibana + fluentd

实践指南

这节列出一些可供学习的自动部署方案：

Linux 上的网络链路聚合

Tue, 15 May 2018 12:22:34 +0800

链路聚合（bonding or link aggregation）将多个物理网卡捆绑在一起，形成一个逻辑端口。它可以用于增加链路带宽和提供链路的冗余与容错。以下是我参考 Ubuntu Bonding 后在 Ubuntu 16.04 上配置的步骤：

安装：
```
sudo apt-get install ifenslave
```
载入提供 bonding 的 kernel module：
```
sudo modprobe bonding
```

在电脑启动时自动载入 bonding 模块，将 bonding 加入 /etc/modules：

# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.

bonding

配置 /etc/network/interfaces：

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

auto ens6f0
iface ens6f0 inet manual
    bond-master bond0

auto ens6f1
iface ens6f1 inet manual
    bond-master bond0

auto bond0
iface bond0 inet static
    address 192.168.10.100
    netmask 255.255.255.0
    bond-mode 6
    bond-miimon 100
    bond-slaves ens6f0 ens6f1

bond-mode 有多重选择，参考 Ubuntu Bonding
重启网络服务：
```
sudo service networking restart
```

FAQ

Q1. 错误信息：

RTNETLINK answers: File exists
Failed to bring up XXX

A1. 解决方案：

确认 /etc/network/interfaces 中的 gateway 只设置了一次；
执行：
```
sudo ip addr flush dev XXX
```

Q2. 在 Ubuntu Desktop 下，通过 /etc/network/interfaces 配置网络会与 GUI 下的 NetworkManager 服务冲突，我们需要关闭并禁用这个服务：

sudo systemctl stop NetworkManager.service
sudo systemctl disable NetworkManager.service

Qin Liu's Academic Family Tree

Tue, 18 Nov 2014 23:19:18 +0800

My PhD advisor is John C.S. Lui. I worked up the tree of academic ancestors (their advisors, etc.) via The Mathematics Genealogy Project.

Qin Liu, Ph.D., Chinese University of Hong Kong, Hong Kong, 2016
└ John C. S. (Chi Shing) Lui, Ph.D., University of California, Los Angeles, 1991
  └ Richard R. Muntz, Ph.D., Princeton University, 1969
    └ Edward Grady Coffman, Jr., Ph.D., University of California, Los Angeles, 1966
      └ Leonard Kleinrock, Ph.D., Massachusetts Institute of Technology, 1963
        └ Edward Arthurs, Sc.D., Massachusetts Institute of Technology, 1955
          └ William Kirby Linvil, Ph.D., Massachusetts Institute of Technology, 1949
            └ Ernst Adolph Guillemin, Sc.D., Ludwig-Maximilians-Universität München, 1926
              └ Arnold Johannes Wilhelm Sommerfeld, Ph.D., Universität Königsberg, 1891
                └ C. L. Ferdinand (Carl Louis) Lindemann, Ph.D., Friedrich-Alexander-Universität Erlangen-Nürnberg, 1873
                  └ C. Felix (Christian) Klein, Dr. phil., Rheinische Friedrich-Wilhelms-Universität Bonn, 1868
                    ├ Julius Plücker, Ph.D., Philipps-Universität Marburg, 1823
                    │ └ Christian Ludwig Gerling, Dr. phil., Georg-August-Universität Göttingen, 1812
                    │   └ Carl Friedrich Gauss, Ph.D., Universität Helmstedt, 1799
                    │     └ Johann Friedrich Pfaff, Dr. phil., Georg-August-Universität Göttingen, 1786
                    │       ├ Abraham Gotthelf Kästner, Ph.D., Universität Leipzig, 1739
                    │       │ └ Christian August Hausen, Dr. phil., Martin-Luther-Universität Halle-Wittenberg, 1713
                    │       │   ├ Johann Christoph Wichmannshausen, Ph.D., Universität Leipzig, 1685
                    │       │   │ └ Otto Mencke, Ph.D., Universität Leipzig, 1665
                    │       │   │   └ Jakob Thomasius, Magister der Philosophie, Universität Leipzig, 1643
                    │       │   │     └ Friedrich Leibniz, Magister der Philosophie, Universität Leipzig, 1622 // Gottfried Leibniz's father; unknown advisor
                    │       │   └ Johann Andreas Planer // to be continued
                    │       └ Johann Elert Bode, Handelsakademie Hamburg // to be continued
                    └ Rudolf Otto Sigismund Lipschitz, Dr. phil., Universität Berlin, 1853
                      ├ Gustav Peter Lejeune Dirichlet, Honorary, Rheinische Friedrich-Wilhelms-Universität Bonn, 1827
                      │ ├ Simeon Denis Poisson, Ph.D., École Polytechnique, 1800
                      │ │ ├ Pierre-Simon Laplace
                      │ │ │ └ Jean Le Rond d'Alembert // unknown advisor
                      │ │ └ Joseph Louis Lagrange
                      │ │   └ Leonhard Euler, Ph.D., Universität Basel, 1726
                      │ │     └ Johann Bernoulli, Medicinae Dr., Universität Basel, 1690, 1694
                      │ │       └ Jacob Bernoulli, Dr. hab. Sci., Universität Basel, 1684
                      │ │         └ Nicolas Malebranche, 1672
                      │ │           └ Gottfried Wilhelm Leibniz, Dr. phil., Universität Leipzig, 1666; Dr. jur., Universität Altdorf, 1667; Académie royale des sciences de Paris, 1676
                      │ │             ├ Jakob Thomasius, Magister der Philosophie, Universität Leipzig, 1643 // see previous
                      │ │             ├ Erhard Weigel, Ph.D., Universität Leipzig, 1650
                      │ │             │ └ Philipp Müller, Magister artium, Universität Leipzig, 1604 // to be continued
                      │ │             ├ Bartholomäus Leonhard Schwendendörffer, Dr. jur., Universität Leipzig, 1656 // unkown advisor
                      │ │             └ Christiaan Huygens, Juris utriusque Doctor, Université d'Angers, 1655 // to be continued
                      │ └ Jean-Baptiste Joseph Fourier, Ph.D., École Normale Supérieure
                      │   └ Joseph Louis Lagrange // see previous
                      └ Martin Ohm, Dr. phil., Friedrich-Alexander-Universität Erlangen-Nürnberg, 1811
                        └ Karl Christian von Langsdorf, Dr. phil., Georg-August-Universität Göttingen and Justus-Liebig-Universität Gießen and Universität Erfurt, 1781
                          └ Abraham Gotthelf Kästner, Ph.D., Universität Leipzig, 1739 //see previous

This post was inspired by Erik Demaine’s Academic Family.