端到端 RAG 系统怎么落地：从课程 Demo 到可维护知识库

资料 最后一章用几条总结把前面内容收住：用多种文档加载器导入数据，把文档分割成语义完整的文本块，为这些块创建 Embedding 并放入向量存储，做语义搜索，处理搜索失败，再把检索结果和问题交给 LLM 生成答案，最后补上对话历史，做成端到端聊天机器人。

这段总结很短，但它提醒了一件事：RAG 不是“在网页上放一个 AI 输入框”。输入框只是最外层。真正决定质量的是后面那条资料链路。资料有没有被正确读出来，chunk 是否能单独回答一个问题，metadata 是否保留来源，向量库能不能稳定召回，模型是不是只按资料回答，多轮追问会不会丢上下文，这些都比聊天框样式更影响结果。

所以做私有数据问答时，不要一开始就把目标写成“做一个知识库机器人”。更准确的目标是：做一套可以导入资料、检索资料、追溯依据、持续排查和迭代的问答系统。这个目标听起来没那么热闹，但更接近能长期使用的产品。

Document Loading 是入口。资料 前面演示过 Py资料Loader、CSVLoader、WebBaseLoader、NotionDirectoryLoader 等加载器，不同来源的资料会被统一成 Document。这个对象最重要的两个部分是 page_content 和 metadata。page_content 是正文，metadata 是来源、页码、行号、文件路径这类描述信息。

这一步最容易被低估。很多知识库效果差，不是因为模型不够好，而是资料一开始就乱。资料 抽出来有页眉页脚、断行、乱码，网页里混着导航和脚本，CSV 行字段没有解释，音视频转写没有时间戳，这些都会进入后面的切分和向量化。入口脏，向量库只会把脏资料索引得更快。

比较稳的做法是，加载后先抽样看 Document。看正文是否能读，页码是否对得上，标题有没有保留，metadata 是否能指回原始文件。不要急着 embedding。能在加载阶段发现的问题，就不要拖到生成阶段才让模型替你猜。

Splitting 的目标不是把文本切小，而是把文本切成能被检索、能被模型阅读的语义块。文中多次用 RecursiveCharacterTextSplitter，设置 chunk_size 和 chunk_overlap。它的基本思路是先按较自然的分隔符切，如果太长再往下切，并用重叠保留前后连接。

chunk 太大，检索回来会塞进很多无关内容；chunk 太小，答案需要的上下文又可能被拆散。比如一段制度里同时讲报销范围、票据要求和审批时限，用户问“票据要什么材料”，如果 chunk 包含太多主题，模型还要从长段落里挑；如果把票据要求拆得只剩一句，又可能丢掉适用条件。

所以切分要和资料类型一起看。课程讲义适合按标题和段落切；FAQ 可以一问一答切；表格类资料可能按行或记录切；长 资料 要处理目录、页眉和标题层级。可以总结里说“语义完整的文本块”，这句话比具体参数更重要。参数只是手段，语义完整才是目的。

Storage 不是把 embedding 存进去就完事。文中用 Chroma、DocArrayInMemorySearch 等向量存储示例，反复强调向量、原文和 metadata 要一起保存。检索时，用户问题会被转成向量，再和库里的向量比较，返回 Top-K 相关片段。这个过程跑通以后，才有语义搜索的基础。

但 资料 也展示了语义搜索的失败边界：重复文档会让 Top-K 被重复 chunk 占满；只靠相似度可能把第一讲和第二讲混在一起；长 chunk 里真正有用的内容可能只有几句。对应的改进包括 MMR、metadata 过滤、SelfQueryRetriever、ContextualCompressionRetriever，以及必要时混合 TF-IDF、SVM 等检索方式。

因此，存储和检索要一起设计。metadata 不完整，后面就很难过滤；重复资料不清理，MMR 也只能缓解；不保存 source_documents，答案就不可追溯。向量库不是一个孤立组件，它是资料质量、切分策略、过滤字段和评估样本共同作用的地方。

Output 阶段看起来最像 AI：模型拿到问题和上下文，生成一段回答。资料 用 RetrievalQA 演示了这个过程，也用 PromptTemplate 限制模型：不知道就说不知道，不要编造，回答尽量简明。后来又打开 return_source_documents，让系统能返回检索到的源文档。

真正调试时，source_documents 比最终答案更重要。答案错了，先看源文档里有没有正确依据。如果没有，回到检索；如果有，再看 prompt 是否把“基于上下文回答”讲清楚；如果 prompt 也没问题，再看模型是否没有遵守格式。这样排查，比一上来反复改提示词省得多。

文中的聊天机器人还保留 generated_question、db_response、chat_history 等状态。这个习惯应该延续到真实项目。RAG 系统不是黑盒问答，至少在后台要能看到每一步输入和输出。看不见中间结果，就只能凭感觉调参，很快会陷入“今天好像准一点，明天又不准”的状态。

相关的 Chat 章节把普通问答链升级成 ConversationalRetrievalChain。它增加了 ConversationBufferMemory，用 chat_history 保存当前会话的历史，并在用户追问时把历史和新问题合并成完整查询。这样，用户说“为什么需要这个前提”，系统才有机会知道“这个前提”指上一轮提到的 Python 或 probability。

但这类 Memory 主要是短期会话上下文，不是长期记忆系统。它不会自动把用户偏好、业务规则和长期事实沉淀进知识库。它也可能带来历史污染：用户切换话题后，如果旧对话还在上下文里，检索和回答可能被前一个主题影响。示例里的 Clear History 按钮不是可有可无，它是切换话题和重置上下文的基本操作。

所以，在端到端系统里，Chat 是最后一层体验，不应该替代前面的资料管理。知识库负责事实，对话记忆负责当前上下文，业务系统负责实时状态和权限。把这三者混在一起，短期看像是功能强，长期看会很难排查。

第一类是资料治理。课程 Demo 可以只加载一个 资料，用内存向量库跑通；真实系统要支持多文件、多版本、权限范围、资料过期、重复内容和冲突内容。资料不治理，RAG 会变成“把所有文档都丢给 AI”，效果一开始也许还行，资料一多就会漂。

第二类是评估和日志。每次迭代要记录用户问题、命中文档、生成答案和人工判断。可以总结里说这是快速迭代的领域，这不是一句客套话。RAG 的参数、资料和模型都会变，只有留下失败样本，才知道这次调整到底改善了什么，又引入了什么副作用。

第三类是产品边界。用户应该知道答案来自哪些资料，资料不足时系统要能说不知道，涉及权限的内容要在检索前过滤，切换主题时要能清空历史。一个可维护知识库不一定最花哨，但它要让用户和使用者都知道：这条答案从哪里来，为什么这么答，哪里可能不确定。

如果现在要从零开始做，不建议一口气接入所有文档。更稳的方式是选一个边界清楚的小场景，比如某一类课程讲义、一个产品手册、一组客服 FAQ 或一套内部制度。先把加载、切分、向量库、检索、回答、来源展示和聊天历史跑通，再逐步扩展。

小闭环的好处是问题容易定位。用户问了 30 个真实问题，哪些没答出来，source_documents 是否正确，Top-K 是否重复，metadata 是否缺字段，generated_question 是否改写错，这些都能快速看清。等这个闭环稳定，再把资料范围扩大，系统才不容易被新资料冲乱。

相关的最后说已经掌握了如何用 LangChain 访问私有数据并建立个性化问答系统。落到工程里，这句话可以再具体一点：不是一次搭好，而是每个环节都能检查，每次失败都能归因，每轮资料更新都能重新评估。做到这一步，RAG 才从课堂 Demo 变成能长期维护的知识系统。