做企业知识库 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 原生向量搜索适合选独立向量数据库数据规模十万级切片以内增长平缓百万级以上日增量大并发要求内部知识库低到中 QPS高并发对外服务低延迟敏感数据一致要求业务元数据与向量需同一生命周期可以接受独立同步链路团队维护能力后端为主不想再养一套基础设施已有专门搜索/向量团队成本模式追求按量付费避免固定实例开销愿意为高性能预留固定资源检索过滤复杂度按分区键过滤为主需要多字段复杂组合过滤一个很常见的实际决策路径是知识库是内部工具数据量十万级团队只有三个后端没有专人维护搜索基础设施那不用犹豫直接先上 DynamoDB 原生向量搜索。反倒是那种要做对外搜索服务、数据量摸到千万级、还要支持高并发多条件检索的场景一开始就得上独立向量数据库硬塞进 DynamoDB 是浪费时间。4.2 分区键、字段与 embedding 维度的配置经验分区键设计是落地时最容易被低估的一个环节。向量搜索如果能在分区键范围内找最近邻结果质量会更好成本也更低因为系统不会扫全表。比如知识库按部门、按租户、按知识域划分分区键检索时带上这个条件相当于先做水平切分再做近邻搜索既隔离了租户数据又缩小了搜索范围。距离函数的选择要看你的向量来源。文本 embedding 模型出来的向量语义相似通常用余弦距离它对向量模长不敏感更适合语义检索场景如果是图像特征或者数值特征向量的大小本身携带信息量用欧几里得距离更合理。这个选错会影响召回质量但不是不能换只是换了之后索引要重建代价不小。embedding 维度要提前确认两件事一是模型输出的维度是否在 DynamoDB 向量索引支持范围内不同模型差异很大有的文本模型只有几百维有的多模态模型可能几千维二是维度越高单条记录越大存储和查询成本都会涨。对于纯文本知识库很多通用 embedding 模型的默认维度在当前支持范围内都够用但如果你的模型输出维度明显偏高就要评估是否需要降维或者换一个向量库方案。4.3 落地前必须验证的五个事项第一确认区域和版本支持情况。这类新功能通常是分区域逐步开放的生产账号所在区域是否支持原生向量搜索、支持到哪个版本要以官方文档为准不要拿预览期的信息做生产决策。第二做真实的召回率测试。很多人只测查询延迟不测召回效果。我建议拿一批真实的问答对掩藏答案看检索能不能召回正确文档。召回率不过关延迟再低也白搭。这一步要趁早做别等功能都接好了再返工。第三验证索引构建的耗时。第一次给已有表开启向量索引时索引构建需要一些时间期间查询行为是什么样、表是否可读要在预发环境里先确认清楚。否则生产表一开索引业务读写先被影响就尴尬了。第四检查监控指标是否覆盖到位。向量搜索的延迟、节流、索引存储增长这些都需要有对应的监控告警。我建议建好 Dashboard把 KNN 查询的读容量消耗和数据量增长放一起看提前发现数据量在涨但容量规划没跟上的趋势。第五设计好失败的降级方案。万一次日向量索引异常知识库问答不能直接瘫掉至少要能回退到关键词搜索或者基础查询。DynamoDB 的优势在于普通字段还在表里备用方案不用依赖另一个系统。从我个人的角度说DynamoDB 原生向量搜索真正解决的不是检索性能最强的问题而是让大量中小知识库项目不再需要为了一个 RAG 场景去部署一套重型基础设施。它把要不要引入向量数据库这个决策点往后推了——等到数据量真正大到撑不住、并发复杂度真正高到兜不住的时候再上专业向量库那时候你的数据模型和写入链路已经经受过实际场景验证迁移起来也更有底气。最后提醒一句如果你现在正在做知识库 AI 的选型别先去看各种炫酷的向量数据库排名先看看你核心业务数据存在哪儿。数据已经在 DynamoDB 里业务场景又不复杂的话原地拥有一套可用的向量检索能力往往是投入产出比最高的起点。