DynamoDB 原生向量搜索上线，我试了试，三个好处一个坑

我对比了DynamoDB原生向量搜索和以前用OpenSearch零ETL的方案，实际跑了一遍。先说结论：这个功能对做RAG（检索增强生成）的同学是个好消息，但新手容易踩一个坑。我实验室最近在做一个强化学习与知识库结合的调度优化项目，需要把状态描述转成向量存起来，然后快速找相似历史场景。之前要么用OpenSearch单独搭一个集群，要么用Pinecone这种第三方服务，现在DynamoDB直接支持了，相当于少了一个组件。

先解释一下向量搜索是什么。简单说，就是把文本、图片、音频转成一串数字列表（专业术语叫嵌入向量，embedding），然后在这堆数字里找“形状最像”的。比如把“实验室的GPU配额不够了”转成1536个数字，再跟其他文字转出来的数字列表比一比，数字最接近的就是语义最像的。DynamoDB这次加的功能就是在表里直接建一个向量索引，跑这种相似度查询，不再需要单独开一个OpenSearch集群。

要启用这个功能，你的DynamoDB表必须是标准表类型（DynamoDB Standard），不能用按需模式或者旧版表。如果你之前用的是按需模式，需要在控制台里把表类型改成标准，这操作不会丢数据，但会改计费方式。另外，向量索引只能在创建表的时候指定，不能事后加。

这是第一个坑：我一开始以为像普通索引一样可以随时建，结果建完表之后发现根本没有“添加向量索引”的选项。后来查文档才知道，必须新建表时在“高级设置”里勾选“启用向量搜索”，然后填维度数和索引类型。所以如果你想把现有表加上向量搜索，只能新建一个表，然后把数据迁过去。

假设你有一个空AWS账号，先从控制台开始。登录后搜DynamoDB，点“创建表”。表名填my_vectors，分区键选id（字符串类型），排序键可以不填。往下翻到“高级设置”，点开，找到“向量搜索”，勾选“启用”。然后需要填两个参数：向量维度和相似度度量。维度取决于你用的嵌入模型，比如OpenAI的text-embedding-3-small是1536维，Claude的amazon.titan-embed-text-v2是1024维。我用的Titan模型，所以填1024。相似度度量支持cosine（余弦相似度）、euclidean（欧氏距离）、dot_product（点积）等多种，根据你的嵌入模型选择合适的度量，比如余弦相似度适合语义匹配。我选cosine。点击创建，等几十秒表就建好了。

接下来要插入数据。你可以在控制台里直接点“探索表项”，然后“创建项”，手动加一条测试数据。但手动加向量字段比较麻烦，需要把向量写成JSON数组。我建议用aws cli操作。先安装好AWS CLI，配置好access key。假设你有一篇文档的文本，用Titan模型生成了向量，存在vector.json文件里，然后执行：

aws dynamodb put-item --table-name my_vectors --item ‘{“id”: {“S”: “doc1”}, “content”: {“S”: “实验室GPU配额不够了”}, “vector”: {“L”: [{“N”: “0.123”}, {“N”: “-0.456”}, 。]}}’

注意要把vector字段名写成vector（默认就是这个名字，可以在创建表时自定义）。向量必须是L类型（列表），每个元素是N类型（数字字符串）。这个格式很容易写错，我一开始写成了M（映射类型），报错“Invalid type for vector field”。踩坑点：向量字段名必须和建表时指定的一致，且值必须是数字列表。

查询也要用API。假设你想找与“GPU不够用”最相似的5条记录，先用同样模型生成查询文本的向量，然后执行query操作。在aws cli里：

返回结果里会包含VectorSearchResults字段，里面是排好序的相似项。注意：--limit控制返回数量，但K参数才是真正的邻居数，两者要一致，否则会多返回一些不相关的项。我一开始没加--limit，结果返回了所有项，但排序不对。踩坑点：K必须小于等于limit，不然返回结果可能包含无效得分。

好处很明显：零运维。以前用OpenSearch需要自己管集群大小、节点数、备份，现在DynamoDB自动处理，省心。实时性。写入后立即可查，延迟大概在几十毫秒，对我这种做强化学习状态查询的场景完全够用。成本清晰。按读写容量计费，没有额外的搜索节点费，小规模场景比OpenSearch便宜很多。

但缺点也得说清楚：相似度度量选择灵活，但需注意维度限制。最大支持4000维，目前主流模型都够，但未来如果出现更高维的模型，可能就套不住了。混合搜索能力弱。虽然可以用FilterExpression做结构化过滤，但过滤器是在向量搜索之后应用的，效率不如专门的向量数据库（比如Pinecone的metadata过滤）。如果你的场景需要同时按类别和语义搜索，最好还是用OpenSearch的零ETL方案。

我倾向于认为，AWS正在把向量搜索内嵌到每一个主流数据库里。DynamoDB、ElastiCache、OpenSearch都已经支持，接下来Aurora和RDS大概率也会跟。这种趋势意味着，未来的RAG应用部署会变得越来越简单，几乎不需要额外组件。但另一方面，对于专门做向量数据库的公司（Pinecone、Weaviate等），竞争压力会很大，它们必须提供DynamoDB做不到的功能，比如混合搜索、多模态支持、更精细的索引策略。对于普通开发者，建议先试试DynamoDB原生向量搜索，如果场景简单，直接用它就够了；如果遇到过滤性能瓶颈，再考虑迁移到OpenSearch或第三方服务。