企业官网建设流程全解析

1. 从一条计费账单说起：为什么我开始重新审视 RAG 的存储层

去年年底我接手了一个内部知识库项目，规模不算大，日活几百人，文档量在百万级 chunk 左右。最初选型的时候，团队几乎没怎么犹豫就定了 DynamoDB 作为向量和元数据的统一存储层——理由很朴素：我们整个后端本来就跑在 AWS 上，DynamoDB 又是那种"你几乎不用管它"的服务，加上后来官方支持了原生向量索引，看起来像是把 RAG 的存储问题一次性解决了。

结果第一个完整月的账单出来，我盯着 Cost Explorer 看了很久。倒不是说贵到离谱，而是贵得没有道理——我完全说不清楚钱花在哪了。EC2 我能算清楚，S3 我能算清楚，但 DynamoDB 那一栏，数字和我脑子里的模型对不上。后来花了两三天把计费维度彻底拆开，才发现问题出在一个很多人（包括当时的我）都会忽略的点上：DynamoDB 的向量搜索不是"一个功能"，而是三套计费逻辑叠在一起，而 RAG 这种"读多写少、但每次读都要扫一大片向量"的负载，恰好把这三套逻辑里最贵的那部分踩满了。

这篇东西就是那次拆账的完整复盘。我会把 DynamoDB 原生向量搜索的成本结构拆到能算账的程度，然后回答一个更实际的问题：RAG 的存储层到底要不要换，什么情况下该换，换成什么。如果你正在做 RAG 项目、正在纠结存储选型、或者已经被某个月的账单吓到过，这篇应该能帮你少走点弯路。我不会给你一个"标准答案"，因为存储选型从来就没有标准答案，但我会给你一套能自己算账的方法。

2. DynamoDB 原生向量搜索的成本结构拆解

2.1 三向计费到底是什么：读、写、存储各管什么

先把概念理清楚。很多人以为 DynamoDB 加了向量搜索之后，计费还是"读写容量 + 存储"那套老逻辑，其实不是。当你启用向量索引并执行相似度查询时，实际发生的是三件独立计费的事：

第一向是向量数据的存储成本。向量本身要占空间，这跟普通属性没区别，按 GB 计费。但关键在于，向量索引是额外的存储——你存了一份原始向量，索引结构又占一份。一个 1536 维的 float32 向量是 6KB 左右，百万级 chunk 就是 6GB 起步，加上索引开销，实际占用往往是你预估的 1.5 到 2 倍。

第二向是写入成本，也就是 WCU。每次你往表里写一条带向量的记录，DynamoDB 不仅要写数据，还要同步更新向量索引。这个索引更新不是免费的，它消耗的 WCU 远高于写一条普通记录。我实测下来，写一条 1536 维向量的记录，消耗的 WCU 大约是写同大小普通记录的 3 到 5 倍，具体取决于索引的维度和分区情况。

第三向是查询成本，也就是 RCU，这是最容易被低估的一块。向量相似度搜索本质上是近似最近邻（ANN），它需要在索引里做一次范围扫描。这个扫描消耗的 RCU 不是按"返回几条结果"算的，而是按扫描过的索引节点数算的。也就是说，你查 top-10，可能实际扫描了几千个候选向量，RCU 消耗是普通 Query 的几十倍甚至上百倍。

提示：很多人第一次看到向量查询账单爆炸，就是因为脑子里还是"查 10 条 = 10 条 RCU"的模型。向量搜索的 RCU 跟返回条数几乎没关系，跟索引规模和查询参数强相关。

2.2 为什么 RAG 负载会把三向计费踩满

RAG 的访问模式有个很鲜明的特征：写入是批量的、低频的，读取是高频的、每次都要全库相似度搜索的。

具体来说，一个典型的 RAG 检索请求是这样的：用户问一个问题，系统把问题向量化，然后拿这个向量去库里找最相似的 top-K 个 chunk。这个动作每次都要扫一遍索引，而且因为用户问题千变万化，缓存命中率很低。这就导致 RCU 消耗是持续且巨大的。

更麻烦的是写入侧。RAG 的知识库不是一次建好就不动的，文档会更新、会新增、会重新切分。每次重新切分，意味着旧向量要删、新向量要写，而删除向量同样要更新索引，同样消耗 WCU。我那个项目因为文档更新策略没设计好，一度出现了"每天重跑一次全量索引"的情况，那段时间的 WCU 账单直接翻了三倍。

存储侧反而是最"温和"的，因为向量数据本身不会频繁变动，存储成本相对可预测。但它的绝对值不小，尤其是当你用了高维向量模型（比如 3072 维）的时候，存储成本会线性上涨。

2.3 一个真实的成本估算：百万 chunk 级别到底花多少

我拿自己项目的真实数据做个估算，方便你对照。假设条件是：100 万条 chunk，每条向量 1536 维 float32，每天 5 万次检索请求，每次 top-10，文档每周更新 5%。

注意最后一行。查询 RCU 是绝对的大头，通常能占到总成本的 60% 到 75%。这个比例会随着检索频率和索引规模的变化而剧烈波动。如果你的检索 QPS 再高一点，或者 top-K 设得大一点，查询成本会指数级上升。

我当时的实际账单里，查询部分占了将近七成。这也是为什么我后来越来越倾向于把"向量检索"和"元数据存储"拆开——因为这两件事的成本曲线完全不同，绑在一起算账，你永远看不清钱花在哪。

3. RAG 存储层到底要不要换：决策框架

3.1 先别急着换：什么情况下 DynamoDB 原生向量搜索是划算的

我得先说句公道话，DynamoDB 原生向量搜索不是"坑"，它在某些场景下非常合理，甚至是最优解。

第一种情况是规模不大、检索频率不高。如果你的知识库只有几万条 chunk，日检索量在几千次以内，那三向计费加起来也花不了多少钱。这时候你换来换去，省下的钱还不够你折腾的工时费。运维简单本身就是价值，DynamoDB 那种"不用管"的体验，在小规模下是实打实的优势。

第二种情况是你已经深度绑定 AWS 生态。如果你的元数据、权限、业务逻辑全在 DynamoDB 里，向量只是其中一个属性，那把它拆出去反而会增加架构复杂度。跨服务查询、数据一致性、事务边界，这些都是隐性成本。

第三种情况是写入远大于读取。比如你做的是离线批处理的语义去重、聚类分析，检索频率很低，那查询 RCU 就不是问题，DynamoDB 的写入性能和托管体验就很香。

判断标准其实很简单：算一下你的"检索次数 / 向量条数"这个比值。如果这个比值很低（比如每天检索次数不到向量条数的百分之一），DynamoDB 原生方案大概率是划算的。如果这个比值很高，你就该认真考虑换存储层了。

3.2 什么信号出现时，你该认真考虑换存储层

我总结了几个"该换"的信号，都是我自己踩过或者见别人踩过的：

信号一：查询成本占比超过总成本的 60%，且还在涨。这说明你的负载是检索密集型的，DynamoDB 的 RCU 模型对你不友好。专用向量数据库（比如基于 HNSW 或 IVF 索引的方案）在检索密集场景下的单位查询成本通常低一个数量级。

信号二：你需要复杂的元数据过滤 + 向量搜索的组合查询。DynamoDB 的向量搜索对"先过滤再搜索"的支持比较有限，很多时候你得先搜再过滤，导致扫描量浪费。专用向量库在这方面更灵活。

信号三：你的向量维度很高（比如 3072 维），或者用了多种向量模型。高维向量的存储和索引成本在 DynamoDB 里是线性上涨的，而一些专用方案对高维有更好的压缩和索引优化。

信号四：你需要跨区域、跨云的可移植性。DynamoDB 是 AWS 专属的，一旦绑定，迁移成本很高。如果你有混合云或者多云的需求，早点解耦存储层是明智的。

信号五：你的团队已经在用其他向量检索方案。如果团队里已经有人熟悉 pgvector、Milvus、Qdrant 这类方案，那统一技术栈带来的协作效率提升，往往比省下的那点钱更值钱。

3.3 换与不换的中间路线：混合架构

其实大多数情况下，答案不是"全换"或"全不换"，而是混合。我后来采用的方案就是混合架构，效果不错：

元数据和业务数据留在 DynamoDB，因为它的强一致性、事务支持、托管体验确实好，这些是向量库给不了的。向量和向量索引拆到专用存储，让检索走专用通道。两边通过 chunk ID 关联，检索时先拿 ID，再回 DynamoDB 取元数据。

这个架构的好处是：检索成本大幅下降（专用向量库的查询成本低），同时保留了 DynamoDB 在事务和一致性上的优势。代价是架构复杂度上升，需要处理两边的一致性——但这个代价是可控的，因为向量和元数据之间是"最终一致"就够用的关系，不需要强一致。

注意：混合架构最大的坑是删除和更新的一致性。文档删除时，如果只删了 DynamoDB 没删向量库，就会出现"检索得到但取不到元数据"的幽灵结果。一定要设计好删除的补偿机制，或者用软删除 + 定期清理。

4. 实操：如何自己算清楚这笔账

4.1 用 CloudWatch 和 Cost Explorer 拆出三向成本

光看总账单是没用的，你得把三向拆开。我的做法是：

第一步，在 Cost Explorer 里按 usage type 分组。DynamoDB 的成本会细分到TimedStorage、WriteRequestUnits、ReadRequestUnits这些维度。把向量表的这些维度单独拉出来，你就能看到三向各自的占比。

第二步，用 CloudWatch 看实际的 RCU/WCU 消耗曲线。重点看ConsumedReadCapacityUnits和ConsumedWriteCapacityUnits这两个指标，按表维度看。如果向量表的 RCU 曲线和你的检索 QPS 曲线高度吻合，那就确认了查询是大头。

第三步，做一次对照实验。挑一个低峰时段，把检索请求停掉一小时，看 RCU 掉多少。这个差值就是纯检索成本。我做过这个实验，结果很直观：停掉检索后，RCU 直接掉了 80%。

4.2 关键参数怎么调：维度、top-K、索引类型

如果你决定暂时留在 DynamoDB，那有几个参数是必须调的，调好了能省不少钱：

向量维度能降就降。1536 维和 768 维的成本差接近一倍。很多场景下，768 维的模型效果已经够用，没必要上最高维度。我后来把一部分非关键场景的向量从 1536 降到了 768，检索质量下降在可接受范围内，成本直接砍半。

top-K 不要设太大。很多人习惯性设 top-20 甚至 top-50，然后让 rerank 去筛。但 top-K 每增加一倍，扫描量可能增加好几倍。我的经验是 top-10 起步，配合一个好的 rerank 模型，效果不比 top-50 差。

索引类型要选对。DynamoDB 的向量索引有不同的配置选项，针对你的查询模式选合适的类型。如果你的查询总是带分区键过滤，那用分区内的索引会比全局索引便宜很多。

4.3 迁移到专用向量库的实操路径

如果你决定迁移，我建议分三步走，别一次性全切：

第一步，双写。新数据同时写入 DynamoDB 和专用向量库，老数据做一次批量迁移。这个阶段两边都有数据，可以随时回滚。

第二步，灰度切读。把一部分检索流量切到新向量库，对比结果质量和延迟。这个阶段重点看召回率有没有下降，以及新方案的查询成本是否符合预期。

第三步，全量切换 + 清理。确认新方案稳定后，把读流量全切过去，然后逐步清理 DynamoDB 里的向量数据，只保留元数据。

整个迁移过程我用了大概三周，其中双写阶段占了两周。慢是慢了点，但没出过一次线上事故。迁移这种事，快就是慢，慢就是快。

5. 常见问题与排查技巧实录

5.1 账单突然翻倍，怎么快速定位

这是我最常被问到的问题。我的排查顺序是：

先看是不是写入侧的问题。检查最近有没有做全量重建索引、有没有批量导入、有没有文档更新策略变更。写入侧的波动通常和你的操作直接相关，最容易定位。

再看查询侧。如果写入没变但账单涨了，那大概率是查询。看检索 QPS 有没有涨、top-K 有没有被调大、有没有新增的检索入口。我遇到过一次账单翻倍，最后发现是新上了一个"相关推荐"功能，每次页面加载都触发一次向量检索，QPS 直接翻了好几倍。

最后看存储侧。存储侧一般不会突然翻倍，除非你做了维度升级或者数据量激增。如果存储侧异常，检查一下是不是有重复写入导致的索引膨胀。

5.2 检索延迟高但成本也高，两头不讨好怎么办

这种情况通常是索引配置和查询模式不匹配。比如你用了一个为高召回率优化的索引，但你的查询其实只需要高精度，那就会既慢又贵。

解决办法是针对查询模式重新设计索引。如果你的查询总是带某个维度的过滤条件，那就把这个维度作为分区键，用分区内索引。这样扫描范围会小很多，延迟和成本都会降。

还有一个常见原因是向量维度太高导致索引效率下降。高维向量的 ANN 索引本身就更难构建，查询时扫描的节点也更多。如果延迟和成本同时高，考虑降维或者换用更适合高维的索引算法。

5.3 混合架构下的一致性怎么保证

这是混合架构最容易被忽视的问题。我的做法是：

用软删除代替硬删除。删除文档时，先在 DynamoDB 里标记为 deleted，然后异步清理向量库。检索时如果拿到已删除的 ID，直接跳过。这样即使清理延迟，也不会出现幽灵结果。

用版本号做幂等。每次更新文档时，给 chunk 打一个版本号。向量库和 DynamoDB 都存版本号，检索时对比版本，不一致就以 DynamoDB 为准。这样能避免更新过程中的中间状态被检索到。

定期做一致性校验。我写了个定时任务，每周跑一次全量对比，找出两边不一致的记录并修复。这个任务本身不贵，但能避免小问题积累成大问题。

提示：混合架构下，永远假设两边会不一致，然后设计好兜底逻辑。不要假设"我写了两边就一定一致"，网络抖动、服务重启、超时重试，任何一个环节都可能让两边不同步。

5.4 常见问题速查表

6. 我个人的选型建议与踩坑体会

折腾完这一圈，我对 RAG 存储层的看法变了很多。最开始我以为这是个"选哪个数据库"的问题，后来发现它其实是个成本结构匹配的问题。DynamoDB 原生向量搜索不是不好，它的托管体验和生态整合确实一流，但它的计费模型天然偏向"写入多、读取少"的负载，而 RAG 恰恰相反。

我现在给别人的建议通常是这样的：如果你的 RAG 项目还在早期，检索量不大，那就先用 DynamoDB 原生方案，别过度设计。等你的检索量涨到查询成本占比超过 60% 的时候，再考虑拆存储层。这个时机点很重要，太早拆是浪费，太晚拆是烧钱。

拆的时候，优先考虑混合架构而不是全量迁移。元数据留在 DynamoDB，向量拆出去，这个组合在大多数场景下都是性价比最高的。迁移过程一定要双写 + 灰度，别图快。

最后分享一个我踩过的坑：别在没算清楚账之前就动手优化。我一开始凭直觉觉得"肯定是存储贵"，结果花了两周做向量压缩，最后发现存储只占总成本的 15%，真正的大头是查询。那两周基本白干。先拆账，再优化，这个顺序不能反。

还有个细节，向量维度这件事真的值得反复权衡。我见过太多团队无脑上最高维度的模型，觉得"维度越高效果越好"。实际上在很多垂直领域，768 维和 1536 维的检索质量差异很小，但成本差一倍。先做个小规模 A/B 测试，用数据说话，别用直觉。