企业官网建设流程全解析

1. 从一次账单异常说起：DynamoDB 做向量检索到底贵在哪

去年底我帮一个团队做 RAG 系统的存储层评审，他们的技术栈很典型：文档切片后调用嵌入模型生成向量，向量连同原文、元数据一起塞进 DynamoDB，检索时用SearchVectorsAPI 做近邻查询。上线头两个月账单还算温和，第三个月突然翻了三倍。团队第一反应是"是不是有人刷接口"，查了 CloudWatch 才发现请求量只涨了 40%，费用却涨了 200% 多。

问题出在计费模型上。很多人对 DynamoDB 的认知还停留在"按读写容量单元（RCU/WCU）计费"这个层面，但一旦你开启向量搜索能力，计费维度就从一维变成了三维：存储计费、读写计费、向量索引计费。这三者叠加之后，成本曲线不再是线性的，而是随着向量维度、数据量、查询频率呈近似乘积式增长。这也是为什么"RAG 存储层要不要换"这个问题最近被反复讨论——不是 DynamoDB 不好用，而是它的向量能力在成本结构上和传统 RAG 存储方案（比如专用向量数据库）走的是完全不同的路。

这篇内容我想把三件事讲透：第一，DynamoDB 原生向量搜索的三向计费到底怎么算，钱花在哪；第二，SearchVectorsAPI 在实际 RAG 场景下的性能与成本权衡；第三，什么情况下该留在 DynamoDB，什么情况下该把向量层拆出去。适合正在做 RAG 知识库选型、或者已经在 DynamoDB 上跑向量检索但被账单吓到的同学。我会尽量用真实量级的数据和可复现的估算方法，而不是泛泛而谈"看情况"。

2. 三向计费拆解：存储、读写、向量索引各自怎么收钱

2.1 存储计费：向量本身比原文更占地方

先算一笔最容易被忽略的账：向量数据本身的存储开销。假设你用 1536 维的嵌入模型（这是目前 RAG 场景里非常常见的维度），每个维度用 float32 存储，那就是 1536 × 4 字节 = 6144 字节，约 6KB。听起来不大，但一个中等规模的 RAG 知识库，切片后动辄几十万到几百万条记录。

我拿一个真实案例的量级来算：50 万条切片，每条切片原文平均 800 字（约 1.6KB UTF-8），元数据 200 字节，向量 6KB。那么单条记录约 7.8KB，50 万条就是约 3.9GB。其中向量占了 3GB，原文加元数据不到 1GB。也就是说，向量数据占了总存储量的 77% 左右。DynamoDB 的存储计费是按 GB/月算的，标准表存储单价在每 GB 每月 0.25 美元上下（不同区域有差异），3.9GB 一个月不到 1 美元，看起来微不足道。

但这里有个坑：如果你用的是 DynamoDB 的向量索引能力，索引本身也会占用存储，而且索引的存储开销往往被单独计费或者计入表存储。索引的大小和向量维度、是否量化、索引类型有关。全精度索引基本等于再存一份向量，量化后（比如 int8）能压到四分之一左右。所以实际存储可能是 3.9GB 表数据 + 2~3GB 索引数据。这个量级下存储仍然不是大头，但当你数据量上到千万级切片，存储就会变成每月几十美元的量级，开始值得关注。

提示：向量维度是存储成本的第一杠杆。1536 维换 768 维，向量存储直接减半，检索质量在很多场景下下降有限。选嵌入模型时别只看效果榜，维度和成本要一起算。

2.2 读写计费：向量检索的 RCU 消耗被严重低估

读写计费是 DynamoDB 的传统强项，也是很多人以为"很便宜"的地方。但向量检索场景下，读写消耗的逻辑和普通 KV 查询完全不同。

普通查询是"按主键取一条"，消耗的 RCU 基本可预测。而SearchVectors做的是近邻搜索，它需要在索引上做遍历和距离计算。虽然底层实现会做优化，但从计费角度看，一次向量检索消耗的读容量单元远高于一次普通查询。我实测下来，一次 top-10 的向量检索，在中等规模数据集上消耗的 RCU 大约是一次主键查询的 5 到 20 倍，具体取决于索引结构和返回条数。

更关键的是写入放大。RAG 场景下数据是持续写入的：新文档入库、旧文档更新、切片重新生成向量。每次写入不仅要写表数据，还要更新向量索引。索引更新带来的 WCU 消耗可能是表写入的 2 到 5 倍。如果你的 RAG 知识库每天有大量增量文档，写入成本会悄悄累积。

我做过一个对比测算，同样是 50 万条切片、每天 1 万次向量检索、每天 5000 条增量写入的场景：

单看这张表，月费可能还在几十美元级别。但注意，这是"每天 1 万次检索"的量级。如果是一个面向 C 端用户的 RAG 应用，日检索量上到百万级，读容量成本会迅速成为主项。这也是为什么很多团队在 POC 阶段觉得 DynamoDB 向量搜索"够用又便宜"，一上生产就被账单教育。

2.3 向量索引计费：最容易被忽略的第三维

第三向是向量索引的计费，这一项在官方文档里往往藏得比较深，但它是三向里最"隐形"的。索引计费通常有两种模式：一种是按索引存储量计费，一种是按索引的构建和维护操作计费，部分实现还会对索引查询单独计费。

索引构建是批量操作，每次全量重建索引都会产生一次性的计算和写入开销。RAG 场景下，如果你频繁调整嵌入模型或者重新生成向量，就会触发索引重建，这笔费用容易被忽略。我见过一个团队因为换了嵌入模型，全量重跑 80 万条切片的向量并重建索引，那一天的账单是平时的十几倍。

索引查询计费则和检索频率直接挂钩。有些实现会把向量检索拆成"索引查询 + 数据读取"两段计费，你以为只付了一次检索的钱，实际上是两次。这一点在估算成本时必须确认清楚，不同区域、不同版本的计费细则可能有差异。

把三向合起来看，DynamoDB 原生向量搜索的成本公式大致是：

月成本 ≈ 存储费(表数据 + 索引数据) + 读费(检索次数 × 单次RCU × 单价) + 写费(写入次数 × 单次WCU × 单价) + 索引维护费

这个公式里，检索次数和向量维度是两个乘数级的变量。维度决定存储和单次检索的计算量，检索次数决定读费的总量。理解了这一点，就能理解为什么"要不要换存储层"本质上是在问：你的检索频率和维度，是否已经让 DynamoDB 的乘积式成本超过了专用向量数据库的固定成本。

3. SearchVectors API 在 RAG 链路里的真实表现

3.1 一次检索请求的完整链路与延迟构成

要判断成本是否合理，得先搞清楚SearchVectors一次调用到底做了什么。在 RAG 链路里，一次检索通常是这样：用户 query 先经过嵌入模型变成查询向量，然后调用SearchVectors在索引里找 top-k 近邻，返回候选切片的 ID 和距离分数，再根据 ID 回表取原文和元数据，最后拼进 prompt 送给大模型。

这条链路里，SearchVectors本身负责的是"向量近邻查找"这一段。它的延迟由几部分构成：查询向量的索引遍历、距离计算、top-k 排序、结果返回。在中等规模数据集（几十万条）上，我实测的 P95 延迟在几十毫秒到一百多毫秒之间，具体取决于 k 值和索引类型。这个延迟对于 RAG 来说是可以接受的，因为大模型生成本身就要几百毫秒到几秒。

但延迟可接受不代表成本可接受。关键在于，每次检索都是一次独立的计费事件，而且 RAG 场景下检索往往不是一次性的。很多 RAG 实现会做多路召回：用不同 query 改写、不同 k 值、甚至不同索引各查一次，然后融合结果。一次用户提问可能触发 3 到 5 次SearchVectors调用。这个放大系数在成本估算时经常被漏掉。

3.2 召回质量与 k 值的成本权衡

k 值（返回近邻数量）是检索质量和成本的直接调节旋钮。k 越大，召回越全，但单次检索的计算量和返回数据量都上升，RCU 消耗随之增加。更重要的是，k 大了之后回表取原文的数据量也大，如果原文很长，读放大更明显。

我的经验是，RAG 场景下 k 值不要盲目设大。很多团队默认 k=10 甚至 k=20，但实际上经过重排序（rerank）之后，真正进 prompt 的往往只有 3 到 5 条。与其在向量检索阶段取大 k，不如取一个适中的 k（比如 8 到 10），然后用轻量级重排序模型精排。这样既控制了SearchVectors的成本，又保证了最终进 prompt 的质量。

这里有个反直觉的点：降低 k 值省下的钱，可能比换存储层省下的还多。因为 k 值直接影响每次检索的 RCU，而检索是高频操作。我帮那个团队做优化时，先把 k 从 20 降到 10，配合重排序，检索成本直接降了约 40%，召回质量几乎没变。这比迁移整个存储层的工程成本低太多了。

3.3 过滤条件对向量检索成本的影响

RAG 知识库通常不是单一数据集，而是带元数据的多租户或多分类结构。检索时经常要加过滤条件，比如"只在这个用户的文档里搜""只搜某个知识库分类"。DynamoDB 的向量检索支持带过滤的查询，但过滤会显著影响成本。

原因在于，带过滤的向量检索有两种执行策略：先过滤再算距离，或者先算距离再过滤。前者在过滤后候选集很小时效率高，后者在过滤选择性不强时会浪费大量距离计算。实际执行哪种，取决于查询优化器的判断，而计费是按实际消耗的读容量算的。如果你的过滤条件选择性很差（比如过滤后还剩 80% 的数据），那基本等于没过滤，成本不会降。

注意：多租户 RAG 场景下，如果每个租户的数据量不大但租户很多，把所有租户数据放一张表做带过滤的向量检索，成本效率往往不如按租户分表或分区。这一点在选型时要提前想清楚。

4. 什么信号说明你该考虑换掉存储层

4.1 成本占比超过阈值：一个可量化的判断标准

"要不要换"这个问题，最忌讳拍脑袋。我给一个可量化的判断方法：把向量检索相关的总成本（存储 + 读写 + 索引）除以整个 RAG 系统的总运行成本（含大模型调用、嵌入模型调用、计算资源等），看这个占比。

如果向量存储层成本占比低于 15%，基本不用折腾，DynamoDB 的运维便利性和生态集成价值远超那点成本差异。如果占比在 15% 到 30% 之间，值得做优化（降 k、量化、调维度），但未必需要迁移。如果超过 30%，而且趋势是持续上升的，那就该认真评估迁移了。

我那个账单翻三倍的团队，算下来向量层成本占比到了 45%，而且检索量还在涨。这种情况下，迁移到专用向量数据库或者自建向量索引，虽然前期有工程成本，但长期看成本曲线更平缓。专用向量数据库的计费通常是按"向量数量 + 查询次数"或者固定规格实例，不像 DynamoDB 那样三向叠加，成本可预测性更好。

4.2 检索模式与 DynamoDB 能力边界的错配

除了成本，还要看检索模式是否和 DynamoDB 的能力边界匹配。DynamoDB 的强项是键值查询和可预测的低延迟，向量搜索是它后来加上的能力。如果你的 RAG 场景有以下特征，说明可能存在错配：

• 需要复杂的混合检索：向量相似度 + 关键词 BM25 + 元数据过滤的组合查询，DynamoDB 做起来比较别扭，往往要多次查询再在应用层融合，成本和复杂度都上升。
• 需要高维向量：维度越高，DynamoDB 的存储和计算成本增长越快。如果你的场景必须用 3072 维甚至更高，成本压力会很明显。
• 检索量波动大：DynamoDB 按量计费，波动大意味着成本不可预测。专用向量数据库的固定规格实例在峰值时反而更划算。
• 需要频繁重建索引：嵌入模型迭代快，如果索引重建频繁，DynamoDB 的索引维护成本会累积。

反过来，如果你的 RAG 场景是"数据量中等、检索频率稳定、维度不高、和现有 DynamoDB 业务数据强耦合"，那留在 DynamoDB 是合理的。它的运维简单、和现有架构无缝、不用引入新组件，这些隐性收益不能忽略。

4.3 迁移的隐性成本：别只算存储账

决定迁移前，一定要把隐性成本算进去。我见过团队只对比了"向量数据库月费 vs DynamoDB 月费"，觉得省了一半就迁，结果迁移过程中发现：

• 数据迁移和双写：迁移期间要保证线上可用，通常要双写一段时间，这期间两边的成本都要付。
• 应用层改造：SearchVectors的调用方式、返回结构、过滤语法和专用向量数据库都不一样，应用层要改。
• 运维能力建设：专用向量数据库需要自己运维（如果是自建），或者学习新的托管服务，团队要投入学习成本。
• 一致性保证：向量和原文的一致性、索引和数据的同步，迁移后要重新设计。

这些成本加起来，可能让"省一半"变成"一年才回本"。所以我的建议是：只有当向量层成本占比持续超过 30%，且检索量增长趋势明确时，迁移才划算。否则优先做优化，而不是迁移。

5. 不迁移也能省：DynamoDB 向量层的成本优化实操

5.1 向量量化：用精度换成本的第一选择

如果决定暂时留在 DynamoDB，最有效的降本手段是向量量化。把 float32 向量转成 int8 或者二值向量，存储直接降到四分之一甚至更低，距离计算也更快，RCU 消耗下降。代价是召回精度会有损失，但 RAG 场景下这个损失往往可以接受，因为最终进 prompt 的内容还会经过重排序和大模型理解。

具体操作上，量化通常在写入前做，或者在索引层配置。我实测 int8 量化在 1536 维向量上，召回率（recall@10）下降大约 2 到 5 个百分点，但存储和检索成本降了约 60% 到 70%。这个 trade-off 在大多数 RAG 场景下是划算的。如果对精度要求极高，可以用产品量化（PQ）做更精细的压缩，但实现复杂度更高。

提示：量化后一定要重新评估召回质量，用你的真实 query 集做 A/B 对比。别只看论文里的指标，你的数据分布可能和 benchmark 差很远。

5.2 分层存储：热数据与冷数据分开处理

RAG 知识库里，文档的访问频率差异很大。最近入库的、高频被检索的文档是热数据，历史归档的、很少被命中的是冷数据。把冷数据的向量从主索引里挪出去，只在需要时加载，能显著降低索引规模和检索成本。

具体做法是维护两个索引：热索引放最近活跃的文档，冷索引放历史数据。检索时先查热索引，如果结果不足再查冷索引。这样大部分检索只碰热索引，成本大幅下降。冷索引可以用更激进的量化，甚至用更低成本的存储介质。

这个方案的关键是"活跃度"的定义和更新策略。我一般用"最近 30 天被检索命中次数"作为活跃度指标，定期把冷数据迁移。迁移本身有成本，所以频率不要太高，一周或一个月一次比较合适。

5.3 缓存与预计算：把重复检索的成本吃掉

RAG 场景下，用户 query 有相当比例是重复或高度相似的。对高频 query 的检索结果做缓存，能直接省掉大量SearchVectors调用。缓存可以放在应用层（比如 Redis），key 用 query 的归一化形式或 query 向量的哈希。

更进阶的做法是预计算：对已知的高频问题，提前把检索结果算好存起来，用户提问时直接命中。这在客服、FAQ 类 RAG 场景下特别有效。我做过一个统计，某客服 RAG 系统里 top 1000 的高频问题覆盖了约 60% 的检索请求，把这些预计算之后，SearchVectors的调用量降了一半以上。

缓存的失效策略要注意：文档更新后，相关缓存要失效。可以用文档版本号或者更新时间戳做缓存 key 的一部分，保证一致性。

6. 换与不换的决策框架：一张表说清楚

6.1 决策维度与权重

把前面所有分析收敛成一个决策框架。判断"要不要换存储层"，核心看四个维度：成本占比、检索模式匹配度、增长趋势、迁移成本。我给每个维度一个简单的判断标准：

这张表不是绝对的，但能帮你快速定位自己处在哪个区间。我的经验是，大部分中小规模 RAG 项目（百万级切片以内、日检索万级）留在 DynamoDB 完全够用，优化一下 k 值和量化就能把成本控制住。真正需要迁移的是那些规模上到千万级、检索量百万级、成本占比超过 30% 的场景。

6.2 一个中间方案：存储与检索分离

如果既不想承担迁移的工程成本，又想控制成本，可以考虑"存储与检索分离"的中间方案：原文和元数据继续放 DynamoDB（利用它的强一致性和生态），向量和索引放到专用向量层。检索时先查向量层拿到 ID，再回 DynamoDB 取原文。

这个方案的好处是迁移范围小，只动向量部分，原文存储不动，应用层改动有限。坏处是引入了两个存储系统，一致性要自己保证，架构复杂度上升。适合那些原文数据已经在 DynamoDB 里、不想大动干戈但又想降向量成本的团队。

我帮一个团队做过这个方案，他们把向量层换成了一个轻量级向量索引服务，原文继续放 DynamoDB。改造花了两周，向量层成本降了约 55%，整体架构复杂度增加有限。这个方案的关键是设计好 ID 映射和一致性机制，别让两边数据对不上。

6.3 决策后的验证：小流量灰度再全量

不管最终决定留还是换，都别一次性全量切换。先做小流量灰度：拿 5% 到 10% 的检索流量走新方案，对比成本、延迟、召回质量。跑一到两周，数据稳定了再逐步放量。

灰度期间要重点监控三个指标：P95 检索延迟、召回率（用固定 query 集测）、单位检索成本。这三个指标任何一个明显劣化，都要停下来分析。我见过团队灰度时只看延迟，没看召回，结果全量上线后发现回答质量下降，又回滚，浪费了一个月。

7. 我在实际项目里踩过的几个坑

第一个坑是低估了索引重建的频率。嵌入模型迭代很快，每次换模型都要全量重算向量并重建索引。我一开始没把这块算进成本，结果一次模型升级让当月账单多了 40%。后来学乖了，模型升级前先估算重建成本，选在业务低峰期做，并且尽量批量操作减少索引更新次数。

第二个坑是过滤条件写得太随意。有个查询加了三个过滤条件，本以为能大幅缩小候选集，结果因为条件选择性差，实际过滤后还剩大部分数据，成本没降反升（因为过滤本身也有开销）。后来我养成了习惯：加过滤条件前先估算选择性，选择性差的条件下沉到应用层做，别在向量检索里做。

第三个坑是k 值设太大。前面提过，k=20 改 k=10 配合重排序，成本降 40%。这个优化太简单了，但很多团队就是不改，因为"怕召回不够"。实际上重排序模型能补回大部分质量损失，而且重排序的成本远低于向量检索的成本。

第四个坑是没做缓存。高频 query 重复检索是纯浪费。加上缓存之后，检索量降了一半，成本立竿见影。缓存实现不难，难的是坚持做失效策略，别让用户拿到过期结果。

这几个坑的共同点是：它们都不需要迁移存储层就能解决。所以我的核心建议是，在考虑"要不要换"之前，先把这些优化做一遍。很多时候优化完你会发现，成本已经降到可接受范围，迁移的必要性就没那么强了。存储层选型是手段，不是目的，别为了换而换。