企业官网建设流程全解析

做企业知识库 AI 选型的时候，我身边很多团队最先纠结的其实是模型：用哪个大模型、怎么调 prompt、RAG 效果好不好。真正把架子搭起来之后才发现，最扎心的问題反而不是模型，而是"业务数据在 DynamoDB 里，向量却得送到另一个专门的向量数据库里，两套数据之间还得靠管道同步"。DynamoDB 原生向量搜索出现之后，这个决策点发生了实质变化。它把向量索引、语义检索直接并进了主数据库，等于告诉你说：小规模知识库，你可以先不引入独立向量库了。

这篇文章我从架构、数据一致性、成本规模三个维度拆一下 DynamoDB 原生向量搜索对企业知识库 AI 选型的具体影响，最后附一份落地前必须盯紧的排查清单。适合正在做 RAG 知识库选型、或者已经在用 DynamoDB 存业务数据、但对是否要额外上向量数据库犹豫不决的架构师和后端负责人。

1. 架构收敛：从"业务库 + 向量库 + 同步管道"到"一张表"

1.1 过去知识库 AI 的底层链路有多重

传统做法里，一个知识库 AI 系统通常要拆成三套存储：业务记录在 DynamoDB，原始文档落在对象存储里，文档切片和 embedding 向量则要单独进一个向量数据库。为了让这三套数据保持相对同步，还得再搭一条管道——通常是 CDC 监听业务表变动，或者用 Lambda 双写，把新数据同步到向量库。

这套链路本身是能跑的，但问题在于它是"为每个组件分别负责一件事"而设计的，不是为知识库场景整体设计的。只要有一个组件出问题，整个检索链路就会跟着抖。比如我见过不止一个团队，自建向量库用的还是大规格实例，只存了十几万条切片，机器的内存却预留了几十 GB，就为了防查询毛刺。结果就是：知识库还没多大，基础设施倒是先胖起来了。

另一个隐藏成本是技能栈。团队里得有人会维护 DynamoDB，还得有人会调向量库的索引参数、观察它的分段和缓存。在很多公司里，这两个角色往往重叠在同一个人身上，于是这个人不仅要处理业务读写，还要半夜爬起来看向量库的磁盘告警。这种架构不是不能做，但对中小团队来说负担偏重。

1.2 原生向量搜索之后，链路变成了什么样

DynamoDB 原生向量搜索的功能逻辑其实很直接：在已有的表里增加一种向量类型字段，写入数据时把 embedding 结果一并存进去，查询时就按向量距离做 KNN 检索，返回最近邻记录。底层索引的构建、近邻搜索、距离计算都由数据库托管，对应用层不可见。距离函数支持余弦相似度和欧几里得距离，基本覆盖了文本语义检索和部分图像特征检索的常见需求。

这样一来，原来的三套存储可以收敛成一套：业务字段、文档内容、向量字段都躺在同一条记录里。查询的时候，一条请求就能拿到"相似的文档列表 + 对应的业务元数据"，不需要先查向量库拿到 ID 列表，再回业务库补全详情。这个合并带来的直接收益是我在多个项目里都能感知到的——连接少了，超时点少了，代码里需要处理的异常分支也少了。

链路变成什么样了？写入端大概是这样：文档进来，普通字段直接写入；同时用一个 embedding 模型给文档内容生成向量，作为同一个表里的另一个属性写入。查询端则是：把用户问题转成查询向量，发给 DynamoDB，让它做近邻检索，返回 top-K 记录。至于索引结构、压缩策略、距离计算细节，业务代码不用管。

1.3 架构收敛带来的连锁反应

架构收敛不光是少一套组件的问题，它会引发一连串正向连锁反应。

基础设施层面，少了一个独立向量库集群，就等于少了磁盘规划、少了副本配置、少了版本升级窗口、少了监控告警体系。按我的经验，很多团队引入向量库之后，真正麻烦的不是检索本身，而是"我还要不要给它单独配一套高可用？备份怎么做？扩容是横向还是纵向？"。

运维层面，告警项会明显变少。原来向量库的 CPU 使用率、内存水位、段合并延迟都是需要盯的指标；现在这些工作被数据库托管了，团队只需要关注 DynamoDB 现有的容量和节流指标。

团队技能栈层面，后端工程师可以直接上手。因为向量搜索的入口和普通 DynamoDB 查询是同一个体系，身份认证、权限模型、SDK 调用方式都保持一致。新人接手的时候不需要再学一套独立的向量库 API，认知负担明显下降。

还有一点常被忽略：POC 速度。以前想验证一个知识库场景，先得部署或者购买一个向量库实例，等资源开通、配置好网络权限，一天时间就过去了。现在如果数据本来就在 DynamoDB，开一个向量索引就能开始验证，半天以内能出一个带检索效果的 Demo。对于需要快速证明价值的团队来说，这个差异很关键。

2. 数据一致性：双写时代最难解的题，现在被挪到了数据库内部

2.1 双写同步失败的真实翻车场景

只要做过 RAG 相关的生产系统，大概率经历过这种问题：业务方更新了产品手册里的某个关键参数，业务库里的记录是新的，但向量库里的老文档切片没被及时替换。结果 AI 客服回答问题时，检索到的还是旧版本切片，给出一个已经失效的答复。用户照着操作失败，回头投诉，最后排查一圈，发现不是模型的问题，是向量库同步任务挂了一个晚上。

这种问题的根源在于"两条管道，两份数据"的结构。业务数据的生命周期由业务系统管理，向量数据的生命周期由同步任务管理，二者的重试策略、幂等逻辑、失败语义完全不同。同步任务一旦出现部分失败，就需要人工对账，而绝大多数团队根本没有建对账机制，都是出了问题再补救。

更隐蔽的是删除场景。文档下架了，业务库里的记录删除了，但向量库里的向量如果忘了删，它仍然会参与检索。用户一搜，出来的是一篇"已失效文档"的摘要，点击进去才发现是旧内容。这类问题在长尾文档很多的知识库里尤其难发现，因为没人会逐个检查"不该出现的搜索结果"。

2.2 单表内向量与业务字段的联动更新

DynamoDB 原生向量搜索把向量字段变成了表里一个普通属性，这从根本上改变了上面几个问题的处理方式。

更新逻辑变成了同一条写请求的事：文档改了，重新生成向量，然后对同一条记录执行更新操作，业务字段和向量字段一起被覆盖。这个过程不再需要跨系统协调，上一秒的旧版本读不到之后，下一秒拿到的一定是"业务字段 + 向量字段"的同一版本。

删除逻辑也变得简单了。业务记录被删除，向量字段随记录一起消失；更常用的做法是用 TTL，给每条记录设置过期时间，到期后 DynamoDB 自动清理整条记录，连带向量一起清掉。这就解决了"文章下架但向量还在检索"的经典问题。

权限治理也会有改善。因为只有一套表、一套 IAM 权限模型，不会出现"业务库的权限是严格控制的，向量库却因为网络策略漏了一条，直接对公网开放"这种错位。知识库数据往往包含企业内部资料，这类权限收敛对我来说是刚需。

2.3 别高兴太早：索引异步与部分更新问题

不过我要泼一盆冷水：原生向量搜索不等于读写强一致。写入请求成功返回后，向量索引的更新通常还需要一点异步时间，极端情况下，刚写入的数据立刻查询，未必能立刻被召回。这和 DynamoDB 本身的最终一致性模型是互相呼应的。做知识库问答时，如果用户刚上传文档就立刻提问，系统可能要先允许一点延迟，或者前台做"文档处理中"的提示，否则会出现"明明传上去了，却答不出来"的诡异体验。

还有个应用层责任要理清：向量字段本身不会自己更新。文档正文变了，系统并不知道"这个变化是否足以改变语义"，需要应用层决定是否重新生成向量。这个判断逻辑不在数据库能力范围内，要放在写入端处理。

我常用的做法是在写入端放一个 Lambda，它会比较文档哈希，内容变了就重新生成 embedding，并把向量字段一起写进同一张表；如果只是改了作者、创建时间这类元数据，就只更新普通字段，不动向量。这样既保证一致性，也避免浪费 embedding 调用的费用。

3. 成本账与规模边界：按量付费真香，但天花板要摸清

3.1 计费模型完全变了

传统的向量库成本结构大致分两种：自建型，你得按峰值预留 CPU、内存、磁盘，然后为用不上的冗余容量持续买单；托管型，通常按底层计算规格或容量单位计费，起步规格就规定了每月的固定成本，哪怕你的知识库只有几万条数据，钱也省不下来。

DynamoDB 的计费模型是另一套逻辑：存储按实际使用量收费，读写按容量单位结算，没有"最低规格"的约束。向量索引的存储会计入表本身，KNN 查询消耗读容量单位，写入时向量字段和其他字段一起占用写入容量。这等于把知识库的成本从"固定预算"变成了"随用量波动"，规模小的时候尤其划算。

拿一个实际例子估算：某制造企业的售后知识库，约 10 万条文档切片。每条切片存了文本内容、业务标签和一个 1536 维的向量，单条记录大约 7KB 左右，整张表接近 0.7GB。存储成本可以忽略，查询每分钟大概 20 次，读容量单位消耗也不高。整体算下来，每月成本基本就是一杯咖啡钱。这在传统向量库里根本做不到，因为哪怕很小的实例，每月的起步账单也在那里摆着。

3.2 多少条切片以内推荐用 DynamoDB

我给不出一个绝对精确的边界，因为结果受向量维度、单条大小、QPS 和索引复杂度影响。但从我自己实测下来的数据和同行交流的情况看，可以给一个粗略的分层：

• 十万级切片以下：完全是舒适区。无论是存储、延迟还是运维成本，DynamoDB 原生向量搜索都明显优于独立向量库。
• 几十万到一百万级切片：依然可用，但要注意数据量、索引存储、RCU 消耗的联动增长。如果查询并发不高，比如面向内部员工的知识库，一天几百上千次问答，完全扛得住。
• 数百万级切片加上高并发查询，或者大维度向量：建议先做压测。这时候专用向量库的批量导入能力、显存索引、更激进的压缩策略优势会逐渐显现。

我个人倾向于把"DynamoDB 原生向量搜索是否够用"的判定点放在数据增长速度和并发压力上，而不是单纯看条数。如果一条业务表的增长很慢，一年也就翻一倍，那用 DynamoDB 承载知识库检索很从容；如果每天灌入几十万条新切片，同时查询侧还要支撑几百 QPS，那它就不再是明显优势方案了。

3.3 超大规模的退路：混合架构与零 ETL

数据规模一旦跨过某一个点，还有一条折中路子，不用急着推倒重来。DynamoDB 本身持续提供零 ETL 集成到托管搜索服务的路径：业务数据照常写进 DynamoDB，向量字段也照常维护，同时通过零 ETL 同步机制复制一份数据到专门的搜索集群，由它承担高并发、重过滤的复杂检索。

这种混合架构的好处是入口统一、成本弹性。写入端永远只面对一张表，应用层不需要知道数据去了哪儿；低峰期可以只走 DynamoDB 原生向量搜索，高峰期或者复杂的语义检索任务再走搜索集群。数据一致性方面，零 ETL 的同步延迟通常可以做到秒级，对知识库检索这种场景足够接受。

如果你连第二套系统都不想引入，也可以做冷热分层：热文档的向量放 DynamoDB 上服务在线查询，冷文档归档到成本更低的对象存储，需要时再回流。我见过几个团队就是这样做的，几百万条历史工单切片放到冷层后，在线检索的噪音反而更少，召回质量也有所提升。

4. 选型决策与落地清单：从 POC 到生产要盯紧的细节

4.1 一张选型对照表，先定量再定性

把三个影响落到决策层面，我习惯用一张表先把约束条件摆出来。它不能替你做决定，但能帮助你在评审会上把"要不要上 DynamoDB 原生向量搜索"这个感性问题转成几个可讨论的量化指标。

一个很常见的实际决策路径是：知识库是内部工具，数据量十万级，团队只有三个后端，没有专人维护搜索基础设施，那不用犹豫，直接先上 DynamoDB 原生向量搜索。反倒是那种要做对外搜索服务、数据量摸到千万级、还要支持高并发多条件检索的场景，一开始就得上独立向量数据库，硬塞进 DynamoDB 是浪费时间。

4.2 分区键、字段与 embedding 维度的配置经验

分区键设计是落地时最容易被低估的一个环节。向量搜索如果能在分区键范围内找最近邻，结果质量会更好，成本也更低，因为系统不会扫全表。比如知识库按部门、按租户、按知识域划分分区键，检索时带上这个条件，相当于先做水平切分再做近邻搜索，既隔离了租户数据，又缩小了搜索范围。

距离函数的选择要看你的向量来源。文本 embedding 模型出来的向量，语义相似通常用余弦距离，它对向量模长不敏感，更适合语义检索场景；如果是图像特征或者数值特征，向量的大小本身携带信息量，用欧几里得距离更合理。这个选错会影响召回质量，但不是不能换，只是换了之后索引要重建，代价不小。

embedding 维度要提前确认两件事：一是模型输出的维度是否在 DynamoDB 向量索引支持范围内，不同模型差异很大，有的文本模型只有几百维，有的多模态模型可能几千维；二是维度越高，单条记录越大，存储和查询成本都会涨。对于纯文本知识库，很多通用 embedding 模型的默认维度在当前支持范围内都够用，但如果你的模型输出维度明显偏高，就要评估是否需要降维，或者换一个向量库方案。

4.3 落地前必须验证的五个事项

第一，确认区域和版本支持情况。这类新功能通常是分区域逐步开放的，生产账号所在区域是否支持原生向量搜索、支持到哪个版本，要以官方文档为准，不要拿预览期的信息做生产决策。

第二，做真实的召回率测试。很多人只测查询延迟，不测召回效果。我建议拿一批真实的问答对，掩藏答案，看检索能不能召回正确文档。召回率不过关，延迟再低也白搭。这一步要趁早做，别等功能都接好了再返工。

第三，验证索引构建的耗时。第一次给已有表开启向量索引时，索引构建需要一些时间，期间查询行为是什么样、表是否可读，要在预发环境里先确认清楚。否则生产表一开索引，业务读写先被影响，就尴尬了。

第四，检查监控指标是否覆盖到位。向量搜索的延迟、节流、索引存储增长，这些都需要有对应的监控告警。我建议建好 Dashboard，把 KNN 查询的读容量消耗和数据量增长放一起看，提前发现"数据量在涨但容量规划没跟上"的趋势。

第五，设计好失败的降级方案。万一次日向量索引异常，知识库问答不能直接瘫掉，至少要能回退到关键词搜索或者基础查询。DynamoDB 的优势在于普通字段还在表里，备用方案不用依赖另一个系统。

从我个人的角度说，DynamoDB 原生向量搜索真正解决的不是"检索性能最强"的问题，而是让大量中小知识库项目不再需要为了一个 RAG 场景去部署一套重型基础设施。它把"要不要引入向量数据库"这个决策点往后推了——等到数据量真正大到撑不住、并发复杂度真正高到兜不住的时候，再上专业向量库，那时候你的数据模型和写入链路已经经受过实际场景验证，迁移起来也更有底气。最后提醒一句：如果你现在正在做知识库 AI 的选型，别先去看各种炫酷的向量数据库排名，先看看你核心业务数据存在哪儿。数据已经在 DynamoDB 里，业务场景又不复杂的话，原地拥有一套可用的向量检索能力，往往是投入产出比最高的起点。