北京
一个RAG原型，按教程一步步搭起来：API收到文档，切块，生成向量，写进向量数据库。查询时取出上下文，丢给大模型，返回答案。演示阶段它跑得毫无破绽。
真正拿去用的时候，它散架了。问题不在检索逻辑，也不在提示词。问题出在数据进入系统的这一段路上。
拿一份47页的PDF去测，向量化接口在第38页超时，28秒后返回504网关超时。整个流程是同步的，所以这一次API请求直接失败。想重试，就得把整份文档重新切一遍，重复向量的风险和白白烧掉的算力都跟着来了。
向量库不是系统的核心
那次失败之后，一个认知被纠正过来：向量数据库只是派生出来的索引，不是系统的地基。生产级RAG管线里真正难的工程问题，是管理数据进入过程的状态、边界和失败模式。
原来的设计里，向量库同时扮演了两个角色。少一个向量，那份文档就等于丢了。想换一套切块策略，就得让客户端把所有文档重新上传一遍。
正确的做法是把原始文档当作不可变的真相来源，把向量存储当作最终一致的派生索引。这意味着上传动作不能和向量化过程绑在一起。接口要做的只是收下文件、持久化存储、立刻返回。处理必须异步进行。
围绕S3搭建异步边界
在AWS上落地这件事，需要一条事件驱动的管线，能在下游依赖又慢又不稳定的情况下，既不丢数据，也不让用户的请求失败。
整个数据进入的边界围绕Amazon S3来设计。文件上传到S3之后，处理才从这里开始。
（原文在此处中断，后续内容未提供。）
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
