低成本语义搜索方案：用 DynamoDB 颠覆 RAG 成本结构

当向量数据库成为中小企业的"隐形杀手"

想象一下这个场景：一家 20 人规模的律师事务所，想用 AI 帮助律师快速检索数万份案件文档。团队调研后发现，主流向量数据库（如 Pinecone、Milvus Cloud）的月费用轻松破万人民币——这对中小企业来说，AI 还没产生价值，先被基础设施成本"杀死了"。

问题出在哪里？向量数据库本质上是专门为向量检索优化的数据库，它需要独立的服务器集群、内存优化、索引维护，这些资源成本最终都会转嫁给用户。而中小企业实际需要的 RAG 场景，往往只是几千到几万条文档的小规模数据。

亚马逊云科技（AWS）官方解决方案团队（AWS Solutions Library）推出的 Guidance for Low Cost Semantic Search on AWS（以下简称 Low Cost RAG）正是为解决这个问题而来：把向量数据库换成 DynamoDB，把成本从每月数百美元压到不足 30 美元。

从"买数据库"到"自己搭"：DynamoDB 向量化的思路转变

传统向量数据库的核心价值在于向量索引——一种专门加速高维向量相似度搜索的数据结构（如 HNSW、IVF）。但这个索引本身并不"魔法"，它的本质是：在大量向量中，快速找到与查询向量最接近的 Top-K 个结果。

DynamoDB 怎么做到这一点？方案采用了分桶策略 + 精确检索的组合：

分桶（Bucket）：将向量空间按余弦相似度阈值划分成多个"桶"，查询时先锁定相关桶，再在该桶内做穷举精确匹配。数据量在几千条时，这种策略的延迟完全可以接受。
DynamoDB 原生能力：利用 DynamoDB 的分区键（PK）+ 排序键（SK）+ GSI 索引，可以高效地组织向量元数据（chunk_id、doc_id、text、metadata）。

这样做有一个关键前提：数据规模必须"小"。官方明确标注了 100~400 份 PDF 文档的测试场景，盲猜在 1 万条 chunks 以内 DynamoDB 方案有成本优势；一旦数据量达到数十万条，向量数据库的 HNSW 索引优势会显现。所以这个方案的核心定位是：小规模 RAG 的极致性价比之选。

图注：Low Cost RAG 完整系统架构，涵盖文档处理流水线、RAG 推理链、前端交互层

端到端技术栈：从 PDF 上传到答案生成的完整链路

文档处理流水线（Ingestion Pipeline）

当用户上传一份 PDF 文档后，系统经历了以下处理阶段：

S3 触发：文档存入 S3，触发 Step Functions 状态机启动
Textract 提取：Amazon Textract 自动识别 PDF 中的文本内容（支持扫描件 OCR）
LLM 解析（Bedrock + Claude）：Claude 3 Sonnet 将长文档切分为语义完整的 chunks，并生成元数据标签（如"合同条款"、"案件摘要"）
向量化（Titan Text Embedding）：用 Amazon Titan Text Embedding 模型将每个 chunk 转换为 1536 维向量
DynamoDB 入库：向量 + 元数据 + 原始文本批量写入 DynamoDB

整个流水线由 AWS Step Functions 编排，支持重试、错误处理和状态追踪。

RAG 推理链（Query Pipeline）

用户在前端 Web UI 输入自然语言查询后：

查询首先经过 Cognito 用户认证
API Gateway 接收请求，路由到 Lambda 函数
Lambda 调用 Titan Text Embedding 将用户问题向量化
从 DynamoDB 检索相似 chunks（分桶策略）
将检索到的 chunks 作为上下文，调用 Claude 3 生成最终答案
答案通过 API 返回前端，同时记录到 DynamoDB 对话历史表

前端 Web UI

项目提供了一个基于 HTML/JS 的单页应用（S3 + CloudFront 托管），支持：

PDF 文档上传（管理员功能）
对话式问答界面
文档管理（删除已上传文档）
用户注册与登录（Cognito）

图注：Amazon Bedrock 模型访问配置界面

图注：Claude 3 Sonnet 模型权限启用

为什么选 DynamoDB 而不是专用向量数据库？

维度	Pinecone/Milvus	DynamoDB 方案
月费用（1万条数据）	~$100+	$530
部署复杂度	托管版简单，自托管需运维	完全托管，零运维
查询延迟（小数据）	<50ms（HNSW）	50~200ms（精确匹配）
数据规模上限	百万~亿级	建议万级
额外成本	向量存储+计算资源	仅 DynamoDB RCU/WCU
配套功能	向量检索为主	DynamoDB 全特性（事务、GSI、流）

DynamoDB 的优势在于它是AWS 原生服务：无需额外部署，与 Lambda、Step Functions、API Gateway 等服务天然集成，计费模型透明（按读写容量单元计费）。

开发者视角：CDK 基础设施即代码

项目的部署完全基于 AWS CDK（Cloud Development Kit），这是一个用 TypeScript/Python 等编程语言定义云基础设施的工具。相比于手写 CloudFormation YAML，CDK 的优势是代码可复用、逻辑可编程。

从 chatbot_stack.py 可以看出，整个系统的 CDK 定义了约 20+ 个云资源：

DynamoDB 表：3 张表（对话历史、小块向量、大块向量）
S3 桶：2 个（文档存储、网站托管）
Lambda 函数：多个 Python Lambda 函数处理不同业务逻辑
Step Functions：3 个状态机（文档解析、LLM 解析、删除文档）
API Gateway：REST API with Cognito 授权
CloudFront：前端 CDN 分发 + WAF 防护
Cognito：用户池管理（支持自助注册开关）
SNS：Textract 异步通知

CDK 栈通过 cdk deploy 一键部署，但前提是本地机器配置好 AWS CLI 凭证和 CDK 环境——这一步对非 AWS 深度用户来说并不简单。

成本实测：不同场景月费明细

官方提供的 4 个测试场景月费（美国东区默认配置）：

场景	文档量	查询频率	月费（美元）
场景 1	100 PDF	6次/小时	$23.78
场景 2	200 PDF	6次/小时	$29.26
场景 3	300 PDF	6次/小时	$40.70
场景 4	400 PDF	10次/小时	$67.95

主要费用来源：

DynamoDB 读写容量：文档入库时写入量大，日常查询以读为主
Bedrock Claude：每次查询调用，约 $7~12/月（按 token 计费）
Bedrock Titan Embedding：嵌入向量生成，入库时一次性费用
AWS WAF：$8.1/月（固定费用，提供基础 DDoS 和 SQL 注入防护）
Textract + Step Functions：仅在文档入库时计费，不属于日常月费

对比 Pinecone 的 $70+/月（入门级），节省幅度相当可观。

谁适合用这个方案？

适用场景：

100~500 份中小规模文档的 RAG 问答（如内部知识库、合同检索）
团队有 AWS 使用经验，熟悉 CDK 和 Lambda
需要控制 AI 基础设施成本，不愿为"可能用不到"的向量数据库能力付费
对数据隐私有要求（所有数据在自有 AWS 账号内）

不适用场景：

数据量超过 10 万条 chunks（查询延迟会显著上升）
团队没有 AWS 运维经验（CDK 部署有一定门槛）
需要跨云或本地部署
需要毫秒级实时检索（DynamoDB 精确匹配不如 HNSW 索引快）

局限性与挑战

向量检索精度：分桶策略的查全率理论上不如 HNSW 精确，特别是向量分布不均匀时
扩展性瓶颈：DynamoDB 单表吞吐有分区上限（约 1000 WCU/分区），高并发场景需预留足够容量
部署门槛：需要 CDK、Docker、AWS CLI 配置，不适合完全零基础用户
Claude API 成本：虽然基础设施便宜，但 Bedrock Claude 的 token 计费在大规模查询场景下不可忽视
无中文文档：目前项目文档全英文，AWS CDK 术语对国内用户有一定阅读门槛

行业意义：RAG 民主化的新思路

Low Cost RAG 的出现体现了云原生时代一个重要趋势：基础设施解耦。过去做 RAG，似乎"必须"用专用向量数据库。但 AWS 团队用 DynamoDB + 分桶策略证明了，只要满足业务需求的精度，通用的云服务完全可以替代专用数据库，成本可以降低一个数量级。

这一思路与"用 S3 做向量存储"、"用 PostgreSQL pgvector 插件做向量检索"一脉相承，本质上都是在说：向量检索不是只有一种实现方式，在特定数据规模下，简化的方案往往更实用。

随着 Claude、Gemini 等 LLM 的上下文窗口不断扩展（Gemini 1.5 Pro 已支持 100 万 token），有人认为向量检索的必要性在下降——直接把所有文档扔进上下文不就行了？但对于需要实时更新、快速检索、结构化元数据过滤的场景，向量数据库（或 DynamoDB 替代方案）仍然不可替代。