在生产全栈应用中运行 RAG 管道（无 Vector Database）
Source: Dev.to
Note: 如果您还没有阅读第一篇文章，您可以在此查看：[Insert link to previous post]
概览
在本文中，我们将仅后端版本的 RAG 流水线包装成完整的前端应用。结果是一个 全栈应用，它可以让您：
- 注册 / 登录（通过 AWS Cognito）。
- 上传 PDF 文档。
- 等待文档被索引（异步）。
- 提问，答案仅来自已上传 PDF 的内容。
目标是演示低成本 RAG 流水线在真实用户和流量下的表现，且不使用任何隐藏的延迟技巧或大规模假设。它非常适合早期实验、内部工具或 MVP，在这些场景中功能验证比峰值性能更重要。
源代码位于与前文相同的 GitHub 仓库的 full-stack-implementation 分支。
技术栈
| 层 | 技术 | 目的 |
|---|---|---|
| Frontend | Next.js (App Router) | 具有服务器端渲染和路由的 React 框架 |
| Tailwind CSS 4 | 实用优先的样式 | |
| shadcn/ui | 基于 Radix UI 基元构建的组件库（纽约风格） | |
| NextAuth.js | Next.js 的身份验证集成 | |
| Lucide React | 图标集 | |
| Backend | AWS Lambda | 无服务器 API 层 |
| AWS Cognito | 用户池与身份验证 | |
| Amazon S3 (presigned URLs) | PDF 存储 | |
| Amazon DynamoDB | 嵌入和元数据存储 | |
| Amazon Bedrock | 大语言模型与嵌入模型 | |
| Amazon EventBridge + SQS | 解耦的异步文档索引 |
用户流程
-
Authentication – 登录页面显示 Sign‑up / Login 表单。
由身份验证堆栈提供支持（Cognito + 登录 / 注册 Lambda）。 -
Upload PDFs – 登录后，用户可以拖拽 PDF 文件。
文件通过预签名 URL 上传至 S3；EventBridge 规则将消息推送到 SQS 队列，触发索引 Lambda。 -
Indexing – Lambda 提取文本，生成嵌入（通过 Bedrock），并将向量和元数据存储在 DynamoDB 中。
此步骤完全异步——用户不会被阻塞。 -
Chat UI – 索引完成后，文档会出现在聊天界面中。
选择一个或多个文档，输入问题，Ask‑Questions Lambda 将检索相关片段，运行 Bedrock LLM 推理，并返回答案。
演示 GIF
在此插入显示 PDF 上传流程的 GIF
架构图
在此插入 Lambda 索引流程的图示 (S3 → EventBridge → SQS → Lambda → DynamoDB) here
性能亮点
文档索引
| PDF 大小 | PDF 数量 | 平均 Lambda 持续时间 |
|---|---|---|
| ~400 KB | 1 | ~8 s |
| ~200 KB 每个 | 2 | ~8 s 总计 |
索引仍然是舒适的异步进行；用户永不被阻塞。
我已经对 20+ 份 大小相似的文档进行了索引，观察到索引 Lambda（包括 DynamoDB 写入）的耗时大约为 每份文档 4 秒。
Get‑Documents API
使用 Postman 测试
- 第一次请求：由于 cold start（冷启动）而较慢。
- 随后请求：warm start（热启动），始终快速。
在此插入 Postman 响应和 Lambda 持续时间的截图
在多用户环境中，cold start（冷启动）不常见，因此大多数用户会看到快速响应。
Ask‑Questions Lambda
| 场景 | 输入 | 平均持续时间（cold） | 平均持续时间（warm） |
|---|---|---|---|
| 1 份文档 | “这份文档是关于什么的？” | ~1.2 s | ~0.6 s |
| 4 份文档 | 相同的问题，多个文档 | ~2.0 s | ~1.1 s |
在此插入 Lambda 执行时间（cold vs. warm）的图表
该 Lambda 仅接收包含所选文档 ID 和用户问题的负载，从 DynamoDB 获取相关的嵌入向量，运行 Bedrock LLM 推理，并返回答案。
成本与运营收益
- 无长期运行的服务 → 零固定月费。
- 仅使用无服务器（Lambda、S3、DynamoDB、Bedrock） → 按使用付费。
- 为身份验证和文档处理分离堆栈 → 独立扩展且易于 API‑gateway 保护（导入 Cognito User Pool ID）。
每一个架构决策都旨在 最小化成本和运营开销，同时仍提供功能完整的 RAG 体验。
下一步
- 添加缓存（例如 DynamoDB TTL 或 CloudFront）以进一步降低冷启动影响。
- 实现分页以处理大型文档集。
- 探索微调 Bedrock 模型以实现领域特定的准确性。
随意克隆仓库，切换到 full-stack-implementation 分支，并使用您自己的 PDF 进行实验！
祝构建愉快！
四份文档的摘要
当查询 单个文档 时，冷启动时长约为 3 秒，而热启动的 Lambda 执行时间 低于 1.5 秒。
对于 四个文档，冷启动时长略高于 4 秒，热启动时长略低于 4 秒。
关键要点： 普通用户几乎不会遇到太多 Lambda 冷启动。对于使用极少 AWS 服务、保持低成本且复杂度最小的 RAG 系统来说，这些性能是可以接受的。
该应用验证了第一篇博客文章的理论——基于 DynamoDB‑based RAG 系统 不仅便宜，而且可用，只要了解其局限性，其性能也是可以接受的。
权衡
- Lambda 冷启动是真实存在的。
- 文档查询延迟符合预期，并随文档数量的增加而上升。
对于早期应用、内部工具、实验，甚至是希望控制成本但仍需可用 RAG 系统的黑客马拉松比赛，这种配置能够很好地完成任务。它让你能够快速交付产品、收集用户反馈，并将昂贵的架构决策推迟到数据真正迫使你做出选择时。