一个RAG原型，按教程一步步搭起来：API收到文档，切块，生成向量，写进向量数据库。查询时取出上下文，丢给大模型，返回答案。演示阶段它跑得毫无破绽。

真正拿去用的时候，它散架了。问题不在检索逻辑，也不在提示词。问题出在数据进入系统的这一段路上。

打开网易新闻 查看精彩图片

拿一份47页的PDF去测，向量化接口在第38页超时，28秒后返回504网关超时。整个流程是同步的，所以这一次API请求直接失败。想重试，就得把整份文档重新切一遍，重复向量的风险和白白烧掉的算力都跟着来了。

向量库不是系统的核心

那次失败之后，一个认知被纠正过来：向量数据库只是派生出来的索引，不是系统的地基。生产级RAG管线里真正难的工程问题，是管理数据进入过程的状态、边界和失败模式。

原来的设计里，向量库同时扮演了两个角色。少一个向量，那份文档就等于丢了。想换一套切块策略，就得让客户端把所有文档重新上传一遍。

正确的做法是把原始文档当作不可变的真相来源，把向量存储当作最终一致的派生索引。这意味着上传动作不能和向量化过程绑在一起。接口要做的只是收下文件、持久化存储、立刻返回。处理必须异步进行。

围绕S3搭建异步边界

在AWS上落地这件事，需要一条事件驱动的管线，能在下游依赖又慢又不稳定的情况下，既不丢数据，也不让用户的请求失败。

整个数据进入的边界围绕Amazon S3来设计。文件上传到S3之后，处理才从这里开始。

（原文在此处中断，后续内容未提供。）