600 行 Python 干掉向量库:RAG 底座的「去专门化」回潮

一、单表 RAG：第一个反水的人——StarRocks Rocky

第一个把这件事说破的，是 Phoenix AI 的 Billy Chang。他们做了一个 Slack 内部的 Q&A bot，名字叫 Rocky。Rocky 的架构可以用一句话讲完：

一张 OLAP 表 = 整个 RAG。

具体来说，文档切片、768 维 Gemini embedding、关键词、相似度分数，全部塞进一张 StarRocks 的 PRIMARY KEY 模型表。检索就一条 SQL：用 approx_cosine_similarity 排序，取 top 8。整个 bot 大约 600 行 Python + 一张表 + 一个 Gemini API key。没了。

建议配图位置：这里可放一张极简的架构对比图——左边「Embedding 服务 + 向量库 + 元数据 DB + 检索编排」四件套，右边「单 OLAP 表 + Gemini function call」一件套。视觉冲击来自减法。

这条路径的设计原则被作者一句话点透：

"如果你的分析型数据库已经支持数组类型列和余弦相似度函数，你就不需要第二个数据系统来做向量搜索。"

这是架构师会点头的一句话。第二个数据系统意味着什么？意味着多一套部署、多一套备份、多一套一致性对账、多一套监控告警、多一套升级窗口。在 Rocky 这种规模下，这些隐性运维成本远超向量检索本身带来的收益。

但 Rocky 真正有想法的，不是"塞进一张表"，而是它对 RAG 的重新定位：

RAG 是 Tool，不是 Pipeline

Rocky 把 search_starrocks_doc 暴露成一个 function call，由 Gemini 自己决定何时调用、调用几次（每轮上限 10 次），还能和 Gemini 内置的 Google Search 混用。这不是 pipeline，而是把检索降级成一个 LLM 可调用的工具。

这一点比"一张表"更值得抄。很多团队把 RAG 当成一条固定 pipeline：query → embed → 检索 → 拼 prompt → 生成。问题在于，不是每个问题都需要检索，也不是每个问题都需要同样的检索次数。让 LLM 自己决策，往往比写死的 pipeline 更省钱也更准。

原子化热更新：PK 表 + Stream Load

文档更新是个被低估的难点。很多向量库的更新是"软更新"——新 chunk 进去、旧 chunk 还在，检索结果会出现半新半旧。Rocky 的解法很干脆：文档更新时整库重新切片、重新 embedding、一次性 PUT 进表，靠 PRIMARY KEY 表的语义保证——用户要么看到旧语料，要么看到全量新语料，绝不半新半旧。

这种"原子化热更新"在生产里非常重要，尤其是知识库频繁变动的场景（内部文档、产品手册）。

真正的瓶颈不在检索

Rocky 团队给了一组非常诚实的生产经验，其中两条我会原话引用：

"分块工程量约是集成向量搜索工程量的 10 倍。"

"RAG 检索固然重要，但 prompt engineering 往往是抑制幻觉更便宜、更快的杠杆。"

这两句话直接戳破了一个流行幻觉——很多团队把"换向量库"当成提升 RAG 质量的银弹，但实际上瓶颈 90% 在 chunking 和 prompt 上。Billy Chang 还顺手补了一刀：

"对 Q&A bot，听起来很自信的错误答案，比没有答案更糟糕。"

这条路的边界

我不是来鼓吹"全都用一张表"的。Rocky 这套成立的前提很具体：

• • 知识库规模在单机 OLAP 表能扛的量级（不是亿级向量）；
• • 检索是辅助 LLM 的 tool，不是高 QPS 的纯检索服务；
• • 你已经有一台 StarRocks / 类似的分析库在跑，加一列数组类型是边际成本。

如果你的场景是亿级向量、毫秒级 P99、高并发纯检索（比如电商搜索召回），这张表就扛不住了。这正是下一节要讲的——即便要做专门库，也得换一种做法。

二、即便做专门库，也要 disk-first：Skeg

承认了"专门库在重负载场景仍然成立"之后，下一个问题来了：专门库应该长什么样？ Skeg 给了一个反共识但务实的答案——disk-first, RAM-frugal。

它的设计哲学一句话：把内存还给模型。

这个判断的背景是当下最尖锐的资源争夺：RAG 服务、SaaS 多租户、Agent 场景下，向量库和 LLM 推理正在抢同一块 RAM。 你在本地起一个 7B 模型 + 一个 Qdrant，你会发现 Qdrant 把显存/内存吃掉一大块，模型推理反而 OOM。Skeg 的方案是：完整高维向量存 SSD，内存里只留"小的、量化的工作集"。

这种取舍是不是亏了？看实测（10 万条 1024 维向量、单租户）：

读这张表的方式很重要：Skeg 在保持 recall 1.000 的前提下，把 RAM 压到了 Qdrant 的 1/19。这不是用精度换内存的妥协，这是工程重新分配资源。

更狠的对比在多任务下：M1 Pro 同时跑 3B 参数 LLM + 100 万向量时，Skeg 峰值 RSS 仅 67 MiB，Qdrant 高达 2,387 MiB，约 35 倍。延迟方面 2.5ms p50，1024 维约 780 QPS 饱和——对绝大多数 RAG 检索场景来说，这个延迟和吞吐完全够用。

多租户：构造出来，不是过滤出来

Skeg 还有一个我觉得很对的设计判断：一租户一索引。

传统做法是"所有租户的数据放一个索引，查询时加 filter 过滤"。这种做法的隐患是——filter 写错一次就是跨租户泄漏。Skeg 把多租户"构造出来"而不是"过滤出来"：一次查询在物理上就不可能碰到另一个租户的向量。再叠加硬配额（max_vectors、max_disk_bytes）和公平缓存淘汰，这套设计在 SaaS 多租户场景下几乎是教科书级的。

架构师视角：当一个安全属性能从"靠 filter 正确性"上升到"物理上不可能违反"，那就应该上升。安全靠纪律是脆弱的，靠结构才是稳的。

工程细节

Skeg 用 Rust 1.88+ 写，认证用 argon2id，可观测性走 Prometheus / OpenTelemetry / tracing，双引擎（KV + 向量）共用 Redis 兼容协议。发布版面向 aarch64——这是个细节，说明它瞄准的是云 ARM 实例和 Apple Silicon，都是和 LLM 推理抢 RAM 的主战场。

Skeg 的边界

我必须把代价讲清楚：

• • disk-first 的代价是写入路径和 SSD I/O 抖动。如果你的 SSD 是共享云盘或 IOPS 受限，延迟方差会变大；
• • Skeg 的"亚线性性能"依赖过滤检索规划器，复杂过滤条件下需要实测，不要拿 benchmark 直接外推；
• • 它目前是个相对新的项目，生态、社区、托管方案的成熟度远不及 Milvus / Qdrant——生产采用前要评估团队支撑能力。

判断：当你要把宝贵 RAM 留给 LLM 推理（本地部署、单机多租户、Agent on-device），disk-first + 量化工作集是反共识但务实的取舍。当你的瓶颈是"算力而非内存"，那 Skeg 的优势就发挥不出来。

三、检索可加密：XTrace

第三个趋势更前沿，但场景非常硬：密文上做最近邻检索。

XTrace 抛出的核心命题，戳到了所有托管向量库的软肋：

"市面上每一个向量数据库，都要求你把数据以明文形式交给第三方。"

对个人开发者这无所谓，但对金融、医疗、法务这些数据出域有强约束的行业，这是结构性的拦路虎。你不可能把病历、合同、客户尽调材料做成 embedding 然后丢上某个 SaaS 向量库——合规那一关过不了。

XTrace 的解法是零知识加密检索，密码学上很硬：

• • embedding 向量用 Paillier 同态加密——服务器能在密文上直接做最近邻运算，全程不解密；
• • 原始文本块用 AES-256 加密；
• • 秘密钥永不离开本地，服务器永远看不到一字节明文。

四步流程：

1. 1. 本地 embedding + 本地加密；
2. 2. 服务器只存密文，查询也本地加密后再发送；
3. 3. 服务器"盲算"——在加密向量上算最近邻；
4. 4. 返回加密结果，本地用秘密钥解密。

架构师视角：注意 Paillier 同态加密是部分同态（支持加法同态），它适合做余弦相似度这种"加法和点积"可表达的运算。如果你的检索要用更复杂的距离度量或量化索引（如 HNSW + 乘积量化），同态方案能不能扛、recall 损失多大，是需要实测的——XTrace 的 README 没给性能/延迟/吞吐基准，这是个明确的 [需核实] 项。

模块上 XTrace 分了 x-vec（加密向量搜索）和 x-mem（加密 Agent 记忆，coming soon），本地 embedding 默认用 Sentence Transformers（示例 mxbai-embed-large-v1），还提供 CLI 做密钥生成 / 上传 / 检索 / 凭证管理。仓库作者很直白：

"This repo exists so you can verify the encryption yourself."

XTrace 的判断

这是个场景驱动的工具，不是普适方案。它的价值在两点：

1. 1. 化解"上云做向量搜索"和"数据合规"的矛盾——这是金融/医疗/法务做 RAG 时最痛的一点；
2. 2. 它示范了一种密码学第一性的检索架构，对自建加密检索系统有参考价值。

代价同样明确：同态加密的开销不小，吞吐和延迟会显著低于明文检索，且生态、性能数据都还在早期。如果你的场景没有出域约束，别为了"加密"而加密——这是用复杂度换一个你不需要的安全属性。

四、范式收敛：HelixDB

如果说前三个趋势是在"专不专门"和"省不省内存"上做文章，第四个趋势更野心勃勃：把多种数据库范式收敛到一套引擎。

HelixDB 的定位是"OLTP graph-vector 数据库"，用 Rust 从零构建，架在对象存储之上，专为知识图谱和 AI 记忆设计。它的 slogan 简单粗暴：

"Just Use Helix."

背后的判断是：当下的 AI 应用正在堆出一座数据库巴别塔。一个企业级 Agent 通常长这样：

• • 一个应用 DB（PostgreSQL）存业务数据；
• • 一个关系 DB 存结构化分析；
• • 一个向量 DB 存 embedding；
• • 一个图 DB 存实体关系和知识图谱；
• • 一个 KV 存会话状态。

这套堆叠的运维复杂度，是真实生产里每天都在出血的伤口。HelixDB 的方案是把 图、向量、KV、文档、关系多范式合并到一个平台，目的是"消灭架构臃肿"：

"你不再需要一个独立的应用 DB、关系 DB、向量 DB、图 DB。"

两种形态

HelixDB 提供本地和云两种形态：

• • 本地容器：默认内存模式，加 --disk 可持久化，适合开发调试；
• • HelixDB Cloud：建立在对象存储之上，分布式高可用，完整 ACID 事务，架构为单写者 + 自动扩缩容读节点。

"单写者 + 自动扩缩容读节点"这个组合很有意思——它本质上是承认了"对象存储上做高并发写很难"，于是用一个串行化的写者换 ACID，再用读节点横向扩展吞吐。这是个诚实的工程妥协，比那些号称"对象存储上既 ACID 又高并发写"的方案靠谱。

查询层面，HelixDB 提供 Rust / TypeScript / Go / Python SDK，用各语言 DSL 写查询，编译成 JSON AST 发给运行实例。这种"DSL 编译成 AST"的做法，是为了在不暴露通用查询语言（比如 SQL/Cypher/GraphQL 三选一的尴尬）的前提下，提供跨语言的查询能力。

HelixDB 的判断（含明确保留）

这里我必须给一个带保留意见的判断：

• • 趋势判断成立：图 + 向量 + 对象存储的组合，是 AI 原生数据库的明显方向。把多范式收敛到一套引擎，对降低架构臃肿是有价值的；
• • 成熟度存疑：HelixDB 的 README 没有给出性能、延迟、吞吐数字，也没有和 Neo4j / Turso 的对比——这是个明确的 [需核实] 项。多范式合并的系统，最常见的问题是"每一范式都做不深"——图查询比不过 Neo4j，向量检索比不过 Qdrant，关系分析比不过 Postgres。在没有实测前，不要把它当主力库；
• • 生产采用建议：可以在新的、非核心的 AI 记忆 / 知识图谱场景试用 HelixDB，验证它在你具体 query 模式下的表现；不要为了"统一架构"而把已经稳定的 Postgres + 向量库组合拆掉重做。

判断：范式收敛是值得关注的方向，HelixDB 是一个早期但有意思的样本。但"早期"两个字请你认真对待。

五、批处理复兴：IgniteMS

前四个趋势都在讲"检索侧"的重新设计，第五个趋势转到"写入侧"——大规模 embedding 的批处理复兴。

这个话题之所以重要，是因为很多团队对 embedding 成本有错误的直觉。脑子里默认的是"调一下 OpenAI API，几行代码搞定"。但当你真的要给亿级文档做 embedding（一次性全量索引、定期 reindex、多模型横向对比），账单会让你重新思考。

IgniteMS 给了一组非常硬的实测：用 1 台 p4d.24xlarge（8× A100 40GB spot），嵌入 685,520,494 条文本，总墙钟 1,915 秒（约 31.9 分钟），平均吞吐 357,893 条/秒，峰值 506,589 条/秒，单位成本约 0.01 美元/100 万条消息。

更直观的对比是成本：OpenAI text-embedding-3-small 约 1.36 美元/100 万条，IgniteMS 约 0.01 美元/100 万条——约 136 倍成本差。

架构师视角：136 倍这个数字要冷静看。它对比的是自建 spot 实例 + 自托管 vs 托管 API 的零售价。如果你已经养着 GPU 集群，边际成本确实能压到这个量级；如果你要为这套基础设施专门招人、付云厂商钱、维护 TensorRT 编译流程，TCO 不一定有 136 倍优势。但即便打个对折，量级差异也是真实的——亿级 reindex 时这就是"做不做得了"和"做不做得起"的差别。

它凭什么这么快

IgniteMS 的吞吐来自 5 个工程手段，每一个都值得抄作业：

1. 1. TensorRT 编译——为 GPU 架构和 batch shape 生成专属 kernel，绕开 ONNX/PyTorch 抽象层（TensorRT 11 混合精度）；
2. 2. 分桶批处理——按 token 长度分组，避免短句被强制 pad 到长句而浪费算力；
3. 3. 异步 CPU 流水线——tokenization / batching / GPU dispatch 互不阻塞；
4. 4. 无锁多 GPU 管理——单进程内用无锁队列协作多张 GPU，而不是每张 GPU 起一个容器走 HTTP 通信；
5. 5. 引擎缓存——编译完即缓存复用，避免重复编译。

第 4 点尤其值得说。多 GPU 通信走 HTTP 是很多批处理框架的隐藏开销——你以为是 GPU 慢，其实是 GPU 之间在等网络。无锁队列直接干掉这层，是个朴素但很有效的优化。

IgniteMS 原生支持 60 个模型（E5 / BGE / GTE / MiniLM / MPNet / Nomic / Jina / mxbai / Snowflake Arctic / LaBSE / stella 等，覆盖中文/法语/俄语/韩语），encoder 和 decoder 双架构都支持。

和主流方案的吞吐对比

这张表（100 万条 MSMARCO 文段、8× A100 80GB、单 GPU 跑 e5-small、56,002 msg/s 基线）信息量很大：

读法：SentenceTransformers 是大家最熟的工具，但它比 IgniteMS 慢近 23 倍。这不是 SentenceTransformers 的错——它是为通用性、易用性设计的，不是为极致吞吐设计的。但很多团队在生产里直接拿 SentenceTransformers 跑亿级 embedding，白白烧掉一个数量级的 GPU 时间。

批处理复兴的判断

这一节的判断最干脆：

• • 亿级数据量，必须自建批处理。这个量级下调 API 的成本和速率限制都受不了；
• • 百万级以下，调 API 更划算。0.01 美元/100 万条的前提是你已经持有 GPU 资源，小数据集场景里这套基础设施的搭建和运维成本，远超省下的 token 钱；
• • Rust + TensorRT + 无锁多 GPU 这套技术栈正在重塑"embedding 工程师"这个角色——它越来越像一个高性能计算问题，而不是 ML 问题。

收尾：架构师选型矩阵

讲完五个趋势，回到开篇那个问题：你的 RAG，到底该用什么？

我不打算给你一个"全都好"的中庸答案。下面这张矩阵是我作为架构师，在 2026 年这个时点上会给出的明确判断：

建议配图位置：这张表是本文的"决策核心"，建议整张做成横向卡片，背景色按场景类别分色，方便读者截图保存。

三条需要记住的元判断

表格之外，再给你三条我自己的元判断，这些比具体方案更值得带走：

第一，「专门向量库」正在从默认选项退化为场景选项。 它不再是 RAG 的必选组件，而是一种在"高并发纯检索"和"超大规模索引"等具体场景下才成立的选择。中小规模、知识库场景，单表 RAG 或 pgvector 完全够用。

第二，RAG 的真正瓶颈在 chunking 和 prompt，不在向量库选型。 Rocky 团队那句"分块工程量是向量检索的 10 倍"应该贴在每个 RAG 工程师的显示器上。在你优化向量库之前，先确认你的 chunking 和 prompt 已经做到了 80 分——否则你是在给一辆没有发动机的车换轮胎。

第三，2026 年的 embedding 工程正在从 ML 问题变成 HPC 问题。 TensorRT、无锁多 GPU、分桶批处理——这些词的频次上升，说明大规模 embedding 已经进入高性能计算范畴。如果你的工作涉及亿级数据处理，掌握这套技术栈的回报会越来越高。

最后一句

选型的本质，从来不是"哪个工具更好"，而是"哪个工具的成本结构，匹配你的真实场景"。专门向量库没有错，错的是把它当默认答案。

如果你正在做 RAG 选型，或者已经在生产里跑着一套想重新审视——评论区告诉我你的场景（知识库规模、QPS、是否多租户、是否有合规约束），我会给出更具体的判断。这种问题没有标准答案，但有一个属于你场景的最优解。